4NK/cursor
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
785868b53b1d7d494a280bb1202941b5260125c3
cursor/builazoo/plan-rappel-grandes-regles.md
Nicolas Cantu 785868b53b Initial: desk + ncantu placeholder + per-project cursor configs 
**Motivations:**
- Centraliser les fichiers Cursor (rules, skills, agents, commands, hooks) par user et par projet

**Root causes:**
- N/A

**Correctifs:**
- N/A

**Evolutions:**
- desk: rules, skills-cursor, agents, commands, hooks, argv/hooks/mcp.json
- ncantu: README placeholder
- 4NK_node, algo, builazoo, ia_local, lecoffre_ng, lecoffre_ng_pprod, lecoffre_ng_test: .cursor contents

**Pages affectées:**
- cursor/desk/, cursor/ncantu/, cursor/<project>/
2026-03-03 23:29:29 +01:00

12 KiB
Raw Blame History

Plan Cursor – Rappel des grandes règles (174-324)

Exécution dans l’ordre : Phase 0 → 1 → 3 → 4 → 2 → 5 → 6 → 7 → 8 → 9 → 10 → 11 → 12 → 13. Référence détaillée : docs/plan-implementation-rappel-grandes-regles.md.

PHASE 0 – Modèle de données et configuration

FILES: web/js/types.js | web/js/config.js | web/js/state.js | web/js/loot-tables.js

STEPS:

  1. types.js – Ajouter/étendre :
    • biome?: string et temperature?: number sur les cases (ou sur la grille par case).
    • Nouveaux kinds de cell : research, billeterie, food, reception, biomeChangeColor, biomeChangeTemp. Garder souvenirShop (alias boutique), nursery, camion reste zone/state.
    • Types pour bébé/vente : PendingBaby, ReceptionAnimal, SaleListing (babyId/animalId, zooId, price, endAt, reproductionScoreAtSale?).
    • Animal multi-case : sur AnimalCell ajouter originKey?: string, cellsWide?: number, cellsHigh?: number (optionnel, défaut 1).
    • GameState : researchPoints?: number, pendingBabies?: PendingBaby[], receptionAnimals?: ReceptionAnimal[], saleListings?: SaleListing[], deathCountRecent?: number, birthCount?: number, feedingRate?: number.
  2. config.js – Ajouter blocs (tous MaxLevel: 7 sauf si indiqué) :
    • Research: { MaxLevel: 7, ZoosPerUnit: 10, BaseUpgradeCost, UpgradeGrowth, PointsPerTickPerLevel }
    • Billeterie: { MaxLevel: 7, VisitorsPerUnit: 20, BaseUpgradeCost, UpgradeGrowth }
    • Food: { MaxLevel: 7, AnimalsPerUnit: 5, BaseUpgradeCost, UpgradeGrowth }
    • Reception: { MaxLevel: 7, AnimalsPerUnit: 1, BaseUpgradeCost, UpgradeGrowth, AcclimatationSecondsBase }
    • BiomeChangeColor: { MaxLevel: 7, BaseUpgradeCost, UpgradeGrowth }
    • BiomeChangeTemp: { MaxLevel: 7, BaseUpgradeCost, UpgradeGrowth }
    • Mettre Nursery.MaxLevel = 7, SouvenirShop.MaxLevel = 7, Truck.MaxLevel = 7.
  3. state.js – Dans defaultState() : researchPoints: 0, pendingBabies: [], receptionAnimals: [], saleListings: [], deathCountRecent: 0, birthCount: 0. Prévoir cellules initiales pour recherche, billeterie, nourriture, accueil (voir phase 12 pour positions exactes).
  4. loot-tables.js – Pour chaque animal : cellsWide: 1, cellsHigh: 1 (extensible en 2x2 plus tard), idealTemperature?: number, temperatureTolerance?: number, reproductionScoreByBiome?: Record<string,number>, survivalScoreByBiome?: Record<string,number>.

DONE_WHEN: Types compilent, config lue, defaultState contient les nouveaux champs, loot-tables exporte les champs animaux. Pas de régression sur le jeu actuel (ancien state reste valide).

PHASE 1 – Cartes : couleurs et températures

FILES: web/js/biome-rules.js | web/js/grid-utils.js | web/css/main.css | web/js/ui.js

STEPS:

  1. Étendre biomes : eau douce, eau salée, montagne, prairie, forêt (au moins 5). Attribuer à chaque case un biome et un temperature (dérivés de la position ou stockés).
  2. Exporter getDisplayBiome(x, y, grid) et getDisplayTemperature(x, y, grid) avec interpolation des voisins.
  3. Rendu CSS : classes ou variables par biome et par plage de température ; dégradés entre cases.
  4. Grille zoo et monde utilisent ces fonctions pour le fond des cases.

DONE_WHEN: Les cases affichent une couleur/milieu et une température avec transition douce.

PHASE 3 – Bâtiments zoo (7 niveaux)

FILES: web/js/config.js | web/js/state.js | web/js/economy.js | web/js/placement.js | web/js/zoo.js | web/js/ui.js

STEPS:

  1. Coûts d’upgrade pour research, billeterie, food, reception, biomeChangeColor, biomeChangeTemp (formules exponentielle comme Plot).
  2. Placement : construction sur case vide pour research, billeterie, food, reception, biomeChangeColor, biomeChangeTemp. Upgrade sur clic comme aujourd’hui pour nursery/souvenirShop.
  3. Recherche : tick produit researchPoints (formule par niveau des cells research). Agrandissement carte consomme researchPoints (phase 9).
  4. Billeterie / Boutique : capacités (visiteurs/unité) utilisées en phase 8.
  5. UI : icônes et libellés pour chaque type de bâtiment ; affichage niveau et flèche upgrade si possible.

DONE_WHEN: Tous les bâtiments sont constructibles et upgradeables à 7 niveaux ; recherche produit des points.

PHASE 4 – Bébés et flux (remplacement œufs)

FILES: web/js/state.js | web/js/zoo.js | web/js/placement.js | web/js/hatching.js | web/js/conveyor.js | web/js/ui.js | web/js/world-map.js

STEPS:

  1. Remplacer pendingEggTokens / œufs par pendingBabies (bébé en croissance en nurserie) et offres = bébés ou animaux adultes.
  2. Nurserie : slot avec bébé en croissance ; durée selon niveau nurserie ; à la fin état « bébé mature » déplaçable (case zoo → animal, ou camion → vente).
  3. Accueil : animal acheté/reçu va en receptionAnimals ; durée acclimatation ; à la fin « animal prêt » déplaçable (case zoo ou camion).
  4. Conveyor/offres : générer offres de bébés et d’animaux (pas d’œufs). Achat envoie en nurserie (bébé) ou en accueil (animal).
  5. UI : afficher bébé mature / animal prêt ; glisser vers case vide ou camion.

DONE_WHEN: Plus d’œufs ; achat bébé/animal → nurserie/accueil → mature/prêt → placement ou vente.

PHASE 2 – Animaux multi-cases

FILES: web/js/loot-tables.js | web/js/placement.js | web/js/grid-utils.js | web/js/ui.js | web/js/state.js

STEPS:

  1. Définir cellsWide, cellsHigh dans loot-tables (par défaut 1).
  2. Placement : vérifier que toutes les cases (originKey + largeur/hauteur) sont vides et dans les limites.
  3. Stockage : une entrée par case avec référence à l’origine (originKey) ou une entité avec originKey + dimensions.
  4. Suppression / déplacement : libérer ou déplacer tout le bloc.
  5. UI : dessiner l’animal sur plusieurs cases ; drag déplace le bloc.

DONE_WHEN: Au moins un type d’animal 2x2 (ou 1x2) placeable et déplaçable.

PHASE 5 – Nourriture, consommation, morts

FILES: web/js/config.js | web/js/state.js | web/js/food.js (new) | web/js/game-loop.js | web/js/animal-visits.js | web/js/loot-tables.js

STEPS:

  1. Module food.js : par tick, calculer consommation totale ; capacité nourriture = sum(food buildings × AnimalsPerUnit) ; répartir ; animaux non nourris reçoivent un déficit ou timer.
  2. Mort si pas nourri au-delà d’un seuil ; retirer de la grille ; incrémenter deathCountRecent.
  3. Implémenter toutes les autres causes de mort (seul, pas visité, recherche trop basse, bébé non vendu à temps, bébé mature non placé à temps, animal accueil non placé à temps, vente échouée, température/milieu en écart). Appeler une fonction checkDeathCauses(state, nowUnix) dans la game loop.
  4. loot-tables : température idéale et tolérances par animal.

DONE_WHEN: Les animaux non nourris meurent ; les autres causes de mort sont branchées (même si certaines règles sont simplifiées au début).

PHASE 6 – Reproduction

FILES: web/js/loot-tables.js | web/js/reproduction.js (new) | web/js/state.js | web/js/game-loop.js

STEPS:

  1. Détecter paires d’animaux même type, origine « autre zoo » pour au moins un, en proximité (adjacent ou distance N).
  2. Timer par paire ou par animal ; à l’échéance créer un bébé → nurserie si place, sinon en vente. Utiliser score de reproduction du zoo et adéquation température/milieu pour réduire le délai.
  3. Exposer score de reproduction par milieu et survie par milieu depuis loot-tables.

DONE_WHEN: Une paire admissible peut produire un bébé après un délai ; le bébé va en nurserie ou en vente.

PHASE 7 – Score de reproduction du zoo

FILES: web/js/state.js | web/js/food.js | web/js/reproduction.js | web/js/trade.js | web/js/world-map.js

STEPS:

  1. birthCount incrémenté à chaque naissance ; feedingRate = ratio nourris/total (ou fenêtre glissante).
  2. Formule score agrégé = f(birthCount, feedingRate, …). Exposer dans state et sur la carte du monde (case sous le nom du zoo).
  3. À la vente, attacher reproductionScoreAtSale à l’entité vendue (pour phase 6 côté acheteur).

DONE_WHEN: Score de reproduction affiché ; vendu porte le score du zoo vendeur.

PHASE 8 – Attractivité et visiteurs

FILES: web/js/income.js | web/js/visitor-attraction.js | web/js/config.js | web/js/state.js | web/js/ui.js | web/js/world-map.js

STEPS:

  1. Entrée visiteurs uniquement via billeterie ; cap = Billeterie.VisitorsPerUnit × niveau total billeterie.
  2. Durée max 1 journée par visiteur ; sortie par billeterie. Temps passé prolongé par boutiques et diversité animaux.
  3. Formule attractivité : valeur cumulée, nombre d’espèces, rareté, taux remplissage ; pénalités morts ; bonus naissances.
  4. Affichage score d’attractivité sous le nom du zoo sur la carte du monde.

DONE_WHEN: Visiteurs plafonnés par billeterie ; attractivité calculée et affichée.

PHASE 9 – Carte du monde (recherche + compteurs)

FILES: web/js/state.js | web/js/economy.js | web/js/world-map.js | web/js/ui.js | web/js/config.js

STEPS:

  1. Agrandissement carte payé en researchPoints (pas en pièces). Coût par palier en unités de recherche. Bouton grisé si pas assez.
  2. Compteurs : bébés à vendre, animaux à vendre, laboratoires, zoos, villes (affichage sur la carte ou barre).
  3. Case zoo : nom, score attractivité, score reproduction, case de vente (phase 10).

DONE_WHEN: Agrandissement carte consomme researchPoints ; compteurs affichés.

PHASE 10 – Ventes et enchères

FILES: web/js/state.js | web/js/trade.js | web/js/world-map.js | web/js/ui.js | server/routes/zoos.js ou server/routes/trades.js | server/db.js

STEPS:

  1. Cases de vente sous chaque zoo sur la carte du monde ; afficher bébé ou animal à vendre + dernier montant enchère.
  2. Depuis le zoo : glisser bébé mature ou animal sur le camion → création d’une entrée saleListings (zoo du joueur).
  3. API enchères : créer/consulter offres, enchérir, valider/refuser vente par le vendeur. Si délai dépassé sans vente validée pour un bébé → mort du bébé.
  4. Vente validée : acheteur reçoit bébé (nurserie) ou animal (accueil) ; reproductionScoreAtSale attaché.

DONE_WHEN: Mise en vente depuis le zoo ; enchères joueurs/bots ; validation vendeur ; bébé invendu meurt.

PHASE 11 – Villes

FILES: web/js/config.js | web/js/world-map.js | web/js/income.js | web/js/ui.js

STEPS:

  1. Chaque ville : 1 case nom, 1 case « nombre max visiteurs vers zoos ». Config ou state.
  2. Répartir ou limiter les visiteurs vers les zoos selon ce plafond et l’attractivité.

DONE_WHEN: Villes affichent le max visiteurs ; la règle limite ou répartit les visiteurs.

PHASE 12 – UI et grilles au lancement

FILES: web/js/state.js | web/js/ui.js | web/js/world-map.js | web/css/main.css

STEPS:

  1. Grille zoo au lancement : 1 agrandissement, 1 recherche, 1 billeterie, 1 nurserie, 1 accueil, 1 nourriture, 1 camion, 24 cases 3 couleurs. Positions fixes dans defaultState().
  2. Grille monde au lancement : 1 agrandissement carte (recherche), compteurs, 1 accueil, 1 nourriture, 1 camion, 24 cases 3 couleurs.
  3. Transitions douces visibles (phase 1). Actions : achat sur case vide (tous les types), déplacement bébé mature / animal prêt. Accessibilité ARIA/clavier/contraste.

DONE_WHEN: Les deux grilles de lancement sont conformes au cahier ; toutes les actions sont accessibles.

PHASE 13 – Migration et compatibilité

FILES: web/js/state.js | server/routes/zoos.js

STEPS:

  1. specVersion ou version dans game_state (ex. 1 = ancien œufs/école, 2 = rappel grandes règles).
  2. Au load : si version 1, soit migration (œufs → bébés, école → research niv 1, etc.), soit message « sauvegarde incompatible ».
  3. API accepte game_state étendu (JSONB) sans casser les anciens champs.

DONE_WHEN: Anciennes sauvegardes migrées ou refusées proprement ; nouvelles sauvegardes complètes.

Reference in New Issue View Git Blame Copy Permalink