Chapter 14 Exercises: Curiosity, Exploration, and the Pull of the Unknown

These exercises are designed to be done in sequence. The first few are analytical — you will study existing games to develop your eye for curiosity design. The middle exercises are practical implementation work in your prototype. The final exercises require you to step back and audit your design choices against the principles in this chapter.

You should expect to spend roughly 8 to 12 hours total across all exercises. Some are quick (twenty minutes); others (the implementation work) may take an evening each.

Exercise 1: The Sightline Audit (Analysis, 30-45 minutes)

Pick a 3D open-world or large-environment game you know well. Boot it up. Choose a single location — a hilltop, a tower, a vista, a doorway. Stand there and slowly rotate the camera 360 degrees.

For every distinct landmark visible from that point, note:

  • What it looks like (a one-sentence description of its silhouette).
  • How far away it appears.
  • Whether you can identify it by name or function.
  • Whether you have ever visited it.
  • Whether the camera, terrain, or lighting deliberately drew your eye toward it.

Then move 50-100 meters and repeat the exercise.

After two or three vantage points, write a short reflection (300-500 words) analyzing what the designer did well and where they failed. Pay particular attention to landmarks that you can identify by silhouette alone versus landmarks that require getting close. Pay attention to whether the world's curiosity load felt high (you wanted to go everywhere) or low (you found yourself wandering aimlessly).

🎮 Play This: If you do not have a 3D open-world game on hand, this exercise also works in 2D. Hollow Knight, Hyper Light Drifter, or any Metroidvania will give you sightline-equivalent compositions through screen layout and silhouette.

Exercise 2: Map a Curiosity Loop (Analysis, 30 minutes)

Choose a moment in a game you have played where you remember being intensely pulled to investigate something. It might be a distant tower, a mysterious cave, an unexplained phenomenon, an environmental story.

Map the experience using the four-phase loop from Section 14.10:

  1. Notice. What was the first cue that drew your attention? Visual, auditory, structural?
  2. Approach. What was the journey toward the thing like? Was it long? Were there obstacles? Did the thing become more or less mysterious as you got closer?
  3. Discover. What did you find when you arrived? Was the discovery satisfying, anticlimactic, or surprising?
  4. Understand. Did you grasp the meaning of what you found? Was there context that made it click into place?

Write up your map (one page). Then identify which phase was the most carefully designed, and which phase the designer might have left under-developed. Most games are stronger in some phases than others.

Exercise 3: Three Hidden Areas, Three Tells (Design, 60 minutes)

You will design — on paper, no implementation yet — three hidden areas for your prototype. Each must use a different kind of tell from the list in Section 14.11:

  • Hidden Area A uses a visual tell. A texture difference, a slight crack, a misaligned tile.
  • Hidden Area B uses an auditory tell. A faint sound, a wind whistling through a wall, a rumble.
  • Hidden Area C uses a structural tell. A geometry pattern that breaks the convention of the surrounding level.

For each area, write a half-page description containing:

  • The exact location in your prototype.
  • The tell (what the curious player will notice).
  • The specific cost of investigation (time, risk, etc.).
  • The reward (what they find).
  • The relationship between the reward and the rest of the game (does this matter? does it just exist? does it open a new question?).

Compare the three. Which one are you most confident a player would find without help? Which would only the most attentive 5% find? Both extremes are valid for different design purposes.

Exercise 4: Implement the Secret Area System (Implementation, 90-150 minutes)

In your prototype, implement the SecretArea.gd pattern from Section 14.11. Use Hidden Area A from Exercise 3 (the visual tell).

Tasks:

  1. Create the destructible wall mesh and place it in your level.
  2. Attach the script. Configure reveal_emission to a value you think is right.
  3. Place a meaningful piece of loot or content behind the wall.
  4. Connect your existing player damage system to the wall (so the player can break it).
  5. Playtest with at least two people who have not seen your level. Watch — do not narrate.

For each playtester, record:

  • Did they notice the wall was different?
  • If they noticed, did they try to break it?
  • If they broke it, did the discovery feel rewarding?

Adjust reveal_emission based on what you observed. If both testers missed it, raise the value. If both testers immediately recognized the wall as breakable, lower it. The right value is one where one of two testers notices on their first pass.

Exercise 5: Implement a Sightline (Implementation, 60-90 minutes)

In your prototype, implement the Sightline.gd pattern from Section 14.4. Choose a transition point — a hilltop, a doorway, a corridor exit — where you want the player to first see a distant landmark.

Tasks:

  1. Place the trigger volume at the transition point.
  2. Designate the target_node (your distant landmark — it must already exist in the world).
  3. Tune pan_duration and hold_duration to feel deliberate but not intrusive.
  4. Playtest. Does the camera move feel natural? Does it actually highlight the landmark, or does it land off-center?

Variation: implement a subtle version. Instead of a forced camera pan, use a particle effect, a sound cue, or a bird flying past in the direction of the landmark. Compare the two versions in playtesting. Which one was more effective at directing player attention? Which one felt more respectful of the player's autonomy?

Exercise 6: Map Your Prototype's Information Gaps (Audit, 60-90 minutes)

This exercise is one of the most important in the chapter. Take a top-down view of your prototype's level (in the editor). On a printed copy or a digital overlay, mark every existing information gap:

  • Doors the player cannot yet open (red).
  • Areas visible but not yet reachable (orange).
  • Hidden areas with tells (yellow).
  • Sightlines that point at distant landmarks (green).
  • Environmental storytelling moments (blue).

Step back from the marked map and look at the density. Are there long stretches of level with no marks? Those are curiosity deserts — places where the player has nothing pulling them forward. Are there places with too many marks too close together? Those are curiosity overload — the player will not be able to track all the gaps and will dismiss them.

Adjust your level to redistribute the marks. Aim for a steady density: roughly one or two information gaps in any region the player can see at once.

Exercise 7: The Visible-but-Unreachable Promise (Design, 45 minutes)

Add to your prototype one element that is visible but not currently reachable by the player. Examples:

  • A high ledge with a treasure chest on it (no way up yet).
  • A door across a chasm (no bridge yet).
  • A glowing object inside a cage (no key yet).

Document, in your design notes:

  • When in the game's progression will this become reachable?
  • What ability or item will allow the player to reach it?
  • What is the reward?

The discipline here is that you must follow through. Do not add a visible-but-unreachable element you do not yet know how to deliver on. The contract with the player is that what they can see, they can eventually reach. Plan the resolution before you add the gap.

⚠️ Common Pitfall: Don't add five unreachable elements at once. Start with one. Master the technique. Add more in later chapters.

Exercise 8: Environmental Storytelling Scene (Design + Implementation, 90 minutes)

Design and build one environmental storytelling scene in your prototype. Follow the rules from Section 14.6:

  • Single primary event implied.
  • Readable from any approach.
  • Question implied, not stated.
  • No confirmation note explaining what happened.

The scene should be small — a single room or a small outdoor area, no more than 30 seconds of player time to take in.

Example seeds (use these or invent your own):

  • A campsite that looks suddenly abandoned. A pot of food still simmering. A bedroll tossed aside. Tracks leading away into the forest.
  • A workshop with tools mid-use. A half-finished item on the bench. A diagram on the wall showing something the workshop is too small to contain.
  • A road blocked by an overturned cart. Spilled cargo of an unusual kind. No sign of the people who were transporting it.

After implementation, ask three playtesters separately to describe what they think happened in the scene. Compare their answers. If they all give the same story, your scene is too obvious. If they all give different stories, your scene is working — players are constructing personal narratives. If they all shrug and say "I dunno, just some stuff," your scene is too vague — there is not enough evidence to formulate a question.

Exercise 9: Compare a Curated and a Procedural World (Analysis, 60 minutes)

Play (or revisit) two open-world games of comparable scale: one hand-curated, one procedurally generated. Suggested pairings:

  • Breath of the Wild vs. No Man's Sky
  • Skyrim vs. Daggerfall
  • Red Dead Redemption 2 vs. Minecraft (in survival mode)

Spend 30 minutes in each. Then write a short reflection (400-600 words) addressing:

  • In which game did you find yourself wanting to walk further?
  • In which game did you start ignoring the environment?
  • What specifically about each game generated or failed to generate curiosity?
  • Were there moments where the procedural game did generate curiosity? Where the curated game failed to?

The point is not to argue that curated is always better. It is to develop your eye for what makes specific moments of exploration land or fall flat.

Exercise 10: Exploration-Exploitation Levers (Audit, 30 minutes)

For your prototype, list every economic incentive you have built in. Examples:

  • Resources the player can gather.
  • Enemies that drop loot.
  • Vendors who sell items.
  • Quests with rewards.
  • Crafting systems with material requirements.

For each, ask: does this push the player toward exploitation (do this thing repeatedly) or exploration (try new things)?

If most or all of your incentives push toward exploitation, your players will optimize and stop exploring, even if your world is beautiful. Identify two incentives you can rebalance to push toward exploration instead. Examples:

  • Gathering nodes that respawn slowly (so farming becomes inefficient).
  • Loot tables that are region-specific (so new regions yield new items).
  • Quest rewards that include map information rather than just gold.

You do not need to implement these yet. Just identify them, and write a short note about how you could change each one.

Exercise 11: The Curiosity Kill (Audit, 30 minutes)

Look at your prototype with one specific question: where am I currently killing curiosity?

Common curiosity-killers:

  • Quest markers that point at every objective (no gap to close — the game already told you).
  • Auto-revealed maps (no exploration value).
  • Rewards that are repetitive across all locations (the gap collapses to "more of the same").
  • Forced tutorial sequences that override player intention (the player wanted to explore, but the game made them stop).
  • Punishment for off-path exploration (invisible walls, instant-death zones at the edge of intended paths).

List every curiosity-killer in your prototype. For each, write whether you think it should be removed, modified, or kept (some are necessary — total absence of guidance creates its own problems).

Exercise 12: Reflection (Writing, 30 minutes)

Write a one-page personal reflection on this chapter's central question: do you trust your player's curiosity?

A designer who does not trust the player will pile on quest markers, force tutorials, lock the player onto rails, and explain everything. A designer who trusts the player will leave gaps, will let the player wander, will allow some confusion. Both approaches have costs and benefits.

Where do you sit on this spectrum, honestly? Why? Is your default toward control (because you fear the player will get lost or bored) or toward freedom (because you fear the player will feel manipulated)? How does that default show up in your prototype? Is it the right default for your specific game, or are you defaulting out of habit rather than design intent?

This exercise has no correct answer. It exists because most designers never explicitly ask themselves where they sit on this spectrum, and the unexamined default tends to creep into every decision they make. Naming it is the first step to choosing it deliberately.