Refonte des variables globales

Quelle portée pour le premier chantier ?

Le plan complet fait sept phases. Rien n'oblige à tout faire d'un coup.

// éditable dans l'outil, sans une ligne de GDScript
{ "path": "element.enemies.fungling.total_killed",
  "op": ">=", "value": 100 }

Pourquoi A. Tu valides l'ergonomie de l'adressage — celle que tu utiliseras tous les jours dans l'outil — avant d'engager le calcul des stats, qui est la partie où une erreur se voit le moins et coûte le plus. Les phases suivantes restent ouvertes et ne redemandent aucun travail jeté.

La couche override tout de suite, ou trois couches pour commencer ?

override est le seul vrai facteur multiplicatif : il s'applique isolément au lieu de se cumuler avec les autres.

1 effet  : (1 + 1)     = ×2  ✓
2 effets : (1 + 1 + 1) = ×3

1 effet  : ×2       = ×2
2 effets : ×2 × ×2  = ×4  ✓

Pourquoi A. Aucun effet de ton jeu n'en a besoin aujourd'hui, et ajouter la couche plus tard ne casse rien : c'est un champ supplémentaire, les données existantes restent valides sans migration. C'est une décision réversible à bas coût — autant ne pas la payer maintenant.

Quel empilement par défaut pour un effet réappliqué ?

Trois fungling empoisonnent le joueur. Poison : 3 dégâts/seconde par pile, maximum 3 piles.

stack_key = "poison"

stack_key = "poison@enemy:1234"

Pourquoi A. C'est le seul des deux où max_stacks garantit réellement un plafond de dégâts — donc le seul équilibrable. B reste disponible effet par effet quand tu le veux explicitement.

Cette liste de champs vivants te convient-elle ?

Fournis automatiquement pour toutes les entités d'une collection, sans rien déclarer.

Faible enjeu. Ajouter un champ plus tard, c'est une ligne dans le catalogue. Ne bloque pas sur cette liste — dis-moi juste s'il en manque un que tu sais déjà vouloir.

Recalcul global, ou invalidation fine par chemin ?

Pourquoi A. C'est le cas où la bonne pratique générale n'est pas la bonne application : à cette échelle, B n'apporte aucun gain mesurable et ajoute des abonnements fantômes et des ordres de mise à jour subtils. Et comme Registry.write() est le point de passage unique, B reste greffable plus tard sans rien réécrire.

Confirmes-tu la forme des adresses ?

Ton exemple disait element.monsters.id.variable. En gardant les noms du fichier maître, ça donne :

// ton exemple
element.monsters.turkey_clown.total_killed

// ce que ça devient réellement
element.enemies.turkey_clown.total_killed

Pourquoi confirmer. Ce préfixe sera tapé dans chaque condition et chaque effet, pour toujours. Si tu préfères entity. ou data. à element., c'est maintenant — après, c'est une migration de toutes les données.

L'équipement est-il prévu, et à quelle échéance ?

Il n'existe aucun système d'arme ou d'équipement dans le jeu aujourd'hui. J'ai proposé que l'équipement soit une source dérivée — lue en direct depuis l'emplacement équipé, jamais stockée dans la table.

Aujourd'hui, la seule source dérivée est upgrade:. Je construis quand même l'interface de fournisseur — elle coûte presque rien — mais je ne construis pas d'équipement tant que tu ne le demandes pas.

Ce que ça change. Si l'équipement arrive bientôt, je dimensionne l'interface pour plusieurs emplacements dès la phase 5. Sinon, un fournisseur unique suffit.

Comment fusionner statistics et fact_values ?

Aujourd'hui le même compteur est écrit dans deux dictionnaires, et load_game() contient de la logique de réconciliation. La phase 2 les fusionne. Si ta sauvegarde actuelle a divergé entre les deux, il faut une règle.

Pourquoi A. Cohérence avec ce qui était affiché. En pratique les deux valeurs sont presque toujours identiques — c'est une règle de sûreté, pas un cas courant.