An android game framework for rapid game prototyping

I've been game programming over the past month or so. I've finished a very small prototype. While the game itself isn't anything very interesting it was built along with a framework that I think has the potential to be an incredible tool for rapid game prototyping for the Android.



Back in school I wrote a Megaman game in Python. With Python it was easy to overcome the problem of having game entities share complex behavior with features like multiple inheritance and Python's reflection. Not that it wasn't a nightmare debugging nasty logic bugs but at least there was nothing stopping me from writing something quickly to solve a problem in front of me (hence all the bugs!).

Then a while after that project I got into writing an XNA game in C#. That was very different. After writing the XNA entity components for 2D collision detection and sprite sheet drawing I didn't know how to go about combining the two onto an entity. Both components shared things like the coordinates and a bounding box. Is a bounding box a sub-component of the collision stuff or is it a component of the drawing stuff or is it another component entirely?

I eventually gave up on that project and started messing around with Game Maker. Specter Spelunker was my only Game Maker game. I liked Game Maker because at a high level it forced you to think about game making mostly the right way. Just understanding the features and just using the terminology Game Maker makes you use helps out with game making.

But Game Maker has it's limitations. I got frustrated to no end after fighting a seeming bug in Game Maker's proprietary scripting language. I was fighting its lame version of objects and data structures.

Since then I've picked up an Android phone and I'm excited about this platform and its online digital distribution model. So I've been programming with the Android SDK in Java and in Eclipse. I'm very comfortable with Java and Eclipse as that's what I do as a programmer at work. My game framework is inspired by my history with XNA game programming and by an article a friend of mine gave me while I was working on XNA: Object Oriented Game Design. If you're still reading this blog post you should quit now and read some of that article. My framework doesn't implement the ideas there exactly but I've implemented some of the key concepts like having objects communicate with each other through action objects. That gets around the problem of having to implement an entity with an interface for every was another object can mess with it.

This is the player class in my prototype:

public class Player extends GamePart {

private static final int DRAW_DEPTH = 9;
private static final float FRICTION = 0.98f;
private static final int COLOR = Color.RED;
public static int BIG_RADIUS = 70;
public static int SMALL_RADIUS = 55;

public Player(GamePart parent) {
super(parent);
}

public void load() {

addPart(new Friction(this,FRICTION));

addPart(new XVelocity(this,0));
addPart(new YVelocity(this,0));

Circle c = new Circle();
c.x = World.SCREEN_WIDTH/2;
c.y = World.SCREEN_HEIGHT/4;
c.radius = Player.SMALL_RADIUS;

CircleProperty cp = new CircleProperty(this);
cp.set(c);
addPart(cp);

addHandler(new UpdateHandler(this));

addHandler(new WallCollideHandler(this));

DrawHandler drawHandler = addHandler(new DrawHandler(this));

addHandler(new TouchHandler(this));

addPart(new ColorProperty(this,COLOR));

addPart(new DrawDepth(this,DRAW_DEPTH));
GamePart world = getWorld();
world.getPart(DrawService.class).register(drawHandler);

}

}

My framework focuses on treating games as a tree of what I can GameParts -- a GamePart being an abstract class that all game components inherit giving them features like being able compose other parts, inspect the parts of it's parent parts, and register itself to accept certain game messages. The root of the game tree in my prototype is called World and is composed of a part called Player. Player is composed of a number of other parts like velocity, position, friction, a handler for touch, and a general handler for update messages. On every frame an update GameAction gets created by the World and routed to it's children parts like the player ball and the shadow balls. When the update action gets to the player ball, the player routes that action to its parts that handle the action like the friction part and the general update part. The general update part reacts to the action by moving the player based on the player's velocity part The friction part reacts by reducing the velocity by a constant. That's how the framework composes behavior on entities. The blue shadow balls are composed like the player but they are not composed of the friction part so they never slow down.

I've hosted my project on Google Code. You can check it out here: http://code.google.com/p/juicygames/. The fun stuff is seeing how the framework is used. That's in the Undoer package. My next set of features will be around sprite sheet drawing. I'll be building a prototype in parallel and I'll be building the framework up along with all of it.