The Ludum Dare Challenge – “Make a game, take it to market, sell a copy.”
On September 24th I saw that PoV, one of the organisers of Ludum Dare, had posted The October Challenge. When I read that, I I was already working to separate the game code for Very Angry Robots from Processing, because I was aiming for an Android port. The problem was that the original code was written with Processing, so I was able to make lots of assumptions about the environment which just wouldn’t be valid on Android. Seeing PoV’s challenge made me realise that I needed a little more clarity in my goals, and decided that setting a deadline of October 31 would be spot on for my own needs.
Milestones
Here are the milestones that I wrote out, along with their target dates.
Milestone | Target Date | Features |
1 | 3 October | There is no Processing-specific code in the Game or Screen packages. |
2 | 10 October | There is a clear separation between API and SPI code. The controller code is cleaned up and is invoked appropriately from the service provider code. |
3 | 17 October | The Android SPI and bootstrapper have been implemented, potentially with placeholders for some of the functionality. The game runs on top of the Android SPI. |
4 | 24 October | The Android SPI and bootstrapper have been fully implemented. All functionality has been implemented. |
5 | 31 October | All glitches have been ironed out. The game runs correctly on both my phone (Nexus One) and the Samsung Galaxy S. |
Where am I now?
There’s something about writing out goals and milestones that gives me a productivity boost. Today is 7th October, and I’m way ahead of schedule, as I achieved milestone 2 last Sunday, ie, a week ahead of schedule. I managed to rewrite the entire game in terms of an API whose services are provided by a Processing-specific wrapper. That wrapper is now part of an entirely separate project in Eclipse.
Having done that, I was free to concentrate on Android programming. I dug out some old test code that I’d written to throw sprites on the screen and filled a scaled 480 x 320 screen with 15 x 10 copies of a 32 x 32 sprite. This ran at around 26-27ms per frame, which is respectable, but I figured that I’d need to get a bit smarter at drawing to the screen otherwise I’d have to start cutting features, because that only equates to about 38 frames per second before I’d even started implementing any game update logic.
I’d previously read some articles comparing different methods of writing to the screen on Android, such as Chris Pruett’s Sprite Method Test code. I took a look at that and wanted more information on VBOs (Vertex Buffer Objects) and was looking around when I accidentally stumbled across some game engines written specifically for Android.
At one point, many years ago, I’d have passed this up in favour of writing my own engine. But while that’s good for learning about the ins and outs of game engines, it’s not good for getting a game finished. Given my goal of completing an Android port of Very Angry Robots by October 31st, I started looking at the engines to see what they were capable of and how easily it would be for me to make use of them and meet my deadline.
There were several engines, but I settled on a shortlist of Rokon, AndEngine and libgdx. I looked at what each engine provided. They all had their pros and cons. AndEngine in particular had a great Android demo (here) but ultimately I chose to go with libgdx. There are a number of reasons why I chose it, but philosophically it just “felt right”, particularly that the guy who had written it had already achieved what I was trying to do, even to the extent of having it possible to have the same game on Android and Windows, and was away ahead of me with it.
I converted my sprite test to use libgdx and was blown away by the difference. Not only did it run faster, at 60 frames per second, but it was able to handle at least twice that many sprites at the same rate. Now I knew that I had headroom to do whatever I wanted and even started to consider the possibilities of running the game on older, less capable phones like my wife’s LG GW620, which inexplicably still runs Android 1.5.
What’s next?
I am now working on Milestone 3, looking specifically at how I can use libdgx as a service provider for my API. Looking at it, I don’t see many difficulties ahead. I know there will be bumps in the road, but it is such a good fit to my needs that I am highly optimistic.
Just beware: there might be dragons in libgdx still. It's tested pretty thoroughfully but there's always a chance that i missed something.
ReplyDeleteI so wished i had the time to participate in the Ludum Dare. Good luck to you.
Thanks. Even if there are dragons in libgdx, it's a very accomplished piece of work. I'm looking forward to using version 0.7.
ReplyDelete