2.7 KiB
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.