Roguelike design notes

7 April 2011

So, I'm going to try and make a roguelike again. Third time's the charm, they say, and I tend to agree. Question is, what are my design goals? Why would anyone play my game and not others?

The short version is that I want my game to be:

1. Much more fair than your average roguelike.
2. As non-repetitive as possible.

I already explained my reasons for choosing the above goals. Now it's time to see how I plan to achieve them.

The fairness issue is in turn about two different points: randomness and... what to call it... arbitrariness.

See, roguelikes are pretty much defined by randomness. From the map that changes with every game to the shuffling of wands/potions/scrolls that forces you to rediscover them anew with each playthrough, this is the secret ingredient that makes each title infinitely replayable. Too bad many developers don't know where to stop. When combat depends more on luck than the skills and equipment you worked hard to accrue, something is wrong with the game design.

But, but! Isn't dice-based combat a staple of role-playing games? How are you going to make it interesting if it's all predictable?

I could answer by sending you to play a little strategy game called Battle for Wesnoth, which manages to be very exciting despite the fact that combat is entirely deterministic. But that's not what I'm advocating. Rather, dice-rolling could be downplayed in favor of other factors. For example, what if a well-fed character could hit stronger, while a hungry one was less effective? Fatigue could have a similar effect on dexterity. Then if a lowly rat manages to kill your mighty 10th-level warrior, at least you'll know why.

The other point is about special attacks such as disease or petrification, that kill you in a few turns unless you have the exact cure the game developer had in mind... and you've already identified it... because otherwise you won't have the time, especially since the monster that just hit you is still around, and very powerful. With that many ifs, the laws of probability ensure that the first basilisk will kill you, period, which pretty much drains all the fun away.

Compare this with the real world danger of being bitten by a venomous snake. That's really dangerous, as anti-venom doesn't exactly grow on trees. But! Who says the snake can bite you in the first place? Maybe you managed to run away, or maybe you were wearing tall leather boots. And some people have natural immunity, or simply a strong enough constitution to weather it out. Other possibilities such as slowing down metabolism also spring to mind.

Roguelikes are about choice. I don't want my own game to railroad me.

Which is more or less related to the second issue: repetitiveness.

Ever fired up a game just to be confronted with a choice between two dozen races and three dozen classes? Ever wondered what might be the practical difference between a lizardman and a troll, or a warmage and a warlock? And most importantly, how will each fare in the game? Then you know what my problem is.

See, I just argued in favor of choice, but choice is useless unless it's meaningful. Diablo, the spiritual successor of roguelikes, has exactly three classes, but each of them plays in a very different way. And I'd rather have a dozen different weapons than a dozen varieties of polearm that ultimately behave the same in play.

Hint: if it doesn't alter the way you're playing, it's not worth adding.

Last but not least, there is another kind of repetitiveness, namely between different gameplay elements that do the same things. Look, I know wands, scrolls and spells are all fantasy staples, but what reason do I have to use one over another, except that I happen to have the scroll, but not the wand? And then there is some overlap with potions, too, just in case it wasn't enough already.

If my little roguelike makes it that far, I want magic to be magic and potions to be potions. And little furry creatures from Alpha Centauri... Ahem. Then again, as I like to say, rules should be roadsigns not roadblocks. After all, the end goal of any game is to be interesting and fun, and that's what I mean to achieve.

Now, of course, there are many more issues. Graphics versus ASCII. The data model. Scripting. Things that are tempting to implement in an improvised manner, but should actually be designed intentionally. But that's for later in the process, after I've figured out what kinds of things I want to be able to do in the game.