2.4 KiB
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.
Snake comme sonde unique des POC plateforme
Snake devient le jeu-sonde de référence pour les POC plateforme de la future série 0.3.x.
Il exerce simultanément :
- keyboard/swipe/touch ;
- update continu ;
- grille et déplacements ;
- plusieurs entités ;
- état de jeu persistant ;
- obstacles/collision ;
- score/lives potentiels ;
- resize/orientation ;
- besoin potentiel de virtual controls ;
- future extension multi-snake/multiplayer.
Les briques Tauri/WASM déjà construites avec Reflex restent des références techniques à réutiliser, mais les nouveaux POC ne doivent plus utiliser Reflex comme jeu principal.
Règle de modification minimale
Pour chaque POC, documenter :
- fichiers/crates réutilisés sans changement ;
- fichiers modifiés ;
- nouveaux adapters ;
- nouveau code strictement platform-specific ;
- duplications provisoires ;
- extractions candidates détectées.
Cette comparaison servira à décider le découpage final du framework.