android computer games entity systems games design

LudumDare 21: Escape from the (Android) Pit

I couldn’t enter this LudumDare competition on a technicality, but here’s my entry which plays by the spirit of the rules. I took a total of 24 hours (out of 48), of which only 12 were actual design + development (see below). Hopefully next time I’ll be able to do it properly, and actually compete. I’ve kept to every rule, except that I did my 48 hours time-shifted :) from everyone else (two successive Sundays, instead of a contiguous Saturday + Sunday).

Screenshot + Android APK

Download link (APK – you need to know how to install APK’s manually (google it if you’re not sure, it only takes 5 seconds)):

Escape From the Pit


  1. Make a LudumDare entry as an Android application – none of this easy “make it in Flash” or “make it in java” stuff – let’s go for a full mobile game, designed, developed, and launched in exactly 2 days flat!
  2. Use an Entity System (c.f. my long-running series of articles, and also the public Wiki I created), and show that ES’s facilitate you writing new games VERY VERY QUICKLY
  3. Make a game that was mildly challenging and (almost) enjoyable

Failed to officially enter the competition, but otherwise succeeded…


LudumDare challenges you to write an entire game in under 2 days (technically: 48 hours – it’s up to you how much of that you sleep). You can’t even design it in advance – there’s a theme that’s only decided shortly before the 48 hours starts.

LudumDare was the weekend before last – but I had to work that weekend on urgent day-job stuff. Like: I had to work all day Saturday, and there was no way out of it. So I couldn’t do the same 48-hour stint as everyone else.

Also, I know from previous experience that the “48 hours in one stretch” is very different from – say – “12 hours for 4 days”. When you do a 24 or 48 hour game, you tend to only manage a certain percent of “productive” hours. The challenge of designing + building something from scratch forces you to keep taking “time off” to go think about what do next.

So, I kept a diary of hours worked, and hours taken “off” as well. I’m confident I’d have fitted all of this – development time AND down-time – into the 48 hours. But I had to spread it over 2 successive weekends :(.

Day 1

(3 hours) – install Eclipse and the Android plugin, and the Android SDK. Document what I’ve done (1 hour) and check I can re-do it at will. Google, please wise-up and fix your install process – it’s not changed in almost 2 years, and it SUCKS

(1 hour) – install some extra Android OS versions, get the emulator working correctly, get projects imported, get everything in source-control, get empty app running on hardware device. Ready to start project!

— NB: everything up to this line I should have done before the contest started. If I were the kind of person that had free time on weekdays. Which sadly I’m not —

(1 hour) – getting Android base classes up and running. Takes a while: Android is insanely badly designed for the “Core application” part. Needs hundreds of lines of code to make a Hello World app that *actually* works as an app (Google’s code example that does it in 4 lines is fake: no real app could do that).

(3 hours) – on the beach, not working

(4 hours) – upgrading the open source Entity System Libraries on to support a bunch of features I’ve been using for a while in my own projects. This required writing a lot of stuff from scratch (using my own old source as inspiration), and integrating some improvements from patches/forks that other people had submitted.

— NB: everything up to this line I could have done before the contest started. Interesting though that I thought this was going to be “about to start writing the actual game” and I’ve only finally got to the point where I can write my first line of game-code —

Day 2

(0.5 hours): trying to make textures in Photoshop. Photoshop really sucks. Half the online resources for making the kinds of textures I want require PSP’s unique filters/effects – useless :(.

(0.5 hours): get a single sprite to appear on screen. A couple of idiot errors in one of my libraries – plus Google’s Eclipse plugin being really really bad at understanding “the scroll bar” (bug in ADT: it implements the world’s only non-static scrollbar)

(1 hour): random maze generation (using: ) that makes nice mazes, printing out onto the screen, still with my default “starfield” background. Rotating the screen is causing the entire game-state to be regenerated – includkng the maze – which was an accident, but actually helped A LOT with testing the maze algorithm (just tilt to re-run the algorithm instantly)

(0.5 hours): learn how to do Android input-handling correctly; en-route, discover I’m missing the SDK docs, and set about downloading + installing them … + updating my blog instructions on how to install Android to include “SDK docs” as a section.

(2.5 hours): discovering MAJOR bugs in Google’s basic “touch handling” API for Android – including bugs on Google’s own website source code, and an API designer on crack who broke the core Java contract didn’t document it. Not Happy.

Day 3

(1 hour) – implementing a collision detection system that does proper swept-collisions, but works OK with the poor fine-grained control of touch input

(1 hour) – added filters to collision detection so I could have background images that the player will NOT collide with
(previously was colliding with every on-screen rendered sprite). Also added a very simple lighting system where squares that the player has walked close to or upon gradually light up, showing how much has been explored

(1 hour) – refined the user-controls so you can hold your finger still and character keeps moving in that direction. Added handling in collision-detection system to allow character to slide along walls and into side-passages without the player having to stop and be ultra-precise (pixel perfect!) in timing the change of direction.

(0.5 hours) – added an exit, fixed bugs in the maze-generation (if started on a right or bottom edge, it crashed)

(1 hour) – fix Android’s brain-dead handlig of Bitmaps, giving a big speed boost, and re-learning how to use DDBS memory-allocation-tracking. I’m now auto-caching each bitmap inside my Sprite object. Sigh. There’s no easy workaround: Google says “don’t use getter methods” but Google also says “don’t call our getDrawable method more than once”.

(1 hour) – added ghosts, made them move around the map nicely, and collide with player was *automatic* on first compile (freebie from using an Entity System!). Also made arrows float nicely in same place on screen even while scrolling.

(1 hour) merge code from laptop back to desktop. Finally add the “win” conditions that makes the app playable!

Source Code

To make this game, I improved the basic Java Entity System up on the ES Wiki, and added some usability improvements and features. I created a whole new page for it here:

NB: It’s called “Beta” simply meaning “second generation (beta == second letter of greek alphabet)”. Not because it’s a beta-quality release :).

Source code to the game itself is also up on github right now ––Escape-from-the-Pit – although that’s a closed repository at the moment. I want to double-check there’s nothing included that shouldn’t be before I set it to “public”.

8 replies on “LudumDare 21: Escape from the (Android) Pit”

Can you tell me more about the “MAJOR bugs in Google’s basic “touch handling” API for Android”? Because now I’m interested! There are quite a few bugs, even in the SDK tools. I’m working with GPS a lot, but after an update of the DDMS, sending GPS coordinates from the gui stopped working. Connecting to the emulator via telnet and dropping gps coordinates by hand still worked. In the end I wrote my very own program that sends GPS coordinates to the emulator via telnet. I even used parts from your Java entity system. Worked like a charm!
By the way, under what license did you release your rdbms-beta source? Some kind of: “Do what ever you want with it, but if anything breaks it’s your problem” ?

A “touch” object in java isn’t a real object.

Instead, it’s a singleton. Returned as if it were a real object. You only ever – always – receive the same physical object, every time the API triggers – but the variables in that object change from call to call.

So … if you ever stick incoming touch events in a list, array, etc … your app will fail. This is a terrible API implementation on multiple counts.

I can invent plausible explanations for this design, but what they come down to is:

“non java programmer was asked to hack-out some code for the Android release, and didn’t want to write java, so they wrote a C-style chunk of API code, and didn’t bother to document this”

If someone needs an actual license, they can contact me and I’ll consider writing them one.

But as far as I’m concerned, it’s trivial code – sample code for tutorials – and there’s no license involved.

If the ES implementations become much more complex over time, at most they’ll be open-source (without any GPL crap). The purpose of these articles, github projects, etc is to educate, not to profit.

Oops sorry just been very busy.

… And a lot of the code was written in a hurry, so I’m afraid there’s something stupid in there I ought to eradicate :)

Ah! I was just curious on how you use the entity system in a game, the next step in my quest to understand on how this system is to be used properly. :-)

OK, source project is now PUBLIC on github. I added a bunch of comments in most of the classes, make it a bit easier to read / follow

Thanks for the game code. Its helped me implement my own Entity Component system in C++.

I know that this page is quite old but I’m kind of stuck in the development. How should I implement sound in an entity component system?

So far I have stuck pretty religiously to the implementation of RDBMS-Beta idea for entity component systems.

Thanks in advance

Comments are closed.