Balance Windows, Android game

Midway through January 2013 I came across this website: www.onegameamonth.com/The concept is a year long challenge, a new year’s resolution per say, the aim to create one game, every month. I considered doing it, but decided I probably wouldn’t have time, or get around to finishing a game each month.Spontaneously two days ago I changed my mind and decided to do it. I realised that the game needn’t be of a decent size or something unique, the point is to finish 12 games in a year. So I set to work, and spent a total of around six hours over the next couple of days putting together my January game.The library I nearly almost use when game programming Java is libgdx, due to it’s ease of use yet scale of complexity. I’ve got flexibility to make something as easy or as hard as I want to, as there is always a framework for me to build on if I need it. However, in my time of using the library, I never really used it’s key draw amongst game developers, how programs can be transferred over to android with only a few lines of code. Libgdx also comes with the Box2D physics library packaged in, so this seemed like a perfect opportunity to explore these two aspects and attempt to broaden my abilities with the library.Having settled on making a game for android, I knew that I’d have to make something incredibly simple, as my time constraints were short already, less the time needed to familiarise myself with writing code for multiple phone resolutions and setting up the project to export and build for android in the first place. My idea was to make a simple balance game, where you attempt to keep orbs from falling off a beam that can rotated about a pivot in it’s centre.Implementing the physics of the orbs colliding with each other and the beam was fantastically easy with Box2D, despite having never used it. It took only a small amount of code the library handles the rest. Although it was a quick set-up, it became apparent that there was a lot of depth to the library and a lot of properties to play with, some of which could have made an interesting game mechanic had I the time. Either way, writing a physics based game was incredibly stress free and something definitely worthy of another game in the future.Already using box2D, it seemed stupid not to implement the Box2DLights library, a separate download that adds, unsurprisingly, very easy to use a nice looking lighting to a game with minimal code. Some simple code to get the graphics to render, put in a primitive score count, add some difficulty levels and there!I knew the biggest challenge of writing this small game would be to get it running, and running efficiently, on android in the time constraint. Having a reasonably fast computer can make it easy to be over-optimistic when deciding how far to push lighting and graphics, v.s performance. It quickly became apparent that the a high volume of lights on the higher difficulty levels would not run well on android, at least on my phone. I took some time then to ensure there was a button to toggle the lighting on and off. Despite this, I still find the performance to be worse on my phone compared to my computer, however I hope on a newer smartphone this gap should be less noticeable.Towards the end of the project, after I’d put in all the mechanics and game-play, I realised I’d need to ensure everything ran fine on different mobile resolutions. An issue arose with the Box2D physics and the change in resolution, as an increased resolution meant an increase in the distance from the centre of gravity the ends of the beam were. I found this was messing up the motor on my pivot joint, so that on smaller resolutions the beam could be rotated too fast and on large resolutions it rotated far too slow. I realised the solution re-write all references to the screen’s width and height with a constant base size, then let the built in Orthographical Camera object with libgdx handle all the scaling to the correct resolution. This mean that as far as the game was concerned, it’s always at the same resolution. The only part of the app that needed to care that the resolution was different was the camera. Half an hour of code re-writing and the project was done. The game-play truly finished, hopefully the android optimizations adequate. There’s plenty more hours that could go into making this run better, and certainly several days if I had other phones to test the app on. However, the point of the challenge, at least for January, was to put together a game very quickly, to a point where, no matter how basic or un-interesting, it could be classified as finished. I think that goal was achieved. I’m considering getting a developers licence for the Google Play store to upload the app, with the anticipation of experimenting for with writing apps. Ultimately this would provide a perfect source of feedback as to how any apps of mine may function on other devices.I haven’t put any consideration into what I’m going to do the February game, although I much prefer the challenge of writing a game in a very small amount of time rather than trying to write something bigger over an extended period of time. The pressure of getting it done, combined with the simplicity and purity of what you have to make, makes it a fun challenge.