Monthly Archives: March 2013

Raiders Title

After much work, I feel that Raiders is ready for an initial release. I’ve minimised re-allocation as much as I’m able, and separated the calculations and drawing using a new Thread. This actually boosted the framerate on my brother’s Galaxy Ace from around 25 to over 50!

I may never get round to posting a summary of the PC version, so I’ll do it here. Raiders is a basic arcade-shoot-em-up. The vague plot (if any) is that the player shoots as many enemy ships as possible. As you level up, more valuable ships appear. The score counter counts in the pending score accumulated and multiplies it based on the current Combo value, so if you’re on a 4x combo, each point counted in is worth 4 on the main counter. Destroying a ship adds to a ‘timeout’ counter that has a maximum value of 500 frames, after which the pending score is decimated per frame, and so totted up.

In its current form there are three enemy ship types and no possibility of player death or winning, just a seven figure score counter. After showing both my parents (who are not gamers at all), they both ended up spending a good five or so minutes shooting ships before they got bored. I consider that an achievement!

Here is a download link for a side-loadable .apk. In Android, enable ‘Install from Unknown Sources’, then open the .apk on the phone. Enjoy!

I’ll continue to add more features from the PC version (player and enemy health, more ships, mines, a boss etc) and post the next release here.

After my breakthrough with the primitive game engine for Android in the last post, I’ve ported and adapted Raiders (still yet to write about!). I’ll release it here once its faster, neater and more feature filled, but for now, here is an image!

Game screen:

Raider gameplay

Despite what the screenshot shows (I took it while debugging, which slows the phone down as it reports everything internal to the PC), the framerate I average on my fairly old Galaxy S is around 55 Frames Per Second. I can’t wait to try it on a Galaxy S3.

For a while I’ve wanted to make a simple game in Android. I’ve done simple apps before, such as a scalable test app for A* Pathfinding (which I will write about later) and silly soundboards, but nothing that can actually be played like a game.

The main element any game needs is a 2D canvas on which all the graphics are drawn. It is understanding how to make one, update the contents and render it that kept me back. I’ve also created a few simple Live Wallpapers, but with these all the hard work is done for you by extending an existing class, android.service.wallpaper.WallpaperService (and in-turn extending WallpaperService.Engine).

In order to create an interactive graphical experience outside a pre-built Live Wallpaper Engine, I had to understand how Android handles Canvases, drawing calls and how these are displayed. I had tried doing a similar update() -> render() -> fpsDelay() approach as in my Java games, but an endless loop such as this created in the Constructor of an Android app halts everything.

And I mean everything.

You can’t do any other work in an Android app until the Constructor is done, unlike Java. This is because all the drawing activity is done asynchronously AFTER the application has been created (that is, onCreate() has completed).

To get round this, I found out I could extend SurfaceView and call my update() function in the onDraw() call to keep a cycle going. After some attempts at this, I am pleased to discover it works! Maybe I could make a port of ‘dungeons’ or something similar…

Here is a screenshot from my AVD (Android 2.3.3 Gingerbread), next to a screenshot from my Galaxy S (Android 4.1.2 Jelly Bean, thanks to Cyanogenmod) running the engine:


You can see that performance is much greater on actual hardware!

In the end, the line that gave me most trouble was not including this:



I also found that after I’d ‘closed’ the app, my phone was extremely unresponsive until I re-opened it and killed it manually. Hence, this is needed for now:

public void onPause() {

Which causes a Force Close but I can live with that for now.

‘dungeons’ is the 2D dungeon crawler I mentioned earlier. The main focus is on procedural generation of ‘levels’ with a number of randomly scattered features; rooms, keys, gold and enemies, for the moment.

At the moment, when a level is generated, the following events occur:

  1. Rooms are generated with a random size in random locations. Each room has a random number of doors cut into the walls. doors
  2. The each door is randomly connected to another randomly chosen door using a simple implementation of A* Pathfinding (inspired from this helpful article). After being connected, the door is marked as such, so that it cannot be chosen again. This has two downsides: 1 – There will always be a door that is the last one standing and permanently unconnected. This could be a room with one door. 2 – Paths cannot currently overlap, so it is somewhat messy.connected doors
  3. The middle start area of each level is created at the center. This contains the up and downstairs to the previous or next level. The top most level never has an upstairs, for obvious reasons.stairs
  4. Gold is scattered around for points, keys are scattered around to unlock the trapdoor leading down to the next level. Both are spawned only within rooms, and having more than one key (currently up to five) combats the first disadvantage mentioned in point 2 above.keysandgold
  5. The corridors and room walls are decorated, sort of Dungeon Keeper style. This is done by recognizing the ‘passability’ of tiles surrounding each tile and deciding on which type of layout it is. An example is a right hand corner.decor
  6. Finally, monsters are spawned. These are passed the current level tile data to decide where they can move, and move with a bias towards their current directions rather than turning, so are decorated like zombies for now.zombs

When the player plays the level, all tiles are hidden except those they have just passed. These are revealed with a cardinal line of sight of 5, then forgotten on a tile by tile basis after five seconds, unless a torch item is placed down. visibility

That’s all for now. I’ll release a playable version as soon as its a bit less buggy and a bit more interesting to play. If you want to play it now anyway, send me a tweet and I’ll get back to you soon.

Just for laughs, here is a release for the Filing Cabinet. Its pretty basic software, but I’ve been using it to organize notes that were previously fragmented between Google Tasks, Windows 7 Sticky Note gadget and a plain text file. For me, having these notes all in one place seems like a good idea, and doing it myself helps me learn in the process. Without further ado, here is the link.

If you’re Java literate enough to read the source files you may want to figure out how it works for yourself, but if not, here is a brief summary:

  1. All ‘notes’ are an Entry. These have three fields: ID, Label and Content, all represented as strings. These fields are saved in a ‘.entry’ file.
  2. All ‘drawers’ in the Filing Cabinet are Drawers. These can have any number (though at the moment set to 100) of Entries, and manage creating, listing and deleting individual Entries. These are identified in the respective folder via a ‘.drawer’ file.
  3. The ‘Filing Cabinet’ itself manages the drawers (currently six) in the same manner as mentioned above. After each create or delete operation, all entries and drawers are saved to disk in the path specified. The path can be changed using ‘change path’. If the path is changed, the existing files are reloaded from disk straight away from the new location.

There are quite a few bugs, so please let me know what you find. I’m still adding features, and if it proves useful to me I’ll probably make a GUI for it.


At the moment I’m working on a few project-in-progress, which are listed below. As a general rule, I like to do everything from scratch if I can help it. Unfortunately this results in sometimes inefficient or just plain wrong coding practices and slow progress, but everything I learn on one project tends to get used straightaway in the next, resulting in a sort of ‘standing on the shoulders of giants’ effect. Anyway, here’s the list:


  • ‘dungeons’ (Working Title) – A simple 2D top-down Java dungeon crawler used as a vehicle for exploring procedural generation of game maps, enemy AI and game development in general.


  • ‘ImageAnalyser’ – A scalable Java image analyzer that will find the one or three brightest areas of an image, and return the locations of these, the average brightness of the image and a bearing clockwise from north towards the brightest area. This was used on a recent University project that involved developing an automated tracking system for guiding a quadcopter to an arbitrary target. More details when I write that one up. 


  • ‘PEA’ – An attempt to implement a larger game world, while showing only the player’s range of sight withing the game window. This involves turning world coordinates into on-screen pixel coordinates, and at last count, also a set of mini-map (showing all world space) coordinates in the corner.
  • ‘FilingCabinet’ – Undoubtedly been done before, but more for personal use. Inspired by the brief structure thrown together for humorous purposes in the first post, a command line way of organizing ‘notes’ within virtual filing cabinet ‘drawers’, mainly an exercise in managing file system files. 


So I’ve finally started that blog idea I’d had my eye on for a while – a place to document all the thoughts, processes and results of my attempts at programming. Sure, its been done before, but isn’t that the idea of a blog, to be personal?