refactor: clean map gameplay architecture
This commit is contained in:
tom-boullay
@@ -107,7 +107,7 @@ It owns:
|
||||
|
||||
- `mainState`
|
||||
- intro state
|
||||
- `bike`, `pylone`, and `ferme` mission state
|
||||
- `ebike`, `pylon`, and `farm` mission state
|
||||
- outro state
|
||||
- `isCinematicPlaying`
|
||||
- progression actions
|
||||
|
||||
@@ -1,164 +0,0 @@
|
||||
# Game Flow - La Fabrik
|
||||
|
||||
## Étapes du jeu
|
||||
|
||||
```
|
||||
intro → start-intro → naming → bienvenue → star-move → mission2 → searching_problem → preparation → outOfFabrik
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Détail des étapes
|
||||
|
||||
### 1. `intro` (initial)
|
||||
|
||||
- État initial au chargement du jeu
|
||||
- Aucune action, juste une étape de départ
|
||||
- Transition automatique vers `start-intro`
|
||||
|
||||
### 2. `start-intro`
|
||||
|
||||
- **Déclenchement** : Auto-transition depuis `intro` quand la scène est chargée
|
||||
- **Action** : Joue l'audio d'intro (`intro`)
|
||||
- **Attente** : Attend que l'audio se termine
|
||||
- **Transition** : Vers `naming` quand l'audio se termine
|
||||
|
||||
### 3. `naming`
|
||||
|
||||
- **Déclenchement** : Quand l'audio d'intro se termine
|
||||
- **Action** : Affiche un input pour demander le prénom du joueur
|
||||
- **Attente** : L'utilisateur entre son prénom et valide
|
||||
- **Transition** : Vers `bienvenue` quand l'utilisateur valide
|
||||
|
||||
### 4. `bienvenue`
|
||||
|
||||
- **Déclenchement** : Quand l'utilisateur valide son prénom
|
||||
- **Actions** :
|
||||
- Affiche "Bienvenue {prénom} !" à l'écran
|
||||
- Joue l'audio de bienvenue
|
||||
- **Attente** : Attend que l'audio se termine
|
||||
- **Transition** : Vers `star-move` quand l'audio se termine
|
||||
|
||||
### 5. `star-move`
|
||||
|
||||
- **Déclenchement** : Quand l'audio de bienvenue se termine
|
||||
- **Action** : Active le mouvement du joueur (`setCanMove(true)`)
|
||||
- **État** : Le joueur peut maintenant se déplacer librement
|
||||
- **Zone** : La détection de zone devient active (ZoneDetection)
|
||||
|
||||
### 6. `mission2`
|
||||
|
||||
- **Déclenchement** : Quand le joueur entre dans la zone `fabrikExit` (position: `[-5, 25, -15]`)
|
||||
- **Actions** :
|
||||
- Stocke `activityCity: false` dans le store Zustand
|
||||
- Joue l'audio `alertCentral`
|
||||
- **État** : Les systèmes lisent `activityCity` depuis `useGameStore` pour adapter leur comportement
|
||||
- **Attente** : Le joueur atteint la zone de trigger pour `searching_problem`
|
||||
|
||||
### 7. `searching_problem`
|
||||
|
||||
- **Déclenchement** : Quand le joueur entre dans la zone `searchingProblemZone` (position: `[-5, 25, -30]`)
|
||||
- **Actions** :
|
||||
- Joue l'audio `searchingProblem`
|
||||
- Affiche l'objet "central" (position: `[1, 15, -45]`)
|
||||
- **Attente** : Le joueur interagit avec l'objet "central"
|
||||
|
||||
### 8. `preparation`
|
||||
|
||||
- **Déclenchement** : Quand le joueur interagit avec l'objet "central"
|
||||
- **Actions** :
|
||||
- Bloque le mouvement (`setCanMove(false)`)
|
||||
- Cache l'objet "central"
|
||||
|
||||
### 9. `outOfFabrik`
|
||||
|
||||
- **Déclenchement** : (non implémenté pour le moment)
|
||||
- **Action** : Transition vers l'étape finale
|
||||
|
||||
---
|
||||
|
||||
## Fichiers clés
|
||||
|
||||
| Fichier | Rôle |
|
||||
| --------------------------------------- | --------------------------------------------------------- |
|
||||
| `src/managers/stores/useGameStore.ts` | Store Zustand pour l'état global du jeu |
|
||||
| `src/components/game/GameFlow.tsx` | Gère les transitions automatiques et la lecture audio |
|
||||
| `src/components/ui/IntroUI.tsx` | Affiche l'input pour le prénom et le message de bienvenue |
|
||||
| `src/components/zone/ZoneDetection.tsx` | Détecte quand le joueur entre dans une zone |
|
||||
| `src/world/GameStageContent.tsx` | Monte les contenus de mission dans la scène |
|
||||
| `src/data/audioConfig.ts` | Chemins des fichiers audio |
|
||||
| `src/data/zones.ts` | Configuration des zones de transition |
|
||||
|
||||
---
|
||||
|
||||
## Configuration audio
|
||||
|
||||
```typescript
|
||||
// src/data/audioConfig.ts
|
||||
export const AUDIO_PATHS = {
|
||||
intro: "/sounds/fa.mp3",
|
||||
bienvenue: "/sounds/fa.mp3",
|
||||
alertCentral: "/sounds/fa.mp3",
|
||||
searchingProblem: "/sounds/fa.mp3",
|
||||
};
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Configuration des zones
|
||||
|
||||
```typescript
|
||||
// src/data/zones.ts
|
||||
export const ZONES: Zone[] = [
|
||||
{
|
||||
id: "fabrikExit",
|
||||
position: [-5, 25, -15],
|
||||
radius: 10,
|
||||
height: 20,
|
||||
targetStep: "mission2",
|
||||
},
|
||||
{
|
||||
id: "searchingProblemZone",
|
||||
position: [-5, 25, -30],
|
||||
radius: 10,
|
||||
height: 20,
|
||||
targetStep: "searching_problem",
|
||||
},
|
||||
];
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Store Zustand
|
||||
|
||||
```typescript
|
||||
// src/managers/stores/useGameStore.ts
|
||||
interface GameState {
|
||||
mainState: MainGameState;
|
||||
missionFlow: {
|
||||
activityCity: boolean;
|
||||
canMove: boolean;
|
||||
playerName: string;
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Debug
|
||||
|
||||
En mode debug (`?debug` dans l'URL), on peut voir :
|
||||
|
||||
- **Game Step** : L'étape actuelle dans le panneau lil-gui
|
||||
- **Player Position** : Position X, Y, Z du joueur en temps réel
|
||||
- **Zone Visualization** : Anneaux visuels au sol pour les zones + cylindres transparents
|
||||
|
||||
---
|
||||
|
||||
## Notes techniques
|
||||
|
||||
- Le mouvement du joueur est bloqué tant que `canMove` est `false`
|
||||
- Le store Zustand (`useGameStore`) est la source principale de vérité
|
||||
- `GameStepManager` synchronise automatiquement avec le store Zustand lors des transitions
|
||||
- Les transitions via les zones utilisent `GameStepManager.transitionTo()` qui met à jour le store
|
||||
- L'audio utilise un callback `onEnded` pour déclencher les transitions automatiques
|
||||
@@ -32,7 +32,7 @@ This keeps hand tracking active while the player is inside an interaction zone,
|
||||
|
||||
The production repair activation conditions are:
|
||||
|
||||
- active `mainState` is `bike`, `pylone`, or `ferme`
|
||||
- active `mainState` is `ebike`, `pylon`, or `farm`
|
||||
- the active mission step is `inspected`, `repairing`, `reassembling`, or `done`
|
||||
|
||||
This keeps the webcam off during `waiting`, `fragmented`, and `scanning`, then enables hand input only when the repair flow is expected to use hands.
|
||||
|
||||
@@ -8,11 +8,11 @@ The repair game is the current core gameplay loop. It gives three missions the s
|
||||
|
||||
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 |
|
||||
| Mission | Object | Role |
|
||||
| ------- | ------------- | --------------------------------------------- |
|
||||
| `ebike` | E-bike | Repair a damaged cooling core |
|
||||
| `pylon` | Power pylon | Restore relay/panel-like broken parts |
|
||||
| `farm` | Vertical farm | Stabilize irrigation/sensor-like broken parts |
|
||||
|
||||
## Main Files
|
||||
|
||||
@@ -79,7 +79,7 @@ src/managers/stores/useGameStore.ts
|
||||
- `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.
|
||||
The important architectural choice is that reusable repair components do not call `setEbikeState`, `setPylonState`, or `setFarmState` directly. They use generic mission actions so the same component can run for all three missions.
|
||||
|
||||
## Data-Driven Mission Config
|
||||
|
||||
@@ -324,9 +324,9 @@ 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]} />
|
||||
<RepairGame mission="ebike" position={[42.2399, 4.5484, 34.6468]} />
|
||||
<RepairGame mission="pylon" position={[64, 0, -66]} />
|
||||
<RepairGame mission="farm" position={[-24, 0, 42]} />
|
||||
```
|
||||
|
||||
Only the repair game whose `mission` matches `useGameStore().mainState` renders active content.
|
||||
|
||||
+17
-17
@@ -65,18 +65,18 @@ Main states:
|
||||
| Main state | Role |
|
||||
| ---------- | ------------------------------- |
|
||||
| `intro` | Onboarding and opening sequence |
|
||||
| `bike` | E-bike repair sequence |
|
||||
| `pylone` | Power pylon repair sequence |
|
||||
| `ferme` | Vertical farm repair sequence |
|
||||
| `ebike` | E-bike repair sequence |
|
||||
| `pylon` | Power pylon repair sequence |
|
||||
| `farm` | Vertical farm repair sequence |
|
||||
| `outro` | Ending sequence |
|
||||
|
||||
Other important state:
|
||||
|
||||
- `isCinematicPlaying`
|
||||
- `intro`
|
||||
- `bike`
|
||||
- `pylone`
|
||||
- `ferme`
|
||||
- `ebike`
|
||||
- `pylon`
|
||||
- `farm`
|
||||
- `outro`
|
||||
|
||||
Mission steps:
|
||||
@@ -125,28 +125,28 @@ For development and debug tooling, direct setters also exist:
|
||||
```ts
|
||||
const setMainState = useGameStore((state) => state.setMainState);
|
||||
|
||||
setMainState("bike");
|
||||
setMainState("ebike");
|
||||
```
|
||||
|
||||
Direct setters are useful for debug panels, but production gameplay should prefer business actions such as:
|
||||
|
||||
- `advanceGameState`
|
||||
- `completeBike`
|
||||
- `completePylone`
|
||||
- `completeFerme`
|
||||
- `completeEbike`
|
||||
- `completePylon`
|
||||
- `completeFarm`
|
||||
- `completeMission`
|
||||
|
||||
Mission gameplay that can target `bike`, `pylone`, or `ferme` should prefer generic mission actions:
|
||||
Mission gameplay that can target `ebike`, `pylon`, or `farm` should prefer generic mission actions:
|
||||
|
||||
```ts
|
||||
const setMissionStep = useGameStore((state) => state.setMissionStep);
|
||||
const completeMission = useGameStore((state) => state.completeMission);
|
||||
|
||||
setMissionStep("bike", "inspected");
|
||||
completeMission("bike");
|
||||
setMissionStep("ebike", "inspected");
|
||||
completeMission("ebike");
|
||||
```
|
||||
|
||||
This keeps reusable gameplay components such as `RepairGame` from duplicating mission-specific branches like `setBikeState`, `setPyloneState`, and `setFermeState`.
|
||||
This keeps reusable gameplay components such as `RepairGame` from duplicating mission-specific branches like `setEbikeState`, `setPylonState`, and `setFarmState`.
|
||||
|
||||
## Settings Store
|
||||
|
||||
@@ -188,9 +188,9 @@ State/actions:
|
||||
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 mission="ebike" position={[42.2399, 4.5484, 34.6468]} />
|
||||
<RepairGame mission="pylon" position={[64, 0, -66]} />
|
||||
<RepairGame mission="farm" position={[-24, 0, 42]} />
|
||||
```
|
||||
|
||||
`RepairGame` reads the active mission step from the store and writes transitions through generic actions such as `setMissionStep` and `completeMission`.
|
||||
|
||||
Reference in New Issue
Block a user