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. 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:
State management is one of the more difficult aspects of game programming. Entities in your game must behave differently depending on their internal state, and may depend on the state of other objects as well.
There are several approaches to solving this problem – the naive approach being lots and lots of conditionals. Finite state machines approach the problem by objectifying state and state transitions. More recently, with the growing popularity of higher level languages like Lua, Python, and C#, coroutines have become a popular choice for mitigating the complexities of managing state.
David McDonough, Jack Cooke, and I polished off a 1st place win at Rosetta Stone’s first annual 36 hour game jam in Harrisonburg Virginia on Saturday.
The requirements for the game were given out beforehand, and were very open-ended: make a game that “teaches.” Coming from Firaxis, we decided to make a strategy game, and settled on a “virus” theme. We liked the idea of a virus strategy game because we could abstract things visually (simple shapes with cool shaders – no characters to animate). The simulation aspect of the game play could also be very simple, and amounted to little more than three numbers driving a physics-based steering system (like this).
Each of us had some basic knowledge about how vira spread in the body, and we really didn’t go out of our way to do any additional research. One of Sid Meier’s 10 Rules of Game Design (we’re not really sure which one this is – he changes the order all the time) is to “make the game first, then do the research.” This may sound a bit strange at first, but it makes sense. If the game isn’t fun, it doesn’t engage the player and loses the ability to teach. If the simulation is to detailed or esoteric, the player can’t easily grok it, and you lose them. Civilization is a great example of this. It is built from the assumed historical knowledge of the average gamer (unless you fire up the Civilpedia). The game doesn’t teach by relaying historical facts, rather it does so by allowing the player to engage in a simulation that, while not historically accurate, illustrates very clearly the dynamics of industry, diplomacy, war, and culture.
The game we ended up with at the end of the day is called Pathogen. It features game play that is very similar to Phil Hassey’s Galcon with a 3D play surface. You move your swarm of vira from cell to cell, expanding your population and avoiding autoimmune cells as you go. Before each level, you load out with three “mutation cards” which give you power-ups as you hit certain population milestones. The game is very simple, but illustrates well the balancing act a virus must perform when successfully infecting it’s host. Continue reading “Victory at the Rosetta Stone Game Jam!”