07b Game Level Design

07b — Design game spaces

Follow the protocol, including its source-loading rules. Inputs through profile.sources: baseline, action/movement rules, camera or viewing method, content, narrative/onboarding 07a, UX, art, audio, and known technical constraints. The project registry defines scope; there is no fixed region count.

Select applicable modes: authored spaces/levels; boards, puzzles, or other discrete topology; procedural generation; or combinations. Space without physical movement may still require an exact state and cell layout. If gameplay is entirely nonspatial, justify N_A. Screen interfaces remain with UX and do not need a fictitious level design document (LDD).

1. Derive spatial metrics from rules. For physical spaces, include dimensions, speeds, trajectories, camera, interactions, allowed bodies, and carried objects. For boards, include grid, adjacency, orientation, move ranges, and placement. Make units, scale, origin/axes, height, or layer ordering explicit where applicable. Unknown values need owners and hypothesis status; typical corridor dimensions do not replace this game's rule dependencies.
2. Give every authored unit a connected package: a substantive LDD or equivalent, readable plan, and structured placements/topology in a suitable project format. Dimensioned SVG and JSON may be useful but are not required when an equivalent format exists. Define purpose, experience, entry/start, exit/completion, adjacency, required and optional actions, landmarks, constraints, and revisit/reset behavior. Every required unit needs a package, not just a showcase level.
3. Placement records need a unique ID, entity reference or geometry purpose, coordinate/cell/node, dimensions or occupied cells, orientation where needed, state conditions, and sources. Connections need direction, access, constraints, and relevant cost/length. Plans use the same IDs, scale/grid, legend, dimensional limits, and viewing constraints. Assign one owner to each value and describe synchronization of derived representations. Decorative images do not define gameplay geometry.
4. For procedural generation, define families, grammar/rules, inputs and ranges, required elements, forbidden combinations, module connection rules, reachability/solvability, distributions, budgets, and rejected-result handling. Where the product requires it, specify reproducibility and generator-version/seed compatibility, retry limits, and a defined fallback. Include documented examples, counterexamples, boundary cases, and a future validation plan. Do not enumerate every possible world or present a finite sample as proof of all outputs.
5. Specify encounters and tasks without assuming combat: goal, activation, permitted participants, positions/areas, phases, completion, reset, and recovery. Puzzles need rules, solution conditions, dead ends, hints, and permitted multiple solutions; combat needs threats, cover, sightlines, and resources; competition needs starts, objectives, asymmetry, routes, and geometry exploits. Use only applicable branches.
6. Check reachability and return paths against access conditions, body/object volumes, and state changes. Graph connectivity is insufficient when gates, jumps, move limits, or impassable gaps matter. Connect learning, orientation, workload pacing, visibility, sound, accessibility, boundaries, and reusable environment kits. For 3D spaces, account for vertical transitions and coordinate seams; for boards, boundaries and invalid configurations.
7. If a sequence consumes limited resources, send ordered routes/moves with IDs to the owner of 07: entry → costs/replenishment → exit/recovery, including permitted bypasses and unfavorable allowed states. Canonical formulas remain in the calculation specification. Repeat 07 after spatial detail and before 07c for affected routes. If resources do not affect space, record why this calculation is inapplicable.
8. Define future acceptance for the blockout, board, or generator: routes/solutions, required states, impossible placements, information readability, recovery, and measurable constraints. Address production kits, module joins, and complexity budgets through 10a. D0 does not require a scene, working generator, or game prototype.

When repeatable worlds, replays, or resuming procedural state are required, define the reproducibility contract with the architecture owner. A seed without a version and other material inputs does not determine the result.

For irreversible transitions, use the same reference to define information available before action, affected content, and intended recovery or deliberate surprise. Route connectivity alone does not establish these properties.

Output: all applicable spatial packages and a registry of their sources, geometry/topology, placements, constraints, and open questions. View every image in a package; label errors and overlaps can hide structural defects. Apply the visual review rules to images, including plans and art references. An art reference does not replace a dimensioned or topological plan.

Independent 07c is required after authoring. Then update 05, 04, and affected art/production documents. The package must support construction without guessing essential decisions. A paper plan does not establish comfort, solvability of all generated results, or performance.