Как создаются игры. Основы разработки для начинающих игроделов - Григорий Радовильский

в целом делают по одному и тому же пайплайну, при производстве какой-то отдельной модели вполне может возникнуть какая-нибудь непреодолимая проблема.

Это особенно важно на этапе вертикального среза, ведь может так получиться, что мы просто не обладаем необходимыми навыками и ресурсами для реализации какого-то объекта в соответствии с разработанной концепцией. А значит, нам нужно либо восполнить пробел в виде недостающих навыков – нанять исполнителя, обратиться к помощи аутсорса, подучиться, – либо что-то изменить в концепции объекта, а может быть, и всей игры.

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

По мере принятия этапов реализации отдельных элементов игры наш прототип начнет обрастать «мясом». Кубики будут заменяться предметами и персонажами, простые механизмы взаимодействия – более сложными. Разработка одного объекта игрового мира может требовать большого количества разноплановых навыков. Так, для создания простой двери может понадобиться работа не только художника, но и программиста, не говоря уже о дизайнере уровней. Идея итеративности и здесь должна нам помочь. Ведь чтобы расположить дверь на уровне и заняться разработкой механизма взаимодействия с ней, нам не нужен финальный арт этой двери. Все, что нам требуется для начала, – это финальные характеристики: какого она будет размера, как будет открываться, с какой скоростью, в какую сторону.

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

* * *

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

Остается лишь удостовериться в том, что выбранные нами методы разработки игры сходятся с доступными нам ресурсами. Может так случиться, что производство всего намеченного для игры контента не умещается в ограниченный бюджет или лимит времени. Есть два решения этой проблемы: либо резать контент, либо оптимизировать производство. Оба варианта подразумевают, что мы откатываемся лишь к началу этапа вертикального среза, а результаты этапов концептирования и прототипирования остаются неизменными. Первый вариант может потребовать переделки многих концептуальных моментов типа сценария и устройства создаваемого в игре мира. Второй же вариант может касаться качества ассетов, сложности игровых систем или необходимости обратиться к аутсорсу. Вместо высококачественных моделей персонажей можно использовать низкополигональную стилизацию. Чтобы избежать проблем с лицевой анимацией, можно нарядить всех персонажей в маски. Можно упростить боевую систему и сократить количество анимаций и оружия.

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

Важно не забывать, что финальное качество подразумевается не только для отдельных игровых механик, объектов и ассетов, но и для игры в целом. Количество багов должно быть сведено к минимуму. А значит, на этом этапе проекту будет требоваться полноценное тестирование, а команде – тестировщики. И сам процесс тестирования, вероятно, нуждается в изучении и разработке собственного пайплайна, встраивания его в пайплайны других компонентов, что может повлиять на продолжительность их производства. При этом, учитывая имеющиеся ограничения по времени и бюджету, очевидно, что вычистить из игры все баги, скорее всего, не получится, они будут накапливаться и переходить на следующие этапы производства.

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

Производство

И вот мы, наконец, добрались до производства нашей игры – самого скучного этапа всего процесса разработки. Всевозможные эксперименты с игровыми механиками и различными графическими стилями должны остаться позади. На предыдущих этапах мы проделали очень серьезную работу, чтобы прийти к этому моменту хорошо подготовленными и не ждать никаких сюрпризов. У нас должен быть готовый план производства и отлаженный конвейер (набор пайплайнов), готовые списки игровых объектов, уровней, персонажей, предметов, математическая модель, которая позволит придать персонажам и предметам какие-то ролевые характеристики, сценарий, описывающий игровой мир и происходящие в нем события. Осталась, казалось бы, сущая мелочь: реализовать задуманный план, используя разработанные инструменты. Пришло время делать саму игру.

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

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

Патч (patch – «заплатка»), или обновление (update), – это данные, которые вносят изменения в компьютерные файлы. Обычно выпускаются после выхода игры, чтобы исправить какие-либо баги и проблемы, возникшие у игроков, а также для внесения улучшений и оптимизации производительности проекта. Обычно это не слишком большие изменения, если же в игру нужно внести масштабные изменения, используют DLC (downloadable content – «загружаемый контент»), которые могут быть как бесплатными, так и платными, а также содержать дополнительные сюжетные арки, уровни, карты и регионы, модели машин, костюмов и оружия.

Второй вариант принято называть игрой-сервисом (game as a service, GAAS). Этот вариант подразумевает, что игра может выйти на рынок в минимальном виде и будет дополняться и развиваться в случае успеха выпущенной версии. Подобный метод разработки и выпуска игр особенно распространен на мобильном рынке, но также потихоньку завоевывает рынки игр для РС и консолей.

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