# games.sasedev Workspace expérimental puis productif pour des jeux multiplateformes principalement développés en Rust, avec une première orientation Android et un socle SDL3. ## Principes de départ - un seul workspace Cargo ; - toutes les crates Rust sous `crates/` ; - générations de moteur coexistantes sous `crates/engines/engine-vN-*` ; - une ou plusieurs crates par jeu sous `crates/games/` ; - assets hors des crates sous `assets/` ; - `assets/common/` pour les ressources mutualisées et un répertoire par jeu pour les ressources spécifiques ; - frontend Android sous `Android/`, en Java, avec une partie commune et une partie spécifique par jeu ; - Android de production orienté SDL3 natif/Java/JNI ; Tauri Android reste un POC de référence et non un template de jeu ; - hosts navigateur directs sous `Web/`, avec frontend Vite/TypeScript séparé des adapters Rust/WASM ; - monétisation optionnelle et spécifique à chaque plateforme/distribution ; - runner Desktop natif SDL3 par défaut, avec variante Tauri uniquement si un besoin futur la justifie ; - documentation sous `docs/` ; - règles normatives indexées par `RULES.md` ; - livraison par archives delta versionnées ; - versionnement SemVer avec labels de maturité normalisés. ## Baseline Version stable de référence : `0.3.4`. Version active : `0.3.5-alpha.2.fix.1`. `0.3.2` reste différée. La stable `0.3.4` livre la première baseline realtime : contrat binaire transport-neutral, backend WebSocket Tokio/tokio-tungstenite, limites et deadlines, tests loopback/robustesse, smoke runtime localhost public et frontières de dépendances empêchant moteurs et gameplay de dépendre d'un backend concret. `0.3.5-alpha.2.fix.1` ferme le test d’établissement du backend WebTransport natif minimal : Quinn/HTTP/3, identité TLS locale ECDSA P-256 courte ou injectée, pin SHA-256 et établissement client/server loopback. Streams applicatifs, framing fiable et adaptation `RealtimeConnection` restent réservés à la tranche suivante. Les deux premiers jeux sont des POC structurels : `game-reflex-poc` et `game-snake-poc`. Ils existent d'abord pour valider les frontières du workspace, le moteur, les assets et le packaging multiplateforme. ## Entrées documentaires - [`RULES.md`](RULES.md) - [`ROADMAP.md`](ROADMAP.md) - [`CHANGELOG.md`](CHANGELOG.md) - [`docs/000-README.md`](docs/000-README.md) - [`docs/architecture/001-WORKSPACE_ARCHITECTURE.md`](docs/architecture/001-WORKSPACE_ARCHITECTURE.md) - [`docs/objectives/001-PROJECT_OBJECTIVES.md`](docs/objectives/001-PROJECT_OBJECTIVES.md) - [`docs/games/001-GAME_CLASSIFICATION.md`](docs/games/001-GAME_CLASSIFICATION.md) ## Diagnostics et tests Les socles transverses `crates/common/game-assets-lib` et `crates/common/game-logging-lib` fournissent respectivement la résolution logique des assets et le tracing commun. Le realtime est séparé entre `game-realtime-transport-lib`, contrat binaire transport-neutral, `game-realtime-websocket-lib`, backend Tokio/tokio-tungstenite, et `game-realtime-webtransport-lib`, backend WebTransport/QUIC candidat dont la première frontière native couvre TLS/pinning et établissement de session. Leurs responsabilités sont documentées dans leurs README/USAGE locaux lorsqu'un guide d'usage est justifié. `game-realtime-websocket-smoke` fournit la preuve runtime localhost hors harness de test ; le smoke WebTransport public est planifié après le chemin fiable. Les tests unitaires résident hors `src/` sous `unit_tests/`; les tests d’intégration/environnement résident sous `tests/`.