Architecture du workspace

Vue générale

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 :

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.

3.2 KiB Raw Blame History Unescape Escape