84 lines
3.2 KiB
Markdown
84 lines
3.2 KiB
Markdown
<!-- file: docs/architecture/001-WORKSPACE_ARCHITECTURE.md -->
|
||
<!-- version: 5 -->
|
||
|
||
# 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/
|
||
│ └── game-reflex-poc-wasm/
|
||
├── assets/
|
||
│ ├── common/
|
||
│ ├── game-reflex-poc/
|
||
│ └── game-snake-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/<game>/
|
||
```
|
||
|
||
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`.
|
||
|
||
La crate Tauri suit le modèle des apps Desk KSP : façade `lib.rs`, pont `tauri.rs`, modules propriétaires séparés et frontend Vite/TypeScript local à la crate.
|