When designing a multiplayer game, almost the most important component is balance. The work of the game designer in this regard is similar to the work of an intelligence analyst: if he works well, no one notices. It is necessary to stumble, and the players shamelessly take advantage of the error. But the most interesting thing happens when, in addition to the game designer, the programmer is also mistaken ...

In this article we will consider one element of the Cossacks 3 strategy. In the game there are various types of musketeers and other shooters of the 17th and 18th centuries, as well as the opportunity to explore technologies that reduce the reload time of muskets. In total there are two improvements, each of which brings + 30% to the rate of fire - according to the game interface.

But even by eye it is clear that some combat units after the study of improvements shoot not just 60%, but even several times more often. When measuring the rate of fire directly using the built-in game timer, strange numbers come out that have nothing to do with the stated percentages.

Under the hood at the "Cossacks"

Fortunately, the game is made in a very friendly form for modders, so all the scripts we need are available as text files in the data / scripts / folder. Judging by the syntax, the scripts are written in Delphi or in a very similar language. Let's take a look at the mechanics of calculating the intervals between shots.

1. At the start of the game, initialization of all combat units occurs. The procedure indicates the values ​​of vitality, cost and weapons for each type. For small arms, a parameter is passed indicating the interval between shots in game frames:

   
   

   //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 ); 

   
   

   Judging by the comments, the unit of time "game frame" is an atavism from the first "Cossacks", whose gameplay was copied during the creation of the third part. However, the frames are immediately converted into game seconds with a ratio of 1:32, and we no longer encounter them:

   
   

    //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. Also, when starting the game, the data of the game nations is initialized, including the available improvements. For each of them, the value variable is indicated and stored, which, in the study of this improvement, affects the recalculation of the necessary game parameters:

   
   

    //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, ... ); 

   
   

   In our case, this means that the intervals of combat units after each improvement are multiplied by 0.7 and then ... rounded up ?!

   
   

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

   
   

   Considering that initially the shooters' intervals are floating-point numbers in the range from 3.125 to 5.0, the decision to round the result of recalculation looks rather strange, if not to say important.

   
   

3. After each shot, the delay is indicated before the next shot. The idividual.attackrate modifier applies to tower structures and in our case is always equal to 1.

   
   

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

   
   

So, in addition to the mathematical error in the calculations, the details of which can be read under the spoiler below, there is an inappropriate rounding of floating-point numbers. I wonder what effect this game has on the first look at a minor misstep on the mechanics?

  //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; 

Who is who

Initially, the game scripts distinguish 35 types of shooters (not counting mercenaries who are not affected by the improvements). If we group them all by the size of the interval, then we will be able to distinguish ten categories. I decided to sort them by the relative increase in the rate of fire in order to single out those shooters who benefit most from the improvements. So, the results of the analysis:

In the diagram below, the columns correspond to categories I — X, from left to right. The last hatched column of the diagram corresponds to the rate of fire rate increase declared in the game interface. The left group of columns shows the increase in the rate of fire after one improvement, the right - after both.

It turns out that the 17th century Polish musketeer and the Hungarian haiduk benefit most from improvements in the rate of fire: instead of the promised + 60%, they shoot more than three times more often. Due to the low initial value of the interval, they eventually shoot faster than any other shooter by two, three, or even four times.

Among the cavalry, the French dragoons of the 18th century were best settled: they receive a more than two-fold increase in the rate of fire. As a result, they make 50% more shots per minute than their counterparts from other European nations.

Naturally, the damage of a shot or damage per second is not taken into account, but even without this data it is obvious that combat units do not behave as planned.

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

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

Afterword

In order to reliably identify miscalculations in the balance in this case, two more aspects of game mechanics should be analyzed - shooters' damage and economic value, along with the time required to create a combat unit. However, common sense suggests that you must first wait for the next update ...

I drew the idea for the study from the video “ Why Attack Rates in AoE2 Are Often Wrong ” (eng.), Which considers similar problems in the strategy of Age of Empires II .

UPD: Partially fixed error

Not even a week passed since the publication of the article, as the developers in update 2.2.1 fixed the error with rounding off. At the same time, the formula itself remained the same - the rate of fire grows by 43% for an upgrade. Since the calculation is incremental, after examining both improvements, all arrows work 104% faster.