This is the final mock-up I did of the Mos Speedrun stage select screen. It's surprisingly close to the final version that ended up in the game. From quite early on we wanted to make the game as accessible as possible, and we took this to the extreme here by having a single screen that the game loads up to being the way to access all the stages, levels and options. I mocked up the screen in Photoshop and then drew the annotations in a separate layer using a tablet - this was a lot better for programmer and artist than trying to explain what was going on in a separate text file.

The logo was meant to be temporary but I grew to like it, so it ended up being close to the one that ended up in the game (after some tidying up of course). Another change we made was to lose the big star that was awarded for completing every badge in a level - I can't remember why we didn't end up using that though. I think one of the latest ideas we had was to make the background spin which I think gives this screen a really nice look. The colours in the background change for every levels that is selected, and the colour choice is algorithmic. We use the golden ratio (~1.618) multiplied by the level number, multiplied by 360 to select the hue. This spreads the possible colour choice out as much as possible and avoids any repetition in colours.

I Took a few minutes of Tony's (Programmer of Mos Speedrun) time to give him a bit of a grilling about making our latest iPhone game, Mos Speedrun, here it is!

Q: What tech do you use for development? What software do you rely on?

A: I normally do the bulk of development on my PC, it's pretty fast with loads of memory and (most importantly) super-fast hard drives for quick compiling. I've also got an old-style Mac Mini for the iPhone/iPad development - I share my keyboard and mouse with both machines using cool free software called Synergy.

On the PC I use Visual Studio for nearly everything, on the Mac I use xCode. My most important and most used tools are WinMerge (use for merging lots of horrible code changes), SVN and Dropbox (for sharing files with Nick).

Q: How have you found the whole submission/app store experience?

A: It was pretty awful in the beginning as there's so many things you can get rejected for but after submitting a few titles it definitely gets easier - you get used to the long wait too! The App Store rating system still needs a lot of work though, you can have 5 star apps languishing at the bottom of the charts while 1 star apps are in the top ten :(

Q: The main tool you made is the level editor. Can you say a bit about it? How did it change over time?

A: The editor began as a very basic tool to place blocks in a map and have Mos navigating it with collision. As time went on we added different layers for background graphics and enemies/pickups and an additional interface for controlling game platforms. One of the key ideas was to be able to switch between the editor and the game quickly to test level design - currently we can start playing at any point in the level just by tapping a single key which makes designing levels a lot easier!

I also added various options to make Nick's life easier (like randomising background blocks) and cutting and pasting of block sections. As the game progressed we also added the ability to create web levels and set the speedrun times. The editor currently only works on the PC and the screen area is 4 times larger than the game itself - this makes it a lot easier to see more of the level and how it all fits together. The game maps can be huge but they're all compressed so usually only end up being about 40k each.

Q: Where there any interesting coding tricks you had to use?

A: Most of the coding tricks were really just optimisation to make sure the game runs in 60fps. The whole project is C++ (even on xCode) so that helps with cpu time - there's no garbage collection going on in the background either. All objects are rendered and sorted by texture too so their isn't too much load on the GPU. The wind graphics use a special 'stateless' system so we don't have to keep track of each individual particle. Unfortunately all the objects on the map have to be updated at all times as we wanted the games timing to be perfect. For example, a zombie will always be in the same position if you reach it in the same time. If we didn't use that system then you wouldn't be able to get perfect speedruns as the enemies would only start moving when you were near to them.

One issue we had was that the iPad (V1) couldn't render a fullscreen 'tv' vignette without slowing the frame rate down so we had to ditch that and just have a tv-style border instead. The iPad 2 has a much more powerful gpu and can handle it no probs!

Q: Anything you would have done differently if you had to start from scratch?

A: One of the biggest problems was that the game started off as a simple prototype and grew pretty rapidly. This meant that a lot of the code ended up in a few files rather than being split up properly into different classes and managers. About halfway through the project I tidied it up and split it into more manageable classes but it would still have been better to do it from day one - I guess that would have meant designing everything first though :)

I would also have included 'Lite' support from the start too as that was something that had to be shoehorned in afterwards.

If we had thought about PC and Mac versions at the start as well it would have been useful to design keyboard controls for the frontend.

 Another chat with Tone about the game tonight, some of the things we discussed were the graphics style, game mechanics, mini games and distribution.

 Hello folks, this blog is going to chronicle the creation of our new iPhone game, from start to finish. We intend to post frequent updates about our thoughts, development, behind the scenes stuff, things that haven't worked and screenshots. Hopefully it will be an interesting journey. Please sign up, follow us and post comments, questions or anything else!

Nick