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
• ROADMAP.md
• CHANGELOG.md
• docs/000-README.md
• docs/architecture/001-WORKSPACE_ARCHITECTURE.md
• docs/objectives/001-PROJECT_OBJECTIVES.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/.