Programmer Interrogation

I Took a few minutes of Tony's (Programmer of Mos Speedrun) time to give him a bit of a grilling about making 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.