It took some time until I finally could get back to my little Android game and I must admit that this wasn’t really a “day” I worked on it. Instead, it were multiple, scattered and short sessions where I worked on the collision testing and response code, some effects and UI stuff. It’s simply too hot currently… so bear with me that there’s no cool video this time.

Keep reading below if you’re interested in the recent progress. Comments are welcome! In case you missed it, also don’t forget to read the earlier reports on my steps in Android game development: Steps 1-3, Step 4, Step 5.

All game objects are composed of several components for rendering, behavior, audio,… I’ve tried to make up these components to be as independent as possible, only accessing their owning game object to gather information. It would be natural to add components for collision testing, but it would have a pretty bad impact on performance if every component would independently check for collisions. Moreover, it would need to access all other game objects which I wanted to avoid as well.

So instead I decided to keep the collision testing separate to do it once for all objects and then let those components who are interested in collisions access the gathered data. The collision testing is quite trivial at this point – simple bounding rectangle checks as I already used them in my old ProjectE tutorial – so I kept it in the GameObjectManager. Two nested loops check all possible combinations once per frame and store a colliding object into another and vice versa.

Now on a different topic. The other day I had a discussion with one of my fellow #gamedev.ger residents regarding whether to use singletons or not – I do. The pattern I’m using to implement singletons is the Initialization on demand holder idiom which allows implementing a singleton without further synchronization efforts. It makes use of the fact that class-initialization in Java is an atomic, non-concurrent operation and ends up in a nice and tight singleton implementation with hardly any overhead.

I have two singletons. One is the ServiceRepository which contains references to most of the core classes, like the GameObjectManager, the SaveGame (representing the current player’s status, e.g. score, health and level) and TextureManager. The second one is a PoolRepository which holds all object pools that I use, most mentionable the GameObjectPool and a Map of GameComponentPools.

To make proper use of the event/trigger abstraction mentioned last time, I’m planning to also implement a basic UI system which allows me to create, modify, show and hide controls at runtime. That way, I can e.g. start each level with a blinking LEVEL x… GET READY text at the start. But here’s a clear tradeoff between pooling and garbage collection; I’m not sure which path to follow at that point. I guess I’ll simple pre-instantiate the necessary dialogs and avoid control creation during level runtime…