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

2.2 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.

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.