The observant amongst you may have noticed a new logo appear on this blog, labelled Peggit. Peggit is my first attempt at a smartphone game and at the time of writing is available on both the iPhone and Windows Phone 7 platforms. I’ll not discuss the game itself here – you can check out http://www.peggit.co.uk for that, but instead talk about the technologies behind Peggit and just to make a point that even the simplest of games require an incredible amount of complexity behind the scenes.

My intention with Peggit was to create a cross-platform experience allowing players to compete with friends no matter what type of smartphone they use. Firstly, and most obviously, both iPhone and Windows Phone development use different languages, SDKs, and development environment, namely Objective-C and Xcode for the iPhone, and C# and Visual Studio for Windows Phones. This poses a cross-platform problem – how do you share scores? iPhones use the “Apple Game Center” to store and share game-based achievements, while Windows Phones use Xbox Live.

These obviously don’t and won’t talk to each other so I’m left with one option – create and host my own score server. After a bit of investigation I settled on a protocol known as REST (Representational State Transfer). Using a reasonably standard web server configuration of LAMP (proudly hosted by Vidahost!), I set about implementing a PHP based REST API. REST works by accepting input via a regular HTTP request, or a URL if you like. The URL is interpreted by the REST server and translated in to a PHP method call along with any applicable parameters. For example /getScores/1/50 could be interpreted as “execute the PHP method getScores(gameId=1,numberOfScores=50)” in pseudocode. For a bit more elegance, parameters can be embedded in an HTTP POST request.

Now, this is obviously a very easy way to send data to the server, but you need to be able to get a response from the API, or functions such as getScores are useless! There are two primary methods for returning data using REST: XML and JSON. XML probably doesn’t need explaining – a schema is agreed between server and requestor beforehand and the returned data is encapsulated accordingly. I chose JSON instead though for one main reason: Peggit is a smartphone game which means it will most likely be used by people who are out and about. Data costs on mobiles can be expensive and the speed of those data connections can be slow. JSON, unlike XML, is very lightweight using a fraction of the character overhead that an equivalent XML response would contain. JSON allows me to push the minimum possible data to the app in the minimum amount of time meaning that not only is the transfer more likely to happen, it is also less likely to upset those with mobile data caps. Windows Phone supports Web Services and JSON out of the box using a simple asynchronous WebClient call combined with the System.Runtime.Serialization.Json library. Xcode for the iPhone sadly needed a little more assistance and I had to use the 3rd-party ASHTTPRequest libraries for asynchronous web service calls, and the 3rd-party SBJson library to interpret the results. Apple’s products may “just work” for end users, but they don’t make things easy for developers.

Up on the server, the REST API is paired with a MySQL database, hosting all scores. PHP takes care of the intelligence, ensuring integrity of the data and making sure that only the 10 best scores per player per game are kept. Players are uniquely identified by an anonymously generated string, passed to the API from the phone. This way, no personal data is ever stored (unless you count the display name), and just to ensure that privacy is adhered to, all traffic transferred between the server and the smartphone is encrypted using SSL.

Back on the phone, a simple web service call is made to the REST API on the web server as required – responses are processed using a JSON parser and stored as objects in memory for only as long as needed (usually just to display on the screen). The one exception to this is the storing of the user’s top ten scores per game. As I discovered whilst creating my last app, Watercolour Reference, the easiest way to create a local database on each smartphone is to use SQLite.

Although not explicitly supported on Windows Phones as they use a portable Microsoft-based database as standard, a third party library (Csharp-SQLite) can be utilised meaning that a single SQLite database can be used on iPhones, Windows Phones, and Androids, and the same SQL queries can be copied and pasted between apps saving hours of development time. The top 10 scores are stored in such a local database, and when the app is executed for the first time it will look online to see if scores for this user are available. If they are, it downloads them and populates the local database. Each time a new score is added to the local database, the app will also upload it to the server.

And that’s all there is to it from a technology perspective! A total of 7 different languages were used to create the finished product (C#, Obj-C, Java, Javascript, PHP, SQL, HTML), and yes, I’m counting the creation of the upcoming Android version and the development of the web site in there too.