Happy Holidays

Sorry, no posts for a while! I’m on holiday for Christmas, although I will be spending some time working on finishing up Icefall, I probably won’t be posting that much.
See you in the new year!


This is the second entry in my set of “10 Game Development Golden Rules”. Hopefully, this one is less contentious than the first!

The rule is:

Provide gamma and volume controls, and separate music from sound.

Pretty simple. But essential! The good news is, the AAA titles pretty much universally support this now. And it’s a good thing, as I use these settings all the time.

I have an Xbox 360 but, unlike most Xbox 360s, mine isn’t connected to a TV – it plugs into a second DVI port on one of my 22” widescreen PC monitors. This is awesome because I can run it at 1680×1050 and games look beautiful! (handy bonus: I can web-surf on my other screen while waiting for Matchmaking in Halo 3)

BUT my monitor has a very different colour profile than your average TV, and games with a lot of contrasting light/dark elements can look really bad by default. Gamma controls in your game are pretty essential for me to see the graphics the way the designer intended. I’m sure there are other people in similar situations or even wildly different situations who also need gamma settings. Your game needs to support them too!! And since there’s nothing on the “con” side of the ledger that could make it a bad idea, you have no excuse!

Providing separate controls for sound/music: Music is awesome but people like to be able to hear the game sounds sometimes! Particularly in a ‘competitive’ environment, or simply when your game is providing an audio narrative (GTA4 is an excellent example – the “in-car radio” music is huge and contributes to the GTA atmosphere, but you need to turn the music volume down to be able to hear what mission you’re being given via the cellphone). If I’m playing an FPS single-player, I might turn the music up, but in multiplayer I want to use every audio cue the game gives me for competitive advantage, so I need to kill the music or at least turn it down.

Just like with the gamma controls, the good news is this is pretty universal now. But there are still Flash games that don’t separate them (and, even worse: there are plenty that have no Volume settings at all – sound is either On or Off). Sound might *add* to the game experience, but I’d like to set it so that it doesn’t completely drown out my background music, thanks! Vista and Windows 7 allow you to set the volume controls at the “application” level, which solves the problem for me specifically, but it doesn’t help anyone using XP (or anyone who doesn’t know about that feature). Support them too!


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.


One of the hardest bits about creating Icefall was getting the User Interface (UI) just right.
Icefall’s chief inspirations are “old-school” role-playing games like Angband (aka Roguelikes: Nethack, Moria, Omega, ADOM all fall into this category). But these old-school games all rely on essentially a text-mode interface with a myriad of hotkeys. I want to make Icefall more accessible than that. So I took the UI elements from ‘modern’ RPGs like World of Warcraft, Titan Quest, and Dragon Age: Orgins: hotbars, cooldowns, drag & drop.

Of course these ‘modern’ interfaces are much more work to get right than a classic keyboard-driven one. Even though I’ve spent more time on this aspect than any other, it’s still not perfect. Here’s an example I found yesterday:

Icefall Backpack user interface

Icefall Backpack user interface

Looks easy enough. To equip the Apprentice Jerkin, players can either click and drag it to their Character Sheet, or else right-click it to equip. The problem: there are two, identical jerkins in the player’s inventory. Click and drag works fine, but if you right-click the second one, a strange thing happens: the *other* jerkin is equipped instead, and disappears from inventory.

Why? Well, right clicking an item in Icefall triggers a codepath to essentially “Activate Item: Apprentice Jerkin”. It’s set up this way so that players can also drag equipment to their hotbar, and equip it directly from there. All good so far. BUT: internally, the inventory is stored as an array, and is stored from left-to-right, top-to-bottom. So when the “Activate Item” codepath is triggered, it goes looking for an Apprentice Jerkin to activate, and it finds the other jerkin (the one in the row above) first – so it activates it!

A rare situation, a completely logical consequence of the way I implemented right-click behaviour. Technically correct (There are no downfalls to the player if the ‘wrong’ jerkin is equipped: they’re identical by definition) and yet it feels completely wrong and would likely alienate a casual user. So I’m going to have to find a workaround 🙁