Играй, но проверяй: как движок обсчитывает дизайнера

При дизайне многопользовательской игры чуть ли не самой важной составляющей является баланс. Работа игрового дизайнера в этом плане похожа на работу аналитика спецслужб: если он работает хорошо, никто ничего не замечает. Стоит оступиться, и игроки бессовестно воспользуются ошибкой. Но самое интересное случается, когда помимо гейм-дизайнера ошибается ещё и программист...

В этой статье мы рассмотрим один элемент стратегии «Казаки 3». В игре присутствуют различные виды мушкетёров и иных стрелков 17 и 18 веков, а также возможность исследовать технологии, снижающие время перезарядки мушкетов. Всего имеется два улучшения, каждое из которых приносит +30% к скорострельности — если верить интерфейсу игры.

Но даже на глаз видно, что некоторые боевые единицы после исследования улучшений стреляют не просто на 60%, а даже в несколько раз чаще. При измерении скорострельности непосредственно с помощью встроенного игрового таймера выходят и вовсе странные числа, которые к заявленным процентам никакого отношения не имеют.

Под капотом у «Казаков»

К счастью, игра выполнена в очень дружелюбном для моддеров виде, так что все нужные нам скрипты доступны в виде текстовых файлов в папке data/scripts/. Судя по синтаксису, скрипты написаны на Делфи или на очень похожем языке. Давайте же взглянем на механику расчёта интервалов между выстрелами.

1. При старте игры происходит инициализация всех боевых единиц. В процедуре указываются значения жизненной силы, стоимости и вооружения для каждого типа. Для стрелкового оружия передаётся параметр, указывающий интервал между выстрелами в игровых кадрах:

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

   Судя по комментариям, единица времени «игровой кадр» это атавизм из первых «Казаков», игровой процесс которых был скопирован при создании третьей части. Впрочем, кадры сразу же пересчитываются в игровые секунды с соотношением 1:32, и больше мы с ними не сталкиваемся:

   //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. Также при старте игры инициализируются данные игровых наций, включая доступные улучшения. Для каждого из них указывается и сохраняется переменная value, которая при исследовании этого улучшения влияет на перерасчёт нужных параметров игры:

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

   В нашем случае это означает, что интервалы боевых единиц после каждого улучшения умножаются на 0,7 а затем… округляются?!

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

   Учитывая то, что изначально интервалы стрелков представляют собой числа с плавающей запятой в диапазоне от 3,125 до 5,0, решение округлять результат перерасчёта выглядит довольно странно, если не сказать бажно.

3. После каждого произведённого выстрела указывается задержка перед следующим выстрелом. Модификатор idividual.attackrate применяется к башенным сооружениям и в нашем случае всегда равен 1.

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

Итак, помимо математической ошибки в расчётах, детали которой можно прочитать под спойлером ниже, налицо неуместное округление чисел с плавающей запятой. Интересно, какой эффект на механику игры имеет эта на первый вздляд незначительная оплошность?

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

Изначально скрипты игры различают 35 видов стрелков (не считая наёмников, которые не подвержены воздействию улучшений). Если сгруппировать их всех по величине интервала, то мы сможем выделить десять категорий. Я решил сортировать их по относительному приросту скорострельности, чтобы выделить тех стрелков, кто больше других выигрывает от улучшений. Итак, результаты анализа:

	Интервал атаки			Выстрелы / мин			Рост скорострельности
КатегорияУлучшения	0	+1	+2	0	+1	+2	+1	+2
I	5,00	4,0	3,0	12,0	15	20	+25%	+67%
II	6,88	5,0	4,0	8,7	12	15	+38%	+72%
III	5,31	4,0	3,0	11,3	15	20	+33%	+77%
IV	5,63	4,0	3,0	10,7	15	20	+41%	+88%
V	3,75	3,0	2,0	16,0	20	30	+25%	+88%
VI	5,94	4,0	3,0	10,1	15	20	+48%	+98%
VII	4,06	3,0	2,0	14,8	20	30	+35%	+103%
VIII	4,38	3,0	2,0	13,7	20	30	+46%	+119%
IX	4,69	3,0	2,0	12,8	20	30	+56%	+134%
X	3,13	2,0	1,0	19,2	30	60	+56%	+213%

В диаграмме ниже столбцы соответствуют категориям I—X, слева направо. Последний штрихованный столбец диаграммы соответствует заявленному в интерфейсе игры приросту скорострельности. Левая группа столбцов показывает прирост скорострельности после одного улучшения, правая — после обоих.

Оказывается, больше всех от улучшений скорострельности выигрывают польский мушкетёр 17 века и венгерский гайдук: вместо обещанных +60% они стреляют более чем в три раза чаще. Благодаря низкому изначальному значению интервала они в итоге стреляют быстрее всех остальных стрелков в два, три, а то и четыре раза.

Среди кавалерии лучше всего устроились французские драгуны 18 века: они получают прирост скорострельности более чем в два раза. В итоге они совершают на 50% больше выстрелов в минуту, чем их коллеги из остальных европейских наций.

Естественно, здесь не учитывается урон выстрела или урон в секунду, но даже и без этих данных очевидно, что боевые единицы ведут себя не так как задумано.

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

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

Послесловие

Чтобы достоверно выявить просчёты в балансе в данном случае следует проанализировать ещё два аспекта игровой механики — урон стрелков и экономическая стоимость вместе с временем, требуемым на создание боевой единицы. Однако здравый смысл подсказывает, что сначала следует подождать следующего обновления...

Идею для исследования я почерпнул из видеоролика «Why Attack Rates in AoE2 Are Often Wrong» (англ.), рассматривающего схожую проблематику в стратегии Age of Empires II.

Автор: Ereb

Источник