Mega Driller Mole is a short-play, score-based action game for Android, originally developed as a prototype for the Mobile Devices module on my course at the University of Derby. After submission of the assignment, further development was undertaken by Pillowdrift and myself (mostly Pillowdrift) to make the game worthy for commercial release. Mega Driller Mole was released for Android on 19th June 2012 via Google Play. It’s free, so if you have a capable phone, there isn’t really any excuse not to try it out.
Because of the commercial use of this project, I will not make source or executable versions available here. The rest of this page will describe my work on Mega Driller Mole, including the design and implementation, prior to submitting the assignment and handing the project over to Pillowdrift.
Born of in-jokes and a slight obsession with drills, the concept is simple and familiar: guide a character around the screen using your Android device’s touch-screen, collecting the score items and avoiding the hazards.
The game takes place in a 2D cross-section of earth with an area of surface being visible at the top so that you can pop out the the ground like a dolphin, flip if you like, then plunge back in. I figured that the player would need some sort of incentive to jump out of the ground, even if it was fun in itself, so I came up with a system whereby you build up a combo and a load by collecting minerals, and then leap over a vehicle on the surface to cash in. Hitting a hazard while carrying a load loses you all your combo and load, but unloading into the vehicle also robs you of your combo – introducing a nice risk/reward mechanic. In order to facilitate this combo system, and give some lenience I felt was necessary during development, the player can take three hits before flying out of control and exploding, ending the game.
As initial hazards I introduced mines, though I had intended to implement dynamic enemies such as Demon Cats and Giant Worms if time allowed (it did not). I also created Hot Rocks, which provide a speed boost for a limited time. These are located near the (previously) impenetrable bedrock, and allow you to jump much higher when unloading, so as to achieve a small height bonus, multiplied by your current combo.
For the implementation of the game my original intention was to use OpenGL ES and create my own basic framework wrapping the Android API for all rendering, input, sound and interface requirements. However, after working towards this for a few weeks I decided that with the given time constraints and four other modules to attend to, it would be better to take a higher-level approach.
libgdx is a library which tightly wraps a lot of Android functionality and provides implementations which allow your game or other application to run on desktop PCs. It also provides a convenient wrapper for OpenGL ES 1.0 and 2.0, allowing for hardware accelerated graphics on both platforms, and a number of other useful classes and functions for game development.
Using libgdx sped up implementation time significantly by allowing me to both implement and test features on a desktop PC. Marks in the module were centered around efficiency and use of the Android API, so it’s fortunate that the time saved in game development also allowed me time to explore features not wrapped by libgdx, such as databases, invoking other android applications, and the XML layout system. To keep cross-platform compatibility for the databases and web-links I used a simple system of interfaces and dependency injection to create services.
This being a big issue on mobile devices, I began by adopting the usual methodologies I apply to object orientated games programming: avoid nested loops, don’t use accessors to reach local variables, don’t dynamically create and delete objects too frequently, minimize the conditions under which intensive algorithms are run, and don’t do complicated simulation where cheating will go unnoticed by your audience. I drew the line at avoiding accessors entirely (as suggested by one of my lecturers) because of the safety they offer, and comments I found from one what appears to be one of Dalvik’s JIT compiler’s engineers. I also concerned myself heavily with memory use and allocated fixed-size collections of objects which would be recycled during operation so that a tight grip could be kept on the number of active entities and such.
As it turned out, this was enough to keep the game running at a great speed, held in memory when not at the front, and not an excessive drain on one’s battery, so I never went into the really deep optimization that might be required for an application left running in the background, for example. The target devices were mid-range phones and tablets, so there should be a good range of compatible devices out there.
This was not strictly necessary for the design, and I’ll wager it only garnered me a few extra marks due to careful use of memory. Still, I found myself with a spare day during the Easter break, and I felt like implementing an efficient 2D particle engine in Java (we all get that feeling, right?).
The first step I took was to run the particle system in a different thread to the main game. This should help to minimize the impact on gameplay if it causes lag, and also allows an adjustable update rate to be implemented for the entire particle system. To manage the memory used by the particle system I created a double-buffered pool of particles, one of which is used to draw the particles in their current state while the other is being updated. This way, the only synchronization which needs to occur between the two threads is in the swapping of the two buffers – a very fast operation.
In order to facilitate the addition of particles to a system running in a different thread, I used Java’s ConcurrentLinkedQueue type, to which particles are added to from the game loop, and pulled off of from the particle update loop. The particle pool, being a fixed size, keeps a count of active particles, and simply copies the last active particle into the space freed when another particle is removed. By also keeping a single particle instance in each emitter, and passing it by reference to the add queue, it is possible to operate this particle system with minimal memory allocation at run-time, as long as you’re careful of adding it to the queue twice at once.