Un studio avec un économiste du jeu dédié règle la difficulté à plusieurs, avec des données de télémétrie à grande échelle et des sessions de playtest organisées. Un développeur solo règle la difficulté seul, un soir, en fixant un nombre dans une feuille de calcul en se demandant si ce nombre va rendre le jeu injuste ou ennuyeux — et sans être vraiment sûr de le savoir avant que quelqu'un d'autre y joue.

J'ai deux jeux en ligne en ce moment, AbcDonjon et Cendrelune, et ils m'ont posé deux problèmes d'équilibrage presque opposés. Voici comment je les ai traités, avec les mêmes outils limités : un tableur, mon propre jugement biaisé, et une communauté de beta-testeurs.

Deux jeux, deux définitions de « juste »

Dans AbcDonjon, l'équilibrage se joue à l'échelle d'une run de quelques minutes. La question est : est-ce que ce combat, avec ces lettres, contre cet ennemi, est gérable pour un joueur qui joue bien ? Une seule variable trop généreuse — un multiplicateur de dégâts élémentaire, un stock d'indices trop large — et chaque run devient une formalité. Trop stricte, et une seule définition mal connue transforme la partie en mur infranchissable.

Dans Cendrelune, l'échelle change complètement. L'équilibrage se joue sur des semaines : est-ce que la courbe de coûts des améliorations reste satisfaisante à la dixième heure de jeu, à la cinquantième ? Un idle game ne se juge pas sur un combat, il se juge sur un rythme. Le problème n'est plus « ce moment est-il juste » mais « cette progression reste-t-elle désirable longtemps après que la nouveauté soit passée ».

Ce sont deux métiers différents qui portent le même nom. Et je dois les faire tous les deux, seul.

Le tableur avant le moteur de jeu

La première règle que je me suis imposée : ne jamais régler une courbe de difficulté directement dans le code. Tout passe d'abord par un tableur, parce qu'un tableur permet de voir vingt paliers d'un coup, alors que le jeu ne montre qu'un palier à la fois.

Pour AbcDonjon, chaque étage a un budget de dégâts théorique : les PV de l'ennemi divisés par les dégâts moyens attendus d'un mot de longueur médiane, avec ou sans bonus élémentaire. Si ce budget descend sous trois ou quatre mots pour vaincre l'ennemi, le combat devient un coup de dés plutôt qu'un puzzle. Le tableur me permet de voir tout de suite qu'un multiplicateur élémentaire de x2 rend n'importe quel avantage tactique écrasant, alors que x1.6 laisse une marge où le joueur doit encore résoudre correctement plusieurs mots.

Pour Cendrelune, le tableur modélise le ratio coût/production de chaque palier de bâtiment, avec un objectif de temps avant la prochaine amélioration : quelques minutes en tout début de jeu, environ une heure en milieu de partie, plusieurs heures en fin de partie — calé sur le plafond d'accumulation hors-ligne de 12 heures dont je parlais dans l'article sur la boucle de rétention. Un ratio géométrique mal calibré crée un mur de grind précisément au palier où le joueur devrait sentir que le jeu accélère.

« Un système peut être juste sur le papier et injuste à l'usage. L'écart entre les deux, c'est tout le travail d'équilibrage. »

Le biais que je ne peux pas corriger seul

Le problème du développeur solo n'est pas le manque d'outils, c'est le manque de recul. Après des dizaines d'heures passées à concevoir un système, je ne peux plus le juger comme un joueur neuf. Je connais la faiblesse élémentaire de chaque ennemi avant même de voir la grille. Je sais quel bâtiment de Cendrelune améliorer en priorité parce que j'ai construit la courbe moi-même. Ma perception de la difficulté est structurellement faussée, dans un sens que je ne peux pas mesurer de l'intérieur.

C'est un problème qu'aucun tableur ne résout. Il faut un regard extérieur — et c'est là que la communauté de beta-testeurs, dont je parlais dans un précédent article, devient un outil d'équilibrage à part entière, pas seulement un outil de détection de bugs.

Ce qu'un sondage d'un soir a changé

Le format qui fonctionne le mieux avec les testeurs n'est pas la discussion ouverte, c'est le sondage à une question. « La difficulté de la zone 3 est trop élevée / correcte / trop basse » recueille en une soirée un signal que des semaines de commentaires libres n'auraient jamais produit aussi clairement.

Sur AbcDonjon, un de ces sondages a révélé qu'une majorité de testeurs jugeait un palier « trop élevé » alors que mon tableur le donnait comme équilibré. En creusant, le problème n'était pas le budget de dégâts en lui-même, mais le fait que les joueurs manquaient d'indices au moment précis où ils en auraient eu besoin — une variable adjacente que je n'avais pas modélisée. Le sondage n'a pas donné la solution, il a pointé le bon problème. Charge à moi de trouver l'ajustement : augmenter légèrement le stock d'indices de base plutôt que de toucher aux dégâts.

C'est la limite qu'il faut respecter avec ce type de signal : un testeur qui dit « c'est trop dur » identifie presque toujours un vrai problème. Le même testeur qui propose une solution précise a un avis, pas un diagnostic.

Changer une variable à la fois

La discipline la plus difficile à tenir en solo, c'est de résister à l'envie de tout corriger d'un coup après un retour négatif. Baisser les PV d'un ennemi et augmenter le nombre d'indices et ajuster le multiplicateur élémentaire dans la même mise à jour rend impossible de savoir, la fois suivante, quel changement a réellement eu un effet.

Je tiens depuis peu un changelog d'équilibrage séparé du changelog de version : chaque ajustement numérique, sa date, et le retour qui l'a motivé. Ce n'est pas glamour, mais c'est la seule façon de ne pas répéter les mêmes hésitations d'une version à l'autre.

Ce qui ne se règle jamais complètement

Aucune des deux courbes — celle d'AbcDonjon, celle de Cendrelune — n'est « terminée ». De nouveaux étages, de nouveaux bâtiments, de nouvelles reliques déplacent l'équilibre à chaque mise à jour. L'équilibrage n'est pas une étape du développement qu'on coche une fois : c'est un entretien permanent, au même titre que la correction de bugs.

La différence avec un studio qui a une équipe dédiée n'est pas dans la rigueur qu'on peut y mettre — un tableur bien tenu et une communauté qui répond honnêtement valent largement une session de playtest encadrée. La différence est dans le temps : ce que je fais en un soir par semaine, une équipe le ferait en continu. Ça ralentit tout. Mais ça reste faisable, seul.