Locks, Keys and Shortcuts: Designing an Ability-Gated Map That Never Softlocks

A tester spends forty minutes circling the same flooded basement. The exit needs a dash. The dash pickup is on the far side of a gap that needs the dash. Nobody on the team noticed, because the level artist who built the basement and the designer who placed the dash were working in different files, two weeks apart.

That is not a bug in the usual sense. Nothing crashed, no value was wrong. The shape of the world was wrong, and shape is the one thing a blockout pass does not catch — you can walk every room in a greybox and still miss that the graph connecting those rooms has a cycle in it.

Ability-gated maps — Metroidvanias, Zelda-style dungeons, hub-based action games, even a linear game with a few backtracking loops — need their own design artifact: a gate graph, written before the geometry, audited on purpose. Here is how to build and check one.

What a gate actually is

Four kinds, and they behave very differently under playtest:

Gate type	Opened by	Example	Main risk
Ability gate	A permanent verb (double jump, bomb, grapple)	Metroid's bombable blocks; Hollow Knight's Mantis Claw walls	Circular dependencies; players forget they have the verb
Knowledge gate	Information the player holds, not the avatar	Outer Wilds' coordinates; a door code written on a wall	Unfalsifiable progress — you cannot tell if they know
Key gate	A consumable or carried item	Zelda small keys; a keycard	Spending the key on the wrong door
Soft gate	Skill, damage, or resource pressure	A high-damage enemy guarding an optional area	Reads as a wall, not a choice; blocks the wrong players

Most stuck-player reports come from mixing these without noticing. An ability gate that is also a soft gate ("you need the grapple, and also 40 seconds of precise platforming") produces two different failure feelings that look identical in a bug report: "I can't get past the bridge."

Pick one primary gate type per boundary and write down which it is. That single annotation resolves half the arguments you would otherwise have in review.

Write the graph before the rooms

A gate graph is boring on purpose. Regions are nodes, requirements are edges:

Harbour        -> (none)        -> Market
Market         -> (dash)        -> Flooded Basement
Market         -> (none)        -> Clocktower Base
Clocktower Base-> (hookshot)    -> Clocktower Top
Flooded Basement -> (none)      -> Pump Room      [grants hookshot]
Clocktower Top -> (none)        -> Market         [one-way drop, shortcut]

Grants go in square brackets. Now the dash/hookshot ordering is visible in six lines: the hookshot lives behind a dash gate, so dash must be obtainable from Harbour or Market with no abilities at all. If it is not, you have the flooded-basement bug, on paper, in week one.

In GameDesignerX this lives naturally across two modules — one entry per region in Locations, with the required verb from Mechanics recorded on each connection — so the person blocking out Clocktower Top can see that the only intended entrance assumes a hookshot the player may not own yet.

The reachability pass

Do this by hand for anything under ~20 regions; it takes ten minutes and finds real problems.

1. Start with an empty ability set and the starting region.
2. Mark every region reachable with the current set.
3. Collect every grant inside those regions; add them to the set.
4. Repeat from step 2 until nothing new becomes reachable.
5. Any region left unmarked is unreachable from a cold start.

Run it a second time pretending each ability is not granted — if removing one ability orphans four regions, that ability is a single point of failure for a third of your map, and losing or missing it (a skipped pickup, a reset save) strands the player.

For bigger maps, the same five steps are twenty lines of script over a CSV export of your region table. Worth writing once; it becomes a CI check that fails when someone adds a gate without a key.

Numbers worth deciding up front

These are starting budgets, not laws. Pick values, write them next to the graph, and change them deliberately after testing rather than drifting.

• Tease distance: show the lock within the first 1–2 minutes of a region, grant the key within one region of it. A lock the player meets three hours before the key reads as a dead end, not a promise.
• Backtrack cost: no more than 60–90 seconds of travel from a new ability to the nearest lock it opens. Measure it by walking the blockout with a stopwatch, not by map distance.
• Open questions: at most 2–3 unresolved locks visible to a new player at once. Beyond that, "where do I go" becomes the dominant thought, and it never returns to your pacing curve.
• Shortcut density: one new shortcut (ladder, unlocked door, one-way drop that lands somewhere useful) per region, placed to cut the second traversal of that region roughly in half.
• Dead-end depth: optional branches of 2–3 rooms maximum before a reward. Deeper than that and the branch needs its own tease.

The shortcut rule is the one teams skip and regret. Backtracking is not inherently bad — recognising a room and crossing it in fifteen seconds instead of ninety is one of the genre's best feelings — but that only works if someone budgeted the shortcut as content.

The softlock audit

Run this list against every region before it leaves blockout. Each item is a real failure pattern, not a hypothetical.

• One-way geometry: every drop, slide and collapsing floor has a return path that needs only abilities obtainable below it.
• Consumables: if keys or bombs can run out, either make them respawn, or prove by graph that no door requires a key the player can waste.
• Respawn position: death inside a gated area returns the player somewhere they can still leave from.
• Save-on-enter: a save or autosave inside a one-way area cannot become the only save slot.
• Scripted doors: anything a cutscene or quest flag closes has a written reopen condition.
• NPC dependencies: a gate opened by a character the player can kill, miss or outpace has a fallback.
• Item loss: no quest item can be sold, dropped into a pit, or deleted by inventory limits.
• Sequence breaks: state explicitly whether skipping a gate (clipping, a clever jump) is tolerated; if yes, every downstream gate must not assume the skipped ability.

That last one is a design decision, not a QA task. Deciding "sequence breaks are allowed and must never strand the player" is cheap at graph stage and expensive after you have scripted thirty doors.

Testing the graph, not just the rooms

Two instruments tell you almost everything:

1. Region enter/exit timestamps. Time-between-gates is your real difficulty signal. A median of four minutes with a long tail at twenty-five means a small group is lost, not that the room is hard.
2. Re-entry counts. A region entered six times without any gate being opened in between is a navigation failure. Players are searching, and they are searching in the wrong place because something teased a lock you did not place.

In sessions, resist answering "where do I go". Note the timestamp, let them wander two more minutes, and write down what they tried. The order they try things in is your signposting review, free.

Do this week

Export your regions to a table. Write one line per connection with its required verb and any grant. Run the five-step reachability pass cold. Walk the two longest backtracks with a stopwatch. Then fix the one gate the pass flagged — there is almost always exactly one — and keep the table next to your blockout from now on, because the next person to add a door will not have read this conversation.