Game Level Designer Specialist

Illustrative preview: this representative editorial result is not a recorded runtime session.

Make the gate an intelligible shortcut dependency while preserving a complete open route. Do not place an invented key; the gate mechanism is still an owner decision.

Level packet GREENHOUSE-L01 v1
Status: COMPLETE_LOCAL for topology/specification; locked-gate integration NEEDS_DECISION, traversal/player checks NOT_RUN.
Producer: Game Level Designer Specialist. Recipient: level implementation owner.
Purpose: let the player recognize a short gated connection and choose the longer traversable route under settled walk-only rules.
Confirmed: A(0,0), E(12,8), speed 2 units/s, collider width 1, no jump. Coordinates below and corridor widths are proposed.

Graph: A→B→C→E is the short route, conditional on the actual gate rule. A→B→D→D2→E is the always-open topology. Make both route beginnings visible from B in the implementation; sightline/camera verification remains pending. A named locked-gate cue explains why the direct path stops without telling the player a nonexistent unlocking action.

Measurement basis
Short route: A→B 4 + B→C 8 + C→E 8 = 20 units; ideal movement 20/2 = 10 seconds if the gate is open.
Open route: A→B 4 + B→D 12 + D→D2 8 + D2→E 4 = 28 units; ideal movement 28/2 = 14 seconds.
Difference: eight world units and four ideal movement seconds. These are axis-aligned centerline calculations, not observed completion times. Corners, collision, pauses, gate interaction and camera behavior are excluded.
Proposed corridor clear width: two units for the one-unit collider; that nominal margin does not certify actual collider/corner clearance. Use real collision geometry, not just centerlines, in the candidate.

Entry, checkpoint and recovery proposals
At new-room entry, put the player at A in the confirmed movement state. Proposed checkpoint stays A so retry preserves the meaningful route decision. If the game's existing failure rule requires restart, return to A and restore room state according to the accepted save/reset contract; no hazard or failure is newly added here. Completing at E emits one exit event, not repeated progression rewards. Exact exit trigger bounds and gate reset/persistence are integration decisions.

Dependencies
GH-D1 gate owner specifies prerequisites, interaction/denial and opened-state persistence. Until resolved, implement the open route and represent the locked shortcut without claiming it is completable.
GH-D2 camera owner supplies viewport/follow behavior; then check visibility of the B choice, gate information and exit cue.
GH-D3 implementer supplies actual collider/solid geometry and exit event semantics.

Criteria GH-AC1–5: traverse the open route using actual walk controls without jump; closed gate blocks only its shortcut; confirmed opening unlocks that shortcut without invalidating the open route; one exit completion and ratified checkpoint/retry state survive repeated entry; decision and gate cues are perceivable in the actual camera. All runtime checks NOT_RUN.
Playtest question: do players recognize the shortcut as a bounded gate, choose a route and recover without mistaking a locked route for an absent movement verb? Record route choice, stalls and interventions on a versioned build, rather than interpreting the 10/14-second model as pacing proof. Next action: settle GH-D1–3 and create the bounded blockout.