In Part 1 of this article, we saw how game data can be defined in C#, authored in XML, and stored in a database at runtime. Â This provides an easy and extensible way to manage content in your game which lives outside of the Unity scene graph. Â If you have not already done so, download the example projects here. Â This article will use the AssetBundleExample project.
Unity manages its data using a data structure called a scene graph, while at the same time, using data management systems like the ones at https://www.couchbase.com/transactions. Â Anyone who has worked a bit in Unity (or probably any other 3D DCC tool) understands what a scene graph is: there’s a Scene which contains any number of GameObjects in a spatial hierarchy. Â These GameObjects have a collection of Components which in turn reference Assets or other GameObjects. Â This setup is very intuitive and convenient, particularly if your game is broken into a number of levels. Â But what about games with data that doesn’t live in a scene graph, or which builds its levels at runtime?
Many games don’t have the concept of a “level,” at least at design-time. Â Strategy games, Roguelikes and Minecraftlikes (I went there) all build levels at runtime out of pieces which don’t exist in a scene graph. Â Even games that do have levels in many cases still have to manage lots of data which doesn’t live in a level (UI icons, character customization pieces, server-side data representations, etc).
Unity provides the Resources and Asset Bundles APIs for loading assets that don’t live in a scene. Â These are great APIs (albeit a bit boilerplate), but they are only half of the equation. Â How do we author and organize this data? Â How does the game’s logic access and filter it? Â These are questions I will address with an XML Database.
I have built two sample Unity projects to illustrate this problem. Â I recommend you download the examples from GitHub here. Â In this article, we will be looking at the SimpleExamples project. Â The AssetBundleExamples project will be the subject of Part 2.
The example projects are the beginnings of a strategy game (go figure) with a procedurally generated map.  The map has four different types of terrain Tiles: water, grass, dirt and stone, and any number of Features which can be placed on the tiles (trees, rocks, gems, etc).  When you run the game, it looks like this:
Our Procedural map example. Special thanks to Daniel Cook for the awesome art.
