Game dev post #3 – 10 useful game development hints

I’ve been so busy these days working on my free, promotional game (see previous post). I’m happy to announce that it has been finished! Yay! Not only that, I’ve spent additional week on upgrading in to universal app and added “Retina” display graphics. That’s right now no matter if you have an iPod, iPad or iPhone 4 – game will look just gorgeous with hi-res graphics.

Overall the whole game took me around 600 hours of pure development time.

I’m in the position to go back to the main project now and I must say that during development time of my free game I’ve written lots of code that will be reused. Things like: in-app purchases integration, “Open Feint”/”Game Center” support for achievements/leader boards, game settings handler, frontend, sounds & music manager and more – this will be all used in my “bigger” game. So I’m thinking that loosing those 3 months to develop this free product could actually be calculated as 1.5, since all of the above functionality took about month and a half to complete and will be reused. Also lessons learned from creating a universal app/adding “Retina” display support will come handy as well.

There are some thoughts that I would like to share, which I’ve encountered during development of my free game. Here are 10 useful game development hints:

  1. Since game is using Cocos2d for iPhone engine (, I’ve come across few issues that I’ve spent hours on debugging that turned out to be engine bugs. Upgrading it to a newer version fixed my problems. Conclusion: always check full release logs/community forums BEFORE digging into code and getting your hands “dirty”.
  2. Before you write a single line of code and try to “reinvent the wheel”, do a Google search for a similar problem you’re having. Chances are that someone has already written the code that you need – be sure to check the license though; you don’t want to infringe copyrights.
  3. Always mark temporary test code with “FIXME:” or “TODO:” so later it’s easy to do search and remove them when they are no longer needed – even better/safer option – test code which makes significant changes to the way the game behaves should be put inside “#ifdef DEBUG #endif” block. I’ve had some issues with achievements reporting code – it turned out that for testing purposes I’ve added a line of code which was clearing all saved achievements data every time I restarted the game (notification bar test).
  4.  Frontend manual elements positioning – it’s a NIGHTMARE! I need to think about some kind of editor to speed up this process. It takes absolutely ages to manually code position, compile, run. Totally inefficient way of doing things – same goes for in game elements.
  5. If you don’t have audio guy in your team, picking sound effects and music could take up to 2-3 days. After that you have to format sound/music so they’re right quality/loudness and size (I recommend Adobe Audition). In total about 3-4 days of work for this game. On the plus side it’s a great cost saver, on the minus side: time, sound/music are not unique to your game. Total cost of music/sound effects for my free game: around $250. Sources:,,
  6. Make backup copies of your project on external drives – EVERY DAY! This is important – make on as many drives as you have + use free cloud drive like the one from Amazon ( You don’t want to lose even smallest amount of your work – believe me.
  7. Be aware of the platform limitations that you’re creating software for. I was very careful and aware of iPhone 3GS and iPod 3rd gen memory and CPU limitations, but when I’ve started upgrading my game to universal app I went a bit “wild” on the memory side of things. I thought – “Ok, iPad – 2x resolution graphics and same sound effects as on iPhone 3GS should load just fine…whaaa…!? What’s a memory warning level 2? Nooooo! Crash! <Rage!>” So it turns out that iPad has less RAM than iPod touch 4th gen with “Retina” display, since I had no memory warnings there – loading exactly the same assets. Seeing this made me a bit worried about my flagship game that I’ve just returned to – it has far more data to load…
  8. Always “nil” a pointer after releasing an object and always check pointers before doing operations on it. I know that in Objective-C you could do something mighty crazy as sending “release” message to nil objects and it’ll work fine but it’s not an excuse. If something is still in memory and it shouldn’t be – check retain count by using: “[obj retainCount]”. Use XCode’s performance tools to check performance and look for any memory leaks.
  9. Never leave your computer on and unattended when your 2 year old kid is sleeping in the next bedroom. He woke up, went to my office and… my code just didn’t compile anymore – thank God for “Undo”.
  10. Play your game to death! Honestly every game has got bugs, no matter how hard you’ve tried to make it bug free – we’re only humans and humans do make mistakes. So test it, and iron out any bugs you find. Always give someone else to play your game, a person who is not a developer – they’ll definitely find more bugs than you. Developers always tend to play their game “safe” because they know how exactly it works under the “hood”. My wife – Julia, she found 5 bugs within first 10 minutes of play.


Leave a Reply

You must be logged in to post a comment.