@Play 77: Rules of roguelike design

@Play #77

It's been over two months since the last column, a state that I blame on general poor spirits, personal projects and (to a degree) the twin scourges of Minecraft and Desktop Dungeons. The next column shouldn't take nearly as long, as it will consist mostly of excerpts of one of those personal projects, an encyclopedia of roguelike games. (Which complete document will probably go for sale on Lulu or Amazon or some such.)

I should note that the title, "The Eight Rules of Roguelike Design," was not my idea. I don't think there are only eight, or as many as eight, or whatever. I have eight listed in the column but I think it's fairly obvious from the introduction that I don't actually consider them particularly hard rules, although if you break one you should know what you're doing, certainly. I intended it as a kind of guide to how these games work to provide interesting game choices. Rogue in particular shows a lot of nuance in that area, which indicates to me that the developers must have spent a lot of time devising it.

@Play 76: A first rule of roguelike design

@Play 76

When you die in a roguelike, is it your fault? Not always. This column offers the beginning of a framework for determining whether it is or not, by thinking about the game in a way analogous to checkmate in chess. The move that puts you into a situation in which you might die is the bad one.

At the end of the column I mention the possibility that one might formulate a set of laws of roguelike game design. I've so far come up with six of these. They'll be covered in more detail next time.

Posts are still fairly slow. I fell away from gaming for a bit back there, and am working on a new game project at the moment, and I have a final paper to finish, and other things are conspiring against me and my free time too.

What I've Been Working On: Mayflight

My secret project, a procedural exploratory game for YoYoGames' summer competition, is ready to show the world.  It is called Mayflight.  It's kind of relevant here because I used some roguelike design principles in its making, especially in creating its huge game world and your character's ability set.  (I can't post it on Metafilter Projects yet because it's been too soon since my post of my most recent Gamasutra article.  I seem to be using Projects rather a lot lately....)

It's sort of like a Metroidvania in some ways.  It is a platformer, and you explore a big mappable space looking for powerups and fighting monsters.  However, it has no end.  The game world is randomly created every game, and has no edges.  Exploring out several areas, bring up the map and zooming out, then seeing the trail of blue rooms extending off-screen is kind of fascinating.

Also, the powerup/map dynamic isn't the Russian nesting doll setup of ever-increasing exploration spheres made available by finding new equipment.  Instead your character, Aurora the fairy, is weak in ability at the start, but becomes stronger generally in various areas by finding powerups.

Because there's no end to the world, and the powerups increase ability rather than grant new ones, the point of the game changes.  There is a time limit, and the idea is to go as far as you can during it.  Although it starts at only ten seconds, you can extend it continually by finding "sparks," which are scattered around with the ubiquity of Mario's coins.  The game is played for high score.  The two scores provided are raw distance from the starting location upon death, and a more traditional score that generally measures playing ability and accomplishment.

Playing it, it seems to have a nice balance to me.  The monsters are challenging without being overwhelming (at least not until you have had a chance to power up), the constant need to extend your lifespan means there is little downtime, and it's challenging while possible to survive for more than an hour with good play.  I was even able to squeeze a couple of covert pinball references into the game's interface.  I'm particularly proud of the background generator, which is able to produce a wide variety of interesting dynamically-generated looks for areas for relatively little processor time.  I post some of the more interesting screens here.

Anyway, now that Mayflight has seen a public release I can focus more on @Play.  The next column or two will probably discuss the game as an example of roguelile design principles applied to a very non-roguelike kind of game.  Then we'll probably get back to the usual beat.  In particular, Dungeon Crawl has seen a lot of development effort lately, having jumped another whole version number in the past two months!

More screens from Mayflight: