games/docs/studies/019-UROBURAS_FUNCTIONAL_OWNERSHIP_CLASSIFICATION.md

Uroburas — classification fonctionnelle par ownership

Statut

Étude non normative pour 0.2.0-0-pre.6.

Objectif : éviter que les futures crates Uroburas multiplateformes deviennent des monolithes contenant des responsabilités réutilisables, serveur, plateforme ou tooling.

Principe

Une fonctionnalité appartient à la couche la plus basse qui puisse la fournir sans connaître Uroburas.

La crate jeu conserve uniquement :

• règles propres à Uroburas ;
• composition des game-systems ;
• contenu/rulesets Uroburas ;
• coordination propre aux modes.

Engine kernel

Responsabilités minimales :

• lifecycle générique ;
• boucle update/render ;
• temps monotone ;
• fixed-step/scheduling si retenu ;
• runtime events ;
• provenance runtime ;
• contrats minimaux input/render ;
• quit/pause génériques.

Le kernel ne connaît pas :

• Snake ;
• stages ;
• vies ;
• Hall of Fame ;
• publicité ;
• auth ;
• maps Uroburas ;
• WebSocket ;
• Actix.

Technical capabilities

Input

• semantic actions ;
• keyboard ;
• virtual buttons tactiles ;
• gamepad éventuel ;
• mapping/configuration ;
• focus/lifecycle input.

Rendering 2D

• sprites/textures ;
• rotation ;
• viewport ;
• caméra 2D ;
• layers/z-order ;
• animation sprite simple ;
• debug primitives.

Audio

• musique ;
• SFX ;
• volume/mute ;
• lifecycle audio.

Assets/content

• asset identifiers ;
• package manifest ;
• téléchargement ;
• cache ;
• version/intégrité ;
• invalidation ;
• résolution de chemins logiques.

Localization

• locales ;
• Fluent resources ;
• fallback ;
• message arguments ;
• bundles client ;
• ressources localisées téléchargées.

Persistence locale

• settings ;
• cache ;
• progression locale éventuelle ;
• données de session offline.

Networking client

• HTTP(S) client ;
• realtime transport API ;
• WebSocket baseline ;
• WebTransport/QUIC candidate ;
• transport capability negotiation ;
• fallback transport ;
• reconnect ;
• timeout/backoff ;
• protocole versionné ;
• session/auth tokens ;
• validation des messages ;
• séparation transport/protocole.

La logique de jeu ne dépend pas directement de tokio-tungstenite, Quinn, WebTransport ou d'un type de transport concret.

Logging/telemetry

• tracing ;
• sinks plateforme ;
• diagnostics ;
• métriques séparées du logging.

Game-systems réutilisables

Grid/tilemap

• grille ;
• coordonnées ;
• layers ;
• tile occupancy ;
• topology wrap/toroïdale ;
• zones/chunks possibles.

Collision 2D grid

• murs ;
• obstacles ;
• entités occupantes ;
• collision tile/entity.

Camera/viewport gameplay

• suivi ;
• scrolling ;
• bounds ;
• map plus grande que l'écran.

Stage/progression

• stage id/version ;
• start/complete/fail ;
• transitions ;
• ordre de stages.

Lives/attempts

• vie courante ;
• perte ;
• continue ;
• respawn policy.

Score

• score brut ;
• bonus ;
• pénalités ;
• modifiers ;
• résultat final explicable.

Timed entities

• apparition ;
• durée ;
• expiration ;
• respawn ;
• cooldown.

Pickup/inventory

• pickups ;
• capacité ;
• stacks ;
• consommables ;
• activation volontaire.

Status effects

Réservé pour les évolutions :

• freeze ;
• poison ;
• shield ;
• timed modifiers.

Uroburas-specific gameplay

Snake anatomy

• tête ;
• cou ;
• corps extensible ;
• queue ;
• longueur minimale de quatre unités.

Snake movement

• direction relative ;
• interdiction/gestion du demi-tour ;
• step-based ;
• auto-forward ;
• vitesse Snake.

Snake body geometry

• croissance ;
• rétrécissement ;
• propagation de positions ;
• courbures gauche/droite ;
• rotation de sprites ;
• coupure future.

Uroburas stage rules

• objectifs propres à une map Uroburas ;
• règles de fin ;
• règles de croissance/rétrécissement ;
• interactions propres aux items.

Uroburas modes

• Challenge ;
• Persistent Battle Royale ;
• PvP Battles.

Combat Uroburas

Future scope :

• feu ;
• glace ;
• poison ;
• protections tête/corps ;
• téléporteurs ;
• interaction tête/cou/corps/queue.

Ces concepts restent Uroburas-specific tant qu'un second jeu ne justifie pas leur généralisation.

Server services

Identity/account

• PlayerId canonique ;
• login ;
• session ;
• account linking ;
• external identities ;
• email verification/recovery.

Content service

• catalogue maps/skins/assets ;
• versions ;
• manifests ;
• URLs/download authorization ;
• publication/modération future.

Asset delivery

• service auto-hébergé ;
• HTTP/2 baseline ;
• HTTP/3/QUIC lorsque disponible ;
• même hostname H2/H3 de préférence ;
• cache et distribution multi-nœuds futurs ;
• séparation logique du Content service ;
• séparation physique uniquement lorsque la charge le justifie.

Hall of Fame

• score submission ;
• validation ;
• classement ;
• contexte map/ruleset/game version.

Reward authority

• rewarded ad validation ;
• continue autorisé ;
• bonus de stage ;
• idempotence ;
• anti-double-credit.

Realtime session service

Pour Modes 3 puis 2 :

• WebSocket session ;
• authoritative state ;
• tick ;
• snapshots/deltas ;
• reconnect/resync ;
• spectator.

Bot execution

• profils ;
• décision serveur ;
• respawn ;
• simulation de participants.

Media/replay

Future scope :

• event log ;
• replay ;
• rendu/reconstitution ;
• streaming/enregistrement.

Providers

• ad provider ;
• auth provider externe ;
• email transport provider éventuel ;
• CDN/object storage ;
• Play Games/Game Center/Steam futurs.

Le provider n'est jamais l'identité métier canonique.

Platform adapters

Desktop SDL

• SDL window/render/input ;
• keyboard ;
• filesystem/platform lifecycle.

Android SDL

• Java/JNI ;
• touch/virtual controls ;
• Android lifecycle ;
• packaging.

Web/WASM

• browser host ;
• pointer/touch/keyboard ;
• storage/browser lifecycle ;
• asset fetch.

Tauri

• WebView host ;
• bridge Rust/Web ;
• platform plugins.

Tooling

Map editor

• création ;
• validation ;
• preview/test ;
• publication.

Skin editor

• contrat de skin ;
• preview ;
• génération contrôlée ;
• validation.

Build tooling

• Cargo ;
• Gradle ;
• Tauri CLI ;
• outils natifs de plateforme.

Python n'est pas un outil de build.

Audit/validation tooling

Python reste autorisé pour :

• audits ;
• validations complémentaires ;
• contrôles statiques ;
• rapports.

Règle de dépendance

Le jeu dépend vers les couches réutilisables :

Uroburas game
    ↓
game-systems
    ↓
technical capabilities
    ↓
engine kernel

Les adapters/providers sont composés par les applications/targets, pas appelés directement depuis la logique Uroburas.

Les services serveur partagent des contrats/domain types explicitement dédiés, sans importer les crates client/GUI.