0.3.5-beta.2
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: README.md -->
|
||||
<!-- version: 80 -->
|
||||
<!-- version: 81 -->
|
||||
|
||||
# games.sasedev
|
||||
|
||||
@@ -27,9 +27,9 @@ Workspace expérimental puis productif pour des jeux multiplateformes principale
|
||||
|
||||
Version stable de référence : `0.3.4`.
|
||||
|
||||
Version active : `0.3.5-beta.1.fix.1`. `0.3.2` reste différée.
|
||||
Version active : `0.3.5-beta.2`. `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-beta.1.fix.1` ferme un défaut de cohérence de version du host navigateur découvert pendant la validation large ; `0.3.5-beta.1` avait ouvert la validation large du POC WebTransport/QUIC après fermeture de toutes les tranches alpha : chemins natif et navigateur, composition WebTransport-first avec fallback WebSocket strictement classifié, datagrams backend-spécifiques et caractérisation loopback bornée. La beta n’ajoute aucune nouvelle capacité ; elle doit confirmer le workspace complet, les smokes retenus, le build navigateur/WASM, la portabilité Android raisonnable et les frontières de dépendances avant consolidation pré-RC. La conclusion technique provisoire reste de conserver WebTransport comme second backend à côté de WebSocket, sans prétendre qu’un résultat loopback prédit les performances Internet/mobile.
|
||||
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-beta.2` consolide le résultat du POC WebTransport/QUIC après validation large de `0.3.5-beta.1.fix.1` : 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. La décision désormais figée pour la RC est de **retenir WebTransport comme second backend realtime** à côté de WebSocket, qui reste la baseline/fallback de référence. 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.
|
||||
|
||||
@@ -45,4 +45,4 @@ Les deux premiers jeux sont des POC structurels : `game-reflex-poc` et `game-sna
|
||||
|
||||
## 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 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/`.
|
||||
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/`.
|
||||
|
||||
Reference in New Issue
Block a user