Создание инди-хоррора: опыт авторов Uventa

Советы начинающим разработчикам.

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

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

Всем привет! Мы команда Black Rat, наша первая игра Uventa буквально только что вышла в Steam. Среди инди-разработчиков много профессионалов, которые просто решили создать что-то своё. Но это не наш случай. В игровой индустрии из нас никто и никогда не работал. Мы подумали, что вам будет интересно узнать взгляд на геймдев с точки зрения совсем зелёных новичков. Возможно, наши ошибки помогут другим таким же энтузиастам избежать многих подводных камней.

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

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

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

Нашей первой ошибкой стало то, что мы начали создавать локации не из обычных примитивов, а сразу приступили делать готовые ассеты. В итоге столкнулись с массой проблем. Одна из них — архитектура. Например, NPC не могли пройти в некоторых местах или не замечали главного героя из-за слишком узкого проема в коридоре.

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

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

И, хотя у нас и было свыше двух тысяч фото, порой этого было недостаточно, чтобы суметь сделать полноценную модель предмета или окружения. Поэтому мы специально выезжали на заброшенные участки и в заброшенные здания, чтобы можно было всё сфотографировать и посмотреть, как это выглядит в живую. Отдельный плюс таких выездов в том, что ты ещё можешь взять рулетку и измерить модель по всем координатам и не терять время на угадывания размеров тех или иных деталей. Со временем, конечно, опыт работы с пропорциями приходит, но нам, как новичкам, было тяжело всё определять на глаз. Для создания моделей мы использовали 3ds Max, ZBrush, Substance Painter.

В качестве эксперимента мы ещё использовали Photoshop для создания текстур, но быстро перешли в итоге на Substance Painter. Он хорош тем, то что у него сразу есть готовые смарт-материалы, а это экономит немало времени при текстурировании различных моделей (плюс ещё многое можно скачать с официального сайта). С помощью ZBrush делали простую детализацию для моделей, качали кисти, и всячески пытались её улучшить, чтобы она выглядела как можно лучше и реалистичнее. На наш взгляд, ZBrush сложноват для начинающих в плане быстрого освоения, но для создания простой детализации он нам очень помог.

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

Тут мы столкнулись с проблемой. У аниматора не было возможно проверить свою работу сразу в движке Unreal Engine. Это приводило к тому, что анимация выглядела в игре иначе, либо неправильно взаимодействовала с окружением. Мы использовали Blender, но для UE мы бы порекомендовали Maya.

Например, нам нужно было, чтобы персонаж оставался на том месте, где заканчивается анимация, параллельно крутясь на 180 градусов. Обычная анимация даёт просто визуализацию того, как персонаж двигается, но капсула твоего персонажа останется на месте. Решением было использование Root Motion. Оно позволяло двигать капсулу вместе с анимацией.

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

Основной совет здесь в том, чтобы не откладывать работу со светом на последний момент. Добавьте к этому, что у нас не было концептов помещений (что облегчило бы задачу) и то, что тестирование требовало немало времени. Если у вас слабый ПК, то «запекание» света для всего проекта может занимать от нескольких часов до целого дня.

Сейчас геймеры часто критикуют, если на средних настройках игра не выдаёт 60 FPS. Это огромная проблема для инди-разработчиков. Обязательно следите за количеством полигонов, которые присутствуют на карте одновременно и разделяйте вашу карту на Level Streaming (мы не сразу стали этим стали заниматься и потеряли немало времени). Чем больше индивидуальных материалов — тем больше нагрузка. Тоже самое касается и ваших карт света, чем меньше — тем лучше.

Мы постоянно искали какие-то сбалансированные решения — использовали текстуры с меньшим разрешением, смотрели, не вредит ли это внешнему виду нашего объекта. Словом, старайтесь поддерживать баланс между красотой и оптимизацией.

Отдельно стоит упомянуть Level Streaming. В процессе его использования у нас постоянно возникал вопрос: как делить карту и какие дополнительные уровни нужны для комфортной работы в проекте. К сожалению, мы не смогли воспользоваться всеми его возможностями в Uventa, но зато неплохо его освоили. С помощью Level Streaming вы делите свой уровень на куски, причём некоторые из них могут содержать только код или только звуки, что очень полезно.

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

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

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