Don't Look Back

Don't Look Back was released last week. It's a brilliant minimal atmospheric platformer done in 8-bit color and with a beautiful soundtrack. It's a dark story told entirely through gameplay but I don't want to spoil any of it. If you're into platformers at all it's a 5 to 10 minute game that flows almost perfectly.

Terry Cavanagh is quickly becoming one of my favorite auteurs -- he released Pathways just last month. He's a game designer who knows art and fun.

I'd kill to have the tools to even be able to prototype this quickly. By the way, I should have my second prototype and the second version of my framework done soon.

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.

Zen in Osmos

I got around to playing Osmos today and I'm very glad I did. Ever since my Alien Blood Bath hack I've been thinking about flow in games. Osmos might practice flow better than ThatGameCompany's fl0w itself.

If you want to know what is Osmos or why it's awesome you can just read what I read on IndieGames.com's post. The gist of what I'm interested in Osmos is this: it's a game about getting bigger by consuming things smaller than you, becoming big enough to consume the things that were bigger than you, and avoid the things that are at the moment bigger than you ... because they'll consume you. You can become big enough to consume the whole map though that is not your objective and probably not worth your time. You should become big enough to complete the actual map objective , for instance, to chase down a pretty big green thing in this field of huge other things as that thing you're chasing frantically runs from you. As you move you slowly become smaller. The smaller you are, the more susceptible you are to being consumed. So before starting your objective you need to go out and consume enough stuff, which itself is a dangerous activity, until you think you're ready to complete the objective. When you're ready to move from one activity to the other is totally up to you and how ready you think you personally are to complete the objective. If you think you're hot shit you'll spend a small amount of time developing your guy before flying toward the green thing. Otherwise you might take your time and pick smaller things than you to eat until you feel safe and ready to tackle the challenge.

That's how you create flow in a game. Eddy Boxerman, director of Osmos, calls it Zen Gaming. You leave it up to the player to choose the difficulty of the challenges. But you bake this choice into the game itself. These flow ideas are an intrinsic part of Osmos -- it's not just a feature.

Alien Blood Bath

Alien Blood Bath is an open source platformer game built for the Android mobile OS. To say the game's incomplete or unpolished (like Brain says in that video review I have below) is a mistake. Alien Blood Bath is a strong technical achievement in creating a solid, well written, and feature rich tile engine for the greatest mobile platform in the world. Google's Android hit the market late last year with the G1. It's open Google Market will relieve developers of restrictions to digital distribution like the insane filter Apple has on the iPhone App Store. That's why I think an indie game scene needs to start developing on this exciting platform. And Alien Blood Bath is an awesome start.

I checked out the code and wrote a game prototype in an short amount of time thanks to Matt's engine. The zipped project is up on Will Host For Food. I've been experimenting with the idea of backwards time travel in platformers as a mechanic to reduce at times of punishment player frustration and to create a procedural means to allow player learning by repetition but without the tedium. It's a mechanic I'm calling undoing. Every second or so the game state is saved. When you die, or rather, when you get hit, you return to the last game state. The prototype itself is extremely buggy, barely letting me experience the mechanic but it's close enough for something I developed mostly on a Sunday evening. There are huge side effects to the mechanic especially around disorientation though I'm confident that if I develop the idea I might have an incredible recipe for a simple DDA and simple mechanism for game flow in a traditional platformer and other game genres.