games/docs/studies/003-PLATFORM_CAPABILITY_STUDY.md

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