The last few weeks have been spent putting the finishing touches to RocketFuse ready for submission to Apple for review. We finished on Monday night and are now waiting very impatiently for Apple to finish the review process so that we can unleash our combination of physics, rockets, fuses and caves onto iPhones and iPods worldwide. After all, those rockets won't escape from those caves on their own! The final stage of the game development process is my favourite and simultaneously most dreaded stage. Want to know why?

The last few weeks (or up to 6 months for a large AAA console title) is where everything starts to come together and actually resembles a game. The rest of the time, you are developing and playing something that is either broken, or has such giant holes missing in its functionality that it is hard to see beyond the huge list of jobs that need doing before you can even imagine handing it over to paying members of the public. It is hugely satisfying to see something turn from basically a gameplay demo into a fully fledged game with content, progression, a proper user interface audio, etc.

BUT: this stage of the project is also where you realise that there is still a huge list of jobs to do, and now they are urgent! You discover tasks that you hadn't even thought of before now need immediate attention. You put in the game in the hands of people who have never played it before, and straight away they find defects or issues that need to be resolved. You find there's performance issues on certain devices or configurations, and optimisation is needed. You suddenly decide to change some key part of the game; you only just thought of it but it's the BEST idea ever and there's no way you could possibly ship the game without this feature now that you've thought of it!

Here's a couple of examples of this for RocketFuse:
- Some players would have a go on one level, and see their final time and thruster scores during the level end sequence, but would then try to immediately improve on them by restarting the level. They assumed their results were saved. In fact, by resetting the level, they were throwing away their score, as we were only saving the results on the return to the menu screens, either when the level end sequence completed, or when the user skipped it by hitting the menu button. The solution was to also save the results if the player restarted the level while the level end sequence was in progress.
- One player experienced an interruption to his game due to a notification message from the operating system, and this caused the game to stall for a few seconds. When he dismissed the message, and the game received focus again, the physics was in a bad state and caused the rocket to pop through the wall and end up spinning around at high speed outside the bounds of the level. To solve it, we needed to tap into a callback that the app receives when it is about to lose focus, and use that to properly trigger the pause mode in the game. We had to deal with the cases where the player was doing something such as placing a thruster and drawing its fuse, and ensuring it was correctly completed (by simulating the touch release event, which we miss if the app loses focus). When we first implemented this, it would either completely break the thruster and fuse that were being placed, or at the level end it would crash when it tried to clear everything up.

So picture this: we are about an hour away from the deadline we had set for ourselves to submit the app for review. The game is crashing for the first time in ages, and it's possible to have a thruster that doesn't attach properly with a fuse that somehow attaches to the rocket if the game gets interrupted at just the right moment. We are staring at the code, coming up with solutions, considering them and then throwing them away. We are deep in concentration, and seem to have a heightened sense of alertness and a better ability to consider a large number of issues simultaneously. We fire questions and suggestions back and forth, until we finally settle on a solution that we think will work. We pore over the code, typing extra fast and bizarrely making fewer typos than usual. We hit build and then test it on one of the devices, but it still crashes! We turn back to the code and notice that in our haste we are not infallible, and we made a small error.... we correct it and test again. This time it works as we intended. We spend a while trying to break it in unexpected ways, but it stands robust. There is jubilation that we may have just prevented the frustration of just a few of the people we hope will buy RocketFuse, even though it was hugely risky to undertake right before the deadline.

That is the part that I most dread - making last minute wholesale changes that seem to break everything. But it's also what makes game development so damn exciting and addictive.