Good Dungeon Design Principles

[TheLastOrder]

I've learned with my dungeon that Trial and error is not a valid mechanic to expect from the player to solve door/torch puzzles.

If you play grimrock again and pay attention, all puzzles can be solved or have the solution presented to you via observation alone.

Wisdom phrase.

Maybe I need more testers than my brother before upload to the workshop my dungeon (3 levels with lots of puzzles).

[msyblade]

Personally, I got really, really lucky when a fellow over at the Nexus (subaruswift) dl'd Hotel Hades, and liked it enough that when he found a puzzle killing bug (on level 7!!!), he messaged it to me. I apologized, fixed it and explained he would have to start allll the way over to play the fixed version. He really just wanted a full, solid mod to play till they all start coming out later down the road, and he started over. This started a dialogue between him and I about what he was finding right and wrong down deep in the dungeon (He's got the first 6 levels memorized thanx to having to start over a couple of times) and his input allowed me to get the (nearly) finished product up. Just tweaking left to do. But out of 120 ppl that downloaded it so far, he was the one giving consistent feedback daily. Think I will start a thread asking for beta testers, and maybe all the modders can post their unfinished products there for the right people to find them and help test the dungeons.(and give feedback!)

[nichg]

I'd say a fairly successful technique that I've seen used is to understand and shape the player's expectations with the first half to 2/3rds of the dungeon, then play a twist on them for the ending. For instance, Portal did this with having everything be a testing chamber with all the hazards appropriately marked and everything being 'fair', until it suddenly wasn't. The original Grimrock dungeon did this with having most of the dungeon be a straightforward level-by-level dive, whereas the ending became nonlinear.

Understanding the expectations your dungeon communicates is the big part here. Are buttons always necessary to proceed, or sometimes optional, or even sometimes harmful? If there's a random 'clutter' object will it always be used for a puzzle, or are there just sometimes useless items? Do all keys get used up on the dungeon level they're found on, or do your puzzles cross levels? What are the fundamental elements that comprise the puzzles - e.g. is the dungeon aware of when monsters are killed (kill this skeleton to open the door), do items depress pressure plates (or do you require them to all be creature only?), are there torch puzzles, etc?

Sometimes providing extra things the players can learn to expect can be a way of making subtle pseudo-puzzles over the entirety of the dungeon. For instance, lets say that you color-code the lighting in the dungeon. Red-lit rooms tend to have rough combats, yellow-lit areas are puzzles, blue-lit areas have treasure. Then later in the dungeon, you make a grating that reveals a blue-lit area, and the players will want to try to get there if they've been paying attention. Or you have three doors, one lit red, one lit yellow, and one lit blue, only one of which can be opened to proceed...

Once you have some idea of what the player is expecting you can use that - generally you want to go with the expectations, but going against them can be useful. You can make certain subsets of your dungeon memorable if they violate a rule you've been following in the dungeon design everywhere else. For example, lets say your dungeons have a 'base' which you can return to and get food/healing/etc. A section of the dungeon where the way closes behind you and you have to discover an alternate path to get home ends up being tense and memorable due to violating that expectation of the player being able to set their own pace. However, if the entire dungeon were like that, none of it would stand out in particular. This is a subtle art though - violate the wrong rule and you just confuse the player.

[Skuggasveinn]

Code: Select all

function BuildDungeon()
	if buildstate() ~= "DONE" then
		Design
		Build
		Test
		Iterate
		return
	elseif buildstate() == "DONE" then
		Publish
	end
end

There are a lot of Work in Progress out there, in my opinion that should not have been released in there current condition.
Take your time.. release something that is fun to play, challenging but fair.

I have been sitting on a fully crafted dungeon for about 2 weeks now.
When you can't crash it, get stuck in it by yourself, its time to bring in some other people.
I got 10 people testing it in and out, and some amazing weirdness has been found to say the least so yeah like Drachir said, get someone to test it to pieces.

Some of the stuff I have run into is:

Puzzles involving timers:
Some older computers can produce movement lag, timing something to the millisecond is not the way to go.
I have a pit-trap chamber and was cutting things a little to close, I had to ease up on the timing and I moved it to an optional path, but with greater reward for the player.

Complicated designs:
When you design something it makes perfect sense to YOU. But when testers report that they don't know what's going on and it gets frustrating you need to ease up again, trying to strike a balance between challenging and frustrating is something you will always need other peoples help with. Sometimes you need to simplify the puzzle or lay down more clues.

Be fair:
Nobody likes a dungeon master that cheats on his rolls
Some of the monster placements in the mods I have played are less then ideal
On this forum you can find spreadsheets and item levels etc , use them.

Try to tell a story:
Why are you here ?, what are you trying to find ?

these are just my 2 cents

Best regards.
Skuggasveinn.

[Komag]

every one of you have added excellent tips and advice!

added to the Editing Superthread

[Jakegilla]

Wow! Thanks everyone who contributed, this is a real gold mine!

I'm actually working on replaying the game with a notebook handy and keeping track of how Almost Human designs their levels.

I'm curious if you guys think its necessary to reintroduce the core mechanics (as the vanilla game does) with a custom level. It seems odd not to do it, but I wonder if people already familiar with the game would find it tedious.

[Anurias]

When you say 'core mechanics' I find myself thinking that you are referring to things like on the first level where there were runes on the wall telling about a loose rock or a hint to throw something over a pit onto a pressure plate. If those are the mechanics you're meaning then no I don't think you necessarily need to re-introduce those. However, each of those things in LoG was an aspect of the types of puzzles you would face later, only sometimes combining multiple elements. In this regard you probably want to look at the types of puzzles you intend to have and break them down to their simplest components, introducing each individually and gradually combining and mixing them together into progressively more complex puzzles. This helps the player to get an understanding of the way your puzzles work and how to look at them to solve them.

[SpiderFighter]

I'm reposting this (my post) from another thread, because some of them are related to overall dungeon design, while some are related to work habits. Hopefully, someone will find at least one of them useful.

A few tips I've picked up along the way whenever I start creating with an engine/editor that is new to me:

1. Create a New Folder on your desktop, so you can keep references (such as useful threads, stats tables, your own notes) quickly and easily accessible. For Grimrock, I have two tools (among others) that I keep in it, because I use them constantly (both created and generouasly donated to the community by Edsploration):
Dungeon Analyzer - invaluable tool for testing balance
Stats Spreadsheet - tabs are on bottom for different Monsters, Items, Spells, etc

2. Text files are youir friends. In your new folder, keep a text file called "things to do" (or something similar). When you get a new idea, jot it down. You'd be surprised how many things get forgotten about while you're working. Use it to jot down notes to yourself as you test your maps, too ("place mortar & Pestle in second level," "teleporter in skelly warrior room not working," "forgot to Add Torch to torch_holder in upper left corner room," "tweak timing on pit trap puzzle"...you get the idea.) I also keep a separate files for script notes (anything I know I'm going to want to add that will have to involve scripting), and a Credits text file, so I can keep track along the way of whose code I've used.

3. Find a design method that works for you. Some people map out an entire dungeon, then add mobs (monsters), items, and scenerey. Some create each room completely as they go. I work in between...I'll generally save scenery and items for the end, but I'll add monsters, puzzles and lighting as I go. They all have pros and cons.

4. Be realistic. There are some things that specific game engines can't do. The hardest thing about designing maps is having the courage to edit out ideas you really love, but either aren't working or are disrupting the flow or gameplay (balance, pacing, fun factor)...but those who can do that, often do the best work. Use the limitations of the engine to your advantage. For example, The Duke 3D ("BUILD") engine couldn't do rooms over rooms, yet people found several ways to create the illusion that it could. Make the engine work for your ideas, not the other way around, and you'll find both your dungeons and your skills improving.

5. STOP banging your head against the wall! I can't tell you how many times (particularly while trying to learn scripting in LoG) I've worked an hour or more on a single function, then come back to it later and it was something as simple as restarting the editor, or a misplaced word or connector. Take a break if find yourself spending too much time on one thing while getting nowhere.

6. Pay attention to your mistakes. I released a beta into the wild that was probably possible to play only by myself, because I unconsciously assumed a 100% completion by the player (because I know where every secret is and, therefore, every strong weapon or spell). Now, I've learned and adjusted (after pulling it from release): I now have a separate text file with a list of every item I want in a level. Toward the end of designing, I run through it and place those items, deleting them from the text as I go. In this way, I can better balance things (so 3 spell scrolls aren't in a row, for example. That also leads me to my last point (for now:

7. Assume players will only find about 75% of items in your map. Doing this will make it much more playable.

I think the best way is to recruit a couple folks to specifically test your map and get back to you on it

Volunteering, are you?

[Phitt]

One thing that I noticed in a lot of custom dungeons is that many people seem to think the more lights there are and the more different colors the lights have the better the atmosphere is. And I couldn't agree less.

First of all, just like in any other game, lights are performance hogs. Maybe if you run a GTX 690 you don't care about performance, but other people with (even slightly) older and/or less powerful cards will get a bad framerate, and a bad framerate means no fun. Apart from that one well placed light casting nice shadows has a much better effect on atmosphere than 10 randomly placed lights that are all over the place. Afaik the max view range in Grimrock is 8 tiles, so it is probably a good idea to make sure not more than 3 lights are in a 90° angle 8 tiles in front of the player ever.

And light color...uhhh...I know, it's probably fun for some people to create new lights with different colors. But if you have all colors of the rainbow in your dungeon all you will achieve is that it looks silly. Do you think AH didn't have the option to create new light colors? Then why did they only have two colors for their lights (greenish blue ceiling/healing crystal and yellow/red torch light)? Because less is more and in this case less is definitely more. I even think without custom objects anything but the default light colors looks out of place (apart from some minor adjustments of course). Where does the pink or green light come from? I guess it's 'magic' light. Seems like the mages got drunk on an 80s party and then cast some spells. Please, stick to light that makes at least a bit of sense and use it carefully. Especially don't use weird colors like pink and don't oversaturate lights so your dungeon looks like the Hello Kitty fan club painted the walls.

Just my opinion.

[Ixnatifual]

Volunteering, are you?

Good to know we have a dedicated tester who'll test all mods free of charge.