1. Do you always submit the user’s score to an online server?
2. How do you submit the score so that no one can snoop the traffic and spoof fake top scores?
3. What kind of resources are required to handle score submission and top score retrieval?

For point 1, so far I’m asking the user for a username and email address, and only submitting the score if the email is filled in. For point 2, I have something in mind using a hash function, but haven’t fully decided yet. Point 3 is the interesting one. I read a recent interview on Mobile Orchard with an iphone game developer, and he said that he was relieved to have chosen to implement his top score engine using Google App Engine. Once a few thousand people are using your game, the load on a scoring server can be quite high.

Google App Engine is a confusingly named google service, mainly because google also have ‘Google Apps‘ which is not the same as ‘Google App Engine’. ‘Google Apps’ is the name for the bundling of Gmail, google docs, google calendar, google sites etc. Google App Engine (AppEngine) is a virtualised service cloud thing, a bit like Amazon EC2,  except it uses google’s servers obviously, and perhaps the dealbraker for a lot of people; your app needs to be written in Python. I guess its a bit like if your web hosting provider only let you write cgi scripts in python … well sort of.

The really good stuff about AppEngine is that you can use it for free initially, though there are billing options if you use a lot of traffic or CPU time, and it seems quite fast. So I started looking into it as a platform for a topscores engine. I’d already hacked together some code for doing topscore submission and checking using PHP on a backend server of my own. So how to convert that into Python?

Well for starters I needed to learn Python. Yes, I am a sysadmin and I haven’t looked into Python at all in the past few years. Yes I too read that it was meant to be great So I had a look at the Oreilly Learning Python book. That got me started. The key observations about python;

• looks very object oriented
• indentation is important (this is about the only thing I knew already)
• There is good doco on docs.python.org
• Python noddies probably don’t like perl

For the AppEngine you download a small SDK that includes a demo web server that you can run on your own computer to test things out. There’s also a script to upload your app directory to google. Essentially you have a python script or two along with some static html/images or whatever you need for your app in a directory and just run the appcfg.py update process to update your app on google servers. I really like how a sort of version control is incorporated into this so that if you bump the version number up on your local copy, it won’t become the ‘production’ version of your app. There’s a dashboard control for specifying which version is the production one.

To get an app uploaded you first need to get an account with AppEngine. For starting off, you just use your gmail account (if you have one) and sign in. There’s a confirmation step that involves sending you an SMS with a magic number in it. I guess this is stop the AppEngine being abused and to also allow google to invite you round for dinner if they like your Python program. Google keeps track of the phone numbers used for these SMS’s and suffice to say you can only use a phone number once to receive an SMS.

You also can only create 10 applications. I imagine that might change in the future. You have to pick a unique name that no one else has picked. Your app becomes googlebugle.appspot.com or whatever. You upload your python code and other related files and it just works.  If you don’t want to use the appspot.com domain you need to sign up for google apps using your own domain name and then use your google apps admin account to sign up for the Google App Engine. Then it is reasonably flexible how you redirect subdomains to your app.

So within two days I’ve learnt a bit of python and set up a rudimentary top score engine on Google App Engine. I’m quite impressed. Note, that they have added in billable options recently and I’m not sure if the ‘free usage’ thresholds have dropped.

It’s actually encouraged me to look at Python more closely (a bit like how buying a Mac has enocuraged me to learn Objective C). All good so far.

With my first app, I had one adhoc tester with an iphone. Amazingly this first attempt at making an adhoc app worked first go. You have to create an adhoc provisioning profile and then compile your app against that profile and check a few things. Apple have that part reasonably well explained.

My problems started with this new game I’m working on. The graphics guy working on  it had an ipod touch and a PC (ie. no Mac) and I wanted to get some of the builds I was doing so he could check his graphics out and the general playability of the game. So I found out the unique id of his ipod touch, added it to my adhoc provisioning profile and built the app against this, and sent it to him.

He said the app sync’ed fine from itunes and the icon appeared on his ipod touch, but it kept saying “the blah application cannot be opened’ when he tapped it to run it on his device. From that point I tried a whole heap of different things. iphone developers probably get used to this after a while; restart Xcode, try a clean all a few times, double check the Info pages on the project and target settings to make sure the right provisioning profile is selected. I even created a new provisioning profile with just this guy in it. But no go.

Eventually I found out that the ipod touch had been jailbroken. Ahah!!! Of course if you google for ‘jailbreak cannot open application’ you get a zillion results. I could not be bothered trying to work them out, so he just restored the ipod touch’s OS and the app installed first go.

The other common hoop I hit with ad-hoc testing is to make sure the testers delete the app from their device and in itunes before adding a new version. I kind of know why this is required. Its not required all the time, but it certainly makes testing easier if the beta testers get used to doing it.

But as luck would have it, I recently met another iphone developer here in NZ. He had some good ideas … but not a lot of time. I don’t have a lot of Unix work on at the moment, so seemingly have plenty of time. So at the moment I’m working on a game with him, based on his idea.

There’s definately a big learning curve at the moment. Firstly, I’ve never written a complex game before (I have started some back in the Amiga era), and there’s logically a fair bit more code involved than my simple ‘get something on the app store’ app. Per usual, all the retain/release stuff is a challenge. I typically write some code that kind of works, then go back later to try and sort out the retain/release mess I’ve created. I end up adding a lot of debug code. A good hint is to override the retain and release methods in your own classes. For example;

- (id) retain
{

    NSLog(@"RETAIN MyClass %p rc before:%d", self, [ self retainCount]);

    return [ super retain ];

}

- (void) release

{

    NSLog(@"RELEASE MyClass %p rc before:%d", self, [self retainCount ]);

    [ super release ];

}

I also put some NSLog’s in my dealloc’s like so. Whatever you do, DON’T put the [super dealloc] before the NSLog as I originally did and scratched my head for ages wondering why my dealloc always crashed. Doh!

- (void)dealloc {
    NSLog(@"DEALLOC MyClass %p", self);

    [someVar release ];

    [super dealloc];

}

So there’s some challenges ahead … but it’s all looking good so far.

It’ll be interesting to see where the App Store phenomenon goes.There’s now over 10000 apps on the store … and so you end up with a lot of similar apps … and also it makes it more difficult to find the app you want. There’s also a natural tendency for apps to end up at 99cents or free now. We shall see.  At the moment, it’s got me interested in programming again … and that’s good.