Lors de la conception d'un jeu multijoueur, l'équilibre est presque l'élément le plus important. Le travail d'un concepteur de jeux à cet égard est similaire au travail d'un analyste du renseignement: s'il fonctionne bien, personne ne le remarque. Cela vaut la peine de trébucher, et les joueurs profitent sans vergogne de l'erreur. Mais la chose la plus intéressante se produit lorsque, en plus du concepteur de jeu, le programmeur se trompe également ...

Dans cet article, nous considérerons un élément de la stratégie des Cosaques 3 . Le jeu contient différents types de mousquetaires et autres tireurs des 17e et 18e siècles, ainsi que la possibilité d'explorer des technologies qui réduisent le temps de rechargement des mousquets. Il y a deux améliorations au total, chacune apportant + 30% à la cadence de tir - selon l'interface de jeu.

Mais même à vue, il est clair que certaines unités de combat, après avoir recherché les améliorations, tirent non seulement à 60%, mais même plusieurs fois plus souvent. Lorsque vous mesurez la cadence de tir directement à l'aide du chronomètre de jeu intégré, des nombres complètement étranges sortent qui n'ont rien à voir avec les pourcentages indiqués.

Sous le capot des "Cosaques"

Heureusement, le jeu est fait de manière très conviviale pour les moddeurs, donc tous les scripts dont nous avons besoin sont disponibles sous forme de fichiers texte dans le dossier data / scripts / . A en juger par la syntaxe, les scripts sont écrits en Delphi ou dans un langage très similaire. Jetons un œil à la mécanique de calcul des intervalles entre les prises de vue.

1. Au début du jeu, toutes les unités de combat sont initialisées. La procédure indique les valeurs de vitalité, de coût et d'armes pour chaque type. Pour les armes légères, un paramètre est transmis qui indique l'intervalle entre les tirs dans les cadres de jeu:

   
   

   //lib/unit.script procedure _unit_InitBase() 'musketeer' : maxhp := 70; SetObjBaseWeapon( x,x,x,x, 150, ... ); SetObjBasePrice( ... ); //lib/unit.script procedure SetObjBaseWeapon( x,x,x,x, pause, ... ) weapon.pause := _misc_FramesToTime( pause ); 

   
   

   A en juger par les commentaires, l'unité de temps «cadre de jeu» est l'atavisme des premiers «Cosaques», dont le processus de jeu a été copié lors de la création de la troisième partie. Cependant, les images sont immédiatement recomptées en secondes de jeu avec un rapport de 1:32, et nous ne les rencontrons plus:

   
   

    //lib/misc.script function _misc_FramesToTime( val ) Result := ( val * gc_frames_to_time ); //dmscript.global gc_frames_to_time := 0.03125; gc_time_to_frames := 32; 

   
   

2. De plus, au début du jeu, les données des nations de jeu sont initialisées, y compris les améliorations disponibles. Pour chacun d'eux, la variable de valeur est indiquée et stockée, ce qui, lors de l'étude de cette amélioration, affecte le recalcul des paramètres nécessaires du jeu:

   
   

    //lib/country.script procedure _country_Init() _country_AddUpgrade( x,x,x,x, type_attpauseperc, -30, ... ); procedure _country_AddUpgrade( x,x,x,x, upgrade_type, value, ... ); 

   
   

   Dans notre cas, cela signifie que les intervalles des unités militaires après chaque amélioration sont multipliés par 0,7 puis ... sont arrondis?!

   
   

    //lib/player.script procedure _player_ApplyUpgrade() type_attpauseperc : weapon.pause := Round( weapon.pause * (1 + value/100) ); 

   
   

   Étant donné qu'au départ, les intervalles des tireurs sont des nombres à virgule flottante compris entre 3,125 et 5,0, la décision d'arrondir le résultat du recalcul semble plutôt étrange, sinon importante.

   
   

3. Après chaque coup tiré, le délai avant le coup suivant est indiqué. Le modificateur idividual.attackrate est appliqué aux structures des tours et dans notre cas est toujours 1.

   
   

    //lib/unit.script procedure _unit_ApplyAttackPause() attackdelay := weapon.pause * idividual.attackrate; 

   
   

Ainsi, en plus de l'erreur mathématique dans les calculs, dont les détails peuvent être lus sous le spoiler ci-dessous, il y a un arrondi inapproprié des nombres à virgule flottante. Je me demande quel effet sur la mécanique du jeu a ce léger oubli à première vue?

  //cossacks.ini & editor.ini LogFileEnabled = true LogFileRoot = true 

  //data/scripts/lib/unit.script procedure _unit_ApplyAttackPause(const goHnd, weapind : Integer); begin //... if (attpause<>0) then Log(TObjProp(pobjprop).sid+' '+FloatToStr(attpause)); end; 

Qui est qui

Initialement, les scripts du jeu distinguent 35 types de tireurs (sans compter les mercenaires qui ne sont pas affectés par les améliorations). Si nous les groupons tous selon la taille de l'intervalle, nous pouvons distinguer dix catégories. J'ai décidé de les trier par augmentation relative de la cadence de tir afin de distinguer les tireurs qui bénéficient le plus des améliorations. Ainsi, les résultats de l'analyse:

Dans le diagramme ci-dessous, les colonnes correspondent aux catégories I - X, de gauche à droite. La dernière colonne en pointillés du diagramme correspond au taux d'augmentation déclaré dans l'interface de jeu. Le groupe de colonnes de gauche montre une augmentation de la cadence de tir après une amélioration, la droite - après les deux.

Il s'avère que le mousquetaire polonais du XVIIe siècle et le détournement hongrois gagnent le plus grâce à l'amélioration de la cadence de tir: au lieu des 60% promis, ils tirent plus de trois fois plus souvent. En raison de la faible valeur initiale de l'intervalle, ils tirent finalement plus vite que tous les autres tireurs deux, trois ou même quatre fois.

Parmi la cavalerie, les dragons français du XVIIIe siècle sont les mieux installés: ils reçoivent une cadence de tir plus que doublée. En conséquence, ils tirent 50% de tirs de plus par minute que leurs homologues d'autres pays européens.

Naturellement, les dégâts d'un tir ou les dégâts par seconde ne sont pas pris en compte ici, mais même sans ces données, il est évident que les unités militaires ne se comportent pas comme prévu.

  //lib/player.script Round(weapon.pause*(1+value/100)); 

  weapon.pause/(1+(-value)/100); 

Postface

Afin d'identifier de manière fiable les erreurs de calcul dans la balance dans ce cas, deux autres aspects des mécanismes de jeu doivent être analysés - les dégâts des tireurs et la valeur économique ainsi que le temps requis pour créer une unité de combat. Cependant, le bon sens vous dit d'attendre d'abord la prochaine mise à jour ...

J'ai eu l'idée de l'étude dans la vidéo « Pourquoi les taux d'attaque en AoE2 sont souvent erronés », qui traite d'un problème similaire dans la stratégie Age of Empires II .

UPD: erreur partiellement corrigée

Pas même une semaine ne s'est écoulée depuis la publication de l'article, car les développeurs de la mise à jour 2.2.1 ont corrigé l'erreur d'arrondi. Dans le même temps, la formule elle-même est restée la même - la cadence de tir augmente à 43% par mise à niveau. Comme le calcul est incrémentiel, après avoir examiné les deux améliorations, toutes les flèches fonctionnent 104% plus rapidement.