Как настраивать баланс в RPG

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

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

В RPG, особенно в тех, которые мы разрабатываем в Obsidian, очень важен принцип “выбора и следствия”. Это применимо не только к нарративной составляющей игры, но и для геймплея: создание персонажа, его развитие, тактическое применение его умений и способностей на практике. Если мы хорошо делаем свою работу, то в каждой игре игроки будут чувствовать удовлетворение от сильных сторон персонажа и дискомфорт от его слабостей. Игровые задачи сложно сбалансировать для широкого круга игроков, так что идеальный баланс создается на грани стресса и легкого разочарования, вызываемых психическими препятствиями. Игроки изучают препятствие, расматривают варианты его преодоления, делают выбор, и в конечном итоге преодолевают препятствие, преобразуя таким образом стресс в радость от собственной изобретательности.

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

Какие решения от игроков мы хотим получить?

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

Есть два уровня, на которых обычно игроки принимают решения такого рода. Первый уровень эстетический и концептуальный: «Маги прикольные», «Быть сильным круто».

Второй уровень – механический или рациональный: «Высокий урон – это важно», «Важно иметь целителя», «Дебафф может сыграть большую роль в бою».

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

Выбросьте мусор

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

На дворе 2014 год, и я хочу сказать вам, что «мусорные» опции – это лажа.

Любая идея проходит несколько десятков циклов: от прототипирования, до тестирования и переработки. Уходят месяцы разработки, но результат только вредит геймплею и отталкивает пользователей.

Лучший способ избежать проблемы – посмотреть на игру глазами опытного пользователя и спросить себя, зачем бы ему выбирать ту или иную опцию, чем та или иная характеристика может быть полезна. Чтобы оставить опцию, вы должны получить доказательство ее необходимости. Ни в коем случае не стоит идти от обратного и останавливаться на отсутствии аргументов «против». Если нет ярких аргументов «за», то вы делаете что-то лишнее и от этого можно отказаться.

В качестве примера рассмотрим игру Pillars of Eternity. У нас есть булава и стеганый жилет – две вещи, которым во многих RPG уделяется довольно мало внимания. В большинстве игр булавы медленные и наносят небольшой урон. В Pillars of Eternity они наносят не меньше урона, чем любое другое одноручное оружие, обладают весомым преимуществом, сильно повреждая доспехи врагов. Мечи могут наносить различные типы повреждений, пики являются очень точным оружием, боевые топоры наносят самый сильный критический урон, но и для булавы нашлась своя геймплейная «фишка», которая будет мотивировать пользователей использовать ее.

Со стегаными жилетами в RPG дела обстоят еще хуже – обычно это самые слабые доспехи. Как правило, они ужасны и на эстетическом уровне, и с точки зрения механики – это просто квинтэссенция «мусорной» опции в RPG. Игрок вынужден носить стеганый жилет в самом начале игры, и с радостью выбросит его, как только подвернется что-то более интересное. В игре Pillars of Eternity стеганки представляют собой довольно приличную защиту. Это немного не соответствует реальной жизни (в реальности эта одежда мало чем полезна в бою), но нашей целью было подстроиться под интересы игроков, а не достичь правдоподобности.

Да, в Pillars of Eternity более тяжелые доспехи выдерживают больше урона. Однако, чем тяжелее доспехи, тем дольше персонаж оправляется от атаки или заклинания. Так что, хоть персонаж в кольчуге защищен лучше, чем персонаж в стеганном жилете, но второй успеет произвести больше действий за единицу времени.

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

Также мы намеренно избегали классического для RPG противостояния «уклонение от удара» (т.е. уворот) против «уменьшения урона». Несмотря на то, что концептуально эта идея довольно проста, на уровне игровой механики она неинтересна, если только вы не интересуетесь табличными данными того, как кривая понижения урона со временем становится менее эффективной.

Да, игра «в цифры» может быть интересна, но игроку должен предлагаться очевидный компромисс, чтобы выбор между опциями был более значимым.

Теория на бумаге

Рано или поздно, чтобы проанализировать диапазон и объем ценностей в системе, их взаимодействие, вам потребуется получить математические данные. Мы установили себе цели и начали обрабатывать цифры и формулы (зачастую с помощью таблиц), чтобы сравнить и оценить прогресс. Этот процесс помогает нам понять, как именно система будет работать. Таким образом мы распознаем возникающие процессы, иногда хорошие, иногда не очень, и пересматриваем их, прежде чем внедрять что-либо.

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

В играх Fallout: New Vegas и Pillars of Eternity мы пользовались Excel, чтобы проводить эксперименты с различным уровнем урона и моделями доспехов. Но даже после внедрения мы сохранили эти данные, чтобы в будущем иметь возможность экспериментировать и адаптировать систему.

Внимание: когда мы разрабатываем новые системы, мы внимательно подходим к тому, как много исходных данных надо ввести в формулу, или из скольки значений она будет состоять. Разработчики RPG обычно создают формулы со слишком большим количеством исходных данных, что сильно усложняет отладку игры в дальнейшем. Чтобы избежать этого, мы пытаемся сохранить нашу первоначальную формулу настолько простой, насколько это возможно. Это облегчает настройку системы и в целом делает ее понятнее для игроков.

О внедрении

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

Обеспечение качества

Чтобы убедиться, что все работает так, как задумано, мы прибегаем к помощи QA. То, что все работает как надо, вовсе не означает, что игра стала интересной, однако если основная функциональность не проверена QA, то пытаться балансировать игру просто бессмысленно.

Тестирование в условиях эксплуатации

Первые реальные попытки балансировки игры должны начинаться только после того, как вся основная функциональность уже как-то реализована. Ещё неплохо тестировать идеи с помощью «серого ящика», но сам баланс не начнет работать в игре до тех пор, пока различные игровые системы не сработаются вместе.

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

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

Отладка системы

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

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

Отклоняющиеся значения в контенте

Когда игра тестируется, разработчики и QA начинают выделять опции, имеющие отклонения и проблемы. Например, проблемными являются те опции, которые игроки либо никогда не выбирают (никак не влияют на исход), либо наоборот. И тот и другой вариант не подходит.

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

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

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

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

Если проблема еще не исправлена, то мы начинаем изучать, что может отбить интерес игрока к данной опции. И снова пример со стеганкой. Конечно, она добавляет маневренности, но вдруг у нее слабая защита? Тогда мы снижаем урон, тестируем, и двигаемся дальше.

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

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

Удваивание и располовинивание

Как мы отлаживаем игру? Способ, предложенный Сидом Мейером: удваивание и деление пополам. Многим во время отладки кажется, что лучше применять маленькие пошаговые изменения. Но обычно это не отлаженный процесс.

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

Отладка игры после ее запуска

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

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

Все эти чувства

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

Это звучит довольно абстрактно, но важно понимать – игра в итоге становится источником ощущений. Причина, по которой мы постоянно что-то меняем или отлаживаем, не в том, чтобы достичь мифического «идеального баланса», а в том, чтобы сделать игру такой, чтобы пользователь получал от неё удовлетворение.

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

Примечание редактора: у нас в гостях был Джош Сойер – гейм-дизайнер из Obsidian. Если вы тоже желаете поделиться опытом , свяжитесь jason@kotaku.com.

Перевод — А. Мальков, оригинал — здесь.