# Simulate — Paper prototyping

Tu es un testeur QA et game designer. Ton role : **jouer le jeu sur papier** a partir du `GAME_SEQUENCE.yaml` et des `data/*.yaml`. Trouver les frictions, les desequilibres et les trous AVANT d'ecrire une seule ligne de code.

---

## Sommaire

1. Quand simuler
2. Mode Narrative
3. Mode Balance
4. Mode Exhaustive
5. Iterer apres simulation

---

## 1. Quand simuler

- **Apres** `skills/sequence.md`, **avant** `skills/gate.md`
- **Obligation** : au moins 1 simulation narrative avant le gate
- **Recommande** : 1 balance + 1 exhaustive avant le gate

### Prerequis

- `GAME_SEQUENCE.yaml` existe et est valide
- Pour le mode balance : au moins 1 fichier `data/*.yaml`

---

## 2. Mode Narrative

Jouer le jeu comme un persona. Derouler chaque state du point de vue d'un joueur fictif.

### Personas disponibles

| Persona | Profil | Focus |
|---------|--------|-------|
| **First Timer** | N'a jamais joue, explore tout | Onboarding, tutoriel, clarte |
| **Speedrunner** | Connait le jeu, cherche l'optimal | Skips, exploits, ennui |
| **Casual** | Joue 10 min, facilement frustre | Difficulte, friction, retention |
| **Completionniste** | Veut tout voir/faire | Contenu cache, progression, satisfaction |
| **Custom** | Profil defini par l'user | ... |

### Process

1. Choisir un persona (proposer First Timer par defaut)
2. Derouler chaque state de la sequence
3. A chaque transition, verifier : **le persona VOUDRAIT-IL faire cette transition ?**
4. Noter les frictions, les moments forts, les trous emotionnels

### Format output

```
## Simulation Narrative — {persona}

### State: main_menu
Le joueur arrive sur le menu. Bouton "Play" visible.
→ Feeling: neutre, leger enthousiasme
→ Friction: aucune
→ Transition: click Play → gameplay

### State: gameplay (core loop — iteration 1)
Premiere boucle : explore → encounter → resolve → reward
→ Feeling: curiosite → tension → satisfaction → gratification
→ Friction: le resolve dure trop longtemps pour un casual (>30s)
→ Suggestion: ajouter un hint apres 15s d'inactivite

### State: gameplay (core loop — iteration 2)
Deuxieme boucle, le joueur connait le pattern
→ Feeling: confiance → defi → maitrise → routine
→ Friction: la reward est identique → lassitude
→ Suggestion: varier les drops, ajouter un rare

### State: gameplay (core loop — iteration 3)
Troisieme boucle, le pattern est acquis
→ Feeling: routine → ennui OU maitrise → flow
→ Friction: depend de la variete introduite
→ Suggestion: introduire un nouveau type d'encounter ici

### State: game_over
Premiere mort. Ecran "Game Over" avec retry/quit.
→ Feeling: frustration legere (mort juste = acceptable)
→ Friction: pas de feedback sur pourquoi il est mort
→ Suggestion: ajouter un "killed by {enemy}" ou un tip

...

## Resume
- **Frictions detectees** : 3
- **Frictions critiques** : 1 (resolve trop long)
- **Moments forts** : 2 (premiere recompense, boss defeat)
- **Trou emotionnel** : entre advance et explore (transition plate)
- **Suggestions** : 4 (voir detail ci-dessus)
```

### Simuler la core loop plusieurs fois

Ne pas simuler qu'une seule iteration de la core loop. Minimum 3 :
- **Iteration 1** : decouverte, tout est nouveau
- **Iteration 2** : familiarite, le pattern se repete
- **Iteration 3** : routine ou maitrise ? C'est la qu'on voit si ca tient

---

## 3. Mode Balance

Lit les `data/*.yaml` et verifie les chiffres. Pas de feeling ici — que du calcul.

### Checks

| Check | Quoi | Comment |
|-------|------|---------|
| **DPS vs HP** | Combien de coups pour tuer chaque ennemi ? | `enemy.hp / player.damage` |
| **Survie** | Combien de coups le joueur encaisse ? | `player.hp / enemy.damage` |
| **Economie** | Le joueur gagne assez pour progresser ? | `income_per_minute vs cost_next_tier` |
| **Pacing** | Combien de temps par boucle core ? | Somme des durees estimees |
| **Difficulte** | Courbe lineaire ou exponentielle ? | Comparer les ratios entre niveaux |

### Format output

```
## Simulation Balance

### Combat
| Ennemi | HP | Player DPS | Temps de kill | Coups encaisses | Verdict |
|--------|---:|-----------:|--------------:|----------------:|---------|
| Goblin | 30 | 10 | 3s | 20 (safe) | OK |
| Orc | 100 | 10 | 10s | 6.7 (risque) | Long pour un ennemi basique |
| Troll (boss) | 300 | 10 | 30s | 3.3 (dangereux) | OK pour un boss |

### Economie
| Source | Gold/min | Cout tier suivant | Temps pour acheter | Verdict |
|--------|--------:|------------------:|------------------:|---------|
| Goblin drop | 15 | 200 (epee fer) | 13.3 min | Grind excessif |
| Orc drop | 40 | 200 (epee fer) | 5 min | OK |

### Pacing
| Boucle | Duree estimee | Target | Verdict |
|--------|:------------:|:------:|---------|
| Core (forest_01) | 45s | 30-60s | OK |
| Core (forest_boss) | 120s | 90-180s | OK |
| Session complete | 25 min | 15-30 min | OK |

### Courbe de difficulte
| Level | Enemy HP total | Player Power | Ratio | vs precedent |
|-------|:-------------:|:------------:|:-----:|:--------------:|
| forest_01 | 90 | 10 | 9.0 | — |
| forest_02 | 160 | 10 | 16.0 | +78% |
| forest_boss | 330 | 10 | 33.0 | +106% |

→ Sauts trop grands entre niveaux. Ajouter un level intermediaire ou augmenter le player power.

## Recommandations
1. Reduire HP Orc a 60 (kill en 6s)
2. Augmenter gold drop de 15 a 25/min (tier 1 achetable en 8 min)
3. Ajouter forest_03 entre forest_02 et forest_boss pour lisser la courbe
```

### Pas de data ? Pas de balance

Si les `data/*.yaml` n'existent pas, proposer de les creer d'abord via `skills/sequence.md`. Le mode balance sans donnees = devinettes.

---

## 4. Mode Exhaustive

Parser le `GAME_SEQUENCE.yaml` et construire le graphe de transitions.

### Checks

| Check | Ce qu'on cherche |
|-------|-----------------|
| **Dead ends** | States sans transition sortante (autre que quit) |
| **Orphans** | States jamais atteints depuis entry |
| **Boucles infinies** | Loops sans condition de sortie |
| **Missing transitions** | State mentionne dans une transition mais pas defini |
| **Guards contradictoires** | Conditions qui s'excluent mutuellement sur toutes les sorties d'un state |
| **Unreachable guards** | Conditions qui ne peuvent jamais etre vraies |

### Format output

```
## Simulation Exhaustive

### Couverture
- States definis : 12
- States atteignables : 11
- Orphans : 1 (bonus_level — aucune transition y mene)

### Paths
- Shortest path (splash → victory) : 5 transitions
- Longest path (sans boucles) : 9 transitions
- Loops detectes : 2 (core loop, meta loop) — intentionnels

### Issues
| Sev | Issue | Detail |
|-----|-------|--------|
| CRITICAL | Orphan state | `bonus_level` n'est jamais atteint |
| WARNING | No exit from pause | `pause` ne peut revenir qu'a `gameplay` (pas de quit?) |
| WARNING | Guard contradiction | `main_menu` : `save_exists` et `new_game` couvrent-ils tous les cas ? |
| INFO | Linear meta | meta loop a un seul chemin (peu de rejouabilite) |

### Graphe simplifie
```
splash → main_menu → gameplay <-> pause
                        |
                   +----|----+
                   v    v    v
              game_over  victory
                   |         |
                   v         v
              main_menu  main_menu

Core: explore → encounter → resolve → reward → advance -+
         ^                                               |
         +-----------------------------------------------+
```
```

---

## 5. Iterer apres simulation

Les resultats de simulation menent a des modifications. Mais `skills/simulate.md` **propose, ne modifie pas**.

| Type de finding | Ou corriger | Skill |
|----------------|-------------|-------|
| Friction narrative | `GAME_SEQUENCE.yaml` (reorder states, add transitions) | `skills/sequence.md` |
| Desequilibre balance | `data/*.yaml` (ajuster les chiffres) | `skills/sequence.md` |
| Issue exhaustive | `GAME_SEQUENCE.yaml` (ajouter transitions manquantes) | `skills/sequence.md` |

**NE PAS toucher au code** — on est encore en phase papier.

### Boucle simulation → correction

```
skills/simulate.md (narrative) → findings → corriger GAME_SEQUENCE.yaml
skills/simulate.md (balance)   → findings → corriger data/*.yaml
skills/simulate.md (exhaustive) → findings → corriger GAME_SEQUENCE.yaml
→ re-simuler si necessaire
→ skills/gate.md quand les findings critiques sont resolus
```

---

## Checklist Review

Avant de valider une simulation :

- [ ] Le persona est pertinent pour le type de jeu
- [ ] La core loop a ete simulee au moins 3 iterations (mode narrative)
- [ ] Les donnees numeriques viennent des `data/*.yaml`, pas inventees (mode balance)
- [ ] Tous les states du YAML ont ete visites (mode exhaustive)
- [ ] Les findings critiques sont clairement identifies
- [ ] Les suggestions sont actionnables (pas vagues)
- [ ] Le resume est present avec le comptage des frictions/moments forts
- [ ] Les corrections proposees pointent vers le bon fichier

---

## Pieges courants

| Piege | Solution |
|-------|---------|
| Simuler qu'une seule iteration de la core loop | Minimum 3 : decouverte, familiarite, routine |
| Mode balance sans data/*.yaml | Creer les data d'abord, pas de chiffres inventes |
| Confondre feeling et opinion | "C'est ennuyeux" = opinion. "La transition explore→encounter manque de tension rising" = feeling structure |
| Tout marquer comme critique | Reserver `critical` aux vrais bloquants. Un desequilibre mineur = warning |
| Ne simuler qu'avec First Timer | Le Speedrunner et le Casual trouvent des problemes differents |

---

## See also

| Skill | Quand l'utiliser |
|-------|-----------------|
| `skills/sequence.md` | Creer ou modifier la sequence |
| `skills/gate.md` | Valider apres simulation |
| `skills/plan.md` | Revenir a la vision si la simulation revele un probleme fondamental |
