games/README.md

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.5. 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.5 ajoute au backend WebTransport natif déjà robuste un smoke runtime localhost hors harness : identité TLS locale en mémoire, pin SHA-256 exact, session WebTransport réelle, stream fiable principal, round-trip binaire bidirectionnel et fermeture propre avec verdict PASS déterministe. Navigateur/WASM, fallback et datagrams restent réservés aux tranches suivantes.

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 le chemin natif couvre désormais TLS/pinning, établissement de session et stream fiable principal adapté au 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. Les tests unitaires résident hors src/ sous unit_tests/; les tests d’intégration/environnement résident sous tests/.