# Architecture du workspace ## Vue générale ```text games.sasedev/ ├── crates/ │ ├── common/ │ │ ├── game-assets-lib/ │ │ └── game-logging-lib/ │ ├── engines/ │ │ ├── engine-v1-common/ │ │ ├── engine-v1-platform-api/ │ │ └── engine-v1-sdl/ │ ├── games/ │ │ ├── game-reflex-poc/ │ │ └── game-snake-poc/ │ └── apps/ │ ├── game-reflex-poc-desktop/ │ ├── game-snake-poc-desktop/ │ └── game-reflex-poc-tauri/ ├── assets/ │ ├── common/ │ ├── game-reflex-poc/ │ └── game-snake-poc/ ├── Tauri/ │ └── game-reflex-poc/ ├── Android/ │ ├── common/ │ ├── game-reflex-poc/ │ └── game-snake-poc/ ├── docs/ ├── deltas/ ├── prompts/ └── scripts/ ``` ## Générations du moteur Une génération `engine-vN` est une ligne de compatibilité. Un jeu peut rester sur `engine-v1` pendant qu'un nouveau jeu expérimente `engine-v2`. Les anciens jeux sont ensuite migrés individuellement. Les capacités transverses réutilisables sont séparées des générations moteur. `game-assets-lib` porte la résolution logique des assets et `game-logging-lib` le tracing commun. Les subdivisions moteur sont exprimées par crates afin de ne pas forcer un jeu à dépendre de capacités inutiles. La baseline sépare déjà : - `engine-v1-common` : types et comportements génériques indépendants des plateformes ; - `engine-v1-platform-api` : contrats abstraits des services plateforme ; - `engine-v1-sdl` : frontière d'intégration SDL3, volontairement minimale dans la baseline. ## Jeux Chaque jeu est une crate indépendante sous `crates/games/`. Un jeu ne duplique pas une crate moteur. Il sélectionne explicitement la génération qu'il consomme. ## Assets Les assets sont extérieurs aux crates. Le packaging compose : ```text assets/common/ + assets// ``` Le runtime devra conserver une distinction logique entre ressources communes et ressources spécifiques afin d'éviter les collisions silencieuses. ## Runners Desktop Chaque crate de jeu reste une bibliothèque. Une crate binaire Desktop séparée sous `crates/apps/` la consomme pour permettre les itérations locales rapides. Cette séparation évite d’introduire `main`, des choix de plateforme ou du code de lancement dans le gameplay réutilisable. ## Variante Tauri / WebAssembly La variante Tauri est distincte du runner SDL3 natif. `game-reflex-poc-tauri` porte deux faces du même launcher : - une bibliothèque `wasm32-unknown-unknown` qui adapte `game-reflex-poc` à `wasm-bindgen` ; - un binaire natif Tauri qui héberge la WebView locale. Le frontend statique sous `Tauri/game-reflex-poc/frontend/` pilote un Canvas et appelle l'adaptateur WASM. Les règles Reflex restent exclusivement dans `game-reflex-poc`.