Author Game Levels

Author Game Levels

Treat architecture as gameplay communication. Every route, arena, gate, prop, and light must help the player read movement, threats, objectives, or state.

Enforce one gameplay plane

Keep all collision, navigation, encounter routes, objectives, pickups, and player movement on one accessible plane.

• Do not add stairs, ramps, raised platforms, drop-offs, cliffs, bridges, ledges, pits, or vertical traversal.
• Do not change gameplay elevation for shortcuts, arenas, hazards, rewards, or visual variety.
• If visual height is requested later, keep it non-walkable background dressing. It must not alter navigation, camera occlusion, threat visibility, targetability, or player movement.

Separate level systems

Maintain explicit, independently testable layers for:

• authored level data and stable zone/anchor IDs;
• visual geometry and non-walkable background dressing;
• simplified collision geometry;
• flat navigation data and movement clearance;
• encounter, enemy, gate, reset, pickup, objective, and exit zones.

Share stable IDs and transforms between layers, but never infer collision, navigation, or encounter boundaries from decoration alone.

Lay out readable play

1. Define the architectural purpose of each space: traversal, orientation, combat, recovery, reward, transition, or objective.
2. Preserve clear movement, camera, and dodge corridors at the intended play distance.
3. Keep threats, pickups, exits, gates, and interaction targets visible before commitment.
4. Telegraph encounters through visible arena shape, approach, state change, and stable zone anchors.
5. Deliberately place arenas, gates, checkpoints, retry spawns, and reset paths. Prevent soft locks, duplicate rewards, hidden re-entry, and enemies pursuing through unrelated zones.
6. Use landmarks, lighting, contrast, and composition to guide without hiding hazards or making the route ambiguous.

Motivate every local light

Attach every local torch, lantern, brazier, or similar light spatially to a visible emitter. Its position, range, color, intensity, shadowing, and occlusion behavior must match what that emitter appears able to produce.

• Forbid unexplained floating local lights.
• Keep a source-to-light inventory with emitter ID, light ID, attachment transform, type, range, color/intensity, occlusion intent, enabled state, and fallback behavior.
• Move the light with a moving emitter. Disable or remove its local contribution when the emitter is disabled, hidden, destroyed, or unloaded.