Aller au contenu
Blog
Technique20 octobre 2026

La dette qui dormait dans un mot de 64 bits

J'ai réservé de la place pour 192 technologies et, sans le voir, plafonné mon arbre à 64. La limite ne plante rien: elle attend, tranquille, le jour où le jeu deviendra assez riche pour la heurter.

Une contradiction qui dort dans le code

J'ai donné à mon arbre de technologies de la place pour cent quatre-vingt-douze inventions. Sans le vouloir, dans le même fichier, à quelques lignes d'écart, je l'ai plafonné à soixante-quatre. Des mois durant, ni l'une ni l'autre n'a fait de bruit. C'est le genre de contradiction qui dort dans le code: correcte aujourd'hui, fatale le jour où l'on s'en approche.

L'arbre qui semblait sans limite

Dans Limon, chaque peuple accumule des savoirs: le foyer, le cuivre natif, l'agriculture intensive. Chaque savoir porte un identifiant, un simple numéro. Un peuple qui maîtrise une techno, c'est un interrupteur allumé quelque part.

Pour ranger tous ces interrupteurs, j'utilise un bitset: une longue rangée de cases oui/non, une par techno, tassées dans des nombres entiers. Un entier de 64 bits (un int64, un nombre stocké sur 64 chiffres binaires) tient 64 cases. J'en réserve trois par peuple, soit 192 cases. J'avais vu large: 192 technos possibles, très au-delà des 25 que le jeu compte aujourd'hui.

Et tout ce qui manipule un savoir joue le jeu des 192. Vérifier qu'un peuple connaît une techno, la lui apprendre, la transmettre à un peuple-fille, l'intégrer à l'empreinte qui identifie un monde: chacune de ces opérations sait lire les trois cases. Le stockage, lui, compte bien jusqu'à 192.

Ranger des prérequis dans un seul nombre

Un arbre de technologies, c'est surtout des prérequis: pour le cuivre natif, il faut d'abord le foyer. J'encode ces dépendances dans un masque de bits: pour chaque techno, un nombre dont chaque bit allumé désigne une techno requise.

Un exemple tiré du code: la techno numéro 15 a pour masque la valeur 384. Or 384, c'est 256 plus 128, autrement dit le bit numéro 8 et le bit numéro 7. Traduction: pour débloquer la 15, il faut déjà connaître les technos 7 et 8. C'est élégant. Plusieurs prérequis logés dans un seul nombre, et vérifier qu'un peuple les remplit tous se fait en une seule opération (un ET binaire, qui ne garde que les bits allumés des deux côtés).

Sauf que ce masque de prérequis, lui, est un unique int64. Un seul mot machine, le morceau de mémoire que le processeur manipule d'un bloc, ici 64 bits. Donc 64 cases, pas une de plus. Donc un prérequis ne peut désigner qu'une techno numérotée de 0 à 63.

Le plafond qu'on ne voit pas en codant la tech 10

Le stockage sait compter jusqu'à 192. Le raisonnement, lui, s'arrête à 64.

La fonction qui choisit ce qu'un peuple peut apprendre ensuite ne lit qu'un seul mot: le premier, les cases 0 à 63. Elle le compare au masque de prérequis, et rien d'autre. Les deux autres mots, les technos 64 à 191 que le stockage gère pourtant sans broncher, n'existent tout bonnement pas pour la logique de déblocage.

Conséquence: une techno numérotée au-delà de 63 peut être connue, transmise, comptée dans les hauts faits d'un peuple. Mais elle ne pourra jamais servir de prérequis, et le moteur ne verra jamais qu'un peuple la possède au moment de choisir la suivante. La branche est là, bien rangée, et invisible.

Aujourd'hui, j'ai 25 technos. Le mur est à 64. Je ne l'ai pas encore touché, et c'est tout le piège. En codant la techno 10, tout marche. À la 20, tout marche. Ce n'est qu'en approchant la soixantaine, quand une invention profonde réclamera pour prérequis une autre invention déjà profonde, que le masque n'aura plus de case libre pour la nommer.

Le plafond ne prévient pas. Il se contente d'être là depuis le début.

Pourquoi c'est une dette, pas un bug

Un bug, ça plante. Ça se voit, ça se corrige sous la pression. Ma limite à 64 ne fait rien planter. Le code est correct, les 25 technos tournent parfaitement, l'empreinte de référence reste stable.

C'est exactement ce qui en fait une dette: un choix ancien, raisonnable sur le moment (un seul mot, c'est simple, c'est rapide, ça tient dans une comparaison), qui facture ses intérêts bien plus tard, et au pire moment. Le jour où l'arbre deviendra riche, c'est-à-dire le jour où le jeu deviendra vraiment intéressant sur cet axe, le sol se dérobera.

Le pire, c'est la fausse sécurité. Un commentaire du code annonce fièrement "jusqu'a 192 techs". Le stockage tient la promesse, à la lettre. Un futur moi, ou quelqu'un d'autre, lira ce 192 et le croira. Il n'ira pas vérifier que la logique de prérequis, elle, plafonne trois fois plus bas.

La dette vit dans le type, pas dans la fonction

La dette technique qu'on redoute d'habitude, c'est le code moche qu'on n'a pas eu le temps de nettoyer. La vraie, la sournoise, est ailleurs: dans une structure de données qui décide, en silence, de la taille maximale de ce qu'on pourra bâtir dessus. Elle ne se lit pas dans une fonction, elle se lit dans un type. Un int64 au lieu d'un vrai tableau, et voilà un arbre de technologies plafonné à vie, sans qu'une seule ligne ne le dise à voix haute.

Je n'ai pas corrigé. À 25 technos, ce serait de l'optimisation prématurée, et j'ai d'autres murs plus proches. Mais je sais désormais où est celui-là, et à quelle distance.

C'est déjà mieux que de le découvrir en lui rentrant dedans.