@jgengine/shell 0.11.0 → 0.13.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +52 -0
- package/dist/CombatPresentation.d.ts +5 -0
- package/dist/CombatPresentation.js +8 -0
- package/dist/GameHost.d.ts +27 -1
- package/dist/GameHost.js +83 -4
- package/dist/GamePlayer.d.ts +5 -0
- package/dist/GamePlayer.js +5 -0
- package/dist/GamePlayerShell.d.ts +5 -0
- package/dist/GamePlayerShell.js +63 -359
- package/dist/GameUiPreview.js +3 -0
- package/dist/Shell3dPresentation.d.ts +63 -0
- package/dist/Shell3dPresentation.js +302 -0
- package/dist/ShellChrome.d.ts +51 -0
- package/dist/ShellChrome.js +51 -0
- package/dist/ShellHudPresentation.d.ts +41 -0
- package/dist/ShellHudPresentation.js +22 -0
- package/dist/audio/audioEngine.d.ts +4 -0
- package/dist/audio/audioEngine.js +111 -26
- package/dist/audio/audioWire.d.ts +22 -4
- package/dist/audio/audioWire.js +46 -3
- package/dist/audio/loopParams.d.ts +20 -0
- package/dist/audio/loopParams.js +28 -0
- package/dist/camera/GameCameraRig.js +6 -1
- package/dist/camera/GameOrbitCamera.js +7 -1
- package/dist/camera/cameraCollision.d.ts +28 -0
- package/dist/camera/cameraCollision.js +34 -0
- package/dist/camera/cameraRigs.d.ts +3 -1
- package/dist/camera/cameraRigs.js +24 -10
- package/dist/camera/index.d.ts +1 -0
- package/dist/camera/index.js +1 -0
- package/dist/camera/rigMath.d.ts +27 -0
- package/dist/camera/rigMath.js +45 -0
- package/dist/defineGame.d.ts +15 -1
- package/dist/defineGame.js +26 -4
- package/dist/devtools/DevtoolsOverlay.d.ts +4 -4
- package/dist/devtools/DevtoolsOverlay.js +28 -12
- package/dist/devtools/agentBridge.js +4 -0
- package/dist/devtools/perfDiagnose.js +1 -1
- package/dist/diagnostics/RuntimeDiagnostics.d.ts +7 -0
- package/dist/diagnostics/RuntimeDiagnostics.js +23 -12
- package/dist/environment/EnvironmentScene.js +17 -3
- package/dist/environment/RoadJunctions.d.ts +12 -0
- package/dist/environment/RoadJunctions.js +69 -0
- package/dist/environment/RoadRibbons.d.ts +8 -2
- package/dist/environment/RoadRibbons.js +26 -8
- package/dist/environment/terrainGroundColor.d.ts +9 -0
- package/dist/environment/terrainGroundColor.js +22 -0
- package/dist/gameKit.d.ts +27 -0
- package/dist/gameKit.js +29 -0
- package/dist/map/MapMarkerBeacons.d.ts +3 -2
- package/dist/postfx/PostProcessing.d.ts +9 -1
- package/dist/postfx/PostProcessing.js +11 -4
- package/dist/presentationResolve.d.ts +39 -0
- package/dist/presentationResolve.js +53 -0
- package/dist/registry.d.ts +1 -0
- package/dist/render/PartMotion.d.ts +18 -0
- package/dist/render/PartMotion.js +91 -0
- package/dist/render/SceneModels.d.ts +9 -2
- package/dist/render/SceneModels.js +31 -180
- package/dist/render/assetBase.d.ts +17 -0
- package/dist/render/assetBase.js +35 -0
- package/dist/render/measureBounds.d.ts +34 -0
- package/dist/render/measureBounds.js +127 -0
- package/dist/render/modelLoad.js +4 -1
- package/dist/render/resolveModel.d.ts +15 -0
- package/dist/render/resolveModel.js +43 -2
- package/dist/render/useModelAnimation.d.ts +10 -0
- package/dist/render/useModelAnimation.js +198 -0
- package/dist/scatter/InstancedScatter.js +5 -0
- package/dist/scatter/scatterProxies.js +24 -0
- package/dist/scene/AuthoredScene.d.ts +3 -1
- package/dist/scene/AuthoredScene.js +7 -2
- package/dist/scene/CityRenderer.d.ts +2 -0
- package/dist/scene/CityRenderer.js +1031 -0
- package/dist/scene/GrassFieldRenderer.js +53 -5
- package/dist/scene/PoleLineRenderer.d.ts +2 -0
- package/dist/scene/PoleLineRenderer.js +287 -0
- package/dist/scene/SoilPatchRenderer.js +70 -7
- package/dist/scene/WaterRenderer.js +34 -10
- package/dist/scene/builtinSceneKindRenderers.js +4 -0
- package/dist/scene/cityWindowMaterial.d.ts +16 -0
- package/dist/scene/cityWindowMaterial.js +81 -0
- package/dist/scene/sceneKindRenderers.d.ts +2 -0
- package/dist/settings/appliedSettings.d.ts +2 -1
- package/dist/settings/appliedSettings.js +4 -2
- package/dist/structures/GeneratedBuilding.d.ts +4 -0
- package/dist/structures/GeneratedBuilding.js +17 -7
- package/dist/structures/TransformGizmo.d.ts +11 -1
- package/dist/structures/TransformGizmo.js +9 -5
- package/dist/terrain/GrassField.d.ts +11 -3
- package/dist/terrain/GrassField.js +16 -6
- package/dist/terrain/grassGeometry.d.ts +33 -1
- package/dist/terrain/grassGeometry.js +83 -21
- package/dist/terrain/grassMaterial.d.ts +18 -0
- package/dist/terrain/grassMaterial.js +66 -13
- package/dist/terrain/heightfieldGeometry.d.ts +34 -0
- package/dist/terrain/heightfieldGeometry.js +109 -0
- package/dist/terrain/index.d.ts +1 -0
- package/dist/terrain/index.js +1 -0
- package/dist/terrain/soilPatchMaterial.d.ts +15 -2
- package/dist/terrain/soilPatchMaterial.js +46 -8
- package/dist/terrain/terrainDetailMaterial.js +15 -2
- package/dist/water/Ocean.d.ts +7 -1
- package/dist/water/Ocean.js +16 -3
- package/dist/water/OceanConfig.d.ts +9 -0
- package/dist/water/OceanConfig.js +6 -0
- package/dist/water/OceanMaterial.d.ts +12 -0
- package/dist/water/OceanMaterial.js +9 -0
- package/dist/water/OceanShader.d.ts +2 -2
- package/dist/water/OceanShader.js +78 -10
- package/dist/world/PlaceScene.d.ts +11 -0
- package/dist/world/PlaceScene.js +27 -0
- package/dist/world/WorldHud.d.ts +3 -1
- package/dist/world/WorldHud.js +2 -2
- package/dist/world/WorldScene.js +32 -4
- package/dist/worldSky.d.ts +7 -1
- package/dist/worldSky.js +11 -1
- package/package.json +4 -4
- package/skills/game-design/SKILL.md +28 -0
- package/skills/game-design/agents/openai.yaml +4 -0
- package/skills/game-design/references/application-playbook.md +170 -0
- package/skills/game-design/references/field-guide.md +288 -0
- package/skills/jgengine/SKILL.md +8 -4
- package/skills/jgengine/api.md +182 -81
- package/skills/jgengine/capabilities.md +104 -2
- package/skills/jgengine/recipes/minimal-game.md +88 -0
- package/skills/jgengine-ui/SKILL.md +17 -10
- package/skills/jgengine-ui/api.md +316 -51
- package/skills/jgengine-ui/capabilities.md +135 -2
- package/skills/jgengine-ui/recipes/portable-minimap.md +150 -0
- package/skills/jgengine-ui/reference.md +59 -9
- package/skills/jgengine-ui/references/visual-scorecard.md +1 -1
- package/skills/jgengine-world/SKILL.md +13 -0
- package/skills/jgengine-world/api.md +453 -21
- package/skills/jgengine-world/capabilities.md +112 -2
- package/skills/jgengine-world/recipes/commanding-entities.md +128 -0
- package/skills/jgengine-world/reference.md +43 -4
- package/skills/level-design/SKILL.md +54 -0
- package/skills/level-design/agents/openai.yaml +4 -0
- package/skills/level-design/references/application-playbook.md +192 -0
- package/skills/level-design/references/field-guide.md +337 -0
- package/skills/level-design/references/live-editor-loop.md +179 -0
- package/dist/cartridge/runtime.d.ts +0 -15
- package/dist/cartridge/runtime.js +0 -556
- package/dist/cartridge/spec.d.ts +0 -188
- package/dist/cartridge/spec.js +0 -19
- package/dist/cartridge/validate.d.ts +0 -2
- package/dist/cartridge/validate.js +0 -78
- package/dist/cartridge.d.ts +0 -145
- package/dist/cartridge.js +0 -246
- package/skills/jgengine/reference-cartridge.md +0 -72
|
@@ -0,0 +1,192 @@
|
|
|
1
|
+
# Applying level design
|
|
2
|
+
|
|
3
|
+
Use this playbook to turn spatial intent or an existing world into editor-authored, playable change. Its purpose is to force concrete topology, authoring operations, and evidence rather than aesthetic commentary.
|
|
4
|
+
|
|
5
|
+
## Contents
|
|
6
|
+
|
|
7
|
+
1. Greenfield procedure
|
|
8
|
+
2. Existing-world audit
|
|
9
|
+
3. Spatial truth and metrics
|
|
10
|
+
4. Journey, topology, and beats
|
|
11
|
+
5. Zone and encounter diagnosis
|
|
12
|
+
6. Ranking interventions
|
|
13
|
+
7. Editor change set
|
|
14
|
+
8. Implementation and proof
|
|
15
|
+
9. Failure modes
|
|
16
|
+
|
|
17
|
+
## 1. Greenfield procedure
|
|
18
|
+
|
|
19
|
+
Before production art:
|
|
20
|
+
|
|
21
|
+
1. Import the game-design contract: promise, verbs, repeated decision, loops, target player, and completion proof.
|
|
22
|
+
2. Author a metric gym and measure the actual controller, camera, interaction, combat, AI, and network behavior.
|
|
23
|
+
3. Draw the topology graph with starts, goals, critical/optional routes, gates, returns, checkpoints, encounters, safe spaces, and rewards.
|
|
24
|
+
4. Write a beat sheet across threat, motor, cognitive, navigation, emotional, resource, and social intensity.
|
|
25
|
+
5. Map where each mechanic is cued, tried safely, tested, combined, transformed, and mastered.
|
|
26
|
+
6. Specify encounter cards and the semantic scene ids they require.
|
|
27
|
+
7. Graybox one route/zone slice in `editor.scene.json` through GUI or RPC/CLI.
|
|
28
|
+
8. Playtest orientation, decisions, traversal, encounter flow, failure, and retry before population and art.
|
|
29
|
+
|
|
30
|
+
## 2. Existing-world audit
|
|
31
|
+
|
|
32
|
+
### Inventory spatial truth
|
|
33
|
+
|
|
34
|
+
Inspect the editor document and source tree. Report separately:
|
|
35
|
+
|
|
36
|
+
- authored paths and point counts
|
|
37
|
+
- authored markers grouped by semantic kind and catalog id
|
|
38
|
+
- authored zones/volumes, terrain, foliage, annotations, prefabs, and collections
|
|
39
|
+
- gameplay spawns, objectives, NPCs, vendors, loot, checkpoints, gates, and encounters
|
|
40
|
+
- coordinate arrays, centers, offsets, radii, procedural placement, and duplicated positions in code
|
|
41
|
+
- runtime queries that consume stable scene ids/kinds
|
|
42
|
+
|
|
43
|
+
If gameplay placement exists in code but not the document, mark the spatial-truth audit failed before discussing polish. The repair is an editor-authored migration with stable semantics, not another adapter around coordinate tables.
|
|
44
|
+
|
|
45
|
+
### Observe live play
|
|
46
|
+
|
|
47
|
+
Capture and inspect:
|
|
48
|
+
|
|
49
|
+
- spawn/first frame and the first ten seconds
|
|
50
|
+
- first decision and first objective
|
|
51
|
+
- one critical-path transition
|
|
52
|
+
- one representative encounter and retry
|
|
53
|
+
- one optional route/POI
|
|
54
|
+
- reverse travel or return after state change
|
|
55
|
+
- a dense/peak gameplay frame
|
|
56
|
+
|
|
57
|
+
Record what dominates the frame, what the player can infer, where they look, where they move, what they miss, and whether UI/world cues agree. Pixel metrics only reject technical blanks; human inspection judges composition and gameplay readability.
|
|
58
|
+
|
|
59
|
+
## 3. Spatial truth and metrics
|
|
60
|
+
|
|
61
|
+
### Metric sheet
|
|
62
|
+
|
|
63
|
+
| Family | Measured values | Source/build | Design consequence | Extreme/accessibility case |
|
|
64
|
+
| --- | --- | --- | --- | --- |
|
|
65
|
+
| movement | speed, acceleration, stop, turn, jump, slope, radius | | | |
|
|
66
|
+
| camera | perspective, FOV, offset, obstruction, sensitivity | | | |
|
|
67
|
+
| interaction | range, use time, target clarity | | | |
|
|
68
|
+
| combat/AI | weapon bands, projectile time, sensing, attack, group size | | | |
|
|
69
|
+
| navigation | path width, sightline, branch/rejoin, landmark range | | | |
|
|
70
|
+
| pacing | time to action, encounter, rest, reward, retry | | | |
|
|
71
|
+
| multiplayer | spawn, regroup, revive, latency, count | | | |
|
|
72
|
+
| performance | actor/object density, nav, draw, simulation | | | |
|
|
73
|
+
|
|
74
|
+
Derive dimensions from the measured game. Never paste corridor, cover, jump, or arena numbers from another title.
|
|
75
|
+
|
|
76
|
+
### Travel-time audit
|
|
77
|
+
|
|
78
|
+
Measure each route at the actual movement speed, including turns, hazards, encounters, and interaction delay. For every interval, classify the intended value: decision, mastery, anticipation, story, resource planning, combat, exploration, recovery, or deliberate atmosphere. Empty time with no purpose is a pacing defect even when the scenery is attractive.
|
|
79
|
+
|
|
80
|
+
## 4. Journey, topology, and beats
|
|
81
|
+
|
|
82
|
+
### Topology table
|
|
83
|
+
|
|
84
|
+
| Node/edge | Purpose | Entry information | Choice/tradeoff | Gate/return | Expected time | Downstream change |
|
|
85
|
+
| --- | --- | --- | --- | --- | --- | --- |
|
|
86
|
+
|
|
87
|
+
Validate reachability for relevant quest/world states and the reverse direction. Branches must differ in risk, cost, verb, information, reward, story, or experience.
|
|
88
|
+
|
|
89
|
+
### Beat sheet
|
|
90
|
+
|
|
91
|
+
| Time/distance | Beat | Threat | Motor | Cognitive | Navigation | Emotion/resource | Evidence/failure signal |
|
|
92
|
+
| --- | --- | --- | --- | --- | --- | --- | --- |
|
|
93
|
+
|
|
94
|
+
Look for long flats, constant peaks, unseen goals, repeated rhythms, rewards without anticipation, combat without aftermath, and failure without fast useful retry.
|
|
95
|
+
|
|
96
|
+
### First-minute contract
|
|
97
|
+
|
|
98
|
+
The first minute must deliberately answer:
|
|
99
|
+
|
|
100
|
+
- Where am I and what fantasy am I inhabiting?
|
|
101
|
+
- What can I do now?
|
|
102
|
+
- What should I notice first?
|
|
103
|
+
- What is my immediate goal and why?
|
|
104
|
+
- Where is the first safe experiment?
|
|
105
|
+
- What consequence teaches the rule?
|
|
106
|
+
- What next decision promises depth?
|
|
107
|
+
|
|
108
|
+
Do not answer all seven with text. Use space, action, feedback, and only the necessary UI.
|
|
109
|
+
|
|
110
|
+
## 5. Zone and encounter diagnosis
|
|
111
|
+
|
|
112
|
+
### Zone card
|
|
113
|
+
|
|
114
|
+
- role in the game/session loop
|
|
115
|
+
- visual/spatial identity and landmark hierarchy
|
|
116
|
+
- entry/exit states and critical/optional routes
|
|
117
|
+
- mechanics introduced, tested, combined, and mastered
|
|
118
|
+
- decision types and exploration rewards
|
|
119
|
+
- pacing arc, safe spaces, checkpoints, and return value
|
|
120
|
+
- content budget and performance peak
|
|
121
|
+
- spatial story and world-state change
|
|
122
|
+
|
|
123
|
+
Zones that differ only by palette, enemy level, or kill quota do not provide meaningful progression.
|
|
124
|
+
|
|
125
|
+
### Encounter card
|
|
126
|
+
|
|
127
|
+
- purpose and target player behavior
|
|
128
|
+
- entry sightline, knowledge, position, resources, and condition
|
|
129
|
+
- initial decision and viable approaches
|
|
130
|
+
- geometry for every intended verb and counterplay
|
|
131
|
+
- actors/hazards, escalation, reinforcement, peak, and resolution
|
|
132
|
+
- cover/refuge, retreat, flank, exits, and exploit risks
|
|
133
|
+
- reward, failure/reset, retry time, and downstream state change
|
|
134
|
+
- semantic scene ids and performance budget
|
|
135
|
+
|
|
136
|
+
## 6. Ranking interventions
|
|
137
|
+
|
|
138
|
+
Rank candidate changes with evidence:
|
|
139
|
+
|
|
140
|
+
| Candidate | Player behavior changed | Reach | Evidence/confidence | Effort/risk | Dependencies | Editor/runtime owner |
|
|
141
|
+
| --- | --- | --- | --- | --- | --- | --- |
|
|
142
|
+
|
|
143
|
+
Use three horizons:
|
|
144
|
+
|
|
145
|
+
- **Minimum correction:** migrate invalid spatial ownership or repair a blocking orientation/flow failure.
|
|
146
|
+
- **Strong target:** make one representative route/zone/encounter deliver the intended promise end to end.
|
|
147
|
+
- **Multiplier:** propagate the proven spatial grammar, semantic kinds, encounter kit, and tests across the world.
|
|
148
|
+
|
|
149
|
+
Prioritize upstream seams and reusable authoring kinds. Do not spend the first pass scattering props across a structurally unchanged map.
|
|
150
|
+
|
|
151
|
+
## 7. Editor change set
|
|
152
|
+
|
|
153
|
+
Specify operations semantically, not as code coordinates:
|
|
154
|
+
|
|
155
|
+
| Operation | Stable id/kind | Purpose/meta | Runtime consumer | Acceptance |
|
|
156
|
+
| --- | --- | --- | --- | --- |
|
|
157
|
+
| add/move/remove path | | from/to, route role | | |
|
|
158
|
+
| add/move/remove marker | | spawn/objective/NPC/checkpoint/landmark | | |
|
|
159
|
+
| add/move/remove zone | | encounter/settlement/safe/gate/resource | | |
|
|
160
|
+
| terrain/foliage/material pass | | traversal/readability/identity | | |
|
|
161
|
+
| prop/asset pass | | cover/affordance/story/landmark | | |
|
|
162
|
+
|
|
163
|
+
Execute through `jgengine-editor`. Gameplay code queries ids, kinds, layers, and metadata; it does not receive copied positions. File an editor feature issue if a required semantic kind or operation does not exist.
|
|
164
|
+
|
|
165
|
+
## 8. Implementation and proof
|
|
166
|
+
|
|
167
|
+
When the user asks to build or improve:
|
|
168
|
+
|
|
169
|
+
1. Establish before evidence and the acceptance scenario.
|
|
170
|
+
2. Author the chosen graybox and semantics through the editor.
|
|
171
|
+
3. Connect shared runtime/gameplay primitives to the authored ids.
|
|
172
|
+
4. Migrate superseded coordinate tables without changing unrelated content.
|
|
173
|
+
5. Add document assertions for required paths, zones, markers, and ids.
|
|
174
|
+
6. Add deterministic route, encounter, reset, and state-transition tests.
|
|
175
|
+
7. Run a fresh-player or representative play scenario.
|
|
176
|
+
8. Capture and inspect the same views before/after.
|
|
177
|
+
9. Evaluate timing, choice, comprehension, exploit, accessibility, and performance falsifiers.
|
|
178
|
+
|
|
179
|
+
Evidence should answer the design claim. Scene counts prove ownership, headless tests prove state, a driven playtest proves progress, and inspected screenshots prove visible composition. No one rung proves all four.
|
|
180
|
+
|
|
181
|
+
## 9. Failure modes
|
|
182
|
+
|
|
183
|
+
- praising asset count while gameplay semantics remain in code
|
|
184
|
+
- drawing a map without measuring the real controller/camera
|
|
185
|
+
- calling multiple corridors meaningful choice
|
|
186
|
+
- filling empty travel with collectibles instead of decisions or pacing
|
|
187
|
+
- changing color/lighting while topology and encounter flow remain unchanged
|
|
188
|
+
- using objective markers to compensate for contradictory geometry
|
|
189
|
+
- designing only the critical path or only the plan view
|
|
190
|
+
- making every zone the same objective with new enemies and palette
|
|
191
|
+
- reporting an audit after the user asked for improvement
|
|
192
|
+
- claiming success from scene counts, tests, telemetry, or screenshots alone
|
|
@@ -0,0 +1,337 @@
|
|
|
1
|
+
# Level design field guide
|
|
2
|
+
|
|
3
|
+
Use this reference for spatial planning, authoring, critique, and playtest diagnosis. It synthesizes research and production talks into adaptable tools. There are no universal corridor widths, jump gaps, cover intervals, or pacing curves: derive them from the actual game, camera, controller, opponents, audience, and performance budget.
|
|
4
|
+
|
|
5
|
+
## Contents
|
|
6
|
+
|
|
7
|
+
1. Spatial design contract
|
|
8
|
+
2. Metrics and test spaces
|
|
9
|
+
3. Topology and spatial grammar
|
|
10
|
+
4. Beats, pacing, and learning
|
|
11
|
+
5. Wayfinding and readability
|
|
12
|
+
6. Encounters and challenge spaces
|
|
13
|
+
7. Nonlinearity, exploration, and world structure
|
|
14
|
+
8. Genre lenses
|
|
15
|
+
9. Multiplayer spaces
|
|
16
|
+
10. Accessibility and comfort
|
|
17
|
+
11. JGengine authoring passes
|
|
18
|
+
12. Playtesting and evidence
|
|
19
|
+
13. Diagnostic checklist
|
|
20
|
+
14. Research basis
|
|
21
|
+
|
|
22
|
+
## 1. Spatial design contract
|
|
23
|
+
|
|
24
|
+
Translate the game-design contract into a one-level hypothesis:
|
|
25
|
+
|
|
26
|
+
| Concern | Question |
|
|
27
|
+
| --- | --- |
|
|
28
|
+
| purpose | What skill, choice, story beat, resource change, or social behavior exists because of this level? |
|
|
29
|
+
| entry | What does the player know, possess, expect, and see on arrival? |
|
|
30
|
+
| arc | How should orientation, pressure, discovery, mastery, and recovery change over time? |
|
|
31
|
+
| exit | What state and understanding should the player carry forward? |
|
|
32
|
+
| topology | What is critical, optional, gated, reversible, looping, or one-way? |
|
|
33
|
+
| constraints | What camera, movement, AI, combat, streaming, multiplayer, and accessibility facts bound the space? |
|
|
34
|
+
| proof | What will a fresh player do if the level works, and what observations would disprove it? |
|
|
35
|
+
|
|
36
|
+
Every space spends production and player attention. Give traversal, vistas, safe rooms, side paths, and empty space a purpose; atmosphere and anticipation are valid purposes when their duration supports the arc.
|
|
37
|
+
|
|
38
|
+
## 2. Metrics and test spaces
|
|
39
|
+
|
|
40
|
+
### Measure the real game
|
|
41
|
+
|
|
42
|
+
Author a compact metric gym in the editor. Measure at normal and extreme settings:
|
|
43
|
+
|
|
44
|
+
- walk, sprint, crouch, vehicle, climb, swim, and air speeds
|
|
45
|
+
- acceleration, deceleration, turn radius, strafe behavior, and input latency
|
|
46
|
+
- avatar radius/height, step height, slope limit, clearance, and camera offset/FOV
|
|
47
|
+
- jump height, time aloft, horizontal reach, forgiveness, ledge grab, and fall recovery
|
|
48
|
+
- interaction distance, target acquisition, use duration, and readable feedback range
|
|
49
|
+
- weapon/effect ranges, spread, travel time, damage falloff, reload, and cover exposure
|
|
50
|
+
- AI sensing, pursuit, attack, group size, navigation footprint, and disengage/reset behavior
|
|
51
|
+
- objective readability distance, audio cue range, and UI assistance behavior
|
|
52
|
+
- multiplayer latency assumptions, team size, spawn delay, revive range, and regroup time
|
|
53
|
+
- frame, draw, navigation, simulation, and streaming budgets at the densest intended moment
|
|
54
|
+
|
|
55
|
+
Record units and evidence. Derive spatial values from combinations: traversal distance from speed and desired travel time; arena depth from weapon bands and mobility; landing area from jump variance and camera visibility.
|
|
56
|
+
|
|
57
|
+
### Metric families
|
|
58
|
+
|
|
59
|
+
Track ranges rather than magic constants:
|
|
60
|
+
|
|
61
|
+
- minimum comfortable, standard, and mastery traversal widths
|
|
62
|
+
- safe, pressured, and impossible reaction distances
|
|
63
|
+
- intimate, tactical, navigational, and landmark sightline bands
|
|
64
|
+
- time from spawn/checkpoint to meaningful action
|
|
65
|
+
- time and distance from failure to retry
|
|
66
|
+
- branch divergence and rejoin time
|
|
67
|
+
- cover/exposure rhythm and flank travel time
|
|
68
|
+
- choke throughput and escape capacity for expected actors
|
|
69
|
+
- clue-to-commitment distance at each decision point
|
|
70
|
+
|
|
71
|
+
## 3. Topology and spatial grammar
|
|
72
|
+
|
|
73
|
+
### Draw a graph first
|
|
74
|
+
|
|
75
|
+
Represent the level as nodes and directed edges before detailed geometry. Annotate:
|
|
76
|
+
|
|
77
|
+
- start, goals, exits, checkpoints, safe spaces, peaks, and rewards
|
|
78
|
+
- critical and optional paths
|
|
79
|
+
- locks, keys, ability gates, resource gates, soft gates, and knowledge gates
|
|
80
|
+
- one-way drops, shortcuts, loops, returns, teleports, and failure resets
|
|
81
|
+
- decision points and information available before commitment
|
|
82
|
+
- enemy, hazard, objective, resource, and social pressure zones
|
|
83
|
+
- visibility, audibility, and foreshadowing across non-adjacent nodes
|
|
84
|
+
|
|
85
|
+
Check reachability for every valid state. Check the return route after objectives, not only the approach. A branch should change risk, information, cost, verb use, story, or experience; geometry alone does not create meaningful choice.
|
|
86
|
+
|
|
87
|
+
### Compose space deliberately
|
|
88
|
+
|
|
89
|
+
Use contrast to make places legible and memorable:
|
|
90
|
+
|
|
91
|
+
- compression -> threshold -> release
|
|
92
|
+
- exposure -> refuge -> re-entry
|
|
93
|
+
- low -> high, narrow -> broad, dark -> bright, quiet -> loud
|
|
94
|
+
- concealed approach -> reveal -> understood destination
|
|
95
|
+
- path -> edge -> district -> node -> landmark relationships
|
|
96
|
+
|
|
97
|
+
Preserve silhouettes and negative space. Repetition teaches a visual/spatial grammar; variation creates interest only while the grammar remains recognizable.
|
|
98
|
+
|
|
99
|
+
### Respect camera and viewpoint
|
|
100
|
+
|
|
101
|
+
Design what the player can perceive, not only the plan view. Validate corners, slopes, doors, stairs, jumps, cover, targets, and landmarks from the actual camera at gameplay speed. Third-person cameras need obstruction and shoulder-space checks; first-person spaces need motion/scale checks; top-down spaces need silhouette separation and input target clarity.
|
|
102
|
+
|
|
103
|
+
## 4. Beats, pacing, and learning
|
|
104
|
+
|
|
105
|
+
### Write a beat sheet
|
|
106
|
+
|
|
107
|
+
Useful beat types include arrival, orientation, foreshadowing, approach, choice, commitment, engagement, escalation, reversal, climax, aftermath, reward, reflection, and recovery. Record duration or distance plus separate intensity estimates for:
|
|
108
|
+
|
|
109
|
+
- threat/resource pressure
|
|
110
|
+
- motor precision and timing
|
|
111
|
+
- cognitive load and novelty
|
|
112
|
+
- navigation uncertainty
|
|
113
|
+
- emotional/narrative weight
|
|
114
|
+
- social coordination
|
|
115
|
+
|
|
116
|
+
Graph the axes. Avoid treating all intensity as one number: a quiet navigation puzzle can be cognitively intense while physically calm.
|
|
117
|
+
|
|
118
|
+
Create waves and contrast. Sustained peak pressure becomes a new baseline and prevents reflection. Fixed authored beats can coexist with adaptive population or pacing systems, but protect landmark encounters, guaranteed rests, and minimum recovery windows.
|
|
119
|
+
|
|
120
|
+
### Sequence learning
|
|
121
|
+
|
|
122
|
+
For each required mechanic:
|
|
123
|
+
|
|
124
|
+
1. signal the opportunity before punishment
|
|
125
|
+
2. isolate the mechanic in a low-cost situation
|
|
126
|
+
3. let the player act and see a clear consequence
|
|
127
|
+
4. test independent use
|
|
128
|
+
5. combine it with one mastered demand
|
|
129
|
+
6. vary context or invert an assumption
|
|
130
|
+
7. provide a mastery application and later recall
|
|
131
|
+
|
|
132
|
+
This is a diagnostic progression, not a mandatory number of rooms. Skip, compress, or branch based on target players and observed mastery. Never confuse obscurity with difficulty.
|
|
133
|
+
|
|
134
|
+
## 5. Wayfinding and readability
|
|
135
|
+
|
|
136
|
+
### Build an information hierarchy
|
|
137
|
+
|
|
138
|
+
At a glance, players should distinguish:
|
|
139
|
+
|
|
140
|
+
1. immediate hazards and safe footing
|
|
141
|
+
2. interactables, opponents, allies, and objectives
|
|
142
|
+
3. current route choices and traversal boundaries
|
|
143
|
+
4. distant goals, districts, and optional opportunities
|
|
144
|
+
5. decorative context
|
|
145
|
+
|
|
146
|
+
Use multiple aligned channels:
|
|
147
|
+
|
|
148
|
+
- framing, leading edges, occlusion/reveal, and dominant silhouettes
|
|
149
|
+
- light/value contrast and restrained color coding
|
|
150
|
+
- motion, particles, animation, and population flow
|
|
151
|
+
- audio direction, rhythm, and environmental sound
|
|
152
|
+
- material, shape, scale, signage, and repeated affordance language
|
|
153
|
+
- vistas, landmarks, breadcrumbs, path wear, and environmental change
|
|
154
|
+
|
|
155
|
+
Do not make critical meaning depend on color or audio alone. Decorative contrast must not compete with gameplay signals.
|
|
156
|
+
|
|
157
|
+
### Design decision points
|
|
158
|
+
|
|
159
|
+
Before commitment, show enough of each choice to form an intention: destination, risk, cost, verb requirement, or likely reward. After commitment, confirm the route and preserve a mental link to origin. Make return paths readable from the reverse direction; a one-way composition often fails backward.
|
|
160
|
+
|
|
161
|
+
Layer navigation assistance: spatial cues first, optional map/compass/objective aids second, explicit route guidance when requested or required for access. If every tester follows a marker while ignoring the world, test without it to expose the spatial problem.
|
|
162
|
+
|
|
163
|
+
## 6. Encounters and challenge spaces
|
|
164
|
+
|
|
165
|
+
### Write an encounter card
|
|
166
|
+
|
|
167
|
+
- purpose in the level arc
|
|
168
|
+
- player entry position, knowledge, resources, and likely condition
|
|
169
|
+
- enemies/hazards/objectives and their readable introduction
|
|
170
|
+
- geometry supporting each core verb and counterplay
|
|
171
|
+
- initial choice, escalation trigger, reinforcement rules, and peak
|
|
172
|
+
- resources, cover/refuge, exits, retreat, and alternate approaches
|
|
173
|
+
- success/failure state, reset, reward, and downstream consequence
|
|
174
|
+
- expected duration, intensity axes, and performance budget
|
|
175
|
+
|
|
176
|
+
### Spatial combat checks
|
|
177
|
+
|
|
178
|
+
- sightlines match weapon and perception ranges
|
|
179
|
+
- cover has readable protection, exposure, flanking, and escape relationships
|
|
180
|
+
- vertical advantage has counters and does not hide essential information
|
|
181
|
+
- enemy entrances are foreshadowed and do not feel like arbitrary materialization
|
|
182
|
+
- spawn locations avoid immediate unavoidable damage and repeated trapping
|
|
183
|
+
- the arena supports movement instead of collapsing every fight into one safe corner
|
|
184
|
+
- retreat and recovery do not accidentally reset or exploit the whole encounter
|
|
185
|
+
- resource placement changes decisions rather than merely refilling after them
|
|
186
|
+
|
|
187
|
+
For stealth, model visibility, audibility, patrol information, hiding capacity, bypasses, alarm propagation, search, and recovery. For puzzles, model known facts, manipulable state, hypothesis space, feedback, undo/reset, and whether failure adds information.
|
|
188
|
+
|
|
189
|
+
## 7. Nonlinearity, exploration, and world structure
|
|
190
|
+
|
|
191
|
+
Use hubs, loops, braided paths, spokes, layered spaces, or open fields according to the verbs and orientation burden. More branches do not automatically create agency.
|
|
192
|
+
|
|
193
|
+
Distinct routes can trade:
|
|
194
|
+
|
|
195
|
+
- speed versus safety
|
|
196
|
+
- information versus resources
|
|
197
|
+
- execution difficulty versus planning complexity
|
|
198
|
+
- stealth versus confrontation
|
|
199
|
+
- immediate reward versus future access
|
|
200
|
+
- authored story versus systemic discovery
|
|
201
|
+
- solo efficiency versus group support
|
|
202
|
+
|
|
203
|
+
Reward exploration with knowledge, tactical position, shortcuts, expressive content, systemic advantage, story, resources with real use, or a changed understanding of the world. Uniform collectibles turn discovery into coverage work.
|
|
204
|
+
|
|
205
|
+
Control density. Leave room for anticipation, long views, traversal mastery, and ecological/narrative coherence. Revisit value rises when routes unlock, world state changes, new verbs reinterpret old obstacles, or return travel is meaningfully compressed.
|
|
206
|
+
|
|
207
|
+
## 8. Genre lenses
|
|
208
|
+
|
|
209
|
+
### Platforming and traversal
|
|
210
|
+
|
|
211
|
+
Prioritize landing visibility, input commitment, correction windows, camera stability, readable collision, consequence, restart speed, and progression from isolated movement to chained decisions. Optional mastery routes can carry tighter metrics without blocking the critical path.
|
|
212
|
+
|
|
213
|
+
### Racing and vehicles
|
|
214
|
+
|
|
215
|
+
Design sight distance from speed and braking, corners from handling and camera, passing from route width and line tradeoffs, recovery from crash cost, and landmarks from rapid recognition. Validate reverse/off-course behavior and vehicle congestion.
|
|
216
|
+
|
|
217
|
+
### Puzzle
|
|
218
|
+
|
|
219
|
+
Separate discovering the rule from executing it. Present sufficient information, minimize irrelevant state, keep causality visible, support undo/reset, and test whether hints preserve the player's final inference. Combine mechanics only after their individual language is learned.
|
|
220
|
+
|
|
221
|
+
### Survival and horror
|
|
222
|
+
|
|
223
|
+
Use incomplete information deliberately but keep rules trustworthy. Space controls vulnerability, refuge, resource forecasting, pursuit, and route commitment. Alternate anticipation, exposure, consequence, and relief; random pressure still needs fairness constraints.
|
|
224
|
+
|
|
225
|
+
### Strategy, tactics, and defense
|
|
226
|
+
|
|
227
|
+
Make territory, ranges, lanes, objectives, buildable areas, influence, and path consequences legible from the command view. Check dominant positions, stalled states, path manipulation, economy access, and whether early advantage becomes irreversible.
|
|
228
|
+
|
|
229
|
+
### Exploration and narrative
|
|
230
|
+
|
|
231
|
+
Let navigation itself reveal relationships, history, and choice. Align story beats with movement and attention rather than competing exposition. Optional spaces should deepen context or play, not contain the explanation required to understand the critical path.
|
|
232
|
+
|
|
233
|
+
## 9. Multiplayer spaces
|
|
234
|
+
|
|
235
|
+
Symmetry guarantees sameness, not balance; asymmetry can be fair when route time, information, objectives, roles, and counterplay support the intended mode. Measure from every spawn and team state.
|
|
236
|
+
|
|
237
|
+
Validate:
|
|
238
|
+
|
|
239
|
+
- time to first choice, first contact, objective, power position, and regroup
|
|
240
|
+
- spawn visibility, nearby threats, exits, ally access, and repeat-kill risk
|
|
241
|
+
- lane and flank value, rotation time, choke capacity, and sightline dominance
|
|
242
|
+
- objective approach diversity, defense depth, contest readability, and overtime state
|
|
243
|
+
- callout landmarks and team-color/accessibility readability
|
|
244
|
+
- player-count scaling, uneven teams, join-in-progress, spectators, and disconnects
|
|
245
|
+
- novice traffic versus expert routes; both cohorts can expose different failures
|
|
246
|
+
- exploits involving geometry, camera, collision, projectiles, AI, or destruction
|
|
247
|
+
|
|
248
|
+
Use heatmaps and outcome data to locate questions, then watch matches to explain them. A 50% win rate can conceal miserable spawns or a dominant strategy mirrored by both teams.
|
|
249
|
+
|
|
250
|
+
## 10. Accessibility and comfort
|
|
251
|
+
|
|
252
|
+
Treat navigation, challenge, and sensory load as adjustable dimensions:
|
|
253
|
+
|
|
254
|
+
- communicate objectives and progress without requiring memory alone
|
|
255
|
+
- offer map, breadcrumb, high-contrast, audio/visual cue, and route-assist options
|
|
256
|
+
- avoid color-only teams, routes, hazards, or puzzle state
|
|
257
|
+
- provide timing, precision, damage, resource, puzzle, and navigation assists separately
|
|
258
|
+
- reduce repeated travel and execution after demonstrated mastery
|
|
259
|
+
- support pause where topology permits and provide safe stopping points
|
|
260
|
+
- validate motion, camera acceleration, head bob, FOV, flashing, visual clutter, and audio dependence
|
|
261
|
+
- make shortcuts, skips, and recovery usable without stigma or lost progress
|
|
262
|
+
|
|
263
|
+
Accessibility options can preserve fantasy while changing the barrier. Test with affected players rather than guessing from a checklist.
|
|
264
|
+
|
|
265
|
+
## 11. JGengine authoring passes
|
|
266
|
+
|
|
267
|
+
Use `jgengine-editor` GUI or RPC/CLI for every pass; never hand-edit `editor.scene.json`.
|
|
268
|
+
|
|
269
|
+
1. **Metrics:** author the movement/camera/interaction test space.
|
|
270
|
+
2. **Topology:** place stable semantic markers, zones, paths, starts, goals, gates, and checkpoints.
|
|
271
|
+
3. **Graybox:** establish terrain, boundaries, traversal, sightlines, encounter volume, and reset routes.
|
|
272
|
+
4. **Gameplay:** bind systems to authored ids/kinds; keep coordinates in the document.
|
|
273
|
+
5. **Wayfinding:** add landmarks, composition, lighting/material hierarchy, signage, and redundant cues.
|
|
274
|
+
6. **Population:** place actors, resources, hazards, rewards, foliage, and props with budget awareness.
|
|
275
|
+
7. **Art:** refine materials, asset variation, environmental story, and atmosphere without erasing readability.
|
|
276
|
+
8. **Optimization:** validate dense views, navigation, collision, instancing, streaming, and bounded runtime queries.
|
|
277
|
+
|
|
278
|
+
Use stable names such as `spawn:*`, `goal:*`, `route:*`, `zone:*`, or project-specific semantic kinds consistently. Runtime and tests query semantics; they do not duplicate positions. If an authoring kind is missing, file the editor feature issue first.
|
|
279
|
+
|
|
280
|
+
## 12. Playtesting and evidence
|
|
281
|
+
|
|
282
|
+
### Test in layers
|
|
283
|
+
|
|
284
|
+
- **metric test:** can the controller perform intended movement reliably?
|
|
285
|
+
- **first-look test:** where does a fresh player look and go before prompting?
|
|
286
|
+
- **route test:** what choices, reversals, loops, and missed paths occur?
|
|
287
|
+
- **encounter test:** what positions, verbs, resources, failures, and exploits dominate?
|
|
288
|
+
- **pacing test:** where do hesitation, fatigue, pressure, relief, and payoff occur?
|
|
289
|
+
- **return test:** can players navigate backward or after world-state changes?
|
|
290
|
+
- **accessibility test:** which sensory, motor, cognitive, or timing barriers are avoidable?
|
|
291
|
+
- **multiplayer test:** how do skill, team state, count, latency, and social behavior alter flow?
|
|
292
|
+
|
|
293
|
+
Capture build/version, player profile, timestamps, path/position samples, deaths/damage, retries, objective state, interaction failures, camera direction at decisions, dwell, resource state, and completion time only when they answer a design question.
|
|
294
|
+
|
|
295
|
+
Watch without coaching. Ask afterward what the player believed the goal, rule, route, risk, and consequence were. Diagnose the smallest upstream cause:
|
|
296
|
+
|
|
297
|
+
- missing or competing information
|
|
298
|
+
- misleading affordance or composition
|
|
299
|
+
- bad geometry/metrics
|
|
300
|
+
- mechanic not learned
|
|
301
|
+
- execution burden
|
|
302
|
+
- encounter or economy tuning
|
|
303
|
+
- reset/recovery friction
|
|
304
|
+
- runtime bug
|
|
305
|
+
|
|
306
|
+
Change one causal variable, preserve before/after evidence, and retest. A polished screenshot proves composition, not playability; a scene summary proves authored presence, not visual quality.
|
|
307
|
+
|
|
308
|
+
## 13. Diagnostic checklist
|
|
309
|
+
|
|
310
|
+
- Does the level serve a named loop, pillar, skill, or story purpose?
|
|
311
|
+
- Are dimensions derived from measured controller, camera, actor, and network behavior?
|
|
312
|
+
- Can players see enough to choose before commitment?
|
|
313
|
+
- Does every required mechanic appear before it is demanded?
|
|
314
|
+
- Are critical path, optional paths, return routes, and reset routes all valid?
|
|
315
|
+
- Do beats vary across separate intensity axes and include recovery?
|
|
316
|
+
- Do art, lighting, audio, and UI reinforce rather than contradict spatial guidance?
|
|
317
|
+
- Does every encounter support intended verbs, counterplay, retreat, and fair recovery?
|
|
318
|
+
- Are exploration rewards meaningful and route choices distinct?
|
|
319
|
+
- Are objectives, hazards, footing, interactables, and teams readable without one sensory channel?
|
|
320
|
+
- Do multiplayer spawns, timings, objectives, and power positions survive different skill bands and counts?
|
|
321
|
+
- Does `editor.scene.json` remain the sole source of authored spatial truth?
|
|
322
|
+
- Has a fresh target player completed the scenario without designer coaching?
|
|
323
|
+
|
|
324
|
+
## 14. Research basis
|
|
325
|
+
|
|
326
|
+
- David Shaver and Robert Yang, GDC [“Invisible Intuition”](https://www.gdcvault.com/play/1025360/Level-): blockmesh, composition, light, effects, audio, and early tests as aligned wayfinding channels.
|
|
327
|
+
- Jane Ng, GDC [“Designing for Exploration and Choice in Firewatch”](https://www.gdcvault.com/play/1022409/Designing-for-Exploration-and-Choice): world structure, goals, gating, and encounter thinking for non-combat exploration.
|
|
328
|
+
- Matt Thorson, GDC [“Designing Celeste”](https://www.gdcvault.com/play/1024307/Level-Design-Workshop-Designing-Celeste): movement-driven stages, area arrangement, progression, and story integration.
|
|
329
|
+
- Mike Booth / Valve, [“The AI Systems of Left 4 Dead”](https://steamcdn-a.akamaihd.net/apps/valve/2009/ai_systems_of_l4d_mike_booth.pdf): measure player intensity and separate adaptive pacing frequency from difficulty amplitude.
|
|
330
|
+
- Jolie Menzel, GDC [“Solving Puzzle Design”](https://www.gdcvault.com/play/1023139/Level-): information, goals, teaching, iteration, and frustration diagnosis in spatial puzzles.
|
|
331
|
+
- Andrew Yoder, GDC [“The Holy Grail of Multiplayer Level Design”](https://gdcvault.com/play/1025183/Level-Design-Workshop-The-Holy): test graybox maps with casual and competitive cohorts and combine data with observation.
|
|
332
|
+
- Clemence Maurer, GDC [“Rewarding Exploration in Deus Ex: Mankind Divided”](https://gdcvault.com/play/1024305/Level-Design-Workshop-Rewarding-Exploration): connect optional navigation, systemic advantage, world coherence, and environmental story.
|
|
333
|
+
- Dave Feltham, GDC [“Emotional Journey”](https://gdcvault.com/play/1018166/Emotional-Journey-BioWare-s-Methods): use measured level pacing and flow to reinforce narrative arcs.
|
|
334
|
+
- Matthias Worch, GDC [“Decisions That Matter”](https://gdcvault.com/play/1020570/): informed spatial choices, consequences, possibility space, and agency.
|
|
335
|
+
- Brendon Chung, GDC [“Wayfinding & Storytelling Techniques”](https://www.gdcvault.com/play/1022117/level-design-in-a-day): architecture, navigation, environmental information, and common wayfinding failures.
|
|
336
|
+
- Luke McMillan, [“The Metrics of Space”](https://www.gamedeveloper.com/design/the-metrics-of-space-tactical-level-design): derive tactical space from viewpoint, awareness, and gameplay metrics rather than decoration.
|
|
337
|
+
- Microsoft, [Xbox Accessibility Guidelines](https://learn.microsoft.com/en-us/xbox/accessibility/guidelines): objective clarity, input, object readability, redundant cues, timing, challenge options, and sensory comfort.
|