0.2.0-0-pre.2

docs/studies/003-PLATFORM_CAPABILITY_STUDY.md

@@ -0,0 +1,148 @@
+<!-- file: docs/studies/003-PLATFORM_CAPABILITY_STUDY.md -->
+<!-- version: 1 -->
+
+# Étude plateforme et disponibilité des capacités
+
+## Statut
+
+Étude non normative pour `0.2.0-0-pre.2`.
+
+## Axes indépendants
+
+Une cible produit ne doit pas être décrite par un seul enum « platform ».
+
+Axes candidats :
+
+### OS / environnement
+
+- Linux ;
+- Windows ;
+- macOS ;
+- Android ;
+- iOS ;
+- Browser/Web.
+
+### Device class
+
+- Desktop ;
+- Phone ;
+- Tablet ;
+- Unknown.
+
+D'autres classes ne sont ajoutées qu'avec un besoin réel.
+
+### Execution model
+
+- Native ;
+- Wasm.
+
+### Runtime host
+
+- Native ;
+- Browser ;
+- TauriWebView.
+
+### Backend
+
+Exemples actuels :
+
+- SDL3 ;
+- Web APIs via WASM ;
+- Tauri host + frontend Web/WASM.
+
+Le backend n'est pas l'identité du jeu.
+
+## Cibles connues
+
+| Cible | OS/environnement | Device | Execution | Host | Backend principal |
+| --- | --- | --- | --- | --- | --- |
+| Desktop SDL Linux | Linux | Desktop | Native | Native | SDL3 |
+| Desktop SDL Windows | Windows | Desktop | Native | Native | SDL3 |
+| Desktop SDL macOS | macOS | Desktop | Native | Native | SDL3, réservé |
+| Android SDL | Android | Phone/Tablet | Native | Native | SDL3 + Java/JNI |
+| iOS natif | iOS | Phone/Tablet | Native | Native | réservé |
+| Web | Browser | Desktop/Phone/Tablet | Wasm | Browser | Web/WASM |
+| Tauri Desktop | Linux/Windows/macOS | Desktop | Wasm côté jeu POC | TauriWebView | Tauri + Web/WASM |
+| Tauri Android | Android | Phone/Tablet | à étudier | TauriWebView | expérimental futur |
+
+## Capacités et variabilité
+
+### Input
+
+Desktop :
+
+- clavier ;
+- souris ;
+- gamepad éventuel.
+
+Mobile :
+
+- tactile ;
+- gestes ;
+- contrôles virtuels ;
+- gamepad éventuel.
+
+Web :
+
+- clavier/pointer/touch selon device ;
+- browser restrictions.
+
+Le mapping physique appartient à l'adapter/profil, pas au jeu.
+
+### Storage
+
+Native :
+
+- filesystem/app storage possible selon OS.
+
+Web :
+
+- stockage navigateur et quotas spécifiques.
+
+Le jeu doit consommer un contrat logique et non un chemin OS.
+
+### Ads et IAP
+
+Disponibilité dépendante du produit, de la plateforme et du provider.
+
+Un produit Desktop ou Web peut volontairement déclarer Ads `unsupported` ou `disabled` même si le framework possède une capability Ads.
+
+### Identity plateforme
+
+Play Games, Apple/Game Center ou services similaires sont des providers de plateforme. Aucun n'est requis pour définir un `PlayerId` canonique.
+
+### Networking
+
+HTTP/WebSocket sont plausibles sur toutes les grandes cibles mais leur implémentation et restrictions diffèrent.
+
+Le protocole métier reste indépendant du transport.
+
+## Politique de disponibilité candidate
+
+Une capability produit peut être :
+
+- `required` ;
+- `optional` ;
+- `disabled` ;
+- `unsupported` ;
+- `server-required`.
+
+Cette liste devra être challengée lors de l'étude du manifest produit.
+
+## SDL comme point d'entrée natif
+
+SDL3 est le backend natif de référence actuel parce qu'il permet de réutiliser une grande partie du runtime entre Desktop et Android et réserve une trajectoire macOS/iOS.
+
+Cette décision ne doit pas devenir :
+
+> tous les produits doivent obligatoirement utiliser SDL.
+
+Le POC Tauri Android servira précisément à comparer un second chemin de packaging/host sans modifier les règles de gameplay.
+
+## Questions ouvertes
+
+- support iOS : SDL natif seul, Tauri mobile, ou coexistence ?
+- rendu Web : abstraction SDL-like ou renderer Web dédié ?
+- gamepad mobile/web : capability immédiate ou réservation ?
+- filesystem et save-game : API unique avec garanties minimales ou contrats spécialisés ?
+- quelles capabilities doivent être détectables au runtime et lesquelles doivent être décidées au build ?