add: repair install completion step

This commit is contained in:
Tom Boullay
2026-05-08 01:41:29 +01:00
parent eed0077dd1
commit 7bbcf4359e
7 changed files with 92 additions and 12 deletions
+17 -1
View File
@@ -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({
<ExplodableModel modelPath={config.modelPath} split />
) : null}
{step === "scanning" ? <RepairScanVisual config={config} /> : null}
{step !== "waiting" ? (
{step === "repairing" ? (
<RepairRepairingStep
config={config}
onRepair={() => setMissionStep(mission, "done")}
/>
) : null}
{step === "done" ? (
<RepairObjectModel
label={config.label}
modelPath={config.modelPath}
scale={1}
/>
) : null}
{step !== "waiting" && step !== "done" ? (
<RepairMissionCase
config={config}
open={step === "repairing"}
showFragmentationPrompt={readyForFragmentation}
/>
) : null}
@@ -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 (
<group>
<RepairCaseModel
modelPath={REPAIR_CASE_MODEL_PATH}
open={false}
open={open}
position={config.case.position}
rotation={config.case.rotation}
scale={config.case.scale}
@@ -0,0 +1,54 @@
import { RepairObjectModel } from "@/components/three/gameplay/RepairObjectModel";
import { RepairPromptVideo } from "@/components/three/gameplay/RepairPromptVideo";
import { TriggerObject } from "@/components/three/interaction/TriggerObject";
import type { RepairMissionConfig } from "@/data/gameplay/repairMissions";
interface RepairRepairingStepProps {
config: RepairMissionConfig;
onRepair: () => 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 (
<group>
<TriggerObject
position={[0, 0.8, 0]}
colliders="ball"
label={`Installer ${replacementLabel}`}
onTrigger={onRepair}
>
<mesh>
<torusGeometry args={[0.95, 0.045, 12, 96]} />
<meshBasicMaterial color="#22c55e" transparent opacity={0.85} />
</mesh>
<mesh position={[0, 0.02, 0]} rotation={[Math.PI / 2, 0, 0]}>
<ringGeometry args={[0.15, 0.9, 96]} />
<meshBasicMaterial color="#86efac" transparent opacity={0.35} />
</mesh>
</TriggerObject>
<group
position={[
config.case.position[0],
config.case.position[1] + 1.2,
config.case.position[2],
]}
>
<RepairObjectModel
label={replacementLabel}
modelPath={replacementModelPath}
scale={0.35}
/>
</group>
<RepairPromptVideo src={config.interactUiPath} position={[0, 2.3, 0]} />
</group>
);
}
+3 -3
View File
@@ -361,7 +361,7 @@ Pour les missions de réparation, il monte le composant réutilisable \`RepairGa
<RepairGame mission="bike" position={[8, 0, -6]} />
\`\`\`
\`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