Baseless Rook is none other than Ken Grafals!

I'm Ken Grafals. You know, the Specter Spelunker Shrinks guy. OK, maybe you don't know me. But you will! I've dropped the Baseless Rook handle. Handles are so 90's.

Long story short, I gave up writing a game engine for Android. I picked up Unity and have been making games with that. Unity is incredibly powerful and the interface is pleasant -- I'd recommend it to anyone. I built Specter Spelunker Shrinks in Unity 2.6 with spare time outside of my day time job over the course of about a month.

Check out the website!

Play the game online!

Did anyone hear me? Is anyone reading this blog!?

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.

World of Goo: Indie games win

There are a ton of free indie games you can just download from the net. Most of them are worth the time of playing them. Some are not. A lot of them are well worth the time. Spending 15 minutes trying a game out isn't a big cost for me. It is for some people. 15 bucks on the other hand is a huge deal for a lot of people. So when you get into indie games you pay for you're in a whole other world from the free stuff. When you're playing something for free you're usually playing the cheapest possible production that it would take to try out a game design idea. But when you get into an indie production with cash, now you're talking about a case where that guy with that good idea can realize it with some cash -- he can hire an artist or a programmer and license some software. He'll still keep creative control. He's just using the money to realize his idea.

That's how you get something like World of Goo. The $15 WiiWare game was made by Kyle Gabler and Ron Carmel -- a couple of ex-EA employees who's office is, as they describe on their website, is whichever free wi-fi coffee shop they wander into on a given day.

World of Goo is one of the most engaging single player games I've played all year. The playthisthing.com guys describe it well when they say the style is all about spunk. World of Goo makes Braid look horribly pretentious.

The story is ambiguous at first. You know your goal is to build a tower of goo toward a pipe to deliver goo to it though you're not sure why. Maybe it's for an ill purpose. But that's not really important. The gameplay revolves around building physical structures in the warped physical game world. The gameplay is completely fresh. As soon as I started groking what was thrown at me Kyle and Ron further build on and variate the gameplay. It engaged me into a perfect state of flow through the whole game which took me several nights to get through.

This game is one of the best games on the Wii. And it's only 15 bucks. It's a little pricier than going out to see a movie. If you own a Wii you should play this. If not just for the reason of stopping Space Horror Shooter X or Shallow Fun For All from consuming the industry. Why not try something new?

Depth in mainstream genres

The first person shooter is a genre that demands a lot of the player in terms of understanding the game's complexity. Yet the first person shooter is among the most popular genres today. It's very strange to me that something that difficult can become so popular. But I guess it's like a sport. No one's going to just kick around a soccer ball for the first time and really play soccer. A lot of people are just going to quit because playing soccer when you don't play soccer isn't fun. But say you're young and you've got time and patience. You'll find fun in uncoordinated wanderings of multiplayer Goldeneye maps. And once you fight the inaccessibility you find yourself having grokked a deep and complicated system. And there's just something incredibly fun about grokking something like that.

Game makers know this phenomenon -- at least intuitively. They react to player grokking by supplying to the market deeper games of the same genre. Once a player gets platform jumping he's going to want more. And he's going to want to shoot bullets at the same time. And he'll want harder jumps to plan. And he'll want enemies that he can predict the patterns of enough to dodge them in a platforming world. So he'll have to be challenged while not being frustrated and not being bored. He wants a state of flow. That demand drives game makers to deliver harder, deeper games of the genre.

That's how you end up with Megaman 9. A 10 buck XBLA game marketed toward the people who find the platforming in New Super Mario Bros. boring and easy. I actually like Megaman 9 quite a bit. It goes against a lot of my ideas about indie games and what games should be and how the medium needs to evolve but I don't want to talk about that tonight. Saying that you want games like first person shooters to stop being produced because it's stagnating the medium is hard to say because it's this thirst for a deeper instance of a familiar genre that gives us incredibly deep games like Call of Duty 4. Calling CoD4 deep sounds weird but a lot sounds weird with the present vocabulary of the medium.

There's a place for the mainstream genre and mainstream game. We shouldn't keep people from practicing what they have grokked so well over years. It's fun. I'll worry about games as an artistic medium after getting through this new Wily Castle.