Thursday, March 24, 2011

Dungeon design journal #3: design philosophy

With the basic system in place, the times has now come to think about content. In fact, I have already coded up two rooms -- one of which is the Entrance Hall, which doesn't do an awful lot. But before I dive into content creation, I should spell out my design philosophy, both to make it explicit for myself, and to get some early feedback.


Thematic background

The thematic background of the game will be sword & sorcery: gritty and violent fantasy that takes place in crumbling civilizations built on the ruins of even older empires. It is a world where wizard don't throw around fireballs and other flashy weapons of mass destructions, but cast curses that trap the soul or rot the body -- curses they have learned in a search for forbidden knowledge that left them more demon than human. It is a world where horrific monsters threaten mankind everywhere, but where no elves, dwarfs, orcs, trolls, faeries, or any of the other "races" of Fantasyland have ever been seen. It is a world where priests are not holy men who turn undead, but cruel butchers who sacrifice men to appease evil ancient gods. It is a world full of the wildest decadence and the deepest despair. It is, most of all and appropriately for a rogue-like game, a world where life is very cheap indeed.

High fantasy and character death have always been an uneasy union. If you are in the business of "wish fulfillment", as the Dragon Age developer on the PAX panel described his own job, you need a world where the player feels heroic, in control, and epically successful. If you're making a rogue-like, you do not.

Sword & sorcery is not an overused genre in computer games. There is a Conan MMORPG (which I have not played, and in fact, I have read almost no Howard), but as far as I can see that is about it. On the other hand, it does allow almost as wide a variety of locations, events and creatures as the degenerate "high" or "epic" fantasy that is overused in computer games.

In the end, given that I'm writing a random dungeon crawl, none of this is too important -- but I like having a vague thematic idea to work with.


Design philosophy

Core design goals. The core design goals of the game are tension, tactical depth, variation, and absence of grinding. The player should be on the edge of his seat all the time, because danger lurks everywhere; success must be a matter of making the right decisions; randomisation should be used to generate a large variety of tactical situations; and increased survival chance should never be a matter of taking more time.
Note that "grinding" is not just a term for things like killing thousands of identical zero-threat monsters, or doing a hundred Mephisto-runs in a game without permanent death in order to get that piece of armour you need. It also encompasses things like the "we rest until healed" and "I search for traps" mechanics of D&D, where slowing down the game session to do a risk-free activity is always the tactically optimal option.
Length. As stated in a previous post, I am envisaging a game that takes place in a small dungeon (say 10-15 rooms) and takes only a short time (say 10-30 minutes). This means that there can be more danger (every monster in Crawl or NetHack cannot be dangerous because of the length of the games), and it removes a lot of opportunities for grinding. However, an external file will be used to track how many games have been won, and new features for the dungeon will be unlocked as the player wins more games.

Fairness. Fairness is not a core design goal for this game. This is a game meant to be played in fifteen minutes. If a lightning elemental was randomly generated in the Tesla coil room (not an actual example from my game!) and no electricity resistance can be found -- tough luck, but you lose only a few minutes worth of play and can simply start again.

What I do want to minimise is "unfairness" that is "unfun": a game that kills you arbitrarily or leaves you optionless in the beginning. Even perfect play may lead to death, but reasonable play should never leave the player without a chance.

Hostile environment. I want the whole dungeon to feel hostile and dangerous. Not just the monsters, everything, including empty rooms and treasures. Partly through description, partly by actually making everything potentially dangerous. Also, we will not hold the player's hand. If she types "jump in lava" or "eat poison", the game will oblige her. None of the "That wouldn't be very smart." stuff.

Trade-offs will play a major role in the game. The basic combat actions already offer the player a tactical trade-off (you can concentrate to do more damage later... but you might be hit in the meantime). Using finite resources ("scrolls" and "potions" in many rogue-likes and RPGs) is always trade-off between greater chance of survival now versus greater chance of survival later. And I'd like permanent items to adhere to this philosophy as well: no "sword that is better than your current sword", but a "sword that is mostly better than your current sword, except". An important kind of trade-off is the temptation: offering the player a prize that can only be obtained by braving an optional danger. Rogue-likes often work this way. "I can run away from that ogre, but if I kill it instead, I would get enough XP to level up...". Many deaths are a result of giving in to temptation -- but many victories are as well. It is also thematically appropriate: the temptation of great riches is often a prime motivation of sword & sorcery characters, and it often leads to their untimely demise.

Surprise. I would like the game to contain a lot of surprising features that will keep even experienced players interested.


That is the theory. Now for the implementation. Comments are very welcome.

7 comments:

  1. Very cool, I find the hardest part is taking a step back and not rushing into implementation.. A design manifesto generally helps keep conceptual integrity in check..

    ReplyDelete
  2. This is very interesting. How are you going to handle UNDO? Just turn it off?

    ReplyDelete
  3. For such a short game disabling saving would be good too.

    ReplyDelete
  4. Saving is already disabled. :) Because the game is going to be so short, I felt that just turning off saving was a better idea that using my own Permadeath extension.

    ReplyDelete
  5. ...is there a lot of downside to including permadeath? Because I often find myself needing to do stuff in the middle of even very short games. I could show you some games of Desktop Dungeons that were beaten in something like nine hours, if DD kept track of your victories. (Admittedly I always just leave the application/browser open.)

    ReplyDelete
  6. Disabling SAVE and RESTORE as player commands doesn't have to be equivalent to disabling save and restore as functionality. In other words, an auto-save at the end of one session coupled with an auto-restore at the beginning of the next might be preferable to no save capability at all. In this situation, the saved game can't be used to cheat--because the player can't invoke either save or restore in mid-game--yet it's fully possible to divide play into sessions.

    Anyway, I've been enjoying these design documents and I'll be very interested to see more!

    ReplyDelete