Using static databases and simple code generation to describe almost-dynamic game content.

I’m a solo indie dev working on my magnum opus of undisputed genius, _space_train. The daily grind of handling all aspects of game development is my burden, except when I’m not doing that because I have a regular job as a software developer instead. The major flaw with _space_train is that there’s no compelling reason to play it, and that that will continue to be the case for the foreseeable future. Nonetheless, if you want to follow development and watch as I slowly descend into madness and ignominy, it has an itch.io page here with a downloadable build and a Twitter here.

I had an issue building _space_train, my magnum opus of undisputed genius. The path to complex user interactions lay in the direction of adding ‘content’ for prospective users to engage with. In material terms, this meant adding more of the things that people do in the game: items to pick up and use. The problem was, adding new items was proving a surprisingly laborious task for me, the developer. Items in _space_train are represented by unique id numbers associated with an entry into a centrally managed map which has an id, a type, and a ‘display modifier’, a bitfield which specifies the appearance. The list of possible item types is represented with an enum , and a separate mapping exists to convert between the enum value for each type name and the string name for each type — the string value being necessary for accessing external resources for each item type, specifically Lua scripts which say what they do in various scenarios.

Adding a new item then, means adding both to the enum , and then to the name map, the name of the new item. In addition, over on the client side, the item type then needs to be associated with coordinates into the item texture, represented in another enum . All this before any actual material properties of the new item can be expressed!

A player standing by a handful of items in _space_train.

The elephant in the room is the possibility of loading and representing item types at runtime. This would necessitate separating items into some extra-compilatary zone where they can be manipulated distinct from the game code, all together all in one place. This was appealing in some ways — it would remove business data from the scrappy C++ engine I’ve insisted on building and relocate it, in a potentially more manageable format. I didn’t want to give up, however, on the ease of referring to item types directly in code, or take on the overheads of runtime look-up.