119 lines
2.7 KiB
Markdown
119 lines
2.7 KiB
Markdown
<!-- file: docs/studies/022-UROBURAS_IMPLEMENTATION_DEPENDENCY_ORDER.md -->
|
|
<!-- version: 2 -->
|
|
|
|
# Uroburas — ordre d'implémentation par dépendances
|
|
|
|
## Statut
|
|
|
|
Étude non normative pour `0.2.0-0-pre.6`.
|
|
|
|
## Principe
|
|
|
|
Construire d'abord les mécanismes nécessaires au Mode 1, en conservant les frontières permettant d'ajouter Mode 3 puis Mode 2.
|
|
|
|
## Phase A — fondations réutilisables
|
|
|
|
À stabiliser avant le jeu final :
|
|
|
|
- input semantic actions ;
|
|
- boutons virtuels tactiles ;
|
|
- render sprite/rotation/caméra ;
|
|
- grid/tilemap toroïdale ;
|
|
- collision obstacles ;
|
|
- assets/content manifest ;
|
|
- téléchargement/cache ;
|
|
- localization Fluent ;
|
|
- persistence settings/cache.
|
|
|
|
## Phase B — systèmes nécessaires au Challenge
|
|
|
|
- stages ;
|
|
- vies ;
|
|
- score ;
|
|
- timers ;
|
|
- pickups/items simples ;
|
|
- spawn/respawn ;
|
|
- caméra map large ;
|
|
- transitions de stages.
|
|
|
|
## Phase C — Uroburas Challenge
|
|
|
|
- anatomie Snake ;
|
|
- mouvement ;
|
|
- corps extensible ;
|
|
- longueur minimale ;
|
|
- sprites/virages ;
|
|
- règles de maps ;
|
|
- progression de run ;
|
|
- Hall of Fame local submission model.
|
|
|
|
## Phase D — services Web V1
|
|
|
|
- Actix Web ;
|
|
- Maud ;
|
|
- auth ;
|
|
- PlayerId ;
|
|
- Fluent serveur ;
|
|
- Lettre ;
|
|
- maps/assets metadata ;
|
|
- asset delivery auto-hébergé ;
|
|
- HTTP/2 baseline et HTTP/3 si disponible côté asset delivery ;
|
|
- Hall of Fame ;
|
|
- rewarded ad authority ;
|
|
- protocole HTTP sécurisé/versionné.
|
|
|
|
## Phase E — intégration client/server Mode 1
|
|
|
|
- login/session ;
|
|
- téléchargement contenu ;
|
|
- score submission ;
|
|
- rewarded continue ;
|
|
- rewarded score multiplier ;
|
|
- validation/retry/idempotence ;
|
|
- offline degradation.
|
|
|
|
## Phase F — Mode 3
|
|
|
|
Une fois les moteurs Mode 1 stables :
|
|
|
|
- server realtime ;
|
|
- realtime transport API ;
|
|
- tokio-tungstenite baseline ;
|
|
- WebTransport/QUIC candidat après POC ;
|
|
- fallback transport ;
|
|
- authoritative simulation ;
|
|
- world persistence lifecycle ;
|
|
- bots ;
|
|
- spectator ;
|
|
- snapshots/deltas ;
|
|
- interest management ;
|
|
- rejoin cooldown ;
|
|
- future combat/items.
|
|
|
|
## Phase G — Mode 2
|
|
|
|
Après réutilisation des briques realtime du Mode 3 :
|
|
|
|
- lobby/matchmaking ;
|
|
- private matches ;
|
|
- map selection ;
|
|
- teams ;
|
|
- bounded matches ;
|
|
- lives/match rules ;
|
|
- spectator policy ;
|
|
- bots optionnels.
|
|
|
|
## Tooling en parallèle
|
|
|
|
L'éditeur de maps peut commencer lorsqu'un format de map suffisamment stable existe.
|
|
|
|
L'éditeur de skins vient après stabilisation du contrat de skin.
|
|
|
|
Ni l'un ni l'autre ne doit bloquer le premier gameplay Challenge minimal.
|
|
|
|
## POC transport avant Mode 3
|
|
|
|
Avant de figer le transport realtime du Mode 3, un POC dédié doit comparer WebSocket et WebTransport avec la même couche protocolaire.
|
|
|
|
Le POC mesure la charge et la robustesse ; il ne doit pas forcer la simulation Uroburas à dépendre d'une implémentation réseau particulière.
|