Дисбаланс может свести на нет и гениальный дизайн, и великолепную игру. Большинство дизайнеров постигают основы методом проб и ошибок. В случае успеха они получают лакомый кусок. Те, кто приобрел опыт, ревниво таят свои секреты и не торопятся делиться знаниями с остальными. В результате, несмотря на то, что информация существует и ее достаточно много, она недоступна. По этой причине и была написана данная статья.
Что такое игровой баланс?
Как-то Сид Мэйер сказал -, "Игра - это набор занимательных альтернатив". Следовательно, несбалансированные элементы геймплея уменьшают их количество и тем самым оказывают негативное влияние на саму игру. "Идеальная" игра представляет собой последовательность альтернатив, которые завершаются либо выигрышем, либо каким-нибудь другим финалом. Иногда некоторые альтернативы могут оказаться или бесспорно единственно правильными, или определенно ошибочными. Если в определенный момент времени выделяется из остальных только один правильный выбор, но игра на этом не завершается - это проблема дисбаланса
Почти все ситуации, связанные с дисбалансом, являются следствием уменьшения выбора. К примеру, в стратегии один из юнитов является чрезмерно эффективным по сравнению с затраченными на его постройку ресурсами. Остальные юниты становятся практически бесполезными. Такая ситуация не только предоставляет игроку единственную стоящую альтернативу (из чего тут еще выбирать?), но и отвлекает множеством бесполезных решений. Бесполезные решения также портят игру: они сбивают с толку и разочаровывают своей сложностью пользователя.
Яркий пример дисбаланса демонстрирует Монополия. Здесь ВСЕГДА в интересах игрока как можно дольше просидеть в тюрьме. Поэтому последнее время доминирующая стратегия среди игроков заключается в том, чтобы попасть в тюрьму, не выплачивать собственный выкуп, ожидая, когда другие игроки лишатся своей собственности и станут банкротами. К концу игры пользователям также не предоставляется шанс выбирать - игра просто завершается. Никто не решает, покупать собственность или нет, редко появляется удобный случай построить новую собственность (поскольку сбережения фирм израсходованы), и торговли просто не происходит: собственность скапливается внутри монополий. В такой ситуации исход игры становится абсолютно случайным. Игроки почти не могут повлиять на ход игры и удержать преимущество (если не владеют приемами удачного бросания кости). Ранние версии игры Монополия в этом смысле резко отличались: здесь свирепствовали политические махинации, игроки испытывали различные стратегии в торговле, искусно приобретая для себя выигрыш и подставляя конкурентов, игроки тщательно продумывали, какую именно собственность им приобрести, покупать или не покупать "крупные" желтые/зеленые/черные виды собственности.
Приведенный пример демонстрирует лишь один тип дисбаланса. В играх встречаются и другие типы. Все они в той или иной форме сводятся к уменьшению выбора.
Слишком дорогой/слабый против слишком дешевого/сильного:
Выбор в игре зачастую связан с определенными затратами на его достижение. В качестве затрат могут выступать потеря другого выбора (альтернативные издержки, прим. пер.), игровые денежные единицы, какие-либо другие ресурсы. Когда выбор является или слишком дорогим, чтобы быть полезным; или слишком дешевым, чтобы привлечь внимание, - это явный дисбаланс, поскольку одна или несколько альтернатив непреднамеренно аннулируются. Несмотря на то, что такой тип дисбаланса в играх встречается чаще всего, он с легкостью устраняется изменением цены или эффективности рассматриваемого выбора.
Нарушение временного баланса:
Большинство проблем дисбаланса связано со стоимостью выбора (чего игрок лишится, решив пойти по такому пути). Очень легко упустить из виду тот факт, что делая выбор игрок затрачивает время на его реализацию. В real-time-играх пользователь не имеет в своем распоряжении бесконечный запас внутриигрового времени, а потому время - это не просто ресурс, это ограниченный ресурс. В non-real-time играх, внутриигровое время не ограничено, но ограничено время игрока! Этот тип нарушения баланса лишь очередная версия типа "слишком дорогой/слабый против слишком дешевого/сильного", за исключением того, что стоимость времени менее очевидна.
Яркий пример такого рода дисбаланса демонстрировала игра Starcraft (раса Зерги). По стоимости юниты Зергов более-менее сбалансированы с представителями других рас. Однако развитие у этой расы идет гораздо быстрее. Это была главная причина, почему Зерги лидировали на сетевых турнирах в течение 6 месяцев после выхода Release-версии Starcraft.
Дисбаланс в уровнях сложности:
В течение игры пользователи приобретают опыт. За это время относительная эффективность различных игровых альтернатив может изменяться. Например, в игре существует 2 пути развития, один из которых для прохождения достаточно легок, второй - очень сложен; однако относительная эффективность этих альтернатив для опытного игрока и для новичка окажется различной. В такую ловушку попадают множество разработчиков игр: зачастую они судят об игре с точки зрения опытного пользователя, не принимая во внимание новичков. С другой стороны, развитие игры в сторону поддержки разных уровней сложности считается хорошим тоном. Важно принимать во внимание возможность возникновения подобного дисбаланса и вообще учитывать такие феномены.
Принудительные выгодные/невыгодные положения:
Когда пользователь соревнуется с игровой средой, некоторые последовательности его действий (выборов альтернатив) могут гарантировать превосходство над другими. Эта ситуация дополняет традиционное определение дисбаланса (один выбор явно самый удачный) и также несправедлива. С этим вариантом дисбаланса легко справляются сетевые игры, но он все же является важной ниточкой в паутине.
Все варианты дисбаланса сводятся к начальной постановке: уменьшение выбора. Когда это принимается во внимание, становится гораздо проще различать ситуации, требующие небольшой доработки для балансировки, и ситуации, содержащие дисбаланс в своей основе.
Достижение балансабилити
Зачастую игровым балансом начинают заниматься на стадии "альфа" или "бета"-версии проекта. Но истина гласит, что как и к любой инженерной задаче, к нему стоит готовиться заранее: хорошо спроектированная игра относительно легко поддается балансировке. Это свойство носит название балансабилити.
Игра - это система, чтобы она имела прочное балансабилити требуется своевременно использовать определенные инженерные приемы. Эти приемы основываются на трех базовых идеях: модульность элементов игры, логичность и согласованность дизайна, а также сложность управления. Если эти идеи будут учтены на ранней стадии, дизайнеры сэкономят кучу времени на тестирование альфа и бета-версий.
Модульность элементов игры
Каждый механизм в игре должен служить определенным, специфичным целям и, если это возможно, единственной цели. В этом заключается идея модульности элементов. При этом, если вносить изменения в определенный механизм, это будет отражаться только на отдельном свойстве геймплея (а не сразу на нескольких).
Яркий пример продемонстрировала игра Startcraft. Ее разработчики долго ломали голову в период бета-тестинга. Blizzard (разработчик Starcraft'a) соорудил довольно простую систему повреждений. Каждый юнит обладал тремя видами повреждения: взрывчатое, нормальное и сотрясение земли. Каждый тип повреждения умножался на коэффициент в зависимости от размера юнита: взрывчатое повреждение хорошо действовало против больших целей, сотрясение земли - против небольших, нормальное - против любых. Но один юнит - Муталиск - никак не хотел поддаваться балансировке, поскольку для баланса требовалось более трех типов юнитов (вдобавок к классификации большой/средний/малый). Если отнести Муталиска к среднему типу, он становился слишком устойчивым против взрывчатых повреждений, но уязвимым против собственных собратьев (в игре Муталиски могли быть противниками). Blizzard не мог просто изменить коэффициенты взрывчатого повреждения, поскольку это нарушило бы устоявшийся баланс остальных юнитов. Разработчики не смогли изменить и значения атаки для взрывчатого повреждения, что также разрушило бы систему.
Этот факт отягощался еще одним. Муталиск использовал одну и ту же систему атаки в противовоздушном и противопехотном бою (юниты без воздушной атаки), в то время, как другие подобные юниты (разведчик, дух) имели раздельные системы, которые поддавались балансировке независимо друг от друга.
Из-за недостатка модульности в системе повреждений Муталиска, Blissard'у не удавалось его сбалансировать в течение пяти месяцев после официального выхода игры. Не потому, что ошибку исправить было невозможно, а потому что ее было трудно выявить из-за отсутствия модульности. В Starcraft'е Муталиск играл уникальную роль, и если бы разработчики Blizzard изолировали его параметры, сделали их независимым от других юнитов, они бы потратили гораздо меньше времени для балансировки. Проще всего было добавить еще один тип юнита для Муталиска. Этот тип имел бы уникальные коэффициенты устойчивости к разным повреждениям. Если бы разработчики потрудились разделить воздушную и наземную атаки Муталиска, они бы также сэкономили кучу времени.
Несомненно, по большей части, Старкрафт обладает хорошей системой модульности. В подтверждение тому можно привести юнита Spellcaster. Он наделен множеством функций, но каждая из них играет довольно специфичную роль. Тот факт, что некоторые заклинания, включая Brooding и EMP Blast, имеют очень узкую область применения, делает баланс этого персонажа намного легче.
Продуманная система модульности не является лишь подготовительным действом для достижения игрового баланса, она позволяет сделать шаг к решению проблемы. Система с хорошей модульностью позволит изменять значения отдельных параметров и это не вызовет побочных эффектов.
Логичность и согласованность дизайна
Возможно, этот принцип окажется решающим, особенно на первых порах разработки. Однако зачастую он игнорируется по политическим соображениям, по причине небрежности или просто вследствие плохой коммуникации. Принцип гласит: "если дизайн игры разработан несогласованно и не представляет собой единое целое, в лучшем случае это отвлечет пользователей от "основной сути игры"; в худшем - это полностью разрушит ядро геймплея." Яркий пример такой ситуации демонстрируют игры, разработка которых происходила либо без централизованного управления, либо слишком продолжительный период времени.
Разработчики игры MUD Duris несколько раз сталкивались с подобной проблемой. В одном случае программист взял на себя обязательства написать собственный тип персонажа, с которым ему бы хотелось поиграть. Несмотря на то, что получившийся персонаж оказался весьма привлекательным, он свел на нет множество других юнитов, поскольку значительно превосходил соперников по мощности. Всего лишь обладая набором преимуществ, персонаж разрушил монополию, которой обладали несколько других юнитов. Конечно же этому сопутствовал ряд других типичных проблем дисбаланса. Программист планировал создать персонаж, в который хотелось бы играть ему самому. Его задумка вступила в противоречие с замыслами остальных разработчиков MUD, потому и не удалось реализовать оригинальный класс, который бы являлся звеном, образуя единое целое с остальным геймплеем. Тип не был уникальным ( он обладал в разной степени преимуществами других типов персонажей ), и не мог быть согласован с остальной частью MUD.
Сложность управления
Этот принцип можно определить одной английской фразой: "keep it simple, stupid" ("делай это проще, дурачок"). Чрезмерно сложные игровые системы с трудом поддаются понимаю, а следовательно, и балансировке. Они могут появиться по двум причинам. Первая - начальный вариант дизайна оказался бедноватым, в результате чего "оброс" огромным количеством дизайнерских "заплат" ( в результате появилось множество бессвязной мишуры, которая теоретически должна работать ); вторая - известный феномен "у семи нянек дитя без глазу", сопровождающийся утратой логичности и согласованности дизайна. Сложная система управления скрывает ряд потенциальных возможностей геймплея; игроки с трудом ее понимают и не могут всецело насладиться игрой. Зачастую дизайнеры отдают предпочтение сложности, путая ее с глубиной. Это ведет к дополнительным проблемам баланса, к запутанному и непонятному геймплею.
Основной процесс создания игрового баланса
Наряду с базовыми принципами и приемами этот процесс является очень важным. Он состоит из нескольких этапов, на каждом из которых для балансировки игры используется свой набор методов.
На первом этапе игру приводят в "играбельный вид". Для этого необходима макрокалибровка, которая подразумевает неявную, приблизительную балансировку всех элементов геймплея.
Безусловно, поскольку к альфа-версии проекта большинство игр уже проходят стадию макрокалибровки, в процессе добавления новых функциональных возможностей может потребоваться рекалибровка. Erin Daly, ведущий дизайнер Homeworld, предлагает расширять геймплей группами связанных между собой функциональных элементов, над которыми и производить макрокалибровку. Считается, что это наиболее эффективный способ сохранять играбельность в процессе разработки.
По завершению стадии макрокалибровки ( в лучшем случае это происходит перед выходом альфа версии ), начинается этап микрокалибровки, окончательная стадия балансировки игры.
Макрокалибровка
Учет игрового баланса при продумывании дизайна - лишь первый шаг к сбалансированной игре. Даже самый безукоризненный дизайн требует реализации, в процессе которой просачиваются ошибки; мелкие ошибки зачастую встречаются и на начальной стадии дизайна. Вдобавок ко всему, до реализации игры большинство значений параметров нельзя предугадать. В этих ситуациях, которые обычно встречаются на этапах разработки альфа-версии, дизайнеры должны воспользоваться приемами макрокалибровки, чтобы поместить значения игровых параметров хотя бы в правильный диапазон.
Стадия макрокалибровки всегда должна быть закончена перед началом микрокалибровки: небольшие изменения в геймплее сойдут на нет и окажутся бесполезной работой, если фундамент игры все еще не стоит на твердой почве. Основная задача в период макрокалибровки - "отыскать" тот геймплей, что описан в дизайн-документе. Очевидно, нет смысла заниматься отшлифовкой, если вы еще не создали основу.
Чтобы приблизиться к искомому ядру геймплея, требуется ясно и четко определить, на что он будет похож и как это будет проявляться. Как только основная сущность игры будет раскрыта, станет возможным выделить некоторый базис (или "якорь" ("anchor"), как его называют в Ensemble Studios). Например, в пошаговой игре в качестве базиса можно использовать "приблизительный десятиминутный игровой цикл", а для прочности главного героя установить базис "три атаки от монстра должны быть смертельными". Как только вы реализуете каждый игровой элемент (ОДНУ карту, ОДИН тип персонажа, ОДИН диалог и пр.), работа которого пока удовлетворяет, расширять игру станет легче, отталкиваясь от базиса для каждого игрового элемента.
Математика баланса
Как только вы закончили макрокалибровку отдельного элемента, можно попробовать применить математику баланса и "клонировать" полученный результат для оставшихся подобных. Несмотря на то, что роль математических вычислений при достижении баланса сомнительна (очень сложно учитывать и правильно оценивать влияние множества мелких факторов), они все еще остаются полезными для применения базиса к различным элементам игры. Одна из формул, которая остается универсальной и применима почти ко всем играм - уравнение эффективности издержек/затрат.
Формула эффективности издержек/затрат утверждает. что:
Воздействие * Длительность воздействия = Эффективность
Отсюда вытекает,
Квадратный корень ( Воздействие * Длительность воздействия / (Стоимость * Стоимость ) = эффективность издержек/затрат
В качестве воздействия может выступать, например, мощность взрыва (повреждение * скорость стрельбы), или points. Под длительностью воздействия можно понимать количество раз, когда было задействовано оружие, или hitpoints. Стоимость - объем игровых ресурсов (например, золота, денег) или положение игрока в игре ("реальная" стоимость хода в шахматах).
Другая, не менее полезная формула носит название уравнение фрагментации. Она применяется, главным образом, для стратегических игр и для других "боевых" ситуаций. Формула отражает тот факт, что в бою толпа слабых юнитов, суммарная сила которых равна нескольким более сильным, на самом деле уступает последним по силе. Толпа слабых юнитов всегда будет менее эффективна. Все потому, что в период боя она постепенно теряет свою мощь (погибают отдельные юниты), в то время как жизнь одного сильного юнита длится намного дольше, и следовательно он не страдает от потери силы. Формула для вычисления относительной эффективности имеет такой вид:
Уменьшение Эффективности (более слабых юнитов) = .5 + .5(Количество сильных / Количество слабых такой же стоимости)
Инверсия результата дает значение увеличения эффективности более сильных юнитов.
Подобные формулы и другие разновидности "математики баланса", как правило, хорошо подходят для нахождения приблизительных значений параметров. Достичь полного баланса математическими методами обычно не удается. Исключение составляют лишь очень простые игровые системы. Например, сбалансировать Risk при помощи математики не составит большого труда, поскольку правила игры достаточно просты, а все возможные игровые варианты можно рассмотреть и рассчитать очень точно. Сбалансировать Монополию тоже можно, но посложнее, чем risk: большое влияние будет оказывать элемент случайности (бросание кости); кроме того, в Монополии задействовано огромное количество игровых элементов (chance cards, mortgage rules, jail, и т.п.). А описание математического способа достижения баланса для более сложных систем, таких как современные стратегии в реальном времени, будет сравнимо с докторской диссертацией.
Математика баланса остается чрезвычайно полезной в симметричных играх, таких как Warcraft 2 или Homeworld, где противостоящие стороны более менее схожи с точки зрения функционирования. Чем больше общих свойств имеют два элемента или группы элементов геймплея, тем меньше возникает параметров, которые с трудом поддаются балансировке при помощи математических формул.
Микрокалибровка
По завершению макрокалибровки переходят к точной балансировке игры. Микрокалибровка начинается, когда игра уже представляет собой нечто привлекательное и не содержит ярких проявлений дисбаланса. Процесс микрокалибровки заключается в небольших изменениях параметров для достижения полного игрового баланса. Под небольшими здесь понимаются изменения значений глобальных параметров (нечто, влияющее на несколько игровых элементов) не более чем на 10 %, и изменения значений локальных параметров (нечто, влияющее на отдельный элемент игры) не более чем на 30-40% .
Самое сложное во время микрокалибровки - определить и распознать проблему. Как только это сделано, остается немного изменить параметры, так, чтобы не вызвать новых проблем. Продуманная модульность элементов и предварительное планирование помогут сэкономить кучу времени на данном этапе: без них вряд ли удастся сбалансировать игру за установленный начальством срок.
Отслеживание дисбаланса на микро-уровне
Существует ряд приемов, позволяющих дизайнеру определить проблему. Самым очевидным здесь является длительное и упорное тестирование игры, в процессе которого выявляются находящиеся в постоянном преимуществе, а также ни разу не задействованные элементы. Другой общеизвестный прием: дизайнер обсуждает некоторые гипотетические ситуации со специалистом по тестированию или другим дизайнером, приходит к соглашению, что и как должно случиться, а затем проверяет свои предположения на практике.
Если дизайнер использует первый метод, занимаясь поиском превосходящих (или никогда не используемых) стратегий, важно точно определить причину, по которой одна стратегия всегда является выигрышной, а другая - проигрышной; и более того, понять, предполагалось или нет, что развитие игрового сюжета пойдет таким путем. Классификация дисбаланса и приведение его к одному из нескольких общеизвестных типов также поможет понять проблему. В конечном счете, чем больше известно о типе дисбаланса и его характеристиках, тем легче его устранить.
В последние годы становится популярным записывать статистику игр и результаты сражений без ведома игрока. Age Of Empires, несколько игр, выпущенных Sierra, и Strifeshadow удачно воспользовались этим приемом. Иногда подобная статистика может пролить свет на проблемы дисбаланса, иногда - ввести в заблуждение.
Все данные должны быть собраны тщательно и аккуратно. В некоторых ситуациях неопытные специалисты по тестированию могут преподнести очень искаженные результаты просто потому, что недостаточно хорошо знакомы с игрой и не опробовали все ее возможности (пробежались только по самым простым элементам геймплея). Точно так же чрезмерно опытные специалисты могут иметь собственное представление о местах возникновения дисбаланса и упустить из виду некоторые потенциально возможные стратегии. Очень эффективным приемом воспользовалась компания Ethermoon Entertainment. Данные о балансе бета-версий игры Strifeshadow были преднамеренно завышены, чтобы вдохновить игроков на поиск новых стратегий.
Второй метод иногда называют "охотой на дисбаланс". Он заключается в следующем: формулируется гипотетическая ситуация; затем договариваются, какие реакции и последствия могут в этой ситуации иметь место. Например, формулировка может быть такой: "Нападающий танк должен с небольшими потерями уничтожать легкое вражеское судно, и в то же время уступать по силе противотанковой пехотной пушке". Если в игре танк без особых трудностей разбивает вражеское судно и может устоять даже против пушки, приходят к выводу, что мощность танка слишком велика. Охота за дисбаланс очень важна, и аккуратное и точное использование этого метода позволяет выявить более 75% проблем дисбаланса на микро-уровне. То, что ожидает увидеть дизайнер и то, что происходит в игре на самом деле - это две разные вещи. Небольшое отклонение одного локального параметра может обратить баланс в дисбаланс в конкурентоспособной сетевой игре!
Во время "охоты на дисбаланс" нужно всегда учитывать одну особенность: элементы геймплея, которые были введены в игру на начальной стадии, более чувствительны к балансировке: их дисбаланс отразится на всех последующих элементах; в то время, как дисбаланс более поздних элементов геймплея породит значительно меньше проблем. Точно также как и макрокалибровку проводят перед микрокалибровкой, ранние элементы доводят до баланса перед тем, как переходят к поздним.
Балансировка игры на микро-уровне
Как только источник дисбаланса обнаружен, остается его устранить. Это очень просто... если игра обладает хорошим балансабилити. В такой системе дизайнер занимается именно устранением источника проблемы, а работа его не вызовет побочных эффектов.
Следует помнить, с изменением параметров нельзя переусердствовать, особенно когда оно направлено в сторону увеличения силы/мощности. Юнит, обладающий чрезмерной силой, может разрушить всю систему, сделав многих других юнитов бесполезными, в то время как слишком слабый элемент геймплея просто игнорируется и не оказывает влияние на игровой процесс.
Важно по возможности так выполнять балансировку, чтобы не затронуть параметры других элементов. Например, представим мага в ролевой игре "fireball". Если огненный шар слишком мощный, дизайнер может понизить силу магии огня вообще, или силу магии огня для отдельного мага. Ясно, что нашей ситуации желательно воспользоваться вторым приемом, локальным параметром, перед тем как переходить к глобальному. Приведен очень простой пример, во многих случаях будет сохраняться определенный уровень взаимодействия между игровыми объектами. Внимательно прослеживайте, на что влияет то или иное изменение, постарайтесь использовать то, что устраняет только рассматриваемую проблему и не оказывает влияние на другие элементы игры.
И еще совет. Одновременно не изменяйте значения нескольких параметров, чтобы решить одну единственную проблему. Сделать это очень трудно, и понять эффект от действия каждой отдельной переменной практически невозможно (по сути, в этом случае вы пытаетесь повлиять на одну зависимую переменную, изменяя множество независимых). Кроме того, такой подход может вызвать дополнительные проблемы, оказывая побочное влияние на другие элементы игры.
В заключение...
В процессе разработки можно погрязнуть в работе с огромным количеством элементов игры и потерять из виду конечные цели и идеи дизайнера. Сохранить изначальные задумки очень сложно, но в конечном счете нужно гарантировано получить хороший баланс и при этом уложится в сроки разработки бета-версии. Приобретают все большую популярность сетевые игры, для которых постоянно возрастает роль сбалансированного дизайна: огромное количество перспективных проектов пострадало отсутствием хорошего игрового баланса.
По материалам сайта MirGames
