Sponsored By

Opinion: Game Pre-Mortem

In this reprinted <a href="http://altdevblogaday.com/">#altdevblogaday</a> opinion piece, Nlogn Information's Charilaos Kalogirou discusses the value of game pre-mortems, and shares lessons he learned from developing his indie iOS title.

January 5, 2012

6 Min Read

Author: by Charilaos Kalogirou

[In this reprinted #altdevblogaday opinion piece, Nlogn Information's Charilaos Kalogirou discusses the value of game pre-mortems, and shares lessons he learned from developing his indie iOS title.] Happy new year everybody! It seems we made it to 2012 successfully! Lets hope this will be a prosperous year for everybody, with many new things to learn and accomplish. With my game entering the final phase of development, I think its time for a pre-mortem. We all often get to read postmortems, but we seldom see the state of the developer when heading for the release. There is lot that can be discussed there, before the after-release discussions kicks in to overshadow everything. So here I would like to share some random "wisdom" I gained walking this path. First of all, let me provide some background. I started coding our game engine in August 2010. This was not starting from scratch, as I started by modifying my old game engine Sylphis3D (you can poke around the source here: http://devnet.sylphis3d.com). This was all done in my spare time, with the only goal being to see if it would be possible to run in on iPhone. It took a little while to succeed, an endeavor that required lots of code chopping. You see, Sylphis3D is a fairly heavy engine for iPhone with its stencil shadows, per-pixel-lighting, normal mapping, etc. It was around January 2011 when the engine was pretty much ticking with a new low-end renderer, when I got the idea of creating a simple 2D game with it. The game project was started and canceled a few months later because of problems with the graphics artist's "productivity". It was clearly my mistake of overlooking several indications of problems coming along. Which is my first lesson learned thought out this project. Never overlook problems and expect them to solve themselves automatically. It is not going to happen. It took a lot of time, but it was not all to waste, since the work on the game engine was there to stay. And this involved huge rewrites that would anyway take lots of time. The changes included the migration to a different scripting language, the integration of two 2D physics engines (ended up with Box2D), new renderer, and lots of other minor things. As you understand there is little left that still relates to the original Sylphis3D game engine I wrote years ago. Later came the idea of a different game that started from a single gameplay element I thought of and that we later brainstormed along with my sister to a full themed game. This game was supposed to be done in 2-3 months, and here we are a few days in 2012 and the release will happen later this month… so classic. It turns out you can't really estimate the human factor in months. Crippling bugs will happen, artists will not deliver on time, the (awesome) music composer and sound effects engineer might get caught in an album release, and so on. To all that, add the fact that I always seem to forget the time cost of communication in all these. Through all that, we finally managed to be able to make a pre-Christmas release, but at the last moment, I pushed the big red cancel button. I thought that it might be better to release the game after Christmas despite the huge sales spike the App Store sees. It occurred to me that with all the big names dropping prices, it would be pointless for a poor, self-funded, indie game, to even consider a chance. I hope it was a wise decision. It certainly gives us more time to do tunings to the game progression with more beta testers logging many more hours of gameplay. Below are the commandments to self for building an iPhone engine and game; feel free to embrace any of them:

  • Go Lua. The iPhone can't really handle a heavy scripting language like Python for example.

  • Even with Lua you should:

    • use incremental garbage collection, or even better a near-realtime gc.

    • disable the use of undeclared globals or suffer pain debugging typos.

    • create an object graph walker that will walk all globals, locals, upvalues, parameters, in order to be able to understand how your game is using memory and find leaks.

    • create a custom memory allocator that can also gather statistics of where your memory is allocated. Lua makes tones of small allocations and memory fragmentation will hurt you bad.

    • create a remote debugger for script code.

    • always precompile the lua scripts in the release build, his will pose far less stress to the memory allocator.

  • Always have in-place a logging facility to be able to replay game sessions.

  • Don't rely on the XCode build system to build/install/debug your game. Create scripts that deploy the game to the iPhone simulator (with rsync for example) and bring the turnaround time to 1-2 seconds when only script code is changed.

  • Build a solid asset pipeline. It should be possible to build the whole assets directory from the raw source files with a single command.

  • Use testflightapp.com. This will make the beta distribution as smooth as it gets, coupled with console and event logging send to you for every single session played.

  • Create a logging facility for key gameplay events (for example how much time does it take the player to clear the first level?). This should log to a remote server so you can collect data from your beta testers, and statistically analyse it later to extract useful information.

  • Always test the game at the lowest hardware you support.

  • Always try to watch new players play your game as you must keep in touch with the newbie perspective of your game. If you implement achievements for example at the end of your gamedev cycle you might find out that you create them to be a bit hard to achieve for a new player.

  • Premature optimization is the root of all evil, but you better assign a day a week or so for checking your "optimization corruption" and fixing it. Even if you don't "fix" it, it will at least provide you with a more clear insight of how things are going which is a very good thing to have at the back of your head when coding.

  • And last but not least, don't go out making a game without having read all the #altdevblogaday posts!

I hope you will find the above canned experience useful for your development. I tried to provide them in almost single sentences for the purpose of forcing myself to extract the essence of my thoughts. I would really like to hear your single-sentence kind of wisdom. (If you would like to stay in touch with the upcoming release of the game, you can subscribe to this Facebook page: http://www.facebook.com/MrPopCorny. There's not a lot in there yet, but I will start providing more info soon.) [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like