diff --git a/docs/technical/zustand.md b/docs/technical/zustand.md index 2ed658d..c7199e0 100644 --- a/docs/technical/zustand.md +++ b/docs/technical/zustand.md @@ -136,7 +136,7 @@ For repair missions, it mounts the reusable `RepairGame` component with a missio ``` -`RepairGame` reads the active mission step from the store and writes transitions through generic actions such as `setMissionStep`. This keeps the scene component small and avoids mission-specific branching inside the repair flow. The production repair flow currently supports `waiting -> inspected -> fragmented -> scanning -> repairing` state transitions. +`RepairGame` reads the active mission step from the store and writes transitions through generic actions such as `setMissionStep`. This keeps the scene component small and avoids mission-specific branching inside the repair flow. The production repair flow currently supports `waiting -> inspected -> fragmented -> scanning -> repairing -> done` state transitions. That means the scene can progressively move toward this pattern: @@ -181,4 +181,4 @@ Current overlays: ## Next Steps -The next natural step is to add the visual fragmentation sequence after the `fragmented` state, then continue with scanning, repairing, and completion behavior. +The next natural step is to replace the simple install trigger with deeper repair interactions, such as selecting parts from the case, grabbing them, and validating the right replacement on a broken module. diff --git a/docs/user/features.md b/docs/user/features.md index 44bf341..c629ad5 100644 --- a/docs/user/features.md +++ b/docs/user/features.md @@ -31,7 +31,7 @@ This document lists features that are implemented in the current codebase. - Reusable production `RepairGame` mounted for `bike`, `pylone`, and `ferme` mission states - Repair mission config shared through `src/data/gameplay/repairMissions.ts` -- Repair-game flow supports `waiting -> inspected -> fragmented -> scanning -> repairing` with `.webm` prompts, repair case spawn, `E`, two-fists hold input, exploded model transition, and scan visuals +- Repair-game flow supports `waiting -> inspected -> fragmented -> scanning -> repairing -> done` with `.webm` prompts, repair case spawn/opening, `E`, two-fists hold input, exploded model transition, scan visuals, replacement part display, and install trigger ## Audio diff --git a/docs/user/main-feature.md b/docs/user/main-feature.md index 378d07b..d382c57 100644 --- a/docs/user/main-feature.md +++ b/docs/user/main-feature.md @@ -4,7 +4,7 @@ This document explains the current repair-game flow in La-Fabrik. ## What It Does -The main feature is becoming a reusable repair flow mounted in the production game scene. It lets the player approach the active mission object, inspect it, and bring in the repair case before later repair steps take over. +The main feature is becoming a reusable repair flow mounted in the production game scene. It lets the player approach the active mission object, inspect it, fragment it, scan the broken part, install a replacement, and mark the repair done. The current user flow is: @@ -14,6 +14,10 @@ The current user flow is: 4. The mission step moves from `waiting` to `inspected`. 5. The repair case appears near the mission object and can float when the player approaches it. 6. 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 highlights the broken area and shows the `cassé.webm` prompt. +9. In `repairing`, the case opens and a replacement part appears near the case. +10. Press `E` on the green install target to move to `done` and show the reassembled object. The older debug repair sandbox still exists in the physics test scene, but the production path now starts from the reusable `RepairGame` component. @@ -29,7 +33,9 @@ When the player inspects the object, `RepairGame` writes `inspected` through the In `inspected`, `RepairGame` can also move to `fragmented`. The player can use the interaction key or hold both fists closed for one second. The hand-tracking path is state-based, so it does not depend on being inside a local object interaction radius. -Repair module slots and exploded-model behavior still exist in the debug prototype. They will be migrated into the reusable repair flow in later steps. +In `fragmented`, the repair object is rendered with `ExplodableModel`, then automatically advances to `scanning`. In `scanning`, a blue scan visual and the `cassé.webm` prompt are shown before the flow advances to `repairing`. In `repairing`, the case opens, a replacement part appears, and the player can press `E` on the install target to finish the repair and move to `done`. + +Repair module slots and model-selection behavior still exist in the debug prototype. They can be migrated into the reusable repair flow in later steps if the repair interaction needs more depth. ## Key Files @@ -38,7 +44,9 @@ Repair module slots and exploded-model behavior still exist in the debug prototy - `src/components/three/gameplay/RepairGame.tsx` composes the reusable production repair flow. - `src/components/three/gameplay/RepairInspectionObject.tsx` handles the `waiting` inspection interaction. - `src/components/three/gameplay/RepairMissionCase.tsx` renders the mission repair case after inspection. +- `src/components/three/gameplay/RepairRepairingStep.tsx` renders the replacement part and install trigger in `repairing`. - `src/components/three/gameplay/RepairPromptVideo.tsx` renders `.webm` prompts inside the 3D scene. +- `src/components/three/gameplay/RepairScanVisual.tsx` renders the scan halo, scan line, and broken prompt. - `src/hooks/gameplay/useRepairFragmentationInput.ts` handles the `inspected -> fragmented` keyboard and hand-tracking input. - `src/hooks/gameplay/useRepairMissionStep.ts` reads the active mission step from the game store. - `src/hooks/handTracking/useBothFistsHold.ts` detects the reusable two-fists hold gesture. @@ -87,8 +95,8 @@ python -m backend.main ## Current Limitations -- The reusable production `RepairGame` currently covers `waiting -> inspected -> fragmented -> scanning -> repairing`; repair interactions and completion still need to be implemented. +- The reusable production `RepairGame` currently covers `waiting -> inspected -> fragmented -> scanning -> repairing -> done`. - Mission progression exists in Zustand, but the full repair mission flow is still being integrated. - There is no central `GameManager` in this branch. -- Hand tracking is available for repair-step input, but the later repair interactions are still being integrated. +- Hand tracking is available for the repair-step input, but the install interaction currently uses the shared `E` trigger path. - The repair-game content is configured statically in `src/data/gameplay/`. diff --git a/src/components/three/gameplay/RepairGame.tsx b/src/components/three/gameplay/RepairGame.tsx index 320d53e..3da576d 100644 --- a/src/components/three/gameplay/RepairGame.tsx +++ b/src/components/three/gameplay/RepairGame.tsx @@ -2,6 +2,8 @@ import { useEffect } from "react"; import { ExplodableModel } from "@/components/three/models/ExplodableModel"; import { RepairInspectionObject } from "@/components/three/gameplay/RepairInspectionObject"; import { RepairMissionCase } from "@/components/three/gameplay/RepairMissionCase"; +import { RepairObjectModel } from "@/components/three/gameplay/RepairObjectModel"; +import { RepairRepairingStep } from "@/components/three/gameplay/RepairRepairingStep"; import { RepairScanVisual } from "@/components/three/gameplay/RepairScanVisual"; import { REPAIR_FRAGMENTATION_SEQUENCE_SECONDS, @@ -77,9 +79,23 @@ export function RepairGame({ ) : null} {step === "scanning" ? : null} - {step !== "waiting" ? ( + {step === "repairing" ? ( + setMissionStep(mission, "done")} + /> + ) : null} + {step === "done" ? ( + + ) : null} + {step !== "waiting" && step !== "done" ? ( ) : null} diff --git a/src/components/three/gameplay/RepairMissionCase.tsx b/src/components/three/gameplay/RepairMissionCase.tsx index 916d9e2..46bb6a4 100644 --- a/src/components/three/gameplay/RepairMissionCase.tsx +++ b/src/components/three/gameplay/RepairMissionCase.tsx @@ -5,18 +5,20 @@ import type { RepairMissionConfig } from "@/data/gameplay/repairMissions"; interface RepairMissionCaseProps { config: RepairMissionConfig; + open?: boolean; showFragmentationPrompt?: boolean; } export function RepairMissionCase({ config, + open = false, showFragmentationPrompt = false, }: RepairMissionCaseProps): React.JSX.Element { return ( void; +} + +export function RepairRepairingStep({ + config, + onRepair, +}: RepairRepairingStepProps): React.JSX.Element { + const replacementPart = config.replacementParts[0]; + const replacementModelPath = replacementPart?.modelPath ?? config.modelPath; + const replacementLabel = replacementPart?.label ?? config.label; + + return ( + + + + + + + + + + + + + + + + + + + ); +} diff --git a/src/data/docs/docsTranslations.ts b/src/data/docs/docsTranslations.ts index ff97479..f557e99 100644 --- a/src/data/docs/docsTranslations.ts +++ b/src/data/docs/docsTranslations.ts @@ -361,7 +361,7 @@ Pour les missions de réparation, il monte le composant réutilisable \`RepairGa \`\`\` -\`RepairGame\` lit l'étape de mission active depuis le store et écrit les transitions via des actions génériques comme \`setMissionStep\`. Cela garde le composant de scène petit et évite les branches spécifiques à chaque mission dans le flow de réparation. Le flow de réparation de production supporte actuellement les transitions \`waiting -> inspected -> fragmented -> scanning -> repairing\`. +\`RepairGame\` lit l'étape de mission active depuis le store et écrit les transitions via des actions génériques comme \`setMissionStep\`. Cela garde le composant de scène petit et évite les branches spécifiques à chaque mission dans le flow de réparation. Le flow de réparation de production supporte actuellement les transitions \`waiting -> inspected -> fragmented -> scanning -> repairing -> done\`. La scène peut donc évoluer progressivement vers ce pattern : @@ -406,7 +406,7 @@ Overlays actuels : ## Prochaines étapes -La prochaine étape naturelle est d'ajouter les interactions de réparation après l'état \`repairing\`, puis de continuer avec la complétion. +La prochaine étape naturelle est de remplacer le trigger simple d'installation par des interactions de réparation plus profondes, comme choisir des pièces dans la mallette, les saisir et valider le bon remplacement sur un module cassé. `; export const featuresFr = `# Fonctionnalités implémentées @@ -442,7 +442,7 @@ Ce document liste les fonctionnalités présentes dans le code actuel. - \`RepairGame\` de production réutilisable monté pour les états de mission \`bike\`, \`pylone\` et \`ferme\` - Configuration de mission partagée via \`src/data/gameplay/repairMissions.ts\` -- Flow repair-game avec \`waiting -> inspected -> fragmented -> scanning -> repairing\`, prompts \`.webm\`, apparition de la mallette, touche \`E\`, hold deux poings, transition de modèle explosé et visuels de scan +- Flow repair-game avec \`waiting -> inspected -> fragmented -> scanning -> repairing -> done\`, prompts \`.webm\`, apparition/ouverture de la mallette, touche \`E\`, hold deux poings, transition de modèle explosé, visuels de scan, pièce de remplacement et trigger d'installation ## Audio