games/docs/studies/009-PLATFORM_POC_CANDIDATES.md

<!-- 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.