Files
games/ROADMAP.md
2026-09-20 06:15:50 +02:00

4.0 KiB

Roadmap

Légende

  • ( ) — planned ;
  • (x) — completed ;
  • (d) — deferred ;
  • (c) — cancelled.

Les marqueurs qualifient une ligne de scope. Une même version peut donc apparaître plusieurs fois si une partie est livrée, une partie reportée et une autre annulée.

0.1.0 — Fondation POC

  • (x) 0.1.0 — squelette du workspace, règles, architecture, versions et assets.
  • (x) 0.1.0 — moteur V1 POC, boucle de jeu, input abstrait et rendu SDL3 minimal.
  • (x) 0.1.0 — Reflex et Snake jouables comme POC de réutilisation.
  • (x) 0.1.0 — Desktop SDL3 natif, Android SDL3/Java/JNI et Tauri/WebView/WASM Reflex.
  • (x) 0.1.0 — tracing commun, provenance runtime, packaging et validation multi-appareils.

Le détail historique des prereleases 0.1.0-* reste dans deltas/0.1.0/ et history/0.1.0/.

0.2.0 — Conception du framework modulaire

  • (x) 0.2.0 — fixer la gouvernance documentaire, la nomenclature et le cycle de maturation des idées et décisions.
  • (x) 0.2.0 — inventorier et réserver les capabilities déjà justifiées sans les implémenter prématurément.
  • (x) 0.2.0 — définir les couches, les dépendances autorisées et la frontière entre kernel, capability, plateforme, provider, système de jeu et service.
  • (x) 0.2.0 — établir la matrice plateformes et les archétypes de jeux utilisés pour challenger l'architecture.
  • (x) 0.2.0 — retenir la composition Rust statique comme direction de référence.
  • (d) 0.2.0 — figer un manifest produit/jeu et l'architecture physique définitive des crates → target TBD après observation des POC 0.3.x.
  • (x) 0.2.0 — définir la trajectoire d'implémentation progressive 0.3.x POC puis 0.4.x Uroburas.
  • (x) 0.2.0 — consolider les études acceptées en architecture/règles durables, notamment ownership, réseau, Uroburas et POC, puis fermer les points encore candidats.
  • (x) 0.2.0 — formaliser la stratégie réseau : Actix Web pour le Web/API, asset delivery auto-hébergé H2/H3, WebSocket baseline et WebTransport/QUIC candidat.
  • (x) 0.2.0 — préparer une trajectoire 0.3.x dédiée aux POC plateforme/réseau avec Snake comme jeu-sonde.
  • (x) 0.2.0 — préparer la trajectoire 0.4.x Uroburas Mode 1 et le prompt de session associé après gel de la conception.

0.3.0 — Baseline Snake + premier POC Web direct

  • ( ) 0.3.0 — nettoyer la baseline Snake sans introduire de logique Uroburas et maintenir le runner Desktop SDL3 fonctionnel.
  • ( ) 0.3.0 — produire une adaptation WASM dédiée à Snake sans déplacer le gameplay hors de game-snake-poc.
  • ( ) 0.3.0 — réaliser un POC navigateur direct Snake couvrant clavier, boutons directionnels tactiles, resize, lifecycle, logging, assets et provenance runtime.
  • ( ) 0.3.0 — utiliser uniquement Cargo, wasm-bindgen et Vite/npm pour le chemin de build Web ; aucun script Python ne pilote ce build.
  • ( ) 0.3.0 — documenter les duplications observées, les extractions réellement justifiées et les reports avant promotion RC.

Série 0.3.x — trajectoire actuelle après 0.3.0

  • ( ) 0.3.1 — second host Snake : Tauri Android, en réutilisant la baseline Web/WASM validée et en remplaçant toute orchestration Python du chemin touché.
  • ( ) 0.3.2 — Tauri Desktop + Snake et factorisation WebView uniquement lorsque deux consommateurs réels justifient l'extraction.
  • ( ) 0.3.3 — Android SDL natif multi-ABI avec Cargo/Gradle natifs, sans script Python de build.
  • ( ) 0.3.4 — API de transport realtime + WebSocket/tokio-tungstenite baseline, sans serveur Uroburas Mode 3.
  • ( ) 0.3.5 — POC WebTransport/QUIC sur le même protocole, avec comparaison mesurée et fallback WebSocket.
  • ( ) 0.3.6 — consolidation des POC plateforme/réseau et préparation de la baseline 0.4.x.

La numérotation 0.3.1+ reste révisable à partir des résultats réels ; les lignes ci-dessus décrivent le planning actuel, pas une obligation de créer des versions artificielles.