2.2 KiB
Architecture modulaire et ownership
Décision
Le framework est structuré par responsabilité et non par jeu ou plateforme unique.
game-specific
↓
game-systems
↓
technical capabilities
↓
engine kernel contracts
La composition produit ajoute latéralement les platform adapters, providers, server contracts et tooling.
Engine kernel
Le kernel contient uniquement les primitives nécessaires à tous les jeux consommateurs : lifecycle, update/render, temps, runtime events, provenance et contrats minimaux input/render.
Il ne contient pas de logique Snake, publicité, authentification, HTTP ou règles Uroburas.
Technical capabilities
Les capabilities fournissent des mécanismes techniques réutilisables : input, rendu 2D, audio, assets/content, localisation, persistence, networking et logging/telemetry.
Game-systems
Les game-systems portent des mécaniques réutilisables entre jeux lorsque leur API est réellement justifiée : grid/tilemap, collision, caméra gameplay, stages, score, vies/attempts, timed entities, pickups/inventory et status effects lorsque leur généralisation devient réelle.
Game-specific
Une crate jeu conserve les règles propres au jeu, la composition des systèmes et les concepts qui n'ont pas encore de second consommateur crédible.
Une mécanique n'est pas extraite uniquement parce qu'elle pourrait théoriquement servir ailleurs.
Adapters, providers et services
Les adapters traduisent un environnement local. Les providers encapsulent un service externe. Le gameplay ne dépend pas directement d'un adapter ou SDK provider concret.
Les services serveur possèdent leurs modèles métier et leurs contrats de transport dédiés. Actix, Tungstenite, Protobuf ou Maud ne remontent pas dans le gameplay.
Tooling
Éditeurs, build tooling, audits et outils de publication restent séparés du runtime du jeu.
Création de crates
Une nouvelle crate est justifiée par une frontière stable ou un besoin de réutilisation réel.
Le projet évite à la fois la crate jeu monolithique et l'explosion artificielle en une crate par concept minuscule.