0.2.0-0-pre.4
This commit is contained in:
@@ -1,5 +1,5 @@
|
|||||||
// file: Android/game-reflex-poc/build.gradle
|
// file: Android/game-reflex-poc/build.gradle
|
||||||
// version: 33
|
// version: 34
|
||||||
|
|
||||||
plugins {
|
plugins {
|
||||||
id 'com.android.application'
|
id 'com.android.application'
|
||||||
@@ -18,7 +18,7 @@ android {
|
|||||||
minSdk 21
|
minSdk 21
|
||||||
targetSdk 36
|
targetSdk 36
|
||||||
versionCode 2
|
versionCode 2
|
||||||
versionName '0.2.0-0-pre.3.fix.1'
|
versionName '0.2.0-0-pre.4'
|
||||||
}
|
}
|
||||||
|
|
||||||
compileOptions {
|
compileOptions {
|
||||||
|
|||||||
@@ -1,5 +1,5 @@
|
|||||||
// file: Android/game-snake-poc/build.gradle
|
// file: Android/game-snake-poc/build.gradle
|
||||||
// version: 33
|
// version: 34
|
||||||
|
|
||||||
plugins {
|
plugins {
|
||||||
id 'com.android.application'
|
id 'com.android.application'
|
||||||
@@ -18,7 +18,7 @@ android {
|
|||||||
minSdk 21
|
minSdk 21
|
||||||
targetSdk 36
|
targetSdk 36
|
||||||
versionCode 2
|
versionCode 2
|
||||||
versionName '0.2.0-0-pre.3.fix.1'
|
versionName '0.2.0-0-pre.4'
|
||||||
}
|
}
|
||||||
|
|
||||||
compileOptions {
|
compileOptions {
|
||||||
|
|||||||
@@ -1,5 +1,5 @@
|
|||||||
# file: Cargo.toml
|
# file: Cargo.toml
|
||||||
# version: 45
|
# version: 46
|
||||||
|
|
||||||
[workspace]
|
[workspace]
|
||||||
resolver = "3"
|
resolver = "3"
|
||||||
@@ -19,7 +19,7 @@ members = [
|
|||||||
]
|
]
|
||||||
|
|
||||||
[workspace.package]
|
[workspace.package]
|
||||||
version = "0.2.0-0-pre.3.fix.1"
|
version = "0.2.0-0-pre.4"
|
||||||
edition = "2024"
|
edition = "2024"
|
||||||
license = "MIT"
|
license = "MIT"
|
||||||
repository = "https://git.sasedev.com/Sasedev/games"
|
repository = "https://git.sasedev.com/Sasedev/games"
|
||||||
|
|||||||
@@ -1,5 +1,5 @@
|
|||||||
<!-- file: README.md -->
|
<!-- file: README.md -->
|
||||||
<!-- version: 13 -->
|
<!-- version: 14 -->
|
||||||
|
|
||||||
# games.sasedev
|
# games.sasedev
|
||||||
|
|
||||||
@@ -25,7 +25,7 @@ Workspace expérimental puis productif pour des jeux multiplateformes principale
|
|||||||
|
|
||||||
Version stable de référence : `0.1.0`.
|
Version stable de référence : `0.1.0`.
|
||||||
|
|
||||||
Version candidate en cours de conception : `0.2.0-0-pre.3.fix.1`.
|
Version candidate en cours de conception : `0.2.0-0-pre.4`.
|
||||||
|
|
||||||
Les deux premiers jeux sont des POC structurels : `game-reflex-poc` et `game-snake-poc`. Ils existent d'abord pour valider les frontières du workspace, le moteur, les assets et le packaging multiplateforme.
|
Les deux premiers jeux sont des POC structurels : `game-reflex-poc` et `game-snake-poc`. Ils existent d'abord pour valider les frontières du workspace, le moteur, les assets et le packaging multiplateforme.
|
||||||
|
|
||||||
|
|||||||
55
deltas/0.2.0/0-pre.4.md
Normal file
55
deltas/0.2.0/0-pre.4.md
Normal file
@@ -0,0 +1,55 @@
|
|||||||
|
<!-- file: deltas/0.2.0/0-pre.4.md -->
|
||||||
|
<!-- version: 1 -->
|
||||||
|
|
||||||
|
# Delta 0.2.0-0-pre.4
|
||||||
|
|
||||||
|
## Base
|
||||||
|
|
||||||
|
Base déclarée : `0.2.0-0-pre.3.fix.1`.
|
||||||
|
|
||||||
|
## Objet
|
||||||
|
|
||||||
|
Définir les POC plateforme utiles avant toute implémentation de la série suivante.
|
||||||
|
|
||||||
|
## Études ajoutées
|
||||||
|
|
||||||
|
- candidats POC plateforme ;
|
||||||
|
- réutilisation du code existant ;
|
||||||
|
- matrice commune de validation ;
|
||||||
|
- séquence proposée pour une future série `0.3.x`.
|
||||||
|
|
||||||
|
## POC prioritaires étudiés
|
||||||
|
|
||||||
|
Première vague candidate :
|
||||||
|
|
||||||
|
- Tauri Android + Reflex ;
|
||||||
|
- Web navigateur direct + Reflex ;
|
||||||
|
- Tauri Desktop + Snake ;
|
||||||
|
- builder Android multi-ABI.
|
||||||
|
|
||||||
|
Deuxième vague lorsque l'environnement existe :
|
||||||
|
|
||||||
|
- Windows SDL natif ;
|
||||||
|
- macOS SDL natif ;
|
||||||
|
- iOS SDL natif.
|
||||||
|
|
||||||
|
Tauri iOS reste conditionnel aux résultats Tauri Android et à l'existence d'un besoin Apple réel.
|
||||||
|
|
||||||
|
## Principes
|
||||||
|
|
||||||
|
- réutiliser le gameplay existant ;
|
||||||
|
- minimiser le code spécifique ;
|
||||||
|
- mesurer la duplication ;
|
||||||
|
- ne pas extraire prématurément une abstraction avant d'avoir observé au moins un besoin réel ;
|
||||||
|
- comparer SDL natif, Web/WASM et Tauri/WebView ;
|
||||||
|
- ne pas implémenter les POC dans `0.2.0`.
|
||||||
|
|
||||||
|
## Validation
|
||||||
|
|
||||||
|
```bash
|
||||||
|
python3 scripts/audit_rust_workspace_rules.py
|
||||||
|
python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates Android deltas history
|
||||||
|
python3 scripts/audit_distribution_layout.py
|
||||||
|
```
|
||||||
|
|
||||||
|
Aucune gate Cargo/Gradle/smoke n'est requise pour ce delta documentaire.
|
||||||
@@ -1,5 +1,5 @@
|
|||||||
<!-- file: docs/studies/000-README.md -->
|
<!-- file: docs/studies/000-README.md -->
|
||||||
<!-- version: 4 -->
|
<!-- version: 5 -->
|
||||||
|
|
||||||
# Études
|
# É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.
|
- [`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.
|
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.
|
||||||
21
history/0.2.0/0-pre.3.fix.1.md
Normal file
21
history/0.2.0/0-pre.3.fix.1.md
Normal file
@@ -0,0 +1,21 @@
|
|||||||
|
<!-- file: history/0.2.0/0-pre.3.fix.1.md -->
|
||||||
|
<!-- version: 1 -->
|
||||||
|
|
||||||
|
# Historique 0.2.0-0-pre.3.fix.1
|
||||||
|
|
||||||
|
## Statut
|
||||||
|
|
||||||
|
Complément d'étude validé avant ouverture de `0.2.0-0-pre.4`.
|
||||||
|
|
||||||
|
## Contenu accepté
|
||||||
|
|
||||||
|
- étude des bots/pseudo-IA locale ou serveur ;
|
||||||
|
- distinction bot déterministe, recherche et modèles entraînés éventuels ;
|
||||||
|
- identité Web canonique et providers liés ;
|
||||||
|
- account linking ;
|
||||||
|
- portail `games.sasedev.com` ;
|
||||||
|
- évolution possible vers des domaines et sous-services propres aux jeux.
|
||||||
|
|
||||||
|
## Suite
|
||||||
|
|
||||||
|
`0-pre.4` étudie les POC plateforme à réaliser ultérieurement en maximisant la réutilisation du code `0.1.0`.
|
||||||
Reference in New Issue
Block a user