Как создать свой движок: Как и зачем создавать собственный игровой движок / Хабр

Содержание

Как и зачем создавать собственный игровой движок / Хабр

Игра с нуля — интересный челлендж для разработчика. Но если хотите пройти его на сложности Nightmare, можно еще и сделать собственный игровой движок, заточенный специально под проект. Подводных камней много, рассказываем, что важно знать при разработке такого гейм-дизайнерского софта, и что в него добавить.

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

Зачем?

Начнем с главного вопроса, который стоит задать себе, если вы решили разработать собственный движок: зачем это вам?

Резонными причинами могут быть, например, такие:

Хотите создать игру с использованием новой технологии, которую не поддерживают другие движки. Или поддерживают, но реализация слишком сложна и костыльна. Это может быть масштабная симуляция (Factorio), нестандартный проект, который не вписывается в готовые шаблоны (Noita, Miegakure), и множество других идей. В таких случаях нет иного выхода кроме как писать собственный движок под проект.
Хотите оптимизировать рабочий процесс под игры, которые создаете. Если для проекта не нужен полный объем возможностей коммерческого движка, есть смысл создать кастомизированный вариант с подходящими для конкретной игры редакторами и функциями. Если движок не затачивается под конкретный проект, стоит задуматься, так ли нужно самописное решение или все-таки достаточно готовых вариантов?
Не хотите в долгосрочной перспективе зависеть от чужих технологий. Если вы хотите иметь полный контроль над проектом, готовы самостоятельно исправлять ошибки (а не сидеть в ожидании багфикса от создателей) и не бояться, что очередное обновление сломает игру, то собственный движок — подходящий вариант! И не придется зависеть от прихотей крупных корпораций
Вам интересно разобраться, как устроены и работают игровые движки. Это отличная причина — по правде говоря, самый веский повод заняться разработкой собственного движка.

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

Вам кажется, что вы придумаете движок покруче, чем Unity или Unreal (или Godot, или GameMaker). Не выйдет. Разработать подходящий для специфических нужд софт можно (см. предыдущий список), но в одиночку или маленькой командой невозможно создать универсальный движок, который будет конкурировать с известным универсальным ПО. Особенно при первой попытке.
Думаете, что иначе вы «ненастоящий программист»? Использование готового движка не делает гейм-разработчика хуже. Для того они и придуманы! Это просто инструмент для создания игр. 99% проектов можно разработать при помощи уже существующего софта — в этом нет ничего постыдного. Ведь главное — это сама игра!
Если вы хотите таким образом сэкономить время или деньги — забудьте! Создавать движок с нуля долго, а время = деньги. Использовать готовый софт выгоднее, чем пытаться разработать собственный. В долгосрочной перспективе это может стать выигрышной стратегией, но только если движок будет основой для нескольких прибыльных проектов, и при этом значительно удобнее в работе, чем коммерческие. Такое ПО разработать сложно, особенно если это первый опыт (и почти невозможно, если речь о 3D).

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

Я начинал с флэш-игр в 90-00х, и ни один движок того времени не поддерживал импорт флэш-анимаций. Единственным выходом было создать собственный софт. Намного приятнее и быстрее закидывать swf-файлы в папку с ресурсами и сразу использовать анимации в игре без промежуточных шагов типа экспорта в списки спрайтов.

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

Что?

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

Разные движки выполняют за вас разное количество работы. Некоторые просто отображают графику на экране (Flash, Pico-8). Другие сами по себе — целая игра с возможностью кастомизации или узко заточены под определенный жанр (RPGMaker, Ren’Py). А между ними — бесчисленное количество вариантов.

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

Базовые функции движка.

Это основы, необходимые для того, чтобы начать создавать игры.

Инициализация системы.

Приводит программу в боевую готовность после запуска — открывает окно, загружает данные. С этим (и не только!) справится стандартная библиотека SDL, проще ее и использовать.

Контроль частоты кадров

Ограничивает частоту сменяемости кадров для плавного изображения и оптимизации работы.

Ввод

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

Рендеринг

Большинство (ну как минимум 75%) игр так или иначе используют графику, и за нее отвечает как раз движок. В 2D-игре минимальному рендеру достаточно отображать на экране текстурированные четырехугольники. Шейдеры, буферы вершин, однобуферная прорисовка, меши, материалы и так далее — это прекрасные опции, которые можно добавить позднее, если понадобится. Если хочется заморочиться с OpenGL или Vulkan и кастомизировать рендерер — на здоровье! Но помните, нет ничего постыдного в том, чтобы использовать для рендеринга готовые библиотеки типа Ogre3D. Выбор зависит от целей и потребностей разработчика, а также от того, какие задачи интереснее решать самостоятельно.

Математические и прочие утилиты

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

Дополнительные функции

Еще несколько систем, которые лучше добавить в движок ближе к делу, когда они непосредственно понадобятся для игры:

Управление игровыми объектами и сценами

Можно кодить и вручную, но практичнее предусмотреть систему для обработки отдельных игровых объектов и коллекций. Это один из ключевых механизмов в движке, ведь он управляет логикой игры. Из каких компонентов состоят объекты, на какие типы событий реагируют, как происходит взаимодействие, что со структурой памяти, используется ECS? (Кстати, «чистый» неадаптированный ECS лучше применять только для специфических кейсов.) Эти и не только вопросы должна покрывать система управления объектами и сценами. Для таких задач доступны готовые библиотеки (особенно для чистого ECS), но, поскольку эта структура сильнее остальных влияет на игровой код, я склоняюсь к принципу «сделай сам». Использование существующего решения вынудит постоянно думать о том, как вписать логику игры в рамки. А надо наоборот — адаптировать движок под выражение задуманной игровой логики.

Аудио

Звуковые эффекты и музыка здесь разделены, хотя и прячутся под одним названием. Основные необходимые функции — это запуск и остановка звуковых циклов и воспроизведение звуковых эффектов от начала до конца. Этим аудио не ограничивается, но даже с двумя базовыми опциями можно далеко продвинуться. Минус в том, что стандартные звуковые фреймворки (FMod and Wwise) — коммерческие и с кучей лицензионных ограничений. Однако большинство ресурсов с открытым кодом раздражают неудобством (передаю привет OpenAL). Сам я использую FAudio — на мой вкус, простая и комфортная в использовании база для построения сложных звуковых механик.

Загрузка и управление файлами

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

Нетворкинг

Окей, нетворкинг (онлайн-мультиплеер) — это ОЧЕНЬ опционально. Если не планируется режим p2p, то и не заморачивайтесь. Однако эту систему чрезвычайно сложно встроить в движок, который разработан не с расчетом на многопользовательские игры. Поэтому, если вы планируете или допускаете добавление мультиплеера, подготовьте почву заранее, потому что иначе придется переделывать все системы.

Это базовый набор систем, которые входят в игровой движок. Другие варианты типа обнаружения столкновений, физики, сериализации, анимации и UI уже опциональны. Они распространены, поэтому входят в большинство движков, но для создания игр не обязательны. Например, предотвращение столкновений можно обеспечить при помощи математических утилит и прописать алгоритм в коде игры. Простейшую гравитацию и ускорение можно настроить без физических движков типа Box2D or Bullet. А полная сериализация вообще лишняя, если нужно попросту сохранить чекпойнт.

В самописном движке однозначно будет меньше систем и функций, чем в универсальном коммерческом. Такова цель! Unity и Unreal — огромные монолиты, и каждая отдельная игра использует лишь малую часть предложенных опций. Добавляйте только то, что нужно для вашего конкретного кейса и сосредоточьтесь на том, чтобы сделать инструменты разработки лучше и комфортнее в использовании.

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

Как?

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

Сразу к делу: делайте игру параллельно с разработкой движка. Это правило нельзя нарушать. Изучите основы как можно скорее и сразу же начинайте создавать на этой базе игру. Движок — ничто без игры.

Это необходимо, потому что функционал движка должен соответствовать потребностям сделанных на нем игр. Нельзя понять, как построить хорошую анимационную систему, если проект не требует сложной анимации. Слабые места движка проявляются в процессе написания игры. Может быть, нужна древовидная система, благодаря которой дальние объекты не будут рендериться, пока не приблизятся на определенное расстояние? Я не знаю, и вы не узнаете, пока не соберете игровой уровень, который будет страшно зависать. И даже тогда проблема может оказаться не в обновлении объектов — чтобы понять, надо проверить.

Не программируйте того, что не нужно. Если единственный UI в игре — кнопка Play в главном меню, поздравляю! Не придется создавать мудреный пользовательский интерфейс. В The End Is Nigh нет ни физического движка, ни детектора столкновений. Там даже нет камеры, потому что она там не нужна. Я использовал электронную таблицу .csv, чтобы собрать карту мира, вместо всяких сложных редакторов. Делается легко и нормально работает.

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

Что касается языков программирования — выбирайте, каким лучше владеете. Разработка движка — сама по себе непроста, а если делать это параллельно с изучением С++, обе эти задачи станут в два раза сложнее. C# идеально подойдет для создания движка. Медленнее, чем на С++, но не критично. Более медленный язык типа Python может вызвать затруднения, если в игре много движущихся объектов… но для некоторых игр пойдет. Используйте, что удобно.

И еще — с первой попытки идеально не получится. Моей первой игрой на самописном движке стала Closure, и в ней полный бардак (забавно, что ее номинировали на награду «Техническое совершенство» на фестивале независимых игр в 2010 году). Системы рендеринга и обновления вдвоем обрабатывали всю игру. Добавлять новые объекты было крайне трудоемко, приходилось дописывать кучу кода и работать с кривыми редакторами анимации, так что в итоге осталось с дюжину интерактивных предметов. У некоторых из них было несколько вариаций, кардинально менявших поведение объекта — это было проще, чем добавлять новые. Так что прожекторы, зеркала и турели по сути один и тот же объект!

Но с ошибками приходит и опыт. Движок Closure написан кое-как, но оказался достаточно хорош, чтобы запустить игру на PS3. Идея переписать некоторые части движка была заманчивой, но это лишь отложило бы выход игры. Вместо этого я писал заметки о том, что получилось плохо, чтобы учесть ошибки в следующий раз. Особенно о том, что мешало непосредственно созданию игры. То же и с The End is Nigh. В ее движке (который, кстати, НАМНОГО лучше, чем в Closure) все равно была куча ошибок, которые я решал, стиснув зубы. Как только игра вышла, я сразу начал улучшать движок для следующего проекта, исправлять раздражающие баги и добавлять новые функции.

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

Не стал вдаваться в технические подробности, как внедрить в движок каждую отдельную систему. Это зависит от конкретных вариантов использования, есть сотни способов — и каждый из них правильный. Понять, что вам подходит — ВОТ в чем суть разработки движка, с таким настроем стоит браться за создание собственных проектов.

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

Как и зачем создавать собственный игровой движок

Зачем?

Резонными причинами могут быть, например, такие:

Хотите создать игру с использованием новой технологии, которую не поддерживают другие движки. Или поддерживают, но реализация слишком сложна и костыльна. Это может быть масштабная симуляция (Factorio), нестандартный проект, который не вписывается в готовые шаблоны (Noita, Miegakure), и множество других идей. В таких случаях нет иного выхода кроме как писать собственный движок под проект.
Хотите оптимизировать рабочий процесс под игры, которые создаете. Если для проекта не нужен полный объем возможностей коммерческого движка, есть смысл создать кастомизированный вариант с подходящими для конкретной игры редакторами и функциями. Если движок не затачивается под конкретный проект, стоит задуматься, так ли нужно самописное решение или все-таки достаточно готовых вариантов?
Не хотите в долгосрочной перспективе зависеть от чужих технологий. Если вы хотите иметь полный контроль над проектом, готовы самостоятельно исправлять ошибки (а не сидеть в ожидании багфикса от создателей) и не бояться, что очередное обновление сломает игру, то собственный движок — подходящий вариант! И не придется зависеть от прихотей крупных корпораций
Вам интересно разобраться, как устроены и работают игровые движки. Это отличная причина — по правде говоря, самый веский повод заняться разработкой собственного движка.

Вам кажется, что вы придумаете движок покруче, чем Unity или Unreal (или Godot, или GameMaker). Не выйдет. азработать подходящий для специфических нужд софт можно (см. предыдущий список), но в одиночку или маленькой командой невозможно создать универсальный движок, который будет конкурировать с известным универсальным ПО. Особенно при первой попытке.

Думаете, что иначе вы «ненастоящий программист»? Использование готового движка не делает гейм-разработчика хуже. Для того они и придуманы! Это просто инструмент для создания игр. 99% проектов можно разработать при помощи уже существующего софта — в этом нет ничего постыдного. Ведь главное — это сама игра!

Если вы хотите таким образом сэкономить время или деньги — забудьте! Создавать движок с нуля долго, а время = деньги. Использовать готовый софт выгоднее, чем пытаться разработать собственный. В долгосрочной перспективе это может стать выигрышной стратегией, но только если движок будет основой для нескольких прибыльных проектов, и при этом значительно удобнее в работе, чем коммерческие. Такое ПО разработать сложно, особенно если это первый опыт (и почти невозможно, если речь о 3D).

Что?

Базовые функции движка.

Это основы, необходимые для того, чтобы начать создавать игры.

Инициализация системы.

Контроль частоты кадров

Ограничивает частоту сменяемости кадров для плавного изображения и оптимизации работы.

Ввод

Рендеринг

Математические и прочие утилиты

Дополнительные функции

Управление игровыми объектами и сценами

Аудио

Загрузка и управление файлами

Нетворкинг

Как?

Как сделать игровой движок (шаг за шагом)

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

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

Игровой движок — это основа того, как вещи будут реагировать и реагировать в игре, поэтому крайне важно иметь правильный движок для вашей идеи. У вас есть отличные варианты, такие как Unity и даже движок Unreal, но что, если вы хотите создать свой собственный?

Это вообще возможно? Я здесь, чтобы сказать, что да: это абсолютно так.

Это не то же самое, что иметь отличную идею для проекта и просто следовать ей. Нет, нет, нет, мой друг. Это инвестиции, в которые вы, скорее всего, вложите сотни, если не тысячи часов.

Подумайте обо всех этих часах в Ведьмаке 3 и Red Dead Redemption раз в сто, нет, в тысячу.

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

Содержание:

Переключатель

Зачем создавать двигатель?

Стоит ли делать собственный игровой движок? Это большой вопрос, не так ли? Почему вы хотите создать игровой движок? Это попытка сделать что-то самостоятельно?

Может быть, что-то, что не нуждается в Unreal или Unity? Если бы кто-то использовал мощь игрового движка, творческий потенциал в будущем был бы огромен.

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

Что входит в игровой движок? Что ж, создание игрового движка — непростая работа; если бы это было так, то так бы поступили все и их брат. Вместо этого это требует времени и терпения, чего многим геймерам (в том числе и мне) иногда может не хватать.

Создание игрового движка может стать чрезвычайно интересным и полезным активом в вашем портфолио разработки. Насколько впечатляюще было бы увидеть под чьими-то проектами, что они разрабатывают/разрабатывают или делают игровой движок?! Я преклоняю колени перед ними в благоговении.

Вы должны хорошо понимать, что такое двигатели. Например, вы можете что-то перепутать. Является ли OpenGL игровым движком? Нет, это скорее графический рендерер, а не движок.

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

Установленная школа кодирования

плюсы и минусы построения игрового двигателя

Pros:

Творческий потенциал

Создание игрового двигателя — это более или менее создание строительных блоков для потенциальной жизни, слоительный мир. Это может варьироваться от чего-то более простого, такого как кровавый пиксельный фестиваль Hotline Miami, до более сложных проектов, таких как название AAA.

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

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

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

Некоторым должно хватить. Я знаю, что это для меня!

Встреча с коллегами-создателями

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

Управление

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

Это может оказаться неоценимым, поскольку, поскольку вы знаете все, что нужно знать о движке, вы являетесь лучшим источником помощи во всех аспектах, таких как анимация и физика.

Опыт обучения

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

Как я уже говорил, вы также можете добавить эти впечатления в свое портфолио в будущем. Будет довольно впечатляюще увидеть, как кто-то с вашим опытом присоединится к команде или работает над проектом.

Минусы

Значительная трата времени

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

Ариэль Манзур и Хуан Линиецки, разработчики движка Godot, постоянно обновляют Godot с момента его запуска в середине 2000-х годов. Имейте в виду, что после запуска вам, скорее всего, придется продолжать работать и работать после даты запуска, чтобы ваш движок работал бесперебойно.

Это связано с сообществом, и мы надеемся, что ресурсов будет достаточно и они будут доступны. Многие говорят, что это может быть одним из, если не самым важным, фактором, почему НЕ стоит делать игровой движок.

Крутая кривая обучения

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

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

Другие движки

Многие в Интернете говорят, что гораздо проще использовать существующий движок для разработки игры или творческого проекта, который крутится у вас в голове.

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

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

Языки и опыт: научитесь программировать

C++ — это основа программирования. Если вы являетесь мастером C++, то разработка игр и сборка движка могут легко попасть в ваши руки.

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

C++ — отличное первое, с чего можно сразу начать. Он работает почти на всех платформах и используется практически со всем, с чем вы столкнетесь. Это виртуальная кровь, текущая по венам вашего творческого игрового движка. Как только вы достаточно изучите C++, вы сможете развиваться дальше. Например, Java — одна из самых известных и популярных когда-либо созданных программ кодирования.

Java является производным от языка C++. Это проще, что упрощает разработку на Java.

Он упрощает некоторые из более сложных аспектов C++ и упрощает усвоение синтаксиса и терминов.

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

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

Code.org
Код Академии
Академия Хана
Кодовые войны
Курсера
Удеми
Завоевание кода
И многое другое…

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

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

По сути, C++ практически необходим и используется во многих современных движках как важная часть процесса проектирования.

Как структурировать свой проект

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

Есть система

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

Это также может означать «работай на двух работах, приходи домой и кодируй». Для всех, кто берется разрабатывать игровой движок с нуля, все будет по-разному.

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

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

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

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

Рассмотрим сотрудничество

Это одна из моих любимых идей в разработке. Зачем идти одному? В игре и при разработке движка одиночная игра может быстро разочаровать и невероятно раздражать.

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

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

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

Бьюсь об заклад, если бы я связался с разработчиками знаменитого мода Дарта, я мог бы получить ценную информацию; это так просто. Два разработчика Godot были друг у друга, и это огромная причина, по которой они вообще запустили Godot.

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

Использовать итеративный подход

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

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

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

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

Как сказано выше, вам нужно знать, как все это работает. Это ваш мир; вам нужно жить в нем.

Не пытайтесь сделать все сразу

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

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

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

Ничего не получится, если вы станете слишком самоуверенными и забросите свой проект из-за разочарования.

Аспекты игрового движка

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

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

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

Собираетесь строить?

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

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

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

(Источники изображения: Thenextweb, шоколадный, blender.stackexchange, dashjump, hssmi, kingston, github)

Как сделать свой игровой движок (и зачем) | Тайлер Глэйел | Компьютерная культура

Опубликовано в

Чтение: 14 мин.

11 ноября 2021 г.

Типичный игровой движок

Итак, вы думаете о создании собственного игрового движка. Большой! Есть много причин сделать его самостоятельно, а не использовать коммерческий, такой как Unity или Unreal. В этом посте я расскажу почему вам может понадобиться, какие системы нужны в игровом движке, и как вам следует подходить к его разработке. Я не буду здесь вдаваться в какие-то глубокие технические подробности, это о том, зачем и как разрабатывать игровой движок, а не учебник о том, как писать код.

Давайте начнем с самого первого вопроса, который вы должны задать себе, если хотите создать свой собственный игровой движок: зачем?

Вот несколько веских причин, по которым вы можете захотеть:

Новая технология : Вы хотите создать игру, в которой используется часть новой технологии, которую в настоящее время не поддерживают никакие другие движки или которые не могут быть легко сделать для поддержки в их текущем состоянии. Это может означать какую-то крупномасштабную симуляцию, требующую тщательного кодирования, чтобы сделать ее производительной (Factorio), или какую-то нестандартную вещь, которая не вписывается ни в какие существующие шаблоны (Noita, Miegakure), или желание нацелиться на странную аппаратное обеспечение, которое современные движки не поддерживают (Playdate), или что-то еще. Это хорошая причина сделать свой собственный движок, потому что в таких случаях другого выхода нет.

Специализация : Вы хотите оптимизировать свой рабочий процесс для тех игр, которые вы делаете. Вам не нужны все функции, включенные в коммерческий игровой движок, и вы можете сделать свой конвейер ресурсов/редактор уровней/как угодно более удобным для использования при рассмотрении ваших конкретных вариантов использования, вместо того, чтобы использовать его для общего назначения. Специализация — это почти обязательное условие для создания собственного движка, и если вы не специализируетесь на нем и не ориентируете его на свой конкретный вариант использования, вам следует переосмыслить, в первую очередь, зачем вы делаете движок.
Независимость : Вы не хотите в долгосрочной перспективе зависеть от чужой технологии. Стимулы и ценности таких компаний, как Unity или Epic, не всегда будут совпадать с вашими собственными, и вам нужен контроль над собственной технологией, возможность исправлять ошибки самостоятельно, а не «ждать и надеяться», и чувствовать себя комфортно, зная, что обновление не сломает полностью ваш текущий проект. Вы готовы взять на себя затраты на разработку собственной технологии, потому что в долгосрочной перспективе хорошо, когда вам не нужно постоянно что-то менять в зависимости от прихотей гигантских компаний.

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

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

Если что-то из этого является вашей (единственной) мотивацией, вы должны вернуться и пересмотреть:
Я могу сделать это лучше : Вы думаете, что можете просто сделать что-то лучше, чем Unity или Unreal (или Godot, или GameMaker) в целом. Вы не можете. Можно сделать что-то лучше этого для конкретных случаев использования (см. Специализация выше), но вы, как человек или небольшая команда, не собираетесь конкурировать с этим для вещей общего назначения. Особенно, если вы никогда раньше не создавали свой собственный игровой движок.
Это то, чем занимаются настоящие программисты : Не существует «правильного способа» сделать игру, вы не получите очки программиста за создание собственного движка. Если ваша игра подходит для существующего движка (а я бы сказал, что 99% игр), в использовании нет ничего постыдного. В конце концов, игровой движок — это просто инструмент для создания игры, он не может и никогда не должен быть целью сам по себе. Игры, которые вы делаете с ним, — это все, что имеет значение.
Экономия денег/времени : Скорее всего, нет. Создание двигателя требует времени, а время=деньги. Стоимость Unity незначительна по сравнению со временем, которое требуется для создания собственной технологии. Доля оборотов Unreal незначительна, если только вы не продаете 10 миллионов копий игры AAA. Использование собственного движка не заставит вас автоматически продавать больше копий игры. И хотя вы *можете* сэкономить время в долгосрочной перспективе, обычно это означает, что ваш движок будет достаточно хорош для выполнения нескольких проектов, а также обеспечит вам значительные улучшения рабочего процесса по сравнению с коммерческими движками. Это нелегко сделать правильно, и вы определенно не справитесь, если это ваша первая попытка (и крайне маловероятно, если вы делаете 3D вместо 2D).

Кроме того, вы должны обязательно учитывать свой собственный опыт и цели при взвешивании всего этого. Если у вас нет большого опыта в создании игр, вам будет намного сложнее сделать движок (и вам обязательно нужно получить некоторый опыт в создании игр, прежде чем пытаться сделать движок в любом случае). Если вы хотите заниматься 3D, вам будет гораздо труднее, чем просто делать 2D.
Для меня мотивация к созданию собственного двигателя в основном связана с новыми технологиями и специализацией. Я родом из флеш-игр, я сделал довольно много их в середине/конце 00-х, и этот рабочий процесс мне очень удобен и мне нравится. Ни один из существующих движков не поддерживал импорт флеш-анимации, поэтому единственным вариантом было сделать это самому. Чрезвычайно приятно иметь возможность просто помещать файлы .swf в папку с ресурсами и мгновенно получать анимации, доступные для использования в моем игровом коде, без каких-либо промежуточных шагов для их экспорта в листы спрайтов или что-то еще.

Это не единственные причины, по которым вы хотите создать собственный игровой движок. У этого есть масса преимуществ (и недостатков), и перевешивают ли плюсы минусы, во многом зависит от того, сколько у вас опыта как в разработке игр в целом, так и в программировании более низкого уровня. Например, приятно просто иметь свою собственную технологию, и приятно не постоянно искать в Google учебники, которые могут быть устаревшими, о том, как что-то сделать в вашем движке. Приятно иметь возможность отлаживать внутренности вашей игры, если что-то пойдет не так. Но это также может быть отстойно, если вы сделали пару неудачных дизайнерских решений, и все полностью развалится, а в Интернете нет ресурсов, которые могли бы вам помочь. У вас есть полный контроль и полная ответственность, а также все плюсы и минусы, которые с этим связаны.
Прежде чем мы перейдем к тому, как создать свой собственный игровой движок, давайте сделаем шаг назад и определим, что такое игровой движок на самом деле и какие типы проблем он должен решать.
Игровой движок — это основа, на которой вы делаете игру. Он предоставляет вам основу, на которой можно строить, а также все строительные блоки и детали лего, из которых вам нужно собрать игру. Он обеспечивает границу между «игровой логикой» и «скучной технической ерундой», так что код вашей игровой логики (материал, который на самом деле описывает, что из себя представляет ваша игра, как она управляется, взаимодействие между объектами и правила) не нуждается в на самом деле заботиться о таких вещах, как отправка треугольника на видеокарту.
На самом деле есть много различий в том, сколько игровых движков на самом деле делают для вас. Некоторые из них представляют собой не более чем просто фреймворк для отображения графики, и помимо этого они мало что делают для вас (Flash, Pico-8). Некоторые из них сами по себе являются целой игрой или, по крайней мере, гиперспециализированы для определенного жанра, закладывая массу общей игровой логики в сам движок (RPGMaker, Ren’Py). И все между ними.
Сами игровые движки также, как правило, строятся на основе фреймворков еще более низкого уровня, таких как SDL и OpenGL, и включают в себя множество специализированных библиотек для таких вещей, как звук, физика, математика и все остальное, что вы считаете полезным. Создание пользовательского игрового движка не означает написания каждой его части самостоятельно, особенно такого стандартного и полезного, как SDL. Сборка правильного набора существующих библиотек для вашего варианта использования также является частью создания движка, и существуют библиотеки почти для всех систем, которые вы могли бы захотеть использовать в своем движке.
В любом случае, имея это в виду, давайте немного поговорим о том, что я считаю самым базовым набором функций, необходимых для вашего игрового движка. Самое необходимое. Минимум, что вам нужно, прежде чем вы сможете начать делать игру.
Инициализация системы : открытие окна, получение контекста OpenGL/DirectX/Vulkan, инициализация звука. SDL справится со всем этим за вас, так что просто используйте SDL. На самом деле, SDL на данный момент является отраслевым стандартом для пользовательских движков, поэтому нет причин делать эту часть самостоятельно.
Управление синхронизацией кадров : Вы хотите, чтобы ваша игра работала со скоростью 60 кадров в секунду, поэтому вам нужен какой-то таймер и цикл, который контролирует, когда происходят обновления и рендеринг.
Ввод : Вы должны уметь реагировать на нажатия кнопок. Есть много разных способов реагировать на нажатия кнопок, может быть, вы просто хотите иметь возможность запрашивать текущее состояние кнопки, или, может быть, вы хотите регистрировать события, это не имеет большого значения. SDL сообщит вам о вводе кнопок, если вы уже используете это для инициализации системы, вы должны использовать его и здесь. Вы можете построить действительно мощную и гибкую систему ввода поверх этого, но сначала нет необходимости делать что-то большее, чем основы.
Рендеринг : Большинство, по крайней мере, 75% игр, так или иначе используют графику, и это абсолютно то, за что должен нести ответственность ваш движок. Если вы делаете 2D-игру, минимальный рендерер просто должен иметь возможность отображать на экране простые текстурированные четырехугольники. Шейдеры, буферы вершин, цели рендеринга, меши, материалы и многое другое — все это прекрасно, но они могут появиться позже, когда они вам понадобятся. Если вы хотите запачкать руки OpenGL или Vulkan или чем-то еще, вы можете полностью отказаться от своего собственного рендерера, но опять же, нет ничего постыдного в использовании существующей библиотеки, такой как Ogre3D, для покрытия рендеринга. Всецело зависит от ваших целей и потребностей, а также от того, какие проблемы вам действительно интересно решать.
Математика и прочее Утилиты : я не считаю «векторы и матричные математические вычисления» полной «Системой», но это то, что вам, вероятно, следует иметь в качестве библиотеки утилит, к которой имеют доступ как движок, так и код игры. Плюс любые другие случайные полезные функции и формулы, которые вы найдете в процессе разработки. STB — невероятно отличный ресурс для случайных утилит, которые могут вам понадобиться.
Также есть несколько систем, которые также являются базовыми, но вам не нужно добавлять их до тех пор, пока вы действительно не начнете их использовать.
Управление игровыми объектами/сценами : Кодирование всего в одной большой функции обновления на самом деле не так уж плохо, как кажется, но если ваша игра становится хоть немного сложной, вам понадобится какая-то система для обрабатывать отдельные игровые объекты и наборы игровых объектов. В каком-то смысле это оказывается самой важной системой в вашем движке, поскольку именно она управляет логикой вашей игры. Являются ли ваши объекты большими деревьями наследования? Состоят ли они из более мелких компонентов? Вы используете ЭКС? (примечание: вам, вероятно, не следует использовать «чистую» ECS, если у вас нет действительно конкретного варианта ее использования) На какие типы событий они реагируют? Как вы запрашиваете другие объекты для взаимодействия? Вы заботитесь о структуре памяти? Это все, что должна охватывать ваша система управления игровыми объектами/сценами. Для этого есть несколько существующих библиотек, особенно для чистой ECS, однако, поскольку это система с больше всего влияет на то, как выглядит код вашей игры, здесь я склоняюсь к принципу «сделай сам». Использование существующего решения заставит вас постоянно думать о том, как вписать логику вашей игры в эту форму. Точно в обратном направлении от того, что вы обычно хотели бы. Вы хотите, чтобы ваш движок был разработан для поддержки того способа, которым вы хотите выразить игровую логику, а не наоборот.
Аудио : Звуковые эффекты и Музыка здесь представляют собой отдельные системы, хотя обе объединены в «Аудио». Основные функции, которые вам нужны, — это возможность запускать и останавливать звуковые циклы (музыку) и возможность полностью воспроизводить отдельные звуковые эффекты. Аудио — это гораздо больше, чем просто это, но вы можете продвинуться очень далеко, используя только основы. Раздражает то, что стандартные отраслевые звуковые фреймворки (FMod и Wwise) являются коммерческими и имеют множество лицензионных ограничений, но многие из них с открытым исходным кодом просто очень раздражают в использовании (привет OpenAL). Лично я нахожу FAudio довольно простым и довольно замечательным, и я использую его в качестве основы для построения более сложного поведения.
Загрузка файлов и управление ими : Все игры должны загружать файлы. Вам нужен способ загрузки файлов. Вы, вероятно, не хотите повторно загружать/декодировать файлы, которые уже были загружены, поэтому вам нужен какой-то базовый менеджер, который обрабатывает все это. Возможно, вы захотите иметь возможность создавать поддержку модов или динамическую загрузку/выгрузку или что-то еще, если у вас есть основы здесь и когда-либо загружаете файлы только через файловый менеджер, вы можете легко добавить любые другие функции, которые вы хотите в это позже. Вам не нужно это немедленно, так как вы можете просто использовать встроенную загрузку файлов в качестве заполнителя, но в конечном итоге вы захотите иметь систему управления файлами/ресурсами, как только вы начнете использовать файлы чаще.
Сеть : Хорошо, работа в сети (сетевой многопользовательский режим) ОЧЕНЬ необязательна (если вам не нужен сетевой многопользовательский режим, не беспокойтесь), однако это исключительно сложная система, которую можно прикрепить к движку, который не был разработан с учетом многопользовательской игры. , так что если вы делаете многопользовательскую игру, вам нужно подумать об этом заранее, потому что само ее существование влияет на дизайн буквально каждой другой системы.
Это базовый набор систем, которые вам понадобятся для того, что я называю игровым движком. Другие системы, такие как Столкновение и Физика и Сериализация и Анимация и Пользовательский интерфейс и еще много чего на самом деле необязательны. У большинства движков они есть, потому что они достаточно распространены, и их стоит включать, но вам не нужно для создания игры. Вы можете обойтись простой проверкой столкновений в своей библиотеке математических утилит и просто позволить игровой логике сделать все это вручную. Вы можете выполнять базовую гравитацию и ускорение без физического движка, такого как Box2D или Bullet. И полная сериализация часто может быть огромным излишеством, если все, что вам нужно сделать, это сохранить контрольную точку, на которой вы появляетесь.
Если вы пишете свой собственный движок, обязательно в нем будет меньше систем и функций, чем в крупных коммерческих движках общего назначения. Это должно быть целью! Unity и Unreal — раздутые монолиты, каждая отдельная игра использует лишь небольшую часть того, что они могут предложить. Добавляйте только то, что вам нужно для вашего конкретного случая использования, и сосредоточьтесь на том, чтобы сделать то, что важно для вас и вашей игры, еще лучше.
Я настоятельно рекомендую ознакомиться с тем, как работает множество различных игровых движков, прежде чем начинать создавать свои собственные. Узнайте, какие парадигмы и структуры они используют, что в них классного и что раздражает. Сделайте небольшую игру на нескольких разных движках, если сможете, просто чтобы получить эти знания.
Итак, вы взвесили «почему» и изучили «что» и решили, что хотите создать свой собственный игровой движок. Как вы собираетесь это делать?
Сразу к делу: Делайте игру одновременно с созданием движка . Это нерушимое правило. Единственное нерушимое правило. Изучите основы как можно быстрее, а затем сразу же приступайте к созданию игры на их основе. Движок ничего без игры.
Вам необходимо это сделать, потому что особенности движка должны соответствовать потребностям игр, сделанных на нем. Вы не поймете, как спроектировать хорошую систему анимации, если у вас нет игры, требующей сложного потока анимации. Вы не будете знать, какие у вас узкие места в производительности, если у вас нет игры. Вам нужна какая-то древовидная структура мира, которая позволит избежать обновления или рендеринга объектов, которые находятся слишком далеко от камеры? Я не знаю, и вы тоже не знаете, пока у вас не будет большого уровня, который работает как дерьмо. Даже в этом случае обновление объектов может не быть узким местом, и вы не узнаете об этом, пока не профилируете его.
Не кодируйте что-либо, пока оно вам не понадобится. Если единственным интерфейсом в вашей игре является кнопка воспроизведения в главном меню, поздравляем! Вам не нужно кодировать причудливую систему пользовательского интерфейса для вашего движка. The End Is Nigh поставляется без физического движка и даже без широкой фазы столкновений. Черт, у него даже не было системы камер, так как игра просто не нуждалась в ней. Я использовал электронную таблицу .csv для упорядочивания карты мира вместо какого-то сложного редактора. Это было легко и работало нормально.
Я не буду вдаваться в подробности реализации этих систем, потому что существует слишком много способов сделать это, и все они прекрасно работают для разных целей. Не существует «лучшего способа рендеринга» или «лучшего способа управления игровыми объектами». Все зависит от вашей игры. Начните с основ и расширяйте их по мере необходимости.
Для языков программирования используйте то, что вам удобно. Создание движка — сложная задача, и если вы одновременно с изучением C++ пытаетесь научиться делать игровой движок, вы просто удваиваете сложность изучения любой из этих задач. C# отлично подходит для создания игрового движка. Медленнее, чем C++, но часто недостаточно медленный, чтобы это имело значение. Что-то очень медленное, такое как Python, может быть немного натянутым, если в вашей игре много движущихся частей… но для некоторых игр это все еще нормально. Используйте то, что вам удобно.
Кроме того, вы никогда не получите это правильно с первой попытки . Моей первой игрой с нестандартным движком была Closure, и это был полный бардак (несмотря на довольно забавную номинацию на награду за техническое совершенство на IGF 2010). Одна большая функция обновления и одна большая функция рендеринга обрабатывали практически всю игру. Добавление новых типов игровых объектов было чрезвычайно раздражающим и требовало добавления кода в кучу разных мест и работы с некоторыми дерьмовыми пользовательскими редакторами для анимации, поэтому в итоге мы получили всего около дюжины различных типов интерактивных объектов, хотя у некоторых из них были варианты (логические переключатели), которые значительно изменили их поведение, потому что добавлять варианты было проще, чем добавлять новые объекты. Прожекторы, зеркала и турель — это один и тот же объект!
Но вы учитесь на этом опыте. Движок Closure был в беспорядке, но он все еще поставлялся в таком состоянии, и он был «достаточно хорош», чтобы я мог без особых хлопот запустить его на PS3. Было заманчиво переписать движок в некоторых местах, но вместо того, чтобы сделать это (что только задержало бы игру), я просто записал все, что в нем было отстойно, чтобы в следующий раз я мог сделать лучше. Особенно то, что мешало созданию игры. Я сделал то же самое с The End is Nigh. Его движок (хотя и НАМНОГО лучше, чем у Closure) по-прежнему имел кучу проблем, с которыми я просто стиснул зубы и решил их во время разработки. Как только игра вышла, я сразу же начал обновлять движок для использования в нашем следующем проекте, исправляя с ним все недоработки и добавляя новые функции, которые нам были нужны.
Это повторяющийся процесс насквозь. Вы учитесь, делаете игру, итерируете и повторяете. Снова и снова, пока в конце концов ваш двигатель не будет в порядке.
Надеюсь, вы поняли, почему я не удосужился дать какие-либо технические подробности о том, как реализовать все эти отдельные системы. Просто это слишком сильно зависит от ваших конкретных вариантов использования, и есть сотни разных, абсолютно правильных способов приблизиться к каждому из них. Выяснение того, что работает для вас, — ЭТО и есть создание собственного игрового движка, и это образ мышления, которого вы должны придерживаться, когда пишете свои собственные вещи.