85 lines
5.7 KiB
Markdown
85 lines
5.7 KiB
Markdown
<!-- file: prompts/001-V0_2_0_START_PROMPT.md -->
|
|
<!-- version: 1 -->
|
|
|
|
# Prompt de démarrage 0.2.0 — conception du framework modulaire
|
|
|
|
Partir de la version stable `0.1.0` et considérer cette version comme la clôture du POC multi-plateforme. Lire intégralement `RULES.md`, `ROADMAP.md`, `CHANGELOG.md`, `docs/000-README.md`, `docs/architecture/011-POST_0_1_0_DIRECTION.md`, les documents d'architecture existants, `history/0.1.0/3-rc.1.fix.1.md` et `deltas/0.1.0/rel.md` avant toute proposition.
|
|
|
|
La première phase `0.2.0` est une phase de conception et de réservation architecturale. Ne pas commencer par développer massivement de nouvelles fonctionnalités ni par créer une crate pour chaque idée.
|
|
|
|
## Objectif
|
|
|
|
Transformer le POC en architecture de framework modulaire capable d'accueillir progressivement des jeux très différents tout en gardant un kernel moteur réduit et des dépendances explicites.
|
|
|
|
Les fonctionnalités doivent être inventoriées et réservées lorsqu'un besoin plausible concret est déjà identifiable, puis implémentées seulement lorsqu'un jeu, un archétype ou une plateforme les exige réellement.
|
|
|
|
## Travail de conception obligatoire
|
|
|
|
Effectuer les étapes suivantes dans cet ordre, avec discussion/audit avant gel :
|
|
|
|
1. établir un inventaire large des capabilities plausibles déjà justifiées par les jeux et plateformes envisagés ;
|
|
2. classer chaque élément dans une couche explicite : `kernel`, `capability`, `platform adapter`, `provider`, `game/system`, `server/service` ou `tooling` ;
|
|
3. définir les dépendances autorisées et interdites entre ces couches ;
|
|
4. définir une matrice des capacités par plateforme : Desktop SDL, Android SDL, Web/WASM, Tauri Desktop et Tauri Android expérimental ;
|
|
5. définir les archétypes de jeux et leurs besoins : reflex/arcade, snake/grid, puzzle/adventure, racing, fighting 1v1, hack'n slash, multiplayer compétitif, MMORPG/PKE et autres besoins déjà identifiés ;
|
|
6. distinguer capability générique, système de jeu réutilisable et logique spécifique à un jeu ;
|
|
7. définir le modèle de composition statique des produits et éviter de faire reposer toute la composition sur des Cargo features globales ;
|
|
8. concevoir un manifest machine-readable de produit/jeu décrivant capabilities requises, optionnelles, non supportées, dépendantes d'un serveur ou spécifiques à une plateforme ;
|
|
9. définir l'architecture cible des crates sans créer immédiatement toutes les crates réservées ;
|
|
10. définir la stratégie de logging/tracing par domaines de crates et la configuration statique de build par produit/plateforme ;
|
|
11. définir les frontières auth/identity, online/offline, persistence/sync, ads/providers, leaderboards, multiplayer, assets/CDN et services Web ;
|
|
12. étudier explicitement le POC Tauri Android en comparaison de SDL Android ;
|
|
13. remplacer à terme l'orchestration Android Python du POC par un outil/build system multi-ABI conçu pour le projet ;
|
|
14. seulement après validation de cette conception, proposer la roadmap détaillée `0.2.x`, puis les orientations `0.3.x` et suivantes.
|
|
|
|
## Exemples de pression architecturale
|
|
|
|
Utiliser des jeux concrets pour tester la conception, sans les implémenter tous immédiatement.
|
|
|
|
### Snake
|
|
|
|
Prévoir notamment la possibilité de configurer taille de grille et serpent, croissance, vitesse, textures tête/corps/queue, obstacles, murs ou wrap, collisions avec soi/autres serpents, plusieurs joueurs locaux/IA/online, variantes de maps et leaderboard.
|
|
|
|
### Reflex
|
|
|
|
Prévoir des parties déterministes ou générées, mêmes séquences pour plusieurs joueurs, taille/skin/durée des cibles, scoring, comparaison de scores, validation serveur et leaderboard.
|
|
|
|
### Adventure/puzzle à énergie
|
|
|
|
Considérer énergie, inventaire, progression/XP/niveaux, maps/tiles, Sokoban, pipes, lasers/mirrors, rewarded ads, événements et classement.
|
|
|
|
### Racing / fighting / hack'n slash / MMORPG-PKE
|
|
|
|
Utiliser ces familles pour challenger input, temps réel, authoritative server, sessions/lobby/matchmaking, synchronisation, chat, persistence, économie et éventuelles rewards externes, sans intégrer ces domaines dans le kernel moteur.
|
|
|
|
## Livrables de conception attendus
|
|
|
|
Créer au minimum, sous réserve de validation des noms pendant la session :
|
|
|
|
```text
|
|
docs/architecture/CAPABILITY_CATALOG.md
|
|
docs/architecture/LAYERING_AND_DEPENDENCIES.md
|
|
docs/architecture/PLATFORM_CAPABILITY_MATRIX.md
|
|
docs/games/GAME_ARCHETYPES_AND_REQUIREMENTS.md
|
|
```
|
|
|
|
Le catalogue doit pouvoir attribuer à une capability un statut tel que `Reserved`, `Planned`, `Experimental`, `Implemented`, `PlatformSpecific`, `Unsupported(platform)` ou `Deprecated` sans que la simple réservation déclenche une implémentation.
|
|
|
|
## Contraintes
|
|
|
|
- ne pas transformer `engine-v1` en moteur monolithique ;
|
|
- conserver le gameplay portable indépendant des APIs de providers et plateformes ;
|
|
- préférer des contrats explicites et des adaptateurs aux `#[cfg]` dispersés dans les jeux ;
|
|
- ne pas charger dynamiquement des bibliothèques sans besoin démontré ;
|
|
- garder la composition statique Rust comme défaut ;
|
|
- ne pas figer prématurément une API ou une crate pour une fonctionnalité purement spéculative ;
|
|
- distinguer disponibilité, désactivation volontaire et non-support d'une capability ;
|
|
- permettre qu'un jeu soit mono-plateforme, multi-plateforme, offline-only, online-optional ou online-required ;
|
|
- respecter toutes les règles de version, audit, tests, fichiers et livraisons du dépôt.
|
|
|
|
## Résultat attendu de la première session 0.2.0
|
|
|
|
La session doit d'abord produire une architecture documentée cohérente et une roadmap d'implémentation progressive.
|
|
|
|
Le développement fonctionnel significatif ne commence qu'après validation de cette conception.
|