0.1.0-0-pre.2

docs/architecture/001-WORKSPACE_ARCHITECTURE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/001-WORKSPACE_ARCHITECTURE.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Architecture du workspace
 
@@ -12,9 +12,12 @@ games.sasedev/
 │   │   ├── engine-v1-common/
 │   │   ├── engine-v1-platform-api/
 │   │   └── engine-v1-sdl/
-│   └── games/
-│       ├── game-reflex-poc/
-│       └── game-snake-poc/
+│   ├── games/
+│   │   ├── game-reflex-poc/
+│   │   └── game-snake-poc/
+│   └── apps/
+│       ├── game-reflex-poc-desktop/
+│       └── game-snake-poc-desktop/
 ├── assets/
 │   ├── common/
 │   ├── game-reflex-poc/
@@ -54,3 +57,7 @@ assets/<game>/
 ```
 
 Le runtime devra conserver une distinction logique entre ressources communes et ressources spécifiques afin d'éviter les collisions silencieuses.
+
+## Runners Desktop
+
+Chaque crate de jeu reste une bibliothèque. Une crate binaire Desktop séparée sous `crates/apps/` la consomme pour permettre les itérations locales rapides. Cette séparation évite d’introduire `main`, des choix de plateforme ou du code de lancement dans le gameplay réutilisable.

docs/architecture/003-SDL3_PLATFORM_ABSTRACTION.md

@@ -0,0 +1,58 @@
+<!-- file: docs/architecture/003-SDL3_PLATFORM_ABSTRACTION.md -->
+<!-- version: 1 -->
+
+# Abstraction SDL3 et plateformes
+
+## Frontière générale
+
+Le gameplay ne doit pas connaître directement Linux, Windows, macOS, Android ou le navigateur. SDL3 est une frontière technique commune, complétée par des services plateforme lorsqu'une capacité n'appartient pas au cœur SDL.
+
+```text
+Game library
+     │
+Engine API
+     │
+SDL3 boundary
+ ┌───┼───────────────┐
+ │   │               │
+Desktop           Android            Web
+native            SDL/JNI            WASM/browser
+```
+
+## Desktop
+
+Le runner Desktop est la cible d'itération la plus rapide. Il utilise la crate lib du jeu et, à terme, le runtime SDL3 natif. Les entrées disponibles peuvent inclure clavier, souris, trackpad, gamepad et joystick.
+
+La cible Desktop sert à tester le gameplay, le rendu, la boucle de jeu, l'audio et les abstractions communes sans imposer un déploiement sur émulateur ou téléphone.
+
+## Android
+
+Android empaquette le jeu natif dans une application standard. La structure cible combine : SDL3 Android, une bibliothèque native Rust, la couche Java commune, les extensions Java spécifiques au jeu, les assets communs et spécifiques, puis les SDK Android requis.
+
+Les fonctionnalités suivantes restent côté plateforme Android : lifecycle, JNI, Ads, Billing, haptique, share sheet, intégrations Play et autres API Android spécifiques.
+
+Le gameplay Rust ne doit pas dépendre des classes Java ni d'une régie publicitaire particulière.
+
+## Web / WASM
+
+La cible Web est prévue comme cible ultérieure. SDL3 peut être utilisé avec une chaîne Web adaptée, notamment Emscripten, tandis que le navigateur fournit ses propres contraintes de boucle d'événements, audio, stockage, permissions et interaction utilisateur.
+
+Une version Web peut être équivalente au jeu natif ou être volontairement réduite pour jouer immédiatement depuis un lien, partager un challenge et orienter vers l'installation Android.
+
+## Contrats plateforme
+
+Les différences non couvertes proprement par SDL3 passent par des contrats explicites, par exemple :
+
+```text
+PlatformServices
+├── Advertising
+├── Billing
+├── Sharing
+├── Haptics
+├── Leaderboard
+├── CloudSave
+├── Analytics
+└── Notifications
+```
+
+Une génération de moteur ne doit pas obligatoirement imposer une nouvelle génération de bridge Android si ce contrat reste compatible.

docs/architecture/004-INPUT_AND_CONTROLS.md

@@ -0,0 +1,55 @@
+<!-- file: docs/architecture/004-INPUT_AND_CONTROLS.md -->
+<!-- version: 1 -->
+
+# Abstraction des entrées et contrôles
+
+## Règle générale
+
+Le gameplay manipule des actions logiques et non des périphériques physiques. Une action comme `Primary`, `Left` ou `Pause` peut donc provenir d'un clavier, d'une souris, d'un écran tactile ou d'un gamepad sans modifier les règles du jeu.
+
+## Desktop
+
+Entrées possibles :
+
+- clavier : flèches, WASD, espace, touches de fonction ;
+- souris : clic principal/secondaire, position, mouvement relatif, molette ;
+- gamepad et joystick ;
+- trackpad lorsqu'il est présenté comme pointeur ou geste exploitable.
+
+## Android
+
+Schémas de contrôle envisagés :
+
+- boutons virtuels ;
+- tap simple ;
+- swipe horizontal ou vertical ;
+- drag direct ;
+- joystick virtuel ;
+- touch relatif sans joystick visible ;
+- multitouch ;
+- accéléromètre, gyroscope et orientation lorsqu'un jeu le justifie ;
+- vibration/haptique comme retour, derrière un service plateforme.
+
+## Web
+
+Le navigateur peut combiner clavier, souris et tactile. Le mapping doit produire les mêmes actions logiques que les autres plateformes.
+
+## État normalisé
+
+Une représentation de type suivant peut être introduite lorsque nécessaire :
+
+```rust
+pub struct InputState {
+    pub move_x: f32,
+    pub move_y: f32,
+    pub primary: bool,
+    pub secondary: bool,
+    pub pause: bool,
+}
+```
+
+Cette structure n'est pas imposée comme API définitive à la baseline ; elle illustre le contrat recherché.
+
+## Orientation d'écran
+
+Portrait convient particulièrement aux jeux one-button, merge, puzzle, idle, stacking et climber. Paysage convient mieux aux shooters, runners latéraux, survivor-like, tower defense et jeux utilisant deux zones de contrôle.

docs/architecture/005-ASSET_ARCHITECTURE.md

@@ -0,0 +1,49 @@
+<!-- file: docs/architecture/005-ASSET_ARCHITECTURE.md -->
+<!-- version: 1 -->
+
+# Architecture des assets
+
+## Séparation physique
+
+Les assets ne résident jamais dans les crates Rust. La racine `assets/` contient :
+
+```text
+assets/
+├── common/
+├── game-reflex-poc/
+├── game-snake-poc/
+└── <future-game>/
+```
+
+`assets/common/` ne contient que les ressources dont la mutualisation est réelle : fonts, UI générique, sons communs, icônes, particules ou shaders selon les besoins.
+
+Chaque jeu possède son propre répertoire pour textures, audio, données, niveaux et autres ressources spécifiques.
+
+## Espace logique
+
+Le runtime doit éviter les collisions silencieuses. Une résolution logique peut distinguer :
+
+```text
+common://ui/button.png
+game://textures/player.png
+```
+
+ou préserver des préfixes équivalents dans le package final.
+
+## Packaging
+
+Chaque plateforme assemble les deux sources sans créer de copie source durable dans la crate :
+
+```text
+assets/common/
++
+assets/<game>/
+=
+package runtime du jeu
+```
+
+Desktop, Android et Web peuvent utiliser des mécanismes de packaging différents tout en conservant les mêmes noms logiques.
+
+## Évolution
+
+Un AssetManager commun pourra ultérieurement prendre en charge cache, loaders, textures, audio, fonts, données, erreurs, hot-reload de développement et éventuellement bundles. Ces capacités ne doivent être ajoutées qu'au rythme des besoins réels des jeux.