0.2.0-0-pre.3
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
// file: Android/game-reflex-poc/build.gradle
|
||||
// version: 31
|
||||
// version: 32
|
||||
|
||||
plugins {
|
||||
id 'com.android.application'
|
||||
@@ -18,7 +18,7 @@ android {
|
||||
minSdk 21
|
||||
targetSdk 36
|
||||
versionCode 2
|
||||
versionName '0.2.0-0-pre.2.fix.3'
|
||||
versionName '0.2.0-0-pre.3'
|
||||
}
|
||||
|
||||
compileOptions {
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
// file: Android/game-snake-poc/build.gradle
|
||||
// version: 31
|
||||
// version: 32
|
||||
|
||||
plugins {
|
||||
id 'com.android.application'
|
||||
@@ -18,7 +18,7 @@ android {
|
||||
minSdk 21
|
||||
targetSdk 36
|
||||
versionCode 2
|
||||
versionName '0.2.0-0-pre.2.fix.3'
|
||||
versionName '0.2.0-0-pre.3'
|
||||
}
|
||||
|
||||
compileOptions {
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
# file: Cargo.toml
|
||||
# version: 43
|
||||
# version: 44
|
||||
|
||||
[workspace]
|
||||
resolver = "3"
|
||||
@@ -19,7 +19,7 @@ members = [
|
||||
]
|
||||
|
||||
[workspace.package]
|
||||
version = "0.2.0-0-pre.2.fix.3"
|
||||
version = "0.2.0-0-pre.3"
|
||||
edition = "2024"
|
||||
license = "MIT"
|
||||
repository = "https://git.sasedev.com/Sasedev/games"
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: README.md -->
|
||||
<!-- version: 11 -->
|
||||
<!-- version: 12 -->
|
||||
|
||||
# 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.2.fix.3`.
|
||||
Version candidate en cours de conception : `0.2.0-0-pre.3`.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
66
deltas/0.2.0/0-pre.3.md
Normal file
66
deltas/0.2.0/0-pre.3.md
Normal file
@@ -0,0 +1,66 @@
|
||||
<!-- file: deltas/0.2.0/0-pre.3.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.2.0-0-pre.3
|
||||
|
||||
## Base
|
||||
|
||||
Base déclarée : `0.2.0-0-pre.2.fix.3`.
|
||||
|
||||
## Objet
|
||||
|
||||
Compléter l'étude fonctionnelle validée en `0-pre.2.fix.3` avec deux axes manquants : adversaires pilotés/bots et architecture Web/identité/hébergement multi-jeux.
|
||||
|
||||
## Bot / pseudo-IA
|
||||
|
||||
L'étude couvre :
|
||||
|
||||
- logique simple ;
|
||||
- recherche/pathfinding ;
|
||||
- modèles entraînés éventuels ;
|
||||
- bot local ;
|
||||
- bot serveur ;
|
||||
- difficulté ;
|
||||
- remplacement de joueur ;
|
||||
- bots de tests/charge ;
|
||||
- réutilisation des semantic actions ;
|
||||
- séparation entre moteur d'exécution et stratégie propre au jeu.
|
||||
|
||||
Aucune dépendance ML n'est réservée comme obligatoire.
|
||||
|
||||
## Web / identité / hébergement
|
||||
|
||||
L'étude couvre :
|
||||
|
||||
- identité canonique `PlayerId` ;
|
||||
- anonymous account ;
|
||||
- credentials propres ;
|
||||
- OAuth/OIDC ;
|
||||
- Google/Apple ;
|
||||
- Play Games/Game Center/Steam comme identities liées ;
|
||||
- account linking/merge ;
|
||||
- sessions/tokens ;
|
||||
- portail initial `games.sasedev.com` ;
|
||||
- pages/jeux sous portail commun ;
|
||||
- migration future d'un jeu vers son propre domaine ;
|
||||
- services logiques `www/auth/api/cdn/leaderboard/realtime/admin` ;
|
||||
- services spécifiques par jeu ;
|
||||
- multi-tenant logique ;
|
||||
- modular monolith initial puis séparation motivée par besoin réel ;
|
||||
- CORS/origins/OAuth redirects lors de la multiplication des domaines.
|
||||
|
||||
## Fichiers nouveaux
|
||||
|
||||
- `docs/studies/007-GAME_AI_AND_BOT_EXECUTION_STUDY.md` ;
|
||||
- `docs/studies/008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md` ;
|
||||
- `history/0.2.0/0-pre.2.fix.3.md`.
|
||||
|
||||
## 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 : aucune implémentation runtime ou configuration de build n'est modifiée.
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/studies/000-README.md -->
|
||||
<!-- version: 3 -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Études
|
||||
|
||||
@@ -24,5 +24,7 @@ Les études conservent les alternatives et raisons utiles à la compréhension f
|
||||
- [`004-GAME_ARCHETYPE_PRESSURE_TEST.md`](004-GAME_ARCHETYPE_PRESSURE_TEST.md) — vérification du modèle par plusieurs familles de jeux.
|
||||
- [`005-DEPENDENCY_AND_COMPOSITION_STUDY.md`](005-DEPENDENCY_AND_COMPOSITION_STUDY.md) — dépendances autorisées et composition statique envisagée.
|
||||
- [`006-REALTIME_MULTIPLAYER_SERVER_STUDY.md`](006-REALTIME_MULTIPLAYER_SERVER_STUDY.md) — transport, session, synchronisation, autorité, resync et scaling du multijoueur temps réel.
|
||||
- [`007-GAME_AI_AND_BOT_EXECUTION_STUDY.md`](007-GAME_AI_AND_BOT_EXECUTION_STUDY.md) — adversaires pilotés par logique, bot local, bot serveur et frontières avec l'IA générative/ML.
|
||||
- [`008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md`](008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md) — identité canonique, providers externes, hébergement global puis sites/services propres à chaque jeu.
|
||||
|
||||
Ces études sont des propositions à relire. Elles ne deviennent pas automatiquement des décisions d'architecture.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/studies/001-FUNCTIONAL_CAPABILITY_INVENTORY.md -->
|
||||
<!-- version: 2 -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# Inventaire fonctionnel initial
|
||||
|
||||
@@ -241,6 +241,24 @@ Plusieurs niveaux possibles :
|
||||
|
||||
Seules les collisions réellement nécessaires seront implémentées. Un moteur physique généraliste n'est pas réservé à ce stade.
|
||||
|
||||
### Game AI / bot control
|
||||
|
||||
Besoins identifiés :
|
||||
|
||||
- adversaire piloté par règles déterministes ;
|
||||
- bot local embarqué ;
|
||||
- bot serveur pour parties online ;
|
||||
- difficulté configurable ;
|
||||
- décision basée sur un état de jeu réduit ou complet ;
|
||||
- budget de calcul/tick ;
|
||||
- reproductibilité éventuelle par seed ;
|
||||
- remplacement d'un joueur déconnecté dans certains jeux ;
|
||||
- simulation de charge ou de joueurs synthétiques pour tests.
|
||||
|
||||
Le terme « IA » ne signifie pas nécessairement machine learning. Un bot peut être une simple machine à états, un arbre de décision, du pathfinding, une recherche minimax/MCTS ou une stratégie spécialisée.
|
||||
|
||||
Le modèle doit permettre d'exécuter la logique côté client ou côté serveur selon le jeu sans dupliquer les règles métier.
|
||||
|
||||
### Determinism / seeded challenge
|
||||
|
||||
Besoins identifiés par Reflex compétitif et potentiellement puzzles/races :
|
||||
@@ -331,6 +349,24 @@ Aucun provider ne doit remonter dans le kernel.
|
||||
|
||||
## Server services candidates
|
||||
|
||||
### Portail Web / sites de jeux
|
||||
|
||||
Besoins identifiés :
|
||||
|
||||
- portail global `games.sasedev.com` ;
|
||||
- pages/catalogue des jeux ;
|
||||
- profil joueur global ;
|
||||
- pages de leaderboard ;
|
||||
- pages d'aide/support ;
|
||||
- pages légales et confidentialité ;
|
||||
- landing pages spécifiques par jeu ;
|
||||
- possibilité qu'un jeu migre ensuite vers son propre domaine ;
|
||||
- conservation de l'identité centrale malgré la séparation du site ;
|
||||
- APIs partagées et APIs spécifiques par jeu ;
|
||||
- séparation possible entre `www`, `auth`, `api`, `cdn`, `leaderboard`, `realtime`, `admin` et services propres au jeu.
|
||||
|
||||
Le découpage DNS/deployment ne doit pas imposer le découpage interne initial. Une architecture modulaire peut commencer déployée ensemble puis être séparée.
|
||||
|
||||
### Services Web non temps réel
|
||||
|
||||
Besoins identifiés :
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/studies/004-GAME_ARCHETYPE_PRESSURE_TEST.md -->
|
||||
<!-- version: 2 -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# Pressure test par archétypes de jeux
|
||||
|
||||
@@ -41,7 +41,7 @@ Besoins :
|
||||
- vitesse/ruleset configurable ;
|
||||
- maps ;
|
||||
- score/lives ;
|
||||
- AI éventuelle ;
|
||||
- bot/AI éventuel local ou serveur ;
|
||||
- multiplayer 2 joueurs éventuel.
|
||||
|
||||
Conclusion provisoire :
|
||||
@@ -163,7 +163,7 @@ Besoins potentiels :
|
||||
|
||||
Conclusion provisoire :
|
||||
|
||||
ce cas impose une architecture client/serveur nettement plus large mais ne doit pas gonfler l'engine local avant qu'un tel projet soit réellement lancé.
|
||||
ce cas impose une architecture client/serveur nettement plus large, un portail/compte durable et potentiellement des bots serveur, mais ne doit pas gonfler l'engine local avant qu'un tel projet soit réellement lancé.
|
||||
|
||||
## PKE avec reward crypto éventuel
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/studies/005-DEPENDENCY_AND_COMPOSITION_STUDY.md -->
|
||||
<!-- version: 3 -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Étude des dépendances et de la composition
|
||||
|
||||
@@ -186,6 +186,54 @@ Le framework peut fournir les couches techniques réutilisables sans imposer une
|
||||
|
||||
Le serveur Web/API classique peut partager des types/protocoles avec le service realtime, mais il ne doit pas obligatoirement partager le même process ni la même cadence d'exécution.
|
||||
|
||||
|
||||
## Bot / AI execution
|
||||
|
||||
Le pilotage artificiel doit emprunter autant que possible les mêmes semantic actions qu'un joueur humain :
|
||||
|
||||
```text
|
||||
observation
|
||||
↓
|
||||
bot strategy
|
||||
↓
|
||||
semantic action
|
||||
↓
|
||||
game simulation
|
||||
```
|
||||
|
||||
La stratégie peut être composée :
|
||||
|
||||
- dans le client pour un mode offline ;
|
||||
- dans le serveur authoritative pour une partie online ;
|
||||
- dans un outil de test pour simulation/charge.
|
||||
|
||||
Le kernel n'a pas à connaître l'algorithme utilisé.
|
||||
|
||||
## Web et services par jeu
|
||||
|
||||
La composition backend doit permettre un démarrage partagé puis une séparation progressive :
|
||||
|
||||
```text
|
||||
games.sasedev.com
|
||||
├─ auth
|
||||
├─ common API
|
||||
├─ leaderboard
|
||||
├─ realtime
|
||||
└─ game modules
|
||||
```
|
||||
|
||||
puis, si nécessaire :
|
||||
|
||||
```text
|
||||
game-domain
|
||||
├─ www
|
||||
├─ api
|
||||
├─ realtime
|
||||
└─ cdn
|
||||
```
|
||||
|
||||
L'identité canonique et les contrats communs doivent survivre à ce changement de déploiement.
|
||||
|
||||
## Online/offline
|
||||
|
||||
La composition doit pouvoir exprimer :
|
||||
|
||||
181
docs/studies/007-GAME_AI_AND_BOT_EXECUTION_STUDY.md
Normal file
181
docs/studies/007-GAME_AI_AND_BOT_EXECUTION_STUDY.md
Normal file
@@ -0,0 +1,181 @@
|
||||
<!-- file: docs/studies/007-GAME_AI_AND_BOT_EXECUTION_STUDY.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Étude des adversaires pilotés et bots
|
||||
|
||||
## Statut
|
||||
|
||||
Étude non normative pour `0.2.0-0-pre.3`.
|
||||
|
||||
## Objectif
|
||||
|
||||
Prévoir des adversaires contrôlés par le programme sans supposer qu'ils doivent être :
|
||||
|
||||
- du machine learning ;
|
||||
- embarqués dans le client ;
|
||||
- dépendants d'un provider externe ;
|
||||
- spécifiques à une seule plateforme.
|
||||
|
||||
Le besoin générique est :
|
||||
|
||||
> produire une décision de joueur artificiel à partir d'un état de jeu autorisé.
|
||||
|
||||
## Familles de logique
|
||||
|
||||
### Règles simples
|
||||
|
||||
Exemples :
|
||||
|
||||
- réflexes basiques ;
|
||||
- comportement scripté ;
|
||||
- probabilités pondérées ;
|
||||
- machine à états.
|
||||
|
||||
Adapté à :
|
||||
|
||||
- Snake simple ;
|
||||
- ennemis d'arcade ;
|
||||
- tutorial opponent ;
|
||||
- bots de remplissage.
|
||||
|
||||
### Recherche / planification
|
||||
|
||||
Exemples :
|
||||
|
||||
- BFS/A* ;
|
||||
- minimax ;
|
||||
- alpha-beta ;
|
||||
- MCTS ;
|
||||
- heuristiques de navigation.
|
||||
|
||||
Adapté à :
|
||||
|
||||
- puzzles ;
|
||||
- jeux de plateau ;
|
||||
- certains jeux tactiques.
|
||||
|
||||
### Modèles entraînés
|
||||
|
||||
À réserver seulement lorsqu'un projet réel le justifie :
|
||||
|
||||
- modèle supervisé ;
|
||||
- reinforcement learning ;
|
||||
- réseau neuronal ;
|
||||
- XGBoost/LightGBM pour décisions tabulaires.
|
||||
|
||||
Le framework de jeu ne doit pas dépendre d'un framework ML tant qu'aucun consommateur concret ne l'exige.
|
||||
|
||||
## Contrat conceptuel
|
||||
|
||||
Un bot pourrait consommer :
|
||||
|
||||
```text
|
||||
GameObservation
|
||||
BotContext
|
||||
DifficultyProfile
|
||||
DecisionBudget
|
||||
```
|
||||
|
||||
et produire :
|
||||
|
||||
```text
|
||||
SemanticAction
|
||||
```
|
||||
|
||||
ou une séquence courte d'actions.
|
||||
|
||||
Le contrat exact n'est pas figé.
|
||||
|
||||
## Local vs serveur
|
||||
|
||||
### Bot local
|
||||
|
||||
Avantages :
|
||||
|
||||
- fonctionne offline ;
|
||||
- latence faible ;
|
||||
- pas de coût serveur.
|
||||
|
||||
Risques :
|
||||
|
||||
- logique visible/modifiable côté client ;
|
||||
- comportement potentiellement différent selon version ;
|
||||
- impossible d'en faire une autorité fiable pour compétition.
|
||||
|
||||
### Bot serveur
|
||||
|
||||
Avantages :
|
||||
|
||||
- comportement centralisé ;
|
||||
- version contrôlée ;
|
||||
- utile pour matchmaking/remplacement de joueurs ;
|
||||
- peut partager la simulation authoritative.
|
||||
|
||||
Risques :
|
||||
|
||||
- coût CPU ;
|
||||
- besoin réseau ;
|
||||
- complexité de scaling.
|
||||
|
||||
## Règle d'ownership candidate
|
||||
|
||||
La stratégie de bot dépend du jeu ou d'un game-system spécialisé.
|
||||
|
||||
Le mécanisme d'exécution générique peut être réutilisable :
|
||||
|
||||
```text
|
||||
game simulation
|
||||
↓
|
||||
observation
|
||||
↓
|
||||
bot strategy
|
||||
↓
|
||||
semantic action
|
||||
```
|
||||
|
||||
Le bot ne doit pas appeler directement l'input physique ni modifier l'état interne par un chemin privilégié si un joueur humain passe par des semantic actions.
|
||||
|
||||
## Difficulté
|
||||
|
||||
La difficulté peut être obtenue par :
|
||||
|
||||
- profondeur de recherche ;
|
||||
- délai de réaction ;
|
||||
- précision ;
|
||||
- bruit ;
|
||||
- accès limité à l'information ;
|
||||
- heuristique plus ou moins forte ;
|
||||
- budget CPU/tick.
|
||||
|
||||
Éviter de tricher implicitement en donnant au bot des informations invisibles au joueur, sauf si le game design l'assume explicitement.
|
||||
|
||||
## Remplacement de joueur
|
||||
|
||||
Cas utile en multiplayer :
|
||||
|
||||
- joueur déconnecté ;
|
||||
- lobby incomplet ;
|
||||
- partie d'entraînement ;
|
||||
- remplissage temporaire.
|
||||
|
||||
Le remplacement doit être une décision du jeu/session, pas une règle imposée par le moteur.
|
||||
|
||||
## Tests
|
||||
|
||||
Les bots peuvent aussi servir à :
|
||||
|
||||
- tests de longues parties ;
|
||||
- fuzzing de gameplay ;
|
||||
- génération de trajectoires ;
|
||||
- tests de charge serveur ;
|
||||
- validation de déterminisme.
|
||||
|
||||
Un bot de test peut être distinct d'un bot destiné au joueur final.
|
||||
|
||||
## Questions ouvertes
|
||||
|
||||
- faut-il une API générique `BotController` ou rester game-specific au début ?
|
||||
- où stocker les profils de difficulté ?
|
||||
- comment garantir le même comportement client/serveur si la logique est partagée ?
|
||||
- quand extraire pathfinding/recherche vers des game-systems réutilisables ?
|
||||
- comment versionner la stratégie d'un bot dans un match replayable ?
|
||||
282
docs/studies/008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md
Normal file
282
docs/studies/008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md
Normal file
@@ -0,0 +1,282 @@
|
||||
<!-- file: docs/studies/008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Étude Web, identité et hébergement des jeux
|
||||
|
||||
## Statut
|
||||
|
||||
Étude non normative pour `0.2.0-0-pre.3`.
|
||||
|
||||
## Objectif
|
||||
|
||||
Permettre un démarrage simple sous une plateforme commune puis une évolution vers des sites et services propres à certains jeux sans casser l'identité joueur.
|
||||
|
||||
## Identité canonique
|
||||
|
||||
Le backend games.sasedev doit posséder un identifiant joueur canonique indépendant des providers externes.
|
||||
|
||||
Conceptuellement :
|
||||
|
||||
```text
|
||||
PlayerId
|
||||
├─ anonymous device identity
|
||||
├─ email/password ou passwordless
|
||||
├─ Google identity
|
||||
├─ Apple identity
|
||||
├─ Play Games identity
|
||||
├─ Steam identity
|
||||
└─ autres providers futurs
|
||||
```
|
||||
|
||||
Un provider externe est une identité liée, pas la clé primaire du joueur.
|
||||
|
||||
## Modes d'authentification à prévoir
|
||||
|
||||
### Anonymous
|
||||
|
||||
Cas :
|
||||
|
||||
- découverte immédiate du jeu ;
|
||||
- première partie sans création de compte ;
|
||||
- fonctionnement offline ou semi-online.
|
||||
|
||||
Doit permettre si nécessaire :
|
||||
|
||||
- création d'un profil temporaire ;
|
||||
- migration vers un compte durable ;
|
||||
- conservation de progression lors de l'upgrade.
|
||||
|
||||
### Credentials propres
|
||||
|
||||
Options à étudier :
|
||||
|
||||
- email + mot de passe ;
|
||||
- username + mot de passe ;
|
||||
- magic link ;
|
||||
- passkey/WebAuthn.
|
||||
|
||||
Le choix final dépendra des besoins sécurité/UX.
|
||||
|
||||
### OAuth / OpenID Connect
|
||||
|
||||
Providers plausibles :
|
||||
|
||||
- Google ;
|
||||
- Apple ;
|
||||
- autres comptes sociaux si pertinents.
|
||||
|
||||
Le backend doit valider les tokens/provider claims puis lier l'identité externe à son `PlayerId`.
|
||||
|
||||
### Platform identities
|
||||
|
||||
Exemples :
|
||||
|
||||
- Google Play Games ;
|
||||
- Apple Game Center ;
|
||||
- Steam.
|
||||
|
||||
Ces identités peuvent faciliter sign-in, achievements ou leaderboard mais ne remplacent pas l'identité canonique globale.
|
||||
|
||||
## Account linking
|
||||
|
||||
Cas à prévoir :
|
||||
|
||||
- anonymous → compte durable ;
|
||||
- Google + Apple sur le même joueur ;
|
||||
- appareil perdu puis récupération ;
|
||||
- changement de provider ;
|
||||
- conflit lorsque deux providers correspondent déjà à deux comptes distincts.
|
||||
|
||||
Le merge de comptes doit être explicite et sécurisé.
|
||||
|
||||
## Sessions
|
||||
|
||||
Besoins :
|
||||
|
||||
- access token court ;
|
||||
- refresh/session token ;
|
||||
- révocation ;
|
||||
- liste des devices/sessions éventuellement ;
|
||||
- logout global ou local ;
|
||||
- rotation ;
|
||||
- protection CSRF/cookies pour Web selon architecture ;
|
||||
- stockage sécurisé côté apps natives.
|
||||
|
||||
Le détail cryptographique sera étudié séparément avant implémentation.
|
||||
|
||||
## Portail initial
|
||||
|
||||
Déploiement initial plausible :
|
||||
|
||||
```text
|
||||
games.sasedev.com
|
||||
```
|
||||
|
||||
Responsabilités possibles :
|
||||
|
||||
- catalogue ;
|
||||
- login/signup ;
|
||||
- compte joueur ;
|
||||
- pages des jeux ;
|
||||
- leaderboards ;
|
||||
- support ;
|
||||
- liens vers stores ;
|
||||
- jeu Web pour les produits compatibles ;
|
||||
- administration séparée.
|
||||
|
||||
Les premiers jeux peuvent être servis sous :
|
||||
|
||||
```text
|
||||
games.sasedev.com/games/snake
|
||||
games.sasedev.com/games/reflex
|
||||
```
|
||||
|
||||
ou équivalent.
|
||||
|
||||
Le chemin exact n'est pas encore décidé.
|
||||
|
||||
## Évolution vers un site propre
|
||||
|
||||
Un jeu devenu suffisamment important peut avoir :
|
||||
|
||||
```text
|
||||
snake.example-game-domain.tld
|
||||
```
|
||||
|
||||
ou un domaine propre.
|
||||
|
||||
Le déplacement ne doit pas imposer :
|
||||
|
||||
- nouveau compte joueur ;
|
||||
- nouvelle base d'identité ;
|
||||
- duplication des providers OAuth ;
|
||||
- incompatibilité des leaderboards/progression.
|
||||
|
||||
Le site propre consomme les services communs via des APIs versionnées.
|
||||
|
||||
## Sous-services
|
||||
|
||||
Découpage logique candidat :
|
||||
|
||||
```text
|
||||
www.games.sasedev.com
|
||||
auth.games.sasedev.com
|
||||
api.games.sasedev.com
|
||||
cdn.games.sasedev.com
|
||||
leaderboard.games.sasedev.com
|
||||
realtime.games.sasedev.com
|
||||
admin.games.sasedev.com
|
||||
```
|
||||
|
||||
et, pour un jeu spécifique :
|
||||
|
||||
```text
|
||||
www.<game-domain>
|
||||
api.<game-domain>
|
||||
realtime.<game-domain>
|
||||
cdn.<game-domain>
|
||||
```
|
||||
|
||||
Ce sont des frontières logiques possibles, pas une obligation de créer immédiatement tous ces DNS/process.
|
||||
|
||||
## Global vs game-specific
|
||||
|
||||
Services globalement partageables :
|
||||
|
||||
- auth/identity ;
|
||||
- account/profile ;
|
||||
- entitlement général éventuel ;
|
||||
- catalogue ;
|
||||
- administration centrale ;
|
||||
- common CDN assets éventuels.
|
||||
|
||||
Services souvent game-specific :
|
||||
|
||||
- gameplay API ;
|
||||
- matchmaking ;
|
||||
- realtime simulation ;
|
||||
- rulesets ;
|
||||
- game inventory/progression spécialisée ;
|
||||
- events/seasons ;
|
||||
- maps/assets propres au jeu.
|
||||
|
||||
Certains services, comme leaderboard, peuvent avoir une API générique et une configuration par jeu.
|
||||
|
||||
## Multi-tenant logique
|
||||
|
||||
Le backend commun doit pouvoir distinguer :
|
||||
|
||||
- `game_id` ;
|
||||
- environment ;
|
||||
- protocol/version ;
|
||||
- player ;
|
||||
- product/platform.
|
||||
|
||||
Éviter de dupliquer tout le backend par jeu avant qu'une isolation réelle ne soit nécessaire.
|
||||
|
||||
## Hébergement et découpage physique
|
||||
|
||||
Étape initiale plausible :
|
||||
|
||||
```text
|
||||
modular monolith
|
||||
```
|
||||
|
||||
avec modules clairement séparés.
|
||||
|
||||
Évolution possible :
|
||||
|
||||
```text
|
||||
auth service
|
||||
API service
|
||||
realtime service
|
||||
leaderboard service
|
||||
game-specific services
|
||||
```
|
||||
|
||||
La séparation physique est motivée par :
|
||||
|
||||
- charge ;
|
||||
- sécurité ;
|
||||
- cycle de déploiement ;
|
||||
- isolation de panne ;
|
||||
- besoins réseau ;
|
||||
- ownership.
|
||||
|
||||
Pas par recherche de microservices pour eux-mêmes.
|
||||
|
||||
## Web game hosting
|
||||
|
||||
Un jeu Web/WASM peut être :
|
||||
|
||||
- servi directement par le portail global ;
|
||||
- servi par son propre site ;
|
||||
- embarqué dans une page Tauri pour certains produits ;
|
||||
- télécharger ses assets depuis un CDN séparé.
|
||||
|
||||
Le build jeu doit rester indépendant du hostname final.
|
||||
|
||||
## CORS / origins / OAuth redirects
|
||||
|
||||
Le passage d'un domaine global à des domaines propres impose de prévoir :
|
||||
|
||||
- origins autorisées ;
|
||||
- callback URLs OAuth ;
|
||||
- cookies/domain policy ;
|
||||
- CORS ;
|
||||
- CSP ;
|
||||
- token audience ;
|
||||
- deep links/app links éventuels.
|
||||
|
||||
Ces points doivent être configurables et non hardcodés dans le gameplay.
|
||||
|
||||
## Questions ouvertes
|
||||
|
||||
- quel provider d'identité implémenter en premier ?
|
||||
- anonymous account server-side dès le début ou seulement local ?
|
||||
- email/password, magic link ou passkey ?
|
||||
- cookies de session pour Web vs bearer tokens pour apps natives ?
|
||||
- comment gérer account merge ?
|
||||
- quel découpage initial entre portail, auth, API et realtime ?
|
||||
- quels services doivent être multi-game dès V1 ?
|
||||
- comment versionner les APIs et protocoles par jeu ?
|
||||
27
history/0.2.0/0-pre.2.fix.3.md
Normal file
27
history/0.2.0/0-pre.2.fix.3.md
Normal file
@@ -0,0 +1,27 @@
|
||||
<!-- file: history/0.2.0/0-pre.2.fix.3.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Historique 0.2.0-0-pre.2.fix.3
|
||||
|
||||
## Statut
|
||||
|
||||
Étude fonctionnelle initiale validée avant ouverture de `0.2.0-0-pre.3`.
|
||||
|
||||
## Contenu accepté
|
||||
|
||||
- inventaire fonctionnel initial ;
|
||||
- séparation kernel / capability / game-system / platform adapter / provider / server service / tooling / game-specific ;
|
||||
- matrice conceptuelle des plateformes et backends ;
|
||||
- pressure tests par archétypes de jeux ;
|
||||
- dépendances et composition statique ;
|
||||
- étude du serveur realtime, snapshots/deltas, resync, authoritative state et scaling ;
|
||||
- conventions de tableaux Markdown corrigées et validées par audit.
|
||||
|
||||
## Suite
|
||||
|
||||
`0-pre.3` complète l'étude avec :
|
||||
|
||||
- adversaires pilotés/bots local ou serveur ;
|
||||
- identité Web multi-provider ;
|
||||
- portail commun puis sites propres aux jeux ;
|
||||
- séparation progressive des sous-services.
|
||||
Reference in New Issue
Block a user