Hail to the Rainbow. Разработка игры длиною в вечность
Вступление.
Всем привет! Меня зовут Сергей Носков, я являюсь разработчиком инди-игр. Вот уже пятый год я веду разработку своего проекта под названием Hail to The Rainbow. Имею в портфолио такие игры как The Light, 35ММ, The Train, , а также 7th Sector. Текущая работа ведется с 2020 года, очень длительный срок, долгий и кропотливый труд, который наконец подходит к своему завершению. Hail to the Rainbow это научно- фантастическая адвенчура в сеттинге отечественного киберпанк постапокалипсиса. История одинокого юноши по имени Игнат, выживающего в тяжёлых условиях новой действительности.
Поскольку в моей работе где-то на горизонте уже виден финал, а несколько дней назад в Steam вышло DEMO проекта (игру уже можно пощупать), я решил создать цикл статей на тему разработки , где хотел бы поделиться историей создания, техническими моментами, кейсами, связанными с неожиданными трудностями и тд. Также, хотелось бы затронуть и моральный аспект, столь длительная работа неизбежно пробуждает целый ансамбль эмоций, настроений, ощущений, взлётов и падений. Должен сказать, что порой с этим весьма трудно справляться и процесс требует большой выдержки.
Немного предыстории.
В 2018 году я выпустил в релиз проект 7th Sector. Это был экспериментальный для меня жанр, киберпанк платформер с пазлами на логику и скорость реакции. Игра не оправдала ожиданий и не вызвала большого отклика, однако для меня лично она имела большое значение. Если предыдущие проекты в плане проработки вселенной были достаточно поверхностны, многое делалось по наитию, логика мира не была детально продумана, то в случае с 7th Sector вселенная имела под собой неплохую основу. Хотя в проекте не всё было раскрыто полноценно, персонаж имел мотивацию, мир и некоторые действующие лица имели предысторию и у происходящего была определённая логика, по крайней мере в моем представлении. Это была история о мрачном футуристичном мире в киберпанк стилистике, с роботами, странными технологиями и тоталитарной системой в комплекте.
Постер игры 7th Sector
Тем не менее, работа не выстрелила, публику особо не зацепила. Провал огорчил, но почему-то ещё больше подогрел интерес к тематике. Это и побудило на создание новой, пятой по счету игры Hail to the Rainbow. Теперь это не платформер , а приключение с видом от первого лица с элементами шутера. Я решил задействовать те приемы, что уже неплохо показали себя ранее, в моих предыдущих играх: упор на атмосфере, погружение в историю от лица главного героя, хоррорные элементы, драматическая составляющая истории.
Работа началась сразу после релиза ремейка игры The Light в 2019 году. Так повелось, что разработку я веду практически в соло. Конечно, говорить, что игра создана одним человеком, как иногда пишут, будет неверно, в проекте задействован композитор, актёры озвучки, иногда есть и сторонняя помощь в моделинге, но это небольшой процент. Весь основной контент игры уже традиционно создаётся самостоятельно. Люди иногда задаются вопросом, зачем делать в одного, если можно с кем-то скооперироваться и сделать качественнее и быстрее. В комментариях часто предлагают обратиться в студию за качественными анимациями и кат-сценами, нанять программиста и т.д. Но для меня именно в этом соль, мне нравится процесс, нравится самостоятельно погружаться в каждую сферу, будь то работа с графикой или скриптами. Работая над игрой, я полноценно проживаю всю её историю, прорабатываю каждую деталь и получаю специфический моральный профит от выполненных задач.
Ко всему прочему вдохновляет и ощущение того, что ты приобретаешь опыт и навыки разных областей деятельности , поднимаешь свой уровень. Интересная особенность, приступая к новому проекту каждый раз присутствует иллюзия, что сейчас-то я применю свои новые навыки и работа пойдёт быстрее. Но по мере роста опыта растёт и требовательность к результату. По итогу, время разработки лишь растягивается. Для сравнения на мои первые проекты уходило от полугода до двух лет. Текущая игра в работе уже пятый год… Серьёзный срок, за это время мы многое успели пережить.
Подготовка.
Вернусь непосредственно к проекту, разработку я решил продолжить на движке Unity, как и в случае со всеми предыдущими проектами. За годы работы привыкаешь к инструменту и выработанным методам , мне достаточно сложно менять привычки, поэтому с переходом на Unreal (о котором я уже давно думаю) было решено повременить. Раньше я начинал проекты от частного к общему, иногда в прямом смысле создание игры начиналось с моделинга какой-то локации или объекта и лишь потом я выстраивал структуру проекта, управление, сюжет и тд. В случае с «Радугой» я пошел от общего к частному. Изначально была концепция того, что будет представлять из себя игра, в чем задумка, кто является главным героем и каковы основные механики. Сюжет я длительное время расписывал в разных формах, в заметках телефона, в файле -документе и письменно от руки в тетради. Постоянно делал какие-то зарисовки, небольшие записи и пометки.
Концепт Игната (персонажа Радуги) и некоторые наброски
С самого начала я задумывал эту игру как весьма мрачную и драматичную историю. В этот раз главным героем стал молодой парнишка по имени Игнат. Мне показалось интересной идеей — сделать героя не крепким маскулинным борцом со злом, а вполне уязвимым мальчишкой, для которого любая стычка с врагом может представлять серьёзную опасность. При этом игрок может по-настоящему погрузиться в подобного персонажа, вспоминая себя в юном возрасте и то, как мы фантазируя разыгрывали на детских площадках какие то приключенческие сценки. В качестве референсов для антуража и вселенной в целом, в ход пошли образы мира Half-Life 2, Blade Runner, работы Simon Stallenhug и многое другое, перечислять всё не буду, поскольку источников вдохновения было действительно великое множество. Все наброски и задумки периодически приходилось сгребать в одну кучу и пытаться структурировать, приходилось также сразу ориентироваться на возможности, что-то отсеивалось по причине высокой сложности исполнения, что-то откладывалось «на подумать».
Первые шаги.
Непосредственно работу в движке я начал с создания полигона и блокинга уровней. На собственном опыте со временем понимаешь, насколько это важные аспекты. Игра с видом от первого лица и сперва создавался основной контроллер персонажа с минимумом функций, который в дальнейшем обрастал всё новыми элементами. У меня был опыт использования простой капсулы с Rigidbody, но в этот раз я взял за основу Character Controller. На полигоне отрабатывалось перемещение персонажа, прыжки, преодоление препятствий, реакции на приземление и тд. Также настраивалась высота самого перса и базовые высоты разных элементов локаций : дверных проёмов , предметов под которыми можно пройти в приседе, например столов, предметов на которые можно сходу запрыгнуть.
Часть тестового полигона в движке
Параллельно я приступил и к другому важному пункту. Как говорится «театр начинается с вешалки», а игра в каком-то смысле начинается с меню. На базе предшествующего опыта, опять же, я понял, что крайне удобно в самом начале создать базовую структуру меню, загрузки сцен и сохранений, настроек и тд. Всё это изначально выглядит как черновые заглушки и болванки. Я наметил структуру основных системных компонентов, каждый из компонентов крепился на свой объект, чтобы можно было легче искать поиском. Сперва шёл объект и скрипт, отвечающий за само меню, за кнопки, иконки, настройки. Далее объект сохранения, в его компоненте происходило всё, что связано с сохранением данных (для моих задач вполне было достаточно системы Player Prefs) . Затем объект локализации, его компонент считывал файл локализации и создавал список, что — то вроде библиотеки с текстами разных категорий. Далее я ещё вернусь к теме локализации более подробно.
Уже после создания меню, парочки тестовых уровней, создания префаба самого персонажа можно в штатном режиме запускать игру, нужный уровень и отрабатывать на нём какой- либо функционал. На каждом уровне также находился компонент, управляющий сценой, в нём прописаны различные события, с его помощью запускаются кат сцены, анимации, спавнятся персонажи (для спавна есть ещё отдельный компонент) , активируются триггеры и т. д. Также на сцене имелся свой объект для управления сохранениями. В нём были списки для нескольких основных категорий объектов сцены: дверей и их состояний (открыто/закрыто, если закрыто то как именно) , предметов, которые можно подбирать и объектов с которыми можно взаимодействовать, например технических пазлов. Также в сохранение шло и состояние триггеров на сцене, например триггеров каких-то событий или монологов напарника. Да, как в Атомик Харт у главного героя есть напарник, беседующий с ним по радио связи, но держим в уме, что я начал разработку задолго до выхода Атомика :)
Вообще для меня система сохранений до сих пор является достаточно сложной темой, поэтому подробно я свой принцип описывать не буду, дабы не подкидывать ошибочных и кривых идей. Скажу лишь, что для упрощения задачи я снова решил использовать систему чекпоинтов. В этом случае отпадает необходимость записывать большое количество данных в любой рандомный момент игры, а некоторые события и изменения на новых чекпоинтах я просто прописывал в скрипте, не опираясь на сейвы. Данные персонажа, наличие предметов, количество жизней и прочее записывалось с индивидуальным айди для каждого чекпоинта. Например для главы 2 и чекпоинта 5 в этой главе мы пишем уровень жизни героя в переменной под названием — health_2_5, которая идёт в Player Prefs.
Сохраненные переменные
Персонаж.
В целом, весьма замороченной в этот раз для меня стала система персонажа. Поскольку он должен был содержать в себе большое количество переменных и состояний, его контроллер раздулся со временем до гигантских объемов. Помимо уровня жизни герой имел индикатор температуры, уровень заряда батареи (она используется для взаимодействия с приборами, техническими пазлами и девайсами, а также для работы фонаря) , уровень усталости, несколько основных предметов инвентаря, которые можно регулярно использовать, детектор, дрон, оружие, а также большое количество разных предметов, квестовых и рядовых, в том числе расходников. Есть также ряд постоянных функций, таких как проверка рейкастом препятствий впереди, проверка коллайдера над персонажем, чтобы игрок мог встать из сидячего положения, проверка поверхности, по которой идёт персонаж, для проигрывания звуков шагов и многое другое. Во всём выше описанном достаточно ощутимой проблемой становится отсутствие порядка, когда контроллер инвентаря и состояний персонажа переполняется функциями (, а в моём случае порядка мало и скрипты оформлены весьма хаотично) , начинается путаница и ты сам порой перестаешь понимать, где и что находится. Поэтому, важно соблюдать структуру и иерархию.
Префаб игрока с набором предметов
Структурно персонаж в Hail to the Rainbow также оказался весьма сложен. Как говорилось ранее, для управления движением использовался Character Controller. У компонента персонажа есть режим полного контроля над управлением, а также частичного, когда в определенный момент герой плавно замирает и его камера поворачивается в нужную сторону, например для акцента на каком-либо событии или объекте. Этот же режим используется при взаимодействии с устройствами и пазлами, когда персонаж замораживается и глядит на целевой объект, например монитор компьютера, электронную книгу и т.д.
Многим известна сложность с реализацией рук с видом от первого лица, иногда предмет в руках, например оружие, проходит сквозь объекты перед игроком. Для избежания подобного приходится либо делать руки очень маленькими, либо добавлять анимацию прижимания рук ближе к телу игрока, либо обращаться к другим более хитрым методам. Я мониторил некоторые варианты, были предложения рендера на разных слоях двумя камерами, был и вариант изменения последовательности отрисовки рук с помощью скрипта и специального шейдера, но к сожалению в моём случае в данных методах обнаруживались неочевидные на первый взгляд подводные камни. Мне пришлось остановиться на первоначальном варианте с маленьким масштабом и анимацией отведения. Заготовку самих рук я сделал на начальных этапах разработки, чтобы постепенно обновлять их и добавлять новые анимации. Количество анимаций со временем приблизилось к сотне. Они включали в себя взаимодействие с некоторыми квестовыми предметами, управление основными предметами инвентаря, вроде аптечки, детектора и оружия, перебирание перекладин лестницы в процессе подъемов и спусков, взаимодействие с некоторыми пазлами и т. д. Древо анимаций рук в аниматоре разрослось до внушительных масштабов. Длительное время, в предыдущих проектах я продолжал использовать старую систему анимаций Unity, но в столь сложной структуре движений без системы Аниматор было не обойтись.
Анимация взаимодействия рук персонажа
На этом пожалуй все. В следующей статье я подробнее затрону тему визуала и освещения в проекте. Поскольку в игре не применялись современные техники глобального освещения и все делалось по старым принципам, было использовано много интересных приемов, связанных с лайтмапами и рилтайм светильниками. Нестандартные технические решения всегда интересно разобрать .
Всем спасибо за внимание! Буду рад гостям в социальных сетях и благодарен за добавление проекта в вишлист!
