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.
