Создание системы боёв в RPG +12


image

Боевые системы наших игр Rimelands: Hammer of Thor и Trulon: The Shadow Engine были высоко оценены игроками. Несмотря на то, что это два сильно отличающихся взгляда на систему боя в RPG, они имеют много общего в дизайне механик и иллюстрируют мою личную философию дизайна. В обоих играх используются пошаговые бои, но Trulon они основаны на колоде карт, а в Rimelands — на наборе кубиков. В первой вы управляете целой партией персонажей, во второй — только одним героем. У этих игр есть сходства и различия не только в боях, но в данной статье я расскажу только о базовых боевых механиках.

Rimelands: Hammer of Thor (2010)



(Скриншот из неопубликованной версии игры для PC)

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

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

Традиционно для жанра у персонажей есть различные характеристики, определяющие их шансы на успех в бою. В Rimelands базовые боевые способности называются Melee (рукопашный бой), Ranged (бой на дальней дистанции) и Magic (магия); каждая из них связана с определённым типом атак. При начале атаки игра бросает кости, их количество равно уровню способности персонажа. Каждая кость имеет четыре возможных значения: двойной удар, удар, блокировка и промах. После броска кости для атаки кости бросает защищающийся. Защищающийся использует для защиты ту же способность, что и нападающий. Если количество попаданий, выброшенных нападающим, больше, чем количество блокировок, выброшенных защищающимся, то атака завершается успехом.

Также у каждого персонажа есть две защитных характеристики: Toughness (выносливость, используется против рукопашных и дальних атак) и Deflection (уклонение, используется против магических атак). Если количество ударов после вычитания блокировок равно или больше значения выносливости/уклонения, то атака оказывается пронзающей. Пронзающие атаки не учитывают значение брони защищающегося и обычно удваивают количество наносимого урона.

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

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

Процесс создания дизайна


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

  • Какие действия выполняет игрок в каждом ходе?
  • Как система определяет результат действия?
  • Каким образом о результате узнаёт игрок?

Часто процесс создания дизайна игры не начинается с боевой системы, поэтому для ответа на эти вопросы можно уже извлечь какую-то информацию. В случае Rimelands уже было принято решение, что это игра от третьего лица с тайловой картой. Это давало мне два очевидных действия — перемещение по карте и нападение на врагов. Следующим этапом стало добавление костей, то есть я на самом деле ответил на третий вопрос до второго. Так как я уже знал, что это будет набор костей в стиле HeroQuest с символами вместо чисел, систему удалось быстро встроить в игру.

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

Значимые решения в базовой механике


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

Механики переброса костей не было в исходном дизайне игры, который очень напоминал современное переосмысление цифровой версии настольной игры HeroQuest. Изначально наглядные броски костей вводились в игру ради прозрачности игровой механики. Когда игрок видит кости, ему проще разобраться, как работает игра, без длинных туториалов и руководств.

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

Бросание костей в цифровом пространстве


Глубоко внутри Rimelands — это очень настольная игра. Хотя настольные ролевые игры портировались на компьютеры ещё с начала Dungeons and Dragons в 70-х, всегда присутствовали некоторые аспекты, которые было сложно реализовать в цифровых устройствах. Чаще всего это Dungeon Master, потому что компьютеры до сих пор не могут конкурировать в навыках и гибкости повествования с живым человеком. Ещё одним таким аспектом часто называют обычную кость.

Бросок кости в настольной игре — это на самом деле активное действие. Игрок бросает кость. Даже если мы знаем, что по большому счёту результат является случайным, часть нас всегда верит, что на самом деле можно повлиять на результат с помощью «хорошего броска» (или выбора кости). В цифровых играх кости бросает компьютер, и игрок в этом не участвует. Чтобы перенести ощущения от настольной игры на цифровую платформу, необходимо как-то обойти в дизайне это ограничение. В Rimelands мы пришли к такому решению: добавили ещё один этап обработки, на котором игрок может принять активное решение.

Жестокая развязка


Фундаментальный вопрос дизайна битв традиционной RPG заключается в следующем: как персонаж снижает жизненные ресурсы другого персонажа?

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

Бросок на удар:

Количество ударов - количество блоков > 0

Бросок на урон:

Если количество оставшихся ударов < выносливость/уклонение:

Урон = Random(мин. урон оружия, макс. урон оружия) - значение брони противника

Иначе:

Урон = Random(мин. урон оружия, макс. урон оружия)

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

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

Задаём темп пошагового боя


Один из рецензентов назвал Rimelands «пошаговой action RPG» — это определение, вероятно, появилось из-за влияния roguelike, а значит, и из-за похожести на серию Diablo и другие игры жанра action RPG. Однако с точки зрения темпа, в такой классификации есть заслуга и самой игры: ограничив персонажей всего одним действием на ход, мы в целом сделали бои достаточно короткими, даже в случае сражения с большой группой противников.

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

В отличие от более распространённой системы, использовавшейся, например, в первых двух частях Fallout, интервалы между активной и пассивной игрой значительно короче. Ещё один эффект — это снижение объёма планирования. Хотя в Rimelands определённо стоит планировать действия заранее, игрок может выполнять до изменения состояния игры очень короткие цепочки действий. Это приводит к ощущению меньшего планирования в бою, по сравнению с играми, где можно выполнять за ход несколько действий, часто для каждого персонажа в партии. Я не хочу этим сказать, что какой-то подход объективно лучше; они просто создают разные ощущения от игры.

Заключение


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

В следующей части мы обсудим те же решения в отношении дизайна карточной ролевой игры с отчётливым японским колоритом под названием Trulon: The Shadow Engine, а также расскажем о собственных любопытных моментах этой игры.

Trulon: The Shadow Engine (2015)



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

Изначально Trulon задумывалась как довольно традиционная JRPG, но постепенно превратилась в нечто более уникальное. Боевая система игры основана на картах, у каждого из персонажей есть собственные колоды. Характеристики персонажей похожи на традиционные для японских ролевых игр, например, «атака» и «нападение», определяющие величину наносимого в атаках урона.

В начале боя каждый персонаж вытягивает на руку от трёх до пяти карт, которые в игре называются «тактиками». Затем персонажи делают ходы, играя по одной карте. Действие выполняется сразу же после ввода карты в игру. Также есть две дополнительные карты: «тактика атаки» и «джокер». Персонажи всегда могут использовать тактику атаки и она никогда не пропадает. «Джокер» выбирается случайно из всех тактик в колодах всех игроков, за исключением тактик, которые могут использовать только определённые персонажи, или для которых требуется мана. После использования «джокера» он восстанавливается на следующем ходе персонажа.

Мана в мире Trulon разделена на две силы: Gaudium, рождающаяся из жизни и счастья, и Dolorum, рождающаяся из страдания. Такое разделение — важнейшая часть антуража, поэтому мне было необходимо включить его и в игровые механики. Некоторым тактикам требуется мана, и каждый персонаж может использовать только одну из двух. Использование магических тактик снижает запас маны игрока (он может быть расширен при помощи различных предметов), который не восстанавливается в бою. Это балансируется тем, что тратящие ману тактики более эффективны, чем обычные.

Базовый цикл игры


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


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

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


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

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

Третий эффект — это случайный элемент игры, добавленный для повышения вариативности боёв.

Карты как меняющееся игровое поле



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

Trulon добивается этого с помощью ограничения вариантов случайного выбора действий. Хотя в качестве резервного варианта всегда доступна тактика атаки, другие тактики созданы так, что они всегда лучше «ванильной» атаки.

Цель дизайна заключалась в разрешении одной из распространённых проблем жанра JRPG: «спамминга атаки», при которой бои часто сводятся к постоянному выбору стандартной атаки, потому что у игрока отсутствует мотивация использования навыков или ресурсов, способных истощать его запасы.

Управление случайностью


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

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

В отличие от Rimelands, над Trulon мы работали по найму, что привело к более строгому бюджету и графику. Хотя Powerpark был отличным, очень понимающим клиентом, доверяющим нам в области разработки игр, мы всё равно должны были создать нечто, во что поверил бы и заказчик. К концу альфа-версии у нас был дедлайн по созданию рабочей механики карточного боя. Если бы у нас она не получалась, мы вернулись бы к более традиционной боевой системе JRPG.

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

Критические удары


Устранение из вычислений урона случайности имело одну серьёзную проблему: оно уничтожало шанс на «критический удар». Хотя игроков раздражают случайные промахи по врагу, чрезвычайно хороший удар даёт удовлетворение на психологическом уровне. Эта дилемма привела к появлению последнего куска паззла боевой системы Trulon: карт штурма. Карты штурма — это карты со специальными эффектами, определяемыми надетым на персонажа обмундированием. В начале каждого боя пятая часть карт помечается как «Тактика штурма».

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

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


Итерации через тестирование


Обычно я разделяю тестирование на три обобщённые категории:

  • Тестирование геймплея: увлекательно ли играть в игру?
  • Тестирование Usability: достаточно ли быстро игроки понимают, как играть?
  • Тестирование функционала: всё ли работает, как задумано?

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

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

При работе над Trulon нашей целевой аудиторией были подростки, поэтому на самых ранних этапах проекта мы начали тестировать игру на людях от 13 лет и старше. Мы пришли с первой играбельной версией игры в школы (которые часто благосклонно воспринимают такие акции), чтобы получить обратную связь. Результаты в буквальном смысле изменили правила игры.

Доступность


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

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

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

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

Враги


Последний кусок головоломки боевой системы — это механика врагов. Часто механики симметричны: персонажи игрока и враги часто следуют одинаковым правилам, только врагами управляет не игрок, а ИИ. Существуют и другие способы реализации, например, асимметричные механики, ситуации, когда враги в каких-то аспектах отличаются от игрока. В одном из источников вдохновения Trulon, игре Chrono Trigger, враги, например, не используют механики комбо.

Я решил использовать в Trulon небольшую асимметрию. Враги совсем не используют тактики штурма, и у них нет руки или колоды, из которых нужно вытягивать карты (а поэтому нет и «джокера»). Вместо этого ИИ запрограммирован на использование определённых карт единожды или нужное количество раз, а различные триггеры изменяют поведение ИИ. Некоторые враги предсказуемее других, и я обнаружил, что более сложные враги должны вести себя с большим постоянством, чтобы бой с ними походил на головоломку. Например необязательный босс Hunter in the Dark меняет тактику и имеющиеся в его распоряжении карты, когда его здоровье падает ниже определённого значения. Встречаемый ранее босс перед запуском мощной специальной атаки всегда выполняет прицеливание, которое можно увидеть, если перед боем повернуть паровой вентиль.

Выводы


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

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




К сожалению, не доступен сервер mySQL