0.2.0-0-pre.6
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
// file: Android/game-reflex-poc/build.gradle
|
||||
// version: 38
|
||||
// version: 39
|
||||
|
||||
plugins {
|
||||
id 'com.android.application'
|
||||
@@ -18,7 +18,7 @@ android {
|
||||
minSdk 21
|
||||
targetSdk 36
|
||||
versionCode 2
|
||||
versionName '0.2.0-0-pre.5.fix.1'
|
||||
versionName '0.2.0-0-pre.6'
|
||||
}
|
||||
|
||||
compileOptions {
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
// file: Android/game-snake-poc/build.gradle
|
||||
// version: 38
|
||||
// version: 39
|
||||
|
||||
plugins {
|
||||
id 'com.android.application'
|
||||
@@ -18,7 +18,7 @@ android {
|
||||
minSdk 21
|
||||
targetSdk 36
|
||||
versionCode 2
|
||||
versionName '0.2.0-0-pre.5.fix.1'
|
||||
versionName '0.2.0-0-pre.6'
|
||||
}
|
||||
|
||||
compileOptions {
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
# file: Cargo.toml
|
||||
# version: 50
|
||||
# version: 51
|
||||
|
||||
[workspace]
|
||||
resolver = "3"
|
||||
@@ -19,7 +19,7 @@ members = [
|
||||
]
|
||||
|
||||
[workspace.package]
|
||||
version = "0.2.0-0-pre.5.fix.1"
|
||||
version = "0.2.0-0-pre.6"
|
||||
edition = "2024"
|
||||
license = "MIT"
|
||||
repository = "https://git.sasedev.com/Sasedev/games"
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: README.md -->
|
||||
<!-- version: 18 -->
|
||||
<!-- version: 19 -->
|
||||
|
||||
# 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 candidate en cours de conception : `0.2.0-0-pre.5.fix.1`.
|
||||
Version candidate en cours de conception : `0.2.0-0-pre.6`.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
75
deltas/0.2.0/0-pre.6.md
Normal file
75
deltas/0.2.0/0-pre.6.md
Normal file
@@ -0,0 +1,75 @@
|
||||
<!-- file: deltas/0.2.0/0-pre.6.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.2.0-0-pre.6
|
||||
|
||||
## Base
|
||||
|
||||
Base déclarée : `0.2.0-0-pre.5.fix.1`.
|
||||
|
||||
## Objet
|
||||
|
||||
Classifier les fonctionnalités Uroburas avant toute implémentation afin d'éviter un monolithe dans les futures crates multiplateformes du jeu.
|
||||
|
||||
## Classification
|
||||
|
||||
Les responsabilités sont réparties entre :
|
||||
|
||||
- engine kernel ;
|
||||
- technical capabilities ;
|
||||
- game-systems réutilisables ;
|
||||
- gameplay Uroburas-specific ;
|
||||
- services serveur ;
|
||||
- providers ;
|
||||
- platform adapters ;
|
||||
- tooling.
|
||||
|
||||
## Décomposition candidate
|
||||
|
||||
L'étude propose des familles de crates pour :
|
||||
|
||||
- capabilities ;
|
||||
- game-systems ;
|
||||
- Uroburas ;
|
||||
- apps ;
|
||||
- servers ;
|
||||
- providers ;
|
||||
- tools.
|
||||
|
||||
Aucune création massive de crates n'est imposée : l'extraction doit rester motivée par une frontière et une API réelles.
|
||||
|
||||
## Stack serveur de référence
|
||||
|
||||
Direction étudiée :
|
||||
|
||||
- Tokio ;
|
||||
- Actix Web ;
|
||||
- Maud ;
|
||||
- tokio-tungstenite pour le realtime public ;
|
||||
- tonic/gRPC conditionnel pour server-to-server ;
|
||||
- Fluent/fluent-bundle ;
|
||||
- Lettre.
|
||||
|
||||
Le client public reste orienté `HTTPS + WebSocket`.
|
||||
|
||||
## Ordre d'implémentation
|
||||
|
||||
Priorité :
|
||||
|
||||
1. fondations réutilisables ;
|
||||
2. game-systems du Mode 1 ;
|
||||
3. Uroburas Challenge ;
|
||||
4. services Web V1 ;
|
||||
5. intégration client/server Mode 1 ;
|
||||
6. Mode 3 ;
|
||||
7. Mode 2.
|
||||
|
||||
## 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 : ce delta reste documentaire.
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/studies/000-README.md -->
|
||||
<!-- version: 7 -->
|
||||
<!-- version: 8 -->
|
||||
|
||||
# Études
|
||||
|
||||
@@ -46,3 +46,10 @@ Ces documents étudient les POC à réaliser ; ils ne lancent encore aucune impl
|
||||
- [`016-UROBURAS_COMBAT_ITEM_EFFECT_SPEC.md`](016-UROBURAS_COMBAT_ITEM_EFFECT_SPEC.md) — armes, protections et interactions tête/corps/queue.
|
||||
- [`017-UROBURAS_SCORE_RESPAWN_AND_HALL_OF_FAME.md`](017-UROBURAS_SCORE_RESPAWN_AND_HALL_OF_FAME.md) — score, vies, rewarded continue/rejoin et classements.
|
||||
- [`018-UROBURAS_SERVER_MEDIA_AND_OBSERVATION_SPEC.md`](018-UROBURAS_SERVER_MEDIA_AND_OBSERVATION_SPEC.md) — spectator, bots, replay, streaming et vidéo régénérée.
|
||||
|
||||
## Classification Uroburas avant implémentation
|
||||
|
||||
- [`019-UROBURAS_FUNCTIONAL_OWNERSHIP_CLASSIFICATION.md`](019-UROBURAS_FUNCTIONAL_OWNERSHIP_CLASSIFICATION.md) — mapping des fonctionnalités vers kernel, capabilities, game-systems, Uroburas, server, provider, platform et tooling.
|
||||
- [`020-UROBURAS_CRATE_DECOMPOSITION_STUDY.md`](020-UROBURAS_CRATE_DECOMPOSITION_STUDY.md) — proposition de familles de crates et dépendances sans monolithe jeu.
|
||||
- [`021-UROBURAS_SERVER_REFERENCE_STACK.md`](021-UROBURAS_SERVER_REFERENCE_STACK.md) — stack serveur de référence Actix/Tokio/tokio-tungstenite/Maud/Fluent/Lettre et gRPC/Tonic conditionnel.
|
||||
- [`022-UROBURAS_IMPLEMENTATION_DEPENDENCY_ORDER.md`](022-UROBURAS_IMPLEMENTATION_DEPENDENCY_ORDER.md) — ordre d'implémentation recommandé pour le Mode 1 avant les modes multijoueurs.
|
||||
|
||||
394
docs/studies/019-UROBURAS_FUNCTIONAL_OWNERSHIP_CLASSIFICATION.md
Normal file
394
docs/studies/019-UROBURAS_FUNCTIONAL_OWNERSHIP_CLASSIFICATION.md
Normal file
@@ -0,0 +1,394 @@
|
||||
<!-- file: docs/studies/019-UROBURAS_FUNCTIONAL_OWNERSHIP_CLASSIFICATION.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# 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
|
||||
|
||||
- HTTPS ;
|
||||
- WebSocket ;
|
||||
- reconnect ;
|
||||
- timeout/backoff ;
|
||||
- protocole versionné ;
|
||||
- session/auth tokens ;
|
||||
- validation des messages ;
|
||||
- séparation transport/protocole.
|
||||
|
||||
### 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.
|
||||
|
||||
### 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 :
|
||||
|
||||
```text
|
||||
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.
|
||||
208
docs/studies/020-UROBURAS_CRATE_DECOMPOSITION_STUDY.md
Normal file
208
docs/studies/020-UROBURAS_CRATE_DECOMPOSITION_STUDY.md
Normal file
@@ -0,0 +1,208 @@
|
||||
<!-- file: docs/studies/020-UROBURAS_CRATE_DECOMPOSITION_STUDY.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Uroburas — étude de décomposition en crates
|
||||
|
||||
## Statut
|
||||
|
||||
Étude non normative pour `0.2.0-0-pre.6`.
|
||||
|
||||
Les noms ci-dessous sont des candidats, pas encore des crates à créer immédiatement.
|
||||
|
||||
## Engine existant
|
||||
|
||||
À conserver comme fondation :
|
||||
|
||||
```text
|
||||
crates/engines/engine-v1-common
|
||||
crates/engines/engine-v1-platform-api
|
||||
crates/engines/engine-v1-sdl
|
||||
```
|
||||
|
||||
Le kernel ne doit pas absorber les systèmes de grille, score ou Snake uniquement parce que Uroburas en a besoin.
|
||||
|
||||
## Capabilities candidates
|
||||
|
||||
Famille possible :
|
||||
|
||||
```text
|
||||
crates/capabilities/
|
||||
game-assets-lib
|
||||
game-input-lib
|
||||
game-localization-lib
|
||||
game-network-client-lib
|
||||
game-persistence-lib
|
||||
game-audio-lib
|
||||
```
|
||||
|
||||
Les noms finaux devront respecter les règles workspace et éviter les crates artificiellement petites.
|
||||
|
||||
## Game-systems candidates
|
||||
|
||||
Famille possible :
|
||||
|
||||
```text
|
||||
crates/game-systems/
|
||||
game-grid-lib
|
||||
game-collision-grid-lib
|
||||
game-stage-lib
|
||||
game-score-lib
|
||||
game-lives-lib
|
||||
game-timed-entity-lib
|
||||
game-pickup-lib
|
||||
```
|
||||
|
||||
Ces crates ne sont créées que si leur API est suffisamment stable et réutilisable.
|
||||
|
||||
Des mécanismes très liés peuvent rester regroupés dans une même crate plutôt que multiplier les packages.
|
||||
|
||||
## Uroburas game crates
|
||||
|
||||
Proposition progressive :
|
||||
|
||||
```text
|
||||
crates/games/
|
||||
game-uroburas-lib
|
||||
```
|
||||
|
||||
Cette crate compose les règles Uroburas.
|
||||
|
||||
Si la complexité le justifie plus tard :
|
||||
|
||||
```text
|
||||
game-uroburas-core-lib
|
||||
game-uroburas-content-lib
|
||||
game-uroburas-protocol-lib
|
||||
```
|
||||
|
||||
Mais ne pas splitter avant besoin réel.
|
||||
|
||||
`game-uroburas-lib` ne doit pas dépendre directement de :
|
||||
|
||||
- Actix ;
|
||||
- Maud ;
|
||||
- Lettre ;
|
||||
- tokio-tungstenite ;
|
||||
- SDK publicitaire ;
|
||||
- Java Android ;
|
||||
- Tauri API.
|
||||
|
||||
## Applications client
|
||||
|
||||
Candidats futurs :
|
||||
|
||||
```text
|
||||
crates/apps/
|
||||
game-uroburas-desktop
|
||||
game-uroburas-wasm
|
||||
game-uroburas-tauri
|
||||
game-uroburas-android-entrypoint
|
||||
```
|
||||
|
||||
Les apps composent :
|
||||
|
||||
- jeu ;
|
||||
- adapters plateforme ;
|
||||
- capabilities ;
|
||||
- providers nécessaires.
|
||||
|
||||
## Server crates
|
||||
|
||||
Famille proposée :
|
||||
|
||||
```text
|
||||
crates/servers/
|
||||
uroburas-server-domain-lib
|
||||
uroburas-server-api-lib
|
||||
uroburas-server-web
|
||||
uroburas-server-realtime
|
||||
```
|
||||
|
||||
Puis seulement si besoin :
|
||||
|
||||
```text
|
||||
uroburas-server-media
|
||||
uroburas-server-admin
|
||||
```
|
||||
|
||||
### server-domain-lib
|
||||
|
||||
Contient des concepts serveur partagés :
|
||||
|
||||
- PlayerId ;
|
||||
- MapId/MapVersion ;
|
||||
- ScoreSubmission ;
|
||||
- HallOfFameEntry ;
|
||||
- RewardGrant ;
|
||||
- Session identifiers.
|
||||
|
||||
Ne contient pas Actix/Tungstenite/Tonic.
|
||||
|
||||
### server-api-lib
|
||||
|
||||
Contrats DTO/protocole :
|
||||
|
||||
- HTTP DTOs ;
|
||||
- WebSocket messages ;
|
||||
- versioning ;
|
||||
- validation structurale.
|
||||
|
||||
Les wire types restent distincts des modèles métier internes.
|
||||
|
||||
### server-web
|
||||
|
||||
- Actix Web ;
|
||||
- Maud ;
|
||||
- auth endpoints ;
|
||||
- Hall of Fame ;
|
||||
- maps/assets metadata ;
|
||||
- administration initiale ;
|
||||
- Fluent serveur ;
|
||||
- Lettre.
|
||||
|
||||
### server-realtime
|
||||
|
||||
Future Mode 3/2 :
|
||||
|
||||
- Tokio ;
|
||||
- tokio-tungstenite ;
|
||||
- rooms/worlds ;
|
||||
- authoritative simulation ;
|
||||
- snapshots/deltas ;
|
||||
- spectator ;
|
||||
- bots.
|
||||
|
||||
## Providers
|
||||
|
||||
Famille possible :
|
||||
|
||||
```text
|
||||
crates/providers/
|
||||
game-ads-api-lib
|
||||
game-ads-<provider>-lib
|
||||
game-auth-<provider>-lib
|
||||
```
|
||||
|
||||
Ne pas créer les providers tant qu'ils ne sont pas nécessaires à une cible réelle.
|
||||
|
||||
## Tooling
|
||||
|
||||
Candidats futurs :
|
||||
|
||||
```text
|
||||
crates/tools/
|
||||
uroburas-map-editor
|
||||
uroburas-skin-editor
|
||||
```
|
||||
|
||||
Un éditeur Web peut aussi avoir sa propre app/host au lieu d'être une crate de jeu.
|
||||
|
||||
## Anti-monolithe
|
||||
|
||||
Avant d'ajouter une fonctionnalité à `game-uroburas-lib`, poser trois questions :
|
||||
|
||||
1. connaît-elle explicitement les règles Uroburas ?
|
||||
2. serait-elle utile dans un autre jeu sans référence à Uroburas ?
|
||||
3. dépend-elle d'une plateforme, d'un transport ou d'un provider ?
|
||||
|
||||
Si la réponse à 1 est non et à 2 ou 3 est oui, elle appartient probablement ailleurs.
|
||||
169
docs/studies/021-UROBURAS_SERVER_REFERENCE_STACK.md
Normal file
169
docs/studies/021-UROBURAS_SERVER_REFERENCE_STACK.md
Normal file
@@ -0,0 +1,169 @@
|
||||
<!-- file: docs/studies/021-UROBURAS_SERVER_REFERENCE_STACK.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Uroburas — stack serveur de référence
|
||||
|
||||
## Statut
|
||||
|
||||
Étude de référence pour `0.2.0-0-pre.6`.
|
||||
|
||||
## Runtime async
|
||||
|
||||
Référence :
|
||||
|
||||
```text
|
||||
Tokio
|
||||
```
|
||||
|
||||
## HTTP / Web
|
||||
|
||||
Référence :
|
||||
|
||||
```text
|
||||
Actix Web
|
||||
```
|
||||
|
||||
Responsabilités initiales :
|
||||
|
||||
- auth ;
|
||||
- compte ;
|
||||
- maps/assets metadata ;
|
||||
- Hall of Fame ;
|
||||
- rewarded grants ;
|
||||
- admin initiale ;
|
||||
- pages Web.
|
||||
|
||||
## HTML server-side
|
||||
|
||||
Référence :
|
||||
|
||||
```text
|
||||
Maud
|
||||
```
|
||||
|
||||
Objectif :
|
||||
|
||||
- rendu HTML côté Rust ;
|
||||
- pages compte ;
|
||||
- Hall of Fame ;
|
||||
- administration ;
|
||||
- pages jeu/portail.
|
||||
|
||||
Le JavaScript reste réservé aux interactions qui le nécessitent.
|
||||
|
||||
## Realtime public
|
||||
|
||||
Référence :
|
||||
|
||||
```text
|
||||
Tokio + tokio-tungstenite
|
||||
```
|
||||
|
||||
Utilisé pour les futurs Modes 3 puis 2.
|
||||
|
||||
La logique de gameplay ne dépend pas directement des types Tungstenite.
|
||||
|
||||
Le transport doit rester encapsulé derrière le protocole Uroburas afin qu'un benchmark futur puisse justifier un changement d'implémentation sans réécrire la simulation.
|
||||
|
||||
## gRPC
|
||||
|
||||
Référence conditionnelle :
|
||||
|
||||
```text
|
||||
tonic
|
||||
```
|
||||
|
||||
Utilisation envisagée :
|
||||
|
||||
- server-to-server ;
|
||||
- worker média/replay ;
|
||||
- orchestration interne ;
|
||||
- appels typés entre services lorsque la séparation physique le justifie.
|
||||
|
||||
gRPC n'est pas obligatoire pour le transport public client/gameplay.
|
||||
|
||||
Le client public utilise en priorité :
|
||||
|
||||
```text
|
||||
HTTPS + WebSocket
|
||||
```
|
||||
|
||||
## Localization
|
||||
|
||||
Référence :
|
||||
|
||||
```text
|
||||
Fluent / fluent-bundle
|
||||
```
|
||||
|
||||
Côté client :
|
||||
|
||||
- menus ;
|
||||
- HUD ;
|
||||
- erreurs ;
|
||||
- contenu localisé ;
|
||||
- maps/assets téléchargeables.
|
||||
|
||||
Côté serveur :
|
||||
|
||||
- HTML ;
|
||||
- emails ;
|
||||
- messages utilisateur ;
|
||||
- administration.
|
||||
|
||||
Les protocoles transportent des codes/identifiants métier, pas des chaînes déjà traduites.
|
||||
|
||||
## Email
|
||||
|
||||
Référence :
|
||||
|
||||
```text
|
||||
Lettre
|
||||
```
|
||||
|
||||
Cas initiaux possibles :
|
||||
|
||||
- vérification de compte ;
|
||||
- reset password ;
|
||||
- notifications sécurité ;
|
||||
- magic link si retenu.
|
||||
|
||||
Les contenus email utilisent Fluent.
|
||||
|
||||
## Séparation des modèles
|
||||
|
||||
Ne pas partager directement comme modèles métier :
|
||||
|
||||
- types Actix ;
|
||||
- types Tungstenite ;
|
||||
- messages protobuf ;
|
||||
- types Maud.
|
||||
|
||||
Séparation attendue :
|
||||
|
||||
```text
|
||||
domain model
|
||||
HTTP DTO
|
||||
WebSocket protocol
|
||||
gRPC contracts
|
||||
HTML view model
|
||||
```
|
||||
|
||||
## Performance
|
||||
|
||||
La stack realtime doit être validée par benchmarks de charge avant gel long terme.
|
||||
|
||||
Mesures candidates :
|
||||
|
||||
- connexions concurrentes ;
|
||||
- mémoire/connexion ;
|
||||
- messages/s ;
|
||||
- bytes/s ;
|
||||
- p50/p95/p99 ;
|
||||
- backpressure ;
|
||||
- coût broadcast ;
|
||||
- coût interest management ;
|
||||
- reconnect/resync ;
|
||||
- CPU par tick.
|
||||
|
||||
Le choix `tokio-tungstenite` est la référence initiale, pas une affirmation non mesurée de supériorité universelle.
|
||||
107
docs/studies/022-UROBURAS_IMPLEMENTATION_DEPENDENCY_ORDER.md
Normal file
107
docs/studies/022-UROBURAS_IMPLEMENTATION_DEPENDENCY_ORDER.md
Normal file
@@ -0,0 +1,107 @@
|
||||
<!-- file: docs/studies/022-UROBURAS_IMPLEMENTATION_DEPENDENCY_ORDER.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# 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 ;
|
||||
- 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 ;
|
||||
- tokio-tungstenite ;
|
||||
- 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.
|
||||
19
history/0.2.0/0-pre.5.fix.1.md
Normal file
19
history/0.2.0/0-pre.5.fix.1.md
Normal file
@@ -0,0 +1,19 @@
|
||||
<!-- file: history/0.2.0/0-pre.5.fix.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Historique 0.2.0-0-pre.5.fix.1
|
||||
|
||||
## Statut
|
||||
|
||||
Spécification fonctionnelle Uroburas acceptée comme base de classification avant `0-pre.6`.
|
||||
|
||||
## Points structurants
|
||||
|
||||
- première version centrée Mode 1 Challenge ;
|
||||
- ordre prévu Mode 1 → Mode 3 → Mode 2 ;
|
||||
- anatomie minimale tête + cou + corps + queue ;
|
||||
- corps seul extensible ;
|
||||
- maps/assets/skins téléchargeables ;
|
||||
- virtual directional buttons Mobile/Tablet ;
|
||||
- Hall of Fame, auth et rewarded ads dès la première trajectoire ;
|
||||
- combat avancé conservé pour les évolutions ultérieures.
|
||||
Reference in New Issue
Block a user