Джош Сойер: Как сбалансировать ролевую игру
Зачем баланс в однопользовательской игре? Многие игроки считают этот вопрос риторическим, но есть немало причин, по которым стоит стремиться к хорошему балансу даже в однопользовательских ролевых играх. Балансировка заключается не только в выяснении, какой способ развития персонажа более эффективен, но и в понимании различных видов препятствий, которые будут возникать перед ним на протяжении игры.
В идеале, у каждого метода развития есть свои достоинства и недостатки, которые проявляются в тех или иных игровых ситуациях, однако в целом каждый персонаж должен быть в той или иной мере жизнеспособен. Никто не захочет потратить 40 часов на персонажа с неудачным вариантом развития, равно как и случайно обнаружить, что выбранный персонаж валит всех одной левой.
Ролевые игры, особенно от Obsidian, строятся на концепции выборов и последствий. Она используется не только при построении повествования, но и в элементах игрового процесса: создании персонажа, его развитии, применении способностей и навыков. Если всё сделать хорошо, игрок почувствует сильные и слабые стороны своего персонажа, и останется доволен. Балансировка сложности игры для широкой аудитории игроков — задача отнюдь не из лёгких, и в идеале в игре должны присутствовать короткие моменты напряжения и лёгкого удивления от поставленной задачи. Игрок изучает задачу, рассматривает варианты её решения, делает выбор, тем самым преодолевая возникшее препятствие и заменяя напряжение ощущением собственной изобретательности.
С чего же всё начинается? В моём случае, это ответ на вопрос:
Какие решения может принимать игрок?
Я имею в виду не только банальные вопросы вроде выбора между силой и обаянием, классами воина и разбойника, мечом и топором, но и критерии, которые приводят к подобным решениям. Критерии могут быть значительными, как при выборе между боевым классом с высоким уроном и полагающимся на дипломатию мирным, так и менее важными, например, между скоростью атаки и повреждениями при критическом попадании.
Есть два уровня, на которых принимаются такого рода решения. Первый — это эстетический, или концептуальный: «Маги круты», «Скучно сражаться дубиной» или «Хочу быть сильным».
Второй — механический, или рациональный: «Необходимо добиться большого урона», «Мне нужен целитель», «Эффекты ослабления очень помогают в сражениях».
Разные игроки относятся к этим уровням по-разному, но в самом идеальном случае выбор в пользу эстетического удовольствия должен быть жизнеспособным, и наоборот, рациональный выбор должен быть интересен. Когда этого не происходит, игроки остаются недовольны, ведь им приходится играть нравящимся им персонажем, который плохо согласуется с механикой игры или отказываться от приглянувшегося образа в пользу большей эффективности. Для ролевой игры такой поворот событий, мягко говоря, не очень желателен. Вот почему вы можете перейти к следующему этапу только после того, как ответите на вопрос, почему игрок может захотеть выбрать любой из предложенных ему вариантов.
Выносите мусор
Мусорные варианты или варианты-ловушки долгое время оставались традицией ролевых игр, как настольных, так и компьютерных. Мусорные варианты — это решения, которые намеренно были созданы неудачными или не были проработаны должным образом, чтобы стать жизнеспособными.
На дворе 2014 год, и вы знаете, я должен сказать: мусорные варианты — это полное дерьмо.
В любой компьютерной RPG мусор, возникший в голове проектировщика и попавший в окончательную версию игры, вероятно, прошёл несколько десятков этапов реализации, тестирования и пересмотра. Таким образом, мусорный вариант можно прямо назвать не иначе как вылизанным говном. Любой ветеран ролевых игр поймёт это с первого взгляда и никогда не выберет для своего персонажа. Не столь опытные игроки, плохо разбирающиеся в механиках ролевых игр, могут поддаться впечатлению обманчивой полезности выбранного варианта, но в любом случае его существование в игре не окупит затраченного на него времени.
Несмотря на то, что некоторые мусорные варианты всё равно просачиваются в крупные ролевые проекты, лучшим способом избежать этого я считаю ответ на вопрос, почему хорошо информированный игрок должен выбрать именно этот вариант, а не какой-либо другой. Для это всегда должна быть как эстетическая/концептуальная, так и игромеханическая причина. Если чего-то не хватает, нужно прорабатывать вариант до тех пор, пока он не начнёт вас удовлетворять. Однако это не всегда возможно. В таком случае вы быстро осознаете, что вариант стал мусорным (то есть, не подходит игроку как по эстетическим, так и по механическим параметрам), и исключите его из разработки до того, как на него будут потрачены большие силы.
Возьмём в качестве примера булаву и стёганую броню — две вещи, бесполезные в большинстве ролевых игр. Обычно булавы медлительны и наносят мало урона, что компенсируется несколькими полезными свойствами. В Pillars of Eternity они наносят столько же урона, сколько и другие виды одноручного оружия, но при этом игнорируют какую-то часть защиты противника. Мечи наносят разные виды урона, копья невероятно точны, боевые топоры имеют высокие повреждения при критическом попадании, при этом булавы являются вполне жизнеспособным вариантом, не хуже прочих.
Стёганая броня обычно ещё хуже: во многих играх она играет роль слабейшей защиты. Выглядит она некрасиво, а в игровой механике её роль ничтожна — идеальное воплощение мусорного варианта — и если игроков заставляют носить её в самом начале игры, то они при первой же возможности меняют её на что-то другое. В Pillars of Eternity стёганая броня предоставляет достойный уровень защиты. Можно, конечно, сказать, что в игре она защищает персонажа даже сильнее, чем это было бы в настоящей жизни, однако для нас важна не столько реалистичность, сколько увлекательность игрового процесса.
В то время как тяжёлая броня поглощает больше урона, этот вид доспехов в Pillars of Eternity замедляет процесс восстановления после атаки или чтения заклинания. Персонаж в кольчуге защищён лучше, чем персонаж в стёганой броне, однако последний сможет выполнить больше действий за определённый промежуток времени.
Этот основополагающий и в то же время понятный компромисс («получить меньше урона или делать больше»), имеющий одинаковое значение для всех персонажей. Каждый персонаж выполняет какие-то действия, а потому ускорение их выполнения выгодно для всех. И в то же время, всем персонажам нужна защита. Тем не менее, выбор между защитой и скоростью перемещения будет иметь разные последствия для ориентирующегося на ближний бой варвара и предпочитающего сражаться на расстоянии мага.
Мы также постарались избежать характерного для классических ролевых игр выбора между поглощением урона и уклонением от него. Эту концепцию легко понять, однако механически она неинтересна, если только вы не решите закопаться в таблицы с целью выяснить эффективность поглощения урона на протяжении всей игры. Игра в таблицы сама по себе может быть весьма увлекательной, но всегда должен быть очевидный компромисс, понятный с первого взгляда.
Теория на бумаге
Рано или поздно, практические аспекты проектирования потребуют создания математической основы для понимания масштабов и диапазонов значений в системе, и их взаимодействия между собой. Поставив перед собой чёткие цели, мы начали работать над черновыми формулами и значениями, используя таблицы и различные математические операции с целью сравнения чисел и оценки прогрессий. Таким образом, мы начали лучше понимать, как будут работать наши механики. Начали появляться первые закономерности — иногда хорошие, но чаще плохие — и исправлять их нужно было до того, как мы приступим к их реализации.
Существует опасная тенденция уделять этому этапу больше времени, чем того следует. Мы хотели убедиться, что спроектированные нами механики хорошо работают, и только после этого приступить к их реализации. Даже хорошо составленные таблицы не передают того, как будут работать механики в контексте игрового окружения.
Разрабатывая Fallout: New Vegas и Pillars of Eternity, мы экспериментировали с различными видами урона и защит в таблицах Excel. И даже после реализации этих механик в игре, мы сохранили таблицы для дальнейших экспериментов.
Обратите внимание: разрабатывая системы, мы старательно следим за количеством входных данных в различных формулах, а также значениями, принимаемыми отдельными её переменными. В ролевых играх нередко возникает проблема переизбытка входящих данных, что делает настройку систем крайне трудоёмкой процедурой. Чтобы избежать этого, мы старались сохранять основные формулы как можно более простыми. Это облегчило не только дальнейшую их настройку, но и понимание игроками механик.
Реализация в общих чертах
После того, как проектирование на бумаге подошло к концу, а инженеры оценили стоимость проекта, можно приступать к реализации задуманного. На данном этапе происходит грубая настройка систем. Различия намеренно преувеличиваются, чтобы стать хорошо заметными. Если что-то должно двигаться быстро, мы делаем его очень быстрым. Если что-то должно наносить большие повреждения, пусть они будут гораздо выше всех остальных. Зайдя слишком далеко, вы всегда можете вернуться и двинуться к намеченной цели небольшими шажками. В этот момент перед нами не стоит задача балансировки игры, мы лишь должны убедиться, что все основные классы, виды оружия, заклинания и монстры ведут себя так, как положено.
Проверка качества
Чтобы убедиться, что всё работает как задумано, мы привлекаем специально обученных людей. Эти люди занимаются тестирование игры по заранее подготовленному плану. Разумеется, само по себе то, что всё работает как задумано, ещё не означает, что это будет интересно само по себе или в сочетании с другими механиками, но до тех пор, пока не будет протестирована основная функциональность игры, продолжать дальше не имеет смысла.
Полевые испытания
Первые серьёзные усилия по балансировке систем начинают применяться лишь после того, как определена основная функциональность и установлены взаимосвязи между различными системами, иными словами, игра начала обретать свою форму. Хорошей идеей может быть тестирование по принципу «серого ящика», однако найти правильный баланс не получится до тех пор, пока многочисленные системы игры не заработают в среде настоящих игровых уровней.
В ролевых играх многие сценарии подразумевают совместную работу нескольких систем — особенно это относится к боевым сценариям. Уровень персонажа, его класс, навыки и их уровни развития, здоровье, меткость, защита, поглощение урона, улучшение доступных игроку предметов, анимация, частота атак, скорость перемещения, доступ к второстепенным членам команды и их способностям — и всё это не считая противников.
Во время полевых испытаний разработчики и тестировщики начинают замечать разного рода закономерности. Одни представляют собой проблемы с общеигровыми механиками, другие же — отдельные проблемы. Следом за изменением роста здоровья в зависимости от уровня персонажа может полностью измениться сложность средней и заключительной частей игры. Если увеличение наносимого игроком урона не соответствует росту здоровья противников, это общеигровая проблема. Если какой-то вид оружия не может пробить броню противника — это отдельная проблема.
Настройка механик
Изменение механик оказывает огромное влияние на ощущения от игрового процесса. Изменение скорости атаки повлечёт за собой не только изменение скорости сражения, но и передвижения на местности. Если изменить количество получаемого за уровень здоровья, то начиная с середины игры сложность изменится катастрофически. Изменив частоту выпадения определённых видов снаряжения, мы можем заставить игрока экономить или дать возможность купаться в деньгах.
В случае с Pillars of Eternity, мы старались как можно сильнее ограничить объём входящих данных, поэтому количество возможных настроек каждой подсистемы оказалось небольшим. Мы всегда начинали с наиболее значимых формул и переменных, изменение которых приводило к далеко идущим последствиям. Подобрав правильные значения, мы переходили к менее значимым вещам.
Исключения — всегда или никогда
Продолжая играть, разработчики и тестировщики начинают видеть решения, которые можно назвать исключениями. Такого рода решения принимаются всегда или никогда. Так или иначе, ситуацию приходится исправлять.
Некоторые варианты предоставляют настолько очевидные преимущества, что остальные меркнут на их фоне, и выбор становится автоматическим. Если баланс игры строится вокруг одного очевидно выгодного решения, то для всех остальных вариантов она оказывается несбалансированной.
Если игрок отказывается воспользоваться каким-либо вариантом, значит у него есть недостаток — эстетический или механический (чаще всего механический, поскольку прожжённые игроки зачастую не обращают внимания на эстетическую сторону вопроса, если это сулит им большие выгоды). Несмотря на все наши усилия, иногда такое случается.
Рассматривая исключения, мы должны убедиться в том, что у решения есть некая характеристика, способная склонить к нему игрока. Если стёганая броня хороша тем, что позволяет персонажу действовать быстрее, то настолько ли заметна разница в скорости, чтобы оправдать её существование? Если прибавка к скорости мала, или, наоборот, велика, требуется настройка. Изменив необходимые значения, мы вновь тестируем механику, чтобы определить, перестала ли она быть исключением.
Обратите внимание, что за раз мы изменяем лишь одно значение. Если изменить два и больше, мы не сможем точно определить источник проблемы и можем даже столкнуться с новыми.
Если проблема никуда не исчезла, мы берём наиболее заметное свойство, удерживающее игрока от принятия решения. В случае со стёганой бронёй таким свойством может оказаться поглощение урона. Да, персонаж в стёганой броне может быть быстр, однако предоставляемая бронёй защита окажется не лучше, чем от бумажного пакета. Обнаружив это, мы увеличим поглощение урона, протестируем новые значения и двинемся дальше.
Однако мы должны не только сделать вариант жизнеспособным, но и сохранить его концепцию и идею. Изменяя параметры кувалды, можно добиться того, что персонаж будет наносить ею серии быстрых, но слабых ударов. Такой вариант может быть вполне сбалансированным, но большинство людей ожидают от кувалды немного другого, а именно медленных и тяжёлых ударов.
Примечание. Изменение механик до выхода игры и после значительно отличаются. До выхода игры мы можем свободно вносить практически любые изменения. Если что-то кажется нам излишне мощным, нет никакой проблемы в том, чтобы уменьшить параметры в несколько раз. Но как только игра попала в руки игроков, такие действия могут привести к выплеску отрицательных эмоций (ведь любимую игрушку внезапно ослабили). Поэтому мы с большей готовностью ослабляем что-то очень мощное, чем усиливаем более слабое.
Вдвое или надвое
Каким образом мы настраиваем механики? По методу Сида Мейера: удваиваем или делим пополам. Большинству людей инстинкт подсказывает необходимость вносить небольшие и постепенные изменения, однако этот способ нельзя назвать эффективным. Практически всегда быстрее оказывается умножение или деление значения определённой переменной на два, с последующей тонкой доводкой. Персонаж двигается слишком медленно? Удвоим скорость. Класс получает мало здоровья на уровень? Удвоить! Оружие наносит слишком много урона? Уменьшим повреждения в два раза. Слишком много противников в сражении? Убрать половину.
Если вы видите, что зашли слишком далеко, всегда можно вернуться назад. Проведя достаточное количество испытаний и циклов настройки, мы добиваемся того, что все механики и игровые материалы оказываются жизнеспособными и не противоречащими логике. Теперь мы готовы отправить игру на полки магазинов.
Изменения после выхода игры
Даже разработчики с огромным штатом тестировщиков неизбежно сталкиваются с проблемами, и это никого не должно удивлять. Количество игроков, в руки которых попадёт ваша игра, превзойдёт команду тестировщиков любого размера, в соотношении сто к одному. Они обязательно сделают нечто такое, о чём разработчики даже не догадывались, либо у них не было времени это проверить.
После выхода игры есть лишь два пути для внесения правок. Наиболее очевидным является обновление игры. Обновление игр на консолях значительно сложнее, чем на ПК, требует большого количества времени и денег, поэтому количество попыток сделать всё правильно резко сокращается. Как результат, мы должны быть абсолютно уверены в правильности вносимых изменений прежде, чем приступать к обновлению игры. Следующего шанса может уже не быть.
После того, как разработчики заканчивают работу над игрой и переходят к следующим проектам, в дело вступает сообщество мододелов. Будучи проектировщиком, я никогда не позволяю чему-либо оставаться в том положении, чтобы для исправления требовалось устанавливать модификации. Тем не менее, уследить за всем и исправить не всегда возможно, даже при помощи обновлений. Кроме того, игрокам могут попросту не понравиться принятые нами решения. Мы пытаемся удовлетворить сотни тысяч, а иногда даже миллионы игроков. У всех разные вкусы, а модификации как раз и позволяют ставить над игрой эксперименты и настраивать игру под свои личные предпочтения.
Чувства игроков
Наша высшая цель — сделать так, чтобы вне зависимости от сделанного выбора, игрок остался доволен. Это абстрактная концепция, но любую игру можно представить как последовательность впечатлений. Все эти настройки и подгонки — не стремление к балансу ради баланса, это желание, чтобы игрок остался доволен игрой. Есть множество эстетических и механических элементов, составляющих основу доступных для игрока решений, мы же стараемся сделать так, чтобы выбор игрока соответствовал его представлениям о собственном персонаже и помогал преодолевать препятствия, не делая эти препятствия бессмысленными.
via core-rpg.net
