games/docs/studies/009-PLATFORM_POC_CANDIDATES.md

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 :

SDL native
Web/WASM
Tauri/WebView

sur plusieurs hosts sans modifier le gameplay.