5 правил игрового баланса: разбор кейсов от Rocket Jump

Константин Сахнов

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

У термина «игровой баланс» есть ряд определений. На практике балансом удобно считать систему правил и ограничений, нацеленных на создание вовлекающего геймплея. В этом определении есть указание на ключевые элементы баланса. Так как же подойти к его разработке на практике?

Я определил для себя последовательность шагов и вопросов, которые необходимо отработать для создания внутриигрового баланса. В дальнейшем они легли в основу простых правил.

Правило № 1: Игровой баланс – это система ограничений

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

К примеру, создавая стратегию типа StarCraft, нереально проверить все кейсы и варианты развития, которые возникнут у игроков. Но можно задать ограничения — скорость развития, максимальный уровень и т.д.

В World of Warcraft есть очень явный и топорный пример такого подхода к ограничениям, который, однако, отлично работает. Перед разработчиками стояла задача — дать игрокам возможность осваивать контент рейдов за нужное и удобное им время. Это время продиктовано многими факторами, один их них — скорость ввода в игру свежего контента. Для решения этой задачи разработчики ввели системы граничных условий:

Цель игрока — собрать всю необходимую для его класса экипировку в рейде, включая уникальный комплект (тир), сбор которого дает дополнительные бонусы к способностям и характеристикам. Количество предметов известно. Они падают за убийство боссов. Также мы знаем число боссов в рейде и количество доступных актуальных рейдов.

Первое ограничение — вещи падают только при первом убийстве босса в течение недели (несколько лет назад рейдовый контент разделили на «обычный» и упрощенный, где рейд собирается из «рандомов» с помощью системы Looking for Group, но мы примем за основу классические правила). Иными словами — игрок может получить не более одной вещи с босса в неделю.

Второе ограничение — вероятность выпадения нужного предмета не равна 100%. Игроку может выпасть дубликат, предмет для другого класса. А может и вообще ничего не достаться.

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

После продумывания ограничений обычно идут расчёты. Давайте прикинем вероятности собрать все необходимые нам предметы в рейдах World of Warcraft.

Пусть для полной экипировки необходимо надеть 10 вещей. Для простоты скажем, что каждая из них падает с одного из 10 боссов. Помним ограничение — одна вещь в неделю с одного босса. Если предмет падает с шансом 10%, то вероятность не получить предмет, убив босса, равна:

Вероятность не получить ни один из 10 предметов считается по формуле суммы вероятностей независимых событий, т.е. как произведение вероятности каждого из них:

Соответственно, вероятность того, что мы выбьем в первую неделю с 10 боссов хотя бы один нужный нам предмет, получится:

То есть 65%, что довольно много! А что если мы хотим получить все 10 предметов за 10 недель? Шанс такого события будет равен:

Всего 1%.

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

В представленной модели есть вероятность 0,00000001%, что игрок соберёт полный набор вещей за неделю. И ненулевая вероятность того, что он не соберёт его никогда. Чтобы избежать таких ситуации, рандом нередко делают управляемым. Так, например, в «Героях Меча и Магии V» призраки, имеющие 30% шанс увернуться от удара, гарантированно получают урон после двух уворотов.

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

Правило № 2: Основа баланса — точный расчёт

Очень часто мы балансируем сущности «на глазок». Такой подход в большинстве случаев ведёт к большой проблеме — отсутствию контроля и прогнозируемости изменений. Да, кейсы, когда баланс «из головы» можно применять на практике, действительно есть. Но в таких случаях игровая логика имеет шаткий фундамент. Для игры с пятью сущностями можно свести их плейтестами и «видением разработчика». Но когда перед гейм-дизайнером стоит задача разработать систему и прописать весь контент предметов в ММО или набор исследований в 4X-стратегии, подходить к такой задаче без системы опасно.

Хороший баланс должен иметь прочную основу, подкрепленную логикой и математикой. Это позволит:

• вводить новый контент системно;
• прогнозировать его потребление игроками;
• задавать правила ввода и вывода сущностей;
• заранее предвидеть некоторые проблемы ещё до того, как вам напишет об этом саппорт;
• снизить вероятность ошибки.

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

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

Будет учитываться скорость стрельбы, прочность оружия, количество патронов в магазине, урон от одного выстрела и т.д. На скриншоте приведён калькулятор баланса оружия, рассчитывающий мощь. Его цель заключается не в генерации большого количества предметов для игры, а в балансе ограниченного числа оружия между собой. Были заданы граничные условия: самое крутое оружие не должно иметь DPS, более чем в 2 раза превышающий DPS самого слабого оружия.

Ссылка на таблицу

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

Посчитав урон в секунду для каждого оружия, вычислим его мощь, учитывая также другие параметры пушки.

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

Правило № 3: Инструментарий — залог надёжности баланса.

Когда вы занимаетесь теоретическим геймдизайном, в расчётах всё может быть очень красиво и лаконично. Но на практике всегда есть необходимость перенести выполненные расчёты в продукт. Такой процесс, часто называемый конфигурированием, предполагает написание XML-кода, JSON- и SQL-скриптов для базы иного метода заведения данных.
Научившись на собственном опыте, сейчас я начинаю разработку любого продукта с создания набора инструментов, которые позволяют избавиться от необходимости писать код вручную. Почему это так важно?

• Все люди ошибаются. Excel надёжней.
• Хороший инструментарий проверит за вами типы введённых данных, укладываются ли они в заданные рамки, и покажет, как изменится вся система при изменении одного параметра.
• Автоматизация работы. Больше не нужно пробегаться по сотням XML-файлов и писать регулярные выражения.

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

В одном из продуктов, над которыми я работал, была система офферов — внутриигровых предложений купить тот или иной набор товаров со скидкой. Офферы вносились в SQL-базу. Они имели следующие параметры:

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

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

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

• все обязательные поля заполнены;
• стоимость, награда, скидка и другие величины не выходят за заранее заданные рамки;
• контент офферов действительно соответствует стоимости с учётом скидки с заданной степенью точности;
• условия появления и кулдауны не порождают офферы, которые никогда не появятся.

Ссылка на таблицу

Если те или иные данные введены неверно, соответствующие ячейки будут подсвечены красным.

Ссылка на таблицу

Руководствуясь теми же принципами, я создавал простые Excel-калькуляторы для всех аспектов игры. Такой подход позволил не только избавиться от ненужного ручного труда, но и в совокупности с автотестами на клиенте значительно снизить время тестирования.

Ссылка на таблицу

Подводя итог данного пункта, резюмирую основные цели инструментария:

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

Правило №4: Математики недостаточно, нужны плейтесты

Это правило действует в обе стороны. Отсутствие математической и логической модели — это отсутствие базы, опорной точки, относительно которой будет проводиться балансировка. Но полностью математически описать комплексную игру — это как разработать «теорию всего» для физиков. Задача не из тривиальных. А потому на практике всегда есть место исключениям и отступлениям от точных расчётов.

После выхода легендарной Clash of Clans я делал её деконстракшн, чтобы лучше понять принципы этой игры. Тогда я заметил, что стоимость улучшения зданий и производимые ими золото и эликсир на больших значениях отклоняются от экспоненты и прямой линии соответственно. Причина такого расхождения оказалась проста: разработчики сильно округлили параметры до ближайших «красивых» чисел: 1 день, 2 дня, 3 дня и т.д.

В любом достаточно комплексном игровом продукте всегда есть место непредсказуемым взаимодействиям. Ситуации, когда комбинация способностей даёт неожиданный мультипликативный эффект, встречаются в играх постоянно. Такие проблемы решают плейтесты. Хороший геймдизайнер постоянно играет в свой проект. Это звучит банально, но именно эту простую истину постоянно забывают сотрудники игровых компаний. Высокие темпы разработки подгоняют, позволяя забыть, как важно не просто выполнить свою работу, но и увидеть её результаты своими глазами. Кроме автора фичи никто не знает, как она должна работать на самом деле. И даже лучший отдел QA не сможет провести за вас полноценное геймдизайнерское тестирование. Приведу пример.

Работая в качестве продюсера над одной социальной-стратегической игрой, я оценил объём продаваемого контента и решил ввести в игру нового юнита для увеличения выручки проекта. Мы реализовали очень крутого наёмника с завышенными характеристиками и интересной игровой логикой. Созданный юнит – группа из трёх бойцов в защитных костюмах – передвигался по полю медленно, сжигая потоками токсичной кислоты всё на своём пути. Он имел очень много очков здоровья, был защищён от многих типов атак и даже оставлял за собой ядовитые лужи после смерти. Интересной механикой стала токсичность — юнит наносил урон самому себе с определённой периодичностью, пока запас его здоровья на упадёт до 20%. В сочетании с изначально огромным запасом здоровья это сделало его хорошим танком, который, однако, терял свой потенциал через какое-то время, когда сам доводил себя до низкого здоровья. Юнит имел мощную защиту от яда и задумывался в качестве контрмеры против самого сильного наёмника игры, сжигавшего противников ядовитым уроном.

Реализовав нового юнита, мы провели плейтесты. Хорошо сбалансированная боевая единица оказалась полезной в целом ряде игровых ситуаций. Что же могло пойти не так? Один из геймдизайнеров проектной команды отнёсся к новому контенту с должным вниманием. Он переживал за продукт и то, как игроки воспримут нововведение.

Он выпустил наёмника против обычных войск. Отличный результат! Играется интересно. Против уникальных ивентовых армий — всё замечательно. И вот настало время проверить, как новый пехотинец справляется с главным врагом игры, ведь его делали как раз для борьбы с ним.

Первый бой — и неудача. Новый отряд умирает слишком быстро. Его характеристики увеличиваются гейм-дизайнерами, и тестирование проводится ещё раз. И снова неудача. В калькуляторе, созданном для расчёта боевой мощи наёмников, новичок не уступает лидеру. В чём же проблема? Мы проверили, работает ли сопротивление яду. Работает. Увеличили здоровье юнита снова и провели повторные тесты. Безрезультатно. Старый лидер разносит новичка, без шансов.

Эти плейтесты позволили нам осознать настоящую причину, по которой старый юнит был настолько непобедим. Его механика «отравляет попавшую под атаку пехоту, снимая ей 15% максимального запаса здоровья в течение N секунд» работала хитрым образом. Всё было реализовано корректно и соответствовало документации. Но накладываемый DoT-эффект (damage over time) аккумулировался со временем — говоря игровым жаргоном, «стэкался». А потому, после нескольких залпов нашей элиты по пехоте, на пехотинцах висело сразу несколько «дотов», наносящих процентный урон. Естественно, ничто не способно спасти от ситуации, когда процентный урон складывается многократно и растет по экспоненте.

Таких примеров в моей работе было много. И ключевой вывод, который я сделал для себя — нужно играть в свои игры. Нельзя просто посчитать «идеальный» баланс, как нельзя обойтись и без точных расчётов. Хороший продукт рождается в больших усилиях, которые в него вложены. И проверять каждую мелочь — просто необходимо. Это правило касается не только гейм-дизайнеров. Все специалисты, работающие над продуктом, должны видеть его глазами конечного потребителя.

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

Правило №5: Ничто не вечно — работай со статистикой

Одной из популярных ошибок при разработке онлайн-игр является молчаливое согласие команды с тем, что максимально важно делать продукт здесь и сейчас, вложить в разработку новых фичей все усилия, отдать контент игрокам и… забыть про него.

Фритуплейные игры – очень тонкая система, требующая постоянной настройки. Введение нового контента способно кардинально изменить не только игру, но и все её метрики. В том числе финансовые. Нам необходимо постоянно держать руку на пульсе и понимать состояние внутриигровой экономики, показателей вовлечения, баланса и других аспектов игры. Лучший помощник в этом вопросе — аналитика. Каждую фичу, которую вы вводите в продукт, необходимо подкрепить сбором статистики и отслеживанием ключевых показателей. Большой ошибкой будет считать, что важно смотреть лишь на монетизационные показатели. Когда вы увидите явное падение DAU, выручки или ARPPU, может быть уже поздно.

Недавно мы в Rocket Jump вводили новые игровые активности в проект Under Control, который находится в оперировании уже четыре года и до сих пор пользуется интересом аудитории. Это был новый регулярный мини-ивент «Холодная Вахта». По своей механике он близок к другим нашим ивентам. Но с введением вахты игровая активность и, как следствие, вовлечённость и удержание аудитории, значительно увеличилась. Объясню, как мы к этому пришли.

Один из показателей, которые отслеживаются на проекте Under Control — количество боёв разных типов (PvE, PvP, клановые) на одного активного игрока в день. Это цифра в определённой степени отражает интерес игроков к продукту, показывая, когда игрокам начинают надоедать текущие режимы боя, и требуется введение новых. Но одной статистики недостаточно. Важно уметь правильно трактовать её. Так, в приведённом примере снижение числа боёв на игрока в день вполне чётко означает, что игроки теряют интерес к игре. Но почему? Они сталкиваются с техническими проблемами? В игре дисбаланс? Наскучил геймплей? Неактуальные награды?

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

• анализировать статистику, наличие девиаций – признак того, что стоит углубиться в поиск возможных проблем;
• если видна проблема с непрогнозированным изменением метрик, выдвигаем набор гипотез, которые могут объяснить причину;
• идём по списку и для каждой проблемы формулируем, как технически проверить именно её, исключая неверные гипотезы.

На примере, приведённом выше, это выглядит так:

1) В регулярном просмотре отчётов мы нашли падение метрики «количество боёв на игрока в день».

2) Зафиксировали список гипотез: баги, дисбаланс, наскучил геймплей, неактуальные награды.

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

Другой пример, когда аналитика сильно помогла нам в балансе — оптимизация наград в игровой ярмарке. В том же Under Control есть еженедельная ярмарка, в которой выпадают мощные случайные награды, которыми доступны для использования лишь неделю. В ней можно открывать сундуки за два типа игровых денег и за реальную валюту. Анализируя активность игроков на ярмарке и слушая отзывы комьюнити, мы регулярно меняем её состав, чтобы дать людям то, что им действительно нужно. Задача пересчитать вероятности тысячи сущностей в трёх типах сундуков, что-то удалить, что-то добавить, занести всё это в конфиги и протестировать, выглядит весьма трудоёмкой. На практике, разработанный нашей командой калькулятор ярмарочных сундуков делает всю эту работу за нас.

Ссылка на таблицу

Ярмарка (или распродажа трофеев, как она называется в игре) – источник ценных наград, которые, однако, существуют ограниченное время. В разные периоды жизни игры у игровых сущностей меняется ценность. В зависимости от предлагаемых разработчиком офферов, состояния игровой экономики и других факторов, у игроков в каждый момент времени востребованы разные награды. Разрабатывая ярмарку, мы хотели, чтобы она предлагала игрокам именно те награды, которые им нужны. А значит, мы должны регулярно отсматривать статистику и менять состав наград, чтобы ярмарка оставалась интересной для нашей аудитории.

***

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

Идеальный баланс не является целью. Вы можете бесконечно улучшать его на остове плейтестов, статистики и более глубоких моделей. Важно, какие ощущения обеспечивает даёт ваш баланс. Более того, многие разработчики намеренно вводят в игру дисбалансные элементы и периодически «встряхивают» игру, перебалансируя сущности. Взять, к примеру, стратегические игры по типу Warcraft III. Баланс юнитов, героев и рас в них периодически меняется, если продукт находится в активном оперировании. Это позволяет ломать устоявшиеся оптимальные стратегии, порождая новые исследования и новые впечатления от игрового процесса.

Выводы:

• любой баланс начинается не с расчётов, а с правил и ограничений;
• система ограничений должны иметь под собой математическое обоснование;
• важнейшую роль для качества и скорости работы имеет инструментарий, позволяющий менять расчеты быстро и без ошибок;
• математики недостаточно для создания крепкого баланса, нельзя обойтись без плейтестов и делать продукт, не играя в свою игру;
• ни одна система не вечна. Нужно иметь инструменты проверки её текущего состояния.

Источник: Rocket Jump