Гайд: как и зачем деконструировать механики из чужих игр
Геймдизайнерам часто приходится изучать игры конкурентов, чтобы находить удачные решения для собственных проектов и избегать распространённых ошибок.
Один из главных приёмов, которым они пользуются, — деконструкция игровых механик. В чём состоит процесс деконструкции и почему он так важен, рассказывает старший геймдизайнер Allods Team и ментор курса XYZ School «Продюсирование игр» Кирилл Золовкин.
Введение в тему: атомарные и комплексные игровые механики
Игровая механика — это способ взаимодействия с игрой по заданным геймдизайнером правилам. Другими словами, это конкретное действие игрока и те изменения игровой среды, которые оно за собой влечёт.
Геймдизайнер должен обладать богатой игровой эрудицией, чтобы подбирать лучшие механики для своих проектов. Игры, из которых дизайнер берёт решения, могут быть из совершенно разных эпох, ведь многие механики живут десятилетиями.
Например, классический индикатор жизней за время своего существования прошёл множество итераций. Во времена игровых автоматов он представлял собой количество попыток в виде сердечек или других иконок. Когда они заканчивались, игрок закидывал новую монетку в автомат и возрождался с полными жизнями.
Другой, более современный вариант реализации той же механики — отображение виньеток по периметру экрана в тех случаях, когда игрок получает урон. Такой визуальный индикатор опасности можно встретить в Gears of War, Call of Duty, Uncharted 4 и других современных экшенах, где здоровье восстанавливается автоматически.
Базовые механики, подобные шкале здоровья, принято называть атомарными. Они могут складываться в более сложные системы, которые называют комплексными механиками. Например, получение урона от вражеских атак — это комплексная игровая механика, которая включает в себя сразу несколько систем:
- шкала здоровья и манипуляции с ней (убавление и восполнение);
- способности игрока (возможность уклоняться от пуль, парировать удары и т.д.);
- временные аффекты: баффы (временные усилители), дебаффы (временные негативные эффекты) и правила их наложения;
- система экипировки: может ли игрок надеть доспех, который поглотит часть урона?
- воздействие на основные системы: как различные типы урона влияют на состояния игрока? Могут ли остановить или замедлить его (мультипликатор на скорость)? Могут ли перевести из состояния атаки в состояние кулдауна?
Процесс деконструкции заключается в том, чтобы разобрать подобную комплексную механику на составляющие, проанализировать каждый из её компонентов, внести нужные изменения и пересобрать её заново для собственного проекта.
Ищем референсы
Процесс деконструкции механик начинается с поиска игр-референсов. Вы определяете жанр собственной игры и составляете список тегов, которые её характеризуют, а затем ищите по тем же тегам похожие игры. Вот, например, как выглядит список тегов у Cyberpunk 2077 (посмотреть его можно на странице игры в Steam).
При отборе игр-референсов нужно учитывать их рейтинги и объём продаж. Если вы будете опираться на игры, которые уже полюбились игрокам, продались большим тиражом и получили хорошие отзывы критиков, то вы снизите риски дизайнерских ошибок.
Конечно, можно пойти путём изобретения новых механик — в инди-студиях такая тактика является чуть ли не основным способом выделиться. Но в студиях покрупнее на первый план обычно выходит качество проработки и поиск новых сочетаний уже проверенных механик. Взять хотя бы Genshin Impact или Immortals Fenyx Rising. Обе эти RPG используют механики карабканья и глайдинга (парения в воздухе). Решение реализовать их могло бы считаться рискованным, если бы не The Legend of Zelda: Breath of the Wild, которая три года назад доказала играбельность обеих механик.
Итак, вы подобрали 3-5 успешных референсов, посмотрели лестплеи на YouTube и нашли в них нужные механики, которые собираетесь деконструировать. Следующий шаг — самому поиграть в эти игры, чтобы получить пользовательский опыт. Только так вы сможете разобраться, что интересного есть в предложенных механиках и в чём их фан.
Не ставьте себе слишком общих задач охватить всё и сразу. Если вы изучаете «вход в игру» (первые 30 минут геймплея), сосредоточьтесь на них. Если ваша задача — более глубокие механики, раскрывающиеся после пяти часов игры, придётся пройти эти 5 часов или скачать сейв. Главное — получить игровой опыт, испытать ощущения игрока.
Приступаем к деконструкции
Предположим, что мы работаем над новой игрой и хотим реализовать в ней такую же механику поведения камеры, как в Genshin Impact, но с некоторыми улучшениями. Для этого нам понадобится записать на видео все возможные варианты поведения камеры, которые мы могли наблюдать во время прохождения игры. Для записи можно использовать Nvidia ShadowPlay или OBS — это софт, уже зарекомендовавший себя среди стримеров.
Все ролики необходимо собрать в одной папке, желательно, в облаке. Из облачных сервисов можем посоветовать Облако Mail.ru, Яндекс.Диск, Google Drive, OneDrive или Dropbox. Для удобства можно установить их клиентские приложения, чтобы иметь доступ к облаку в проводнике компьютера.
Собрав и упорядочив ролики, мы понимаем, что у камеры есть несколько режимов поведения, которые активируются по определённым триггерам:
- Режим по умолчанию: камера следует за игроком на заданной дистанции, отдельный стик или мышь управляет её вращением по орбите игрока.
- С зажатой кнопкой прицеливания: камера улетает за плечо игрока и перемещается как в шутерах при использовании кнопки вращения.
- При нажатии на кнопку быстрой атаки: камера выхватывает ближайшего противника, не упуская игрока из поля зрения. Принудительно поворачивается (в отличие от режима по умолчанию), чтобы показать противника.
- При карабканье: камера отдаляется, увеличивая радиус вращения вокруг игрока.
- При открытом инвентаре: камера перемещается за спину игрока и застывает там.
- В катсценах: камера либо резко прыгает на нужный ракурс (управление камерой при этом отбирается), либо плавно перетекает, держа в центре объект внимания.
Каждый из режимов необходимо снабдить ссылкой на соответствующее видео в облаке. В процессе добавления видеороликов структура схемы может меняться.
Теперь, когда мы зафиксировали в схеме все режимы и особенности поведения камеры, пройдёмся ещё раз и отсечём лишние ветки (принцип бритвы Оккама). На этом этапе важно правильно обобщить разные с виду сущности, сведя их одному общему параметру:
- Плавное отдаление камеры в режиме карабканья или резкое отдаление и приближение камеры из-за выпада игрока — это изменение одних и тех же параметров: радиуса и скорости. Когда изменения столь незначительны, их можно объединить в один режим с двумя переменными.
- Во время сюжетных катсцен (вроде диалогов) и коротких синематиков, демонстрирующих важные объекты, игрок теряет управление и камера сама направляется в заданную точку. Следовательно, эти режимы можно определить как два подтипа одного кинематографического режима. Разница между ними — всего один параметр: камера или резко переключается в кинематографический режим, или плавно перетекает в него.
- Крафтинг у костра с открытием инвентаря — это тоже частный случай катсцены, когда управление камерой блокируется. Будь там альтернативное поведение (например, как в RDR2), мы бы вынесли его в отдельный режим. Но в нашем случае в этом нет необходимости.
В итоге наша диаграмма приобретает вот такой вид:
Не забывайте указывать в комментариях к диаграмме все параметры и переменные, которые встречались вам в процессе создания схемы. Позже их нужно будет указать в документации. В нашем случае получился такой список:
- CameraMovementRadius — радиус камеры в режиме движения;
- CameraMovementSpeed — максимальная скорость, с которой камера движется за игроком (процесс замедления и ускорения можно задавать по кривой);
- CameraAimPosition — положение камеры относительно игрока в процессе прицеливания;
- CameraClimbingRadius — радиус, на который отлетает камера, когда игрок карабкается;
- и другие...
Наша задача на этапе визуализации механики — внести в схему все особенности поведения камеры и правильно их сгруппировать. Главное преимущество от использования UML-диаграмм состоит в том, что вы в любой момент можете добавлять новые элементы и быстро менять их структуру. После того, как диаграмма примет свой окончательный вид, она ляжет в основу дизайнерской документации.
Пишем дизайн-документ
Последний этап нашей работы — это подготовка дизайн-документа, в котором будет описана техническая спецификация поведения камеры. В каком формате его готовить — зависит от инфраструктуры конкретной компании. Это может быть документ Word или Google Docs, но чаще всего для этих целей используется вики-система Confluence.
Преимущество Confluence в его нелинейности. Он позволяет добавлять в дизайн-документацию разделы, кросс-ссылки, примечания, вложенные страницы и многое другое. Это гораздо удобнее, чем работать с линейным документом.
Вы вольны сами решать, как представить схему работы камеры: в виде отдельных страниц на каждый режим или закладок внутри одной страницы. Главное, чтобы ваша схема была понятна человеку, читающему её впервые. Вот что для этого понадобится:
- Автоматическое оглавление: его обычно вставляют в начале страницы.
- Правильное форматирование: чтобы построить правильную иерархию, заголовкам должен быть задан корректный стиль (Заголовок 1, 2, 3 и т.д.).
- Абзац аннотации, который введёт в суть дела и объяснит квинтэссенцию механики. Вот пример: «Камера в Genshin Impact по умолчанию следует за персонажем, держась от него на заданном радиусе. Она свободно вращается по двум осям с помощью отдельного стика или курсора мыши на ПК. В некоторых режимах Атаки переходит в вид от плеча (режим Прицеливания) или отдаляется, включая противника в обзор (режим Автоприцеливания)».
- Перечень всех режимов камеры в виде списка: Движение, Прицельная Атака, Автоатака и др. Сюда же необходимо добавить схему их взаимосвязей (картинка из Miro).
- Табы или страницы с подробным описанием каждого режима.
- Ссылки на референсы в теле документа или в его конце. Помните, что референс — это уже вырезанный фрагмент, прошедший вашу модерацию и максимально точно характеризующий то, что вы хотите увидеть в вашей игре. Нельзя просто написать программисту: «Сделай камеру как в The Legend of Zelda». Нужно разобрать механику на составляющие и выбрать конкретные фрагменты геймплея, которые эти составляющие проиллюстрируют.
Готовый документ нужно прикрепить к истории в таск-трекере (Jira, Asana, Youtrack), чтобы он ушел в работу в отделы продакшена. Хорошо оформленная и подробная документация — залог того, что все участники команды правильно поймут ваш замысел и успешно его реализуют.
Итог
Деконструкция механики — это комплексный процесс, который включает в себя описание её компонентов, их взаимосвязи и принципов работы. Но помимо этого вы также должны уметь фиксировать свои впечатления от механики (что могло быть лучше, что конфликтует) и строить предположения о том, как механика работает за кадром. Чем богаче ваш игровой опыт, тем лучше у вас это будет получаться. Умение мыслить абстрактно и проводить параллели между механиками в разных играх — важный скилл, над развитием которого нужно работать.
Ведь в конечном счёте ваша задача — не бездумно скопировать игру, а проанализировать её, перенять чужой опыт и воспользоваться им в создании собственной механики.
Материалы по теме
1. Andrey Panfilov, How to Deconstruct Games Better
2. Michail Katkoff, Mid-Core Success Part 1: Core Loops
3. Will Luton, Deconstructing Supercell’s match-3: Hay Day Pop
Материал подготовлен командой XYZ Media.
Материал - хороший, а школа - плохая. Деньги платить ресурсу, чтобы там ну коменты потереть, есть, а ученикам обманутым вернуть - денег нет. Айайай