For anyone curios about how I made my game “Death Cell”, here’s a short post on that subject and how the game works technically.

Tools

• Unity 3.5.5 with MonoDevelop
• Ableton Live 8 Suite
• Native Instruments Komplete
• Pixelmator
• as3sfxr

Cellular Automata

I wanted to do something with cellular automata (CA) and somehow I got this idea of a scrolling Shoot ‘Em Up. I was originally planning on having the CA rules evolve over time by having different parts of the level, or different levels, with different rules visualized by changing color schemes. I wanted to have the player try to figure out the rules in each part of the game as the game progressed.

Time as you know is quite limited, and since I wasn’t an expert on Unity setting everything up took longer than expected, and I settled for just implementing the basic rules of Conway’s Game of Life, which turned out pretty good.

There is support for a full CA simulation in the code though, but it isn’t used. Game of Life only needs a binary state but the code has integer states if I would ever get to try out something else.

Instead I tried exploring what I could do with Game of Life and I found some really interesting parts in the gameplay that I wasn’t expecting. The first sign of emergent behavior was that the square blocks were totally indestructible, which makes them perfect for level design. Secondly, shooting things such as the glider may cause it to mutate into a square block which often results in death if you’re not careful.

This allowed for a somewhat interesting level design in the game. The large explosions in the game are simply a single glider crashing into a set of 2-3 stationary objects. Still, quite impressive, and very deadly.

Unity

At first I was unsure of how to implement a scrolling CA field in Unity as this is something you usually do in code, not with game objects and components. The way I ended up implementing it might not be the best way, but it works better than I expected it to.

Each cell is actually a prefab with a single rectangle (among other things) and a cell script. This is what performs the actual CA simulation. The cell changes the color of the material according to its state.

There is also a cell row prefab which just spawns a number of cell columns in that row. These rows are in turn spawned by a cell manager script and object which handles much of the game logic. The cell manager communicates hierarchically with the rows and then in turn with the cells.

There is a fixed set of rows and cells, initialized at startup, including neighborhood lists for the cells. When the screen scrolls the cell rows are used in a ring buffer fashion, i.e. the lowermost row is reinitialized and moved to the top.

There’s also a “scroller” object in the scene which tracks the movement and everything else is parented to this object, including the ship and the collision trigger. The ship itself is a separate prefab and is instanced as a separate game object. The ship fires bullets that also are separate from the CA simulation. Scrolling the world down and moving things up in the CA system simultaneously didn’t work like I was hoping for. The ship and spawned bullets instead check against the cell manager for collisions.

To have a level and be able to do level design, there is a “spawner” prefab with a collider which triggers a moving box collider parented to the “scroller” object. When one of these spawners are hit by the moving world trigger a shape, described by the spawner, is inserted into the CA system state at the x coordinate where the spawner was found. An enemy appears at the top of the screen at that position.

Results

The whole thing seems to work pretty good on my system. I experimented with different grid resolutions but larger grids seems to slow down on my machine, which I suspected. The final size is an acceptable tradeoff between speed and playability I think.