Дизайним абилки как в X-COM

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

Я разработчик с 16-летним опытом, который участвовал в разработке различных игр, включая мобильный клон X-COM. Помимо игр, я разрабатываю и продаю компоненты и инструменты для игр. Одним из таких инструментов является редактор игровых данных Charon, на основе которого в этой статье будут приведены примеры. Это не означает, что без этого редактора статья бесполезна, так как аналогичный результат вы можете получить, используя JSON/XML/YAML файлы и любой язык программирования для реализации.

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

Способом активации абилки может быть указание себя в качестве цели (Self), указание на некую игровую сущность (Target), указание точки на игровом поле (Ground) или событие (Triggered).

У абилки есть эффекты, каждый из которых указывает на того, на кого он применяется во время активации абилки. Он может применяться к инициатору действия (Self), на указанную цель (Target) или на цель в зоне поражения (Impact) для Ground абилок. К примеру, выстрел RPG может наносить урон всем, кто попал в зону поражения (Effect: Impact → -Damage / 2), и дополнительный урон по тому, в кого он нацелен (Effect: Target → -Damage).

Эффект применяется на игровые сущности и остается на них, если не указано, что он временный (см. ниже). Для Ranged Attack это будет урон, который вычитается из HP. После применения эффекта факт его применения записывается в игровую сущность и сохраняется до конца боя.

Для более сложных механик эффекты можно расширить дополнительными полями и поведением, и получить яды, бонусу, штрафы и статус-эффекты.

Только для реализации атаки вам понадобится в X-COM-подобной игре иметь игровые сущности с такими атрибутами, как HP, Action Points, Ammo In Magazine. Почему не "персонажи", а "игровые сущности"? Я использую этот термин для более широкого охвата того, на кого/что может быть нацелена абилка, например, персонажи, бочки, двери, мины, турели, которые тоже могут иметь HP, очки действия, патроны и т.д.

Для примера рассмотрим такую способность, как Ranged Attack, которая состоит из одного эффекта - HP = -context.Self.RangedWeapon.Damage. Конечно, чтобы эту способность не использовали много раз подряд за один ход, ей нужна "цена" (Cost) использования в каком-либо восполняемом ресурсе. Этим ресурсом будут очки действия (Action Points) и патроны в магазине (Ammo In Magazine).

Что такое context.Self.RangedWeapon.Damage? Это формула или выражение, без них сделать систему гибкой будет сложнее. Гейм-дизайнеры довольно быстро учатся писать простые формулы и выражения, особенно если им предоставить документацию и список готовых выражений. Не скупитесь на документацию формул.

В пару к Ranged Attack дизайним Reload, которая будет восполнять патроны в магазине за счет одного очка действия. Эффектом перезарядки будет восполнение патронов в магазине до максимальной вместимости магазина (Magazine Capacity). Максимальная вместимость магазина – это еще один атрибут игровой сущности, на основе которого можно создать навыки/бонусы/штрафы к его вместимости. А через его временное обнуление можно реализовать запрет на стрельбу и подобные способности.

Дополнением к атаке и перезарядке будет способность Throw Grenade , тип цели у нее – Ground, цена – в очках действия. Так как эта способность в игре появляется только когда оперативник берет с собой расходник Grenade, то мы ограничим ее применение одним разом за бой. Это будет еще один параметр способности "количество использований" (Uses Per Battle), который подходит для расходных материалов или чрезвычайно мощных способностей. У этой способности будет еще один новый параметр "зона поражения" (Impact Zone), который определяет форму и размер зоны поражения, в которой будут применены эффекты. Этот параметр можно выразить через построение геометрической фигуры – Impact Zone = shape.Sphere(min: 0, max: 10) или через список заранее определенных зон поражения, из которых можно выбирать.

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

К вопросу: откуда вообще берутся абилки у оперативника? Они поступают с предметами, которые надеты на куклу оперативника на этапе подготовки к миссии.

У предмета может быть список абилок, которые он предоставляет. К примеру, у винтовки это будет Ranged Attack и Reload, у гранаты — Throw Grenade. В дополнение к этому, навыки, полученные за уровень, тоже могут быть предметами, которые надеты на оперативника и предоставляют абилки.

Уже в бою абилки со всех этих предметов и псевдо-предметов собираются, сортируются и предоставляются внизу экрана для игрока.

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

Некоторые абилки бывают настолько мощны, что для баланса игры их применение требует ограничений. Одно из таких ограничений — это "откат" (Cooldown). Это время, обычно в ходах, через которое можно повторно активировать абилку. Где Cooldown → 0, это значит, что активировать можно сразу, а Cooldown → 1 — только на следующий ход, Cooldown → 2 — после следующего хода и т.д.

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

Иногда абилкам требуется дополнительное условие для активации, не только стоимость, тогда их можно расширить кастомным условием применения (Use Condition).

К примеру: Fire Rocket не может быть использована, если персонаж двигался.

Аналогично можно ограничить применимость абилки на цель и добавить условие применение на цель (Target Condition).

К примеру: Лечащая абилка может проверять, что цель - союзник, Executioner требует, чтобы цель имела меньше 50% HP.

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

Для эффектов можно добавлять условия их применения на цель через Effect Apply Condition.

К примеру: HEAT Ammo наносит двойной урон роботам.

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

Расширив эффекты с помощью поля Status Effect, можно ввести механику статусных эффектов. Статусные эффекты — это флаги на игровой сущности, меняющие её поведение, не в количественных параметрах. К примеру, "заморозка", уменьшающая дальность передвижения, "оглушение", отключающее обновление очков действия в начале хода, и т.д. Для "вдохновения" можно посмотреть Wiki по Dota 2 или League of Legends.

Эффект, который накладывает флаг статусного эффекта, обычно имеет длительность в ходах или времени. Через указанное Duration эффект удаляется с игровой сущности, и флаги статусных эффектов пересчитываются. Эффект можно не удалять, а только помечать как неактивный или пропускать при Duration = 0, т.к. потом его можно использовать для подсчёта статистики и достижений.

Эффекты с отложенным временем применения, которые можно использовать для стеков, проклятий и подобных механик.

Немного изменив поведение Duration и Duration Unit, можно получить яды, горение и другие механики урона, зависящего от ходов/времени. Также на этом же механизме можно построить проклятия, т.к. Duration Unit может быть и Shot, Got Hit, Got Miss, Reload и т.д. Каждый раз, когда происходит событие Duration Unit такого эффекта, из Duration вычитается единица, создаётся дубликат этого эффекта с изменённым Application Time на Instant и применяется к сущности, на которую был наложен оригинальный эффект.

Бонусы, зависящие от событий/триггеров, лучше делать через пассивные способности (см. ниже).

Самый простой и логичный способ применения значения эффекта к игровой сущности — это прибавление к текущему значению атрибута значения из эффекта. Этого может быть достаточно для урона/лечения и простых бонусов, например, +2 к точности. Для более масштабируемых бонусов лучше подойдут проценты, для которых требуется другой метод применения значения — умножение (Multiply). С помощью операции Multiply можно реализовать проценты, как множители, так и делители. Чтобы в вашей игре не появлялись магические константы типа 9999 урона и т.д., когда нужно убить персонажа, используйте операцию Set для установки атрибута сущности в определённое значение. Это позволит сбрасывать значения атрибутов (например, HP → 0 или HP → Max HP), не привлекая внимания санитаров.

Формула расчёта финального значения атрибута:

Для реализации резистов непосредственно из абилок можно добавить еще одно поле в эффекты — атрибут уменьшение значения эффекта (Value Reduction Attribute), указывающее на атрибут игровой сущности, который является множителем значения эффекта, тем самым снижая или увеличивая урон/лечение, которое повлечёт за собой эффект.

Value Reduction Attribute — это коэффициент, где 1.0 соответствует 100% резисту урону, 0.0 — 0% резисту урону, а -0.1 обозначает усиление на 10%.

Даже лечение стоит реализовывать через Value Reduction Attribute и предусматривать сопротивление к лечению, что позволит реализовать запрет на лечение или снизить его эффективность. К примеру, можно создать Arrow of Ilmater из BG3, которая отключает лечение на один ход.

Формула расчёта финального значения атрибута:

Некоторые абилки предоставляют постоянный бонус в начале боя и не требуют активации игроком. Другие абилки дают свой бонус при определенных событиях или условиях и должны быть активированы не в ход игрока. Такие абилки называются пассивками и реакциями. Для их реализации нужен явный запрет на активацию игроком в коде и механизм событий и триггеров, а в дизайне — дополнительное поле с указанием триггера. Таким триггером может быть начало боя, начало раунда, получение/нанесение урона, промах, перезарядка, движение и т.д. Каждый триггер, который вы реализуете, увеличит комбинаторное многообразие механик для геймдизайнера. Эта же логика может быть использована для отсчета Duration Unit на эффектах.

В зависимости от триггера контекст того, кто есть Self и кто Target, может меняться, и это надо тщательно документировать. К примеру, для триггера "Was Hit" непонятно, кто будет для эффектов Self — стреляющий или тот, в кого стреляли?

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

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

Например, как были сделаны мины в одной из наших игр. Установка мины — это Ground абилка, у которой нет эффектов. В коде при активации в указанной точке карты создается игровая сущность Mine, и она входит в команду активировавшего игрока. У мины с момента "рождения" есть 4 абилки: Ranged Attack, Overwatch, Throw Grenade и Martyr. Последняя абилка в разных играх называется по-разному, но суть её в том, что персонаж, умирая, бросает под себя гранату. Итак, наша мина после создания встаёт на Overwatch с радиусом, совпадающим с радиусом взрыва гранаты. При пробегании врага через Overwatch, мина стреляет в него и наносит себе (!) фатальный урон, после мина (!) достаёт гранату и кидает под себя. Вуаля.

Гейм-дизайнеры в одной из наших игр создали самостоятельно около 450 абилок (включая скучные на подобие +5% к меткости) и только 50 потребовали дополнительного кода.

JSON для импорта в Charon - Game Data Editor → тут

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

Кода с реализацией не будет, т. к. нет универсального варианта который подойдет для каждой игры.