# 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`. Prochaine version planifiée : `0.3.5-alpha.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. La RC a été validée sans défaut de publication, puis promue mécaniquement en stable. `0.3.5` est réservée au POC WebTransport/QUIC et à sa comparaison avec WebSocket, sans rouvrir dans `0.3.4` les couches wire/session/synchronisation. 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, et `game-realtime-websocket-lib`, backend Tokio/tokio-tungstenite ; leurs responsabilités et leur consommation sont documentées dans leurs README/USAGE locaux. `game-realtime-websocket-smoke` fournit la preuve runtime localhost hors harness de test. Les tests unitaires résident hors `src/` sous `unit_tests/`; les tests d’intégration/environnement résident sous `tests/`.