Dungeon Design as Lesson Planning

Started by Max, January 23, 2019, 10:07:08 PM

Previous topic - Next topic
So, I've been thinking about my philosophy on dungeon design and was curious if anyone else has thoughts on it.

My primary goal is pretty similar to my goal when I've taught classes before. I want the player/student to explore the dungeon/material I've provided, think about the information I've given them, and use that information to solve challenges, thereby internalizing the information. Each challenge is a kind of test.

If you're a good teacher, you don't let the student ignore every assignment and test before the final exam. Then they'd go in and be frustrated if they hadn't learned how to solve the problems the exam was giving them.

Dungeons are similar. If you don't require the player to show they know how to solve small components of a big challenge, then they're likely to fail the large, complex challenge you give them later. I think failing to solve a puzzle or defeat an enemy because you're unaware of how or even that you can perform some kind of action is the most frustrating kind of problem you can experience in a game.

A well-deserved dungeon will have already required the player to prove they know how to solve each piece of a larger challenge before allowing the player to undertake the big challenge.




So what does designing a dungeon like this look like? You can go about it in a ton of different ways, but I'll outline my method. I'd love feedback on how you think I could improve or how you go about it.

First you need several sets of challenges that build on each other, like lessons. Your first challenges are to learn how to manipulate wind and that you can move some hampster wheels or whatever, for example. Your second set of challenges involve how your hampster wheels and wind interact with each other. Without proving that the player knows how to solve the earlier challenges, we risk putting them into the second set of challenges without them realizing they CAN move the hampster wheels. So how will we ensure the first set of lessons in learned before the second set can be taken on? And how can we make this interesting to explore as a dungeon?

What I like is to make x number of viable paths that must all be completed, but can be in whatever order. X=1 quite frequently, especially in earlier dungeons. Each of these paths involves a self contained challenge. Their completion order doesn't matter, because the lessons each of these challenges teach aren't required for the other challenges. Let's call this set "level 1 challenges", since nothing else the this dungeon teaches is required to solve them. (You can make the point that they player will need to understand other lessons- maybe how to use weapons or tools they already have. If this is the case, the player must demonstrate understanding of that in order to even enter this dungeon).

Now higher level sets present challenges that combine the tests presented in earlier sets. A level 2 challenge can assume you know how to solve any of the level 1 challenges, and so on.




The next step is to figure out how to prevent players from moving on to higher level challenges without first passing the tests of the lower level challenges. This is where lock-and-key style design comes in. You put locks of some type between the player and any higher level challenges than they've already completed. (As an aside, it is much more satisfying to find a lock, then find a key and excitedly travel back to it, than to find a key, continue wandering, then stumble across the lock. Try to place most locks along the player's path to the keys.)

This might look like a player getting a key from a challenge that requires them to move a log out of the way to get to a chest. They use this key before they can get to a challenge that requires them to know they can move logs to solve another challenge.

This type of design is also evident in dungeons where some areas are gated off by requiring a special item or tool. The player needs to prove they know some usage of a tool before they can be tested on that usage in combination with another mechanic.

So I try to arrange the first set of level 1 challenges in an interesting area. Completion of all of these challenges somehow unlocks the next set. This next set can be nearby to each other, or can be accessed from various places branching off the level 1 area. This is one place dungeon difficulty can be modulated. The further the distance between each component in a set, the more difficult it will be for a player to complete them all to move onto the next set. You can think of this as the axiom: the further the lock is from the key, the more difficult the navigational challenge will be. It's a very nerdy game design rhyme.




So we'll have several sets of paths. I try to arrange these sets of paths so that you can't go more than 1 room or so down a path you can't yet complete. The more difficult you want the dungeon to be, the more paths you leave open to allow the player to start down.

Perhaps in an early dungeon you have 2 paths the player can start down but won't open until later in their progression. In a later dungeon, there might be six paths they can start down, 2 of which will open from keys they find after completing level 1 challenges, 1 of which opens after a level 2 challenge is completed, which will provide the dungeon item and allows the remaining 3 paths to open.

The important part is that although satisfying navigational challenges can be presented to the player via many different closed paths they can start down, don't let the player go very far. Going through five rooms along a path before you find you need a key from elsewhere is not fun. Investigating five rooms, each the start of a path you can't yet take, is fun because it teases the player with paths they'll be able to fully take later, and adds satisfying challenge in remembering which path will open now that you've found a key of one sort or another.

The easiest dungeon only shows you the path you can take. A more satisfying but still easy dungeon shows you two-three paths, but only one is viable once you start down it.




Next I'll roughly figure out what I want as far as how these paths cross over each other, what I want to be loops, try to draw lines so the player isn't immediately dumped at step 2 once step 1 is completed, but there still isn't too much backtracking. One-way loops are very useful for this. It's not what I mean to focus on here, but self-contained paths shouldn't be linear- obviously the player will, upon completing the path, have to take it again backwards.

A perfect unidirectional loop is better, because the player completes a single path, and finds themselves immediately back where they started, ready to navigate to the next challenge.

A path that rewards the player with some type of key can loop the player back near to where this key's lock is located (as ideally, the player would find the lock first). However, if you loop the player back right to the lock's location, you remove all challenge the player might have of remembering and navigating to the lock- at this point it might as well be a linear path. This is another place you can modulate difficulty as a designer. The further away you give the player the key from the lock, the more difficult the navigational challenge. So you may want to loop the player back fairly close to a lock in an earlier dungeon, but in a later dungeon, design the loop so it deposits the player in an area of the dungeon that, while familiar, is far from the lock.




So at this point, you've got several sets of challenges, where each set teaches you the lessons you'll need to complete later sets. So you can safely know your player won't be frustrated by a challenge they don't have the tools to solve. My idea of how difficult I want the dungeon's navigation to be will determine how far geographically I want each challenge to be from the other challenges in the same set. That also determines how far I want the player to travel to get to the next set of challenges after they complete a set.

Now I start to roughly sketch out the geographic relation of all my paths and challenges.

One common design pattern is to have one, or several, hubs. Each hub doesn't have to be a single room, it could be a series of rooms. But each challenge or path in a set will be a spoke from this hub, and once the set has been cleared (this may be a good time to remind us that sets of 1 are common and fine), the next set will become accessible from the hub.

I personally find that, especially in later dungeons, three or four hubs work well. The first set of challenges are around hub 1 and unlock hub 2. The second set of challenges are around hub 2, and unlock a smaller hub 3. The third set of challenges are around hubs 1-3, forcing the player to remember previously inaccessible paths and return to them.




I have a few other stray thoughts on dungeon design.

First, I think it's very good design to make areas the player has to backtrack far to have a memorable landmark. If the player needs to backtrack across most of the dungeon to get to a puzzle they can finally solve with a new item or something, this location should be memorable. A unique graphic, room shape, enemy, or arrangement of elements in the room will help. This is why Zelda's boss doors usually have special graphics.

Rhythm is also important. Every room in a dungeon doesn't need to be an intense fight, or though puzzle. Having rooms where all you require of the player is to walk through is fine, and allows the player to take a mental break. Particularly for hub rooms, or other rooms the player will need to travel repeatedly, you shouldn't require the player to re-engage with a challenge. Challenges should only need to be solved once.

The difficulty of a dungeon doesn't need to constantly escalate. While the general difficulty curve should rise, having breaks between challenges is important, and those can be easier challenges. Besides challenging the player, you could also be making them feel powerful or clever.

Main paths should usually be at least 2 tiles, unless you have some reason for making them narrow. If you're often requiring the player to go through narrow paths to navigate, this will cause the player to frequently question if they're on the path the designer wants them to be. If you want them to take this path, why did you make it so narrow? This is mainly important in overworld design, but narrow paths in dungeons only make sense in caves or if the player feels they're exploring into an area the fictional in-world people who built the dungeon didn't want you to visit.


I like how in Zelda games they often force you to use the new item you found in that very room to get out. If you don't realize there's a new mechanic, it's at least obvious that you have to do something to get out. And since you are trapped in the room until you figure it out (and thus limiting the possible actions possible), it prevents the player from wandering around the rest of the dungeon aimlessly trying to figure out what to do next and getting frustrated.

One aspect you've barely touched on is using visual cues to guide the player to where you want them to go, both consciously and subconsciously. This could be as simple as adding lighting where you want to direct their eyes and adding shadows where you don't want them to go. Or perhaps tapering the room into a point. Or maybe just the use of colors to guide their eyes.

Yeah, those are really good points! Trapping the player in a room is honestly great. The player is absolutely forced to demonstrate their understanding of a mechanic to progress. While it can be overused, I think it should be required for situations where the player needs to know "oh, I can DO that?"




Visual cues are definitely worth going into. Light and Shadow is a good one for all visual mediums. What you mention with tapering the room is also really good, and one way to use visual hierarchy to direct the player.

Many of the techniques architects use to direct people's attention and guide their circulation through a space are perfectly applicable for level design too. You are doing the job of an architect, just for a virtual space instead of a physical one.

A taper or triangle naturally draws attention to its corners. A circle naturally draws attention to its center. People's eyes will follow straight lines from end to end. Eyes are attracted to detail, and will pay more attention to busier or more sense areas. Symmetry always catches our eye. We also are hyper aware of patterns, and will even try to make them where there aren't any. All of this should be leveraged to either direct the player toward something you want them to see, or used to distract the player from something you don't want them to immediately notice.



Another thing I didn't mention is that not only should paths be at least 2-3 tiles wide, they shouldn't be too wide either. Then it doesn't feel directed. All of that falls under the principal of scaling your space to the size of the thing moving through it. When people need to decorate a large room, they'll usually section it off into smaller areas by arranging their furniture into partitions, so that each little "room" in the room is scaled to human size.

But all of that falls more into a different topic than designing dungeons' challenges as lesson plans.