Играть в игру с нуля — интересная задача для разработчика.
Но если вы хотите пройти ее на сложности «Кошмар», вы также можете создать собственный игровой движок, адаптированный специально для проекта.
Подводных камней много, мы рассказываем, что важно знать при разработке такого программного обеспечения для геймдизайна, и что в него добавить.
Итак, вы задумались о создании собственного игрового движка.
Большой! Этот вариант имеет множество преимуществ по сравнению с использованием коммерческого варианта, такого как Unity или Unreal. В этой статье мы разберемся За что разработать свой собственный движок, который системы должны быть предусмотрены и Как правильно подойти к процессу.
За что?
Начнем с главного вопроса, который вам следует задать себе, если вы решили разработать собственный движок: зачем вам это нужно? Разумный причинами могут быть, например:- Хотите создать игру, используя новую технологию, которую не поддерживают другие движки.
Или поддерживают, но реализация слишком сложная и костыль.
Это может быть крупномасштабное моделирование ( Факторио ), нестандартный проект, не укладывающийся в готовые шаблоны ( Нойта , Миэгакуре ) и многие другие идеи.
В таких случаях нет другого выхода, кроме как написать собственный движок для проекта.
- Хотите оптимизировать рабочий процесс для создаваемых вами игр? Если проект не требует всех возможностей коммерческого движка, имеет смысл создать собственную версию с редакторами и функциями, подходящими для конкретной игры.
Если движок не заточен под конкретный проект, стоит задуматься, действительно ли необходимо самодельное решение или достаточно готовых вариантов?
- Вы не хотите зависеть от технологий других людей в долгосрочной перспективе.
Если вы хотите иметь полный контроль над проектом, готовы самостоятельно исправлять ошибки (а не сидеть в ожидании исправления от создателей) и не боитесь, что следующее обновление сломает игру, то собственный движок — правильный вариант ! И вам не придется зависеть от прихотей крупных корпораций.
- Вам интересно понять, как устроены и работают игровые движки.
Это отличная причина — фактически, самая веская причина начать разработку собственного движка.
Если вы найдете среди этих пунктов свой, притормозите и подумайте еще раз.
- Вы думаете, что придумаете более крутой движок, чем Unity или Unreal (или Godot, или GameMaker).
Не будет работать.
Можно разработать программное обеспечение, подходящее для конкретных нужд (см.
предыдущий список), но в одиночку или небольшой командой невозможно создать универсальный движок, который будет конкурировать с известным универсальным программным обеспечением.
Особенно с первой попытки.
- Вы думаете, что иначе вы не «настоящий программист»? Использование готового движка не делает разработчика игр хуже.
Для этого их и придумали! Это просто инструмент для создания игр.
99% проектов можно разработать с использованием существующего программного обеспечения — в этом нет ничего зазорного.
Ведь главное – это сама игра!
- Если вы хотите таким образом сэкономить время или деньги, забудьте об этом! Создание движка с нуля занимает много времени, а время = деньги.
Выгоднее использовать готовое программное обеспечение, чем пытаться разработать собственное.
В долгосрочной перспективе это может быть выигрышной стратегией, но только в том случае, если движок является основой нескольких прибыльных проектов и при этом гораздо удобнее в использовании, чем коммерческие.
Разработать такое программное обеспечение сложно, особенно если это ваш первый опыт (и практически невозможно, если речь идет о 3D).
Чем меньше у вас практики в создании игр, тем сложнее будет разработать движок — обязательно потренируйтесь, прежде чем браться за игровое программное обеспечение.
Я начал с флеш-игр в 90-х и 00-х, и ни один движок в то время не поддерживал импорт флеш-анимации.
Единственным выходом было создание собственного программного обеспечения.
Гораздо приятнее и быстрее закинуть swf-файлы в папку ресурсов и сразу использовать анимацию в игре без промежуточных действий типа экспорта в списки спрайтов.
Конечно, целесообразность создания собственного движка во многом зависит от количества опыта как в разработке игр, так и в программировании.
Приятно делать собственный софт, а не постоянно гуглить туториалы и самостоятельно отлаживать возникающие ошибки.
При этом достаточно допустить пару ошибок, и проект развалится, и обратиться за советом будет не к кому.
Собственный движок означает полный контроль, но и полную ответственность за продукт.
Что?
Игровой движок — это рабочая среда, в которой создаются игры.Он состоит из основы, на которой построен проект, и частей, которые, подобно деталям Лего, составляют саму игру.
Это золотая середина между «игровой логикой» и «скучной технической ерундой»: благодаря движку вам не придется вручную прописывать в коде игры, как вывести на экран условный треугольник, можно сразу приступить к работе над взаимодействие элементов.
Разные двигатели выполняют за вас разный объем работы.
Некоторые просто отображают графику на экране ( Вспышка , Пико-8 ).
Другие представляют собой целую игру с возможностью кастомизации или узко заточены под конкретный жанр( РПГмейкер , Рен'Пи ).
И между ними существует бесчисленное множество вариантов.
Игровые движки обычно основаны на простых платформах, таких как СДЛ И OpenGL и включать специализированные библиотеки для аудио, видео, физических и математических расчетов и всего остального.
При создании движка нет необходимости прописывать каждую деталь вручную; соответствующая библиотека доступна практически для каждой потенциально полезной опции.
Основные функции двигателя.
Это основы, необходимые для того, чтобы начать создавать игры.
Инициализация системы.
Приводит программу в боевую готовность после запуска - открывает окно, загружает данные.
Стандартная библиотека SDL может справиться с этой задачей (и даже больше!), и ее проще использовать.
Контроль частоты кадров
Ограничивает частоту кадров для обеспечения плавности изображения и оптимизации производительности.
Входить
Существует много способов реагировать на нажатия кнопок или движения джойстика, и ранее упомянутый SDL обычно справляется с этим.Поэтому, если он используется для инициализации, больше ничего устанавливать не нужно.
На его основе можно построить мощную и гибкую систему ввода, но для начала будет достаточно системы по умолчанию.
Рендеринг
Большинство (ну по крайней мере 75%) игр так или иначе используют графику, и за это отвечает движок.В 2D-игре минимальному рендереру достаточно отображать на экране текстурированные четырехугольники.
Шейдеры, буферы вершин, рендеринг с одним буфером, сетки, материалы и т. д. — отличные варианты, которые при необходимости можно добавить позже.
Если вы хотите повозиться с OpenGL или Vulkan и настроить рендерер, молодец! Но помните, нет ничего постыдного в использовании готовых библиотек, таких как Огре3D .
Выбор зависит от целей и потребностей разработчика, а также от того, какие задачи интереснее решать самостоятельно.
Математика и другие утилиты
Желательно, чтобы и код игры, и движок имели доступ к этим библиотекам.Плюс — ко всем остальным полезным функциям и формулам, которые вы встретите в процессе разработки.
СТБ — отличный ресурс для поиска всевозможных утилит, которые могут пригодиться при создании движка.
Дополнительные функции
Еще несколько систем, которые лучше добавлять в движок ближе к тому моменту, когда они непосредственно нужны для игры:Управление игровыми объектами и сценами
Можно писать код вручную, но практичнее предусмотреть систему обработки отдельных игровых объектов и коллекций.Это один из ключ механизмы в движке, потому что он управляет логикой игры.
Из каких компонентов состоят объекты, на какие типы событий они реагируют, как происходит взаимодействие, как насчет структуры памяти, используется ли ECS? (Кстати, «чистую» неадаптированную ECS лучше использовать только для конкретных случаев.
) Эти и другие вопросы должна решать система управления объектами и сценами.
Для таких задач доступны готовые библиотеки (особенно для чистого ECS), но поскольку эта структура оказывает большее влияние на код игры, чем другие, я склоняюсь к DIY-подходу.
Использование существующего решения заставит вас постоянно думать о том, как вписать игровую логику в рамки.
Но нам нужно сделать обратное — адаптировать движок для выражения задуманной игровой логики.
Аудио
Звуковые эффекты и музыка здесь разделены, хотя и спрятаны под одним названием.Основные необходимые функции — запуск и остановка звуковых циклов и воспроизведение звуковых эффектов от начала до конца.
Аудио этим не ограничивается, но даже с двумя базовыми опциями вы можете многое сделать.
Недостатком является то, что стандартные звуковые фреймворки ( ФМод и Мудрый ) — коммерческий и с кучей лицензионных ограничений.
Однако большинство ресурсов с открытым исходным кодом досадно неудобны (поздоровайтесь ОпенАЛ ).
Я использую его сам ФАудио — на мой вкус простая и удобная основа для построения сложной звуковой механики.
Загрузка файлов и управление ими
Файлы скачиваются всеми играми.Вероятно, вы не захотите вручную повторно загружать и декодировать файлы, которые вы уже добавили, поэтому вам понадобится система, которая справится с этим.
В будущем к загрузчику файлов могут быть добавлены и другие функции, такие как поддержка модов или динамическая загрузка.
Это не срочно — поначалу можно использовать встроенный менеджер, но со временем файлов станет так много, что вам понадобится удобная система управления файлами и ресурсами.
сеть
Хорошо, работа в сети (многопользовательская онлайн-игра) ОЧЕНЬ необязательна.Если режим p2p не планируется, то не беспокойтесь.
Однако эту систему чрезвычайно сложно интегрировать в движок, не предназначенный для многопользовательских игр.
Поэтому, если вы планируете или рассматриваете возможность добавления мультиплеера, подготовьте почву заранее, ведь в противном случае вам придется переделывать все системы.
Это базовый набор систем, входящих в игровой движок.
Другие варианты типа обнаружение столкновений, физика, сериализация, анимация и пользовательский интерфейс уже являются необязательными.
Они распространены, поэтому включены в большинство движков, но для создания игр они не требуются.
Например, предотвращения столкновений можно добиться с помощью математических утилит, а алгоритм можно записать в код игры.
Простейшую гравитацию и ускорение можно регулировать без физических движков, таких как Коробка2D или Пуля .
А полная сериализация вообще не нужна, если вам просто нужно сохранить чекпоинт. В специальном движке определенно систем и функций будет меньше, чем в универсальном коммерческом.
Это цель! Unity и Unreal — огромные монолиты, и каждая отдельная игра использует лишь небольшую часть предлагаемых возможностей.
Добавляйте только то, что необходимо для вашего конкретного случая использования, и сосредоточьтесь на том, чтобы сделать инструменты разработки лучше и проще в использовании.
Прежде чем использовать свой, ознакомьтесь с тем, как работают другие игровые движки.
Понять, какие парадигмы и алгоритмы они используют, что реализовано хорошо, а что раздражает. Попробуйте создать мини-игру на нескольких движках, чтобы понять, как они работают.
Как?
Итак, вы взвесили все за и против, поняли, чего хотите, и решили приступить к созданию движка.И как это сделать? Прямо в точку: делать игру параллельно с разработкой движка.
Это правило нельзя нарушать.
Изучите основы как можно быстрее и сразу приступайте к созданию игры на их основе.
Двигатель - ничего нет игры.
Это необходимо, поскольку функционал движка должен соответствовать потребностям сделанных на нем игр.
Вы не сможете понять, как создать хорошую систему анимации, если проект не требует сложной анимации.
Слабые места движка проявляются в процессе написания игры.
Может быть, нам нужна древовидная система, чтобы удаленные объекты не отображались, пока не окажутся на определенном расстоянии? Я не знаю, и вы не узнаете, пока не построите игровой уровень, который ужасно зависает. И даже тогда проблема может быть не в обновлении объектов — нужно проверить, чтобы понять.
Не программируйте ничего, что вам не нужно.
Если единственным пользовательским интерфейсом в игре является кнопка «Играть» в главном меню, поздравляем! Вам не нужно создавать причудливый пользовательский интерфейс.
В Конец - ночь Здесь нет физического движка или детектора столкновений.
Там даже камеры нет, потому что она там не нужна.
Для составления карты мира я использовал таблицу .
csv вместо каких-либо модных редакторов.
Это легко сделать и отлично работает. Не буду вдаваться в подробности реализации — слишком много методов, каждый из которых подходит для определенных случаев.
Не существует «лучшего варианта рендеринга» или «самого правильного способа манипулирования объектами».
Все зависит от игры.
Начните с основ и расширяйте по мере необходимости.
Что касается языков программирования, выберите тот, на котором вы говорите лучше всего.
Разработка движка сама по себе непростая задача, но если заниматься ею параллельно с изучением C++, обе эти задачи станут в два раза сложнее.
C# идеально подходит для создания движка.
Медленнее, чем C++, но не критично.
Более медленный язык, такой как Python, может оказаться трудным, если в игре много движущихся объектов.
но для некоторых игр он подойдет. Используйте то, что удобно.
И далее - С первой попытки это не будет идеально .
Моя первая игра на самодельном движке была Закрытие , и это полный бардак (забавно, что он был номинирован на премию «Техническое совершенство» на фестивале независимых игр 2010 года).
Две системы рендеринга и обновления обрабатывали всю игру.
Добавление новых объектов было чрезвычайно трудоемким; нам пришлось добавить кучу кода и поработать с кривыми редакторами анимации, так что в итоге у нас осталось около десятка интерактивных объектов.
Некоторые из них имели несколько вариаций, радикально менявших поведение объекта — это было проще, чем добавлять новые.
Таким образом, прожекторы, зеркала и турели — это, по сути, один и тот же объект! Но с ошибками приходит опыт. Движок Closure был написан плохо, но его было достаточно, чтобы запустить игру на PS3. Идея переписать некоторые части движка была заманчивой, но это лишь задержало бы выпуск игры.
Вместо этого я писал заметки о том, что пошло не так, чтобы в следующий раз учесть ошибки.
Особенно о том, что мешало собственно созданию игры.
То же самое и с «Конец близок».
В его движке (который, кстати, НАМНОГО лучше, чем Closure) все еще было множество ошибок, которые я стиснул зубы, чтобы исправить.
Как только игра вышла, я сразу начал улучшать движок для следующего проекта, исправлять досадные ошибки и добавлять новые возможности.
И так снова и снова: изучаешь, создаешь игру, запускаешь ее и делаешь все заново.
Пока двигатель не станет действительно хорошим.
Я не вдавался в технические подробности того, как внедрить в движок каждую отдельную систему.
Это зависит от конкретных случаев использования, способов сотни — и каждый из них правильный.
Понимание того, что вам подходит, — это суть разработки движка, и с этим мышлением вам следует начинать создавать свои собственные проекты.
Это все, что я хотел вам сказать в этой статье.
Скорее всего, это либо сподвигло вас на разработку собственного движка, либо полностью отпугнуло от этой идеи.
Оба варианта хороши, если вы понимаете, чего хотите.
Теги: #Разработка игр #Игры и игровые приставки #Дизайн игр #дизайн игр #unity #gamedev #unreal engine #игровой движок #engine
-
Изменения В Составе Участников
19 Oct, 24 -
Звонки В Приложениях Авито
19 Oct, 24 -
«Мои Родственники»: Сеть Родственников
19 Oct, 24 -
Обзор-Эпитафия Samsung Gear Live
19 Oct, 24 -
Другие Браузеры Добрались До Антарктиды
19 Oct, 24
