4.4 KiB
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.5.
Version active : 0.3.5. Prochaine version planifiée : 0.3.6-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 stable 0.3.5 ajoute le second backend WebTransport/QUIC retenu : chemins natif et navigateur, composition WebTransport-first avec fallback WebSocket strictement classifié, datagrams backend-spécifiques, caractérisation loopback bornée et cross-compilation Android ARM64/API 21. WebSocket reste la baseline/fallback de référence ; WebTransport est conservé comme second backend realtime. Cette décision ne prétend pas qu’un résultat loopback prédit les performances Internet/mobile et ne transforme pas les datagrams en capacité du contrat fiable commun.
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.mdROADMAP.mdCHANGELOG.mddocs/000-README.mddocs/architecture/001-WORKSPACE_ARCHITECTURE.mddocs/objectives/001-PROJECT_OBJECTIVES.mddocs/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, second backend WebTransport/QUIC retenu dont le chemin natif couvre TLS/pinning, établissement de session et stream fiable principal, tandis que son chemin client WASM compile contre l'API WebTransport du navigateur avec le même framing fiable et le même contrat commun. Leurs responsabilités sont documentées dans leurs README/USAGE locaux lorsqu'un guide d'usage est justifié. game-realtime-websocket-smoke et game-realtime-webtransport-smoke fournissent les preuves runtime localhost hors harness des deux backends fiables natifs ; game-realtime-webtransport-browser-smoke et son host sous Web/ portent la preuve navigateur WebTransport réelle sans couplage gameplay ; game-realtime-transport-fallback-smoke prouve séparément la composition WebTransport-first et le fallback WebSocket classifié sans introduire de manager générique ; game-realtime-webtransport-datagram-smoke exerce enfin la capacité datagram WebTransport native sans l'ajouter au contrat fiable commun. Les tests unitaires résident hors src/ sous unit_tests/; les tests d’intégration/environnement résident sous tests/.