0.1.0

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 17 -->
+<!-- version: 18 -->
 
 # Documentation games.sasedev
 
@@ -16,6 +16,7 @@
 - [`architecture/005-ASSET_ARCHITECTURE.md`](architecture/005-ASSET_ARCHITECTURE.md) — assets communs/spécifiques hors crates et packaging.
 - [`architecture/009-ENGINE_V1_RENDER_SCENE.md`](architecture/009-ENGINE_V1_RENDER_SCENE.md) — scène 2D portable, rectangles normalisés et backend SDL3.
 - [`architecture/010-RUNTIME_PROVENANCE.md`](architecture/010-RUNTIME_PROVENANCE.md) — provenance plateforme/device/runtime/input pour sessions, scores et analytics.
+- [`architecture/011-POST_0_1_0_DIRECTION.md`](architecture/011-POST_0_1_0_DIRECTION.md) — décisions de transition entre le POC stable 0.1.0 et la conception modulaire 0.2.0.
 
 ## Jeux
 

docs/architecture/011-POST_0_1_0_DIRECTION.md

@@ -0,0 +1,69 @@
+<!-- file: docs/architecture/011-POST_0_1_0_DIRECTION.md -->
+<!-- version: 1 -->
+
+# Direction après 0.1.0
+
+## Statut
+
+`0.1.0` clôt le POC multi-plateforme.
+
+Cette version démontre qu'un gameplay Rust commun peut être exécuté via SDL3 sur Desktop et Android, ainsi que via WASM dans une application Tauri Desktop. Elle ne constitue pas encore l'architecture définitive du framework.
+
+## Décisions de direction déjà acquises
+
+La génération suivante doit éviter de transformer `engine-v1` en moteur monolithique contenant toutes les fonctionnalités possibles.
+
+La cible conceptuelle sépare au minimum :
+
+- un kernel moteur commun volontairement petit ;
+- des capabilities fonctionnelles réutilisables ;
+- des adaptateurs plateforme ;
+- des providers externes ;
+- les logiques propres aux jeux ;
+- les services et serveurs online ;
+- les outils de build et de distribution.
+
+La composition des produits doit rester statique par défaut. Un jeu ou un launcher ne dépend que des capabilities dont il a réellement besoin et sélectionne explicitement les implémentations disponibles sur sa plateforme.
+
+## Réservation avant implémentation
+
+`0.2.0` commence par une phase de conception.
+
+Elle doit inventorier les besoins plausibles déjà identifiés par les familles de jeux envisagées, les classer et réserver leurs frontières sans créer automatiquement une crate ni une implémentation pour chaque idée.
+
+Une capability réservée n'impose aucune dépendance aux jeux qui ne l'utilisent pas.
+
+Les implémentations sont ensuite ajoutées progressivement lorsqu'un jeu ou un type de jeu en fournit un besoin concret.
+
+## Domaines déjà identifiés pour le brainstorming 0.2.0
+
+Le brainstorming doit notamment couvrir, sans considérer cette liste comme une architecture déjà figée :
+
+- input sémantique, bindings, gestes et contrôles virtuels ;
+- rendu, sprites, textures, animation, maps, tiles et collisions ;
+- score, vies, énergie, expérience, niveaux et progression ;
+- inventaire, équipements, loot, quêtes et systèmes de puzzle réutilisables ;
+- sauvegarde locale, cloud sync et politiques online/offline ;
+- authentification anonyme ou obligatoire et account linking ;
+- leaderboards, achievements, sessions, lobby, matchmaking, chat et multiplayer temps réel ;
+- publicité, rewarded ads, achats intégrés et providers par plateforme ;
+- assets distants, CDN et configuration distante ;
+- logging/tracing par domaines avec politique de build statique ;
+- services Web modulaires et protocoles HTTP, WebSocket, WebRTC ou gRPC selon le besoin ;
+- build/distribution Android multi-ABI sans dépendre durablement du script Python du POC ;
+- comparaison expérimentale SDL Android / Tauri Android ;
+- jeux mono-plateforme autant que jeux multi-plateformes.
+
+## Jeux comme moteurs de validation architecturale
+
+L'architecture future doit être éprouvée par des jeux concrets plutôt que construite dans le vide.
+
+Les POC Reflex et Snake peuvent devenir les premiers laboratoires de modularité : configuration des règles, assets, contrôles, maps, obstacles, multiplayer, parties déterministes et leaderboards.
+
+D'autres archétypes envisagés — aventure/puzzle à énergie et inventaire, course, fighting 1v1, hack'n slash, MMORPG/PKE — servent à révéler des besoins architecturaux, pas à imposer immédiatement leur implémentation.
+
+## Frontière avec 0.1.0
+
+Le catalogue détaillé des capabilities, la matrice plateformes, le graphe de dépendances autorisées, le manifest produit/jeu, l'arborescence cible des crates et la roadmap détaillée des implémentations ne sont volontairement pas figés dans `0.1.0`.
+
+Ils constituent le travail de conception initial de `0.2.0`.