I AM PLAYR Mobile, the mobile instalment of the popular web game of the same name. Based on (but not a carbon copy) of the web game, I have been developing a companion app (available for iOS and Android) to complement the already well-established web game.

The game itself consists of 12 training drills, where players compete against friends, furiously outscoring each other by flicking a ball at various targets. The mechanics change dependant on which drill you choose. Some require fast reflexes, others astute timing, but all in all it’s a lot of fun.

For all your developers out there, a few morsels technical details. The game itself is was pretty straight forward to develop, with a few nice additions. I added back-end support (with help from Bill Robinson on the server side code) which means that data can be pulled and pushed between the web and mobile game. This was a vital piece of functionality (both technically and design wise) as we wanted players to be able to play the mobile game, whilst also be rewarded in the web game and visa-versa. Therefore, driving players to both games; a double pronged attack! Furthermore, been able to host our localisation and settings files (i.e. replacing text, changing thresholds and settings) on our own servers, enabling us to alter the game remotely, without having to recommit the app each time we wanted to make small changes (especially in response to analytics).

The game’s initial brief consisted of a graphics heavy landing map (the main menu of the game). The map itself couldn’t have been more enjoyable to implement. Thanks to the great graphics skills of George Allan, we had a beautiful set of assets. Additionally, it provided me the chance to indulge with my love of computer graphics, and heavily optimise the scene, in order for it to run smoothly on lower end devices, such as the iPhone 3GS and iPad 1. This was quite a tough task when you’re handling roughly 40k – 50k triangles, and around 35 – 40 draw calls. Obviously, the major bottleneck with mobile tends to be the fill rate, which was combatted throughout. Using texture atlases, static and dynamic batching and LOD really helped bring the frame rate to a smooth 60 frames per second. We added a nice camera sweep, which shows off all the assets, and really completes the scene. I couldn’t be more happy with how it turned out.

A major part of this project, for me personally, was steering the technical direction, software architecture and code design of the project. Even though I have always been an advocate of good software design, providing other people with direction was a new experience to me; and one which I have throughly enjoyed. Continuously scoping the project and guiding it toward a goal, really makes any project you’re working on, a labour of love. Working with fellow Unity Developer Carlos Revelo to produce the game, was also great fun. Closely discussing ideas with the Senior Games Designer Dan Mayers, outlining briefs and getting to work with the implementation, is a process which I never get bored of. I guess it the analogy would be an engineer pouring himself into designing a bridge, building it and finally seeing it come to fruition. Except, at least for me, building games is a lot more fun than building bridges.

Hopefully (will have to clear it with the company first) I’ll be doing some in-depth technical posts, about anything technically interesting, tips and any problems I encountered and how I solved them. And as always, if you see something I could have done better, comment and let me know (I never stop learning, let’s be honest, it would be pretty boring if you knew everything).