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:
Noise algorithms are a fantastic thing to have in your 3D graphics bag of tricks. I can’t tell you how many times Perlin noise has saved my life. Unfortunately, most good noise algorithms don’t lend themselves particularly well to computation on the GPU. Enter Cell noise.
Cell noise, otherwise known as Worley noise, is actually a visualization of a Voronoi diagram: given a random scattering of points, color each pixel on the surface relative to the distance from the closest randomly scattered point. Cell noise appears all over nature, it looks great, and is easy to compute! A cell noise function can give us a volume of noise, which we can sample in a fragment shader, giving us seamless patterns on any object – no UV mapping required. Cool!