Comment créer des mécanismes de jeu fiables dans Excel. 2e partie

Dans cette partie, nous allons résoudre le problème du placement optimal des armes sur le char, la disposition spatiale des téléporteurs en MMORPG et équilibrer les batailles des quatre classes de personnages RPG.

Tâches de placement d'objets

Les feuilles de calcul pour cette partie peuvent être téléchargées ici: ( SuperTank ) ( téléporteurs, partie 1 ) ( téléporteurs, partie 2 )

SuperTank: le problème est résolu!

Dans le premier article de la série, nous avons parlé d'un exemple de tâche pour un jeu appelé SuperTank. Dans la deuxième partie, nous nous sommes familiarisés avec les concepts de base de la modélisation décisionnelle et j'ai parlé de résoudre un exemple simple en utilisant l'outil "Rechercher des solutions" dans Excel.

Nous pouvons maintenant appliquer les connaissances acquises dans la deuxième partie au problème du SuperTank et prouver qu'avec leur aide, ce problème peut être résolu facilement et rapidement. Rafraîchissez votre mémoire: SuperTank est un jeu dans lequel vous pouvez vous battre sur un tank personnalisé. Le supertank ressemble à ceci:


Chaque supertank peut avoir n'importe quel nombre d'armes à feu de cinq types différents:


Un supertank peut contenir 50 tonnes d'armes et un joueur peut dépenser 100 crédits. En outre, le supertank dispose de 3 «emplacements critiques», dans lesquels des pistolets spéciaux tels que MegaRocket et UltraLaser sont placés.

La feuille de calcul de cet exemple peut être téléchargée ici .

L'objectif est de ramasser des armes qui maximisent les dégâts causés par le super tank, sans dépasser les limites de 50 tonnes, 100 crédits et 3 emplacements critiques. Nous supposons également que ce tableau contient toutes les informations nécessaires et que des facteurs tels que la portée, la fréquence et la précision ne sont pas pertinents ou sont déjà pris en compte dans le paramètre Dégâts de l'arme correspondante.

Pour optimiser ce schéma, nous saisissons d'abord ces données dans la feuille de calcul. Juste en dessous, nous ajouterons un autre tableau, dans lequel il y aura un ensemble de 5 cellules «quantitatives» pour indiquer la quantité de chacun des 5 types d'armes.

Jusqu'à ce que nous entrions une valeur de 1 dans ces cellules, juste pour tester leur travail, mais ce seront nos cellules de décision - nous demanderons à l'outil Solveur de trouver les valeurs correctes pour ces cellules. Il est possible de comprendre que ce sont des cellules de décision en jaune, car nous continuons de suivre les règles de mise en forme décrites dans la deuxième partie. À droite des cellules «quantitatives», nous ajouterons des cellules de calcul qui multiplieront les valeurs de quantité dans les cellules de décision par les valeurs de dommages, poids, coût et emplacements critiques du tableau ci-dessus. Ainsi, chaque ligne de ce tableau affichera correctement les dégâts, le poids, le prix et les emplacements critiques requis pour toutes les armes utilisées dans toutes les catégories d'armes.


Nous allons également créer une section ci-dessous, qui résumera toutes les valeurs de quantité, de poids, de coût et de créneaux critiques du tableau ci-dessus, et les comparera avec les valeurs maximales de poids, de coût et de créneaux critiques spécifiées dans les conditions de la tâche (50, 100 et 3, respectivement).


Conformément aux règles de mise en forme de la deuxième partie de l'article, les cellules bleues en haut sont les critères des conditions du problème. Les cellules grises sont des cellules de calcul qui représentent le poids total, le coût et les emplacements critiques en fonction de la somme du tableau des quantités (c'est-à-dire les valeurs totales des colonnes Poids x Quantité, Coût x Quantité et Emplacements critiques x Quantité). Enfin, la cellule orange représente le total des dégâts de notre super tank reçus sur la base du total des dégâts de la colonne Damage x Quantity du tableau ci-dessus.

Avant de commencer, rendons notre feuille de calcul plus conviviale. Nous profiterons de l'occasion d'Excel pour attribuer un nom à chaque cellule et donner des noms clairs à sept cellules dans le dernier tableau de calcul. C'est facultatif, mais à long terme, cela rendra la feuille de calcul beaucoup plus claire (par exemple, si au lieu de $ F $ 21 la cellule sera appelée MaxCriticalSlots). Pour ce faire, il suffit de sélectionner une cellule et d'aller dans le champ de saisie du nom à gauche du champ de formule, puis de saisir un nouveau nom.


Enfin, allons dans Excel Solver et trouvons une solution (allez sur le côté droit de l'onglet Données et sélectionnez Solver. Si vous ne le voyez pas, allez dans Options Excel , sélectionnez la catégorie Compléments ("Modules complémentaires"), assurez-vous que les Compléments Excel sont sélectionnés dans la liste déroulante "Gérer", cliquez sur Aller ("Aller ...") et assurez-vous que La case Complément Solveur est cochée.

Dans le champ Définir l'objectif («Optimiser la fonction objectif»), nous sélectionnerons la cellule orange de la cible, puis cliquez sur le bouton radio Max («Maximum»). Dans le champ En modifiant les cellules variables, sélectionnez les cellules de décision (cellules jaunes dans la colonne Quantité du deuxième tableau). Ci-dessous, cliquez sur le bouton Ajouter pour ajouter les restrictions suivantes:

• Les valeurs des cellules de décision doivent être comprises entre 0 et un maximum raisonnable (nous avons choisi 50, même s'il s'agit probablement d'une valeur limite beaucoup plus élevée que nécessaire). Il est également nécessaire de définir chaque cellule de solution sur une restriction "= entier", car nous ne pouvons pas avoir une partie fractionnaire de l'armement, et Excel Solver considère que chaque variable est un nombre réel par défaut, sauf indication contraire.

• Nous devons également limiter les valeurs du coût total, du poids total et du nombre total d'emplacements critiques aux valeurs des conditions du problème. L'image de la boîte de dialogue montre qu'ils ont maintenant des noms pratiques que nous avons ajoutés au tableau inférieur, ce qui facilite la lecture de la boîte de dialogue.

Maintenant, nous cliquons sur le bouton Résoudre («Trouver une solution») et après une courte attente, le solveur remplira les valeurs de quantité, ce qui nous donnera ce qui suit:

• 1 mitrailleuse
• 3 fusées
• 2 MegaRockets
• 1 laser
• 1 UltraLaser

Tout cela nous donne un total de dégâts de 83 unités et prend exactement 50 tonnes, 100 crédits et 3 emplacements critiques. Vous pouvez voir que la meilleure solution ne change pas avec l'exécution du solveur. Si vous réinitialisez ces valeurs et effectuez une seconde optimisation, ou allez dans Options et modifiez la valeur de départ, nous obtiendrons toujours les mêmes valeurs. Nous ne pouvons pas être sûrs à 100% que cette solution est optimale, mais compte tenu du fait que Solver n'a pas réussi à l'améliorer après plusieurs passes d'optimisation, il est très probable qu'il s'agit d'un réel optimum, et pas seulement d'un maximum local.

Le problème est résolu!

Utilisations supplémentaires

Ce qui est cool, c'est que non seulement nous avons résolu le problème beaucoup plus rapidement que nous ne pouvions le traiter manuellement, mais aussi que nous l'avons configuré de manière à ce qu'il nous permette de tester quelles armes dans le jeu SuperTank seront les plus utiles avec différents paramètres (poids, coût, emplacements critiques). Cela signifie que nous pouvons changer relativement facilement l'effet de divers changements de ces paramètres sur le jeu SuperTank, et si nous voulons ajouter un nouveau modèle alternatif de super tank qui sera plus léger, plus lourd ou aura un nombre différent d'emplacements critiques, alors cela peut être fait très simplement.

En modifiant tous ces paramètres, nous pouvons également comprendre l'utilité relative de chacune de ces armes et déterminer rapidement laquelle est trop utile, pas assez utile, a un prix qui ne convient pas à son poids et à ses dégâts, etc.

Encore une fois, le fait est qu'un tel outil nous permet de rechercher l'espace de conception beaucoup plus rapidement que nous ne pourrions le faire manuellement. Cela nous offre une opportunité pratique d'évaluer l'effet de ces changements pour toute décision de conception incrémentielle que nous pouvons prendre, que ce soit en changeant les paramètres de l'arme ou du super tank lui-même, en ajoutant de nouvelles armes ou des modèles de super tanks, ainsi qu'en ajoutant de nouveaux paramètres (disons que la taille limite est en mètres cubes).

Pour comprendre ce que je veux dire, accédez à la cellule bleue «Coût maximal» et modifiez sa valeur de 100 à 99. Exécutez à nouveau Solver et vous obtiendrez une disposition d'arme complètement différente:

• 0 mitrailleuses
• 2 fusées
• 3 MegaRockets
• 3 lasers
• 0 UltraLasers

Un tel schéma donne un indice de dommage légèrement inférieur (82 au lieu de 83), mais il est radicalement différent du précédent.

Si vous définissez la valeur du coût maximal sur 101 ou 102 et effectuez à nouveau le calcul, il est possible que nous obtenions une configuration similaire à la première ou coïncidant avec elle; Quoi qu'il en soit, les dommages resteront égaux à 83 (les régimes peuvent changer, car dans de tels cas, il existe plusieurs régimes optimaux). Cependant, si vous définissez Coût maximum sur 103, vous devriez obtenir les éléments suivants:

• 1 mitrailleuse
• 4 fusées
• 2 MegaRockets
• 0 lasers
• 1 UltraLaser

Ce qui augmente le total des dégâts à 84.

C'est intéressant: cet arrangement d'armes est très différent des deux premiers.


Comme vous pouvez le voir, nous obtenons un résultat inattendu: le choix optimal des armes dans notre schéma dépend fortement des paramètres du super tank et peut varier considérablement même avec de petits changements dans ces paramètres. De plus, cela nous donne toutes sortes d'informations utiles: les cinq types d'armes sont utiles dans au moins deux des trois paramètres de super tank, et les fusées et les méga-poches sont évidemment utiles dans les trois. Il semble que cela nous indique que les cinq types d'armes sont bien équilibrés, c'est-à-dire utiles les uns par rapport aux autres, et en même temps ils restent uniques.

Et comme vous pouvez également le constater, une telle modélisation et optimisation des solutions nous offre une excellente opportunité d'effectuer rapidement des recherches dans un quartier local et de ré-optimiser. Pour certains types de tâches, cela nous permettra de détecter des stratégies dominantes et des exploits de joueurs difficiles ou impossibles à trouver autrement.

Téléports - Trous de ver

En regardant les deux derniers exemples (l'exemple des taux d'imposition dans un jeu stratégique et SuperTank), vous pourriez penser que de telles techniques ne sont applicables que dans les cas où les utilisateurs ont affaire à des chiffres. Mais vous vous tromperez absolument! Comme nous le verrons, il existe de nombreux exemples de la façon dont vous pouvez obtenir les avantages de l'optimisation d'éléments de conception qui non seulement ne ressemblent pas à des nombres pour les utilisateurs, mais ne leur ressemblent pas du tout!

Vous pouvez également penser que la modélisation des décisions ne s'applique qu'aux décisions que les joueurs peuvent prendre dans les jeux. Ce n'est pas non plus vrai: dans certains cas, ils peuvent être utilisés pour la modélisation afin d'optimiser vos propres solutions en tant que concepteur.

Supposons que vous travaillez sur un MMORPG spatial. Un jour, votre concepteur principal vient à vous avec une anxiété visible sur son visage. "Nous achevons une refonte du secteur Omega", dit-il. «Et nous avons eu un problème. Nous prévoyons d'ajouter quelques téléporteurs de trous de ver "dans ce segment du monde, mais nous ne pouvons pas nous mettre d'accord sur l'endroit où les placer".

«Combien de téléporteurs?» Demandez-vous.

«Nous ne savons pas encore. Probablement trois, mais il peut y en avoir de deux à quatre. Nous n'en sommes pas encore sûrs. » Puis il vous montre une carte qui ressemble à ceci:


"Qu'est-ce que c'est?", Demandez-vous.

«Il s'agit d'une carte du secteur Omega. Ou au moins les systèmes stellaires qu'un joueur peut visiter dans ce quadrant. Nous devons déterminer dans quelles cellules les trous de ver doivent se trouver. »

«Eh bien, et selon quelles règles sont-ils placés? Est-il possible de placer le trou de ver dans un quadrant avec le système stellaire? »

«Nous voulons que vous placiez les trous de ver de manière à minimiser la distance entre tout système stellaire et le trou de ver le plus proche. Et oui, vous pouvez les mettre dans le même quadrant que le système stellaire; ce ne sont que de petits téléporteurs suspendus dans l'espace, ils peuvent donc être placés n'importe où. Et rappelez-vous que nous n'avons pas encore décidé combien il devrait y en avoir, alors donnez-moi des solutions pour 2, 3 et 4 trous de ver. »

Comment formuler ce problème et comment le résoudre?

Optimiser les téléporteurs!

Commençons par préparer les cellules de la solution. Nous désignons les quatre téléports comme A, B, C et D. Nous savons que chaque téléportation n'est essentiellement rien de plus que les coordonnées (x, y) sur la carte stellaire du secteur Omega. Nous savons également que nous aurons besoin d'un moyen d'indiquer le nombre de téléports actifs, nous allons donc ajouter une cellule qui vous permet de définir le nombre de téléports. Nous n'utilisons la téléportation D que lorsque 4 trous de ver sont utilisés et C uniquement lorsque nous en avons 3 ou plus.


Ci-dessous, nous préparerons un tableau pour calculer la distance de chaque système stellaire au téléport le plus proche. Ce tableau ressemble à ceci:


Le bleu de gauche montre les coordonnées de chaque système d'étoiles sur la carte. Chaque rangée est un système en étoile. Nous les avons simplement transférés de la carte du secteur Omega, qui nous a été donnée par le principal designer.

À droite, nous calculons la distance jusqu'à chacun des quatre téléporteurs. Ceci est juste un théorème de Pythagore. La distance est calculée comme la racine carrée des distances horizontales et verticales entre le système stellaire et le téléport:

= SQRT (($ B14-Ax) ^ 2 + ($ C14-Ay) ^ 2)

(Ne vous inquiétez pas - je vous promets que ce sont les mathématiques les plus difficiles que nous rencontrerons dans la série!)

Nous prenons les coordonnées X et Y de chaque système stellaire dans les cellules bleues du tableau ci-dessus, et les coordonnées X et Y de chaque téléport (cellules avec les noms Ax et Ay pour téléport A dans la fonction SQRT () illustrée ci-dessus) des cellules de solution jaunes en haut.

Enfin, nous prenons le minimum de ces quatre valeurs dans la colonne Dist to Closest, c'est-à-dire que nous utilisons simplement la fonction MIN () pour déterminer le minimum de quatre valeurs sur la gauche. Ensuite, nous résumons la colonne entière ci-dessous; la somme est la cellule cible.

Vous avez peut-être remarqué que dans la capture d'écran ci-dessus, toutes les cellules sont définies sur Dist à D. La raison en est que nous utilisons la cellule "Nombre de téléporteurs?" dans la partie supérieure du modèle de solution, qui permet de configurer le nombre de téléports pris en compte. Si le nombre de téléporteurs est 2, alors nous utilisons la valeur 99 à la fois dans Dist vers C et Dist vers D, et si elle est 3, alors la valeur 99 est utilisée uniquement dans la colonne Dist vers D. Par conséquent, chaque système stellaire ignorera tous les téléporteurs inutiles lors du calcul de la distance jusqu'au téléport le plus proche dans le cas de 2 ou 3 téléports.

Nous allons maintenant lancer Solver:


La cellule cible est la somme au bas de la colonne Dist to Closest. Notez que contrairement à d'autres exemples, nous voulons ici utiliser le bouton radio «To: Min» car nous avons besoin d'une distance minimum entre tous les systèmes stellaires et les téléporteurs, pas un maximum.

Ci-dessous, nous indiquerons huit cellules jaunes de solutions des coordonnées X et Y des «trous de ver» A, B, C et D comme «En changeant les cellules variables». Dans la section des restrictions, nous limiterons chacune des coordonnées comme une valeur entière dans la plage de 0 à 12. Notez que nous utilisons une contrainte entière pour ces cellules de solution, car nous voulons dire que le concepteur principal souhaite simplement savoir dans quelle cellule chaque téléport se trouvera, mais nous pouvons facilement ignorer cette restriction si le concepteur a besoin de coordonnées matérielles.

Si nous demandons "Nombre de téléporteurs?" valeurs 2, 3 et 4, et séquentiellement nous lancerons Solver à chaque valeur, nous obtiendrons les configurations suivantes:


Ayant ces informations, nous pouvons aller au concepteur principal et lui montrer les emplacements optimaux pour l'emplacement d'un nombre quelconque de téléporteurs dans la plage de 2 à 4. C'est ainsi que les emplacements optimaux des «trous de ver» pour les téléporteurs 2, 3 et 4 apparaissent sur la carte (indiquée en vert).


La feuille de calcul de cet exemple peut être téléchargée à partir d'ici .

Ai-je parlé du ninja?

"Incroyable", dit le concepteur principal, mais vous voyez la souffrance sur son visage. «Euh, mais j'ai oublié de vous dire que certains de ces systèmes sont habités par des ninjas de l'espace. Et nous voulons que les systèmes avec le ninja soient plus éloignés des "trous de ver" afin que les joueurs ne se sentent pas trop menacés. "

«Wow. Cela change complètement le cas. "

"D'accord. De plus, dans certains systèmes stellaires, il n'y a pas une mais deux colonies, c'est-à-dire qu'elles sont deux fois plus importantes que la proximité des téléporteurs. Ou il est deux fois plus important d'être plus loin s'il s'agit d'un système avec deux colonies de ninjas spatiaux. Voici à quoi ressemble la carte maintenant: "


Il poursuit: «Chaque nombre négatif est une colonie de ninjas spatiaux. Le système avec le numéro 2 contient deux colonies humaines et avec le nombre -2, il contient deux colonies de ninja. Pouvez-vous me dire où placer les téléporteurs dans ce cas? »

"Dites-moi, au moins vous avez déjà décidé combien de téléports il y aura: 2, 3 ou 4?", Demandez-vous avec ironie.

"Je n'ai pas encore peur."

Nous résolvons en tenant compte du ninja

Pour résoudre ce problème, nous devons ajouter une nouvelle colonne au tableau qui indique le poids du tableau. Nous l'appellerons le «multiplicateur». Nous multiplierons simplement cette valeur par la valeur dans la colonne Dist to Closest.

Lorsque nous faisons cela, Dist to Closest change légèrement sa signification. Maintenant, ce n'est pas la distance au système stellaire le plus proche, car pour les systèmes stellaires ninja, la valeur change de -1 fois. Cela ressemble à des «points» plus généralisés (score), appelons-les ainsi.


Ainsi, les points indiquent désormais la valeur cumulée. En le minimisant, nous faisons en sorte que Solver s'efforce d'être le plus près possible des systèmes avec des colonies humaines et en même temps aussi loin que possible des systèmes ninja peuplés.

Nous obtenons maintenant les résultats suivants:


Comme vous pouvez le voir, cela nous donne la configuration des téléporteurs, dans chaque cas très différent des versions plus simples sans ninja.


La feuille de calcul de cette version étendue de l'exemple de téléportation peut être téléchargée ici .

Comme vous pouvez le voir, notre modèle de solution a pu résoudre très rapidement cette tâche non triviale, et nous pouvons l'adapter à l'évolution des besoins.

Cette tâche appartient à la classe des tâches dites «tâches d'allocation d'objets», très bien étudiées dans le domaine de la gestion opérationnelle. Mais comme vous pouvez le voir, ils peuvent potentiellement être utilisés dans la conception de jeux, ainsi que dans la conception de niveaux, et la solution est simple (sinon triviale) dans Excel.

Équilibrage des classes pour les combats Joueur contre Joueur

La feuille de calcul de cette partie peut être téléchargée à partir d'ici: lien

Feuilles de calcul et simulations

Dans les trois parties précédentes de cette série d'articles, nous nous sommes présentés au concept de modélisation et d'optimisation des solutions, ainsi qu'à l'outil «Solveur» du package Excel. Nous avons montré comment ils peuvent être utilisés pour calculer les taux d'imposition optimaux de la ville dans la stratégie 4X, pour déterminer le placement optimal des téléporteurs dans le jeu spatial et pour sélectionner la disposition optimale des armes pour la tâche de super-char décrite dans la première partie.

Une question naturelle se pose: qu'en est-il de l'équilibre du jeu? Est-il possible d'appliquer des techniques similaires à toutes sortes de tâches d'équilibrage complexes que l'on retrouve dans de nombreux types de jeux différents, en particulier dans les stratégies, les RPG et les MMORPG?

La réponse à cette question est oui, bien sûr, mais avec de nombreuses réserves. Les feuilles de calcul en particulier ont de nombreuses limites, car dans la plupart des cas non triviaux, elles ne décrivent pas le jeu avec précision. Par conséquent, il nous sera difficile d'effectuer un équilibrage fiable à l'aide de techniques d'optimisation; les tâches d'équilibrage réelles de la grande majorité des jeux seront bien au-delà de ce que nous pouvons modéliser dans un tableur. La simulation du jeu lui-même est généralement trop compliquée, comporte beaucoup de "pièces mobiles" et est souvent effectuée en temps réel, lorsque l'on essaie de faire des simulations discrètes, on peut rencontrer toutes sortes de problèmes.

Par conséquent, si nous voulions utiliser des techniques similaires pour équilibrer les classes dans les MMORPG tels que WildStar ou dans les jeux stratégiques commeAnnihilation planétaire , alors pour assurer au moins une certaine précision et utilité, il faudrait les intégrer dans la simulation du jeu lui-même.

De plus, la vérité est que certains aspects de l'équilibrage ne peuvent pas être automatisés; comme nous l'avons expliqué dans la première partie de l' article, il est impossible d'ajuster automatiquement l'expérience de jeu.

Par conséquent, le mieux que nous puissions espérer est une démonstration d'un exemple simple illustrant une approche générale des tâches de ce type: avec un exemple simple dans Excel, nous apprendrons comment aborder la formulation de ce type de problèmes d'équilibrage et les optimiser. Nous montrerons que, au moins pour un exemple de bataille simple, Solver peut bien équilibrer plusieurs classes RPG les unes par rapport aux autres. Ensuite, vous pouvez utiliser cette structure de base comme base pour résoudre de tels problèmes d'optimisation avec un schéma plus complexe et plus profondément intégré dans la simulation du jeu.

Nous espérons qu'avec nous, vous apprendrez toutes les astuces et verrez ce que cet exemple simple peut nous donner.

Déséquilibré

Il n'y a pas de définition unique et généralement acceptée du mot «équilibrage». Cela a de nombreuses significations et la vérité dépend généralement du contexte du jeu en question. Dans différentes conditions, l'équilibrage peut être lié à la mise en place de plusieurs classes de personnages afin d'égaler leurs capacités dans un jeu de rôle, au nombre de forces des adversaires se battant les uns contre les autres dans un jeu stratégique, ou à l'ajustement du coût de diverses unités ou ressources en fonction de leur utilité.

La meilleure définition de «l'équilibrage» dépend généralement des objectifs de conception du jeu en question, mais comme ces objectifs peuvent être quelconques, il est impossible de déterminer a priori ce que l'équilibrage signifie réellement pour les jeux en général.

Certains joueurs ont tendance à croire que l'équilibrage au combat signifie des dégâts égaux. Cela est particulièrement vrai pour les MMORPG, dans lesquels les joueurs se plaignent souvent que les dégâts par seconde (DPS) d'une classe sont trop faibles ou trop importants par rapport aux autres.

Bien sûr, les classes ne peuvent pas être équilibrées uniquement par DPS; il est acceptable qu'une classe ait un DPS plus grand qu'une autre, mais cela devrait être compensé par d'autres facteurs limitant l'utilité globale de la classe, par exemple, une survie réduite ou un DPS à moins long terme par rapport au DPS à court terme.

Tiny MMO

Imaginez que nous créons un nouveau projet, un jeu de rôle en ligne massivement multijoueur très simplifié appelé "Tiny MMO". Dans le cadre du développement de la conception, nous nous efforçons d'équilibrer les quatre classes pour les combats de joueur à joueur (PVP) afin que les quatre classes soient relativement égales au combat les unes contre les autres, et qu'il n'y ait pas de classe claire «meilleure» ou «pire» qui Vous pouvez vous battre contre d'autres classes.

Bien que Tiny MMO soit un jeu en temps réel, l'action de chaque joueur dure exactement 3 secondes, nous pouvons donc le discrétiser en le présentant comme un jeu au tour par tour dans lequel chaque mouvement représente une part de gameplay de trois secondes.

Les joueurs de ce jeu peuvent choisir l'une des quatre classes de personnages:

• Le guerrier fait le plus de dégâts.
• Le mage lance des sorts à distance et a la plus longue portée d'attaque des quatre classes
• Guérisseur (Guérisseur) est traité automatiquement, rétablissant à chaque tour une certaine partie de sa santé
• Barbare (Barbare) a le plus de santé

C'est tout ce que nous savons sur ces quatre classes, et nous devons définir les paramètres initiaux de santé (HP), de dégâts, de soins et de portée des attaques pour les quatre classes. Nous devons les équilibrer de manière à ce que chaque classe soit unique et ses caractéristiques soient sensiblement différentes de toutes les autres classes, mais de sorte que chaque classe se révèle être aussi «équilibrée» que possible par rapport aux trois autres.

En d'autres termes, nous nous efforçons d'optimiser le tableau suivant:


Alors que nous utilisons des valeurs temporaires et supposons que chaque classe commence avec 50 HP, inflige 10 dégâts par tour, soigne 0 HP par tour et a une portée d'attaque de 40 mètres. Chaque personnage se déplace à une vitesse de 10 mètres par tour. Étant donné que la conception indique que les quatre classes de caractères peuvent se déplacer à la même vitesse, nous considérerons cette valeur constante et nous n'entrerons pas la vitesse de déplacement dans le tableau des variables de décision.

Évidemment, il s'agit d'une étude de cas avec un modèle de dommage très simplifié. Il s'agit d'une valeur moyenne continue de dégâts par seconde, qui ignore la différence entre les dégâts impulsifs et les dégâts à long terme, ainsi que le mana et d'autres mécanismes qui modifient les capacités d'attaque des classes. Nous n'aurons qu'un seul type de dégâts, ce qui est assez irréaliste, car la plupart des classes ont des dizaines de types de dégâts, et nous devrons implémenter un système d'IA qui sélectionne l'attaque à chaque tour. De plus, dans la plupart des jeux, les dégâts ont un élément aléatoire, mais pour l'instant nous allons l'omettre et supposer que la variabilité des dégâts n'est pas si grande qu'elle affecte de manière significative le résultat de la bataille entre les deux classes.

Bien sûr, tout équilibrage effectué dans Excel est peu susceptible d'être idéal ou cohérent avec l'équilibre final du jeu; elle devra passer par de nombreuses itérations de playtesting. Mais si nous prenons une ou deux heures pour obtenir une bonne première option pour notre jeu dans Excel, alors au moins nous sommes beaucoup plus susceptibles de nous rapprocher des paramètres qualitatifs du solde initial, ce qui nous rapprochera du solde final que nous voulons obtenir.

Table de victoire

Nous devons équilibrer quatre classes les unes avec les autres dans une bataille individuelle. Comme nous n'avons que 4 classes (Guerrier, Mage, Guérisseur et Barbare), il existe 6 combinaisons possibles de classes différentes:

• Guerrier - Mage
• Guerrier - Guérisseur
• Guerrier - Barbare
• Mage - Guérisseur
• Mage - Barbare
• Guérisseur - Barbare

Cet équilibrage peut être assez compliqué. Même dans notre cas assez simple avec quatre classes, nous avons obtenu six relations interclasses, tout comme nous pouvons tracer six lignes entre quatre points d'un carré.


Chaque fois que nous voulons apporter un petit changement à l'un des paramètres de l'une des classes, ce changement affectera également l'équilibre PvP entre cette paire de classes et les deux autres classes. Cette interconnexion de loi de puissance ne fera que croître avec une augmentation du nombre de classes, et les décisions d'équilibrer le PvP entre n'importe quelle paire de classes prises "dans le vide", sans prendre en compte toutes les autres interactions, peuvent devenir très dangereuses.

Idéalement, nous aimerions créer une sorte de table de victoirecomme celui illustré ci-dessous. Si nous pouvons simuler une bataille entre chacune de ces 6 paires dans un tableur, alors nous serons en mesure de générer une certaine variable «points» pour chacune des 6 paires. Plus il y a de points, mieux c'est, donc nous pouvons combiner ces six points pour générer une fonction objectif.


Notez que dans le tableau ci-dessus, les cellules le long des diagonales sont nulles, car elles désignent des paires de la même classe qui seront équilibrées par définition. De plus, les cellules dans le coin supérieur droit sont également nulles, car elles désignent exactement les mêmes paires que dans les cellules en bas à gauche.

Préparons maintenant le modèle pour la bataille entre deux classes différentes.

"Simulateur de bataille"

Nous organiserons chaque paire de cours à une distance de 100 mètres les uns des autres. Chaque personnage a 3 secondes pour attaquer, nous pouvons donc imaginer cela comme une simulation au tour par tour dans laquelle chaque «mouvement» signifie 3 secondes. À chaque «coup», chaque personnage attaque l'autre, s'il est à portée de l'attaque, ou continue de se déplacer pour réduire la distance.

La simulation ressemble à ceci:


Ci-dessus, une paire de personnages qui sont entrés dans la bataille: dans ce cas, Mage (classe 1) et Healer (classe 2). La colonne de gauche indique la distance actuelle entre les deux caractères simulés.

Pour chaque caractère, les colonnes seront:

• Max Range : , . .
• Healing : , .
• HP : . HP , . , .
• Damage : , , . , 0.
• Des attaques? : Cette colonne vérifie si le personnage est dans la zone d'attaque. Si c'est le cas, cela signifie que le personnage attaque dans le tour en cours; sinon, le personnage se rapproche pour atteindre un autre personnage.

Ainsi, les deux personnages commencent à se rapprocher, puis attaquent jusqu'à ce que l'un d'eux ou les deux meurent. Chaque personnage se déplace toutes les 3 secondes sur 5 mètres (5 mètres par "tour"). Lorsque les deux personnages se rapprochent, la portée change à chaque tour de 10 unités, et de 5 unités si un seul d'entre eux se déplace. Le jeu lui-même est structuré de sorte que les deux personnages puissent commencer à se déplacer simultanément, après quoi le mouvement est autorisé en même temps, il est donc possible que les deux personnages puissent mourir en même temps.

Ensuite, nous devons configurer la notation de ce tableau et générer une valeur numérique indiquant la «bonne» bataille. en d'autres termes, dans quelle mesure sommes-nous proches d'atteindre nos objectifs de conception.

De toute évidence, nous voulons que les deux personnages soient morts à la fin de la bataille, ou au moins aussi près de la mort que possible. Si la bataille est équilibrée, les deux classes de combat devraient minimiser la santé de l'ennemi à la fin de la bataille.

Cependant, cela ne suffit pas. Si nous organisons le score de cette manière, l'optimiseur maximisera simplement les valeurs des dégâts afin que les deux personnages s'entretuent instantanément! (Si vous êtes curieux, essayez de changer la feuille de calcul jointe à l'article pour voir par vous-même.) Évidemment, nous ne visons pas la mort instantanée: nous avons besoin que les deux personnages soient morts ou presque morts à la fin de la bataille, mais en même temps, nous voulons que le combat dure un temps raisonnable.

En d'autres termes, nous nous efforçons non seulement d'assurer un équilibre relativement égal de toutes les classes les unes contre les autres; nous voulons également rendre l'équilibre intéressant , y compris les combats qui durent un temps approprié.

Pour générer une telle estimation de solde, nous devons créer plusieurs cellules à droite de chaque tableau. La durée indique la durée de la bataille; elle compte le nombre de lignes du tableau dans lesquelles les deux personnages sont toujours en vie. Total HP calcule le total des points de vie des deux personnages survivants. Idéalement, il devrait être égal à 0, c'est-à-dire qu'au moment où la bataille se termine, les deux personnages sont en train de mourir.


Et enfin, Score combine la durée et le nombre total de points de vie sous la forme (Durée / (1 + HP total)). Notez que nous avons ajouté 1 au diviseur, car Total HP pourrait être égal à 0, et dans ce cas, nous obtiendrions une division par erreur zéro. De cette façon, nous pouvons garantir que nous récompensons l'optimiseur pour avoir trouvé la durée maximale de la bataille et la valeur minimale de la somme des points de vie.

(Notez que puisque nous avons 17 lignes dans chaque «simulation» de combat de classe à classe. Cela signifie que nous avons essentiellement pris une décision de conception selon laquelle le combat devrait durer environ 17 rounds. Si nous voulons que le combat soit plus court ou plus longtemps, vous pouvez modifier le nombre de lignes, modifier la formule de calcul du score et effectuer une seconde optimisation en conséquence.)

Enfin, nous prenons ces six valeurs de score (une pour chaque table) et les utilisons dans le tableau de victoire ci-dessus pour montrer les résultats de la bataille entre chaque paire de classes.

Vous pouvez simplement résumer ces six valeurs de score et utiliser le résultat comme valeur de score finale. Cependant, si nous le faisons, Solver ne sera probablement pas en mesure de trouver un bon équilibre entre les notes les plus élevées et les plus basses pour les combats individuels, et recevra également des notes très élevées pour certaines paires de classes et des notes faibles pour d'autres. Ce n'est pas ce que nous voulons: nous avons besoin que toutes les notes soient élevées et nous nous efforçons de toutes les élever. Pour résoudre ce problème, nous multiplions la somme des notes par la note la plus basse du groupe (en utilisant la fonction Excel MIN ()) pour que Solver se concentre sur la note la plus basse .

Ajouter des restrictions

Nous n'avons pas encore fini. Si vous optimisez un modèle de solution avec les paramètres actuels, il est fort probable que les classes ne seront pas configurées correctement - en fait, il est fort probable que le modèle écrira les mêmes valeurs HP, Damage, Healing et Range dans le tableau des variables de décision.

Et nous voulons bien sûr que chaque classe ait sa propre personnalité. Nous avons besoin du guerrier pour faire le plus de dégâts, le mage a la plus grande portée, le guérisseur a la valeur de guérison maximale et le barbare a les HP les plus élevés. Nous voulons également que ces différences ne soient pas trop petites - nous avons besoin que ces classes soient très différentes les unes des autres.

Pour ce faire, nous allons créer un petit tableau de restrictions. Ce tableau garantit que chacune des quatre classes aura un attribut correspondant, puis donnera un score de 0 ou 1, selon que la condition de contrainte est satisfaite.


Le tableau Différence minimale à droite montre la différence minimale de chaque attribut de la classe par rapport à toutes les autres classes. En d'autres termes, le guerrier doit avoir au moins 4 HP plus de dégâts que toutes les autres classes, le mage doit avoir une portée d'attaque d'au moins 10 de plus, et ainsi de suite.

Maintenant que nous avons ajouté ces restrictions spéciales, il est temps d'optimiser!

Recherche de solutions

Nous pouvons maintenant exécuter l'outil Solver («Finding Solutions») intégré à Excel pour essayer d'optimiser les paramètres initiaux. En tant que cellule cible, nous sélectionnerons la cellule Score, qui combine les résultats des six tournois. Nous avons défini les variables de décision pour inclure les 16 cellules dans le tableau jaune des variables de décision que nous avons créé au début.

Nous définissons également les contraintes (dans le champ Sujet aux contraintes) comme suit:

• Toutes les cellules de décision doivent être entières avec une valeur minimale de 0.
• Toutes les cellules de la colonne HP doivent avoir une valeur maximale de 200 et un minimum de 30.
• Toutes les cellules de la colonne Dommages ont une valeur maximale de 20.
• Toutes les cellules de la colonne Guérison ont une valeur maximale de 15.
• Toutes les cellules de la colonne Plage ont une valeur maximale de 100.
• De plus, les quatre cellules de la section Contraintes spéciales doivent être définies sur 1 pour satisfaire leurs conditions spéciales.

Enfin, définissez la méthode de résolution sur Evolutionary et exécutez Solver. Veuillez noter que puisqu'il s'agit d'un algorithme évolutif, il est possible d'améliorer la solution trouvée lors de la deuxième ou troisième exécution du solveur, ou après avoir défini des paramètres (bouton Options) pour une optimisation évolutive.

En conséquence, nous devrions obtenir quelque chose de similaire:


... et comme par magie, Solver nous a donné une bonne configuration d'équilibre initial.

Comme vous pouvez le voir, le Guerrier fait maintenant le plus de dégâts, le Mage a la plus grande portée, le Guérisseur guérit le mieux et le Barbare a le plus de PV. De plus, vous pouvez descendre dans les résultats des tournois individuels «classe contre classe» et voir comment les classes se sont montrées au combat; comme vous pouvez le voir, la plupart d'entre eux sont équilibrés de manière très égale - à la fin de la bataille, les deux classes sont en train de mourir, ou l'une d'elles survit à peine. De plus, tous les tournois durent assez longtemps, aucune des classes ne peut «filer» l'autre.

Pas mal pour quelques heures de travail, non?

Conclusion

Dans cet exemple, nous avons créé une tâche d'équilibrage simple et démontré qu'en fait, nous pouvons la résoudre à l'aide de la simulation et de l'optimisation. Bien qu'il soit évident qu'il s'agit d'un exemple simple, il nous montre la puissance des techniques de modélisation et de l'optimisation des décisions. De plus, il peut devenir une source d'inspiration utilisable dans des outils d'équilibrage plus complexes, étroitement intégrés à la simulation du jeu. Nous espérons que vous pourrez utiliser cet exemple comme guide pour formuler de telles tâches dans la pratique.

Dans les deux prochaines parties de la série, nous allons plonger dans le domaine des tâches d'affectation, qui est associé à la sélection d'affectations optimales à partir de deux ou plusieurs ensembles d'entités. Nous allons montrer comment résoudre ces types de problèmes et montrer comment nous avons utilisé cette approche pour créer la conception de tours dans notre jeu de stratégie pour iOS / Android City Conquest .