From 5f75c3ad1a0d820891f7f328b4a9b0d26c19feb6 Mon Sep 17 00:00:00 2001 From: SinuS Von SifriduS Date: Fri, 18 Sep 2026 14:46:05 +0200 Subject: [PATCH] 0.2.0-0-pre.3 --- Android/game-reflex-poc/build.gradle | 4 +- Android/game-snake-poc/build.gradle | 4 +- Cargo.toml | 4 +- README.md | 4 +- deltas/0.2.0/0-pre.3.md | 66 ++++ docs/studies/000-README.md | 4 +- .../001-FUNCTIONAL_CAPABILITY_INVENTORY.md | 38 ++- .../004-GAME_ARCHETYPE_PRESSURE_TEST.md | 6 +- .../005-DEPENDENCY_AND_COMPOSITION_STUDY.md | 50 +++- .../007-GAME_AI_AND_BOT_EXECUTION_STUDY.md | 181 +++++++++++ ...008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md | 282 ++++++++++++++++++ history/0.2.0/0-pre.2.fix.3.md | 27 ++ 12 files changed, 656 insertions(+), 14 deletions(-) create mode 100644 deltas/0.2.0/0-pre.3.md create mode 100644 docs/studies/007-GAME_AI_AND_BOT_EXECUTION_STUDY.md create mode 100644 docs/studies/008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md create mode 100644 history/0.2.0/0-pre.2.fix.3.md diff --git a/Android/game-reflex-poc/build.gradle b/Android/game-reflex-poc/build.gradle index cea504e..429e4c6 100644 --- a/Android/game-reflex-poc/build.gradle +++ b/Android/game-reflex-poc/build.gradle @@ -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 { diff --git a/Android/game-snake-poc/build.gradle b/Android/game-snake-poc/build.gradle index 67de8e5..87165eb 100644 --- a/Android/game-snake-poc/build.gradle +++ b/Android/game-snake-poc/build.gradle @@ -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 { diff --git a/Cargo.toml b/Cargo.toml index 338f9f4..7104074 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -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" diff --git a/README.md b/README.md index 5b8e634..11f2630 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,5 @@ - + # 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. diff --git a/deltas/0.2.0/0-pre.3.md b/deltas/0.2.0/0-pre.3.md new file mode 100644 index 0000000..64e9de7 --- /dev/null +++ b/deltas/0.2.0/0-pre.3.md @@ -0,0 +1,66 @@ + + + +# 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. diff --git a/docs/studies/000-README.md b/docs/studies/000-README.md index 9b19320..a95d432 100644 --- a/docs/studies/000-README.md +++ b/docs/studies/000-README.md @@ -1,5 +1,5 @@ - + # É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. diff --git a/docs/studies/001-FUNCTIONAL_CAPABILITY_INVENTORY.md b/docs/studies/001-FUNCTIONAL_CAPABILITY_INVENTORY.md index 8eb094f..f69acfa 100644 --- a/docs/studies/001-FUNCTIONAL_CAPABILITY_INVENTORY.md +++ b/docs/studies/001-FUNCTIONAL_CAPABILITY_INVENTORY.md @@ -1,5 +1,5 @@ - + # 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 : diff --git a/docs/studies/004-GAME_ARCHETYPE_PRESSURE_TEST.md b/docs/studies/004-GAME_ARCHETYPE_PRESSURE_TEST.md index 8356a6b..9429d5d 100644 --- a/docs/studies/004-GAME_ARCHETYPE_PRESSURE_TEST.md +++ b/docs/studies/004-GAME_ARCHETYPE_PRESSURE_TEST.md @@ -1,5 +1,5 @@ - + # 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 diff --git a/docs/studies/005-DEPENDENCY_AND_COMPOSITION_STUDY.md b/docs/studies/005-DEPENDENCY_AND_COMPOSITION_STUDY.md index f21a13e..b0bf8a0 100644 --- a/docs/studies/005-DEPENDENCY_AND_COMPOSITION_STUDY.md +++ b/docs/studies/005-DEPENDENCY_AND_COMPOSITION_STUDY.md @@ -1,5 +1,5 @@ - + # É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 : diff --git a/docs/studies/007-GAME_AI_AND_BOT_EXECUTION_STUDY.md b/docs/studies/007-GAME_AI_AND_BOT_EXECUTION_STUDY.md new file mode 100644 index 0000000..c1f4b01 --- /dev/null +++ b/docs/studies/007-GAME_AI_AND_BOT_EXECUTION_STUDY.md @@ -0,0 +1,181 @@ + + + +# É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 ? diff --git a/docs/studies/008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md b/docs/studies/008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md new file mode 100644 index 0000000..11d21ce --- /dev/null +++ b/docs/studies/008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md @@ -0,0 +1,282 @@ + + + +# É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. +api. +realtime. +cdn. +``` + +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 ? diff --git a/history/0.2.0/0-pre.2.fix.3.md b/history/0.2.0/0-pre.2.fix.3.md new file mode 100644 index 0000000..2ba510d --- /dev/null +++ b/history/0.2.0/0-pre.2.fix.3.md @@ -0,0 +1,27 @@ + + + +# 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.