Об использовании основной архитектуры игры при прототипировании

Devlog#16

Доброго дня, Граждане Земли!

С вами команда Rummy Games, и это очередной Дневник разработчика.

Мы немного запоздали с выкладыванием этого дневника, но лучше позже, чем никогда)

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

О себе

На проекте я занимаю роль технического геймдизайнера и лида команды программистов UE4.

О проекте

Saturated Outer Space - тактическая пошаговая стратегия с элементами RPG. Игра имеет 2 основных геймплейных режима: пошаговый (как в XCOM) и реалтайм (как в Mutant Year Zero). Игровых режимов я коснусь отдельно ниже. Помимо этих двух в игре есть еще режим “хаб” в виде промежутка между миссиями на космическом корабле. Но его в этом посте я касаться не буду.

Чем делюсь, не претендуя на авторитетное мнение

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

Что такое прототипирование?

Прототипирование является широким понятием, поэтому в контексте этой статьи я разделю его на 3 категории:

1. Прототипирование окружения.

2. Прототипирование игровых механик.

3. Прототипирование игровых систем, связанных напрямую с пользовательским опытом (UX).

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

Метрики

В самом начале разработки основной архитектуры игры, которая по задумке должна превратиться в вертикальный срез, мне нужно было описать инструментарий для создания блокаутов уровней, опираясь на то, что в игре будет пошаговый режим, в котором должны соблюдаться правила жесткой привязки объектов геометрии к тайлам. Забегая вперед, скажу, что мы в команде решили использовать комбинированный подход при создании блокаутов. Мы совмещаем жестко привязанную к тайловой сетке геометрию с геометрией, которая не влияет на тайловую навигацию и Line of Sight (видимость) в пошаговых боях:

Некоторые вопросы для самопроверки:

Для поиска ответов мне потребовалось провести немало времени в различных пошаговых играх, наблюдая за тем, как работает техническая сторона игры. Это очень помогло понять, в каком направлении нужно двигаться при создании инструментария размещения - настройки геометрии на уровнях. Еще для меня было важно, что некоторые из рассматриваемых игр были разработаны на Unreal Engine 4. Если есть понимание, как работает движок, то нетрудно уловить общие паттерны и убедиться, что идешь верной дорогой при разработке (или не верной).

Вернемся к вопросам. После изучения игр-конкурентов было решено создать тайл с комбинированными размерами и разделить его на 2 области:

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

Чем у нас отличается толстая геометрия от тонкой:

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

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

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

Стоит отметить, что полезно иметь отдельную карту, на которой будут расположены все те же объекты геометрии, но только в виде Box Brush. Это сильно помогает, если нужно изменить метрики у уже имеющейся геометрии и создать новые статик меши.

С оптимальной высотой стен и дверных проемов было сложнее всего, так как нужно было сразу учитывать высоту/ширину самого большого персонажа в игре и параметры камеры (угол наклона и высоту). Работу с камерой я затрону отдельно. Для измерения высоты можно использовать разные инструменты, некоторые создают специальные меши-помощники, которые сразу имеют конкретные размеры (1м, 2м и тд.). В данном случае я использовал самых высоких персонажей, которые были доступны, и дополнительный слой тайловой сетки, который можно поднять на любую высоту и получить общую картину по высотам на всем уровне:

Подведем итог по инструментарию для левелдизайна. В нашем случае инструменты изначально были вплетены в основную архитектуру игры, т.к. очень важно иметь стандартизированную систему разработки уровней на самых начальных этапах, чтобы левелдизайнеры сразу привыкали к основным метрикам. К тайловой системе у нас привязаны почти все игровые логики, для игры это фундамент. Не буду врать, что при разработке инструмента мы использовали только C++, блюпринты применялись для быстрой проверки некоторых гипотез, а после прохождения стадии Proof of concept почти весь низкоуровневый код переносился на C++.

Небольшое видео с демонстрацией работы инструментария: https://youtu.be/b13vls81NeI

Прототипирование игровой механики на примере способности броска гранаты

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

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

Вопросы для самопроверки:

1. Какие методы, ивенты, переменные или классы из основной архитектуры доступны в блюпринтах? Насколько сложно будет встроить маленький прототип в большую систему? И есть ли смысл?

2.Как будет работать таргетинг в случае с гранатой? Обычно это сфера, целями которой являются пересекающие ее объекты, либо объекты, которые находятся на условном участке с размерами 3 на 3 тайла;

3. Нужна ли физика полета гранаты? Каким будет поведение гранаты при броске? Будет ли столкновение с другими объектами?

Вопрос встраиваемости всегда индивидуален, для этого мы стараемся по возможности всегда открывать доступ к логике, которая написана на C++. В случае со способностью броска гранаты есть ряд методов, которые требуется переопределить в блюпринтах, вызвать распознование цели (возможна атака или нет), ну и применить необходимые модификаторы (отнять HP у цели и очки действия у юнита игрока). Показывать код смысла нет, здесь идея только в доступности низкоуровневых логик из блюпринтов. Если прототипирование механики занимает неоправданно большое количество времени по причине того, что программист должен отвлекаться от других дел, открывая доступ к переменным, то, имеет смысл:

а) прототипировать механику, не касаясь основной архитектуры;

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

По моему мнению, лучше всего сразу писать код таким образом, чтобы в дальнейшем образовалось как можно меньше мест, где нужно поставить UPROPERTY или UFUNCTION.

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

Но есть альтернативный способ выбора целей - подсветка тайлов, как это было в XCOM:

В случае с XCOM урон получат только те цели, которые стоят на конкретных тайлах, но визуально будет ясно, что круг гранаты частично покрывает еще несколько тайлов, которые не учитываются системой. Сейчас мы пока сделали первый вариант, так как он кажется более понятным для игрока, в нем нет пустых мест, которые есть в случае с XCOM. Но наш вариант плохо подходит для оружия или инструментов, которые могут накладывать или снимать эффект с площади, или зависят от дальности поражения. Например, если огнетушитель частично обрезает тайлы с огнем, это будет выглядеть странно. Напротив, огнетушитель, который работает как граната из XCOM, смотрится гораздо честнее.Еще одним этапом работы над способностью гранаты было определение ее поведения во время полета. На этапе прототипирования сразу стало понятно, что симуляция физики полета вообще не нужна из-за того, что бой всегда пошаговый. Достаточно было рассчитать траекторию полета для гранаты и оторвать ее от руки в момент броска. Дальше анимация полета через Timeline все сама сделает. Когда граната долетает до конечной точки траектории, вызывается событие взрыва:https://youtu.be/YHo3zt3OYB8Итог по прототипированию игровых механик:

Прототипирование камеры

Сразу скажу, что на сегодня у нас есть 2 камеры. Каждая камера привязана к своему режиму игры и имеет Top Down перспективу:

1. Камера для пошагового боя. Летает по карте свободно, не прикреплена к персонажам;

2. Камера для режима реалтайм. Прикреплена к выбранному персонажу, ограничена в наклоне, поворот вокруг оси Z свободный. Самый близкие примеры - Mutant Year Zero или Divinity Original Sin (игра с геймпада).

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

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

Итоги прототипирования камеры сильно затронули метрики высоты на уровне. Базовая геометрия опустилась с 5 м до 3.6 м. Можно сравнить, насколько иной была геометрия перед завершением работ по камере и после.

До:

После:

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

Итог

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

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

До новых встреч!

Мы в Steam -

Мы в Twitter - @mvmvgames

Мы в Reddit - https://www.reddit.com/user/mvmvgames

Мы в VK - https://vk.com/saturatedouterspace