0.2.0-0-pre.4
This commit is contained in:
231
docs/studies/009-PLATFORM_POC_CANDIDATES.md
Normal file
231
docs/studies/009-PLATFORM_POC_CANDIDATES.md
Normal file
@@ -0,0 +1,231 @@
|
||||
<!-- file: docs/studies/009-PLATFORM_POC_CANDIDATES.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Candidats POC plateforme
|
||||
|
||||
## Statut
|
||||
|
||||
Étude non normative pour `0.2.0-0-pre.4`.
|
||||
|
||||
## Objectif
|
||||
|
||||
Identifier les POC plateforme qui apportent une information architecturale réelle en réutilisant au maximum le code déjà validé en `0.1.0`.
|
||||
|
||||
Le but n'est pas de multiplier les variantes pour leur propre intérêt.
|
||||
|
||||
## Baseline déjà disponible
|
||||
|
||||
Le projet dispose déjà de :
|
||||
|
||||
- Reflex Rust réutilisable ;
|
||||
- Snake Rust réutilisable ;
|
||||
- runner SDL3 Desktop ;
|
||||
- Android SDL3 + Java/JNI ;
|
||||
- Tauri Desktop + Vite/TypeScript + WASM pour Reflex ;
|
||||
- provenance runtime ;
|
||||
- tracing commun ;
|
||||
- abstraction initiale d'input ;
|
||||
- politique de build externe ;
|
||||
- validation Android x86_64 et ARM64.
|
||||
|
||||
Les POC futurs doivent partir de cette base.
|
||||
|
||||
## POC A — Tauri Android avec Reflex
|
||||
|
||||
### Question
|
||||
|
||||
Le chemin Tauri Android peut-il exécuter le même gameplay Reflex déjà utilisé par Tauri Desktop/WASM avec une intégration mobile acceptable ?
|
||||
|
||||
### Réutilisation visée
|
||||
|
||||
- `game-reflex-poc` ;
|
||||
- `game-reflex-poc-wasm` si le modèle reste Wasm/WebView ;
|
||||
- frontend Vite/TypeScript existant ;
|
||||
- tracing frontend/Tauri ;
|
||||
- assets existants ;
|
||||
- provenance runtime étendue.
|
||||
|
||||
### Modifications attendues
|
||||
|
||||
- génération/projet mobile Tauri ;
|
||||
- input tactile ;
|
||||
- lifecycle Android ;
|
||||
- orientation/fullscreen ;
|
||||
- packaging APK/AAB ;
|
||||
- ABI ;
|
||||
- logging Android/Tauri ;
|
||||
- éventuels plugins mobiles.
|
||||
|
||||
### Ce que le POC doit apprendre
|
||||
|
||||
- complexité réelle du build ;
|
||||
- taille binaire/package ;
|
||||
- startup ;
|
||||
- latence input ;
|
||||
- stabilité lifecycle ;
|
||||
- accès aux APIs/plugins natifs ;
|
||||
- faisabilité ads/auth plus tard ;
|
||||
- coût de maintenance par rapport au chemin SDL Android.
|
||||
|
||||
## POC B — Web navigateur direct avec Reflex
|
||||
|
||||
### Question
|
||||
|
||||
Le même gameplay WASM peut-il être livré comme jeu Web direct, sans Tauri, avec un packaging propre et un input navigateur fiable ?
|
||||
|
||||
### Réutilisation visée
|
||||
|
||||
- `game-reflex-poc` ;
|
||||
- crate WASM existante ;
|
||||
- Vite/TypeScript partagé autant que pertinent ;
|
||||
- assets communs.
|
||||
|
||||
### Points à tester
|
||||
|
||||
- browser host ;
|
||||
- resize ;
|
||||
- pointer/touch ;
|
||||
- fullscreen ;
|
||||
- focus/visibility ;
|
||||
- persistence navigateur minimale ;
|
||||
- build statique ;
|
||||
- chargement assets ;
|
||||
- tracing console ;
|
||||
- hébergement sous un chemin non racine.
|
||||
|
||||
## POC C — Tauri Desktop avec Snake
|
||||
|
||||
### Question
|
||||
|
||||
La voie Tauri/WASM validée avec Reflex est-elle réellement générique ou trop spécifique au premier POC ?
|
||||
|
||||
### Pourquoi Snake
|
||||
|
||||
Snake exerce :
|
||||
|
||||
- keyboard input continu ;
|
||||
- cadence update différente ;
|
||||
- état plus long ;
|
||||
- rendu d'entités multiples ;
|
||||
- logique de quit/pause différente.
|
||||
|
||||
### Réutilisation visée
|
||||
|
||||
Créer le minimum nécessaire pour que Snake utilise les mêmes contrats Tauri/WASM que Reflex.
|
||||
|
||||
Si cela exige de copier beaucoup de code frontend/bridge, cela signale une capability ou un adapter à extraire.
|
||||
|
||||
## POC D — Windows SDL natif
|
||||
|
||||
### Question
|
||||
|
||||
Le runner SDL3 natif et le workspace Rust se construisent-ils proprement sur Windows avec une divergence minimale ?
|
||||
|
||||
### Périmètre
|
||||
|
||||
Reflex ou Snake, selon la cible la plus simple.
|
||||
|
||||
### À tester
|
||||
|
||||
- toolchain Rust MSVC ;
|
||||
- SDL3 ;
|
||||
- assets ;
|
||||
- input ;
|
||||
- audio si disponible ;
|
||||
- packaging minimal ;
|
||||
- logs ;
|
||||
- chemins/filesystem.
|
||||
|
||||
Ce POC nécessite une machine ou CI Windows réelle ; le cross-build Linux ne remplace pas un smoke Windows.
|
||||
|
||||
## POC E — macOS SDL natif
|
||||
|
||||
### Question
|
||||
|
||||
Le backend SDL natif actuel peut-il devenir une cible macOS sans modification du gameplay ?
|
||||
|
||||
SDL3 documente macOS comme plateforme supportée.
|
||||
|
||||
### À tester ultérieurement
|
||||
|
||||
- build x86_64/arm64 selon environnement ;
|
||||
- SDL3 framework/dylib ;
|
||||
- app bundle ;
|
||||
- input ;
|
||||
- filesystem ;
|
||||
- signing/notarization seulement dans une phase de distribution ultérieure.
|
||||
|
||||
Nécessite un environnement macOS réel pour être validé.
|
||||
|
||||
## POC F — iOS SDL natif
|
||||
|
||||
### Question
|
||||
|
||||
Le modèle Android/SDL peut-il être adapté à iOS tout en conservant le même gameplay ?
|
||||
|
||||
SDL3 documente iOS et son usage via `SDL3.xcframework`.
|
||||
|
||||
### Périmètre futur
|
||||
|
||||
- build iOS ;
|
||||
- simulator/device ;
|
||||
- lifecycle ;
|
||||
- touch ;
|
||||
- app storage ;
|
||||
- packaging Xcode.
|
||||
|
||||
Ce POC est réservé à une phase disposant de macOS/Xcode et ne doit pas bloquer les POC immédiatement réalisables sous Linux/Android.
|
||||
|
||||
## POC G — Tauri iOS
|
||||
|
||||
Candidat plus lointain.
|
||||
|
||||
Il n'est utile qu'après :
|
||||
|
||||
- validation du POC Tauri Android ;
|
||||
- disponibilité d'un environnement Apple ;
|
||||
- intérêt réel pour comparer deux chemins mobiles Apple.
|
||||
|
||||
Il ne doit pas être planifié par défaut dans la première vague.
|
||||
|
||||
## POC H — builder Android multi-ABI
|
||||
|
||||
### Question
|
||||
|
||||
Peut-on remplacer les scripts Python POC par un outil de build explicite, reproductible et commun aux jeux ?
|
||||
|
||||
### Périmètre
|
||||
|
||||
- `arm64-v8a` ;
|
||||
- `x86_64` ;
|
||||
- éventuellement autres ABI seulement si réellement supportées ;
|
||||
- Debug/Release ;
|
||||
- Reflex/Snake ;
|
||||
- placement contrôlé des artefacts ;
|
||||
- Gradle orchestration ;
|
||||
- diagnostic clair des prérequis.
|
||||
|
||||
Ce POC est plutôt un POC tooling qu'un POC runtime.
|
||||
|
||||
## Candidats non prioritaires
|
||||
|
||||
Ne pas lancer immédiatement :
|
||||
|
||||
- Tauri iOS ;
|
||||
- macOS Tauri spécifique si Tauri Desktop actuel suffit déjà à tester le host ;
|
||||
- Linux SDL supplémentaire, déjà baseline ;
|
||||
- nouvelle technologie de rendu ;
|
||||
- nouveau moteur Web ;
|
||||
- nouvelles plateformes console.
|
||||
|
||||
## Résultat attendu
|
||||
|
||||
La première vague doit surtout comparer trois chemins :
|
||||
|
||||
```text
|
||||
SDL native
|
||||
Web/WASM
|
||||
Tauri/WebView
|
||||
```
|
||||
|
||||
sur plusieurs hosts sans modifier le gameplay.
|
||||
Reference in New Issue
Block a user