How Do You Provide Clues for Players?

Authoring General Design Discussions
1

I’ve designed a couple of puzzles which, I worry, might be a bit difficult for players to figure out. So, I searched the Internet for advice on cluing in games and found … not much.

There’s a thread on rec.arts.int-fiction listing 32 different reasons a player can get stuck.

And there’s a dictionary of computer game elements at a Japanese university which has an entry on clues. This one says there are five ways to provide information to the player about how to complete a goal in a video game:

  1. Use a Status Indicator (a device which indicates that the player did something which has either helped or hurt his progress).
  2. Use a Near Miss Indicator (an event which indicates that the player just did something that almost helped or hurt his progress).
  3. Provide a Helper (a character who says or does things which provide clues to the player).
  4. Provide Traces (evidence that something happened in the environment which provides clues to the player).
  5. Provide an Outstanding Feature (a noticeable part of the environment which provides clues to the player).

This is helpful, but a little vague. Has this been discussed around here (or elsewhere)? Does anyone have any advice?

Am I worrying about something I shouldn’t, because, perhaps, IF players are universally relentless and will figure it out regardless?

2

I think this is absolutely worth worrying about. Lack of direction and “psychic author” puzzles are no fun for the player.

The list you provided is a good starting point. Here are a few more recommendations off the top of my head.

  • Make sure the existence of your puzzle is clear. “I thought the whangdoodle was a permanent part of the shelf, so I never even tried to get it” is a serious problem if getting the whangdoodle is necessary for progress.

  • Consider your puzzle in the context of the game world. How did it come into being? How does it affect the world around it? This will often lead to ideas for good clues. For example, if there’s a secret door in the library, then the book used to trigger the door might be more worn than the others nearby, or there might be a scrape mark on the carpet.

  • Think about what the player might try that isn’t right, and give them lots of clear feedback including not just “this didn’t work” but why it didn’t work. A classic example is in Colossal Cave Adventure, where prying the bivalve with anything but the trident will produce a message that you need something stronger to get it open.

  • Look for possible alternate solutions to your puzzle, and then either implement them or shut them down. (This is less a clue recommendation and more a good puzzle design note.)

In all cases, playtest a lot! After all, only your players can tell you whether a puzzle is sufficiently cued.

1 Like
3

After rereading this, I want to give Grodjejog the God of Tablecloths his own game someday.

4

Bob Bates’s Designing the Puzzle had a very small section on “Steering the Player”.

There’s also the “Guidance” section of IF Gems.

5

:open_mouth:

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:

  1. 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.)

  2. 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.

  1. 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.)

  2. 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.)

  3. 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.

  1. 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.

  1. 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.)

  1. 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.

  1. 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!

6

All of Jenni’s reply is excellent, but I especially want to call out

Sometimes the way to make a difficult game easier is to add more puzzles to it – easier, set-up puzzles in the first portion of the game that will serve as training for what comes later on. A lot of the design for Counterfeit Monkey consisted of me thinking of difficult things the player could do, and then working backwards and providing some prior puzzles that familiarized the player with tools or objects that were going to come into a late-game puzzle.

A couple of other thoughts:

– Another approach is to add graduated messages for players that give stronger and stronger clues about what they ought to be doing. If they’re trying to interact with an object but they do it wrong several times in a row, you can put in a response that triggers with some extra information. This is a technique to apply gently – you don’t want to create a puzzle game that’s constantly solving itself just before the player has had a chance to come up with the right answer – but it does come in handy if you have strong pacing goals for a particular puzzle. E.g., in a key boss monster fight, it’s probably more fun if the player gets some stronger hints just before the timer runs out, and thus has a chance to pull out a late victory, than if the player has to play that same scene over and over again.

A variant on that is the more-information-on-loss strategy: if there’s a puzzle sequence that can definitively fail, or the whole game can end if the player doesn’t solve something, then it can help if the failure state at least gives some extra information about why it went wrong. Ideally the player then thinks, “ah, I have something else to try” and immediately replays, rather than thinking “ugh, I can’t get past this” and going off to play something easier.

– Blue Lacuna and City of Secrets also both do a thing where if the player hasn’t noticed something important (visited a particular location in a large map for too many turns after it becomes available, e.g.), a little vignette triggers that points it out. In BL, if I recall correctly, there’s an animal that turns up and takes the exit that the player hasn’t yet explored.

– This one is more a process thing than a game feature thing, but I also get a lot out of back-and-forth conversations with my beta-testers about why they had trouble with the things they had trouble with. In Savoir-Faire, there’s a bit where the player is expected to notice that a certain object is about the same size as the cork from a wine bottle. In my description of this object, I’d described it as being roughly the length of the protagonist’s thumb – because my thumb is not that much longer than a wine bottle cork, at least if you measure from the bottom knuckle where it separates from the rest of my hand. For a player with significantly bigger hands, though, the visualization came out quite differently, and therefore they weren’t making the connection at all.

This is a case where probably I should’ve been able to anticipate that it was foolish to connect a key measurement with something as variable as body part length, but in practice I find a lot of confusion comes from things where the author has a very specific idea of the layout of a room or the objects in it, and the player is for whatever reason picking up quite a different one. If you can sort out where the miscommunication is happening, often all that’s needed is a refinement of the descriptive text.

7

Yep. I was hopelessly stuck because I’d overlooked an exit, then I saw an animal going that way, and I went, “Hey, there’s an exit down that way?!”.

8

Emily’s “train the player with a small version of the larger puzzle” is great.

Also another way to clue is to show another entity solving the puzzle. If I have a door that won’t let me through, but an endless parade of blue aliens walks through the door with no problem, I’m going to trek back to that room that had cans of blue spray paint that seemed useless at the time.

9

If you have a systemic mechanic, I think Portal is actually an object lesson in player education. Very systematically it introduces a problem space, then uses that problem space to build on previously-mastered skills, again and again. Each puzzle is also acting as a clue for the next puzzle, starting with the very first player interactions that might not even be considered “puzzles.” Forcing the player to interact with something in a mundane, obvious way is often a good step to suggesting that it can be interacted with in a puzzle-solving context.

10

Thanks, everyone. That should help.