<!-- file: docs/studies/003-PLATFORM_CAPABILITY_STUDY.md -->
<!-- version: 4 -->

# É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.

Pour le multijoueur temps réel, le support d'un WebSocket côté plateforme ne suffit pas à définir la synchronisation. Le client doit pouvoir se connecter à une session distante qui possède ses propres contrats de tick, sequencing, snapshots/deltas, reconnexion et resynchronisation.

Les contraintes navigateur/mobile/desktop peuvent modifier :

- la durée de vie d'une connexion ;
- la suspension en arrière-plan ;
- les timeouts ;
- les politiques de reconnexion ;
- la disponibilité de threads/timers ;
- les stratégies de buffering.

Ces différences appartiennent aux adapters/runtime et ne doivent pas modifier le protocole de gameplay lui-même.

## 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 ?