0.2.0-0-pre.4
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/studies/000-README.md -->
|
||||
<!-- version: 4 -->
|
||||
<!-- version: 5 -->
|
||||
|
||||
# Études
|
||||
|
||||
@@ -28,3 +28,12 @@ Les études conservent les alternatives et raisons utiles à la compréhension f
|
||||
- [`008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md`](008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md) — identité canonique, providers externes, hébergement global puis sites/services propres à chaque jeu.
|
||||
|
||||
Ces études sont des propositions à relire. Elles ne deviennent pas automatiquement des décisions d'architecture.
|
||||
|
||||
## Études POC plateforme
|
||||
|
||||
- [`009-PLATFORM_POC_CANDIDATES.md`](009-PLATFORM_POC_CANDIDATES.md) — inventaire des POC réellement pertinents à partir du code existant.
|
||||
- [`010-PLATFORM_POC_REUSE_AND_DELTA.md`](010-PLATFORM_POC_REUSE_AND_DELTA.md) — code réutilisable, modifications minimales et frontières à tester.
|
||||
- [`011-PLATFORM_POC_VALIDATION_MATRIX.md`](011-PLATFORM_POC_VALIDATION_MATRIX.md) — critères comparables de build, runtime, input, packaging et intégration plateforme.
|
||||
- [`012-PLATFORM_POC_SEQUENCE.md`](012-PLATFORM_POC_SEQUENCE.md) — ordre proposé des POC pour une future série `0.3.x`.
|
||||
|
||||
Ces documents étudient les POC à réaliser ; ils ne lancent encore aucune implémentation.
|
||||
|
||||
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.
|
||||
97
docs/studies/010-PLATFORM_POC_REUSE_AND_DELTA.md
Normal file
97
docs/studies/010-PLATFORM_POC_REUSE_AND_DELTA.md
Normal file
@@ -0,0 +1,97 @@
|
||||
<!-- file: docs/studies/010-PLATFORM_POC_REUSE_AND_DELTA.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Réutilisation et delta attendu des POC plateforme
|
||||
|
||||
## Statut
|
||||
|
||||
Étude non normative pour `0.2.0-0-pre.4`.
|
||||
|
||||
## Principe
|
||||
|
||||
Un POC plateforme est utile s'il répond à une question avec peu de code neuf.
|
||||
|
||||
S'il nécessite immédiatement une réécriture large du jeu, cela indique soit :
|
||||
|
||||
- une mauvaise frontière actuelle ;
|
||||
- un adapter manquant ;
|
||||
- une capability mal placée ;
|
||||
- un POC trop ambitieux.
|
||||
|
||||
## Éléments à ne pas dupliquer
|
||||
|
||||
### Gameplay
|
||||
|
||||
Les crates `game-*` restent source de vérité des règles.
|
||||
|
||||
### Assets
|
||||
|
||||
Les assets communs et game-specific existants doivent être réutilisés.
|
||||
|
||||
### Logging
|
||||
|
||||
Le POC doit brancher les domaines de tracing existants plutôt que créer un logger spécifique.
|
||||
|
||||
### Runtime provenance
|
||||
|
||||
Chaque nouveau host/backend doit enrichir la provenance existante, pas créer un mécanisme parallèle.
|
||||
|
||||
### Semantic input
|
||||
|
||||
Les nouvelles entrées touch/keyboard/pointer doivent converger vers les actions sémantiques du jeu.
|
||||
|
||||
## Éléments probablement à extraire
|
||||
|
||||
Les POC peuvent révéler des duplications aujourd'hui acceptables dans le POC `0.1.0`.
|
||||
|
||||
Candidats :
|
||||
|
||||
- bridge WASM générique ;
|
||||
- frontend shell commun ;
|
||||
- input adapter Web ;
|
||||
- lifecycle Web/Tauri ;
|
||||
- asset loader Web ;
|
||||
- tracing frontend commun ;
|
||||
- fullscreen/resize ;
|
||||
- mobile lifecycle abstraction ;
|
||||
- packaging/build tooling.
|
||||
|
||||
Aucune extraction n'est imposée avant d'avoir vu la duplication réelle.
|
||||
|
||||
## Reflex comme sonde
|
||||
|
||||
Reflex reste un bon POC de plateforme parce qu'il est petit.
|
||||
|
||||
Il permet d'isoler :
|
||||
|
||||
- pointer/touch ;
|
||||
- timing ;
|
||||
- rendu simple ;
|
||||
- WASM ;
|
||||
- bridge ;
|
||||
- startup.
|
||||
|
||||
## Snake comme seconde sonde
|
||||
|
||||
Snake vérifie que la solution n'est pas façonnée uniquement pour Reflex.
|
||||
|
||||
Il ajoute :
|
||||
|
||||
- keyboard/swipe ;
|
||||
- update continu ;
|
||||
- plusieurs entités ;
|
||||
- état de jeu persistant plus longtemps ;
|
||||
- besoin potentiel de virtual controls.
|
||||
|
||||
## Règle de modification minimale
|
||||
|
||||
Pour chaque POC, documenter :
|
||||
|
||||
1. fichiers/crates réutilisés sans changement ;
|
||||
2. fichiers modifiés ;
|
||||
3. nouveaux adapters ;
|
||||
4. nouveau code strictement platform-specific ;
|
||||
5. duplications provisoires ;
|
||||
6. extractions candidates détectées.
|
||||
|
||||
Cette comparaison servira à décider le découpage final du framework.
|
||||
53
docs/studies/011-PLATFORM_POC_VALIDATION_MATRIX.md
Normal file
53
docs/studies/011-PLATFORM_POC_VALIDATION_MATRIX.md
Normal file
@@ -0,0 +1,53 @@
|
||||
<!-- file: docs/studies/011-PLATFORM_POC_VALIDATION_MATRIX.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Matrice de validation des POC plateforme
|
||||
|
||||
## Statut
|
||||
|
||||
Étude non normative pour `0.2.0-0-pre.4`.
|
||||
|
||||
## Dimensions communes
|
||||
|
||||
Chaque POC doit produire des observations comparables.
|
||||
|
||||
| Dimension | Mesure / validation attendue |
|
||||
|------------------------|-------------------------------------------------------------------|
|
||||
| Build | commande reproductible, dépendances, durée indicative |
|
||||
| Artifact | type, taille, emplacement |
|
||||
| Startup | lancement réussi, erreurs, temps indicatif |
|
||||
| Render | frame visible, resize/orientation |
|
||||
| Input | actions principales, latence perçue, touch/keyboard/pointer |
|
||||
| Lifecycle | pause/resume/background/quit selon host |
|
||||
| Logging | domaines visibles sur le canal plateforme |
|
||||
| Assets | chargement sans chemin hardcodé |
|
||||
| Runtime provenance | dimensions correctes |
|
||||
| Packaging | APK/AAB/app bundle/static web/binary selon cible |
|
||||
| Distribution | contraintes de signature/store identifiées |
|
||||
| Platform integration | faisabilité auth/ads/IAP/notifications sans implémentation finale |
|
||||
| Code reuse | part de gameplay/adapters/front réutilisée |
|
||||
| Duplication | duplication nouvelle explicitement recensée |
|
||||
| Maintenance | complexité qualitative et outils nécessaires |
|
||||
|
||||
## Critères de réussite
|
||||
|
||||
Un POC n'est pas jugé uniquement sur « ça démarre ».
|
||||
|
||||
Il doit permettre de conclure :
|
||||
|
||||
- quel code est réutilisé ;
|
||||
- quel adapter est nécessaire ;
|
||||
- quelles dépendances sont spécifiques ;
|
||||
- quelles limitations sont structurelles ;
|
||||
- quelle stratégie mérite d'être conservée.
|
||||
|
||||
## Critères d'arrêt
|
||||
|
||||
Un POC peut être arrêté si :
|
||||
|
||||
- la plateforme n'est pas accessible dans l'environnement disponible ;
|
||||
- le coût de setup dépasse l'information recherchée ;
|
||||
- une contrainte externe rend le résultat non représentatif ;
|
||||
- un POC précédent répond déjà à la question.
|
||||
|
||||
Un arrêt documenté n'est pas un échec de version.
|
||||
70
docs/studies/012-PLATFORM_POC_SEQUENCE.md
Normal file
70
docs/studies/012-PLATFORM_POC_SEQUENCE.md
Normal file
@@ -0,0 +1,70 @@
|
||||
<!-- file: docs/studies/012-PLATFORM_POC_SEQUENCE.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Séquence proposée des POC plateforme
|
||||
|
||||
## Statut
|
||||
|
||||
Étude non normative pour `0.2.0-0-pre.4`.
|
||||
|
||||
## Principe
|
||||
|
||||
La future série `0.3.x` pourra être dédiée aux POC plateforme, mais la numérotation exacte n'est pas encore figée.
|
||||
|
||||
## Vague 1 — réalisable avec la base actuelle
|
||||
|
||||
Ordre candidat :
|
||||
|
||||
1. Tauri Android + Reflex ;
|
||||
2. Web navigateur direct + Reflex ;
|
||||
3. Tauri Desktop + Snake ;
|
||||
4. builder Android multi-ABI.
|
||||
|
||||
Raisons :
|
||||
|
||||
- réutilisation maximale ;
|
||||
- environnement déjà proche de celui utilisé ;
|
||||
- comparaison directe SDL / Web / Tauri ;
|
||||
- détection rapide des abstractions manquantes.
|
||||
|
||||
## Vague 2 — plateformes natives supplémentaires
|
||||
|
||||
Lorsque les environnements sont disponibles :
|
||||
|
||||
1. Windows SDL natif ;
|
||||
2. macOS SDL natif ;
|
||||
3. iOS SDL natif.
|
||||
|
||||
Ces POC servent surtout à valider la portabilité du backend SDL et du packaging.
|
||||
|
||||
## Vague 3 — variantes mobiles alternatives
|
||||
|
||||
Après résultat du POC Tauri Android :
|
||||
|
||||
- Tauri iOS si pertinent ;
|
||||
- comparaison iOS SDL/Tauri si un produit Apple devient réellement prévu.
|
||||
|
||||
## Ce que la 0.2.0 doit produire
|
||||
|
||||
La `0.2.0` ne doit pas implémenter ces POC.
|
||||
|
||||
Elle doit produire :
|
||||
|
||||
- la liste retenue ;
|
||||
- les questions auxquelles chaque POC répond ;
|
||||
- les critères de validation ;
|
||||
- l'ordre recommandé ;
|
||||
- le prompt de la future session `0.3.x`.
|
||||
|
||||
## Transition vers le prochain jeu
|
||||
|
||||
Après la définition des POC, la fin de `0.2.0` doit étudier le prochain jeu réel.
|
||||
|
||||
Ce jeu servira à :
|
||||
|
||||
- prioriser les capabilities ;
|
||||
- découvrir les capacités oubliées ;
|
||||
- reclasser certains concepts ;
|
||||
- distinguer ce qui doit être implémenté avant le jeu de ce qui peut être développé avec lui.
|
||||
|
||||
La série `0.4.x` est candidate pour porter ce prochain jeu réel et les capabilities prioritaires qu'il exige.
|
||||
Reference in New Issue
Block a user