Europa is a Android 2d game library which I have been working on for the past 5 months on and off.
This was created originally out of some frustration with the existing engines that were available. They all seem to focus heavily on providing classes which abstract the graphics layers of the Android platform. What I really wanted was a proper framework which I could use to organise the game elements. This desire had come about from my previous attempt to write a simple shoot-em-up style game. I got so far with the sprites but got bogged down in how to ‘manage’ the scene elements. When I examined cocos2d I was struck how similar the idea of ‘actions’ was to my original design where I was associating command objects with what I now know as elements from the scene graph.
In cocos2d there are actions which run in sequence on each tick of the game loop and are attached to ‘nodes’ where a node is merely an abstraction and can be sub-classed to implement scenes, layers and sprites. The actions form the basis of all animation and what’s more is they can be composed together to form chains of operations e.g. move from a to b and rotate by an amount. Europa basically follows the same design with a Director, scenes, layers, nodes and an action pipeline which operates in the node elements.
So far I have implemented
- Texture cache which can load images from file or resource. It can also load simple sprite sheets.
- Animated sprites.
- Base Node class which is very much simpler that the cocos2d version where the base class is loaded with masses of cruft.
- Actions for base animation, movement and scene transition.
- Control actions for sequence and parallel compositing of operations.
- Bitmap fonts build from the Android system fonts along with a font cache.
- Publish/subscribe sources for I/O events.
- Simple event pipeline to broadcast to subscribed handlers in nodes. This is not in the original cocos2d design.
- Ability to switch between Canvas and OpenGL.
- Touch areas which respond by broadcast events to subscribers.
- Touch labels.
- Simple buttons.
The framework has been designed with good practise in mind so there are lots of design patterns plus most importantly this has been written with Android in mind right from the start. When I say ‘android in mind’ I mean that there is nowhere where it creates objects with the game loop unless it is deliberate. This was a major design goal from the start.
I have also tried to keep the class hierarchy as flat as I can so it’s exceptionally lean and mean in terms of how it hangs together.
I am quite close to a version of the framework I am happy with and plan to publish it as a work in progress when I get a bit more into the shoot-em-up demo that I am using to iron out the parts needed.
I am no where near releasing this in reality. I rewrote all the graphics subsystem to use matrices for the transformation between the coordinate systems which was a massive mind bender as that stuff is all new to me. Now am at a stalemate. The library is supposed to support Canvas and OpenGL but I have reached the point where I have to decide whether to ditch the Canvas support but I can’t let it go. The problem is that Canvas does not support lots of features like offloading the images onto the graphics memory and also the sprite drawing is so slow when there are lots of images. The caching of images is not efficient. Analysis paralysis has set in big stylee. I know I should just ditch the Canvas support but cannot bring myself to design it out. I’ll come back to it when I’m ready.
I have scrapped this version and am now using LibGDX instead coupled with some of the same concepts.