Indie game developer. Runs a software company in Greece. Author of the open source game engine Sylphis3D (http://devnet.sylphis3d.com/). Creator of the iOS game "Pop Corny". Blogs at http://kalogirou.net/
Posts by Charilaos Kalogirou
  1. Porting your iOS game to Blackberry Playbook (and future BB10 phones) ( Counting comments... )
  2. Porting your game from iOS to Android ( Counting comments... )
  3. Writing portable code: A process full of gain ( Counting comments... )
  4. Launching on the AppStore in the year 2012 ( Counting comments... )
  5. My game design hat ( Counting comments... )
  6. Game Pre-Mortem ( Counting comments... )
  7. Debugging hard to reproduce bugs ( Counting comments... )
  8. Optimizing for the instruction cache ( Counting comments... )
  9. Take your time (off) ( Counting comments... )
  10. Predictable garbage collection with Lua ( Counting comments... )
  11. Keep your mallocs close, and your related mallocs closer ( Counting comments... )
  12. From Python to Lua ( Counting comments... )
Technology/ Code /

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 post-mortems 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 going by coding the 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 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 AppStore 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 relay 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.

(edit: The game is now released and you can get it here)