# 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.