January 08, 2005

The Ramble Chronicles: Ramble 0.1

Just for fun, I've made my latest version of Ramble available for download at the new Ramble Home Page. It's available as a Mac OS X application, a Windows executable, and for the die-hard Tclers in the audience, a starkit. If you decide to take a look at it, be aware that it's still in its infancy, and isn't much of a game yet; it's more a preview of coming attractions. The game begins immediately when you start the application; it ends when you die or win the game. In either case, you'll need to quit the game and start over in order to play again.

Ramble 0.1 consists of two levels, a town level and a dungeon level. Here's the town level:

As you can see, the look owes a lot to the original Ultima series of games. We've got some shops (which sell absolutely nothing at the moment, though you can talk to the shopkeepers), a library (walk on the question marks to learn how to play the game) and a King; talk to the King to learn your quest. Then there's the dungeon:

The dungeon is a randomly generated maze with a bunch of chests, one of which contains the treasure you need to find to complete your quest. Unfortunately, it's also got a bunch of skeletons who are bent on killing you. You better hope you've acquired the crossbow before you go down there....

Some specifics of the current game model:

Visibility: The player has complete visibility of each level.

Creature Model: Most tile-based games--in fact, most RPGs--define the player and the monsters using a set of statistics ("stats") like Strength, Intelligence, and so forth; the granddaddy of all such schemes is, of course, the original Dungeons & Dragons rules. At present, Ramble has no such model.

Combat Model: The combat model is a simple as can be. If a skeleton catches the player, the player dies and the game's over. The player can acquire a crossbow; one shot kills any skeleton. I could get a little hifalutin here and say that each creature has one hitpoint and each attack is guaranteed to do one hitpoint of damage, but in fact the model isn't even that sophisticated--there's no notion of damage as yet.

Creature Movement: There are currently three kinds of creature in the game: the King, the shopkeepers, and the skeletons. The King doesn't move; he just waits to be talked to.

The skeletons get to move each time the player does. The algorithm is simple: the skeleton computes the distance to the player from each adjacent open tile, and moves to the tile with the minimum distance. If that tile contains the player, the player dies. Note that the skeleton will always move to an adjacent tile, even if that moves it farther away from the player--that seems counter-intuitive, but in fact it gives the skeleton a limited ability to get out of dead-ends that's surprisingly effective.

The shopkeepers get to move each time the player does, though they are confined to the space behind the counters in their respective shops. The algorithm is the same as for the skeletons, except that the shopkeeper won't ever move away from the player. This has the neat effect that the shopkeeper will follow the player up and down the counter, remaining always directly opposite, an effect I've stolen shamelessly from Ultima.

Player Inventory: There is none, really. There are only two objects the player can have, the crossbow and the treasure, and both are represented as Boolean flags. When the player is given the crossbow, for example, his crossbow flag is set; this enables the "fire" command, so he can now fire missiles. At present, the player has an unlimited supply of missiles. There's no way to drop an object.

So ramble is still incredibly limited. On the other hand, I've come a long way since my initial prototype. Here are some of the technical problems I've solved:

Displaying a graphical map of tiles: I got most of the bitmaps I'm using from a freeware set called Anthony's Icons (you can Google for it, if you care); they are clearly patterned after the original Ultima set. I've added some more of my own. If I were an artist, I'd use beautifully drawn GIF files instead; but I'm not.

Terrain Model: I've defined a number of terrain types (grass, tile floor, brick wall, and so forth), each of which has its own bitmap (or "glyph", as I call it in the code), as well as other attributes, like whether you can walk over it and whether you can see through it.

Feature Model: A feature is something that sits in a tile with which the player can interact. Ladders, chests, and "help spots" are all features. A feature has a glyph, a description, and handlers for different interactions. For example, when the player steps onto a tile containing a ladder feature, the "walkon" handler logs a message telling how to use the ladder.

Creature Model: A creature is (naturally) a person, a monster, an animal, or so forth. Creatures are a little like mobile features: they have a glyph, a description, and handlers for different interactions. In particular, each creature type has a "move" handler, which implements the creature's movement algorithm, and a "transact" handler, which allows the player to talk to the creature (not that skeletons say anything of interest).

Minimal Level Model: Since the game has two levels I obviously have a level model of some kind, but it's pretty simple at the moment. There's a lot more to do.

I'll probably have more to say about most of these things in future essays.

Posted by Will Duquette at January 8, 2005 11:07 AM