56 lines
3.5 KiB
Markdown
56 lines
3.5 KiB
Markdown
<!-- file: docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md -->
|
||
<!-- version: 4 -->
|
||
|
||
# Architecture des POC plateforme et réseau
|
||
|
||
## Rôle de la série 0.3.x
|
||
|
||
La série `0.3.x` doit éprouver les frontières décidées en `0.2.0` avant le développement Uroburas réel.
|
||
|
||
Snake est le jeu-sonde principal.
|
||
|
||
## POC plateforme prioritaires
|
||
|
||
Première vague, réordonnée à partir du résultat réel de `0.3.0` :
|
||
|
||
- Web navigateur direct + Snake — validé par `0.3.0` ;
|
||
- Tauri Android + Snake — POC de référence terminé par `0.3.1`, conservé pour comparaison mais non retenu comme voie de production Android par défaut ;
|
||
- Tauri Desktop + Snake — différé tant qu’un bénéfice produit explicite n’est pas démontré, en particulier une voie de monétisation publicitaire/reward vidéo compatible avec une WebView desktop distribuée ;
|
||
- build Android multi-ABI avec outils natifs — tranche dédiée après les POC WebView.
|
||
|
||
Plateformes supplémentaires lorsque l'environnement existe : Windows SDL natif, macOS SDL natif et iOS SDL natif.
|
||
|
||
## Positionnement Tauri Android après `0.3.1`
|
||
|
||
Le host Tauri Android reste pertinent comme preuve de portabilité du gameplay Rust/WASM et comme banc d’essai WebView. Il n’est pas retenu comme distribution Android de jeu par défaut.
|
||
|
||
La baseline Android productive reste SDL3 natif avec wrapper Java/JNI : elle fournit déjà le rendu et les contrôles nécessaires avec moins de couches d’outillage. Tauri Android ne doit être rouvert pour un produit que lorsqu’un besoin concret apporte une valeur supérieure à ce coût, par exemple si les tests futurs démontrent un avantage net de la WebView pour une saisie texte ou une capacité UI difficile à obtenir proprement via SDL.
|
||
|
||
Cette décision n’interdit pas Tauri Desktop. Le Desktop reste une distribution distincte et optionnelle ; sa valeur doit être démontrée séparément. À la clôture du POC Android, aucune solution de publicité ou reward vidéo dans une WebView Tauri Desktop n’est considérée comme validée. Une approche exigeant une URL Web publique, un chargement distant du jeu ou un SDK tiers spécifique doit faire l’objet d’un POC et d’une vérification contractuelle avant de rouvrir cette cible.
|
||
|
||
## POC réseau
|
||
|
||
Avant le Mode 3, comparer au minimum WebSocket/tokio-tungstenite, WebTransport/QUIC, fallback automatique, charge, reconnect/resync, backpressure, snapshots/deltas et mobilité réseau.
|
||
|
||
Le même protocole métier doit pouvoir être exercé sur plusieurs transports.
|
||
|
||
## Build
|
||
|
||
Les builds utilisent Cargo, Gradle, Tauri CLI et les toolchains plateforme.
|
||
|
||
Python reste limité aux audits, validations complémentaires et contrôles statiques.
|
||
|
||
## Critère d'extraction
|
||
|
||
Un POC sert à identifier duplication, adapters manquants, capability réellement réutilisable, frontières mal placées et coût de maintenance.
|
||
|
||
Une abstraction n'est pas extraite avant observation d'un besoin concret.
|
||
|
||
Le POC Web direct `0.3.0` n'a pas justifié d'extraire prématurément un adapter WASM commun entre Reflex et Snake : les deux adapters spécifiques restent acceptés. Le second host Snake fournit un second consommateur technique, mais son statut de POC Tauri Android de référence réduit encore l'intérêt d'une factorisation durable : une extraction n'est retenue que si elle reste utile à au moins deux hosts réellement conservés.
|
||
|
||
## Relation avec Uroburas
|
||
|
||
Les résultats des POC `0.3.x` déterminent les choix techniques conservés pour la trajectoire Uroburas `0.4.x`.
|
||
|
||
Le POC ne doit pas réimplémenter le futur jeu ; il valide ses fondations.
|