ТЕМА: Балансирование с математической моделью и без

Красивое слово - баланс. Ему как будто не нужно особенных объяснений: в игре должен быть баланс, с ним хорошо, без него плохо. Но это не так.

Достижение баланса, как и любая разработка, преследует своей целью добиться чего-то полезного для конечной игры. Если вы тратите время на работу и не можете сформулировать, зачем она в проекте нужна - например, выбираете частоту и врагов для случайных встреч, но не можете объяснить, что они дают игре (“потому что в JRPG так надо”) - выкиньте это и займитесь полезным делом. Так же и с балансом. Если вы “балансируете”, не поставив себе конечной цели, вы зря тратите своё время.

Например, вы можете поставить себе такие цели:

• Битва должна длиться от 1 до 3 минут, потому что меньше легко, а больше скучно.
• Все персонажи должны быть одинаково полезными в бою.
• Не должно быть навыков, которые никогда не пригождаются.

Сказанное выше кажется разумным, но не следует слепо применять это к любой игре! Точно так же кажется разумным следующее:

• Битва должна длиться не больше 10 секунд (в игре много кача).
• Битва должна длиться не меньше 10 минут (игра про тактические бои).
• Персонажи должны быть полезны в бою в соответствии со своим рейтингом престижности (коллекционируем монстров).
• Персонажи должны быть полезны в бою, если у них боевой класс (экономическая ролевая игра).
• Персонажи должны быть почти бесполезны в бою (пародия или стелс).
• Все навыки полезны в разной мере, игрок должен сам вычислить, которые действительно полезны.

Иначе говоря, продумайте, что нужно вашей игре. Для этого нужно знать, чего она хочет добиться и как. Возможно, она даже не будет следовать принятым жанровым представлениям о длине боя или полезности персонажей, поэтому я не обсуждаю их в этой статье.
Только когда вы определитесь, можно говорить о балансе.

Допустим, вы подумали: бои в моей игре не главное, главное - сюжет, значит, бои в балансе не нуждаются. Допустим даже, вы не просто вставили в игру бои “потому что так делают все”, а осознанно решили: бои нужны для создания атмосферы JRPG. Важен сам факт боёв. Не важно, какие они будут.

В таком случае вам будет полезно придерживаться принципа: в балансе нуждается то, за чем игрок проводит заметное количество времени. Заметное - то такое, которое он сам бы заметил. Потратил 20 минут подряд на скуку? Заметил и закрыл игру. Потратил первые 5 минут игры на скуку? Заметил и закрыл игру. Заметил на середине игры, что потратил 20% игрового времени на скуку? Закрыл игру.

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

Основной способ баланса сложных систем в игровой разработке - это математическое моделирование. О нём можно почитать в Википедии. Если коротко, то это упрощённое описание какого-либо процесса математическими формулами.

Например, герой атакой бьёт на 10 урона за ход, а у врага - 100 здоровья. Несложно подсчитать, что для убийства врага понадобится 10 ходов. Мы вычислили это по формуле “здоровье делить на урон в ход”. Это и есть математическая модель. Она упрощённо описала десятиходовый бой.

Если герой бьёт на 10-20 урона в ход, то достаточно очевидно, что для убийства врага понадобится 5-10 ходов. Это немного более сложная математическая модель, учитывающая минимальный и максимальный урон.

Математическое моделирование точно так же подходит для балансирования экономики, поуровневого развития и всего, что может быть выражено математически. (Исключая, к примеру, “баланс экранного времени” персонажей в сюжете - это скорее режиссура; или левел-дизайн.)

Популярным способом балансировки боя является подсчёт урона в секунду (или в ход, смотря что актуально для вашей игры), то есть DPS. Этот термин может быть вам знаком по MMORPG, MOBA и мобильным стратегиям. Очевидно, если мы хотим двух героев, умеющих наносить урон одинаково хорошо, у них должен быть примерно равный DPS. Показатель DPS легко получить, умножив средний урон на частоту его нанесения в секунду (или разделив на количество секунд кулдауна). Можно даже городить формулы посложнее: допустим, 4 раунда из пяти герой бьёт обычной атакой на 8-12, а на пятый раунд - суперударом на 50. Его DPS будет равен (8+12)/2*(4/5) + 50*(1/5) = 18 (расчёт можно просто вбить в Гугл, он вычислит). Не забывайте порядок выполнения операций: сначала вычисляются скобки, потом умножение и деление в порядке следования, потом сложение и вычитание в порядке следования.

Но DPS - это приближение. Урон может наноситься часто помалу (пулемёт, яд) или редко помногу (рельса, ракета, файрбол). Редкий большой урон может наноситься в начале отрезка времени (гиперлуч - мощный удар, затем ход перезарядки) или в конце (солнечный луч - ход на зарядку, затем мощный удар). И если вы уже сражались в игровых боях (вы же не делаете игру с тактическими боями, не разбираясь в них как игрок?), то знаете, что эти варианты отнюдь не равнозначны. Лучше нанести побольше урона раньше - может, вы убьёте противника, и он уже ничего вам не сделает. А если у врага есть абсолютная (вычитаемая) броня, то бить урон на множество атак не выгодно, ведь броня будет вычтена из каждой атаки - в итоге, может, урон вообще не будет нанесён. Математическая модель с DPS этого не отражает. Что делать?

Вы можете прикинуть на глаз, насколько более выгодна атака, позволяющая пораньше нанести большой урон (или насколько не выгодна - та, которая наносит большой урон попозже) и соответственно увеличить или уменьшить урон, а затем сразиться и проверить, нормально ли получилось. Или можно построить модель, которая это учитывает.

Если математическое моделирование - основной способ балансирования, то таблицы - основной инструмент. Подойдут таблицы в Гугл-доках, они бесплатны. Но ими надо уметь пользоваться, иначе это просто числа, записанные в строчку и в столбик. Изучите использование формул в Гугл-доках или Экселе с помощью какого-нибудь видеоурока (раньше Эксель также преподавали в школе, возможно, преподают и сейчас). В итоге вы сможете автоматически производить вычисления над введёнными в таблицу данными.

Например, если в клетке А1 находится урон атаки героя, в клетке Б1 - число атак в секунду, а в клетке В1 - здоровье врага, то в клетке Г1 можно записать формулу “=В1/(A1*Б1)” и получить среднее число секунд, за которые герой убивает врага. Можно поставлять разные значения, смотреть на результат, уточнять… А можно воспользоваться школьной алгеброй и сделать формулу вычисления атаки героя, чтобы он убивал врага за нужное число секунд, записанное в Г1. В клетке А1 записать: “=В1/(Г1*Б1)”. Это следует из правила пропорции; или же можно домножать и делить на бумаге обе стороны уравнения “Г=В/АБ”, пока не слева не станет “А=...”. Кстати, несмотря на мощность цифровых инструментов, рекомендую разжиться блокнотом или тетрадью.

Сошлись герой с врагом, и у героя 10 DPS, а у врага - 5 DPS. Кто победит?

Из этих данных невозможно сказать, если, конечно, в вашей игре защитные характеристики не совпадают у всех бойцов. В действительности нужно вычислить, за сколько секунд (или ходов) герой убьёт врага, а враг - героя. Допустим, это соответственно 1,2 и 1. Кто победит?

Если вы сказали “злодей” или “примерно 50/50”, то вы неправы. Из этих данных всё ещё невозможно сказать. Нужно знать, как происходят случайности в боевой системе и как распределён урон. Например, если боец всегда наносит ровно столько урона, сколько у него DPS, то, действительно, всегда победит злодей. Если злодей - пулемётчик, а герой - снайпер, бьющий в начале боя на 50, а потом молчащий 5 секунд - герой победит. Наконец, если урон равномерен, но случаен, скажем, +/-20%, то исход такого боя тоже будет случаен: может, герой нанесёт сразу 12 урона и прикончит врага, а может и нет.

Мораль в том, что DPS - хотя и очень простой показатель, который используется почти в любом моделировании боя, но нужно также учитывать нюансы боевой системы. Если вы их не учли, то увидите расхождение модели с реальностью, когда будете проверять вычисления в бою. В таком случае ищите, где в модели допущено чрезмерное упрощение.

Сбалансированной должна быть не одна битва между конкретным героем и конкретым монстром, а все битвы, возможные в игре (или хотя бы все, которые вам нужно сбалансировать). А персонажи - это не наборы констант, часто они развиваются по какой-то схеме. Возможно, игрок даже может выбирать направление их развития и куда идут очки! И даже менять классы! А если игра содержит элемент нелинейности, так что партия, вступившая в бой, тоже непредсказуема?

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

Несколько полезных правил:

• Уровни балансируются от первого до последнего. Во-первых, так легче (вы же в этом порядке проходите игру во время тестов). Во-вторых, обычно первые уровни влияют на числа на последних, а не наоборот. Соответственно, если вы сбалансируете финальный бой, а потом станете менять что-то на первых уровнях, то финальный бой тоже расстроится.
• Сначала балансируются герои, потом - враги. Герои актуальны для большей части игры, а враги - обычно для небольшой области или отдельных событий.
• В конце разработки или после релиза исправлять баланс нужно точечно, чтобы не расстроить всю систему: например, если битва с боссом дисбалансированная - следует вносить изменения в босса (они касаются только одной битвы), а не в героев (касаются многих и многих битв).

Кроме того, развитие - это не просто сколько (какие числа будут на каком уровне), но и когда (частота повышения уровня, изменения чисел). Например, вам нужно, чтобы игрок получил второй уровень к 15-й минуте игры. Для этого нужно знать, сколько и каких источников опыта он за эти 15 минут увидит (если ваша система повышает уровни за опыт, конечно). Тогда сумма опыта из этих источников - например, боёв - должна составлять то, сколько нужно для 2-го уровня. Подобные вычисления нужно провести для всей продолжительности игры. Опять же, будет полезно использовать таблицу, чтобы не считать на пальцах.

Далее я буду использовать такие термины, обозначающие разные виды математических модель в форме таблицы:

• Калькулятор (расчётная таблица) - автор закладывает пожелания (“битвы заканчиваются за 10 ходов, DPS 20”), а на выходе получает данные для ввода в игру (“здоровье врагов 200”).
• Контроль (валидатор, проверочная таблица) - автор закладывает данные, которые надо проверить, а на выходе получает оценку правильности данных. (“DPS 20, здоровье врагов 200. Заканчиваются ли битвы за 15-25 ходов?”).
• Симулятор - автор закладывает данные, которые надо проверить, а модель упрощённо разыгрывает их и выдаёт результат. (“DPS и здоровте у героя 20/50, у врагов 10/200” - “Вот лог боя”).
• Интерактивный симулятор - то же, что и симулятор, но игрок может принимать решения в процессе симуляции, например, выбирать атаки или покупать/продавать вещи. Маленькая упрощённая копия одной из ситем игры.
• Экспортёр - запускаемый в таблице скрипт, который может полученные данные экспортировать в формат, понятный игре.
• Импортёр - запускаепый в таблице скрипт, который может считать данные игры и записать их в модель.

Термины, касающиеся данных:

• Данные - под этим я подразумеваю числа, которые будут использоваться игрой: показатели атаки и здоровья, коэффициенты в формулах… А также списки персонажей, врагов, атак и другого контента.
• Заглушечные данные - числа “чтобы были”, необходимые для начала тестирования системы. Не имеют ничего общего с целями игры и критериями баланса. Ими просто нужно по-быстрому заполнить модель.
• Предварительные данные - данные, полученные моделью, но ещё не проверенные на игре; особенно если игра гораздо сложнее модели и их почти наверняка нужно исправлять.
• Финальные (актуальные) данные - данные, на которых автор поставил точку и сказал “в релизе будет так”. Само собой, до релиза и после релиза данные всё равно могут поменяться… Но в данный момент автор не считает нужным пересматривать их.
• Устаревшие данные - данные, бывшие актуальными, но теперь нуждающиеся в пересмотре.
• Расчётные данные - данные, полученные моделью (без внесения изменений вручную).
• Текущие данные - данные, сейчас находящиеся в игре, независимо от того, актуальны ли они.

А теперь собственно техники.

• Используйте условное форматирование: оно позволяет глазами отследить закономерности и аномалии в данных. Есть разные виды условного форматирования - цветом, столбиками…
• Изучите параметры условного форматирования! Например, иногда важно все числа, которые больше 1000, красить одинаковым красным, а не растягивать промежуток с белого до красного до максимального числа в области.
• Обратите внимание, что процентиль - не то же, что процент. Если вы не знакомы с термином “процентиль”, настоятельно рекомендую в параметрах условного форматирования в качестве среднего значения указывать “процент”.
• Есть условное форматирование, которое позволяет сделать все нулевые значения серым, или сделать “Да” зелёным, а “Нет” - красным… В общем, можно выделить данные почти что как угодно.
• Используйте графики. Пользоваться ими даже проще, чем условным форматированием: выделил область с данными, нажал “Вставить график” (или “Вставить/График”, смотря в какой вы программе). Это другой способ глазами увидеть закономерности и аномалии.
• Используйте знак доллара $ в формулах. Он позволяет при копировании или растягивании клетки с формулой на соседние зафиксировать координаты, по которым она берёт данные из других ячеек. Например, растягивание формулы “=А1” на клетку ниже даст “=А2” на этой клетке; если же формула будет “=А$1”, то в клетке ниже тоже будет “=А$1”, потому что единица - зафиксирована.
• Используйте именованные области. Вы может назвать клетку А1 “множитель_атаки” и дальше использовать это название в формулах: “=Б1*множитель_атаки”. Это делает формулы более удобными для восприятия, особенно когда вы сели за них после полугодичного перерыва.
• Читайте учебники. Если вы хотите добиваться серьёзных результатов с использованием таблиц, читайте про то, как ими пользоваться. Там вы прочтёте о том, как сделать и настроить условное форматирование, как использовать знак доллара, какие бывают формулы и многое, многое другое. После 10 лет работы в этой области я, по своей оценке, пользуюсь только 10% возможностей Экселя и Гугл-таблиц, и этого хватает для баланса серьёзных коммерческих игр.

Поскольку математическое моделирование - это упрощение, то чем сильнее упрощение, тем меньше модель согласуется с реальностью. В зависимости от степени этих разногласий она может перестать быть полезной. Обычно это происходит, если в игре есть факторы, которые сложно выразить математически: например, позиционирование. Боёвку “бойцы стоят друг напротив друга и поочерёдно атакуют” выразить математически просто, а боёвку “два отряда с разными боевыми классами сражаются на карте с учётом высоты” - гораздо сложнее. Обычно всё, что можно сделать - это какие-то предположения о том, какой “бонус к DPS” даёт выгодная позиция и сколько бойцов занимают выгодные позиции. То же касается боёвки, в которой действует “золотое правило” из Magic: the Gathering: частные правила приоритетней общего. Боёвку, где всё строится на уникальных способностях или свойствах героев, замоделировать значительно сложнее, чем сражения типовых юнитов.

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

Полезно помнить, что “ни один игровой баланс не переживает встречу с релизом”. По крайней мере в наш век, когда можно выпускать патчи и обновления. Если модель вашей сложной боевой системы дала вам лишь отправную точку для чисел в контенте, то для перебалансировки вам придётся либо автоматически импортировать данные из игры, либо перебивать их вручную.

Все методики выше подходят не каждому. Автор игры может быть гениальным сюжетчиком, дизайнером игрового процесса, даже программистом, но начинать клевать носом от одного вида таблиц с числами. Это нормально! В действительности способность воспринимать стены текста (вроде этой статьи) или таблицы чисел - редкое умение среди людей. К тому же никто ещё никогда не хвалил игродела за то, что он классно пырится в скучные таблицы. Наша братия геймдизов-математиков остаются невоспетыми.

Но это не повод не выпустить сбалансированной игры. Нужно только правильно к этому подойти. Есть три способа.

1. Балансировать “на глаз”. Просто много играть в игру и замечать “ага, тут битва слишком сложная, нужно ослабить врагов”. Этот способ надёжен, но требует много времени и труда. Если вы тестировали игру недостаточно или не проверили все ситуации, в них может остаться дисбаланс с большей вероятностью, чем если вся игра была описана и рассчитана с помощью математической модели. Главное - соблюдать принципы, изложенные в разделе “Баланс развития”, чтобы не тратить время и силы зря.
2. Подобрать систему, которую легче балансировать. А то и вообще не надо балансировать. Например, вам нужно, чтобы игрок получил уровень после первого босса? Просто выдавайте уровни в игре при прохождении ключевых точек, а не от накопления опыта. Если это не кажется изящным, проявите фантазию и выдайте магический меч, или сенсея для апгрейда класса, или герой может искупаться в драконьей крови на манер Зигфрида… Главное - избегать таких закономерностей, когда исправив что-то в одном месте, можно расстроить баланс во многих и многих местах.
3. Попросить помощи у других. Правда, у нас принято просить помощи только у художников, скриптеров и мапперов.

Вы готовитесь к релизу и знаете, что игра слишком простая или слишком сложная, и вы ничего не можете с этим сделать. Не успеваете, или поняли, что заложенная вами система не может быть сбалансирована (бывает и такое - у математики свои законы), или что-то ещё…

Ваша задача в таком случае - сократить потери и дать игроку наилучший пользовательский опыт из объективно возможных здесь и сейчас.

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

Если игра слишком лёгкая, то и чёрт с ним. Сложность - понятие субъективное. Может, в неё начнёт играть 8-летний школьник, и это станет его первой игрой после того, как он только смотрел игры на Ютубе. Она покажется ему как раз в меру сложной. Кроме того, игра может быть хороша сюжетом или графикой.