Разработка игрового движка с нуля: шаг к инновациям или безумие?

В наше время большинство инди-разработчиков выбирают для своих проектов готовые движки, например Unity или Unreal Engine. При этом собственные технологии используют единицы. Сама мысль о разработке движка у широких масс часто вызывает недоумение. Зачем тратить время на создание чего-то нового, когда на рынке существует масса готовых решений, в том числе бесплатных?

Тем не менее программист Дэвид Грэм, известный под никнеймом Рез, убеждён, что индустрия нуждается в новых технологиях и эту нишу вполне под силу занять инди-разработчикам. В своём выступлении на GDC 2024 он разобрал преимущества и недостатки создания собственного игрового движка. Учитывая, что этот процесс требует определённых технических знаний, доклад Грэма рассчитан в первую очередь на программистов. Впрочем, геймдизайнеры тоже могут почерпнуть много полезного.

Редакция «Геймдев» Skillbox Media делится основными тезисами из выступления специалиста.

Кратко о спикере

Дэвид Грэм

---

Известный также как Рез, разрабатывает игры уже более 28 лет, из них 19 лет работал программистом как в небольших инди-студиях, так и в крупных компаниях, включая MicroProse, Planet Moon Studios и Electronic Arts. Наиболее известен в индустрии как ведущий программист искусственного интеллекта в The Sims 4. В настоящий момент ушёл из сферы AAA и занимается разработкой инди-игр. Также он обучает программированию, уже 11 лет. Свободное время проводит за настольными ролевыми играми.

---

Ссылки

Что такое игровой движок?

Само по себе понятие «игровой движок» достаточно размыто. Одни считают движком SDL, другие думают, что к ним можно отнести такие технологии, как Unity или Ogre3d. По сути, игровой движок — это набор кода и (или) инструментов для создания приложений. Эти сборки можно разделить на следующие типы.

• Математические библиотеки. К ним относятся Zlib, TinyXML, TinyXML2, Box2D, GMTL и другие. Они содержат большое количество функций и классов, которые программист может вызвать и решать с их помощью разные задачи.

• Фреймворки. Выполняют практически ту же функцию, что и библиотеки, но предназначены только для специфических задач вроде воспроизведения аудио или обработки ввода с клавиатуры. В пример можно привести SDL (Simple DirectMedia Layer), SFML (Simple and Fast Multimedia Library), pygame, LÖVE, или даже Microsoft XNA. Поддержка последнего официально прекращена (хотя патчи к версии 4.0 выходят по сей день), тем не менее у него остались последователи — FNA и MonoGame.

• Универсальные движки. В эту категорию входят Unity, Unreal Engine и Godot — готовые технологии с широким набором инструментов для разных задач. Они на слуху даже у обычных игроков.

• Специализированные движки. Предназначены для определённого типа проектов — например RPG Maker (ролевые игры), Ren’Py (визуальные новеллы), Construct (2D- и HTML-игры).

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

Почему готовый игровой движок — не всегда удачное решение

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

Грэм привёл пару примеров из своей практики. В первом случае он работал на Unity, и проект предполагал очень много объектов. В результате код родительского класса MonoBehaviour становился слишком тяжёлым, что сказывалось на производительности игры. От стандартной системы игровых объектов (GameObject) пришлось отказаться и сделать собственную таким образом, чтобы множество объектов в сцене считалось как один. В дальнейшем команда изменила и другие системы, и от оригинального набора инструментов Unity осталась только технология рендеринга и система ввода аудио.

Другая история произошла с Грэмом, когда он пришёл на техническое собеседование на роль ведущего специалиста по ИИ для игры на движке Unreal Engine. Проект изначально предполагал мощный сетевой компонент, который следовало переработать. Поначалу Грэм не понимал, зачем это нужно, ведь Unreal Engine поддерживает сетевое взаимодействие. Но авторы проекта пояснили, что их концепция немного выходила за рамки возможностей движка, и они хотели в буквальном смысле извлечь и переписать его сетевые технологии, что само по себе очень сложно из-за специфики Unreal Engine.

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

Основные недостатки универсальных движков

Хотя многие из движков распространяются по бесплатной или условно-бесплатной модели, финансовые затраты всё же могут возникнуть — например, на специфические виды лицензии или дополнительные плагины и ассеты на маркетплейсах. Рассчитать выгоду покупки очень просто: достаточно вычесть из суммы лицензионных сборов сэкономленное время. Если затраты превышают выгоду, то с финансовой точки зрения нет смысла покупать лицензию и нужно создавать свою технологию. Впрочем, такой подход нельзя применить ко всем движкам: к примеру, у Godot и Ren’Py есть большой потенциал за счёт открытого исходного кода.

Есть и другая, более коварная, чем денежные расходы, причина — ограничения в плане дизайна. Некоторые движки предназначены только для определённых жанров. У других встречаются проблемы с графикой (специфические шейдеры в Unity) или освещением (некорректное отображение в Unreal Engine). К примеру, если разработчик захочет сделать игру в 2D, вряд ли он выберет движок компании Epic Games, так как Unreal Engine специализируется на 3D-графике. Конечно, в теории это возможно, но результат будет не столь эффективным, как в случае с технологией, рассчитанной под эти задачи.

Ещё существуют технические ограничения. Сколько объектов может обработать выбранный вами движок в мире игры? Поддерживает ли он платформы, на которых запланирована игра? Если да, как это реализовано на практике?

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

Здесь можно вспомнить скандал, связанный с попыткой Unity Technologies внедрить в тарифные планы Runtime Fee. Позднее это решение отменили, потому что сообщество было не в восторге. Единственная причина, по которой эта задумка не сработала, — отсутствие монополии, ведь разработчики всегда могут перейти на альтернативные движки.

Epic Games тоже изменила условия лицензирования для кино и телевидения и других сфер, использующих Unreal Engine для производства проектов, не связанных с видеоиграми. Если раньше студии, производящие подобный контент, могли пользоваться технологией бесплатно, то теперь при достижении прибыли в 1 миллион долларов в год им придётся платить 1850 долларов за одно рабочее место в год.

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

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

Как «завести» свой движок

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

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

• уровень абстракции платформы;
• рендеринг;
• физика (при необходимости);
• аудио;
• система ввода;
• представление мира (в формате сцен, уровней);
• система внутриигровых объектов;
• пользовательский интерфейс;
• ресурсы (данные, скрипты, логика);
• внутриигровой редактор (по сути, сердце будущей игры).

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

Если вы программируете на C#, то подойдёт и SFML. А если проект будет с 3D-графикой, можно рассмотреть Ogre3d — нечто среднее между фреймворком и движком. У этого инструмента также открытый исходный код, поэтому с ним можно делать всё что угодно.

Если в игре нужна физика, существует такой инструмент, как Box2D. Для редактора карт можно использовать Tiled. К слову, отсутствие редактора уровня — одна из главных причин, почему разработчики выбирают универсальные движки, и Tiled может решить эту проблему, в том числе для 2D-игр.

Экспорт данных осуществляется в формате XML, поэтому нужен инструмент для чтения этих файлов. Ранее упомянутая библиотека TinyXML как раз для этого подойдёт. А фреймворк SOL помогает перенести код C++ на код Lua. У Грэма есть собственная сборка для интеграции кода между C++ и Lua, ознакомиться с ней можно на GitHub.

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

Имея набор таких инструментов и определённые технические знания, разработчик за выходные уже сможет подготовить собственный фреймворк с базовой структурой и привязать его к игровому циклу. За неделю — возможно, собрать тестовый уровень. В своё время у Грэма получился именно такой результат: в конце недели у него уже был небольшой тестовый уровень с движущимся объектом.

Однако здесь стоит ещё раз уточнить, что предложенный Грэмом вариант поможет только тем, кто хочет сделать простую игру и не планирует создавать условный клон Unity.

Преимущества и недостатки кастомных движков

Плюсы разработки собственного движка

• Экономически выгодно (в долгосрочной перспективе). Делая собственный движок, вы инвестируете в собственную студию и технологию. Здесь важно отметить, что затраты зависят от формата игры. Чем она масштабней, тем больше средств уйдёт на поддержание технологий в будущем. Именно поэтому такие крупные студии, как CD Projekt RED, начинают разработку новых проектов уже не на собственном движке, а на Unreal Engine 5.
• Ничего лишнего. Вы создаёте только то, что нужно, интегрируя в технологию все необходимые системы.
• Делать определённые типы игр становится намного проще. У разработчика есть набор необходимых инструментов и чёткое представление о том, как их применить для воплощения той или иной задумки.
• Независимость. Как отмечалось выше, вы не зависите от условий другой компании.

Минусы разработки собственного движка

• Большие расходы на старте разработки. Создание технологии с нуля потребует сил, времени и финансовых вложений.
• К новой технологии придётся составлять документацию для тех, кто будет с ней работать. Грэм столкнулся с этой необходимостью, когда нанимал специалистов в свою инди-студию. По понятным причинам новые коллеги не знали, как работает система игровых объектов в кастомном движке Грэма, поэтому пришлось составлять сопроводительную документацию.
• Требуется начальный уровень C++. Даже если вам не нужно программировать на этом языке, потребуется хотя бы самый базовый уровень знаний. К примеру через C++ намного проще отследить программные ошибки в Unity, чем через C#.
• Не всегда удобный с точки зрения инструментов. Грэму довелось поработать над приключенческой игрой в формате point-and-click. В качестве основы главного редактора использовался Tiled. Чтобы собрать уровень в универсальном движке, например в Unity, достаточно перетащить ассеты в редактор и расположить их в сцене. В проекте Грэма приходилось переносить контент сначала в Tiled, затем запускать скрипт экспорта, а после — саму игру. Нюанс в том, что игра не запускалась через пользовательский интерфейс фреймворка, поэтому разработчикам приходилось переходить в другое окно и запускать исполнительный файл.
• Сложнее убедить издателя или инвестора в успехе будущего проекта. Многие потенциальные партнёры отказывают в сотрудничестве тем разработчикам, которые работают на кастомных движках, опасаясь рисков. Грэм признаётся, что в прошлом тоже сталкивался с таким отношением — это вынудило его заняться самиздатом. В таких случаях Грэм рекомендует во время переговоров сделать упор на профессиональный опыт. В случае Грэма опыт работы над проектами в Electronic Arts внушает доверие — очевидно, что у специалиста достаточно технических знаний, чтобы выпустить игру на собственном движке. Также важно продемонстрировать готовый контент, например демоверсию, которая может раскрыть потенциал технологии.

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

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

• Don’t Starve;
• Into the Breach;
• FTL: Faster than Light;
• Starbound;
• Factorio;
• Darkest Dungeon;
• Shovel Knight;
• Prison Architect;
• This War of Mine;
• Banished;
• Pixel Dungeon;
• Bastion;
• Stardew Valley;
• Legend of Grimrock;
• Crypt of the Necrodancer.

Итог

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

Например, работая над The Sims 4, Грэм отмечал, что основные системы игры идентичны The Sims 3, а та, в свою очередь, построена на The Sims 2, которая переняла многое из первой The Sims. Разумеется, с каждой новой частью в серию вносились изменения и дополнения, но суть в том, что основа оставалась прежней.

Грэм ушёл из AAA в инди-разработку просто потому, что устал работать над идеями других людей. Когда он приходит на мероприятия вроде GDC, он в первую очередь посещает стенды инди-студий. Именно там, по мнению спикера, можно увидеть самые интересные нововведения, которых ему не хватало в AAA.

Сейчас в индустрии особенно ощущается нехватка технических инноваций. Рынок захватили два крупных движка — Unity и Unreal Engine. Компании Epic Games и Unity Technologies продолжают совершенствовать свои технологии, привлекая огромное количество людей, желающих делать игры на этих движках. Но из-за того, что разработчики получают готовые решения и идут по проложенному пути, возникает тот самый недостаток новизны.

А вот если вы решитесь на создание собственной технологии, появится шанс сделать что-то по-настоящему безумное и необычное. Безумие ведь в каком-то смысле присуще всем инди-разработчикам, не так ли?