OK, this trick is probably universally known, but I’ve only just discovered it (by the classic programmer method of reinventing it), so on the chance there are others who are unfamiliar with this technique, it’s worth describing.

Any sufficiently complex game is going to have “assets”: data external to the main program that the game depends on to function. This includes “art assets” (textures, images, music, etc) as well as more application-specific “data assets” which contain data in a format unique to your application (e.g. Icefall has “item types” of all the different equipment players can find/buy/receive).

Handling art assets is relatively easy: you create/modify them in Photoshop (or equivalent), you save them as PNGs or JPGs, and you’re done! You might wrap them all up in a custom file format to compress/encrypt/streamline them, but that’s pretty simple and you can do that at the very end of development.

Data assets are different. There aren’t any programs around that can edit “Icefall item types” files. I need to write my own “Item Types Editor”, which understands this format and can load, modify and save it. This leads to two problems:

1. I have to spend time writing an Editor. (the actual format load/save code could be shared with Icefall itself, but there’s all the UI!).

2. If I ever change the “item types” format, all the data I’ve previously created is now in jeopardy. (What I typically do is modify the ‘save’ code only, run the editor and  load each asset (old-code), and re-save it (new-code), then when that’s done I can modify the ‘load’ code.

Depending on the type of data asset, using Asset Text Files may be superior. I DON’T mean your game should store all of it’s data assets in plain text (yuck!). Here’s what I mean:

Whip up a simple plaintext ‘syntax’ that stores all of the information you want to include in your data asset. Then,  instead of creating an “Editor” with bulky UI code, create a command line utility that can parse your plaintext files and spit out your compiled data asset files. If you borrow your main game code for load/save, all you have to write is the text parser, and that can be as easy as you like: you’re dictating the syntax it has to interpret.

The BEST part of this system is that it makes changing the format of the assets later on very very easy. Oops, I forgot a field for my item types? No worries. Add the extra field to your text file sources (bringing to bear the full power of your fantastic Programmer Text Editor / IDE you’re using – the programmers’ Photoshop), a quick change to the asset compiler to recognise the new format, and hit execute.

You get other benefits too: you can put ‘logic’ into your compiler without having to put it in you main game. (e.g. scale the values, dictate whatever “optional” or “Default” fields, anything!

It doesn’t work for everything (e.g. Icefall’s “Level Map” is huge and an Editor really is the right option for that) – but when it’s appropriate, I have found it works brilliantly.

3 comments so far

Add Your Comment
  1. Hi Lawry, the game is looking like its shaping up nicely.
    Have you considered XML for your format? It can be edited in a plain text format, is flexible, and most importantly its hierarchical. Also all the parsing code is done for you 🙂

  2. Yeah, I did consider XML. But XML has quite a large overhead when you’re creating it, and relatively strict syntax requirements… if I was going to use an in-game editor to create the ‘source’ assets then that would have probably been the way to go. As I am just whipping them up manually I can get away with less work. Also lots of the sources refer to ID’s defined in other sources (and in one of the game source files itself to refer to “built in” elements) which meant I needed a non-XML parsing component anyway.

  3. Cool can’t wait to see a tech demo (how about one for Christmas!)