Files
games/docs/studies/010-PLATFORM_POC_REUSE_AND_DELTA.md
2026-09-18 15:03:33 +02:00

98 lines
2.2 KiB
Markdown

<!-- file: docs/studies/010-PLATFORM_POC_REUSE_AND_DELTA.md -->
<!-- version: 1 -->
# Réutilisation et delta attendu des POC plateforme
## Statut
Étude non normative pour `0.2.0-0-pre.4`.
## Principe
Un POC plateforme est utile s'il répond à une question avec peu de code neuf.
S'il nécessite immédiatement une réécriture large du jeu, cela indique soit :
- une mauvaise frontière actuelle ;
- un adapter manquant ;
- une capability mal placée ;
- un POC trop ambitieux.
## Éléments à ne pas dupliquer
### Gameplay
Les crates `game-*` restent source de vérité des règles.
### Assets
Les assets communs et game-specific existants doivent être réutilisés.
### Logging
Le POC doit brancher les domaines de tracing existants plutôt que créer un logger spécifique.
### Runtime provenance
Chaque nouveau host/backend doit enrichir la provenance existante, pas créer un mécanisme parallèle.
### Semantic input
Les nouvelles entrées touch/keyboard/pointer doivent converger vers les actions sémantiques du jeu.
## Éléments probablement à extraire
Les POC peuvent révéler des duplications aujourd'hui acceptables dans le POC `0.1.0`.
Candidats :
- bridge WASM générique ;
- frontend shell commun ;
- input adapter Web ;
- lifecycle Web/Tauri ;
- asset loader Web ;
- tracing frontend commun ;
- fullscreen/resize ;
- mobile lifecycle abstraction ;
- packaging/build tooling.
Aucune extraction n'est imposée avant d'avoir vu la duplication réelle.
## Reflex comme sonde
Reflex reste un bon POC de plateforme parce qu'il est petit.
Il permet d'isoler :
- pointer/touch ;
- timing ;
- rendu simple ;
- WASM ;
- bridge ;
- startup.
## Snake comme seconde sonde
Snake vérifie que la solution n'est pas façonnée uniquement pour Reflex.
Il ajoute :
- keyboard/swipe ;
- update continu ;
- plusieurs entités ;
- état de jeu persistant plus longtemps ;
- besoin potentiel de virtual controls.
## Règle de modification minimale
Pour chaque POC, documenter :
1. fichiers/crates réutilisés sans changement ;
2. fichiers modifiés ;
3. nouveaux adapters ;
4. nouveau code strictement platform-specific ;
5. duplications provisoires ;
6. extractions candidates détectées.
Cette comparaison servira à décider le découpage final du framework.