162 lines
4.8 KiB
Markdown
162 lines
4.8 KiB
Markdown
<!-- file: docs/studies/003-PLATFORM_CAPABILITY_STUDY.md -->
|
|
<!-- version: 3 -->
|
|
|
|
# É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 ?
|