BIG EGG · Plan du donjon · Pour décision
Le donjon passe d'un lieu à une progression. Ce que ça impose à la sauvegarde, comment se construit une salle, et le grand cycle des mondes.
Le point structurant
Ton cycle de mondes introduit une durée de vie que le projet n'a pas encore. Aujourd'hui il n'y a que « la partie ». Il en faut trois, et elles doivent être nettes avant qu'on construise quoi que ce soit — parce qu'elles décident du format de sauvegarde.
| Portée | Contient | Effacée quand | Existe déjà ? |
|---|---|---|---|
runune plongée |
Salle courante, bonus choisis en récompense, butin en cours | Au retour au restaurant, quelle qu'en soit la raison | Racine créée, jamais vidée en fin de plongée |
worldun monde |
Upgrades générales, pièces, ingrédients, avancement du restaurant | À la victoire sur le boss final du monde | n'existe pas |
metala sauvegarde |
Upgrades spéciales, numéro de monde, contenu débloqué | Jamais | Racine créée, inutilisée |
purchased_upgrades est aujourd'hui une seule liste plate. Le passage à un monde suivant doit en effacer une partie et en garder une autre. Il faut donc que chaque nœud déclare sa portée — un champ scope valant world ou meta suffit, et il se règle dans l'outil comme n'importe quel autre champ.
Sans ce champ, la remise à zéro du cycle devient une liste d'exceptions codées en dur, qui se désynchronisera de l'arbre à la première upgrade ajoutée.
Le reste tombe tout seul : la remise à zéro d'un monde efface run, remet les upgrades de portée world, et laisse meta intact. Une seule opération, sur un ensemble défini par les données.
L'unité de jeu
Aujourd'hui spawn_count est une quantité fixe par monstre : la vague contient exactement ce que les fiches demandent. Ton modèle est différent — la salle a un budget de créatures, et chaque monstre a un poids qui décide de sa probabilité d'être tiré.
// aujourd'hui: quantité imposée
chicken_beast.spawn_count = 7 → 7 chicken_beast, toujours
// visé: poids relatif
chicken_beast.spawn_weight = 7 → 7 chances sur (somme des poids)
salle.budget = 12 → 12 tiragesC'est ce qui rend l'idée d'objet possible : « cet item fait apparaître plus de gobelins » devient un modificateur sur le poids, pas une règle spéciale. Et le poids étant une donnée d'entité, il est déjà adressable.
Le nombre initial et les renforts sont deux statistiques distinctes, donc toutes deux améliorables et modifiables par un biome :
room_spawn_initial — combien la salle contient à l'ouvertureroom_spawn_reinforcement — combien arrivent encore pendant le combatUne salle est « nettoyée » quand le budget total est épuisé et qu'aucun monstre ne reste. La porte s'ouvre à ce moment.
Entre deux salles, un choix parmi quelques bonus. C'est exactement ce pour quoi la source run: du pool de modificateurs a été prévue : un bonus choisi est un modificateur de source run:, et la fin de la plongée le retire d'un seul appel — rien à nettoyer à la main, rien qui puisse survivre par accident.
Sortie
| Fin | Butin | État actuel du code |
|---|---|---|
| Stamina épuisée | Conservé intégralement | déjà en place |
| Mis hors service | Perdu, sauf le pourcentage couvert par l'assurance | la perte fonctionne déjà (restore_ingredient_inventory) ; l'assurance reste à faire |
| Boss final du monde | Conservé, plus l'upgrade spéciale | à construire |
L'assurance est une statistique, pas un drapeau : insurance_rate à 0 par défaut, qu'une upgrade monte à 0,25 puis 0,5. Même raisonnement que le four autonome — une question de degré se règle par un nombre, jamais par un booléen.
Le retour au restaurant est toujours la même destination, donc la même scène et le même chemin de code. L'animation du joueur qui repart vers la gauche est une couche visuelle par-dessus, pas une variante de logique.
La boucle longue
plongées → boss du monde → récit → upgrade spéciale
→ monde suivant (upgrades générales remises à zéro)
→ nouveau monstre + nouvelle salle spéciale + nouveau biome
→ ... × 4 ou 5 → dernier biome, vrai boss finalLe point important : le contenu qui apparaît à chaque cycle n'est pas du code. Un monde déclare quels monstres, quels biomes et quels types de salles sont disponibles ; passer au monde suivant, c'est incrémenter meta.world_index et laisser les données décider du reste.
Un biome, dans ce modèle, est une simple table : la liste des monstres autorisés et leurs poids, plus les modificateurs qu'il applique à la salle. Il ne contient aucune logique.
Ne pas dupliquer les données par monde. Un monde sélectionne et pondère du contenu existant ; il ne le recopie pas. Sinon cinq mondes veulent dire cinq fois la maintenance, et un rééquilibrage à faire cinq fois.
Exécution
Chaque phase est jouable et testable seule. Sauvegarde datée avant chacune, suite complète au vert avant la suivante.
Champ scope sur les nœuds d'upgrade, run vidé en fin de plongée, opération de passage de monde. Aucun changement visible en jeu — c'est le socle.
spawn_count devient spawn_weight, tirage pondéré, budget de salle piloté par une statistique. La vague actuelle continue de fonctionner, avec une composition variable.
Compteur de créatures, porte qui s'ouvre au nettoyage, passage à la salle suivante, run.room_index. La plongée devient une suite au lieu d'un lieu.
Seconde vague pendant le combat, avec sa propre statistique.
Choix entre salles, bonus posés comme modificateurs de source run:.
insurance_rate, upgrade correspondante, unification des trois sorties.
Collection biomes, types de salles, salle de boss en fin de parcours.
meta.world_index, récit de fin de monde, upgrades spéciales, contenu qui se débloque par cycle.
À trancher
Tu as dit « toutes les upgrades générales ». La question est ce qui les accompagne.
Pourquoi A. C'est ce qui donne un sens au recommencement : sans remise à zéro de l'économie, le deuxième monde se termine en quelques minutes et les cycles suivants n'ont plus d'enjeu. Et un restaurant plus beau au monde 2 se lit mieux si on le rebâtit.
Pourquoi A. Zéro duplication d'outillage, et les upgrades spéciales peuvent conditionner des nœuds normaux sans mécanisme supplémentaire. Rien n'empêche de les afficher à part plus tard : c'est une question de présentation, pas de structure.
La stamina et la mort ont leurs sorties. Mais quand le joueur enchaîne les salles, qu'est-ce qui l'arrête ?
Pourquoi A. C'est ce qui fait vivre la stamina : pousser une salle de plus contre le risque de tout perdre. Avec B, la stamina n'est qu'une limite technique.
Pourquoi A. Aujourd'hui la plongée ne rapporte que des ingrédients ; les pièces viennent du restaurant. B n'aurait d'effet que si le donjon se met à donner des pièces — décision à prendre à ce moment-là, pas maintenant.
Tu parles de quatre ou cinq cycles et d'un « plus beau restaurant ». Est-ce une nouvelle scène par monde, ou la même scène avec une palette et des décors différents ?
Ce que ça change. Une variante visuelle par monde tient dans les données. Une scène par monde veut dire dupliquer la logique du restaurant, ce que je déconseillerais fortement.
Ta réponse
E1 remise à zéro du monde : A (A = tout l'avancement · B = arbre seulement)
E2 upgrades spéciales : A (A = même arbre + scope · B = arbre séparé)
E3 fin de plongée : A (A = le joueur choisit · B = N salles fixes)
E4 assurance : A (A = ingrédients · B = ingrédients + pièces)
E5 mondes : ? (nombre visé · variante visuelle ou scène séparée)Avec tout en A, j'attaque les phases 1 à 3 : portées de persistance, apparition pondérée, salle et porte. C'est le point où le donjon devient une progression, et c'est testable de bout en bout.