
A lot of this will be paraphrasing Jan Thorsby’s awesome post, but:
I tend to prefer puzzles where the player is presented with a clear problem and a motivation for solving it, and where the game provides clear and honest feedback about what is working and not working. It might be helpful to imagine the player’s train of thought:
“I need to get over this bridge, but there’s a dragon guarding it. What do I know about dragons? They breathe fire and they like gold. Have I seen any gold? I don’t think I’ve seen any gold. I could really go for a biscuit all of a sudden. No. Focus. This bridge is on a river, maybe I am supposed to get some water and put out the dragon’s fire? Do I have a container? I have this helmet, that might hold water? Okay, I’ll try that first.”
If a particular solution hasn’t been implemented, the merciful thing to do is provide feedback that indicates to the player “Yes, I see what you’re trying to do, but it’s not going to work.” (Or just go ahead and put it in! Then you’ve got Cool Multiple Solutions!) In our dragon example, if filling the helmet with water is implemented (for a different puzzle solution, say) but using it to put out the dragon’s fire is not, the player might spend a lot of time trying different permutations of THROW WATER AT DRAGON before they give up.
Giving up due to frustration is a fun-killer. When your players stop interacting with something fruitless, you want them to feel like the game is still interacting with them. You want them to think “Oh, okay, I guess that didn’t work, maybe I’ll go and look for some gold” instead of “Are there hints?”
It’s even more important that none of the steps of a correct solution discourage the player from continuing. Thorsby gives an example about OPEN WINDOW not working when the solution is ENTER WINDOW, my personal favorite is “Maybe you should stop eating these aspirin” when the solution is to eat every single one of the aspirin. “I TRIED that but I thought it wouldn’t work because […]” is also a fun-killer.
Let’s say the solution you’ve implemented for our example dragon bridge puzzle is for the player to figure out which of the scenery objects they can safely hide behind, then shoot the dragon in its weak spot with an arrow. Here’s just some of the hinting you might want to have for this puzzle:
-
Trying to shoot the dragon when not behind cover should lead to the dragon seeing you pull your bow out and immolating or nearly immolating you before you can get a shot off. (Lesson: I cannot shoot the dragon while it is able to see me.)
-
It should be possible to hide behind all reasonably hide-behindable scenery objects. If the correct solution is HIDE BEHIND ROCK, HIDE BEHIND TREE needs to work or give a reason why it won’t (“You don’t think the tree’s scrawny trunk and finger-thin branches would hide you very well. You also have concerns about flammability.”)
2b) Bonus: HIDE BEHIND in general should offer a non-default response, so the player doesn’t try it earlier in the game and conclude it doesn’t work. “You have nothing to hide from!” might make a good catchall.
-
The player also needs to know that the interactable scenery objects are even in the room. It can be tempting, valid, and even fun to make a puzzle harder by hiding important objects in the descriptions of other objects, but generally this works best when you are examining the details of something or searching through a quantity of junk. If you feel the solution is too obvious (rule of thumb: it probably isn’t!), you can write the sentences as though the scenery were presented for flavor, say, focusing on the fact that the rock has scorch marks and the tree stands alone in a pile of ash. (In which case you might want the correct hiding place to be that tree, because clearly it’s good at surviving.)
-
The failure messages for trying to shoot the dragon while standing behind the wrong object should indicate that the object is wrong but the concept might still be correct. Be clear that the attempt failed because the piece of cover failed; the dragon still saw the PC, or the object they were hiding behind did not survive another blast. (Actually, in conjunction with the weak spot on the dragon, it might be fun to have certain hiding spots good for a certain number of blasts while the player was figuring out where to shoot.)
-
It’s up to you how heavily you want to hint at the weak spot on the dragon – making it a matter of trial and error might be the most fun option – but there are a few caveats. Most importantly: the weak spot needs to be a body part a reasonable person would think of a dragon as having (eyes/wings/tail as opposed to clavicle/sternum/islets of Langerhans) or be hinted at elsewhere.
You could make this a two-stage process where the player had to think of parts of a dragon to examine and the game said things like “The scales over its Achilles heel seem more like feathers.” If you’re going to do this, X DRAGON needs to hint that examining specific parts of the dragon would yield better results.
- You’ll also need to hint that it is possible to aim for specific parts of the dragon. This is pretty easily done by having SHOOT DRAGON by itself say something like “You fire off an arrow without bothering to aim. It hits the dragon in the left bicep and bounces harmlessly off of its thick scales.”
People are used to dragons having weak spots (thanks, Bilbo!) so your failure message for shooting the dragon anywhere else doesn’t need to be too heavy-handed. You should still be careful not to mislead the player – it’s possible they’ll think they need to upgrade their arrows – so throwing in phrases like “The scales in its armpit seem even thicker than the scales on its bicep” might be helpful.
- Step 1 towards solving this puzzle involves knowing that the bow exists at all. By the time they reach this puzzle, the player should own the bow, have seen the bow, or at the very least have heard rumors of the bow’s existence.
What not to do: make the player gather ingredients from all over the game, use an unhinted command to make them into a sandwich, give that sandwich to a hungry troll at the bottom of the cistern in a disused lavatory, and be rewarded – out of the blue! – with a bow. This is an example of a thing that is terrible.
(If you want, you can plant the seed that the player needs to find/make a bow by upping the hints about the weak spot on the dragon. You can also put little rocks on the ground for the player to try throwing, then hint that they need something with more range. The more you hint that a bow is the correct tool for the job, the more out of the way you can put it, provided you leave some hints about how to obtain it.)
- As much as you are able, you need to shut down or implement any reasonable solution to the dragon bridge puzzle. If a longbow works but a crossbow doesn’t, state the reason why – and recognize this as an opportunity to nudge the player towards the longbow.
If there is a sack of gold coins in the game, the response to GIVE GOLD TO DRAGON should indicate that the dragon can’t be bribed – this is another opportunity to hint towards the correct solution. Trying to put out the fire, likewise, and so on. Testing is hugely helpful for this.
- Remember that players will continue to think of your world as you have trained them to think about it. If the bulk of your puzzles have been solved by negotiating with complex NPCs, that’s very likely what they’ll try to do with this dragon. (At this point you should probably ask yourself why you’re including this puzzle in a game that is has largely been about communication and negotiation, and whether or not it would work better in a different game, but it’s your call.)
You may decide you want your world model to include a range of systems and mechanics. You have a couple options here:
a) Tie your systems together if possible; consistently include multiple mechanics in your puzzle solutions from the very beginning. For example, getting past a kobold might require you to scout for crafting ingredients, barter with an NPC for an axe recipe, successfully complete the crafting (which in my head is a VERY finicky turn-based system, let me tell you), and then go kill the kobold. (Ideally in this world you would also have the option of bartering with the kobold and killing the NPC.)
b) Keep 'em separated: Provide very clear contexts in which a given mechanic will work. Maybe all of your physics-based puzzles take place in dwarven ruins and all of your kissing simulations take place in dwarven dreams that you have entered via 15-puzzles.
Actually now that I’m reading A & B here I’m not sure how different they are. The point is that you should provide the full range of your game’s scope up front, at least in small ways. If you want it to be a surprise – and I can think of plenty of games that introduce new mechanics halfway or later – clue the player that they need to re-adjust their thinking, and provide hints.
I’m going to hit post on this before I become a skeleton. Hopefully some of it is useful!