2349 lines
33 KiB
Text
2349 lines
33 KiB
Text
# Plan V1 — Mod Minecraft Boutique PNJ
|
||
|
||
## 1. Environnement
|
||
|
||
* Minecraft 1.21.1
|
||
* NeoForge
|
||
* Easy NPC intégré dès la V1
|
||
* support prioritaire du contenu Vanilla en V1
|
||
* architecture extensible pour les mods ajoutant :
|
||
|
||
* recettes
|
||
* tables de craft
|
||
* fours
|
||
* machines
|
||
* systèmes de transformation
|
||
* nouvelles familles de production
|
||
|
||
Farmer’s Delight pourra servir de premier cas réel de compatibilité, mais aucune architecture centrale ne doit être spécifique à Farmer’s Delight.
|
||
|
||
---
|
||
|
||
# 2. Principe architectural général
|
||
|
||
Le cœur du mod connaît uniquement des concepts abstraits :
|
||
|
||
```text
|
||
Boutique
|
||
Session
|
||
Mode de session
|
||
Recette
|
||
Station
|
||
Famille de production
|
||
Production
|
||
Commande
|
||
Client
|
||
Réputation
|
||
Provenance
|
||
```
|
||
|
||
Il ne doit pas dépendre directement de noms de mods particuliers.
|
||
|
||
Architecture générale :
|
||
|
||
```text
|
||
SHOP CORE
|
||
│
|
||
┌──────────────────┼───────────────────┐
|
||
│ │ │
|
||
RecipeResolver ShopValidator ProductionTracker
|
||
│ │ │
|
||
└──────────────────┼───────────────────┘
|
||
│
|
||
Production Registry
|
||
│
|
||
┌─────────────────┼──────────────────┐
|
||
│ │ │
|
||
Vanilla Farmer's Delight Autres mods
|
||
Integration Integration Integration
|
||
```
|
||
|
||
---
|
||
|
||
# 3. Dépendances
|
||
|
||
## NeoForge
|
||
|
||
Utilisé pour :
|
||
|
||
* blocs
|
||
* menus/screens
|
||
* événements
|
||
* données joueur
|
||
* configuration serveur
|
||
* recettes
|
||
* synchronisation
|
||
* persistance
|
||
* données d'ItemStack
|
||
* rendu client du mode Vérification
|
||
|
||
## Easy NPC
|
||
|
||
Easy NPC fait partie de la V1.
|
||
|
||
Il est utilisé pour :
|
||
|
||
* représentation des clients
|
||
* modèles
|
||
* skins
|
||
* apparences
|
||
* dialogues
|
||
* interactions
|
||
* navigation/pathfinding
|
||
* spawn/despawn
|
||
|
||
Toute utilisation d’Easy NPC passe par une couche d’intégration :
|
||
|
||
```text
|
||
ShopManager
|
||
↓
|
||
CustomerManager
|
||
↓
|
||
NpcAdapter
|
||
↓
|
||
Easy NPC
|
||
```
|
||
|
||
Le cœur économique ne dépend jamais directement d’Easy NPC.
|
||
|
||
---
|
||
|
||
# 4. Concept général
|
||
|
||
Le joueur construit une boutique physique.
|
||
|
||
Des PNJ clients :
|
||
|
||
1. apparaissent à l’entrée ;
|
||
2. suivent le chemin vers la boutique ;
|
||
3. rejoignent la file ;
|
||
4. arrivent au comptoir ;
|
||
5. passent une commande ;
|
||
6. attendent ;
|
||
7. reçoivent les objets ;
|
||
8. paient ;
|
||
9. repartent.
|
||
|
||
Le joueur doit fabriquer les produits demandés dans la boutique.
|
||
|
||
Boucle générale :
|
||
|
||
```text
|
||
Approvisionnement
|
||
↓
|
||
Ouverture de session
|
||
↓
|
||
Clients
|
||
↓
|
||
Commandes
|
||
↓
|
||
Production
|
||
↓
|
||
Livraison
|
||
↓
|
||
Émeraudes
|
||
↓
|
||
Réputation éventuelle
|
||
```
|
||
|
||
---
|
||
|
||
# 5. Boutique physique et session
|
||
|
||
Séparer clairement :
|
||
|
||
## Shop
|
||
|
||
La boutique persistante.
|
||
|
||
Elle définit :
|
||
|
||
```text
|
||
propriétaire
|
||
zone
|
||
marqueurs
|
||
comptoir
|
||
stockage
|
||
entrée/sortie
|
||
chemins
|
||
stations
|
||
spécialisations disponibles
|
||
```
|
||
|
||
## ShopSession
|
||
|
||
Une période d’ouverture temporaire.
|
||
|
||
Elle définit :
|
||
|
||
```text
|
||
sessionId
|
||
shopId
|
||
gameplayMode
|
||
startTime
|
||
materialSnapshot
|
||
activeProductPool
|
||
activeStationFamilies
|
||
clients
|
||
commandes
|
||
état
|
||
```
|
||
|
||
La boutique reste identique d’une session à l’autre.
|
||
|
||
---
|
||
|
||
# 6. Choix du mode à chaque ouverture
|
||
|
||
Le mode de jeu n’est pas une configuration serveur permanente.
|
||
|
||
Lorsque le joueur clique sur :
|
||
|
||
```text
|
||
OPEN SHOP
|
||
```
|
||
|
||
ouvrir une fenêtre de préparation de session.
|
||
|
||
Exemple :
|
||
|
||
```text
|
||
OUVRIR LA BOUTIQUE
|
||
|
||
Choisissez un mode :
|
||
|
||
┌────────────────────────────┐
|
||
│ STANDARD │
|
||
│ │
|
||
│ Réputation active │
|
||
│ Récompenses normales │
|
||
│ Difficulté évolutive │
|
||
│ Gestion avancée du stock │
|
||
└────────────────────────────┘
|
||
|
||
┌────────────────────────────┐
|
||
│ CHILL │
|
||
│ │
|
||
│ Aucune variation de │
|
||
│ réputation │
|
||
│ Récompenses réduites │
|
||
│ Commandes plus tranquilles │
|
||
└────────────────────────────┘
|
||
```
|
||
|
||
Le joueur choisit le mode avant que la session commence réellement.
|
||
|
||
---
|
||
|
||
# 7. ShopGameplayMode
|
||
|
||
Créer :
|
||
|
||
```text
|
||
ShopGameplayMode
|
||
```
|
||
|
||
V1 :
|
||
|
||
```text
|
||
STANDARD
|
||
CHILL
|
||
```
|
||
|
||
Le mode est enregistré dans :
|
||
|
||
```text
|
||
ShopSession
|
||
```
|
||
|
||
et ne modifie pas la structure permanente de la boutique.
|
||
|
||
---
|
||
|
||
# 8. Mode STANDARD
|
||
|
||
Mode principal de progression.
|
||
|
||
Caractéristiques :
|
||
|
||
```text
|
||
Réputation active
|
||
Récompenses normales
|
||
Difficulté liée à la réputation
|
||
Fréquence de clients évolutive
|
||
Quantités évolutives
|
||
Gestion du stock évolutive
|
||
File évolutive
|
||
```
|
||
|
||
Les actions influencent la réputation.
|
||
|
||
```text
|
||
SUCCESS
|
||
→ réputation +
|
||
|
||
REFUSED
|
||
→ réputation -
|
||
|
||
TIMEOUT
|
||
→ réputation --
|
||
|
||
FORCE_CLOSE
|
||
→ réputation ---
|
||
```
|
||
|
||
---
|
||
|
||
# 9. Mode CHILL
|
||
|
||
Mode de session détendu.
|
||
|
||
Caractéristiques :
|
||
|
||
```text
|
||
aucun gain de réputation
|
||
aucune perte de réputation
|
||
récompenses réduites
|
||
commandes raisonnables
|
||
pression logistique réduite
|
||
patience plus généreuse
|
||
file modérée
|
||
```
|
||
|
||
La réputation permanente du joueur existe toujours.
|
||
|
||
Elle est simplement figée pendant cette session.
|
||
|
||
Exemple :
|
||
|
||
```text
|
||
Réputation avant session : 527
|
||
|
||
Session CHILL
|
||
|
||
SUCCESS → 527
|
||
REFUSED → 527
|
||
TIMEOUT → 527
|
||
FORCE_CLOSE → 527
|
||
|
||
Fin de session : 527
|
||
```
|
||
|
||
---
|
||
|
||
# 10. Récompenses CHILL
|
||
|
||
Les récompenses sont réduites afin que le mode CHILL ne devienne pas la meilleure méthode de farm.
|
||
|
||
Utiliser un multiplicateur configurable.
|
||
|
||
Exemple de valeur initiale :
|
||
|
||
```text
|
||
chillRewardMultiplier = 0.60
|
||
```
|
||
|
||
Une commande valant normalement :
|
||
|
||
```text
|
||
10 émeraudes
|
||
```
|
||
|
||
donnerait par exemple :
|
||
|
||
```text
|
||
6 émeraudes
|
||
```
|
||
|
||
en CHILL.
|
||
|
||
La valeur exacte devra être équilibrée par playtest.
|
||
|
||
---
|
||
|
||
# 11. Règles de commandes CHILL
|
||
|
||
Le mode CHILL doit conserver le gameplay de fabrication.
|
||
|
||
Il ne doit pas supprimer :
|
||
|
||
* commandes
|
||
* spécialisations
|
||
* Recipe Resolver
|
||
* production dans la boutique
|
||
* provenance
|
||
* chemins
|
||
* file
|
||
* patience
|
||
* stock
|
||
|
||
Il réduit uniquement la pression.
|
||
|
||
Politique recommandée :
|
||
|
||
```text
|
||
Stock réel utilisé
|
||
Quantités réelles prises en compte
|
||
Commandes raisonnablement réalisables
|
||
Patience supérieure
|
||
File plus courte
|
||
Fréquence modérée
|
||
```
|
||
|
||
---
|
||
|
||
# 12. Stock en CHILL
|
||
|
||
Le mode CHILL utilise toujours la logique de stock sécurisé.
|
||
|
||
Le générateur regarde :
|
||
|
||
```text
|
||
types disponibles
|
||
+
|
||
quantités disponibles
|
||
```
|
||
|
||
afin d’éviter autant que possible les commandes impossibles.
|
||
|
||
Il n’utilise donc pas le mécanisme exigeant de snapshot par type de matière utilisé à haute réputation en STANDARD.
|
||
|
||
---
|
||
|
||
# 13. Stock en STANDARD
|
||
|
||
La politique dépend de la réputation.
|
||
|
||
## Réputation faible
|
||
|
||
Utiliser :
|
||
|
||
```text
|
||
types
|
||
+
|
||
quantités réelles
|
||
```
|
||
|
||
afin de protéger les nouveaux joueurs.
|
||
|
||
## Réputation élevée
|
||
|
||
À l’ouverture :
|
||
|
||
```text
|
||
stock
|
||
↓
|
||
snapshot des TYPES
|
||
↓
|
||
catalogue de session
|
||
```
|
||
|
||
Exemple :
|
||
|
||
```text
|
||
128 Iron
|
||
64 Coal
|
||
32 Logs
|
||
12 Diamond
|
||
```
|
||
|
||
devient :
|
||
|
||
```text
|
||
IRON
|
||
COAL
|
||
WOOD
|
||
DIAMOND
|
||
```
|
||
|
||
Les quantités ne sont ensuite plus utilisées pour limiter les commandes.
|
||
|
||
Le joueur doit gérer son réapprovisionnement.
|
||
|
||
---
|
||
|
||
# 14. Changement de mode
|
||
|
||
Impossible de changer le mode d’une session déjà ouverte.
|
||
|
||
Pour changer :
|
||
|
||
```text
|
||
Fermer la session
|
||
↓
|
||
Nouvelle ouverture
|
||
↓
|
||
Choisir un nouveau mode
|
||
```
|
||
|
||
Cela évite les exploits comme :
|
||
|
||
```text
|
||
ouvrir STANDARD
|
||
↓
|
||
profiter des paramètres
|
||
↓
|
||
passer CHILL juste avant un timeout
|
||
```
|
||
|
||
---
|
||
|
||
# 15. ShopGameplayRules
|
||
|
||
Ne pas disperser :
|
||
|
||
```text
|
||
if (mode == CHILL)
|
||
```
|
||
|
||
dans tout le projet.
|
||
|
||
Créer une abstraction :
|
||
|
||
```text
|
||
ShopGameplayRules
|
||
```
|
||
|
||
Implémentations :
|
||
|
||
```text
|
||
StandardGameplayRules
|
||
ChillGameplayRules
|
||
```
|
||
|
||
---
|
||
|
||
# 16. Responsabilités de ShopGameplayRules
|
||
|
||
Interface conceptuelle :
|
||
|
||
```text
|
||
getRewardMultiplier(...)
|
||
getReputationDelta(...)
|
||
getOrderDifficulty(...)
|
||
getOrderQuantityLimits(...)
|
||
getCustomerPatience(...)
|
||
getSpawnRate(...)
|
||
getMaxQueueSize(...)
|
||
getStockPolicy(...)
|
||
```
|
||
|
||
Les autres systèmes demandent leurs paramètres aux règles de la session.
|
||
|
||
---
|
||
|
||
# 17. Architecture du mode
|
||
|
||
```text
|
||
ShopSession
|
||
│
|
||
├── ShopGameplayMode
|
||
│
|
||
└── ShopGameplayRules
|
||
│
|
||
┌────┴─────┐
|
||
│ │
|
||
Standard Chill
|
||
Rules Rules
|
||
```
|
||
|
||
Cela permettra éventuellement d’ajouter d’autres modes plus tard sans modifier tout le mod.
|
||
|
||
---
|
||
|
||
# 18. Comptoir
|
||
|
||
Le comptoir est le contrôleur principal.
|
||
|
||
Il possède :
|
||
|
||
```text
|
||
5 slots de livraison
|
||
```
|
||
|
||
Il affiche :
|
||
|
||
* état boutique
|
||
* mode de session
|
||
* commande active
|
||
* réputation
|
||
* récompense
|
||
* patience
|
||
* file
|
||
* catalogue
|
||
* spécialisations
|
||
* mode Vérification
|
||
|
||
Boutons :
|
||
|
||
```text
|
||
OPEN SHOP
|
||
CLOSE ARRIVALS
|
||
FORCE CLOSE
|
||
REFUSE ORDER
|
||
VERIFY SHOP
|
||
```
|
||
|
||
---
|
||
|
||
# 19. Écran de préparation de session
|
||
|
||
Le bouton OPEN SHOP ne doit plus immédiatement démarrer la boutique.
|
||
|
||
Flux :
|
||
|
||
```text
|
||
OPEN SHOP
|
||
↓
|
||
Validation boutique
|
||
↓
|
||
Écran préparation
|
||
↓
|
||
Choix STANDARD / CHILL
|
||
↓
|
||
Résumé session
|
||
↓
|
||
CONFIRM OPEN
|
||
```
|
||
|
||
---
|
||
|
||
# 20. Résumé avant ouverture
|
||
|
||
L’écran peut afficher :
|
||
|
||
```text
|
||
MODE
|
||
STANDARD
|
||
|
||
ZONE
|
||
✓ Valide
|
||
|
||
SPÉCIALITÉS
|
||
3 / 3
|
||
|
||
CATALOGUE
|
||
127 produits potentiels
|
||
|
||
STOCK
|
||
Mode : Snapshot haute réputation
|
||
|
||
RÉCOMPENSES
|
||
×1.00
|
||
|
||
RÉPUTATION
|
||
Active
|
||
|
||
[ CONFIRMER L'OUVERTURE ]
|
||
```
|
||
|
||
Pour CHILL :
|
||
|
||
```text
|
||
MODE
|
||
CHILL
|
||
|
||
STOCK
|
||
Mode : Quantités réelles
|
||
|
||
RÉCOMPENSES
|
||
×0.60
|
||
|
||
RÉPUTATION
|
||
Figée
|
||
```
|
||
|
||
---
|
||
|
||
# 21. Validation des objets au comptoir
|
||
|
||
Consommer uniquement les quantités nécessaires.
|
||
|
||
Commande :
|
||
|
||
```text
|
||
24 Stone
|
||
8 Torch
|
||
```
|
||
|
||
Inventaire :
|
||
|
||
```text
|
||
64 Stone
|
||
5 Torch
|
||
3 Torch
|
||
1 Diamond
|
||
```
|
||
|
||
Résultat :
|
||
|
||
```text
|
||
40 Stone
|
||
1 Diamond
|
||
```
|
||
|
||
Le système :
|
||
|
||
* fusionne plusieurs stacks logiquement ;
|
||
* consomme exactement les quantités demandées ;
|
||
* ignore les objets sans rapport ;
|
||
* vérifie la provenance.
|
||
|
||
Validation entièrement serveur.
|
||
|
||
---
|
||
|
||
# 22. Stockage de matières premières
|
||
|
||
Bloc spécifique.
|
||
|
||
Il accepte seulement les matières configurées.
|
||
|
||
Exemples :
|
||
|
||
```text
|
||
#minecraft:logs
|
||
minecraft:iron_ingot
|
||
minecraft:gold_ingot
|
||
minecraft:diamond
|
||
minecraft:redstone
|
||
```
|
||
|
||
Doit supporter :
|
||
|
||
* IDs Vanilla
|
||
* IDs moddées
|
||
* tags
|
||
|
||
D’autres joueurs peuvent approvisionner la boutique.
|
||
|
||
---
|
||
|
||
# 23. Zone de boutique
|
||
|
||
Deux marqueurs définissent les coins opposés d’un cuboïde.
|
||
|
||
Calcul :
|
||
|
||
```text
|
||
minX/maxX
|
||
minY/maxY
|
||
minZ/maxZ
|
||
```
|
||
|
||
Taille maximale configurable.
|
||
|
||
Exemple :
|
||
|
||
```text
|
||
32 × 32 × 16
|
||
```
|
||
|
||
---
|
||
|
||
# 24. ShopValidator
|
||
|
||
Créer :
|
||
|
||
```text
|
||
ShopValidator
|
||
```
|
||
|
||
Fonction conceptuelle :
|
||
|
||
```text
|
||
ShopValidationResult scan(Shop shop)
|
||
```
|
||
|
||
Résultat :
|
||
|
||
```text
|
||
zoneValid
|
||
zoneDimensions
|
||
|
||
counterInside
|
||
storageInside
|
||
|
||
entryValid
|
||
exitValid
|
||
|
||
incomingPathValid
|
||
outgoingPathValid
|
||
|
||
queuePositions
|
||
|
||
detectedStations
|
||
detectedStationFamilies
|
||
|
||
unsupportedStations
|
||
|
||
errors
|
||
warnings
|
||
```
|
||
|
||
---
|
||
|
||
# 25. Mode Vérification
|
||
|
||
Accessible depuis le comptoir.
|
||
|
||
Afficher :
|
||
|
||
* volume boutique
|
||
* marqueurs
|
||
* comptoir
|
||
* stockage
|
||
* stations
|
||
* familles
|
||
* chemins
|
||
* waypoints
|
||
* file
|
||
* entrée/sortie
|
||
* erreurs
|
||
* avertissements
|
||
|
||
Aucun vrai bloc n’est placé.
|
||
|
||
---
|
||
|
||
# 26. Rapport de vérification
|
||
|
||
Exemple :
|
||
|
||
```text
|
||
ZONE
|
||
21 × 14 × 8
|
||
|
||
✓ Zone valide
|
||
✓ Comptoir valide
|
||
✓ Stockage valide
|
||
|
||
|
||
STATIONS
|
||
|
||
CRAFTING
|
||
Crafting Table ×2
|
||
|
||
FORGE
|
||
Furnace ×3
|
||
Blast Furnace ×1
|
||
|
||
STONEWORKING
|
||
Stonecutter ×1
|
||
|
||
|
||
SPÉCIALISATIONS
|
||
|
||
3 / 3
|
||
|
||
|
||
CHEMINS
|
||
|
||
✓ Entrée → Comptoir
|
||
✓ Comptoir → Sortie
|
||
✓ 4 positions de file
|
||
|
||
|
||
WARNINGS
|
||
|
||
⚠ Machine inconnue :
|
||
othermod:custom_machine
|
||
```
|
||
|
||
---
|
||
|
||
# 27. Spécialisations
|
||
|
||
Limiter le nombre de familles de production et non le nombre de blocs.
|
||
|
||
Exemple :
|
||
|
||
```text
|
||
6 Furnaces
|
||
3 Blast Furnaces
|
||
2 Smithing Tables
|
||
```
|
||
|
||
peuvent appartenir à :
|
||
|
||
```text
|
||
FORGE
|
||
```
|
||
|
||
et compter pour une seule spécialité.
|
||
|
||
---
|
||
|
||
# 28. StationFamily
|
||
|
||
Concept générique extensible.
|
||
|
||
Exemples :
|
||
|
||
```text
|
||
CRAFTING
|
||
FORGE
|
||
COOKING
|
||
STONEWORKING
|
||
SMITHING
|
||
```
|
||
|
||
Mods futurs :
|
||
|
||
```text
|
||
MECHANICAL_PROCESSING
|
||
PRESSING
|
||
MILLING
|
||
WOODWORKING
|
||
ADVANCED_COOKING
|
||
```
|
||
|
||
---
|
||
|
||
# 29. Limite de spécialisation
|
||
|
||
Configuration serveur :
|
||
|
||
```text
|
||
station_type_limit_enabled = true
|
||
max_station_types_per_shop = 3
|
||
```
|
||
|
||
La limite appartient à la boutique, pas au mode CHILL/STANDARD.
|
||
|
||
Une session CHILL ne permet donc pas de contourner les spécialisations.
|
||
|
||
---
|
||
|
||
# 30. Framework de compatibilité mods
|
||
|
||
La V1 doit disposer d’un framework interne permettant d’enregistrer :
|
||
|
||
```text
|
||
RecipeProvider
|
||
StationProvider
|
||
ProductionHandler
|
||
StationFamilyProvider
|
||
```
|
||
|
||
Les systèmes centraux utilisent ces interfaces.
|
||
|
||
---
|
||
|
||
# 31. Règle de compatibilité fondamentale
|
||
|
||
Le cœur ne doit pas contenir de logique :
|
||
|
||
```text
|
||
if Farmer's Delight
|
||
if Create
|
||
if Mekanism
|
||
...
|
||
```
|
||
|
||
Préférer :
|
||
|
||
```text
|
||
Registry
|
||
↓
|
||
Providers
|
||
↓
|
||
Handlers
|
||
```
|
||
|
||
---
|
||
|
||
# 32. Niveaux de compatibilité
|
||
|
||
## Niveau 1 — Automatique
|
||
|
||
Nouvelles recettes utilisant un RecipeType déjà supporté.
|
||
|
||
Aucun code spécifique.
|
||
|
||
## Niveau 2 — Déclaratif
|
||
|
||
Nouvelle station simple.
|
||
|
||
Déclaration possible :
|
||
|
||
```text
|
||
block = modid:custom_table
|
||
family = CRAFTING
|
||
recipe_type = modid:crafting
|
||
```
|
||
|
||
## Niveau 3 — Adapter léger
|
||
|
||
Comportement particulier.
|
||
|
||
Créer un :
|
||
|
||
```text
|
||
ProductionHandler
|
||
```
|
||
|
||
## Niveau 4 — Intégration complète
|
||
|
||
Pour :
|
||
|
||
* machines multibloc
|
||
* fluides
|
||
* énergie
|
||
* automation complexe
|
||
* production continue
|
||
* chaînes mécaniques
|
||
|
||
---
|
||
|
||
# 33. RecipeProvider
|
||
|
||
Responsable de fournir une représentation commune des recettes.
|
||
|
||
Doit exposer conceptuellement :
|
||
|
||
```text
|
||
inputs
|
||
outputs
|
||
recipeType
|
||
requiredStationFamily
|
||
conditions
|
||
```
|
||
|
||
---
|
||
|
||
# 34. StationProvider
|
||
|
||
Responsable de déterminer :
|
||
|
||
```text
|
||
Est-ce une station ?
|
||
Quelle famille ?
|
||
Quels RecipeTypes ?
|
||
Quel ProductionHandler ?
|
||
```
|
||
|
||
---
|
||
|
||
# 35. ProductionHandler
|
||
|
||
Responsable de la production réelle.
|
||
|
||
Concept :
|
||
|
||
```text
|
||
canHandle(...)
|
||
detectProduction(...)
|
||
getProducedStacks(...)
|
||
getProductionContext(...)
|
||
```
|
||
|
||
---
|
||
|
||
# 36. Recettes et stations séparées
|
||
|
||
Un mod peut :
|
||
|
||
* ajouter des recettes sans station ;
|
||
* ajouter une station sans nouveau RecipeType ;
|
||
* réutiliser une station existante ;
|
||
* créer les deux.
|
||
|
||
Le framework doit traiter chaque cas séparément.
|
||
|
||
---
|
||
|
||
# 37. Farmer’s Delight
|
||
|
||
Farmer’s Delight est un test du framework, pas une exception architecturale.
|
||
|
||
Une intégration future pourra déclarer :
|
||
|
||
```text
|
||
Cooking Pot
|
||
Cutting Board
|
||
RecipeTypes associés
|
||
ProductionHandlers
|
||
StationFamilies
|
||
```
|
||
|
||
Les addons qui ajoutent simplement des recettes aux mêmes mécanismes doivent être reconnus autant que possible sans intégration supplémentaire.
|
||
|
||
---
|
||
|
||
# 38. Vanilla comme intégration
|
||
|
||
Même les mécaniques Vanilla doivent utiliser le framework.
|
||
|
||
Support V1 :
|
||
|
||
* crafting inventaire 2×2
|
||
* crafting table
|
||
* furnace
|
||
* blast furnace
|
||
* smoker
|
||
* stonecutter
|
||
* smithing table
|
||
* éventuellement campfire
|
||
|
||
Ainsi :
|
||
|
||
```text
|
||
Vanilla = première intégration
|
||
```
|
||
|
||
et non :
|
||
|
||
```text
|
||
Vanilla = logique codée directement dans le core
|
||
```
|
||
|
||
---
|
||
|
||
# 39. Recipe Resolver
|
||
|
||
Créer :
|
||
|
||
```text
|
||
RecipeResolver
|
||
```
|
||
|
||
Pipeline :
|
||
|
||
```text
|
||
Matières
|
||
↓
|
||
RecipeProviders
|
||
↓
|
||
Graphe de recettes
|
||
↓
|
||
Intermédiaires
|
||
↓
|
||
Produits réalisables
|
||
↓
|
||
Stations nécessaires
|
||
↓
|
||
Familles disponibles
|
||
↓
|
||
Blacklist
|
||
↓
|
||
Règles de session
|
||
↓
|
||
Pool de commandes
|
||
```
|
||
|
||
---
|
||
|
||
# 40. ShopGameplayRules et RecipeResolver
|
||
|
||
Le RecipeResolver détermine ce qui est théoriquement fabriquable.
|
||
|
||
Les règles de session déterminent ensuite comment utiliser cette information.
|
||
|
||
Exemple :
|
||
|
||
```text
|
||
RecipeResolver :
|
||
"Diamond Sword est fabriquable"
|
||
|
||
STANDARD haute réputation :
|
||
"Le type DIAMOND était présent au démarrage,
|
||
donc commande possible."
|
||
|
||
CHILL :
|
||
"Il faut également que les quantités disponibles
|
||
permettent raisonnablement cette commande."
|
||
```
|
||
|
||
---
|
||
|
||
# 41. Graphe de recettes
|
||
|
||
Gérer :
|
||
|
||
* dépendances récursives
|
||
* cycles
|
||
* recettes alternatives
|
||
* outputs multiples
|
||
* quantités
|
||
* intermédiaires
|
||
* station nécessaire
|
||
|
||
Exemple :
|
||
|
||
```text
|
||
Log → Planks → Sticks
|
||
+
|
||
Iron
|
||
↓
|
||
Iron Sword
|
||
```
|
||
|
||
---
|
||
|
||
# 42. Production Tracker
|
||
|
||
Créer :
|
||
|
||
```text
|
||
ShopProductionTracker
|
||
```
|
||
|
||
Responsabilités :
|
||
|
||
```text
|
||
identifier boutique
|
||
identifier session
|
||
identifier station
|
||
identifier producteur
|
||
marquer output
|
||
valider provenance
|
||
```
|
||
|
||
---
|
||
|
||
# 43. Provenance
|
||
|
||
Produit manufacturé :
|
||
|
||
```text
|
||
ShopProductionData
|
||
```
|
||
|
||
Exemple :
|
||
|
||
```text
|
||
shopId
|
||
sessionId
|
||
crafterUUID
|
||
productionHandlerId
|
||
stationFamilyId
|
||
craftedForShop
|
||
```
|
||
|
||
---
|
||
|
||
# 44. Matières premières externes
|
||
|
||
Autoriser :
|
||
|
||
```text
|
||
ami apporte Diamond
|
||
→ valide
|
||
```
|
||
|
||
---
|
||
|
||
# 45. Produits finis externes
|
||
|
||
Refuser comme produits de commande :
|
||
|
||
```text
|
||
ami apporte Diamond Sword
|
||
→ provenance invalide
|
||
```
|
||
|
||
Mais :
|
||
|
||
```text
|
||
ami apporte Diamond
|
||
↓
|
||
épée craftée dans la boutique
|
||
↓
|
||
provenance valide
|
||
```
|
||
|
||
---
|
||
|
||
# 46. Session et provenance
|
||
|
||
La provenance dépend également du :
|
||
|
||
```text
|
||
sessionId
|
||
```
|
||
|
||
Un objet produit lors d’une ancienne session ne doit pas automatiquement satisfaire une commande d’une nouvelle session.
|
||
|
||
Cela s’applique à STANDARD et CHILL.
|
||
|
||
---
|
||
|
||
# 47. Modes et anti-cheese
|
||
|
||
Le mode CHILL ne doit jamais désactiver :
|
||
|
||
```text
|
||
provenance
|
||
zone
|
||
spécialisation
|
||
validation de production
|
||
```
|
||
|
||
Sinon il pourrait servir à fabriquer facilement un stock d’objets valides pour STANDARD.
|
||
|
||
Les données de session empêchent ce problème.
|
||
|
||
---
|
||
|
||
# 48. Machines différées
|
||
|
||
Pour les machines comme les fours :
|
||
|
||
```text
|
||
ShopProductionContext
|
||
```
|
||
|
||
Exemple :
|
||
|
||
```text
|
||
shopId
|
||
sessionId
|
||
stationPosition
|
||
handlerId
|
||
startTime
|
||
```
|
||
|
||
---
|
||
|
||
# 49. États de boutique
|
||
|
||
## CLOSED
|
||
|
||
Pas de session active.
|
||
|
||
## OPEN
|
||
|
||
Nouveaux clients autorisés.
|
||
|
||
## ARRIVALS_CLOSED
|
||
|
||
Nouveaux clients bloqués.
|
||
|
||
Clients existants conservés.
|
||
|
||
## FORCE_CLOSED
|
||
|
||
Clients non servis expulsés.
|
||
|
||
En STANDARD :
|
||
|
||
```text
|
||
réputation -
|
||
```
|
||
|
||
En CHILL :
|
||
|
||
```text
|
||
réputation inchangée
|
||
```
|
||
|
||
---
|
||
|
||
# 50. Clients
|
||
|
||
Créer :
|
||
|
||
```text
|
||
ShopCustomer
|
||
```
|
||
|
||
Exemple :
|
||
|
||
```text
|
||
customerId
|
||
shopId
|
||
sessionId
|
||
currentOrder
|
||
state
|
||
queuePosition
|
||
patience
|
||
appearanceProfile
|
||
npcReference
|
||
```
|
||
|
||
États :
|
||
|
||
```text
|
||
SPAWNING
|
||
WALKING_TO_QUEUE
|
||
WAITING_IN_QUEUE
|
||
WALKING_TO_COUNTER
|
||
ORDER_ACTIVE
|
||
SERVED
|
||
REFUSED
|
||
TIMEOUT
|
||
LEAVING
|
||
DESPAWNED
|
||
```
|
||
|
||
---
|
||
|
||
# 51. Easy NPC
|
||
|
||
Créer :
|
||
|
||
```text
|
||
integration/easynpc/
|
||
```
|
||
|
||
Exemples :
|
||
|
||
```text
|
||
EasyNpcAdapter
|
||
EasyNpcCustomerFactory
|
||
EasyNpcDialogueController
|
||
EasyNpcNavigationController
|
||
EasyNpcAppearanceController
|
||
```
|
||
|
||
---
|
||
|
||
# 52. Apparence des clients
|
||
|
||
Créer :
|
||
|
||
```text
|
||
CustomerAppearanceProfile
|
||
```
|
||
|
||
Pouvant contenir :
|
||
|
||
```text
|
||
model
|
||
skin
|
||
displayName
|
||
visual settings
|
||
```
|
||
|
||
Utiliser les modèles et possibilités disponibles dans Easy NPC.
|
||
|
||
Ne pas limiter arbitrairement aux Villagers/Illagers.
|
||
|
||
---
|
||
|
||
# 53. Entrée / sortie
|
||
|
||
Bloc dédié servant au :
|
||
|
||
```text
|
||
spawn
|
||
retour
|
||
despawn
|
||
```
|
||
|
||
V1 : un même point peut être utilisé pour entrée et sortie.
|
||
|
||
---
|
||
|
||
# 54. Chemins
|
||
|
||
Deux couleurs de tapis.
|
||
|
||
Exemple :
|
||
|
||
```text
|
||
Bleu :
|
||
entrée → comptoir
|
||
|
||
Rouge :
|
||
comptoir → sortie
|
||
```
|
||
|
||
Créer :
|
||
|
||
```text
|
||
ShopPathManager
|
||
```
|
||
|
||
---
|
||
|
||
# 55. Navigation
|
||
|
||
Séparation :
|
||
|
||
```text
|
||
ShopPathManager
|
||
↓
|
||
Waypoint
|
||
↓
|
||
NpcNavigationAdapter
|
||
↓
|
||
Easy NPC
|
||
```
|
||
|
||
Le ShopPathManager décide où aller.
|
||
|
||
Easy NPC gère le déplacement physique.
|
||
|
||
---
|
||
|
||
# 56. File d’attente
|
||
|
||
Positions dérivées du chemin entrant.
|
||
|
||
```text
|
||
COMPTOIR
|
||
↑
|
||
Client 1
|
||
↑
|
||
Client 2
|
||
↑
|
||
Client 3
|
||
↑
|
||
Entrée
|
||
```
|
||
|
||
La capacité effective peut dépendre de :
|
||
|
||
```text
|
||
capacité physique
|
||
+
|
||
ShopGameplayRules
|
||
```
|
||
|
||
---
|
||
|
||
# 57. Patience
|
||
|
||
STANDARD :
|
||
|
||
la patience évolue éventuellement avec la progression/difficulté.
|
||
|
||
CHILL :
|
||
|
||
patience généralement plus généreuse.
|
||
|
||
Dans les deux modes :
|
||
|
||
la patience principale commence lorsque la commande devient active.
|
||
|
||
---
|
||
|
||
# 58. Résultats de commande
|
||
|
||
```text
|
||
SUCCESS
|
||
REFUSED
|
||
TIMEOUT
|
||
FORCE_CLOSE
|
||
```
|
||
|
||
Ils sont identiques dans les deux modes.
|
||
|
||
Ce sont leurs conséquences qui changent.
|
||
|
||
---
|
||
|
||
# 59. Politique STANDARD
|
||
|
||
Exemple :
|
||
|
||
```text
|
||
SUCCESS
|
||
→ récompense normale
|
||
→ réputation +
|
||
|
||
REFUSED
|
||
→ aucune récompense
|
||
→ petite réputation -
|
||
|
||
TIMEOUT
|
||
→ aucune récompense
|
||
→ réputation -
|
||
|
||
FORCE_CLOSE
|
||
→ aucune récompense
|
||
→ forte réputation -
|
||
```
|
||
|
||
---
|
||
|
||
# 60. Politique CHILL
|
||
|
||
```text
|
||
SUCCESS
|
||
→ récompense réduite
|
||
→ réputation 0
|
||
|
||
REFUSED
|
||
→ aucune récompense
|
||
→ réputation 0
|
||
|
||
TIMEOUT
|
||
→ aucune récompense
|
||
→ réputation 0
|
||
|
||
FORCE_CLOSE
|
||
→ aucune récompense
|
||
→ réputation 0
|
||
```
|
||
|
||
Les clients repartent normalement.
|
||
|
||
Le gameplay reste cohérent sans conséquence persistante.
|
||
|
||
---
|
||
|
||
# 61. Réputation
|
||
|
||
Liée au propriétaire.
|
||
|
||
Échelle proposée :
|
||
|
||
```text
|
||
0 → 1000
|
||
```
|
||
|
||
En STANDARD, elle influence :
|
||
|
||
* difficulté
|
||
* fréquence
|
||
* quantité
|
||
* valeur
|
||
* file
|
||
* comportement stock
|
||
|
||
En CHILL :
|
||
|
||
elle ne change pas et n’est pas utilisée comme principal moteur de difficulté.
|
||
|
||
---
|
||
|
||
# 62. Rang
|
||
|
||
Exemple possible :
|
||
|
||
```text
|
||
0–99 Inconnu
|
||
100–249 Petit commerçant
|
||
250–449 Marchand
|
||
450–699 Commerçant réputé
|
||
700–899 Marchand renommé
|
||
900–1000 Fournisseur royal
|
||
```
|
||
|
||
Les seuils restent configurables.
|
||
|
||
---
|
||
|
||
# 63. Monnaie
|
||
|
||
Utiliser :
|
||
|
||
```text
|
||
minecraft:emerald
|
||
```
|
||
|
||
Récompense calculée selon :
|
||
|
||
* objet
|
||
* quantité
|
||
* complexité
|
||
* chaîne de production
|
||
* éventuellement réputation
|
||
* multiplicateur du mode
|
||
|
||
---
|
||
|
||
# 64. Blacklist produits
|
||
|
||
Configuration serveur.
|
||
|
||
Support Vanilla et moddé.
|
||
|
||
```text
|
||
product_blacklist
|
||
```
|
||
|
||
---
|
||
|
||
# 65. Whitelist matières
|
||
|
||
Support :
|
||
|
||
* IDs
|
||
* tags
|
||
* objets moddées
|
||
|
||
Exemple :
|
||
|
||
```text
|
||
#minecraft:logs
|
||
minecraft:iron_ingot
|
||
farmersdelight:tomato
|
||
some_mod:raw_material
|
||
```
|
||
|
||
---
|
||
|
||
# 66. Configuration serveur
|
||
|
||
Les valeurs d’équilibrage restent configurables.
|
||
|
||
Exemples :
|
||
|
||
```text
|
||
max_shop_size
|
||
|
||
material_whitelist
|
||
product_blacklist
|
||
|
||
max_reputation
|
||
|
||
standard_reputation_rewards
|
||
standard_reputation_penalties
|
||
|
||
standard_spawn_rate
|
||
standard_queue_limits
|
||
|
||
chill_reward_multiplier
|
||
chill_spawn_rate
|
||
chill_queue_limit
|
||
chill_patience_multiplier
|
||
|
||
order_quantity_limits
|
||
|
||
station_type_limit_enabled
|
||
max_station_types_per_shop
|
||
|
||
enabled_station_families
|
||
enabled_production_handlers
|
||
|
||
inspection_mode_enabled
|
||
```
|
||
|
||
La configuration serveur définit les règles générales.
|
||
|
||
Mais **le joueur choisit STANDARD ou CHILL à chaque ouverture**.
|
||
|
||
---
|
||
|
||
# 67. Compatibilité et modes
|
||
|
||
Les compatibilités de production doivent être complètement indépendantes du mode.
|
||
|
||
Exemple :
|
||
|
||
```text
|
||
Farmer's Delight Cooking Pot
|
||
```
|
||
|
||
peut être utilisé en :
|
||
|
||
```text
|
||
STANDARD
|
||
ou
|
||
CHILL
|
||
```
|
||
|
||
sans handler spécifique au mode.
|
||
|
||
Le handler décrit la production.
|
||
|
||
`ShopGameplayRules` décrit les règles de session.
|
||
|
||
---
|
||
|
||
# 68. Performances
|
||
|
||
Ne pas scanner la zone à chaque tick.
|
||
|
||
Scanner :
|
||
|
||
* lors de VERIFY
|
||
* lors de OPEN SHOP
|
||
* lorsque la structure devient invalide
|
||
* éventuellement après changement pertinent
|
||
|
||
Mettre en cache :
|
||
|
||
```text
|
||
ShopValidationResult
|
||
```
|
||
|
||
---
|
||
|
||
# 69. Cache des recettes
|
||
|
||
Mettre en cache le graphe en fonction notamment de :
|
||
|
||
```text
|
||
RecipeProviders
|
||
stations disponibles
|
||
familles
|
||
whitelist
|
||
blacklist
|
||
```
|
||
|
||
Puis appliquer les règles de session par-dessus.
|
||
|
||
Cela évite de reconstruire tout le graphe simplement parce que le joueur passe de STANDARD à CHILL.
|
||
|
||
---
|
||
|
||
# 70. Persistance
|
||
|
||
Persistant :
|
||
|
||
```text
|
||
Shop
|
||
owner
|
||
zone
|
||
markers
|
||
counter
|
||
storage
|
||
paths
|
||
reputation
|
||
configuration structurelle
|
||
```
|
||
|
||
Session :
|
||
|
||
```text
|
||
sessionId
|
||
gameplayMode
|
||
state
|
||
snapshot
|
||
activeProductPool
|
||
customers
|
||
orders
|
||
```
|
||
|
||
---
|
||
|
||
# 71. Redémarrage serveur
|
||
|
||
Décider une stratégie robuste.
|
||
|
||
Deux possibilités futures :
|
||
|
||
```text
|
||
reprendre session
|
||
```
|
||
|
||
ou :
|
||
|
||
```text
|
||
fermer proprement session au redémarrage
|
||
```
|
||
|
||
Mais dans tous les cas, le mode de session doit être persisté si la session est restaurée.
|
||
|
||
---
|
||
|
||
# 72. Multijoueur
|
||
|
||
V1 :
|
||
|
||
* d’autres joueurs peuvent approvisionner en matières premières ;
|
||
* les produits finis externes restent invalides.
|
||
|
||
Prévoir futur :
|
||
|
||
```text
|
||
OWNER
|
||
ASSISTANT
|
||
OUTSIDER
|
||
```
|
||
|
||
---
|
||
|
||
# 73. Structure de code indicative
|
||
|
||
```text
|
||
shop/
|
||
├── core/
|
||
│ ├── ShopManager
|
||
│ ├── Shop
|
||
│ ├── ShopSession
|
||
│ ├── ShopState
|
||
│ └── ShopGameplayMode
|
||
│
|
||
├── gameplay/
|
||
│ ├── ShopGameplayRules
|
||
│ ├── StandardGameplayRules
|
||
│ └── ChillGameplayRules
|
||
│
|
||
├── validation/
|
||
│ ├── ShopValidator
|
||
│ └── ShopValidationResult
|
||
│
|
||
├── recipe/
|
||
│ ├── RecipeResolver
|
||
│ ├── RecipeProvider
|
||
│ └── RecipeGraph
|
||
│
|
||
├── production/
|
||
│ ├── ShopProductionTracker
|
||
│ ├── ProductionHandler
|
||
│ ├── ProductionContext
|
||
│ └── ShopProductionData
|
||
│
|
||
├── station/
|
||
│ ├── ShopStationRegistry
|
||
│ ├── StationProvider
|
||
│ ├── StationDefinition
|
||
│ └── StationFamily
|
||
│
|
||
├── customer/
|
||
│ ├── CustomerManager
|
||
│ ├── ShopCustomer
|
||
│ └── CustomerAppearanceProfile
|
||
│
|
||
├── path/
|
||
│ ├── ShopPathManager
|
||
│ └── QueueManager
|
||
│
|
||
├── integration/
|
||
│ └── easynpc/
|
||
│
|
||
└── compat/
|
||
├── vanilla/
|
||
├── farmersdelight/
|
||
├── create/
|
||
└── ...
|
||
```
|
||
|
||
---
|
||
|
||
# 74. Ordre de développement
|
||
|
||
## Phase 1 — Setup
|
||
|
||
* NeoForge
|
||
* Easy NPC
|
||
* registries
|
||
* config
|
||
* données joueur
|
||
|
||
## Phase 2 — Core boutique
|
||
|
||
* Shop
|
||
* comptoir
|
||
* stockage
|
||
* markers
|
||
* zone
|
||
* ShopSession
|
||
|
||
## Phase 3 — Gameplay Modes
|
||
|
||
Créer très tôt :
|
||
|
||
```text
|
||
ShopGameplayMode
|
||
ShopGameplayRules
|
||
StandardGameplayRules
|
||
ChillGameplayRules
|
||
```
|
||
|
||
Ainsi les systèmes suivants ne coderont jamais directement les règles STANDARD.
|
||
|
||
## Phase 4 — Compatibility Framework
|
||
|
||
Créer :
|
||
|
||
```text
|
||
RecipeProvider
|
||
StationProvider
|
||
ProductionHandler
|
||
StationFamily
|
||
ShopStationRegistry
|
||
```
|
||
|
||
## Phase 5 — Vanilla Integration
|
||
|
||
Implémenter Vanilla via le framework.
|
||
|
||
## Phase 6 — ShopValidator / Inspection
|
||
|
||
* scan zone
|
||
* stations
|
||
* familles
|
||
* overlay
|
||
* chemins
|
||
* erreurs
|
||
|
||
## Phase 7 — Spécialisations
|
||
|
||
* limites
|
||
* validation
|
||
* configuration
|
||
|
||
## Phase 8 — Recipe Resolver
|
||
|
||
* graphe
|
||
* providers
|
||
* capacités boutique
|
||
* blacklist
|
||
* politiques de stock
|
||
|
||
## Phase 9 — Écran d’ouverture
|
||
|
||
Créer :
|
||
|
||
```text
|
||
OPEN SHOP
|
||
↓
|
||
validation
|
||
↓
|
||
sélection STANDARD / CHILL
|
||
↓
|
||
preview
|
||
↓
|
||
création ShopSession
|
||
```
|
||
|
||
## Phase 10 — Orders
|
||
|
||
* génération
|
||
* quantités
|
||
* validation
|
||
* récompenses
|
||
* règles STANDARD/CHILL
|
||
|
||
## Phase 11 — Production Tracking
|
||
|
||
* provenance
|
||
* handlers
|
||
* sessions
|
||
* stations Vanilla
|
||
|
||
## Phase 12 — Easy NPC
|
||
|
||
* spawn
|
||
* apparences
|
||
* dialogues
|
||
* navigation
|
||
* despawn
|
||
|
||
## Phase 13 — Paths / Queue
|
||
|
||
* tapis
|
||
* waypoints
|
||
* file
|
||
|
||
## Phase 14 — Réputation
|
||
|
||
* progression STANDARD
|
||
* rangs
|
||
* seuils
|
||
* stock haute réputation
|
||
* neutralisation complète en CHILL
|
||
|
||
## Phase 15 — GUI finale
|
||
|
||
* dashboard
|
||
* commandes
|
||
* mode courant
|
||
* diagnostic
|
||
* réputation
|
||
* catalogue
|
||
|
||
## Phase 16 — Première compatibilité moddée
|
||
|
||
Farmer’s Delight est un bon candidat.
|
||
|
||
Le test doit vérifier que :
|
||
|
||
```text
|
||
nouvelles recettes
|
||
nouvelles stations
|
||
nouveaux handlers
|
||
```
|
||
|
||
peuvent être ajoutés sans modifier le cœur.
|
||
|
||
## Phase 17 — Robustesse
|
||
|
||
Tester STANDARD et CHILL séparément ainsi que les transitions entre sessions.
|
||
|
||
---
|
||
|
||
# 75. Tests spécifiques des modes
|
||
|
||
Tester :
|
||
|
||
```text
|
||
ouvrir STANDARD
|
||
fermer
|
||
ouvrir CHILL
|
||
|
||
ouvrir CHILL
|
||
fermer
|
||
ouvrir STANDARD
|
||
```
|
||
|
||
Vérifier qu’aucun état ne fuit d’une session vers l’autre.
|
||
|
||
---
|
||
|
||
# 76. Tests réputation
|
||
|
||
Cas :
|
||
|
||
```text
|
||
Rep = 500
|
||
↓
|
||
ouvrir CHILL
|
||
↓
|
||
10 succès
|
||
3 refus
|
||
2 timeouts
|
||
↓
|
||
fermer
|
||
```
|
||
|
||
Résultat obligatoire :
|
||
|
||
```text
|
||
Rep = 500
|
||
```
|
||
|
||
Puis :
|
||
|
||
```text
|
||
ouvrir STANDARD
|
||
```
|
||
|
||
La progression reprend normalement à 500.
|
||
|
||
---
|
||
|
||
# 77. Tests provenance entre modes
|
||
|
||
Exemple :
|
||
|
||
```text
|
||
Session CHILL A
|
||
→ fabrication Iron Sword
|
||
→ session terminée
|
||
|
||
Session STANDARD B
|
||
→ ancienne Iron Sword utilisée
|
||
```
|
||
|
||
Elle ne doit pas être valide simplement parce qu’elle a été produite dans la même boutique.
|
||
|
||
Le `sessionId` doit empêcher ce contournement.
|
||
|
||
---
|
||
|
||
# 78. Tests ouverture de session
|
||
|
||
Avant création de la session :
|
||
|
||
```text
|
||
validation structurelle
|
||
validation stations
|
||
validation spécialisation
|
||
validation chemins
|
||
```
|
||
|
||
Puis seulement :
|
||
|
||
```text
|
||
choix mode
|
||
création sessionId
|
||
snapshot/catalogue
|
||
spawn clients
|
||
```
|
||
|
||
---
|
||
|
||
# 79. Critère de réussite de la séparation Shop / Session
|
||
|
||
Le joueur doit pouvoir :
|
||
|
||
```text
|
||
construire UNE boutique
|
||
```
|
||
|
||
puis jouer :
|
||
|
||
```text
|
||
Session 1 : STANDARD
|
||
Session 2 : STANDARD
|
||
Session 3 : CHILL
|
||
Session 4 : STANDARD
|
||
```
|
||
|
||
sans :
|
||
|
||
* reconstruire
|
||
* déplacer les stations
|
||
* refaire les chemins
|
||
* recréer le stockage
|
||
* changer une configuration serveur
|
||
|
||
---
|
||
|
||
# 80. Critère de réussite du framework moddé
|
||
|
||
Ajouter une nouvelle station doit idéalement demander seulement :
|
||
|
||
```text
|
||
StationProvider
|
||
RecipeProvider
|
||
ProductionHandler
|
||
StationFamily
|
||
```
|
||
|
||
et ne nécessiter aucune modification de :
|
||
|
||
```text
|
||
ShopManager
|
||
ShopValidator
|
||
OrderGenerator
|
||
ShopGameplayRules
|
||
```
|
||
|
||
---
|
||
|
||
# 81. Critère de réussite du mode CHILL
|
||
|
||
CHILL ne doit pas être :
|
||
|
||
```text
|
||
"STANDARD mais sans réputation"
|
||
```
|
||
|
||
Il doit réellement être une expérience moins stressante.
|
||
|
||
Donc :
|
||
|
||
```text
|
||
récompenses plus faibles
|
||
commandes plus sûres
|
||
stock réel
|
||
patience supérieure
|
||
fréquence raisonnable
|
||
file raisonnable
|
||
```
|
||
|
||
tout en conservant :
|
||
|
||
```text
|
||
production
|
||
spécialisation
|
||
logistique
|
||
clients
|
||
commandes
|
||
provenance
|
||
```
|
||
|
||
---
|
||
|
||
# 82. Philosophie globale
|
||
|
||
La boutique définit :
|
||
|
||
```text
|
||
CE QUE JE PEUX PRODUIRE
|
||
```
|
||
|
||
La session définit :
|
||
|
||
```text
|
||
COMMENT JE VEUX JOUER AUJOURD'HUI
|
||
```
|
||
|
||
STANDARD signifie :
|
||
|
||
```text
|
||
progression
|
||
risque
|
||
récompense
|
||
gestion
|
||
réputation
|
||
```
|
||
|
||
CHILL signifie :
|
||
|
||
```text
|
||
production
|
||
ambiance
|
||
clients
|
||
organisation
|
||
sans pression persistante
|
||
```
|
||
|
||
Les deux utilisent exactement la même boutique.
|
||
|
||
---
|
||
|
||
# 83. Résumé architectural final
|
||
|
||
```text
|
||
SHOP
|
||
│
|
||
├── Structure physique
|
||
├── Stations
|
||
├── Stockage
|
||
├── Paths
|
||
└── Spécialisations
|
||
│
|
||
▼
|
||
OPEN SHOP
|
||
│
|
||
▼
|
||
Choix du GameplayMode
|
||
│
|
||
┌───┴────┐
|
||
│ │
|
||
STANDARD CHILL
|
||
│ │
|
||
└───┬────┘
|
||
│
|
||
▼
|
||
ShopSession
|
||
│
|
||
├── RecipeResolver
|
||
├── OrderGenerator
|
||
├── Customers
|
||
├── ProductionTracker
|
||
└── Rewards
|
||
```
|
||
|
||
---
|
||
|
||
# 84. Principe final à transmettre à Codex
|
||
|
||
Le mod doit distinguer strictement :
|
||
|
||
```text
|
||
SHOP
|
||
= infrastructure persistante
|
||
|
||
SESSION
|
||
= une ouverture de boutique
|
||
|
||
GAMEPLAY MODE
|
||
= règles appliquées à cette session
|
||
```
|
||
|
||
Le joueur choisit `STANDARD` ou `CHILL` à chaque création de `ShopSession`.
|
||
|
||
Ce choix :
|
||
|
||
* ne modifie pas la boutique ;
|
||
* ne nécessite aucune reconfiguration ;
|
||
* ne peut pas être changé pendant une session ;
|
||
* n’affecte pas la compatibilité des stations ;
|
||
* n’affecte pas les règles de provenance ;
|
||
* modifie les récompenses, la réputation et certains paramètres de difficulté.
|
||
|
||
Le système doit utiliser une abstraction `ShopGameplayRules` plutôt que des conditions dispersées dans le code.
|
||
|
||
Enfin, le cœur reste conçu comme un framework générique de boutique et de production moddée :
|
||
|
||
```text
|
||
Recipes
|
||
Stations
|
||
Production
|
||
Gameplay Rules
|
||
Shop
|
||
NPC
|
||
```
|
||
|
||
restent des systèmes séparés et extensibles.
|