docs: audit app architecture and refresh feature documentation
🔍 Lint / 🪄 Check lint (push) Has been cancelled
🔍 Lint / 🎨 Check format (push) Has been cancelled
🔍 Lint / 🔎 Typecheck (push) Has been cancelled
🔍 Lint / 🏗 Build (push) Has been cancelled
📊 Quality / 🔒 Security Audit (push) Has been cancelled
📊 Quality / 📋 Dependency Freshness (push) Has been cancelled
📊 Quality / 📦 Bundle Size (push) Has been cancelled
🔍 Lint / 🪄 Check lint (push) Has been cancelled
🔍 Lint / 🎨 Check format (push) Has been cancelled
🔍 Lint / 🔎 Typecheck (push) Has been cancelled
🔍 Lint / 🏗 Build (push) Has been cancelled
📊 Quality / 🔒 Security Audit (push) Has been cancelled
📊 Quality / 📋 Dependency Freshness (push) Has been cancelled
📊 Quality / 📦 Bundle Size (push) Has been cancelled
This commit is contained in:
Tom Boullay
@@ -9,7 +9,9 @@ This document describes the 3D components that are currently used in the runtime
|
||||
| Interaction | `InteractableObject` | Focus detection through distance and raycasting |
|
||||
| Interaction | `TriggerObject` | Press-to-trigger interactions, optional sound, optional spawned model |
|
||||
| Interaction | `GrabbableObject` | Physics grab and hand-tracking grab behavior |
|
||||
| Model | `AnimatedModel` | GLTF animation playback with fade, speed, and context controls |
|
||||
| Model | `ExplodableModel` | Split/reassemble a GLTF model into separated parts |
|
||||
| Model | `SimpleModel` | Lightweight static GLTF render helper |
|
||||
| Gameplay | `RepairCaseModel` | Repair case lid animation, proximity float, and wobble |
|
||||
|
||||
## Continuous Animation
|
||||
@@ -27,6 +29,30 @@ Use GSAP only for discrete timeline-style transitions. Current example:
|
||||
|
||||
- `RepairCaseModel` animates the case lid between open and closed rotations.
|
||||
|
||||
## Animated Models
|
||||
|
||||
`src/components/three/models/AnimatedModel.tsx` wraps drei `useAnimations()` around a loaded GLTF scene.
|
||||
|
||||
It supports:
|
||||
|
||||
- default animation playback
|
||||
- optional autoplay
|
||||
- fade duration
|
||||
- speed multiplier
|
||||
- `onLoaded`
|
||||
- `onAnimationEnd`
|
||||
- context controls through `AnimatedModelContext`
|
||||
|
||||
The debug physics scene currently uses it to preview:
|
||||
|
||||
```txt
|
||||
public/models/electricienne_animated/model.gltf
|
||||
```
|
||||
|
||||
with the `Dance` animation.
|
||||
|
||||
`src/hooks/animation/useCharacterAnimation.ts` is a hook-level alternative for components that need to own their group ref and animation controls directly.
|
||||
|
||||
## GLTF Reuse
|
||||
|
||||
Use `useClonedObject` when a GLTF scene is reused by a component instance. It memoizes `scene.clone(true)` and keeps clone creation out of render churn.
|
||||
@@ -44,7 +70,9 @@ src/components/three/
|
||||
│ ├── InteractableObject.tsx
|
||||
│ └── TriggerObject.tsx
|
||||
├── models/
|
||||
│ └── ExplodableModel.tsx
|
||||
│ ├── AnimatedModel.tsx
|
||||
│ ├── ExplodableModel.tsx
|
||||
│ └── SimpleModel.tsx
|
||||
└── world/
|
||||
└── SkyModel.tsx
|
||||
```
|
||||
|
||||
+268
-107
@@ -4,140 +4,301 @@ This document describes the code that exists today in the repository.
|
||||
|
||||
## Runtime Structure
|
||||
|
||||
- `src/main.tsx` mounts React.
|
||||
- `src/App.tsx` mounts the TanStack `RouterProvider`.
|
||||
- `src/router.tsx` declares the top-level routes:
|
||||
- `/` mounts the playable 3D scene, debug perf overlay, and HTML overlays.
|
||||
- `/editor` mounts the map editor page.
|
||||
- `src/world/World.tsx` composes the active scene, including:
|
||||
- environment and lighting
|
||||
- debug helpers and debug camera mode
|
||||
- either the map scene or the debug physics test scene
|
||||
- the player rig when the active camera mode is `player`
|
||||
- `src/hooks/world/useWorldSceneLoading.ts` owns the production scene loading state shared by `World`, `GameMap`, and the player octree readiness.
|
||||
- `src/world/GameMap.tsx` loads map nodes from `public/map.json`, resolves available models, renders them progressively, and shows fallback cubes for missing models.
|
||||
- `src/world/GameMapCollision.tsx` builds the player collision octree from dedicated collision nodes only.
|
||||
- `src/world/GameStageContent.tsx` is wrapped in Rapier `Physics` in the production game scene so stage gameplay objects can use physics without moving the map or player to Rapier. It now mounts reusable `RepairGame` instances for `bike`, `pylone`, and `ferme` mission states.
|
||||
- `src/world/debug/TestMap.tsx` provides a debug-oriented interaction and physics map with the existing grab/trigger/model-preview objects plus separate `Bike`, `Pylone`, and `Farm` repair playground zones.
|
||||
- `src/world/player/Player.tsx` mounts the camera and controller.
|
||||
- `src/world/player/PlayerController.tsx` owns pointer lock movement, jump handling, repair-step movement locking, and interaction input.
|
||||
- `src/main.tsx` mounts React in `StrictMode`.
|
||||
- `src/App.tsx` mounts TanStack `RouterProvider`.
|
||||
- `src/router.tsx` declares `/`, `/editor`, and `/docs`.
|
||||
- `src/pages/page.tsx` composes the playable route with `HandTrackingProvider`, React Three Fiber `Canvas`, `World`, `DebugPerf`, `GameUI`, and `SceneLoadingOverlay`.
|
||||
- `src/pages/editor/page.tsx` composes the local editor route.
|
||||
- `src/components/docs/DocsLayout.tsx` composes the in-app documentation route.
|
||||
|
||||
Detailed runtime-loading notes live in `docs/technical/scene-runtime.md`.
|
||||
|
||||
## World Composition
|
||||
|
||||
`src/world/World.tsx` is the main 3D scene composer.
|
||||
|
||||
Always-mounted scene systems:
|
||||
|
||||
- `Environment`
|
||||
- `Lighting`
|
||||
- debug helpers when `?debug` is active
|
||||
- optional hand-tracking glove overlays
|
||||
- optional debug camera controls
|
||||
|
||||
Game scene systems:
|
||||
|
||||
- `GameMap`
|
||||
- Rapier `Physics` wrapping `GameStageContent`
|
||||
- `GameMusic`
|
||||
- `GameDialogues`
|
||||
- `GameCinematics` only while `mainState === "outro"`
|
||||
- `Player` after gameplay is ready
|
||||
|
||||
Debug physics scene systems:
|
||||
|
||||
- `TestMap`
|
||||
- `Player` after the debug octree is ready
|
||||
|
||||
Debug scene and camera mode are controlled by `src/utils/debug/Debug.ts` and enabled with `?debug`.
|
||||
|
||||
## Scene Loading
|
||||
|
||||
The production game scene is considered ready only after:
|
||||
|
||||
- map data and visible map nodes have settled
|
||||
- collision source models have settled
|
||||
- the player octree exists
|
||||
- the Rapier gameplay stage has mounted
|
||||
|
||||
The player is not spawned until that readiness gate is satisfied. This avoids starting player movement, music, dialogue timing, and interactions while the map/stage is still loading.
|
||||
|
||||
## Physics Boundaries
|
||||
|
||||
The project currently uses two collision layers with separate responsibilities:
|
||||
The project currently uses two collision systems with separate responsibilities:
|
||||
|
||||
- `GameMapCollision` builds an octree used by the player controller for map collision.
|
||||
- The player octree must be built from a small collision-only subset of map nodes. It currently uses the `terrain` node only instead of traversing the full visible map, because building an octree from all rendered props can overload the browser renderer.
|
||||
- `GameStageContent` is wrapped in Rapier `Physics` for gameplay objects such as repair triggers, cases, grabbables, and future mission-specific objects.
|
||||
- `TestMap` owns its own Rapier `Physics` playground so repair gameplay can be tuned per mission state without depending on the production map layout.
|
||||
- Player movement uses a Three.js `Capsule` and an `Octree`.
|
||||
- Gameplay objects use Rapier rigid bodies and colliders.
|
||||
|
||||
Keep the player and map octree outside the Rapier provider until there is a deliberate migration plan. This avoids mixing player movement rules with object physics before the gameplay systems need it.
|
||||
`GameMapCollision` builds the player octree from explicit collision nodes. It currently uses only the `terrain` node.
|
||||
|
||||
`GameStageContent` is wrapped in Rapier `Physics` so repair cases, triggers, and grabbable parts can use physics without migrating the player controller to Rapier.
|
||||
|
||||
This split is deliberate. It keeps the player controller simple while still enabling physical manipulation for gameplay objects.
|
||||
|
||||
## Gameplay Layer
|
||||
|
||||
The current core gameplay feature is the reusable repair game.
|
||||
|
||||
Production placements live in:
|
||||
|
||||
```txt
|
||||
src/world/GameStageContent.tsx
|
||||
```
|
||||
|
||||
The reusable flow lives in:
|
||||
|
||||
```txt
|
||||
src/components/three/gameplay/RepairGame.tsx
|
||||
```
|
||||
|
||||
Mission-specific data lives in:
|
||||
|
||||
```txt
|
||||
src/data/gameplay/repairMissions.ts
|
||||
```
|
||||
|
||||
The repair game supports:
|
||||
|
||||
```txt
|
||||
locked -> waiting -> inspected -> fragmented -> scanning -> repairing -> reassembling -> done
|
||||
```
|
||||
|
||||
Detailed repair-game implementation notes live in `docs/technical/repair-game.md`.
|
||||
|
||||
## State Management
|
||||
|
||||
Durable progression state lives in:
|
||||
|
||||
```txt
|
||||
src/managers/stores/useGameStore.ts
|
||||
```
|
||||
|
||||
It owns:
|
||||
|
||||
- `mainState`
|
||||
- intro state
|
||||
- `bike`, `pylone`, and `ferme` mission state
|
||||
- outro state
|
||||
- `isCinematicPlaying`
|
||||
- progression actions
|
||||
- generic mission actions
|
||||
|
||||
Settings state lives in:
|
||||
|
||||
```txt
|
||||
src/managers/stores/useSettingsStore.ts
|
||||
```
|
||||
|
||||
Subtitle display state lives in:
|
||||
|
||||
```txt
|
||||
src/managers/stores/useSubtitleStore.ts
|
||||
```
|
||||
|
||||
Detailed Zustand notes live in `docs/technical/zustand.md`.
|
||||
|
||||
## Managers
|
||||
|
||||
Managers are used for imperative runtime systems that own browser or frame-adjacent objects.
|
||||
|
||||
Current managers:
|
||||
|
||||
- `src/managers/AudioManager.ts`
|
||||
- `src/managers/InteractionManager.ts`
|
||||
|
||||
`AudioManager` owns `HTMLAudioElement` instances, music playback, one-shot pools, category volumes, and optional stereo panning.
|
||||
|
||||
`InteractionManager` owns focused/nearby/holding state for trigger and grab interactions and exposes a snapshot through `useSyncExternalStore`.
|
||||
|
||||
## Interaction Model
|
||||
|
||||
- `src/managers/InteractionManager.ts` is the current interaction state source.
|
||||
- `src/components/three/interaction/InteractableObject.tsx` handles focus detection through distance and raycasting.
|
||||
- `src/components/three/interaction/TriggerObject.tsx` implements trigger-style interactions.
|
||||
- `src/components/three/interaction/GrabbableObject.tsx` implements hold-and-release interactions.
|
||||
- `src/hooks/interaction/useInteraction.ts` exposes the interaction snapshot to React UI.
|
||||
- `src/components/ui/InteractPrompt.tsx` shows the `E` prompt for trigger interactions.
|
||||
Core interaction files:
|
||||
|
||||
## Audio
|
||||
- `src/components/three/interaction/InteractableObject.tsx`
|
||||
- `src/components/three/interaction/TriggerObject.tsx`
|
||||
- `src/components/three/interaction/GrabbableObject.tsx`
|
||||
- `src/hooks/interaction/useInteraction.ts`
|
||||
- `src/components/ui/InteractPrompt.tsx`
|
||||
|
||||
- `src/managers/AudioManager.ts` provides pooled one-shot playback, looped music playback, category volumes, and optional stereo pan for one-shot sounds.
|
||||
- Supported audio categories are `music`, `sfx`, and `dialogue`.
|
||||
- Trigger interactions may play SFX directly through `AudioManager`.
|
||||
- Detailed audio documentation lives in `docs/technical/audio.md`.
|
||||
The player controller bridges raw input to semantic interaction actions:
|
||||
|
||||
## Settings Menu
|
||||
- `E` triggers focused trigger objects
|
||||
- primary mouse button grabs focused grabbable objects
|
||||
- hand tracking can grab hand-controlled grabbable objects
|
||||
|
||||
- `src/managers/stores/useSettingsStore.ts` stores settings for music volume, SFX volume, dialogue volume, subtitle visibility, subtitle language, repair runtime, and menu visibility.
|
||||
- `src/components/ui/GameSettingsMenu.tsx` renders the in-game options menu.
|
||||
- `src/components/ui/GameUI.tsx` mounts the settings menu as an HTML overlay outside the canvas.
|
||||
- `Esc` opens and closes the menu, and `src/world/player/PlayerController.tsx` ignores player input while the menu is open.
|
||||
- Volume changes are forwarded to `AudioManager` by category.
|
||||
Detailed interaction notes live in `docs/technical/interaction.md`.
|
||||
|
||||
## Dialogues And Subtitles
|
||||
## Audio, Dialogue, And Subtitles
|
||||
|
||||
- `public/sounds/dialogue/dialogues.json` is the runtime dialogue manifest.
|
||||
- Dialogue audio files live under `public/sounds/dialogue/`.
|
||||
- Subtitle files live under `public/sounds/dialogue/subtitles/{fr|en}/`.
|
||||
- The current subtitle model is one SRT file per voice and language.
|
||||
- `src/types/dialogues/dialogues.ts` contains the dialogue manifest types.
|
||||
- `src/utils/dialogues/dialogueManifestValidation.ts` validates manifest shape at runtime.
|
||||
- `src/utils/dialogues/loadDialogueManifest.ts` loads the manifest and SRT cues, with French fallback when the selected language is missing.
|
||||
- `src/utils/subtitles/parseSrt.ts` parses SRT blocks and timecodes.
|
||||
- `src/utils/dialogues/playDialogue.ts` plays dialogue audio and synchronizes the active subtitle against the audio element time.
|
||||
- `src/managers/stores/useSubtitleStore.ts` stores the currently displayed subtitle cue.
|
||||
- `src/components/ui/Subtitles.tsx` renders the subtitle overlay.
|
||||
- `src/world/GameDialogues.tsx` currently triggers dialogue entries that define a `timecode`.
|
||||
- Dialogue playback is queued so multiple dialogue requests do not overlap.
|
||||
Audio is split into:
|
||||
|
||||
- `music`
|
||||
- `sfx`
|
||||
- `dialogue`
|
||||
|
||||
Runtime dialogue data lives under:
|
||||
|
||||
```txt
|
||||
public/sounds/dialogue/
|
||||
```
|
||||
|
||||
The current subtitle model is one SRT file per voice and language. A dialogue entry references one cue by `subtitleCueIndex`.
|
||||
|
||||
`src/utils/dialogues/playDialogue.ts` queues dialogue playback and synchronizes the active subtitle cue against the playing audio element.
|
||||
|
||||
Detailed audio notes live in `docs/technical/audio.md`.
|
||||
|
||||
## Cinematics
|
||||
|
||||
- `public/cinematics.json` is the runtime cinematic manifest.
|
||||
- `src/types/cinematics/cinematics.ts` contains cinematic manifest types.
|
||||
- `src/utils/cinematics/cinematicManifestValidation.ts` validates manifest shape at runtime.
|
||||
- `src/utils/cinematics/loadCinematicManifest.ts` loads `/cinematics.json`.
|
||||
- `src/world/GameCinematics.tsx` triggers cinematics that define a global `timecode`.
|
||||
- Cinematics use GSAP timelines to animate the active camera position and look target.
|
||||
- `dialogueCues` on a cinematic trigger dialogue IDs at times relative to the cinematic start.
|
||||
- `src/managers/stores/useGameStore.ts` exposes `isCinematicPlaying`, used to lock player input during cinematics.
|
||||
Runtime cinematic data lives in:
|
||||
|
||||
## Debug System
|
||||
```txt
|
||||
public/cinematics.json
|
||||
```
|
||||
|
||||
- Debug mode is enabled with `?debug`.
|
||||
- `src/utils/debug/Debug.ts` owns the `lil-gui` instance and debug controls.
|
||||
- `src/hooks/debug/useCameraMode.ts` and `src/hooks/debug/useSceneMode.ts` subscribe to debug state.
|
||||
- `src/components/debug/DebugPerf.tsx` lazily mounts `r3f-perf` in debug mode.
|
||||
- `src/components/ui/debug/DebugOverlayLayout.tsx` mounts the compact HTML debug overlay when enabled from `lil-gui`.
|
||||
- `src/components/ui/debug/GameStateDebugPanel.tsx` exposes current game state, main/sub-state switching, previous/next step controls, and reset.
|
||||
- `src/components/ui/debug/HandTrackingDebugPanel.tsx` shows hand tracking status, usage, loaded glove model, hand count, and fist state while hand tracking is active.
|
||||
- `src/components/ui/SceneLoadingOverlay.tsx` displays the fullscreen loading state for 3D scenes, including the production game scene, debug physics scene, and editor scene.
|
||||
- `src/components/three/handTracking/HandTrackingGlove.tsx` places the rigged `gant_l` and `gant_r` models on detected hands in the debug physics scene.
|
||||
- `src/components/debug/scene/DebugHelpers.tsx` mounts debug helpers.
|
||||
- `src/components/debug/scene/DebugCameraControls.tsx` mounts the free debug camera.
|
||||
- `lil-gui` global debug controls include camera mode, scene mode, `R3F Perf`, and `Debug Overlay`; interaction-specific controls live in the `Interaction` folder.
|
||||
Cinematics support camera keyframes, GSAP timelines, optional dialogue cues, and `isCinematicPlaying` input locking. Current world integration mounts `GameCinematics` only during the outro state.
|
||||
|
||||
## 3D Component Domains
|
||||
## Hand Tracking
|
||||
|
||||
- `src/components/three/models/` contains reusable model helpers such as `ExplodableModel`.
|
||||
- `src/components/three/interaction/` contains reusable interaction wrappers such as `InteractableObject`, `TriggerObject`, and `GrabbableObject`.
|
||||
- `src/components/three/handTracking/` contains R3F hand tracking debug models such as the glove overlays.
|
||||
- `src/components/three/gameplay/` contains the reusable production `RepairGame` flow, repair case, repair steps, and repair prompt components.
|
||||
- `src/components/three/world/` contains reusable world/environment objects such as `SkyModel`.
|
||||
Hand tracking can use:
|
||||
|
||||
- local Python backend over WebSocket
|
||||
- browser-side MediaPipe through `@mediapipe/tasks-vision`
|
||||
|
||||
Important files:
|
||||
|
||||
- `src/providers/gameplay/HandTrackingProvider.tsx`
|
||||
- `src/hooks/handTracking/useRemoteHandTracking.ts`
|
||||
- `src/hooks/handTracking/useBrowserHandTracking.ts`
|
||||
- `src/hooks/handTracking/useBothFistsHold.ts`
|
||||
- `src/components/three/handTracking/HandTrackingGlove.tsx`
|
||||
- `backend/main.py`
|
||||
|
||||
Hand tracking is activated lazily. In production it is enabled during repair steps that need hand input. In debug physics mode it is enabled when interaction context makes hand input useful.
|
||||
|
||||
Detailed hand-tracking notes live in `docs/technical/hand-tracking.md`.
|
||||
|
||||
## Editor System
|
||||
|
||||
- `src/pages/editor/page.tsx` is the route-level editor page for `/editor`.
|
||||
- `src/components/editor/EditorControls.tsx` renders the HTML editor control panel.
|
||||
- `src/components/editor/EditorDialogueManifestPanel.tsx` edits `public/sounds/dialogue/dialogues.json`.
|
||||
- `src/components/editor/EditorCinematicManifestPanel.tsx` edits `public/cinematics.json`.
|
||||
- `src/components/editor/EditorSrtPanel.tsx` renders the dialogue SRT editor inside the editor control panel.
|
||||
- `src/components/editor/scene/EditorScene.tsx` composes the editor canvas scene, camera controls, lights, shortcuts, and map rendering.
|
||||
- `src/components/editor/scene/EditorMap.tsx` renders map nodes, fallback cubes, selection highlighting, and transform controls.
|
||||
- `src/controls/editor/FlyController.tsx` provides player-style editor navigation.
|
||||
- `src/hooks/editor/useEditorSceneData.ts` loads scene data and handles folder upload fallback.
|
||||
- `src/hooks/editor/useEditorHistory.ts` owns editor undo and redo state.
|
||||
- `src/utils/editor/loadEditorScene.ts` handles editor-only folder upload parsing.
|
||||
- `src/utils/map/loadMapSceneData.ts` is shared by the game scene and editor to load `public/map.json` and resolve model URLs.
|
||||
- `src/types/editor/editor.ts` contains the shared `MapNode`, `SceneData`, and `TransformMode` types.
|
||||
- `src/types/gameplay/repairMission.ts` contains shared repair mission ids, mission steps, and guards used across store, config, debug UI, and gameplay components.
|
||||
The editor route is:
|
||||
|
||||
```txt
|
||||
/editor
|
||||
```
|
||||
|
||||
Important editor files:
|
||||
|
||||
- `src/pages/editor/page.tsx`
|
||||
- `src/components/editor/EditorControls.tsx`
|
||||
- `src/components/editor/scene/EditorScene.tsx`
|
||||
- `src/components/editor/scene/EditorMap.tsx`
|
||||
- `src/components/editor/EditorDialogueManifestPanel.tsx`
|
||||
- `src/components/editor/EditorCinematicManifestPanel.tsx`
|
||||
- `src/components/editor/EditorSrtPanel.tsx`
|
||||
- `src/hooks/editor/useEditorSceneData.ts`
|
||||
- `src/hooks/editor/useEditorHistory.ts`
|
||||
- `src/controls/editor/FlyController.tsx`
|
||||
|
||||
The editor shares `MapNode` data with the runtime map loader.
|
||||
|
||||
Local save endpoints live in `vite.config.ts`:
|
||||
|
||||
- `POST /api/save-map`
|
||||
- `POST /api/save-srt`
|
||||
- `GET /api/validate-dialogues`
|
||||
- `POST /api/save-dialogues`
|
||||
- `POST /api/save-cinematics`
|
||||
|
||||
These are Vite dev-server helpers, not production backend APIs.
|
||||
|
||||
Detailed editor notes live in `docs/technical/editor.md`.
|
||||
|
||||
## Documentation System
|
||||
|
||||
The docs route uses:
|
||||
|
||||
- `src/components/docs/DocsLayout.tsx`
|
||||
- `src/components/docs/DocsDocument.tsx`
|
||||
- `src/data/docs/docsSections.ts`
|
||||
- `src/routes/DocsRoute.tsx`
|
||||
- `src/pages/docs/**/page.tsx`
|
||||
|
||||
Docs pages import Markdown files with `?raw` and render them through `react-markdown` plus `remark-gfm`.
|
||||
|
||||
## 3D Component Domains
|
||||
|
||||
`src/components/three/` is organized by domain:
|
||||
|
||||
- `gameplay`: repair-game flow and repair components
|
||||
- `handTracking`: glove overlays
|
||||
- `interaction`: trigger/grab/focus wrappers
|
||||
- `models`: animated, simple, and explodable model helpers
|
||||
- `world`: world/environment objects
|
||||
|
||||
## Map Data
|
||||
|
||||
- `public/map.json` is expected to be a `MapNode[]`.
|
||||
- Each map node `name` maps to `public/models/{name}/model.glb` when available, with `public/models/{name}/model.gltf` kept as fallback.
|
||||
- The editor renders a fallback cube for missing models.
|
||||
- The game scene renders fallback cubes for nodes whose model cannot be resolved.
|
||||
- The game scene currently uses `terrain` as the collision source for the player octree. Additional collision nodes should be explicit lightweight collision assets, not arbitrary visible decoration models.
|
||||
Runtime map data:
|
||||
|
||||
```txt
|
||||
public/map.json
|
||||
```
|
||||
|
||||
Expected shape:
|
||||
|
||||
```ts
|
||||
interface MapNode {
|
||||
name: string;
|
||||
type: string;
|
||||
position: [number, number, number];
|
||||
rotation: [number, number, number];
|
||||
scale: [number, number, number];
|
||||
}
|
||||
```
|
||||
|
||||
Each `name` maps to:
|
||||
|
||||
```txt
|
||||
public/models/{name}/model.glb
|
||||
public/models/{name}/model.gltf
|
||||
```
|
||||
|
||||
## Current Limitations
|
||||
|
||||
- The repository is a prototype, not the full intended game runtime.
|
||||
- `src/world/debug/TestMap.tsx` is part of the active scene composition.
|
||||
- There is no central gameplay orchestrator such as `GameManager`.
|
||||
- Mission state exists in Zustand and the repair flow is implemented as a prototype for the current repair missions.
|
||||
- Cinematics and dialogues exist as prototype timecode-driven systems; dialogue branching and broader gameplay orchestration are still limited.
|
||||
- The player uses octree collision and simple movement rules, not a complete gameplay physics stack.
|
||||
- Editor save-to-server is implemented as a Vite dev-server plugin, not a production backend API.
|
||||
- The repository is still a prototype.
|
||||
- There is no central production `GameManager`.
|
||||
- The repair game is implemented, but broader mission orchestration is still light.
|
||||
- `useRepairMovementLocked()` currently returns `false`, so repair movement lock is disabled even though the rule and UI component exist.
|
||||
- The repair-runtime setting is stored in settings but not consumed by the repair-game implementation.
|
||||
- Player collision and Rapier gameplay physics are separate systems.
|
||||
- Editor persistence is local development tooling only.
|
||||
- Debug systems are still part of active scene composition and should remain easy to identify.
|
||||
|
||||
@@ -95,20 +95,11 @@ If any ray hits the object while the object is within `INTERACTION_RADIUS`, the
|
||||
|
||||
## Depth Handling
|
||||
|
||||
Because MediaPipe `z` is relative, the frontend captures the starting depth when the grab begins:
|
||||
Because MediaPipe `z` is relative and noisy, the current frontend does not use it as a direct world-depth controller for object grabbing.
|
||||
|
||||
```txt
|
||||
initialHandZ = hand.z
|
||||
initialHoldDistance = hit.distance
|
||||
```
|
||||
Instead, `GrabbableObject` computes a ray from the 2D hand center and moves the object toward a configurable hold distance in front of the active camera. That hold distance is shared with the mouse grab path and can be tuned in the debug GUI.
|
||||
|
||||
While holding, the object distance from the camera is adjusted by the change in hand depth:
|
||||
|
||||
```txt
|
||||
holdDistance = initialHoldDistance + (hand.z - initialHandZ) * sensitivity
|
||||
```
|
||||
|
||||
The final hold distance is clamped between the configured grab minimum and maximum distances to avoid unstable movement.
|
||||
This is less expressive than true depth-aware hand movement, but it is more stable for the current first-person prototype.
|
||||
|
||||
## UI And Debug
|
||||
|
||||
@@ -131,7 +122,7 @@ The glove models are intentionally smaller than the raw SVG overlay so they do n
|
||||
## Known Limitations
|
||||
|
||||
- Production usage is currently limited to repair mission steps that explicitly need hands.
|
||||
- MediaPipe depth is relative and can be noisy.
|
||||
- MediaPipe depth is relative and currently not used for stable object depth control.
|
||||
- The virtual hit zone is an approximation based on multiple raycasts, not a real 3D collider.
|
||||
- There is no smoothing layer for hand position or depth yet.
|
||||
- The SVG hand visualization is a fallback, not the primary display when glove models load correctly.
|
||||
|
||||
@@ -0,0 +1,240 @@
|
||||
# Interaction System Technical Notes
|
||||
|
||||
This document explains the shared trigger, grab, focus, and hand-grab system.
|
||||
|
||||
## Purpose
|
||||
|
||||
The app has several ways for the player to affect the 3D scene:
|
||||
|
||||
- press `E` on focused trigger objects
|
||||
- hold the primary mouse button on grabbable objects
|
||||
- close a tracked hand into a fist to grab hand-controlled objects
|
||||
- release objects and optionally snap them into target positions
|
||||
|
||||
The implementation keeps those rules in a reusable interaction layer so gameplay features such as the repair game do not each create their own input system.
|
||||
|
||||
## Main Files
|
||||
|
||||
| File | Responsibility |
|
||||
| --------------------------------------------------------- | ----------------------------------------------- |
|
||||
| `src/managers/InteractionManager.ts` | Shared interaction state and imperative actions |
|
||||
| `src/hooks/interaction/useInteraction.ts` | React subscription to the manager |
|
||||
| `src/components/three/interaction/InteractableObject.tsx` | Distance/raycast focus detection |
|
||||
| `src/components/three/interaction/TriggerObject.tsx` | Press-to-trigger wrapper |
|
||||
| `src/components/three/interaction/GrabbableObject.tsx` | Physics-backed grab and hand grab wrapper |
|
||||
| `src/components/ui/InteractPrompt.tsx` | HTML prompt for focused trigger interactions |
|
||||
| `src/world/player/PlayerController.tsx` | Keyboard/mouse input bridge |
|
||||
|
||||
## Architecture
|
||||
|
||||
The interaction system has three layers:
|
||||
|
||||
1. R3F objects detect focus and register handles.
|
||||
2. `InteractionManager` stores the current interaction snapshot.
|
||||
3. UI and player input read the snapshot and trigger the selected action.
|
||||
|
||||
This is intentionally not Zustand. Interaction focus and holding state are short-lived, frame-adjacent runtime state. A small singleton plus `useSyncExternalStore` is a better fit than putting high-frequency interaction details into the durable game progression store.
|
||||
|
||||
## Interaction Snapshot
|
||||
|
||||
The snapshot type lives in:
|
||||
|
||||
```txt
|
||||
src/types/interaction/interaction.ts
|
||||
```
|
||||
|
||||
```ts
|
||||
interface InteractionSnapshot {
|
||||
focused: InteractableHandle | null;
|
||||
nearby: boolean;
|
||||
holding: boolean;
|
||||
handHolding: boolean;
|
||||
}
|
||||
```
|
||||
|
||||
Meaning:
|
||||
|
||||
- `focused`: the interactable currently aimed at by the camera ray
|
||||
- `nearby`: at least one interactable is within interaction radius
|
||||
- `holding`: mouse/player-controller grab is active
|
||||
- `handHolding`: hand-tracking grab is active
|
||||
|
||||
`nearby`, `holding`, and `handHolding` are also used by the hand-tracking provider to decide when webcam tracking should stay active in the debug physics scene.
|
||||
|
||||
## Focus Detection
|
||||
|
||||
Focus detection lives in:
|
||||
|
||||
```txt
|
||||
src/components/three/interaction/InteractableObject.tsx
|
||||
```
|
||||
|
||||
Each frame, it:
|
||||
|
||||
1. finds the interactable world position from its Rapier body or group transform
|
||||
2. checks distance from the camera
|
||||
3. marks the handle as nearby if it is inside radius
|
||||
4. raycasts from the camera forward direction
|
||||
5. sets the focused handle when the ray hits the object
|
||||
6. clears focus if the object is no longer nearby or no longer aimed at
|
||||
|
||||
This gives a simple first-person interaction model: the player must be close enough and looking at the object.
|
||||
|
||||
## Trigger Objects
|
||||
|
||||
Trigger implementation:
|
||||
|
||||
```txt
|
||||
src/components/three/interaction/TriggerObject.tsx
|
||||
```
|
||||
|
||||
`TriggerObject` wraps children in a fixed Rapier body and exposes a trigger handle.
|
||||
|
||||
When triggered, it can:
|
||||
|
||||
- play an optional SFX through `AudioManager`
|
||||
- call `onTrigger`
|
||||
- spawn an optional model at an offset
|
||||
|
||||
Typical users:
|
||||
|
||||
- repair-object inspection
|
||||
- repair-case open/fragment interaction
|
||||
- install target
|
||||
- completion target
|
||||
- debug scene trigger sphere
|
||||
|
||||
## Grabbable Objects
|
||||
|
||||
Grab implementation:
|
||||
|
||||
```txt
|
||||
src/components/three/interaction/GrabbableObject.tsx
|
||||
```
|
||||
|
||||
`GrabbableObject` wraps children in a dynamic Rapier body and exposes a grab handle.
|
||||
|
||||
Mouse/controller grab flow:
|
||||
|
||||
1. Player focuses the object.
|
||||
2. Mouse down calls `InteractionManager.pressInteract()`.
|
||||
3. The object enters holding mode.
|
||||
4. Each frame, velocity is pushed toward a hold target in front of the camera.
|
||||
5. Mouse up calls `releaseInteract()`.
|
||||
6. The object can snap to the nearest configured target.
|
||||
|
||||
Important tuning values live in:
|
||||
|
||||
```txt
|
||||
src/data/interaction/grabConfig.ts
|
||||
```
|
||||
|
||||
The debug GUI exposes hold stiffness, throw boost, and hold distance.
|
||||
|
||||
## Snap-To-Target
|
||||
|
||||
`GrabbableObject` supports:
|
||||
|
||||
- `snapTargets`
|
||||
- `snapRadius`
|
||||
- `snapDuration`
|
||||
- `onSnap`
|
||||
|
||||
On release, the object finds the nearest target inside `snapRadius`. If a target is found, GSAP animates the Rapier body translation to that target and calls `onSnap`.
|
||||
|
||||
The repair game uses this to place replacement parts and broken parts into case placeholders.
|
||||
|
||||
## Hand-Controlled Grab
|
||||
|
||||
If `handControlled` is true, `GrabbableObject` also reads:
|
||||
|
||||
```txt
|
||||
useHandTrackingSnapshot()
|
||||
```
|
||||
|
||||
Hand grab flow:
|
||||
|
||||
1. Find a detected hand where `hand.isFist` is true.
|
||||
2. Compute the visual center of the hand from landmark bounds.
|
||||
3. Convert that screen-space point to a camera ray.
|
||||
4. Raycast against the object.
|
||||
5. Use a small set of offset rays around the center to make hit detection more forgiving.
|
||||
6. If the object is in range and hit, enter `handHolding`.
|
||||
7. Move the object toward a hold target in front of the camera while the fist remains closed.
|
||||
8. When the fist opens or disappears, release and snap if possible.
|
||||
|
||||
This is an approximation, not a full 3D hand collider. It is a practical prototype compromise because MediaPipe gives normalized camera-space landmarks and relative depth, not stable world-space hand meshes.
|
||||
|
||||
## Player Input Bridge
|
||||
|
||||
The player controller owns raw keyboard and mouse input:
|
||||
|
||||
```txt
|
||||
src/world/player/PlayerController.tsx
|
||||
```
|
||||
|
||||
It calls:
|
||||
|
||||
- `interaction.pressInteract()` when `E` is pressed and the focused handle is a trigger
|
||||
- `interaction.pressInteract()` on mouse down when the focused handle is a grab
|
||||
- `interaction.releaseInteract()` on mouse up when a grab is active
|
||||
|
||||
Input is ignored while:
|
||||
|
||||
- the settings menu is open
|
||||
- a cinematic is playing
|
||||
|
||||
Movement lock is read separately from `useRepairMovementLocked`, but that hook currently returns `false` on this branch.
|
||||
|
||||
## UI Prompt
|
||||
|
||||
The prompt lives in:
|
||||
|
||||
```txt
|
||||
src/components/ui/InteractPrompt.tsx
|
||||
```
|
||||
|
||||
It appears only when:
|
||||
|
||||
- camera mode is `player`
|
||||
- a focused interaction exists
|
||||
- the player is not holding an object
|
||||
- the focused interaction is a trigger
|
||||
|
||||
The prompt does not appear for grab objects, because grabs are mouse/hand actions rather than `E` trigger actions.
|
||||
|
||||
## Debug Controls
|
||||
|
||||
Interaction debugging is split between:
|
||||
|
||||
- lil-gui `Interaction` folder for showing interaction spheres
|
||||
- lil-gui `GrabbableObject` folder for grab tuning
|
||||
- debug physics scene for live trigger/grab testing
|
||||
- hand-tracking debug panel for hand grab state
|
||||
|
||||
Use:
|
||||
|
||||
```txt
|
||||
http://localhost:5173/?debug
|
||||
```
|
||||
|
||||
Then switch the scene mode to `Physics` from lil-gui.
|
||||
|
||||
## Why This Architecture Works
|
||||
|
||||
The interaction layer separates concerns:
|
||||
|
||||
- R3F objects know their distance/raycast hit state.
|
||||
- The player controller owns input events.
|
||||
- UI only subscribes to a snapshot.
|
||||
- Gameplay objects receive semantic callbacks like `onTrigger`, `onSnap`, or `onPositionChange`.
|
||||
|
||||
This keeps the repair game focused on gameplay rules instead of low-level input plumbing.
|
||||
|
||||
## Known Limitations
|
||||
|
||||
- Only one focused handle is stored at a time.
|
||||
- The focus rule is camera ray based, so side-facing interactions can feel strict without larger meshes or radii.
|
||||
- Hand grab uses screen-space raycasts, not physical hand colliders.
|
||||
- The manager is singleton-based, so tests must call `destroy()` or isolate state when needed.
|
||||
- `nearby` is boolean, not a list exposed to UI, so the current UI cannot rank multiple nearby objects.
|
||||
@@ -0,0 +1,365 @@
|
||||
# Repair Game Technical Notes
|
||||
|
||||
This document explains the implementation of the reusable repair-game flow.
|
||||
|
||||
## Purpose
|
||||
|
||||
The repair game is the current core gameplay loop. It gives three missions the same interaction structure while allowing mission-specific assets, broken parts, replacement choices, prompts, and timing to live in data.
|
||||
|
||||
Implemented missions:
|
||||
|
||||
| Mission | Object | Role |
|
||||
| -------- | ------------- | --------------------------------------------- |
|
||||
| `bike` | E-bike | Repair a damaged cooling core |
|
||||
| `pylone` | Power pylon | Restore relay/panel-like broken parts |
|
||||
| `ferme` | Vertical farm | Stabilize irrigation/sensor-like broken parts |
|
||||
|
||||
## Main Files
|
||||
|
||||
| File | Responsibility |
|
||||
| ---------------------------------------------- | ------------------------------------------------- |
|
||||
| `src/components/three/gameplay/RepairGame.tsx` | Orchestrates the repair step machine |
|
||||
| `src/data/gameplay/repairMissions.ts` | Mission-specific data |
|
||||
| `src/types/gameplay/repairMission.ts` | Mission ids, step ids, guards |
|
||||
| `src/managers/stores/useGameStore.ts` | Global progression and mission transitions |
|
||||
| `src/world/GameStageContent.tsx` | Production placement of the three repair missions |
|
||||
| `src/world/debug/TestMap.tsx` | Debug repair playground placement |
|
||||
|
||||
## State Machine
|
||||
|
||||
Repair mission steps are defined in:
|
||||
|
||||
```txt
|
||||
src/types/gameplay/repairMission.ts
|
||||
```
|
||||
|
||||
```txt
|
||||
locked -> waiting -> inspected -> fragmented -> scanning -> repairing -> reassembling -> done
|
||||
```
|
||||
|
||||
The practical flow is:
|
||||
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> locked
|
||||
locked --> waiting: mission unlocked
|
||||
waiting --> inspected: inspect mission object
|
||||
inspected --> fragmented: repair-case trigger or two-fists hold
|
||||
fragmented --> scanning: fragmentation timer
|
||||
scanning --> repairing: scan sequence complete
|
||||
repairing --> reassembling: install target validates
|
||||
reassembling --> done: reassembly timer
|
||||
done --> [*]: completion target calls completeMission
|
||||
```
|
||||
|
||||
There is no dedicated finite-state-machine library. The state machine is intentionally lightweight and distributed across:
|
||||
|
||||
- `MissionStep` union types
|
||||
- Zustand transition helpers
|
||||
- conditional rendering in `RepairGame`
|
||||
- callbacks passed to step components
|
||||
|
||||
For the current prototype, this is readable and low overhead. If mission rules become much more branched, a centralized mission orchestrator or FSM library would become more useful.
|
||||
|
||||
## Integration With Zustand
|
||||
|
||||
The durable state lives in:
|
||||
|
||||
```txt
|
||||
src/managers/stores/useGameStore.ts
|
||||
```
|
||||
|
||||
`RepairGame` reads:
|
||||
|
||||
- `mainState`
|
||||
- current step for its mission
|
||||
|
||||
`RepairGame` writes:
|
||||
|
||||
- `setMissionStep(mission, nextStep)`
|
||||
- `completeMission(mission)`
|
||||
|
||||
The important architectural choice is that reusable repair components do not call `setBikeState`, `setPyloneState`, or `setFermeState` directly. They use generic mission actions so the same component can run for all three missions.
|
||||
|
||||
## Data-Driven Mission Config
|
||||
|
||||
Mission variation lives in:
|
||||
|
||||
```txt
|
||||
src/data/gameplay/repairMissions.ts
|
||||
```
|
||||
|
||||
Each mission config defines:
|
||||
|
||||
- `id`
|
||||
- `label`
|
||||
- `description`
|
||||
- `modelPath`
|
||||
- optional `modelScale`
|
||||
- `stageUiPath`
|
||||
- `interactUiPath`
|
||||
- `brokenUiPath`
|
||||
- repair case transform
|
||||
- optional scan/reassembly timings
|
||||
- `requiredReplacementPartId`
|
||||
- `brokenParts`
|
||||
- `replacementParts`
|
||||
|
||||
The main benefit is that `RepairGame` stays generic. A mission can change broken nodes, replacement choices, or prompt videos without changing the orchestration component.
|
||||
|
||||
The tradeoff is that the config can grow complex. If one future mission needs very different rules, create a mission-specific component instead of forcing every exception into the shared config.
|
||||
|
||||
## Orchestration Component
|
||||
|
||||
`RepairGame.tsx` is a step router.
|
||||
|
||||
It:
|
||||
|
||||
1. receives a `mission` id and transform props
|
||||
2. gets `config = REPAIR_MISSIONS[mission]`
|
||||
3. subscribes to the active `mainState`
|
||||
4. subscribes to the current mission step
|
||||
5. preloads mission assets
|
||||
6. mounts the component for the active step
|
||||
7. stores local runtime state needed between steps
|
||||
|
||||
Local runtime state:
|
||||
|
||||
- `casePlaceholders`: placeholder transforms emitted by the repair case GLTF
|
||||
- `scannedBrokenParts`: output of the scan sequence used by the repair step
|
||||
|
||||
Those values are local because they are transient scene/runtime details. They do not need to persist globally in Zustand.
|
||||
|
||||
## Step Components
|
||||
|
||||
### Waiting
|
||||
|
||||
File:
|
||||
|
||||
```txt
|
||||
src/components/three/gameplay/RepairInspectionObject.tsx
|
||||
```
|
||||
|
||||
The mission object is rendered with a 3D prompt video and wrapped in an interaction trigger. Pressing `E` while focused moves the mission to `inspected`.
|
||||
|
||||
### Inspected
|
||||
|
||||
Files:
|
||||
|
||||
```txt
|
||||
src/components/three/gameplay/RepairMissionCase.tsx
|
||||
src/components/three/gameplay/RepairCaseModel.tsx
|
||||
src/hooks/gameplay/useRepairFragmentationInput.ts
|
||||
```
|
||||
|
||||
The repair case appears near the mission object. The player can:
|
||||
|
||||
- aim at the case and press `E`
|
||||
- hold both fists closed for one second when hand tracking is active
|
||||
|
||||
Both paths move to `fragmented`.
|
||||
|
||||
Important current detail: `useRepairMovementLocked()` currently returns `false`, so the movement-lock rule and indicator are present but disabled in the current branch.
|
||||
|
||||
### Fragmented
|
||||
|
||||
File:
|
||||
|
||||
```txt
|
||||
src/components/three/models/ExplodableModel.tsx
|
||||
```
|
||||
|
||||
The mission object is shown split apart. A timer then moves the mission to `scanning`.
|
||||
|
||||
The default delay comes from:
|
||||
|
||||
```txt
|
||||
REPAIR_FRAGMENTATION_SEQUENCE_SECONDS
|
||||
```
|
||||
|
||||
### Scanning
|
||||
|
||||
File:
|
||||
|
||||
```txt
|
||||
src/components/three/gameplay/RepairScanSequence.tsx
|
||||
```
|
||||
|
||||
The scan sequence:
|
||||
|
||||
- keeps the exploded model visible
|
||||
- receives model parts from `ExplodableModel`
|
||||
- advances an active part index over time
|
||||
- renders `RepairScanVisual` on the active part
|
||||
- reveals broken-part highlights when configured broken parts have been reached
|
||||
- returns `RepairScannedBrokenPart[]` when done
|
||||
|
||||
Broken-part lookup first tries `brokenParts[].nodeName`. If no configured node matches, it falls back to the first available exploded parts. This fallback is useful while GLTF node names are still unstable, but precise `nodeName` config is safer for production.
|
||||
|
||||
### Repairing
|
||||
|
||||
File:
|
||||
|
||||
```txt
|
||||
src/components/three/gameplay/RepairRepairingStep.tsx
|
||||
```
|
||||
|
||||
This is the densest gameplay step.
|
||||
|
||||
It renders:
|
||||
|
||||
- install target
|
||||
- placeholder markers
|
||||
- grabbable replacement parts
|
||||
- grabbable broken parts to store
|
||||
- placement feedback
|
||||
- ready-to-install prompt
|
||||
|
||||
Important local state:
|
||||
|
||||
- `placedPartIds`: replacement parts that snapped near a placeholder
|
||||
- `depositedBrokenPartIds`: broken parts stored in the case
|
||||
- `showBlockedInstallFeedback`: temporary visual feedback when install is attempted too early
|
||||
|
||||
Validation:
|
||||
|
||||
```txt
|
||||
correct replacement part placed
|
||||
AND every scanned broken part deposited
|
||||
```
|
||||
|
||||
Only then does the install target call `onRepair()` and move to `reassembling`.
|
||||
|
||||
### Reassembling
|
||||
|
||||
File:
|
||||
|
||||
```txt
|
||||
src/components/three/gameplay/RepairReassemblyStep.tsx
|
||||
```
|
||||
|
||||
The exploded model animates back into assembled form and completion particles play. A timer then moves the mission to `done`.
|
||||
|
||||
Mission configs can override the default reassembly duration.
|
||||
|
||||
### Done
|
||||
|
||||
File:
|
||||
|
||||
```txt
|
||||
src/components/three/gameplay/RepairCompletionStep.tsx
|
||||
```
|
||||
|
||||
The repaired object remains visible. The player validates the completion target, then:
|
||||
|
||||
1. the repair case closes
|
||||
2. the case plays its exit animation
|
||||
3. `completeMission(mission)` advances the global game progression
|
||||
|
||||
## Repair Case Details
|
||||
|
||||
The case model implementation lives in:
|
||||
|
||||
```txt
|
||||
src/components/three/gameplay/RepairCaseModel.tsx
|
||||
```
|
||||
|
||||
It handles:
|
||||
|
||||
- GLTF loading through `useLoggedGLTF`
|
||||
- clone creation through `useClonedObject`
|
||||
- pop-in animation
|
||||
- lid open/close animation
|
||||
- open/close SFX through `AudioManager`
|
||||
- proximity-based floating
|
||||
- small rotation wobble
|
||||
- exit animation
|
||||
- placeholder discovery
|
||||
|
||||
Placeholder discovery is data-friendly:
|
||||
|
||||
```txt
|
||||
placeholder_*
|
||||
```
|
||||
|
||||
Any GLTF node whose name starts with that prefix is exported to the repair step as a placement target. This lets artists move placeholder transforms in the model file without hard-coding every placement point in TypeScript.
|
||||
|
||||
## Interaction Dependencies
|
||||
|
||||
The repair game depends on the shared interaction layer:
|
||||
|
||||
- `RepairInspectionObject` uses `InteractableObject`
|
||||
- `RepairMissionCase` uses `TriggerObject`
|
||||
- `RepairRepairingStep` uses `GrabbableObject` and `TriggerObject`
|
||||
- completion uses `TriggerObject`
|
||||
|
||||
This keeps the repair game from owning raw keyboard or mouse listeners for every object. The player controller handles input, and interaction components decide what is focused.
|
||||
|
||||
## Hand Tracking Dependencies
|
||||
|
||||
Hand tracking participates in two places:
|
||||
|
||||
- `useRepairFragmentationInput` uses `useBothFistsHold`
|
||||
- `GrabbableObject` can be `handControlled`
|
||||
|
||||
`HandTrackingProvider` enables tracking during the repair steps that are expected to use hands:
|
||||
|
||||
```txt
|
||||
inspected
|
||||
repairing
|
||||
reassembling
|
||||
done
|
||||
```
|
||||
|
||||
This avoids keeping the webcam active for the whole game scene.
|
||||
|
||||
## Runtime Placement
|
||||
|
||||
Production placement lives in:
|
||||
|
||||
```txt
|
||||
src/world/GameStageContent.tsx
|
||||
```
|
||||
|
||||
Current positions:
|
||||
|
||||
```tsx
|
||||
<RepairGame mission="bike" position={[8, 0, -6]} />
|
||||
<RepairGame mission="pylone" position={[64, 0, -66]} />
|
||||
<RepairGame mission="ferme" position={[-24, 0, 42]} />
|
||||
```
|
||||
|
||||
Only the repair game whose `mission` matches `useGameStore().mainState` renders active content.
|
||||
|
||||
## Debug Placement
|
||||
|
||||
Debug placement lives in:
|
||||
|
||||
```txt
|
||||
src/world/debug/TestMap.tsx
|
||||
```
|
||||
|
||||
The debug scene mounts repair playground zones for all missions. Use `?debug`, switch to the physics scene in lil-gui, then use the game-state debug panel to activate the mission you want to test.
|
||||
|
||||
## Why This Is A Good Review Focus
|
||||
|
||||
This feature shows several important frontend/game architecture skills:
|
||||
|
||||
- state-driven scene composition
|
||||
- data-driven feature variation
|
||||
- React state for step-local runtime values
|
||||
- Zustand for durable game progression
|
||||
- R3F component boundaries
|
||||
- Rapier object interaction
|
||||
- hand tracking integration
|
||||
- audio feedback
|
||||
- GLTF traversal
|
||||
- graceful asset fallbacks
|
||||
|
||||
## Known Limitations
|
||||
|
||||
- Movement lock is currently disabled by an early `return false` in `useRepairMovementLocked`.
|
||||
- The repair-game runtime setting in the options menu is stored but not consumed by `RepairGame`.
|
||||
- Broken-part scan fallback can produce incorrect matches if GLTF node names are missing.
|
||||
- Mission progression is still prototype-level and not owned by a central `GameManager`.
|
||||
- The same repair flow covers all missions. Very different future missions may need dedicated components.
|
||||
@@ -0,0 +1,252 @@
|
||||
# Scene Runtime And Loading
|
||||
|
||||
This document explains how the playable route boots the 3D world, loads the map, gates gameplay readiness, and spawns the player.
|
||||
|
||||
## Purpose
|
||||
|
||||
The playable scene has heavy asynchronous work: map JSON, GLTF models, collision meshes, octree construction, Rapier stage content, audio, dialogues, and the player controller.
|
||||
|
||||
The current runtime avoids spawning the player too early. That matters because the player controller needs a ready octree, and the repair game needs the production stage to be mounted before the user starts interacting with objects.
|
||||
|
||||
## Entry Flow
|
||||
|
||||
```txt
|
||||
src/main.tsx
|
||||
-> src/App.tsx
|
||||
-> src/router.tsx
|
||||
-> src/pages/page.tsx
|
||||
-> HandTrackingProvider
|
||||
-> Canvas
|
||||
-> World
|
||||
-> DebugPerf
|
||||
-> GameUI
|
||||
-> SceneLoadingOverlay
|
||||
```
|
||||
|
||||
`HomePage` owns the visible loading state and passes `onLoadingStateChange` down to `World`.
|
||||
|
||||
The loading progress in `HomePage` is monotonic:
|
||||
|
||||
- if the scene is already ready, a late loading event is ignored
|
||||
- progress can only increase while the scene is booting
|
||||
|
||||
This prevents the overlay from jumping backward when nested loaders finish in a slightly different order.
|
||||
|
||||
## World Composition
|
||||
|
||||
`src/world/World.tsx` is the main scene composer.
|
||||
|
||||
Always-mounted systems:
|
||||
|
||||
- `Environment`
|
||||
- `Lighting`
|
||||
- debug helpers when `?debug` is active
|
||||
- optional hand-tracking glove overlays
|
||||
- optional debug camera controls
|
||||
|
||||
Game scene systems:
|
||||
|
||||
- `GameMap`
|
||||
- Rapier `Physics` wrapping `GameStageContent`
|
||||
- `GameMusic`
|
||||
- `GameDialogues`
|
||||
- `GameCinematics`, currently only in `mainState === "outro"`
|
||||
- `Player`
|
||||
|
||||
Debug physics scene systems:
|
||||
|
||||
- `TestMap`
|
||||
- `Player`
|
||||
|
||||
## Loading State Owner
|
||||
|
||||
The world loading gate lives in:
|
||||
|
||||
```txt
|
||||
src/hooks/world/useWorldSceneLoading.ts
|
||||
```
|
||||
|
||||
It tracks:
|
||||
|
||||
- `octree`: collision octree built from collision source meshes
|
||||
- `gameMapLoaded`: map data and visible map nodes settled
|
||||
- `gameStageLoaded`: Rapier gameplay stage mounted
|
||||
- `showGameStage`: true when the map is ready enough to mount gameplay content
|
||||
- `gameplayReady`: true when map, stage, and octree are all ready
|
||||
|
||||
The final game-scene readiness condition is:
|
||||
|
||||
```ts
|
||||
showGameStage && gameStageLoaded && octree !== null;
|
||||
```
|
||||
|
||||
The debug physics scene is ready when:
|
||||
|
||||
```ts
|
||||
octree !== null;
|
||||
```
|
||||
|
||||
## Map Loading
|
||||
|
||||
Map loading starts in:
|
||||
|
||||
```txt
|
||||
src/world/GameMap.tsx
|
||||
```
|
||||
|
||||
`GameMap` calls:
|
||||
|
||||
```txt
|
||||
src/utils/map/loadMapSceneData.ts
|
||||
```
|
||||
|
||||
That utility:
|
||||
|
||||
1. fetches `/map.json`
|
||||
2. validates it as a `MapNode[]`
|
||||
3. deduplicates model names
|
||||
4. checks `public/models/{name}/model.glb`
|
||||
5. falls back to `public/models/{name}/model.gltf`
|
||||
6. returns `{ mapNodes, models }`
|
||||
|
||||
If a model is missing, the map still renders a fallback cube. This keeps the scene inspectable while assets are incomplete.
|
||||
|
||||
## Model Settling
|
||||
|
||||
`GameMap` counts settled map nodes.
|
||||
|
||||
A node settles when:
|
||||
|
||||
- it has no model and renders a fallback cube
|
||||
- its GLTF model instance has mounted
|
||||
- a model error boundary catches a load/render error and renders fallback
|
||||
|
||||
This prevents `GameMapCollision` from building collision before the visible map has reached a stable state.
|
||||
|
||||
## Collision Loading
|
||||
|
||||
Collision loading lives in:
|
||||
|
||||
```txt
|
||||
src/world/GameMapCollision.tsx
|
||||
```
|
||||
|
||||
The current production collision source is intentionally small:
|
||||
|
||||
```ts
|
||||
const MAP_COLLISION_NODE_NAMES = new Set(["terrain"]);
|
||||
```
|
||||
|
||||
Only matching map nodes are loaded into the invisible collision group. Then:
|
||||
|
||||
```txt
|
||||
src/hooks/three/useOctreeGraphNode.ts
|
||||
```
|
||||
|
||||
builds the Three.js octree from that group and sends it back through `onOctreeReady`.
|
||||
|
||||
This is a performance choice. Building a player collision octree from every visible prop can overload the browser and make the scene fragile.
|
||||
|
||||
## Stage Loading
|
||||
|
||||
Production gameplay content is mounted by:
|
||||
|
||||
```txt
|
||||
src/world/GameStageContent.tsx
|
||||
```
|
||||
|
||||
`World` wraps it in Rapier `Physics`, but only after `GameMap` reports loaded:
|
||||
|
||||
```tsx
|
||||
{
|
||||
showGameStage ? (
|
||||
<Physics>
|
||||
<GameStageLoaded onLoaded={handleGameStageLoaded} />
|
||||
<GameStageContent />
|
||||
</Physics>
|
||||
) : null;
|
||||
}
|
||||
```
|
||||
|
||||
`GameStageLoaded` is a tiny component that calls `handleGameStageLoaded()` after mount. It gives the loading hook a clear signal that the Rapier stage has entered the scene graph.
|
||||
|
||||
## Player Spawn Gate
|
||||
|
||||
The player is spawned only when the active camera mode is not debug and the active scene is ready.
|
||||
|
||||
```ts
|
||||
const spawnPlayer =
|
||||
cameraMode !== "debug" &&
|
||||
(sceneMode === "game" ? gameplayReady : octree !== null);
|
||||
```
|
||||
|
||||
This avoids two common bugs:
|
||||
|
||||
- the player starts falling or clipping before collision is ready
|
||||
- gameplay starts while the map/stage is still mounting
|
||||
|
||||
The production player spawn uses:
|
||||
|
||||
```txt
|
||||
PLAYER_SPAWN_POSITION_GAME
|
||||
```
|
||||
|
||||
The debug physics scene uses:
|
||||
|
||||
```txt
|
||||
PLAYER_SPAWN_POSITION_PHYSICS
|
||||
```
|
||||
|
||||
## Audio And Narrative Mounting
|
||||
|
||||
`GameMusic`, `GameDialogues`, and `Player` mount together after `spawnPlayer` is true.
|
||||
|
||||
This means background music and global dialogue timecode processing do not start while the loading overlay is still preparing the scene.
|
||||
|
||||
`GameCinematics` is currently gated further:
|
||||
|
||||
```tsx
|
||||
{
|
||||
mainState === "outro" ? <GameCinematics /> : null;
|
||||
}
|
||||
```
|
||||
|
||||
So cinematic playback is part of the outro path today, not a global always-on system.
|
||||
|
||||
## Debug Modes
|
||||
|
||||
Debug is enabled with:
|
||||
|
||||
```txt
|
||||
http://localhost:5173/?debug
|
||||
```
|
||||
|
||||
`src/utils/debug/Debug.ts` provides:
|
||||
|
||||
- camera mode: `player` or `debug`
|
||||
- scene mode: `game` or `physics`
|
||||
- R3F perf toggle
|
||||
- debug overlay toggle
|
||||
- hand-tracking source
|
||||
- hand SVG visibility
|
||||
- interaction sphere visibility
|
||||
|
||||
Important current detail: the older boot flags such as `noMusic`, `noCinematics`, `noMap`, `noDialogues`, `noOctree`, and `noPlayer` are not part of the current `develop` runtime path.
|
||||
|
||||
## Why This Architecture Works
|
||||
|
||||
The runtime uses React composition as the scene orchestration layer:
|
||||
|
||||
- if JSX is mounted, the Three/Rapier object exists
|
||||
- if JSX is unmounted, the object leaves the scene
|
||||
- loading gates are explicit booleans instead of hidden timing assumptions
|
||||
|
||||
This keeps the prototype understandable while still preventing expensive systems from starting too early.
|
||||
|
||||
## Risks And Watch Points
|
||||
|
||||
- Loading progress is manually estimated, not measured from every asset byte.
|
||||
- The production collision source is currently only `terrain`; extra collision needs explicit lightweight nodes.
|
||||
- Rapier gameplay physics and player octree collision are separate systems and can diverge if future features assume they are the same world.
|
||||
- `GameCinematics` is not globally mounted anymore; docs or tests that expect intro cinematics to auto-run should be updated before relying on that path.
|
||||
- Scene readiness is stored in React state, so remounting the route restarts the loading flow.
|
||||
@@ -0,0 +1,22 @@
|
||||
# Three Debugging
|
||||
|
||||
Use the dedicated debug mode when you need Chrome DevTools to step into Three.js internals.
|
||||
|
||||
```bash
|
||||
npm run dev:three-debug
|
||||
```
|
||||
|
||||
This mode aliases `three` to `node_modules/three/src/Three.js` and disables Vite dependency pre-bundling for Three. In DevTools, open `node_modules/three/src/renderers/WebGLRenderer.js` and place a breakpoint inside:
|
||||
|
||||
```js
|
||||
this.render = function (scene, camera) {
|
||||
```
|
||||
|
||||
Reload the page or trigger a frame. When the breakpoint hits, inspect `scene`, `camera`, renderer state, visible objects, matrices, materials, and `this.info.render`.
|
||||
|
||||
If DevTools still opens a bundled file, stop the dev server, clear Vite's cached deps, and restart:
|
||||
|
||||
```bash
|
||||
rm -rf node_modules/.vite
|
||||
npm run dev:three-debug
|
||||
```
|
||||
+141
-83
@@ -1,72 +1,85 @@
|
||||
# Zustand Game State
|
||||
# Zustand Stores
|
||||
|
||||
This document explains how Zustand is used in the current project.
|
||||
|
||||
## Why Zustand Exists Here
|
||||
|
||||
The project needs one shared source of truth for the player's progression through the experience.
|
||||
The project needs shared state that is durable enough to be read by multiple React and React Three Fiber systems.
|
||||
|
||||
The current progression is split into main states:
|
||||
Zustand is used for:
|
||||
|
||||
- game progression
|
||||
- settings
|
||||
- subtitle display
|
||||
|
||||
It is not used for high-frequency frame values. Values such as player velocity, temporary vectors, object positions during a grab, raycasts, and animation-loop data stay in refs or manager-local state.
|
||||
|
||||
## Store Locations
|
||||
|
||||
Current Zustand stores:
|
||||
|
||||
```txt
|
||||
src/managers/stores/useGameStore.ts
|
||||
src/managers/stores/useSettingsStore.ts
|
||||
src/managers/stores/useSubtitleStore.ts
|
||||
```
|
||||
|
||||
They are under `src/managers/stores/` because they are shared runtime state, not state owned by one visual component.
|
||||
|
||||
## Store Responsibilities
|
||||
|
||||
| Store | Responsibility |
|
||||
| ------------------ | ----------------------------------------------------------------- |
|
||||
| `useGameStore` | Durable game progression, mission steps, cinematic input lock |
|
||||
| `useSettingsStore` | Menu visibility, volumes, subtitle options, repair-runtime toggle |
|
||||
| `useSubtitleStore` | Currently displayed subtitle cue |
|
||||
|
||||
## Managers vs Stores
|
||||
|
||||
Managers own imperative runtime objects and side effects.
|
||||
|
||||
Examples:
|
||||
|
||||
- `AudioManager` owns audio elements, music playback, sound pools, category volumes, and optional panner nodes.
|
||||
- `InteractionManager` owns transient interaction handles and input-oriented focus/holding state.
|
||||
|
||||
Stores own durable shared state:
|
||||
|
||||
- current game phase
|
||||
- mission sub-step
|
||||
- progression flags
|
||||
- settings values
|
||||
- currently displayed subtitle cue
|
||||
|
||||
Rule of thumb:
|
||||
|
||||
- manager = runtime objects, side effects, frame-adjacent imperative logic
|
||||
- store = shared state that UI, world, or gameplay components need to subscribe to
|
||||
|
||||
## Game Store Shape
|
||||
|
||||
`useGameStore` exposes the main game progression.
|
||||
|
||||
Main states:
|
||||
|
||||
| Main state | Role |
|
||||
| ---------- | ------------------------------- |
|
||||
| `intro` | Onboarding and opening sequence |
|
||||
| `bike` | E-bike repair sequence |
|
||||
| `pylone` | Power grid sequence |
|
||||
| `ferme` | Vertical farm sequence |
|
||||
| `pylone` | Power pylon repair sequence |
|
||||
| `ferme` | Vertical farm repair sequence |
|
||||
| `outro` | Ending sequence |
|
||||
|
||||
Each main state can also own smaller sub state, such as the current mission step, dialogue audio, or completion flags.
|
||||
Other important state:
|
||||
|
||||
Zustand is useful because React and React Three Fiber components can subscribe only to the state slice they need. When that slice changes, only the subscribed components re-render.
|
||||
- `isCinematicPlaying`
|
||||
- `intro`
|
||||
- `bike`
|
||||
- `pylone`
|
||||
- `ferme`
|
||||
- `outro`
|
||||
|
||||
## Store Location
|
||||
|
||||
The game progression store lives here:
|
||||
|
||||
```txt
|
||||
src/managers/stores/useGameStore.ts
|
||||
```
|
||||
|
||||
The store is placed under `src/managers/stores/` because it belongs to the gameplay orchestration layer, not to a specific visual component.
|
||||
|
||||
## Managers vs Store
|
||||
|
||||
Managers are responsible for local runtime objects and imperative behavior.
|
||||
|
||||
Examples:
|
||||
|
||||
- `AudioManager` owns audio elements and sound pools.
|
||||
- `InteractionManager` owns transient interaction handles and input-oriented behavior.
|
||||
|
||||
Managers can read from or write to the Zustand store when their local behavior needs to affect global gameplay progression.
|
||||
|
||||
The Zustand store is responsible for durable global state:
|
||||
|
||||
- current main state
|
||||
- mission sub state
|
||||
- progression flags
|
||||
- dialogue/audio references
|
||||
- state transitions
|
||||
|
||||
Rule of thumb:
|
||||
|
||||
- manager = runtime objects, side effects, and local imperative logic
|
||||
- store = global gameplay state that UI or world components can subscribe to
|
||||
|
||||
## Current Shape
|
||||
|
||||
The store exposes:
|
||||
|
||||
- `mainState`: the active game phase
|
||||
- `intro`: intro-specific state
|
||||
- `bike`: e-bike mission state
|
||||
- `pylone`: power grid mission state
|
||||
- `ferme`: farm mission state
|
||||
- `outro`: ending state
|
||||
- actions for direct updates and progression updates
|
||||
|
||||
The mission steps currently use this sequence:
|
||||
Mission steps:
|
||||
|
||||
```ts
|
||||
"locked" |
|
||||
@@ -79,6 +92,8 @@ The mission steps currently use this sequence:
|
||||
"done";
|
||||
```
|
||||
|
||||
`isCinematicPlaying` is read by `PlayerController` to ignore player input while camera timelines are active.
|
||||
|
||||
## Reading State In Components
|
||||
|
||||
Use selectors to read only what the component needs.
|
||||
@@ -95,7 +110,7 @@ export function Example(): React.JSX.Element {
|
||||
|
||||
This is better than reading the whole store, because the component re-renders only when `mainState` changes.
|
||||
|
||||
## Updating State
|
||||
## Updating Game State
|
||||
|
||||
Prefer explicit actions from the store.
|
||||
|
||||
@@ -113,9 +128,15 @@ const setMainState = useGameStore((state) => state.setMainState);
|
||||
setMainState("bike");
|
||||
```
|
||||
|
||||
Direct setters are useful for debug panels, but production gameplay should prefer business actions such as `advanceGameState`, `completeBike`, or `completePylone`.
|
||||
Direct setters are useful for debug panels, but production gameplay should prefer business actions such as:
|
||||
|
||||
Mission gameplay that can target `bike`, `pylone`, or `ferme` should prefer the generic mission actions:
|
||||
- `advanceGameState`
|
||||
- `completeBike`
|
||||
- `completePylone`
|
||||
- `completeFerme`
|
||||
- `completeMission`
|
||||
|
||||
Mission gameplay that can target `bike`, `pylone`, or `ferme` should prefer generic mission actions:
|
||||
|
||||
```ts
|
||||
const setMissionStep = useGameStore((state) => state.setMissionStep);
|
||||
@@ -125,40 +146,71 @@ setMissionStep("bike", "inspected");
|
||||
completeMission("bike");
|
||||
```
|
||||
|
||||
This keeps reusable gameplay components such as repair flows from duplicating mission-specific branches like `setBikeState`, `setPyloneState`, and `setFermeState`.
|
||||
This keeps reusable gameplay components such as `RepairGame` from duplicating mission-specific branches like `setBikeState`, `setPyloneState`, and `setFermeState`.
|
||||
|
||||
## Settings Store
|
||||
|
||||
`useSettingsStore` owns player-facing settings and forwards audio volume changes to `AudioManager`.
|
||||
|
||||
State:
|
||||
|
||||
- `isSettingsMenuOpen`
|
||||
- `musicVolume`
|
||||
- `sfxVolume`
|
||||
- `dialogueVolume`
|
||||
- `subtitlesEnabled`
|
||||
- `subtitleLanguage`
|
||||
- `repairRuntime`
|
||||
|
||||
Audio setters clamp values between `0` and `1`, then call:
|
||||
|
||||
```ts
|
||||
AudioManager.getInstance().setCategoryVolume(category, nextVolume);
|
||||
```
|
||||
|
||||
This keeps UI state and browser audio state synchronized.
|
||||
|
||||
Current caveat: `repairRuntime` is stored and displayed in the settings menu, but the repair game does not consume it yet. Treat it as a staged architecture hook rather than an active runtime switch.
|
||||
|
||||
## Subtitle Store
|
||||
|
||||
`useSubtitleStore` is intentionally tiny.
|
||||
|
||||
State/actions:
|
||||
|
||||
- `activeSubtitle`
|
||||
- `setActiveSubtitle`
|
||||
- `clearActiveSubtitle`
|
||||
|
||||
`playDialogueById()` writes to this store while dialogue audio plays. `Subtitles` reads from it and respects `useSettingsStore().subtitlesEnabled`.
|
||||
|
||||
## World Integration
|
||||
|
||||
`src/world/GameStageContent.tsx` subscribes to `mainState` and mounts stage-specific content.
|
||||
`src/world/GameStageContent.tsx` subscribes to `mainState` and mounts the repair-game content.
|
||||
|
||||
For repair missions, it mounts the reusable `RepairGame` component with a mission id:
|
||||
Current production repair placement:
|
||||
|
||||
```tsx
|
||||
<RepairGame mission="bike" position={[8, 0, -6]} />
|
||||
<RepairGame mission="pylone" position={[64, 0, -66]} />
|
||||
<RepairGame mission="ferme" position={[-24, 0, 42]} />
|
||||
```
|
||||
|
||||
`RepairGame` reads the active mission step from the store and writes transitions through generic actions such as `setMissionStep` and `completeMission`. Shared repair ids, mission steps, and runtime guards live in `src/types/gameplay/repairMission.ts` so static mission config does not depend on the Zustand store. The production repair flow currently supports `waiting -> inspected -> fragmented -> scanning -> repairing -> reassembling -> done -> next mission` state transitions.
|
||||
`RepairGame` reads the active mission step from the store and writes transitions through generic actions such as `setMissionStep` and `completeMission`.
|
||||
|
||||
Mission-specific behavior stays in `src/data/gameplay/repairMissions.ts`: each mission can define its broken nodes, placeholder targets, scan duration, and reassembly duration without adding mission branches to `RepairGame`.
|
||||
Shared repair ids, mission steps, and runtime guards live in:
|
||||
|
||||
That means the scene can progressively move toward this pattern:
|
||||
|
||||
```tsx
|
||||
switch (mainState) {
|
||||
case "intro":
|
||||
return <IntroContent />;
|
||||
case "bike":
|
||||
return <BikeContent />;
|
||||
case "pylone":
|
||||
return <PyloneContent />;
|
||||
case "ferme":
|
||||
return <FarmContent />;
|
||||
case "outro":
|
||||
return <OutroContent />;
|
||||
}
|
||||
```txt
|
||||
src/types/gameplay/repairMission.ts
|
||||
```
|
||||
|
||||
In React Three Fiber, mounting and unmounting JSX controls what appears in the Three.js scene. When a state-specific component disappears from JSX, React removes it from the scene.
|
||||
Mission-specific behavior stays in:
|
||||
|
||||
```txt
|
||||
src/data/gameplay/repairMissions.ts
|
||||
```
|
||||
|
||||
That lets the repair flow stay reusable while each mission defines its own model, broken parts, replacement parts, prompts, and timing.
|
||||
|
||||
## UI Integration
|
||||
|
||||
@@ -166,13 +218,16 @@ In React Three Fiber, mounting and unmounting JSX controls what appears in the T
|
||||
|
||||
Current overlays:
|
||||
|
||||
- `DebugOverlayLayout`: debug-only overlay shown with `?debug`, including the `GameStateDebugPanel` progression panel
|
||||
- `GameStateDebugPanel`: compact debug UI for viewing and switching main/sub states, stepping backward or forward, and resetting the store
|
||||
- `DebugOverlayLayout`: debug-only overlay shown with `?debug`
|
||||
- `GameStateDebugPanel`: compact debug UI for viewing and switching main/sub states
|
||||
- `Crosshair`: player aiming helper
|
||||
- `InteractPrompt`: interaction prompt
|
||||
- `RepairMovementLockIndicator`: player-facing indicator shown while repair steps temporarily disable movement
|
||||
- `RepairMovementLockIndicator`: indicator intended for repair movement lock
|
||||
- `HandTrackingVisualizer`: hand tracking SVG fallback/debug visualization
|
||||
- `Subtitles`: active dialogue subtitle overlay
|
||||
- `GameSettingsMenu`: options menu and settings controls
|
||||
|
||||
`src/pages/page.tsx` should stay thin and mount only the canvas and `GameUI`.
|
||||
Current caveat: `useRepairMovementLocked()` returns `false` immediately on the current branch, so the movement-lock rule and indicator exist but are disabled at runtime.
|
||||
|
||||
## Regression Rules
|
||||
|
||||
@@ -182,7 +237,10 @@ Current overlays:
|
||||
- Keep gameplay transitions inside store actions when possible.
|
||||
- Keep debug-only controls behind `?debug`.
|
||||
- Add new state only when a real runtime feature needs it.
|
||||
- Keep settings side effects, such as audio category updates, inside settings actions rather than spreading them across UI components.
|
||||
|
||||
## Next Steps
|
||||
|
||||
Move repair validation into mission data once each mission has distinct broken module nodes, replacement assets, and completion events.
|
||||
- Decide whether `repairRuntime` should be removed, implemented, or clearly labeled as experimental.
|
||||
- Re-enable or remove the repair movement-lock rule depending on desired gameplay.
|
||||
- Move broader mission orchestration into a clearer layer if intro, mission, dialogue, and cinematic branching grows.
|
||||
|
||||
+215
-83
@@ -1,112 +1,244 @@
|
||||
# Implemented Features
|
||||
|
||||
This document lists features that are implemented in the current codebase.
|
||||
This document lists the user-visible and developer-facing features implemented in the current `develop` branch.
|
||||
|
||||
## Scene
|
||||
## Application And Routes
|
||||
|
||||
- Fullscreen React Three Fiber scene
|
||||
- Main map scene loaded from `public/map.json` and matching `public/models/{name}/model.glb` or `model.gltf` assets
|
||||
- Minimal fullscreen scene loading overlay for 3D scenes, with a global progress bar used by the production map, debug physics scene, and editor scene
|
||||
- Debug physics test scene selectable from the debug panel, including grab/trigger tests, an animated model preview, and separate repair playground zones for `bike`, `pylone`, and `ferme`
|
||||
- Rapier physics context available for production stage gameplay objects
|
||||
- Ambient and directional lighting
|
||||
- Environment background setup
|
||||
- React 19 application bootstrapped by Vite and TypeScript
|
||||
- TanStack Router route tree
|
||||
- `/` playable 3D experience
|
||||
- `/editor` local content editor
|
||||
- `/docs` in-app documentation browser
|
||||
- Lazy-loaded docs pages rendered from repository Markdown files
|
||||
|
||||
## 3D World
|
||||
|
||||
- Fullscreen React Three Fiber canvas
|
||||
- Production world composition in `src/world/World.tsx`
|
||||
- Environment model/background through `Environment` and `SkyModel`
|
||||
- Shared lighting setup
|
||||
- Production map loaded from `public/map.json`
|
||||
- Model resolution from `public/models/{name}/model.glb`, then `model.gltf`
|
||||
- Fallback cubes when a map node has no available model
|
||||
- Progressive scene loading overlay for game, debug physics scene, and editor
|
||||
- Stabilized game scene loading gates for map, model, collision, octree, and gameplay stage readiness
|
||||
- Game stage content mounted only after the map has loaded
|
||||
- Player, music, dialogues, and gameplay-dependent systems mounted only after gameplay is ready
|
||||
|
||||
## Player
|
||||
|
||||
- Player camera mode
|
||||
- Pointer lock mouse look
|
||||
- Movement with `ZQSD`
|
||||
- Jumping
|
||||
- Movement lock during active repair steps, with an on-screen indicator while keeping trigger interactions available
|
||||
- Octree-based collision against dedicated map collision nodes, currently scoped to `terrain`
|
||||
- Pointer-lock mouse look
|
||||
- `ZQSD` movement
|
||||
- Jump with `Space`
|
||||
- Trigger interaction with `E`
|
||||
- Grab interaction with primary mouse button
|
||||
- Spawn reset based on scene mode
|
||||
- Input lock while the settings menu is open
|
||||
- Input lock while a cinematic is playing
|
||||
- Octree collision against dedicated map collision nodes, currently scoped to the `terrain` node
|
||||
- Repair movement-lock hook and indicator exist, but the hook currently returns `false`, so movement is not locked during repair on the current branch
|
||||
|
||||
## Interactions
|
||||
## Physics And Collision
|
||||
|
||||
- Focus detection by distance and raycast
|
||||
- Trigger interactions activated with `E`
|
||||
- Grab interactions activated with the primary mouse button
|
||||
- Physics-backed gameplay objects can be mounted inside stage content without replacing player octree collision
|
||||
- Interaction prompt shown for trigger interactions
|
||||
- Separate collision responsibility between player and gameplay objects
|
||||
- Player collision uses a Three.js capsule plus octree
|
||||
- Gameplay objects use Rapier rigid bodies and colliders
|
||||
- Production `GameStageContent` is mounted inside a Rapier `Physics` provider
|
||||
- Debug physics scene owns its own Rapier playground
|
||||
- Map collision octree is built from explicit collision nodes instead of the full visible map
|
||||
|
||||
## Interaction System
|
||||
|
||||
- Shared `InteractionManager` singleton for focused object, nearby object, holding state, and hand-holding state
|
||||
- React subscription through `useSyncExternalStore`
|
||||
- Distance and camera-ray focus detection in `InteractableObject`
|
||||
- Trigger interactions through `TriggerObject`
|
||||
- Grab interactions through `GrabbableObject`
|
||||
- Trigger prompt shown by `InteractPrompt`
|
||||
- Optional trigger SFX and optional spawned model support
|
||||
- Debug interaction sphere visibility through the `Interaction` lil-gui folder
|
||||
- Hand-controlled grab support for grabbable objects
|
||||
- Snap-to-target behavior after releasing grabbable objects
|
||||
|
||||
## Repair Gameplay
|
||||
|
||||
- Reusable production `RepairGame` mounted for `bike`, `pylone`, and `ferme` mission states
|
||||
- Debug physics playground mounts the same reusable `RepairGame` in `Bike`, `Pylone`, and `Farm` zones so each state can be tuned with isolated positioning before moving placement into the production map
|
||||
- Repair mission config shared through `src/data/gameplay/repairMissions.ts`, including per-mission broken nodes, placeholder targets, scan timing, and reassembly timing
|
||||
- Repair-game flow supports `waiting -> inspected -> fragmented -> scanning -> repairing -> reassembling -> done -> next mission` with `.webm` prompts, repair case spawn/opening/exit, focused repair-case view, movement lock indicator during active repair, repair-case trigger interaction, case placeholder traversal, snap-to-placeholder placement, broken-part deposit feedback, `E`, two-fists hold input, exploded and inverse reassembly transitions, completion particles, per-part scan visuals, persistent red broken-part markers, centered broken-part UI videos, multiple grabbable replacement choices, correct-part install validation feedback, and mission completion
|
||||
- Reusable `RepairGame` mounted for `bike`, `pylone`, and `ferme`
|
||||
- Mission progression driven by Zustand and shared `MissionStep` types
|
||||
- Production repair positions:
|
||||
- `bike` at `[8, 0, -6]`
|
||||
- `pylone` at `[64, 0, -66]`
|
||||
- `ferme` at `[-24, 0, 42]`
|
||||
- Debug physics repair playground zones for all three missions
|
||||
- Data-driven mission config in `src/data/gameplay/repairMissions.ts`
|
||||
- Mission flow: `locked -> waiting -> inspected -> fragmented -> scanning -> repairing -> reassembling -> done`
|
||||
- `.webm` 3D prompts for mission object, interaction, and broken parts
|
||||
- Repair object inspection
|
||||
- Repair case spawn, pop animation, proximity float, wobble, open/close lid animation, exit animation, and open/close sounds
|
||||
- Repair case placeholder traversal from GLTF nodes named `placeholder_*`
|
||||
- Fallback placeholder positions when a case asset has no placeholder nodes
|
||||
- Fragmentation through repair-case trigger or two-fists hand gesture
|
||||
- Exploded model visualization through `ExplodableModel`
|
||||
- Scan visual that steps through exploded parts
|
||||
- Broken-part detection by configured `nodeName`, with fallback to first scanned parts
|
||||
- Persistent broken-part highlight and broken-part prompt after discovery
|
||||
- Grabbable replacement part choices, including decoys
|
||||
- Grabbable broken parts that must be deposited back into the case
|
||||
- Snap-to-placeholder placement
|
||||
- Correct-part, wrong-part, and stored-part visual feedback
|
||||
- Blocked install feedback when validation is attempted too early
|
||||
- Install target that validates only when the correct replacement is placed and all broken parts are stored
|
||||
- Inverse reassembly animation
|
||||
- Completion particles
|
||||
- Completion target that closes/exits the repair case before calling `completeMission`
|
||||
|
||||
## Audio
|
||||
## Game Progression Store
|
||||
|
||||
- Category-based volumes for music, SFX, and dialogue
|
||||
- Looped background music playback through `AudioManager`
|
||||
- One-shot sound playback for SFX and dialogue, with simple per-sound pooling
|
||||
- Optional stereo pan for one-shot sounds
|
||||
- Zustand `useGameStore` for durable gameplay progression
|
||||
- Main states: `intro`, `bike`, `pylone`, `ferme`, `outro`
|
||||
- Per-mission repair step state
|
||||
- Per-mission completion flags
|
||||
- Generic mission helpers: `setMissionStep`, `completeMission`, `advanceGameState`, `rewindGameState`, `resetGame`
|
||||
- `isCinematicPlaying` flag used by the player input lock
|
||||
- Debug game-state panel that can jump between main states and sub-states
|
||||
|
||||
## Dialogue And Subtitles
|
||||
## Settings And UI Overlays
|
||||
|
||||
- Dialogue manifest in `public/sounds/dialogue/dialogues.json`
|
||||
- Dialogue audio loaded from `public/sounds/dialogue/`
|
||||
- One SRT subtitle file per voice and language
|
||||
- French subtitle fallback when the selected language file is missing
|
||||
- Runtime subtitle overlay with speaker-specific colors
|
||||
- Timecoded dialogue trigger support for dialogue entries that define `timecode`
|
||||
- Dialogue queueing to avoid overlapping dialogue playback
|
||||
|
||||
## Cinematics
|
||||
|
||||
- Cinematic manifest in `public/cinematics.json`
|
||||
- Timecoded cinematic trigger support
|
||||
- GSAP camera keyframe playback
|
||||
- Optional dialogue cues synchronized to cinematic timelines
|
||||
- Player input lock while a cinematic is active
|
||||
|
||||
## Game Options Menu
|
||||
|
||||
- `Esc` opens and closes the in-game options menu
|
||||
- `Esc` opens and closes the settings menu
|
||||
- Music, SFX, and dialogue volume sliders
|
||||
- Subtitle visibility toggle
|
||||
- Subtitle language choice between French and English
|
||||
- Repair runtime choice between local JavaScript and Python server mode
|
||||
- Repair-runtime choice between JavaScript and Python modes stored in settings
|
||||
- Quit action that clears browser-accessible cookies and returns to `/`
|
||||
- Crosshair overlay
|
||||
- Interaction prompt
|
||||
- Subtitle overlay
|
||||
- Repair movement-lock indicator component, currently inactive because the lock hook returns `false`
|
||||
- Debug overlay layout
|
||||
- Scene loading overlay
|
||||
|
||||
## Audio
|
||||
|
||||
- Singleton `AudioManager`
|
||||
- Looped music playback
|
||||
- One-shot SFX/dialogue playback
|
||||
- Per-path one-shot audio pools
|
||||
- Category volumes for `music`, `sfx`, and `dialogue`
|
||||
- Optional stereo panning for one-shot sounds
|
||||
- Playback-rate option for one-shot sounds
|
||||
- Browser autoplay fallback for music: retry after user `pointerdown` or `keydown`
|
||||
- Game music mounted through `GameMusic`
|
||||
- Current game music path: `/sounds/musique/test.mp3`
|
||||
- Current base music volume: `0.33`
|
||||
- Repair case open/close sounds
|
||||
- Trigger-object SFX support
|
||||
|
||||
## Dialogue And Subtitles
|
||||
|
||||
- Runtime dialogue manifest in `public/sounds/dialogue/dialogues.json`
|
||||
- Dialogue audio under `public/sounds/dialogue/`
|
||||
- One SRT file per voice and language
|
||||
- French and English subtitle folders
|
||||
- Runtime SRT parsing
|
||||
- Subtitle cue lookup by voice, selected language, and `subtitleCueIndex`
|
||||
- French fallback when the selected language file is unavailable
|
||||
- Dialogue playback through the `dialogue` audio category
|
||||
- Runtime subtitle synchronization from audio `timeupdate`
|
||||
- Speaker-aware subtitle overlay
|
||||
- Dialogue queueing to avoid overlapping dialogue playback
|
||||
- Global timecode dialogue triggering through `GameDialogues`
|
||||
|
||||
## Cinematics
|
||||
|
||||
- Runtime cinematic manifest in `public/cinematics.json`
|
||||
- Cinematic manifest validation
|
||||
- GSAP camera keyframe playback
|
||||
- Camera position and look target interpolation
|
||||
- Optional dialogue cues relative to cinematic start time
|
||||
- Player input lock while a cinematic is active
|
||||
- Current world integration only mounts `GameCinematics` during `mainState === "outro"`
|
||||
|
||||
## Hand Tracking
|
||||
|
||||
- Optional webcam hand tracking provider around the playable scene
|
||||
- Source switch in debug GUI: local Python backend or browser-side MediaPipe
|
||||
- Backend WebSocket endpoint at `ws://localhost:8000/ws`
|
||||
- Backend health endpoint at `http://localhost:8000/health`
|
||||
- Browser-side MediaPipe through `@mediapipe/tasks-vision`
|
||||
- Lazy activation so camera/tracking is not always active
|
||||
- Production activation during repair steps that need hand input
|
||||
- Debug activation in physics mode while near, holding, or hand-holding interactions
|
||||
- Hand snapshot context for R3F and UI consumers
|
||||
- Fist detection
|
||||
- Two-fists hold gesture for repair fragmentation
|
||||
- Hand grab support for `GrabbableObject`
|
||||
- Hand-tracking debug panel with status, source/server state, hand count, fist state, and glove model status
|
||||
- SVG hand visualizer fallback
|
||||
- `gant_l` and `gant_r` R3F glove overlays when tracking is active
|
||||
|
||||
## Debug Tooling
|
||||
|
||||
- `?debug` query param enables the debug panel
|
||||
- `lil-gui` controls for camera mode, scene mode, `R3F Perf`, `Debug Overlay`, and interaction tuning
|
||||
- Compact debug overlay for game state controls and hand tracking status
|
||||
- Debug game-state mission switching unlocks locked repair missions at `waiting` for faster testing
|
||||
- Debug scene helpers
|
||||
- Free debug camera
|
||||
- `r3f-perf` overlay
|
||||
- `?debug` query param enables debug systems
|
||||
- `lil-gui` root debug folder
|
||||
- Camera mode switch between player and debug camera
|
||||
- Scene mode switch between production game and physics test scene
|
||||
- R3F perf toggle
|
||||
- Debug overlay toggle
|
||||
- Hand-tracking source switch
|
||||
- Interaction sphere debug toggle
|
||||
- Grabbable tuning controls for stiffness, throw boost, and hold distance
|
||||
- Debug helpers: grid and axes
|
||||
- Debug camera controls
|
||||
- Debug game-state panel
|
||||
- Debug hand-tracking panel
|
||||
- Physics test scene with floor, grabbable object, trigger object, repair zones, and animated model preview
|
||||
- Animated `electricienne_animated` model preview restored in the debug physics scene
|
||||
|
||||
## Map Editor
|
||||
## Map And Content Editor
|
||||
|
||||
- `/editor` route for inspecting and editing `public/map.json`
|
||||
- Automatic loading of `public/map.json` when available
|
||||
- Folder upload fallback when `map.json` is missing
|
||||
- Rendering of available `public/models/{name}/model.glb` or `model.gltf` assets
|
||||
- Fallback cubes for nodes whose model is missing
|
||||
- `/editor` route
|
||||
- Automatic loading of `public/map.json`
|
||||
- Folder upload fallback when map data is not available
|
||||
- Shared `MapNode` format with runtime map loading
|
||||
- Render available map models
|
||||
- Fallback cubes for missing models
|
||||
- Object selection by click
|
||||
- Transform modes for translate, rotate, and scale
|
||||
- Keyboard shortcuts for `T`, `R`, `S`, `Esc`, undo, and redo
|
||||
- Player-style navigation mode with `WASD`, `ZQSD`, arrow keys, `Space`, and `Shift`
|
||||
- JSON export for downloading the edited map
|
||||
- Dev-server save endpoint for writing changes back to `public/map.json`
|
||||
- SRT editor for dialogue subtitles
|
||||
- Audio preview and timing helpers for SRT cues
|
||||
- Dev-server save endpoint for SRT files
|
||||
- Dialogue manifest editor with preview and assisted French SRT cue creation
|
||||
- Cinematic manifest editor with camera keyframes, dialogue cues, and canvas preview
|
||||
- Dialogue manifest validation from the editor UI
|
||||
- Transform modes: translate, rotate, scale
|
||||
- Transform keyboard shortcuts: `T`, `R`, `S`
|
||||
- Selection lock
|
||||
- Explicit selection clear
|
||||
- Undo and redo
|
||||
- Player-style editor navigation with `WASD`, `ZQSD`, arrows, `Space`, and `Shift`
|
||||
- JSON inspector
|
||||
- JSON export
|
||||
- Dev-server save endpoint for `public/map.json`
|
||||
- Dialogue manifest editor
|
||||
- SRT subtitle editor
|
||||
- Audio preview and cue timing helpers
|
||||
- French SRT cue creation helper
|
||||
- Dialogue asset validation endpoint
|
||||
- Cinematic manifest editor
|
||||
- Cinematic camera keyframe editor
|
||||
- Cinematic dialogue cue editor
|
||||
- Cinematic preview in the editor canvas
|
||||
- Dev-server endpoints for dialogue, SRT, and cinematic saves
|
||||
|
||||
## Not Implemented Yet
|
||||
## In-App Documentation
|
||||
|
||||
- complete mission system
|
||||
- zone system
|
||||
- full cinematic system beyond current timecode prototype
|
||||
- gameplay-triggered dialogue branches beyond current prototype triggers
|
||||
- loading flow
|
||||
- minimap and mission HUD
|
||||
- full production separation between gameplay and debug scenes
|
||||
- production backend persistence for editor saves
|
||||
- `/docs` documentation layout
|
||||
- Markdown rendered through `react-markdown` and `remark-gfm`
|
||||
- Technical docs for architecture, scene runtime, repair game, interaction, editor, audio, hand tracking, Zustand, Three debugging, animation, and target architecture
|
||||
- User docs for implemented features, main feature, editor usage, and code-review preparation
|
||||
|
||||
## Not Implemented Or Incomplete
|
||||
|
||||
- Complete production mission manager/orchestrator
|
||||
- Full mission HUD or minimap
|
||||
- Full zone system
|
||||
- Dialogue branching
|
||||
- Production persistence for editor saves
|
||||
- Production backend for repair-game runtime selection
|
||||
- Production save/load of player progression
|
||||
- Full migration of player movement to Rapier
|
||||
- Advanced hand smoothing and calibrated glove finger animation
|
||||
- Snap-to-grid, object creation, object deletion, material editing, or model editing in the map editor
|
||||
|
||||
@@ -12,7 +12,7 @@ The current user flow is:
|
||||
2. Move close to the active repair object in the game scene.
|
||||
3. Aim at the object and press the interaction key when prompted.
|
||||
4. The mission step moves from `waiting` to `inspected`.
|
||||
5. The repair case appears near the mission object, the player movement controls are locked, and the case can float when the player approaches it.
|
||||
5. The repair case appears near the mission object and can float when the player approaches it. A repair movement-lock rule exists in code, but it is currently disabled by the hook on `develop`.
|
||||
6. Aim at the repair case and press `E`, or hold both fists closed for one second, to move from `inspected` to `fragmented`.
|
||||
7. The mission object uses an exploded-model transition, then moves to `scanning`.
|
||||
8. The scan visual moves across the fragmented model one part at a time and keeps a red marker plus the `cassé.webm` prompt centered on any configured broken part once it has been found.
|
||||
@@ -20,22 +20,24 @@ The current user flow is:
|
||||
10. Move the correct replacement part close to a placeholder. When released near a placeholder, it snaps into place with a short animation.
|
||||
11. Move each scanned broken part into a compatible placeholder so the damaged parts are stored in the case.
|
||||
12. Press `E` on the green install target to move to `reassembling`. Wrong parts turn the target red and cannot finish the repair.
|
||||
13. The exploded object animates back into its assembled form with completion particles, then moves to `done` and restores player movement controls.
|
||||
13. The exploded object animates back into its assembled form with completion particles, then moves to `done`.
|
||||
14. Press `E` on the completion target. The repair case closes, returns to the ground, disappears, then `completeMission` moves to the next mission or to `outro` after `ferme`.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
This feature validates the repair loop before a full mission system exists. It tests whether repair objects, physical proximity, model selection, audio feedback, and exploded model visualization can work together in the 3D scene.
|
||||
|
||||
For implementation details, see `docs/technical/repair-game.md`.
|
||||
|
||||
## Current Behavior
|
||||
|
||||
In `waiting`, the active mission renders its repair object and the `interagir.webm` prompt in the game scene. The interaction uses the shared focus/raycast interaction system, so the player still gets the normal `E` prompt.
|
||||
|
||||
When the player inspects the object, `RepairGame` writes `inspected` through the generic mission store action. The repair case then appears from the mission config with a small pop animation, player movement is locked while the repair sequence is active, and a small HTML indicator confirms that movement is temporarily unavailable. When the player is close enough, the existing case model floats upward and rotates gently to signal interactivity.
|
||||
When the player inspects the object, `RepairGame` writes `inspected` through the generic mission store action. The repair case then appears from the mission config with a small pop animation. When the player is close enough, the case model floats upward and rotates gently to signal interactivity. The codebase also contains a shared repair movement-lock hook and HTML indicator, but `useRepairMovementLocked()` currently returns `false`, so movement remains available during the repair flow on the current branch.
|
||||
|
||||
In `inspected`, `RepairGame` can also move to `fragmented`. Keyboard input goes through the shared focus/raycast interaction system on the repair case, so the player must be close enough and aim at the case before pressing `E`. The hand-tracking path still uses a two-fists hold gesture and is state-based, so it does not depend on being inside a local object interaction radius.
|
||||
|
||||
In `fragmented`, the repair object is rendered with `ExplodableModel`, then automatically advances to `scanning`. In `scanning`, the exploded model remains visible, a blue scan visual moves from part to part, and a red halo/wire marker plus the configured broken UI video stay attached to configured broken parts after the scanner reaches them. The scan can match a specific `nodeName` when mission data provides one, otherwise it falls back to the first scanned parts as placeholder broken parts. In `repairing`, the case opens in a larger focused transform, `RepairCaseModel` traverses the case GLTF for empty nodes named `placeholder_*`, several grabbable replacement parts appear on those placeholder positions, and releasing a part near a placeholder snaps it into place with a short GSAP animation. Scanned broken parts are also rendered as grabbable objects and must be deposited into a compatible placeholder before the final install target validates. If `brokenParts[].placeholderName` is configured, that broken part snaps only to the matching placeholder; otherwise it can use any available placeholder. If the current case asset has no placeholder nodes, the flow keeps using fallback focus positions. Replacement parts show green or red placement feedback after snapping, broken parts show stored feedback after deposit, and the install target gives a short blocked feedback if the player tries to validate too early. The install target only validates when the configured correct replacement part is placed and all scanned broken parts have been deposited. Player movement stays locked through `inspected`, `fragmented`, `scanning`, `repairing`, and `reassembling`, while trigger interactions remain available. In `reassembling`, the exploded model animates back into its assembled position with green completion particles before the flow moves to `done`. In `done`, player movement is available again and the repaired object remains visible with a completion target; validating closes the repair case first, then plays the case exit animation before advancing the global mission progression.
|
||||
In `fragmented`, the repair object is rendered with `ExplodableModel`, then automatically advances to `scanning`. In `scanning`, the exploded model remains visible, a blue scan visual moves from part to part, and a red halo/wire marker plus the configured broken UI video stay attached to configured broken parts after the scanner reaches them. The scan can match a specific `nodeName` when mission data provides one, otherwise it falls back to the first scanned parts as placeholder broken parts. In `repairing`, the case opens in a larger focused transform, `RepairCaseModel` traverses the case GLTF for empty nodes named `placeholder_*`, several grabbable replacement parts appear on those placeholder positions, and releasing a part near a placeholder snaps it into place with a short GSAP animation. Scanned broken parts are also rendered as grabbable objects and must be deposited into a compatible placeholder before the final install target validates. If `brokenParts[].placeholderName` is configured, that broken part snaps only to the matching placeholder; otherwise it can use any available placeholder. If the current case asset has no placeholder nodes, the flow keeps using fallback focus positions. Replacement parts show green or red placement feedback after snapping, broken parts show stored feedback after deposit, and the install target gives a short blocked feedback if the player tries to validate too early. The install target only validates when the configured correct replacement part is placed and all scanned broken parts have been deposited. In `reassembling`, the exploded model animates back into its assembled position with green completion particles before the flow moves to `done`. In `done`, the repaired object remains visible with a completion target; validating closes the repair case first, then plays the case exit animation before advancing the global mission progression.
|
||||
|
||||
The mission config now carries the mission-specific variations. `bike` repairs one cooling core, `pylone` scans and stores both the lamp relay and a damaged panel with slower scan/reassembly timing, and `ferme` scans and stores an irrigation pump plus humidity sensor with faster scan/reassembly timing.
|
||||
|
||||
@@ -54,10 +56,10 @@ The mission config now carries the mission-specific variations. `bike` repairs o
|
||||
- `src/components/three/gameplay/RepairPromptVideo.tsx` renders `.webm` prompts inside the 3D scene.
|
||||
- `src/components/three/gameplay/RepairScanSequence.tsx` keeps the exploded model visible and advances the scan from part to part.
|
||||
- `src/components/three/gameplay/RepairScanVisual.tsx` renders the scan halo and scan line around the active part.
|
||||
- `src/components/ui/RepairMovementLockIndicator.tsx` renders the HTML indicator shown while repair movement is locked.
|
||||
- `src/components/ui/RepairMovementLockIndicator.tsx` renders the HTML indicator intended for repair movement lock.
|
||||
- `src/hooks/gameplay/useRepairFragmentationInput.ts` handles the `inspected -> fragmented` two-fists input and can optionally bind keyboard input for non-trigger flows.
|
||||
- `src/hooks/gameplay/useRepairMissionStep.ts` reads the active mission step from the game store.
|
||||
- `src/hooks/gameplay/useRepairMovementLocked.ts` exposes the shared repair movement-lock rule used by the player controller and UI indicator.
|
||||
- `src/hooks/gameplay/useRepairMovementLocked.ts` exposes the shared repair movement-lock rule used by the player controller and UI indicator, but currently returns `false`.
|
||||
- `src/hooks/handTracking/useBothFistsHold.ts` detects the reusable two-fists hold gesture.
|
||||
- `src/components/three/gameplay/RepairCaseModel.tsx` renders and animates the case model, and exposes `placeholder_*` transforms when the GLTF provides them.
|
||||
- `src/components/three/models/ExplodableModel.tsx` renders selectable models with split/exploded visualization.
|
||||
@@ -106,5 +108,6 @@ python -m backend.main
|
||||
- The reusable production `RepairGame` currently covers `waiting -> inspected -> fragmented -> scanning -> repairing -> reassembling -> done -> next mission`.
|
||||
- Mission progression is wired through Zustand using `completeMission` at the end of each repair.
|
||||
- There is no central `GameManager` in this branch.
|
||||
- Repair movement lock is currently disabled by `useRepairMovementLocked()`.
|
||||
- Hand tracking is available for the two-fists input and grabbable repair parts; case interaction and final installation still use the shared `E` trigger path.
|
||||
- The repair-game content is configured statically in `src/data/gameplay/`.
|
||||
|
||||
Reference in New Issue
Block a user