Storms on Cloud 9 #33:

Endurance

by Scott Holliday
2004-07-02

The last few weeks, I've given online gaming a rest to go back to one of my old favorites: ZAngband. For those who aren't familiar with the name, it's an Angband variant based loosely on the Amber setting by Roger Zelazny. For those who don't recognize Angand, it's an improved version of Moria, which is a turn-based ASCII "graphics" dungeon exploration game much like Rogue or Hack. For those who are still lost, it's a game based on a game based on a game made in the late 1970's.

So why is a game with 1970's technology still enjoyable 25 years later? Considering the number of fansites and different variants available, I'm not the only one who thinks so. In fact, it is so popular that there are sites such as this devoted entirely to Roguelike development. While I was researching dynamic environment/quest creation for my own projects, I spent quite a bit of time exploring various Roguelike random dungeon generation algorithms.

I'm guessing every developer dreams of building something that would remain popular for 25 years. As I've stated before, many modern games such as the Diablo series are clearly children of the Rogue family. In addition to basic gameplay, setting, and dynamic dungeon generation, other similarities such as differing qualities of item generation (the term "item drop" comes from long before modern CRPGs) are almost exactly like the older game.

So, as developers, what lessons can we learn from this? What qualities about Roguelike games have allowed them to survive the test of time?

1. Community Development: The original Rogue game was innovative and interesting for the time, but the community projects that followed is what resulted in all of the complexity and all of the variants of Angband today. In addition, each independent project learns from the others. When an idea works well in one project, it is absorbed across all of the variants, improving the whole community. Unfortunately, this structure won't work for most developers because of the money aspect. Especially for subscription games, developers wouldn't want to see modifications of their client (or server) appearing from the community. However, for many modern FPS style games, giving out the ability to build maps or basic scripting has built strong development communities.
   
   
2. Hot Tech Not Required: As most of the Skotos community would tell you, the latest graphics are not required to make a fun game. In fact, in many cases, a text presentation would be more appropriate for the game in question. Some games are reliant on some basic graphic technology or clever use of ASCII (imagine trying to play any of Skotos's strategy games using raw text output). Likewise, having nice graphics is sometimes one way to improve the feel and immersion of a game. However, the ongoing trend to overwhelm older graphics cards doesn't really keep your current players playing. Graphics for the sake of eye-candy might be nice, but they won't entertain players in the long term.
   
   
3. Dynamic Generation: Using computer resources to generate content serves two major purposes. First, it allows the player to constantly experience new and different combinations of what is available. This keeps material fresh since the player never knows exactly what to expect. For games in which the best items/events are rare, it provides ongoing encouragement to keep playing. Secondly, once the basic building blocks are finished, dynamic content generation can substitute for hundreds of hours of content creation. The key is to make sure you have a smart algorithm and both simple and more complex blocks available.
   
   
4. Treadmill: Personally, I detest the treadmill aspect of most CRPGs. However, I can understand the appeal. There is an obvious satisfaction in the ability to advance to areas previously unreachable or stomp carelessly through obstacles that were once dangerous. In any case, if there is going to be a treadmill, the attraction will be in the significance of advancement. Does progress make life easier for the player, or is it just more of the same with more difficult obstacles?
   
   
5. One Person Play Value: Rogue and most of its derivatives are designed as single-player games. As such, they are meant to be fun with a single player. I think the lesson here is that a good measure of a game is how you would measure it if you are playing by yourself. Naturally, this wouldn't apply to many online games, such as communication or competition style games. However, in these cases you are totally dependant on the community to provide those needed elements. When communication isn't available, are your players going to leave? Will they ever be back?
   
   

My point is not that developers should emulate the Roguelike genre. On the contrary, these are just elements that have been found to be popular in Roguelike games. Although it may carry across to some related genres (such as MMOGs), you wouldn't want to "rogue-ify" every game. As stated above, a communication-based game wouldn't work very well with the same structure. On the other hand, since many MMOGs already follow a Roguelike design, the lesson here is to look at the oldest (and most developed) member of the family. For instance, playing ZAngband has brought to my attention several good ways to do things. But at the same time, it has presented several difficult points that I would want to work on in my own designs.

[ <— #32: Captive Audience | #34: The Wheel —> ]