Friday, May 27, 2011

The Train Game - updated and on the iPhone

Following on from the entry written about the iPhone game developed to determine if it is possible to develop a game more quickly now than it was, in say, 1983; I decided to rework The Train Game. It was originally released by Microsphere for the 16K ZX Spectrum in, surprisingly enough, 1983. I had given myself a month to develop it from scratch, utilising a few weeks previous to this to learn Objective C.

It was a game that was originally restricted by its interface, associating changeable points with keyboard letters, and I felt would work well with a purely touch interface. It was also not a graphical powerhouse, even at its time of release, which works well for me as I have no ability to create decent graphics at all.

There were a few must haves in the game; it had to allow the two original levels to be re-created using the implemented mapping method and it had to have a selectable graphical theme that allowed the game to look similar to an actual Centralised Train Control (CTC) screen.

After a lot of researching, the options available for the implementation were to use the native Apple libraries, Corona or Cocos2d. Corona would allow the game to be run on both Android and iOS, but costs $350 for an annual license to publish. I didn't choose this for a couple of reasons; the game was being written as a tile map game and Cocos2d had a much more mature implementation and worked directly with the tool Tiled (which was an excellent help), the game being written required pixel perfect tile matching and the Android phones use a different resolution to the iPhone which to be honest I just didn't think would work and, importantly, it costs $350 to allow publishing.

As an aside, Corona reminded me a bit of Dark Basic; it allows a lot of interesting things to be done with little code, but when it comes to writing the actual code structure around the game Dark Basic became a real pain. I preferred to work with a library sitting on top of Objective C as opposed to a scripting language that everything has to be performed in. I prefer to work with a tool that works with the native language as opposed to replicating all the functionality in its own.

The IDE utilised in Mac or iOS development is XCode; which does some things well and drops the ball on others; a lot of this comes down to personal preference though. One thing that really gets me though is the use of the Home and End keys on a Mac; why it does not take you to the start and end of a line (which has been done on Mainframes, Minis, PCs and every other machine on this planet) irritates me no end. You can update it on the preferences in XCode along with the modified instances, but as soon as you swap into a text editor or another application, you have to remember that they are different.

Cocos2d was an excellent choice as it turned out; a lot of time was initially spent on the forums to work out nuances in the library, but its core concepts are soundly implemented and most things just worked which is nothing short of a blessing and something that cannot be overstated.

The game itself came together over the development time; the code was re-factored many times in the early stages as I had not developed anything in OO for quite a few years; the tile sets were re-vamped a few times to ensure consistency in size and edge matching and to try and make them look at least half-decent. The sounds were worked in Audacity which I was so grateful to find a version for the Mac; the trickiest to get right was the point change (a metallic drag and clunk) which most people probably won't even notice but that was as it ought to be.

The graphics were eventually created in Gimp; I had tried different Mac packages like Seahorse but just could not get the hang of the handling the layers. The splash screen was handed out to an artist I found on oDesk (after the first contact disappeared) who did an excellent job with sketches of progress sent to allow the process to be tweaked. He also re-did the passenger graphic, which until then was just a graphic I had ripped off a forum somewhere.

The tool set used for the game comprised of the following:

Free Tools
XCode (has an excellent iPhone simulator built-in)
Tiled QT
Dropbox (used for storing the media and project backups)

Purchased Tools
Texture Packer (an excellent tool for creating tile sheets)
8GB iPod Touch

The most exasperating part of the project was getting the iPod synched up with the XCode IDE; the iTunes Connect portal was a real pain. I couldn't get the keys in the right place, the hardware recognised or any part of it to work. Given the amount of hits on google when trying to find out what was going wrong, I wasn't the only one.

The signing up for the developer license was an exercise that could have driven the Dalai Lama to violence. It is meant to take 48 hours, and the $120 was indeed taken within that time, but the actual process required creating an ABN, getting GST registered and many calls to Apple support. One needs to prove the GST registration and the ABR site is, to put it mildly, bloody awful. The support telephone number leads to a disconnected number. When I called their technical support, they then took my details and then transferred me through to a disconnected number. In the end, I just needed to take a screenshot from the website (which was much, much better than the ABR) and email it to them. I found this in a very discrete part of the portal FAQ section several section deep. They should have gone the whole way and put a 'Beware of the leopard' sign.

The way the package is created to send to Apple for review is not particularly well documented; but the process is built into XCode. Once again I was hit by missing keys and obscure error messages; seems I missed a tab in the iTunes Connect portal. The review process itself took a bit over a couple of weeks and was successful.

The game is now available on the Apple App Store and if you have managed to read through this diatribe then you should jump on and check out Train Controller.