Как написать свой движок: Как написать собственный игровой движок на C++ / Хабр

Содержание

Как написать собственный игровой движок на C++ / Хабр

Перевод статьи Джеффа Прешинга (Jeff Preshing) How to Write Your Own C++ Game Engine.

Как написать собственный игровой движок на C++

В последнее время я занят тем, что пишу игровой движок на C++. Я пользуюсь им для создания небольшой мобильной игры Hop Out. Вот ролик, записанный с моего iPhone 6. (Можете включить звук!)

Your browser does not support HTML5 video.

Hop Out — та игра, в которую мне хочется играть самому: ретро-аркада с мультяшной 3D-графикой. Цель игры — перекрасить каждую из платформ, как в Q*Bert.

Hop Out всё ещё в разработке, но движок, который приводит её в действие, начинает принимать зрелые очертания, так что я решил поделиться здесь несколькими советами о разработке движка.

С чего бы кому-то хотеть написать игровой движок? Возможных причин много:

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

Вам нравится ощущение контроля. Организовать код именно так, как вам хочется, и всегда знать, где что находится — это приносит удовольствие.
Вас вдохновляют классические игровые движки, такие как AGI (1984), id Tech 1 (1993), Build (1995), и гиганты индустрии вроде Unity и Unreal.
Вы верите, что мы, индустрия игр, должны сбросить покров таинственности с процесса разработки движков. Мы пока не очень-то освоили искусство разработки игр — куда там! Чем тщательнее мы рассмотрим этот процесс, тем выше наши шансы усовершенствовать его.

Игровые платформы в 2017-ом — мобильные, консоли и ПК — очень мощные и во многом похожи друг на друга.

Разработка игрового движка перестала быть борьбой со слабым и редким железом, как это было в прошлом. По-моему, теперь это скорее борьба со сложностью вашего собственного произведения. Запросто можно сотворить монстра! Вот почему все советы в этой статье вращаются вокруг того, как сохранить код управляемым. Я объединил их в три группы:

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

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

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

Мой первый совет — не задерживаясь заставьте что-нибудь (что угодно!) работать, затем повторите.

По возможности, начните с образца приложения, которое инициализирует устройство и рисует что-нибудь на экране. В данном случае я скачал SDL, открыл

Xcode-iOS/Test/TestiPhoneOS.xcodeproj, затем запустил на своём iPhone пример testgles2.

Вуаля! У меня появился замечательный вращающийся кубик, использующий OpenGL ES 2.0.

Моим следующим шагом было скачивание сделанной кем-то 3D-модели Марио. Я быстро написал черновой загрузчик OBJ-файлов — этот формат не так уж сложен — и подправил пример, чтобы он отрисовывал Марио вместо кубика. Ещё я интегрировал SDL_Image, чтобы загружать текстуры.

Затем я реализовал управление двумя стиками, чтобы перемещать Марио. (Поначалу я рассматривал идею создания dual-stick шутера. Впрочем, не с Марио).

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

К тому моменту я отказался от формата OBJ и написал скрипт на Python для экспорта собственных JSON-файлов из Blender. Эти JSON-файлы описывали заскиненный меш, скелет и данные анимации. Я загружал эти файлы в игру с помощью библиотеки C++ JSON.

Как только всё заработало, я вернулся в Blender и создал более проработанного персонажа (Это был первый сделанный и зариганный мной трёхмерный человек. Я им весьма гордился.)

В течение следующих нескольких месяцев я сделал такие шаги:

Начал выделять функции работы с векторами и матрицами в собственную библиотеку трёхмерной математики.
Заменил .xcodeproj на проект CMake
Заставил движок запускаться и на Windows, и на iOS, потому что мне нравится работать в Visual Studio.
Начал перемещать код в отдельные библиотеки «engine» и «game». Со временем, я разделил их на ещё более мелкие библиотеки.
Написал отдельное приложение, чтобы конвертировать мои JSON-файлы в бинарные данные, которые игра может загружать напрямую.
В какой-то момент убрал все библиотеки SDL из iOS-сборки. (Cборка для Windows всё ещё использует SDL.)

Ключевой момент в следующем: я не планировал архитектуру движка до того как начал программировать

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

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

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

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

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

The Vicious Circle of Generalization Томаша Дабровски и Don’t Let Architecture Astronauts Scare You Джоэла Спольски.

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

Итеративный подход дал мне куда более элегантную архитектуру, чем я мог бы вообразить, глядя на чистый лист бумаги. iOS-сборка моего движка сегодня на 100% состоит из оригинального кода, включая собственную математическую библиотеку, шаблоны контейнеров, систему рефлексии/сериализации, фреймворк рендеринга, физику и аудио микшер. У меня были причины писать каждый из этих модулей самостоятельно, но для вас это может быть необязательным. Вместо этого есть множество отличных библиотек с открытым исходным кодом и разрешительной лицензией, которые могут оказаться подходящими вашему движку.

GLM, Bullet Physics и STB headers — лишь некоторые из интересных примеров.

Дважды подумайте, прежде чем слишком обобщать

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

Время от времени нарушайте принцип DRY

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

Owned<> для динамически выделяемых объектов, имеющих единственного владельца.
Reference<> использует подсчёт ссылок чтобы позволить объекту иметь несколько владельцев.
audio::AppOwned<> используется кодом за пределами аудио микшера. Это позволяет игровым системам владеть объектами, которые аудио микшер использует, такими как голос, который в данный момент воспроизводится.

audio::AudioHandle<> использует систему подсчёта ссылок, внутреннюю для аудио микшера.

Может показаться, что некоторые из этих классов дублируют функциональность других, нарушая принцип DRY. В самом деле, в начале разработки я пытался повторно использовать существующий класс Reference<> как можно больше. Однако, я выяснил, что время жизни аудио-объекта подчиняется особым правилам: если объект закончил воспроизведение фрагмента, и игра не владеет указателем на этот объект, его можно сразу же поместить в очередь на удаление. Если игра захватила указатель, тогда аудио-объект не должен быть удалён. А если игра захватила указатель, но владелец указателя уничтожен до того, как воспроизведение закончилось, оно должно быть отменено. Вместо того чтобы усложнять

Reference<>, я решил, что будет практичнее ввести отдельные классы шаблонов.

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

Использовать разные соглашения о вызове — это нормально

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

В моём C++ движке некоторые функции принадлежат классами, а некоторые — нет. Например, каждый противник в игре — это класс, и бо́льшая часть поведения противника реализована в этом классе, как и следовало ожидать. С другой стороны, sphere casts в моём движке выполняются вызовом sphereCast(), функции в пространстве имён physics. sphereCast() не принадлежит какому-либо классу — это просто часть модуля physics. У меня есть система сборки, которая управляет зависимостями между модулями, что сохраняет код достаточно (для меня) хорошо организованным. Заворачивание этой функции в произвольный класс никоим образом не улучшит организацию кода.

А ещё есть динамическая диспетчеризация, которая является формой полиморфизма. Часто нам нужно вызвать функцию объекта, не зная точного типа этого объекта. Первый порыв программиста на C++ — определить абстрактный базовый класс с виртуальными функциями, затем перегрузить эти функции в производном классе. Работает, но это лишь одна из техник. Существуют и другие методы динамической диспетчеризации, которые не привносят так много дополнительного кода, или имеют другие преимущества:

С++11 ввел std::function, и это удобный способ хранить функции обратного вызова. Также можно написать собственную версию std::function, не вызывающую столько боли, когда заходишь в неё в отладчике.
Многие функции обратного вызова могут быть реализованы с помощью пары указателей: указателя на функцию и непрозрачного аргумента. Требуется только явное приведение внутри функции обратного вызова. Это часто встречается в библиотеках на чистом C.
Иногда базовый тип известен во время компиляции, и можно привязать вызов функции вообще без накладных расходов времени выполнения. Turf — библиотека, которой я пользуюсь в своём игровом движке, сильно полагается на этот способ. Взгляните на turf::Mutex для примера. Это просто typedef над платформо-специфичными классами.
Иногда самый прямой путь — создать и поддерживать таблицу сырых указателей на функцию своими силами. Я использовал этот подход в своих аудио микшере и системе сериализации. Интерпретатор Python также на полную использует эту технику, как будет показано ниже.
Вы можете даже хранить указатели на функцию в хэш-таблице, используя имена функций как ключи. Я пользуюсь этой техникой для диспетчеризации событий ввода, таких как события мультитача. Это часть стратегии по записи ввода игры и воспроизведения его в системе реплеев.

Динамическая диспетчеризация — обширная тема. Я лишь поверхностно рассказал о ней, чтобы показать как много способов реализации существует. Чем больше растяжимого низкоуровневого кода вы пишите — что не редкость для игрового движка — тем чаще обнаруживаете себя за изучением альтернатив. Если вы не привыкли к программированию в таком виде, интерпретатор Python, написанный на C — отличный пример для изучения. Он реализует мощную объектную модель: каждый PyObject указывает на PyTypeObject, а каждый PyTypeObjeсt содержит таблицу указателей на функцию для динамической диспетчеризации. Документ Defining New Types — хорошая начальная точка, если вы хотите сразу погрузиться в детали.

Осознайте, что сериализация — обширная тема

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

Для многих, если не большинства, движков игровой контент создаётся в разных редактируемых, таких как .png, .json, .blend или проприетарных форматах, затем в конце концов конвертируется в платформо-специфичные форматы игры, которые движок может быстро загрузить. Последнее приложение в этом процессе часто называют «cooker». Cooker может быть интегрирован в другой инструмент или даже распределяться между несколькими машинами. Обычно, cooker и некоторое количество инструментов разрабатываются и поддерживаются в тандеме с самим игровым движком.

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

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

    void load(InStream& in, u32 fileVersion) {
        // Загрузить ожидаемые переменные-члены
        in >> m_position;
        in >> m_direction;

        // Загрузить более новую переменную только если версия загружаемого файла больше 2.
        if (fileVersion >= 2) {
            in >> m_velocity;
        }
    }

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

Когда вы собираете Blender из исходников, выполняется много шагов. Во-первых, компилируется и запускается собственная утилита makesdna. Эта утилита парсит набор заголовочных файлов C в дереве исходников Blender, а затем выводит краткую сводку со всеми определёнными типами в собственном формате, известном как SDNA. Эти SDNA-данные служат данными рефлексии. SDNA затем компонуется с самим Blender, и сохраняется с каждым .blend-файлом, который Blender записывает. С этого момента, каждый раз когда Blender загружает .blend-файл, он сравнивает SDNA .blend-файла cо SDNA, скомпонованной с текущей версией во время исполнения и использует общий код сериализации для обработки всех различий. Эта стратегия даёт Blender впечатляющий диапазон обратной и прямой совместимости. Вы всё ещё можете загрузить файлы версии 1.0 в последней версии Blender, а новые .blend-файлы могут быть загружены в старых версиях.

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

Несомненно, я упускаю множество деталей. В этой статье я хотел только показать, что есть много способов сериализовать данные, некоторые из которых очень сложны. Программисты просто не обсуждают сериализацию столько же, сколько другие системы движка, даже несмотря на то, что большинство других систем зависят от неё. Например, из 96 программистских докладов GDC 2017, я насчитал 31 доклад о графике, 11 об онлайне, 10 об инструментах, 3 о физике, 2 об аудио — и только один, касающийся непосредственно сериализации.

Как минимум, постарайтесь представить, насколько сложными будут ваши требования. Если вы делаете маленькую игру вроде Flappy Bird, с несколькими ассетами, вам скорее всего не придётся много думать о сериализации. Вероятно, вы можете загружать текстуры напрямую из PNG и этого будет достаточно. Если вам нужен компактный бинарный формат с обратной совместимостью, но вы не хотите разрабатывать свой — взгляните на сторонние библиотеки, такие как Cereal или Boost.Serialization. Не думаю, что Google Protocol Buffers идеально подходят для сериализации игровых ресурсов, но они всё равно стоят изучения.

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

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

Зачем писать свой игровой движок? / Блог компании Social Quantum / Хабр

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

Unity в условиях многообразия игровых движков

Зачем в современном мире, в котором существуют такие гиганты, как Unity, делать что-то своё, писать собственные игровые движки?

Перед вами слайд с данными компании Unity Technologies по использованию различных игровых движков в 2017 году. В следующем году ситуация, как вы понимаете, поменяется. Нас интересует то, чему тут отведён 41%, то есть — движки собственной разработки. Если взглянуть на 5 самых больших компаний, представленных на конференции, то у каждой из них будет свой движок. Получается, что в большей части компаний, представляющих игровую индустрию, используются какие-то внутренние разработки. Далеко не всегда это — самое разумное в мире решение, но это так.

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

Армия семи наций

Пирамиду, которую вы видите на слайде, можно продолжить и вверх, и вниз. Она абсолютно чётко вас ограничивает. Снизу — операционная система, ещё ниже — какие-то базовые технологии. Сверху — аддоны над движками, готовый инструментарий, который поставляют с играми, вроде инструментов Neverwinter Nights. Что бы вы ни делали, вы, так или иначе, оказываетесь внутри этой штуки.

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

Теперь проанализируем затраты времени, сил и средств, необходимых на разработку игры.

Назад, к основам

Если вся показанная на слайде круговая диаграмма — это игра, то движок — это её синий сектор. В идеальном мире, разрабатывая игру, вы можете вынуть этот синий сектор и поставить туда красный, или желтый, или зеленый. Можно одно большое «U» поменять на другое большое «U», или взять некое маленькое «x», и то, что вы выбрали, там тут же заработает. В реальности это не так, но мы должны к этому стремиться. Подобная картина, если речь идёт о реальных проектах, наблюдается в игровой индустрии постоянно. Бывает и так, что вся эта диаграмма занята движком, но это справедливо лишь для каких-то демонстрационных продуктов.

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

Мифический человеко-месяц

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

Долгая разработка движка? Но если разработка с собственным движком пойдёт быстрее, то это — не аргумент. О том, что такое «рационально», пожалуй, вообще никто не знает. Поэтому все эти возражения очень субъективны.

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

13 причин почему

Когда может понадобиться собственный движок? Разберём этот слайд по пунктам:

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

Вот вам история. В одной компании на сайте было задание для программистов, выглядящее примерно так: «Ребята, если хотите у нас работать, напишите пожалуйста «Астероиды», которые должны запускаться на платформе Android без использования внешних библиотек. Мы считаем, что на это вам достаточно 8 часов. Время пошло». Потом время увеличили до 12 часов. Может быть, выглядит это смешно. Сначала я наблюдал за этим, снаружи, потом заглянул в эту компанию и попросил рассказать мне о том, что прислали в виде отклика на это задание. Как оказалось, отбор прошли больше двухсот программ, то есть — эти программы запускались и работали. Это значит, что если вы вдруг захотите издать «Астероиды» для Android, то найдется как минимум 200 человек, которые могут это сделать за 8 часов. Я не говорю, что это можно продавать. Но рассказал я эту историю к тому, что очень часто, собственно, движок — это и есть Time to Market. Скажем, просто потому, что у вас такие маленькие потребности, что вы дольше будете изучать документацию на тот же Unreal, чем просто взять и сделать своё.

Lord of the Platform — властелин платформы. Существуют платформы, для которых нет готовых инструментов. Например, STB, set-top box (ресивер цифрового телевидения) — коробочка для кабельного телевидения, которая стоит на столе у каждого третьего американца.

У Warner имеется 120 миллионов пользователей этой услуги. Если вы пишете туда софт, и игры в том числе, то вы имеете доллар с коробки. Это 120 миллионов долларов в год. При этом кроме вас писать для этой штуки не может больше никто. Потому что там нет DirectX, там вообще ничего нет. Если вы умеете писать программы для STB — то вы властелин платформы, вы имеете эти сто двадцать миллионов долларов в год. Чем не повод писать свой движок?

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

Можно говорить, что нас интересуют телефоны, но речь идёт о миллионах долларов. Почему бы не писать для других устройств? В результате, есть абсолютно четкие причины это делать.
Или, например, перед нами новейшие смарт-часы. SDK к ним ещё не вышел, никто не понимает, что с ними делать, а если вы сможете, своими силами, написать для них качественный продукт, то вы, скажем, заработаете по доллару с каждого такого устройства. Если их будет продано два миллиона — то вам достанется два миллиона долларов. Написать это несложно, но для этого надо делать свой движок, потому что чужих нет, а компании-производители таких устройств не будут делать общедоступные движки для разработки под них.

Weak but proud devices — малые, но гордые устройства. Если вы делаете игры для мобильных телефонов, собираете хоть какую-то статистику, то вы знаете, что с аппаратным обеспечением у устройств от Apple всё более-менее нормально, а вот с платформой Android — просто беда.

Половина устройств на рынке построена на базе чипсета Mali-400 от ARM, любой бюджетный телефон это Mali-400. И если вам платят за то, что вы занимаетесь телефонными приложениями, то вы должны писать для этих вот маленьких, но гордых устройств, которые пока уходить с рынка не собираются и уйдут с него очень нескоро.

При этом в случае с iPhone можно делать хоть какие-то ставки на прогресс. Например, ожидается, что Unreal будет работать под iPhone 10, хотя пока всё это доведут до ума, будет уже какой-нибудь iPhone 12, 15 или 17. А вот в случае с миром вообще в краткосрочной перспективе на прогресс ставить тяжелее. Потому что апгрейд устройств происходит очень медленно.

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

Own language for own ideas — собственные языки для собственных идей. Когда вы сами делаете движок — вы можете задействовать эту концепцию. Дело в том, что основная проблема нашей индустрии в том, что домен геймдизайнера — это филология. Он мыслит на обычном языке. Он ничего другого не умеет. А программист мыслит в домене программирования и между ними пропасть. Как результат, некая итерация, которую приходится непрерывно повторять, стоит, например, два доллара. И вы постоянно тратите эти деньги.

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

Unique Mechanics = Unique engines — уникальные механики = уникальные движки. Мои знакомые писали Minecraft в пятнадцатом году с использованием Unity. Был ли смысл всё это делать — вопрос открытый. Но движок они выбрали и принялись за работу. Однако движок им, очевидно, очень мешал. Им было тяжело. У них были очень долгие итерации. После того, как мы их проконсультировали, они написали, буквально за три дня, собственный рендер. Причём весь остальной код, ответственный, скажем, за построение мира, естественно, никуда не делся. Просто всё это перестало быть в C#, перестало быть в Unity. И работа закипела. Не знаю, удалось ли им на этом заработать, но главный вывод из этой истории заключается в том, что им изначально не надо было использовать Unity.

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

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

The game is not a render — the game is everything else — игра это не рендер, игра — это всё остальное. Мы об этом уже говорили. Если у вас проблема только в том, чтобы нарисовать что-то, или, скажем, использовать звук, делая многоплатформенную игру, то в рассмотренной ранее пирамиде можно было видеть подобные истории. Если вы говорите: «Я хочу проигрывать звук на трёх платформах», то вам для этого не нужна большая «U» — маленькой «c» будет вполне достаточно.

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

Преимущества разработки своего движка

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

Buying is often better than mortgage — покупка часто предпочтительнее ипотеки. Игровая разработка — это, так или иначе, деньги. Есть способы монетизации, при использовании которых покупка не просто лучше, чем ипотека, а это просто единственно возможный вариант.

Если кто-то работал на мобильных технологиях, то вы всё понимаете. Если на коробке движка написано: «10 процентов роялти», то это категорически неприемлемо, вы не заработаете столько. У вас может быть прибыль сто процентов, но вы работаете из 2-х. То есть, если у вас есть роялти, то это чисто экономическая причина отказа от движка. А надо сказать что три, точнее — два из самых популярных на сей момент движков — это как раз вопрос отчислений. То есть такой вариант сразу отпадает.

Specificity is better than universality in the long term — на длинной дистанции специализированные инструменты всегда лучше универсальных. Очевидно, что универсальность всегда медленнее, она менее производительна и менее специфична, чем специализированные вещи. Движок, написанный под конкретную задачу, справится с ней лучше и быстрее, чем универсальное средство. На длинной дистанции специальные инструменты гораздо выгоднее, чем универсальные.
Tools and pipelines are developed within — пайплайны и средства разработки, созданные внутри компании. Любой движок, придуманный людьми вне вашей компании, ориентируется на несколько вещей. Первая — это best practices. То есть ориентируется движок другой компании не на то, как ваш художник рисует, а на то, как рисуют художники, идеальные с их точки зрения. Вполне возможно, что ваши художники рисуют по-другому. У них свой пайплайн и у них это получается.

У вас есть 2 варианта действий: либо их переучивать так, как положено с точки зрения best practices, либо использовать своё. Есть простые примеры. Предположим, вы говорите: «Мы импортируем 3D-модели». Вы не знаете — что там с той стороны. Поэтому вам нужен промежуточный формат. Промежуточный формат пускай будет FBX. Огрехи FBX все, кто этим занимаются, знают. А вам некуда деваться, потому что вы не знаете, что там будет делаться, вы не будете писать плагины под 450 средств 3D-моделирования.

Когда вы работаете внутри своей компании, то вы можете реализовать тот самый пайплайн, который у вас уже существует и надеть на него сверху то, чем вы занимаетесь. На самом деле, это очень важно. Дело в том, что всё это имеет отношение ко времени разработки и, как следствие, к стоимости. Поэтому, когда вы разрабатываете у себя, вы можете утилизировать тот пайплайн, который уже есть. Иначе у вас документ, который называется «Правило выгрузки 3D-моделей и создания материалов для художников» будет больше, чем дизайн документ, а это неправильно.

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

Скажем, в соседнем офисе сидят люди, которые делают движок. Каждый, кто пытался исправить баг в универсальном движке, то есть написать в багтрекер Unity или Epic, знает, что лучше даже не начинать. А если разработчики сидят в соседнем офисе, то вы можете к ним обратиться и решить вопрос за 15 минут.

То же касается и предложения нового функционала, если у вас есть на это право. Исследование новых технологий так же упрощается при использовании собственных движков.
Предположим, ваш программист съездил на конференцию, послушал там лекцию о чём-то новом. Он тут же это попробовал, вы получили представление об этом новом и знаете, нужно оно вам или нет. Вы можете прямо-таки реактивно пробовать что-то интересное из мира науки. А это, кстати, значит, что в компании может быть человек, который будет называться «исследователь». При этом исследованиями можно заниматься и на том же Unreal, поскольку он поставляется в исходниках.

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

Разработка собственного движка — это не только преимущества. Это ещё и риски. Рассмотрим их.

Риски, связанные с разработкой своего движка

Рассмотрим риски сопровождающие разработку и использование собственных движков:

Development time — время разработки. Это понятие пересекается с тем, что мы говорили о времени выхода на рынок. Разработка движка может быть и очень долгой, и достаточно быстрой. Но время разработки движка, в любом случае, вносит вклад в общее время разработки проекта. Поэтому это тоже риск. Например, мне известны коллективы, у которых время разработки движка стремится к бесконечности.
Terminal cases of vendor-lock — терминальные случаи привязки к поставщику. Это относится не только к большим компаниям, но и к маленьким. Скажем, вы наняли Васю, он написал движок, потом влюбился, от вас уволился, и в том, что он написал, не понимает никто. В результате у вас vendor-lock похлеще Google. Потому что в Google еще можно письмо написать, хотя они и не ответят, а здесь с уходом программиста всё закончилось. В результате — потерянное время на разработку и другие неприятные последствия. Надо уметь избегать этих рисков.
Reinvent the wheel — изобретение колеса. Тут дело в том, что мы живём в мире, в котором вы всё равно изобретаете велосипеды. При разработке движка получается перенос велосипедного завода из кода игры в код движка, хотя там им и не место.
Closed ecosystem — закрытая экосистема. Всё, что делается внутри компании, принадлежит этой компании. Я знаю кучу компаний, у которых есть что-то вроде своего скриптового языка. Это может быть какой-нибудь XScript, который работает только в рамках их решения.

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

Главный вопрос жизни, вселенной и всего такого

Рассмотрим очень важный вопрос. Какой ресурс требуется в первую очередь для разработки собственного движка? Ресурс, без которого бессмысленно задумываться о том, надо или не надо делать собственный движок. Ответ на него, конечно, не 42. Вопрос в том — что вообще нужно, чтобы просто хотя бы иметь возможность сказать: «Да, у нас хоть что-то есть, мы можем начать что-то делать».

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

Программисты

Для того чтобы создать собственный движок, нужны программисты. Если не знаете — погуглите разницу между словами «developer» (разработчик) и «programmer» (программист). Это очень важно. Девелоперы — это основная группа. Игровая индустрия так устроена, что большинство людей в ней программистами назвать нельзя. Извините, но они разработчики. Разработчики не способны грамотно сделать движок. Опять же, если взглянуть на разницу между первыми и вторыми, то разработчики делают игры, а программисты делают инструменты. Разработчики делают продукт, компания зарабатывает за счёт продукта, но инструменты должны быть сделаны программистами, иначе они просто не будут работать.

С одной стороны, сейчас очень открытый мир. Я, например, знаю код Unreal 4 и CryEngine, он открыт. Все, кто хотят знать, могут узнать код Unity, есть огромное количество соответствующих материалов. Это значит, что этим способен заниматься тот, кто является программистом и читает по-английски. Там нет какого-то rocket science. Но с другой стороны, как выяснилось, программистов, которые читают по-английски, найти очень непросто. Поэтому вы должны знать, где они водятся, должны уметь их набирать, использовать, поощрять. Если вы это умеете, то можно уже и о своём движке задуматься. Если у вас таких людей нет, то у вас всё равно ничего не получится. Примеров тому — тьма. Дело не в том, что есть плохие и хорошие решения. Просто есть такие вещи, которые не могут работать изначально.

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

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

Техническая эпидемия

Сейчас уместно вспомнить ещё об одном аспекте поиска сотрудников, который касается, преимущественно, больших компаний. У таких компаний есть несколько подходов к подбору персонала.

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

Во-вторых, есть подход, который мы, в принципе, и исповедуем. Как работает кефир? Он всё вокруг превращает в себя. Берёте молоко, кидаете туда кефир — и нет молока, всё превратилось в кефир. У нас это выглядит так: «Ребята, давайте возьмём 5 сильных программистов, это будет внутренний технологический центр». И я всем говорю, что если вы можете себе позволить сделать RnD-отдел, если вы — большая компания — то сделайте. Пускай они даже ничего, с точки зрения денег, полезного не делают. Если компания укрепилась на рынке и перед ней возникает вопрос о том, куда расширяться, то ответом на этот вопрос может стать создание RnD-отдела. Когда компания уже богата, для неё это не потеря денег, потому что она столько денег теряет уже на том КПД, на котором сейчас работает наша игровая индустрия, что расходов на исследования просто не заметит.

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

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

Если компания уже настолько большая, что может себе позволить делать что-то интересное внутри себя, то это окупается даже с точки зрения денег. Поэтому если можете — то пробуйте. Выглядеть это может как угодно — скажем, делается своя ветка Unreal и там перерабатываем всё так, как хочется вам. Я, например, в одной из компаний делал браузер, который помещается в 2.5 мегабайт памяти. И он работал. Зачем — я не знаю, но это было бесконечно интересно.

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

Два мира

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

В игровой индустрии соседствуют два мира. Люди либо ориентированы на решение технологических задач, либо на нарратив. А посередине — кустарщина какая-то. То есть, инструментария практически нет. Слова, слова, слова — бах — код. Опять слова — и опять код. Мы считаем, что требуются инструменты, которые позволяют подключать к тому, что получится в результате работы над игрой, геймдизайнера, менеджера, других сотрудников, не являющихся программистами.

На слайде можно видеть behavior tree, дерево поведения. В принципе, это штука, просто взятая из википедии, но перед нами её оттуда взял Unreal. Ничего страшного в этом нет. Итак, документация к этому лежит на сайте Unreal, нам было несложно сделать подходящий интерфейс, совместимый с тем, что делается в Unreal. То есть, можно взять любой пример с анриловского сайта экшнов, пример самого поведения, так как формат вполне совпадает, вот так вот переписать, и оно заработает. Это значит, что я облегчил себе жизнь, я не пишу документацию. И таких штук здесь много.

В примере со слайда что-то происходит, бегает краб, кого-то ловит, в общем-то, это неважно. Внутри программист решает задачи, которые выглядят как «пойди в…», «стрельни в…», «посчитай расстояние» — и всё. Всё остальное поведение написано в этом редакторе человеком, который не имеет абсолютно никакого отношения к программированию. И это работает, в отличие от перевода текста в код. При этом если говорить, скажем, о балансе. Что такое баланс? Это — 15 коэффициентов, которые можно менять. А здесь описано поведение, а не коэффициенты.

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

Итоги

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

Смотрите, существует такая мода. Каждый второй, кого встречаешь, говорит тебе: «Golang», или говорит тебе: «Rust». И если бы это было сейчас, я бы в принципе задумался. Но когда ты приходишь в компанию руководителем процесса разработки движка, а было это год назад, тебе надо строить какие-то планы, а так придётся включать в эти планы пункт «Почитать о Go». Тут ведь важна производительность, а на C++ мы достаточно давно работаем, умеем им пользоваться.

А почему мы используем Lua? Потому что это недооценённый язык, он отлично подходит для встраивания. Почему JavaScript? Потому что так получилось. Потому что на рынке кроме V8 и Webkit ничего нет. А это монстроиды. Как я уже говорил, мы делали браузер, который занимает 2.5 мегабайт памяти, там есть JavaScript-движок, который проходит все тесты. У нас это есть, и вот поэтому — JavaScript. В результате, например, можно брать тех, кто знает JS и писал сайты на React.

Вопрос

Скажите, вы дерево поведения используете только для управления поведением, или применяете его ещё для управления игровыми механиками и для продвижения игрового прогресса?

Ответ

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

Вопрос

Насколько трудно прогнозировать развитие технологий на будущее? То есть, как сложно предвидеть появление каких-то подводных камней и тому подобных вещей?

Ответ

На данный момент я вижу одну проблему. Сейчас интересно выглядит технология WebAssembly. Flash умер. Мы хотим, естественно, издаваться ещё где-то на вебе. Портировать игру, скажем, с Unity на WebGL — это задача, которая не решается нажатием на одну кнопку. То есть сейчас мы смотрим на WebAssembly и пока неясно — будет ли это стандартом, или нет, начинать сейчас с этим работать, или подождать. В мобильных технологиях тоже ничего особенного не происходит. Нет пока каких-то сингулярных взрывов, но если будут — будем готовиться.

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

Как написать графический движок 3D, который можно использовать в JavaScript?

Недавно я сосредоточился на рисовании некоторых интересных фигур на холсте HTML 5.0. И я хочу написать графический движок 3D, который можно использовать в JavaScript. Я уже закончил вращающийся куб. И я хочу закончить фигуры, как этот пример: http:/ / gyu.que.jp/jscloth/touch. html .

Кто когда-нибудь пробовал в этой области?

graphic 3d-engine
Поделиться Источник user165273 30 октября 2009 в 17:14
5 ответов
Физический движок для sandy 3d
Я разрабатываю небольшую игру, чтобы выучить AS и Сэнди 3D. Я хочу включить физический движок в свою сцену 3D. Я хотел использовать WOW, как говорится в учебнике sandy, но веб-сайт WOW не работает, поэтому трудно что-то разработать без doc. Я ищу новый физический движок, который можно использовать…
графический движок j2me 2d
Для J2ME я нашел несколько фреймворков GUI, таких как LWUIT, J2ME Polish, Twuik и т. д., Я ищу графический движок 2d для платформы Java ME, предпочтительно легкий < 50K, я наткнулся на TinyLine , который поддерживает разумные функции для мобильного устройства. Точно так же у нас есть открытый…

4

Я написал движок Javascript 3D около года назад, примерно в то время, когда Google выпустила свой браузер Chrome с супербыстрым движком V8 Javascript. К сожалению, поскольку ни один браузер не предоставляет 3D графики API (например, OpenGL или Direct3D), этот движок искажает bitmap изображения на веб-страницу, чтобы получить аффинные текстурные треугольники (которые уступают перспективно-корректным текстурным треугольникам), что довольно медленно.
Я использовал свой движок Javascript 3D для создания библиотеки моделей 3D . (Подсказка: не просматривайте первую модель — она самая большая и медленная для просмотра!). Производительность составляет около 10 кадров в секунду для модели 3D с примерно 1000 треугольниками в Google Chrome на моем PC.
Я рассматривал возможность открытого поиска исходного кода для этого движка, но так и не удосужился сделать это. Если есть достаточный интерес, я помещу исходный код в Google Code.
Мой текущий проект pet — это движок Silverlight 3D и просмотрщик моделей , который является программным движком 3D (т. е. мой код C# контролирует цвет каждого пикселя). Silverlight 3 намного быстрее Javascript, но является нестандартным браузерным аддоном и по-прежнему не поддерживает аппаратное ускорение графики 3D (без больших накладных расходов).
Обновление: за время, прошедшее с момента написания этого поста, я обновил упомянутый выше просмотрщик моделей Silverlight, чтобы использовать Silverlight 5 и аппаратное ускорение 3D.
Поделиться voidstar69 05 ноября 2009 в 16:25

3

Как насчет привязки уже существующей библиотеки 3D к JavaScript? Как OpenGL.
V8-GL выставляет 80% из OpenGL API в JavaScript:
Поделиться Leftium 28 октября 2010 в 21:24

3

Правка: этот вопрос был задан много лет назад. С тех пор каждый браузер, кроме IE (на данный момент? ) добавлена поддержка webgl. Вы можете увидеть много образцов здесь: http://www.chromeexperiments.com/webgl /
Я действительно не хочу вас обескураживать, но для того, чтобы написать движок 3D в JavaScript, вы должны быть очень хорошо разбираетесь в математике/логике рендеринга 3D.
Поскольку вы не указали свой текущий опыт, я предполагаю, что вы этого не сделаете, и в этом случае я настоятельно рекомендую вам начать с чего-то другого. Например, XNA Game Studio . Вы пишете код в C#,, и уже есть много хорошо написанных APIs, которые абстрагируют большинство (но определенно не все) трудных частей. Но это отличный способ узнать много концепций и математики, лежащих в основе рендеринга 3D.
Однако если вы твердо решили начать с JavaScript, то в Интернете уже есть много ресурсов по этому поводу. Например этот 🙂
http:/ / dev.opera.com / статьи/просмотр / 3d-games-with-canvas-and-raycasting-part/
Удачи вам!
Поделиться Joel Martinez 30 октября 2009 в 17:18
3D движок для моделирования вождения
Существует ли какой-либо графический и физический движок с открытым исходным кодом 3D, специализирующийся на моделировании вождения? Что-то вроде настраиваемого игрового движка, ориентированного на игры, связанные с вождением, или что-то более специализированное для городских условий дорожного…
Android 2D графический игровой движок?
Я пытаюсь найти хороший графический движок 2D для игры… Что-то для игры вроде сверху вниз (небольшой угол, чтобы она выглядела 3D…), позволяющее пользователю передвигаться.. что-то вроде игры… Любая помощь была бы очень кстати, спасибо!

0

Я не знаю, как бы это получилось, если бы я его написал. Но вот некоторые из них существуют.
Поделиться Ólafur Waage 30 октября 2009 в 17:20

0

Чтобы написать его, вам нужно будет сначала решить, будете ли вы поддерживать Excanvas, чтобы IE мог использовать его или нет.
Это установит некоторые ограничения на то, что вы можете сделать, если поддерживаете IE.
Лучше всего просто начать с создания некоторых первичных форм, и, скорее всего, вы захотите иметь определенные примитивы, из которых можно построить все остальное, поэтому вы можете посмотреть на OpenGL или DirectX, на их примитивы.
Как только вы это сделаете и сможете перемещать их в пространстве 3D, вам захочется начать смотреть на добавление камер, но это будет относительно легко по сравнению с шагом 1.
К сожалению, все это очень тяжело в математике, поэтому вы получите огромный удар по производительности, если создадите несколько объектов 3D, которые должны часто перемещаться.
Я думаю, что лучше всего подождать, так как в конце 2007 года появились блоги для Firefox и Opera, чтобы иметь поддержку 3D в canvas: http://starkravingfinkle.org/blog/2007/11/animating-with-canvas/
Причина в том, что если он будет встроен в браузер, то большая часть тяжелой работы будет выполнена, особенно если он поддерживает какой-то аромат OpenGL.
Поделиться James Black 30 октября 2009 в 17:34
Похожие вопросы:

3d геометрический движок
Я новичок в обработке данных 3D с помощью c++ (или c++0x) и пытаюсь написать простое приложение, которое позволит обрабатывать такие данные (модель, подразделение и т. д.). Я ищу что — то вроде…

Бесплатный кросс-платформенный графический игровой движок 2D
Существуют ли C/C++ бесплатных кросс-платформенных 2D ориентированных графических игровых движков (для изометрической игры)? Я ожидаю от движка следующих функций: При создании окна OpenGL создание и…

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

Физический движок для sandy 3d
Я разрабатываю небольшую игру, чтобы выучить AS и Сэнди 3D. Я хочу включить физический движок в свою сцену 3D. Я хотел использовать WOW, как говорится в учебнике sandy, но веб-сайт WOW не работает,…

графический движок j2me 2d
Для J2ME я нашел несколько фреймворков GUI, таких как LWUIT, J2ME Polish, Twuik и т. д., Я ищу графический движок 2d для платформы Java ME, предпочтительно легкий < 50K, я наткнулся на TinyLine ,…

3D движок для моделирования вождения
Существует ли какой-либо графический и физический движок с открытым исходным кодом 3D, специализирующийся на моделировании вождения? Что-то вроде настраиваемого игрового движка, ориентированного на…

Android 2D графический игровой движок?
Я пытаюсь найти хороший графический движок 2D для игры… Что-то для игры вроде сверху вниз (небольшой угол, чтобы она выглядела 3D…), позволяющее пользователю передвигаться.. что-то вроде игры……

JavaFX 8 как 3D игровой движок?
Я хочу создать игру MMO 3D и ищу 3D-движок, и мой вопрос о javaFX 8 , могу ли я использовать его для рендеринга большого количества кубов 3D, моделей и анимации без потери производительности или…

Насколько сложно было бы сделать простой графический движок 3D в C++?
Я интересуюсь играми 3D и хотел бы узнать больше о том, как работает их графика. Я хочу попробовать сделать простой графический движок, в C++, для опыта. Как много мне нужно знать? Я…

Игровой движок графический движок движок против против
В чем разница между игровым движком, графическим движком и движком рендеринга? Игровой движок-это программный фреймворк для разработки видеоигр. Можем ли мы использовать игровой движок для создания…
• Игровой Движок — Написать Самому или Взять Готовый? « Геймдев: Основы Разработки Игр •
Это пятая статья из цикла материалов для начинающих разработчиков игр: Игровой движок — написать самому или взять готовый?
1. Создание игр для начинающих
2. Специальности в геймдеве
3. Создание команды разработчиков игр
4. Управление командой разработчиков игр
5. Игровой движок — написать самому или взять готовый?
6. Как выбрать игровой движок или конструктор игр
7. Создание MMORPG или любого крупного проекта — стоит ли? Показательный расчёт времени разработки
8. Создание Модов для Игр — Удачный Старт для Разработчика!
Одна из самых распространённых ошибок начинающих разработчиков — это желание во что бы то ни стало написать свой собственный игровой движок и уже на нём сделать игру. Не редкость, когда оба этих дела пытаются проводить параллельно, в итоге, естественно, успешно проваливая оба.
Почему не стоит писать свой игровой движок
В первую очередь необходимо ответить себе на один простой вопрос — что именно вы хотите сделать, игру или движок? Если движок, то забудьте про игру и занимайтесь только им. Если игру — возьмите готовый движок или конструктор и делайте игру, не отвлекаясь на разработку её программной части.
Создание полноценного игрового движка требует специальных знаний, понимания того, как работают игры, огромного количества свободного времени и желания писать исходный код. И уж поверьте — это отнюдь не весёлое занятие, как это может показаться. Даже в бесплатные готовые решения, доступные для использования, вложены тысячи человеко-часов программирования, не говоря уж о коммерческих движках, в которые помимо времени ещё были вложены и серьёзные финансы. Изобретать велосипед, когда вокруг каждый второй ездит на автомобиле — занятие неблагодарное и совершенно излишнее.
Помимо бесплатных систем разработки игр, многие коммерческие игровые движки, полностью готовые к немедленному началу использования в игровых проектах, предлагают сразу несколько очень привлекательных схем лицензирования: полностью бесплатную ( Unity 3D в бывшей Indie-редакции ), смешанную схему с выплатой Royalties ( Unreal Development Kit ) — 99 $ взнос за лицензию и выплаты 25 % прибыли после первых заработанных 5000 $, либо же доступную стоимость полновесной коммерческой лицензии ( Unity Pro за 1500 $ ).
Кроме того, никто не может запретить использовать бесплатную редакцию любого движка до определённой стадии готовности игры, чтобы потом с ощутимым и главное — наглядным результатом своих трудов начать поиски стороннего финансирования для перевода проекта на коммерческую лицензию.
Для 95 % игровых проектов любого жанра и направленности возможно найти адекватное их потребностям готовое решение. Времена, когда игровые движки были диковинкой для отечественного рынка разработки игр и стоили больших денег, прошли — а вместе с ними закончились аргументы в пользу написания собственного игрового движка.
Более того, желание непременно написать всё самостоятельно вкупе с иллюзией того, что такое решение будет лучшим продуктом, чем уже существующие аналоги, может сыграть очень злую шутку с начинающими разработчиками, когда и так весьма ограниченные ресурсы вкладываются в совершенно не нужную задачу ( личный опыт ), в итоге приводя к преждевременной смерти проекта.
Подводим итог: написанием собственного игрового движка могут заниматься те, кто чётко представляет, что именно и зачем ему это нужно, видит адекватные преимущества такого подхода и способен за вменяемые сроки претворить свой план в жизнь. Всем остальным следует поискать готовое решение, благо оных в последнее время появилось достаточно — взять хотя бы те же Unity 3D и UDK.
Читайте далее 6. Как выбрать игровой движок или конструктор игр
Свой игровой движок. Для обучения (С++, OpenGL) – CoreMission
Во время своего #shaderchallenge (заинтересовался как устроена красивая графика, какие визуальные эффекты можно делать шейдерами и тд,- и решил непременно изучить) я пришел к тому, что мне необходимо знать как устроены внутри игровые движки. И, конечно, нет способа лучше изучить устройство чем попробовать написать свой!

Так сказать позаколачивать знания в свою голову, наступая на разные грабли, изгугливая разные форумы, доски и тп.
В 2016ом я решил прокачаться в программировании графики и начал изучать программирование шейдеров. И как оказалось в этом деле никуда без математики, поэтому я хорошую часть этого года вспоминал, а по-большей части заново знакомился с линейной алгеброй и кое-каким мат. анализом.
С какими-то простыми эффектами я познакомился в Unity3d, я по роду своей деятельности программирую именно на этом движке. Делал скринэффекты, простой аутлайн и тп. Кстати, знание того, как устроен пайплайн и какие эффекты можно получить, развязывают руки и в некоторых ситуациях просто думаешь: — Ага, так можно вот шейдерочек написать.
Но, как я говорил выше, необходимы более глубокие знания. Пишу свой движок. Конечно на C++ и OpenGL. Не DirectX, потому, что мне казалось, что на консолях именно OpenGL, но это не так.
Все говорят, что OpenGL и DirectX очень похожи, а я понимаю, что главное это понимать концепции и подходы, а фреймворк освоить можно быстро. Поэтому перескакивать на DirectX я не стал.
Про графическую библиотеку пояснил. Теперь про язык. Я очень доволен выбором именно C++, какой он крутой, ребята! Сколько всего я о нем не знал! Сколько добавилось в новых стандартах и сколько еще предстоит изучить!
Итак, встречайте, первое более-менее презентабельное демо, в моей собственном игровом движке Rudy Engine.
Первое демо
Реализовано: cubemap/skybox, загрузка моделей через assimp, half-lambert для освещения, overlay-рендерер для прицела и маркера-указателя на космическую станцию.

(очень дрожит видео, не стал искать какую-то хорошую программу для записи, воспользовался monosnap, наверное он не очень для этого подходит)
Дальнейшие планы
В дальнейшем я хочу сделать туман, shadow-mapping, и какие-то эффекты для этой демки и, возможно, переключиться на какую-то следующую. В целом, стараюсь придерживаться взрослой и мучительной разработки: дорабатывать движок таким образом, чтобы старые демо оставались рабочими. Подрихтовываю и подлатываю его. Для чего? Нужно понять этот trade-off как у Unity, чего стоит сделать универсальный инструмент?
Update 2017
Летом в 2017ом году, у меня закончился испытательный срок в крупной игровой студии и я написал в блоге, как я пересел с Unity на C++, вся вот эта практика с игровым движком, мне очень помогла!
Как написать свой движок блога, часть 1.
Вступление.
Собственный движок блога обладает многими преимуществами. В нем можно поменять вообще все, до мелочей и уйдет на это в 10 раз меньше времени, чем ковыряться в чужих движках, таких как WordPress или DLE (DLE особенно страшен в этом плане на мой взгляд). Для него легко поставить собственный дизайн. К нему легко прикрутить собственные другие наработки, например, портал, каталог статей и прочее.
Большим плюсом номер два я считаю невозможность взлома собственного движка. Ведь для взлома уникального, нигде больше не установленного движка хакеру придется поломать голову. А вот для стандартных движков обычно делают даже так называемые эксплойты – скрипт, запустив который, даже безмозглый 12летний идиот может получить пароли от админки Вашего блога.
Да, это палка о двух концах – если плохо написать движок с точки зрения безопасности, ломаться он будет довольно легко. Но я лично не собираюсь писать его плохо 😉 А Вы?
Еще плюсы? Например, скорость работы. Тот же огромный и «тяжелый» WordPress будет работать в разы медленнее, чем заточенный под конкретные задачи собственный движок.
Я расскажу, как написать свой движок за пару часов. А если копировать код у меня из статьи – за 15 минут. А если сразу скачать исходник – за 30 секунд 🙂
(тут поясню: у меня блог на стандартном движке, т.к. я его веду уже больше полугода и мне не хочется возиться с переносом статей на собственный движок; жаль, что я не начал вести блог на своем движке с самого начала)
Недостатки есть?
Есть, не без этого. Главным недостатком своего движка и огромным плюсом для стандартных движков я считаю плагины. То есть для собственного движка их просто нет и быть не может, пока автор движка сам их не напишет. Например, в WordPress можно за 1 минуту установить плагин для вывода последних комментариев, вывода смайликов, голосования (и вообще чего угодно), а в своем блоге придется писать это все самому. И если вывод последних комментариев и смайликов – задача не сложная, то, например, с голосованием уже посложнее.
Зачем Вам все это?
В любом случае, даже если Вы выбираете стандартный движок, я все равно рекомендую прочитать статью – особенно начинающим программистам. Эта статья фактически описание создания несложной CMS, которую можно превратить из блога во что угодно 😉
И еще момент. После этого небольшого цикла статей я напишу, как сделать генератор сателлитов! И по плану – там как раз пригодится этот собственный движок 😉 Запахло деньгами?
Составляем ТЗ.
(ТЗ – Техническое Задание, документ, по которому программист пишет программу, скрипт, сайт и т.п.)
Даже в таком несложном деле лучше составить небольшое ТЗ и не отходить от него в процессе разработки. Мы просто опишем, что хотим видеть в движке, а потом сделаем ровно так, как написали. Я считаю, что это полезная практика – иначе можно «расплыться» (захотеть сделать и то и се и пятое и десятое, в итоге не сделать ничего или сделать частично и плохо).
«Нужны возможности: 2* добавлять категории, редактировать их названия, вывод категорий по алфавиту, вложенность не нужна. Добавлять, редактировать или удалять посты. В посте есть заголовок и основной текст. Визуальный редактор не нужен, разрешить HTML-теги. 3* Возможность комментировать пост, вводя имя, почту, сайт и комментарий. Регистрация пользователей не нужна. Все адреса в виде ЧПУ (человеку понятный URL, а-ля dimoning.ru/hello.html). Категории открываются по адресам /category/catname/, где catname – имя категории. Посты открываются по адресам /postname.html, где postname – адес поста. Эти адреса тоже можно редактировать. *4 Прикрутить RSS последней версии протокола. Весь блог в кодировке UTF-8. Все изменения администратор вводит через админку по адресу /vrotmnenogi-admin/. Добавить постраничный вывод постов.»
Вот такое тех-задание. Сделаем четко по нему 😉
Я решил разделить создание собственного движка блога на четыре части – первая – это проектирование и еще три отмечены звездочками в ТЗ [сначала хотел 3 части, но эта статья уже вышла довольно большой, а для понимания читать большую статью, я думаю, тяжеловато]. У меня еще нет готового движка (на момент написания этих строк), поэтому исходник каждый раз будет все более дополняться.
Начнем с начала.
В начале работы я обычно прикидываю, какие мне нужны таблицы в базе данных и как их будет использовать движок. Например, здесь. Я перечислю поля и тип данных в них записываемый, а также объясню – для чего то или иное поле. Для простоты мы будем использовать только int и text.
Категории:
id (int auto increment) | url (text) | title (text)
id – уникальный, автоматически увеличивающийся при добавлении записи, идентификатор категории
url – адрес категории, который будет подставляться /category/сюда/
title – название категории, которое будет выводиться в браузер
Посты:
id (int auto increment) | url (text) | title (text) | post (text) | dt (datetime)
id – уникальный, автоматически увеличивающийся при добавлении записи, идентификатор поста
url – адрес поста, который будет подставляться /сюда.html
title – заголовок поста, выводится в браузер
post – содержимое поста, выводится туда же
dt – дата и время написания поста, проставляется автоматически и изменению не подлежит
Комментарии к постам:
id (int auto increment) | post_id (int) | nick (text) | email (text) | site (text) | comment (text) | ip (text) | dt (datetime)
В ТЗ ничего не сказано про запись IP комментатора, но я считаю, что это необходимо. Может помочь отловить злого спамера или забанить по IP. В общем, если «враг» появится, лучше знать про него как можно больше.
id – уникальный, автоматически увеличивающийся при добавлении записи, идентификатор комментария
post_id – идентификатор поста, к которому написан комментарий
nick – имя комментатора (никнейм)
email – почта комментатора
site – сайт комментатора
comment – сам комментарий
ip – IP-адрес комментатора
dt – дата и время написания комментария. Так. Для протокола. 🙂
Знатоки из Что-Где-Когда, конечно, заметили бы, что IP адрес можно хранить в виде long-числа, а я храню его в виде текста. Я считаю, что так нагляднее и вообще редко храню его в виде числа. Говорят, что по использованию памяти это лучше, не знаю, я не замерял. Но знаю, что это хуже по производительности – нужно преобразовывать число в IP и обратно. Я так не делаю, в общем.
С базой данных все. Теперь пара слов о ЧПУ.
Из ТЗ видно, что должны быть ЧПУ (человеку понятный Url). Для этого нам нужно создать .htaccess, который мог бы разбирать адреса вида /category/name/ и /post.html и передавать в скрипт значения этих полей в виде переменных. Например, пусть имя категории передается в переменной category, а имя поста в переменной post из массива $_GET.
Заметьте, нужно предусмотреть и постраничный вывод! Лучше подумать об этом сразу. Я предлагаю сделать примерно так же, как сделано в WordPress. А именно, для категорий страницы показываются по адресу /category/name/page/1/, где 1 – номер страницы./(page)/([0-9+])/$ index.php?page=$2 [L]
Я пронумеровал строки. В рабочей версии нумерации, конечно, нет.
Строка 1. Перекидывает с rss.html на rss.php прозрачно для пользователя. В rss.php будет генерироваться сама RSS.
Строка 2. При открытии адреса вида /some.html передает все между слешем и .html в скрипт index.php в переменной $_GET[‘post’];
Строка 3. При открытии категорий (адрес вида /category/имя/) передает в скрипт index.php имя категории в перменной $_GET[‘category’];
Строка 4 и строка 5 – аналогичное действие, только для других видов URL.
Ключ L не позволяет серверу идти дальше по списку, если нужное нам совпадение с адресом найдено.
Между прочим, здесь есть еще один большой плюс: с помощью регулярных выражений мы задали конкретные символы, которые можно использовать в адресах. Если хакер попытается ввести в адрес не буквенно-цифровой символ, то сервер прервет запрос сразу же. То есть заботиться об этом в самом движке уже не надо.
На этом с «проектированием» покончено, ровно как и с первой частью. В следующей статье мы сделаем добавление категорий, их редактирование, вывод. Добавление постов, их редактирование и отображение.
Пока что все. Всем удачи и до связи 🙂 Подписывайтесь на RSS, а то что за дела ))) Я еще не набрал даже сотни подписчиков, жуть! ))
Топ-9 JS-движков и библиотек для игр в 2020 году — Разработка на vc.ru
{«id»:131649,»url»:»https:\/\/vc.ru\/dev\/131649-top-9-js-dvizhkov-i-bibliotek-dlya-igr-v-2020-godu»,»title»:»\u0422\u043e\u043f-9 JS-\u0434\u0432\u0438\u0436\u043a\u043e\u0432 \u0438 \u0431\u0438\u0431\u043b\u0438\u043e\u0442\u0435\u043a \u0434\u043b\u044f \u0438\u0433\u0440 \u0432 2020 \u0433\u043e\u0434\u0443″,»services»:{«facebook»:{«url»:»https:\/\/www.facebook.com\/sharer\/sharer.php?u=https:\/\/vc.ru\/dev\/131649-top-9-js-dvizhkov-i-bibliotek-dlya-igr-v-2020-godu»,»short_name»:»FB»,»title»:»Facebook»,»width»:600,»height»:450},»vkontakte»:{«url»:»https:\/\/vk.com\/share.php?url=https:\/\/vc.ru\/dev\/131649-top-9-js-dvizhkov-i-bibliotek-dlya-igr-v-2020-godu&title=\u0422\u043e\u043f-9 JS-\u0434\u0432\u0438\u0436\u043a\u043e\u0432 \u0438 \u0431\u0438\u0431\u043b\u0438\u043e\u0442\u0435\u043a \u0434\u043b\u044f \u0438\u0433\u0440 \u0432 2020 \u0433\u043e\u0434\u0443″,»short_name»:»VK»,»title»:»\u0412\u041a\u043e\u043d\u0442\u0430\u043a\u0442\u0435″,»width»:600,»height»:450},»twitter»:{«url»:»https:\/\/twitter.com\/intent\/tweet?url=https:\/\/vc.ru\/dev\/131649-top-9-js-dvizhkov-i-bibliotek-dlya-igr-v-2020-godu&text=\u0422\u043e\u043f-9 JS-\u0434\u0432\u0438\u0436\u043a\u043e\u0432 \u0438 \u0431\u0438\u0431\u043b\u0438\u043e\u0442\u0435\u043a \u0434\u043b\u044f \u0438\u0433\u0440 \u0432 2020 \u0433\u043e\u0434\u0443″,»short_name»:»TW»,»title»:»Twitter»,»width»:600,»height»:450},»telegram»:{«url»:»tg:\/\/msg_url?url=https:\/\/vc.ru\/dev\/131649-top-9-js-dvizhkov-i-bibliotek-dlya-igr-v-2020-godu&text=\u0422\u043e\u043f-9 JS-\u0434\u0432\u0438\u0436\u043a\u043e\u0432 \u0438 \u0431\u0438\u0431\u043b\u0438\u043e\u0442\u0435\u043a \u0434\u043b\u044f \u0438\u0433\u0440 \u0432 2020 \u0433\u043e\u0434\u0443″,»short_name»:»TG»,»title»:»Telegram»,»width»:600,»height»:450},»odnoklassniki»:{«url»:»http:\/\/connect.ok.ru\/dk?st.cmd=WidgetSharePreview&service=odnoklassniki&st.shareUrl=https:\/\/vc.ru\/dev\/131649-top-9-js-dvizhkov-i-bibliotek-dlya-igr-v-2020-godu»,»short_name»:»OK»,»title»:»\u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0438″,»width»:600,»height»:450},»email»:{«url»:»mailto:?subject=\u0422\u043e\u043f-9 JS-\u0434\u0432\u0438\u0436\u043a\u043e\u0432 \u0438 \u0431\u0438\u0431\u043b\u0438\u043e\u0442\u0435\u043a \u0434\u043b\u044f \u0438\u0433\u0440 \u0432 2020 \u0433\u043e\u0434\u0443&body=https:\/\/vc.ru\/dev\/131649-top-9-js-dvizhkov-i-bibliotek-dlya-igr-v-2020-godu»,»short_name»:»Email»,»title»:»\u041e\u0442\u043f\u0440\u0430\u0432\u0438\u0442\u044c \u043d\u0430 \u043f\u043e\u0447\u0442\u0443″,»width»:600,»height»:450}},»isFavorited»:false}
8489 просмотров
Хотя топ-компании из сферы разработки компьютерных игр не используют JavaScript в качестве одного из основных языков, сама идея использовать его для геймдева не такая уж безумная. На самом деле, в последние несколько лет браузеры и мобильные устройства стали включать в себя такие функции, как WebGL, чтобы расширить возможности графики.
Поскольку производители браузеров делают их доступными для разработчиков через API JS, мы можем создавать продвинутые игровые возможности прямо здесь, в вашем браузере.
Итак, в этой статье вы найдете список игровых библиотек для каждого разработчика JS, желающего заняться разработкой игр, по крайней мере, в качестве хобби.
Выбор лучшей библиотеки или движка полностью зависит от вас. Вы — единственный, кто знает, какую игру хотите создать, и какой у вас уровень понимания внутренней архитектуры игры. Выбирайте те инструменты, которые выглядят наиболее подходящими для ваших потребностей и вашего уровня.
Итак, поехали!
GDevelop предоставляет отличный набор инструментов для любых пользователей — от новичков до продвинутых.
Судя по рекламным заявлениям, платформа позволяет создать игру любого типа, однако, этот игровой движок в первую очередь нацелен на создание 2D-игр, таких как платформеры, шутеры и обычные 8-битные игры.
В качестве дополнительного бонуса GDevelop дает возможность экспорта в различные платформы, такие как Android, iOS, Facebook Instant Games и другие.
Кому подходит. Вариант для тех, кто заинтересован в создании работающих игр, которые можно экспортировать и продвигать в различных платформах, но не хочет углубляться в вопросы геймдева, например, разбираться в низкоуровневой архитектуре игрового движка.
Еще один игровой движок для 2D-игр. Подключая эту библиотеку к своему коду, вы получаете доступ ко всем фичам, таким как поддержка физики, столкновения, спрайты и другие, важные в действительно стоящих играх.
Хотя документация может быть не самой лучшей из имеющихся, вокруг продукта создано много юзер-контента, помогающего понять, что вам делать. Я, конечно, тоже внес свой вклад в это, написав такие статьи (на англ. — прим. переводчика):
Кому подходит. Эта библиотека очень дружелюбна к новичкам, но в то же время очень мощная. Хороший выбор, если вы думаете о создании 2D-игры и геймдев для вас в новинку.
ImpactJS — игровой движок JavaScript, в основном ориентированный на разработку 2D-игр, как и библиотеки выше. Но есть плагины, которые вы можете добавить в Impact для имитации 3D-среды, например как здесь:
Интересно отметить: Impact поставляется с несколькими дополнительными инструментами, такими как редактор уровней для любой 2D-игры, мощный дебаггер, а также очень интересный фреймворк для публикаций Ejecta, позволяющий размещать игры в iPhone App Store.
Невероятно мощный движок веб-рендеринга. Это не игровой движок или игровая библиотека, но вы можете создавать игры на его основе. Поскольку это движок рендеринга, а не библиотека для игр, у вас будет доступ к низкоуровневому функционалу, в частности связанному с визуализацией.
Кому подходит: Вы сначала строите свой движок, а потом уже игру, поэтому у вас есть контроль над тем, что и как происходит. Это здорово для продвинутых создателей игр, но если вы не из них, разработка с помощью BabylonJS может быть контрпродуктивной. Посмотрите на этот пример — он выглядит изумительно. Но взгляните на счетчик линий кода слева — более 1000 строк всего лишь для демки:
Возможно, это ничего, если учесть, сколько кода содержится в топовых играх в наши дни. Если думаете, что будет желание и время писать такой код, то это прекрасный бесплатный инструмент для получения потрясающих результатов. В противном случае держитесь от него подальше.
Это крутой игровой движок, созданный сообществом и готовый для всех ваших десктопных и мобильных задумок. Он поддерживает как WebGL, так и Canvas для устройств, не поддерживающих WebGL, ориентирован на разработку 2D-игр.
Интересно отметить: сам фреймворк является бесплатным и поставляется со всем нужным для создания игр, кроме того, существуют плагины, которые можно добавить к нему, чтобы получить улучшенные или дополнительные функции. Однако такие плагины не бесплатны.
PixiJS — удивительно гибкая и мощная библиотека для 2D-визуализации. Она работает с WebGL и предназначена для создания красивых веб-интерфейсов, которые необязательно должны становиться играми. Хотя библиотека поддерживает ряд игровых элементов, такие как спрайты, текст и даже некоторые продвинутые, например шейдеры.
При этом вам нужно создать свой собственный физический движок, придется позаботиться об обнаружении столкновений и другой игровой механике, например — о проверке правильности построения игрового цикла.
Кому подходит. Это хороший вариант, если вы не создаете сложную игру и вас больше беспокоят визуальные аспекты, нежели более сложные игровые механики.
Среда для разработки игр, которая целиком находится в вебе. Это означает, что вы используете ее как платформу для написания кода, тестирования, настройки своих сцен (у них сумасшедший подробный 3D-интерфейс на WebGL) и даже для экспорта игр в один клик.
Как и некоторые другие варианты, которые я рассматриваю в этом списке, PlayCanvas полностью совместим и готов к созданию VR-приложений, что, похоже, растущий тренд в области разработки игр.
Интересно отметить: небольшой недостаток PlayCanvas — он не полностью бесплатный. Вы, естественно, можете использовать его на некотором бесплатном уровне и делать там публичные проекты, но забудьте о том, чтобы держать их в секрете или даже убрать их экран загрузки, пока вы не начали платить ежемесячную плату.
У некоторых из предыдущих вариантов есть совместимость с VR в качестве дополнительного функционала. А вот A-Frame был создан именно с учетом VR и AR. Это означает, что фокус всего фреймворка смещен.
Конечно, можно создавать на нем и 3D-игры, но максимальную пользу можно извлечь, если использовать WebXR-совместимые браузеры или даже экспериментальные фичи в последних версиях Chrome, обеспечивающие поддержку WebXR AR.
Поскольку A-Frame был разработан для использования в браузере, он имеет синтаксис, похожий на синтаксис HTML-верстки. Поэтому вместо того, чтобы сильно полагаться на JavaScript, он использует некоторые пользовательские элементы разметки, как видно здесь:
Кому подходит. Этот фреймворк — отличный вариант, если вы заинтересованы в опыте с VR/AR вместо старых добрых 3D-игр. Поскольку A-Frame специально разработан для этого, он сделает вашу жизнь намного проще. Попробуйте!
Наконец, в качестве последнего варианта я хочу рассказать не о графически-ориентированном движке, а о чем-то другом. PhysicsJS, как видно из названия, фокусируется на физическом аспекте взаимодействия объектов. Вы можете использовать эту библиотеку для разработки игр или любого другого типа моделирования, которое вы захотите создать.
Как видно на демо-странице, эта библиотека готова к реализации некоторых интересных взаимодействий. Как написано в документации, вы можете использовать различные типы средств визуализации в зависимости от того, что вам нужно.
Вы даже можете использовать PixiJS для рендеринга или создать собственный инструмент, если хотите интегрировать его с другими библиотеками из тех, о которых я говорил выше.
Эта библиотека может быть немного устаревшей, однако, законы физики совсем не поменялись, поэтому эффекты, которых можно достичь с помощью PhysicsJS, очень натуральны.
Кому подходит. В общем — хорошее решение, если вы хотите добавить сложную физику в свою игру или пытаетесь создать собственный движок, используя различные библиотеки, например, PixiJS и другие. PhysicsJS поможет автоматически разрешать все типы взаимодействий 2D-физики, которые только понадобятся.
Конечно, это не все движки и библиотеки для игр
Это далеко не полный список возможных вариантов. Если вы использовали другие библиотеки или фреймворки для разработки игр, поделитесь ссылками в комментариях. 🙂
Что еще почитать по теме:
Как написать свой собственный игровой движок на C ++
В последнее время я писал игровой движок на C ++. Я использую его, чтобы сделать небольшую мобильную игру под названием Hop Out . Вот клип, сделанный с моего iPhone 6. (Включите звук!)
Hop Out — это игра, в которую я хочу играть: ретро-аркадный геймплей с трехмерным мультяшным дизайном. Цель состоит в том, чтобы изменить цвет каждой панели, как в Q * Bert.
Hop Out все еще находится в разработке, но движок, на котором он работает, начинает становиться достаточно зрелым, поэтому я подумал, что могу поделиться здесь несколькими советами по разработке движка.
Зачем вам писать игровой движок? Возможных причин много:
Вы мастерица. Вы любите строить системы с нуля и видеть, как они оживают.
Вы хотите узнать больше о разработке игр. Я проработал 14 лет в игровой индустрии и все еще разбираюсь в этом. Я даже не был уверен, что смогу написать движок с нуля, поскольку это сильно отличается от повседневных обязанностей программиста в большой студии. Я хотел узнать.
Тебе нравится контроль. Приятно организовывать код именно так, как вы хотите, всегда зная, где что находится.
Вы чувствуете себя вдохновленными классическими игровыми движками, такими как AGI (1984), id Tech 1 (1993), Build (1995), и такими гигантами индустрии, как Unity и Unreal.
Вы считаете, что мы, игровая индустрия, должны попытаться демистифицировать процесс разработки движка. Не то чтобы мы овладели искусством создания игр. Отнюдь не! Чем больше мы исследуем этот процесс, тем больше у нас шансов улучшить его.
Игровые платформы 2017 года — мобильные, консольные и ПК — очень мощные и во многих отношениях очень похожи друг на друга. Разработка игрового движка — это не столько борьба со слабым и экзотическим оборудованием, как это было в прошлом. На мой взгляд, это больше о борьбе со сложностью , которую вы сами создаете, создавая . Создать монстра несложно! Вот почему советы в этом посте сосредоточены на том, чтобы все было управляемым. Я разбил его на три части:
Использовать итерационный подход
Подумайте дважды, прежде чем слишком много объединять
Имейте в виду, что сериализация — важная тема
Этот совет применим к любому игровому движку.Я не собираюсь рассказывать вам, как написать шейдер, что такое октодерево или как добавить физику. Я полагаю, вы уже знаете о таких вещах, и это во многом зависит от типа игры, которую вы хотите создать. Вместо этого я сознательно выбрал моменты, которые, кажется, не получили широкого признания или обсуждения — именно такие моменты я нахожу наиболее интересными, когда пытаюсь демистифицировать предмет.
Итерационный подход
Мой первый совет — быстро запустить что-нибудь (что угодно!), А затем повторить.
Если возможно, начните с примера приложения, которое инициализирует устройство и рисует что-нибудь на экране. В моем случае я загрузил SDL, открыл Xcode-iOS / Test / TestiPhoneOS.xcodeproj , затем запустил образец testgles2 на моем iPhone.
Вуаля! У меня был прекрасный вращающийся куб, использующий OpenGL ES 2.0.
Следующим шагом было скачать 3D-модель Марио, которую кто-то сделал. Я написал быстрый и грязный загрузчик файлов OBJ — формат файла не такой уж и сложный — и взломал пример приложения, чтобы визуализировать Марио вместо куба.Я также интегрировал SDL_Image для загрузки текстур.
Затем я реализовал управление двумя джойстиками, чтобы перемещать Марио. (Вначале я подумывал о создании шутера с двумя джойстиками. Но не с Марио.)
Затем я хотел исследовать скелетную анимацию, поэтому я открыл Blender, смоделировал щупальце и оснастил его скелетом из двух костей, который покачивался взад и вперед.
На этом этапе я отказался от формата файла OBJ и написал сценарий Python для экспорта пользовательских файлов JSON из Blender.Эти файлы JSON описывают данные сетки, скелета и анимации со скелетом. Эти файлы я загрузил в игру с помощью библиотеки C ++ JSON.
Как только это сработало, я вернулся в Blender и сделал персонажа более сложным. (Это был первый сфальсифицированный трехмерный человек, которого я когда-либо создавал. Я очень им гордился.)
В течение следующих нескольких месяцев я предпринял следующие шаги:
Начал перенос векторных и матричных функций в мою собственную трехмерную математическую библиотеку.
Заменен файл .xcodeproj на проект CMake.
Движок работает как на Windows, так и на iOS, потому что мне нравится работать в Visual Studio.
Начал перенос кода в отдельные библиотеки «движок» и «игру». Со временем я разделил их на еще более детализированные библиотеки.
Написал отдельное приложение для преобразования моих файлов JSON в двоичные данные, которые игра может загружать напрямую.
В конце концов удалил все библиотеки SDL из сборки iOS.(Сборка Windows по-прежнему использует SDL.)
Дело в том, что Я не планировал архитектуру движка до того, как начал программировать . Это был осознанный выбор. Вместо этого я просто написал простейший код, реализующий следующую функцию, а затем посмотрел на код, чтобы увидеть, какая архитектура возникла естественным образом. Под «архитектурой движка» я имею в виду набор модулей, составляющих движок игры, зависимости между этими модулями и API для взаимодействия с каждым модулем.
Это итеративный подход, поскольку он ориентирован на меньшие результаты. Это хорошо работает при написании игрового движка, потому что на каждом этапе у вас есть запущенная программа. Если что-то пойдет не так, когда вы вводите код в новый модуль, вы всегда можете сравнить свои изменения с кодом, который работал ранее. Очевидно, я предполагаю, что вы используете какую-то систему контроля версий.
Вы можете подумать, что такой подход тратится впустую, поскольку вы всегда пишете плохой код, который нужно исправить позже.Но большая часть очистки включает перемещение кода из одного файла .cpp в другой, извлечение объявлений функций в файлы .h или столь же простые изменения. Решить , куда деваться , — сложная часть, и это легче сделать, когда код уже существует.
Я бы сказал, что больше времени тратится впустую в противоположном подходе: слишком усердно пытаться придумать архитектуру, которая сделает все, что, как вы думаете, вам нужно, заранее. Две из моих любимых статей об опасностях чрезмерной инженерии — это «Порочный круг обобщения» Томаша Домбровски и «Не позволяйте архитектурным астронавтам пугать вас» Джоэла Спольски.
Я не говорю, что никогда не следует решать проблему на бумаге, прежде чем решать ее в коде. Я также не говорю, что вам не следует заранее решать, какие функции вам нужны. Например, я с самого начала знал, что хочу, чтобы мой движок загружал все ресурсы в фоновом потоке. Я просто не пытался спроектировать или реализовать эту функцию, пока мой движок не загрузил сначала некоторые ресурсы.
Итеративный подход дал мне гораздо более элегантную архитектуру, чем я когда-либо мог представить, глядя на чистый лист бумаги.Сборка моего движка для iOS теперь представляет собой 100% исходный код, включая настраиваемую математическую библиотеку, шаблоны контейнеров, систему отражения / сериализации, структуру рендеринга, физику и аудиомикшер. У меня были причины для написания каждого из этих модулей, но вы, возможно, не сочтете необходимым писать все это самостоятельно. Существует множество отличных библиотек с открытым исходным кодом с разрешительной лицензией, которые вы можете найти подходящими для своего движка. GLM, Bullet Physics и заголовки STB — лишь несколько интересных примеров.
Подумайте дважды, прежде чем объединять слишком много вещей
Как программисты, мы стараемся избегать дублирования кода, и нам нравится, когда наш код следует единому стилю. Однако я думаю, что хорошо не позволять этим инстинктам преобладать над каждым решением.
Время от времени не поддавайтесь принципу СУХОСТИ
В качестве примера, мой движок содержит несколько классов шаблонов «умных указателей», по духу схожих с std :: shared_ptr . Каждый из них помогает предотвратить утечку памяти, служа оболочкой для необработанного указателя.
Владелец <> предназначен для динамически выделяемых объектов, имеющих одного владельца.
Ссылка <> использует подсчет ссылок, чтобы позволить объекту иметь несколько владельцев.
audio :: AppOwned <> используется кодом вне аудиомикшера. Он позволяет игровым системам владеть объектами, которые использует аудиомикшер, например голосом, который воспроизводится в данный момент.
audio :: AudioHandle <> использует внутреннюю систему подсчета ссылок для аудиомикшера.
Может показаться, что некоторые из этих классов дублируют функциональность других в нарушение принципа DRY (Don’t Repeat Yourself). В самом деле, на ранних этапах разработки я пытался как можно больше повторно использовать существующий класс Reference <> . Однако я обнаружил, что время жизни аудиообъекта регулируется особыми правилами: если звуковой голос закончил воспроизведение сэмпла, а игра не содержит указателя на этот голос, голос может быть немедленно поставлен в очередь для удаления.Если в игре есть указатель, то голосовой объект не следует удалять. И если игра содержит указатель, но владелец указателя уничтожается до того, как голос закончился, голос должен быть отменен. Вместо того, чтобы усложнять Reference <> , я решил, что будет более практичным вместо этого ввести отдельные классы шаблонов.
В 95% случаев можно использовать повторно существующий код. Но если вы начинаете чувствовать себя парализованным или обнаруживаете, что усложняете что-то, что когда-то было простым, спросите себя, должно ли что-то в кодовой базе действительно состоять из двух вещей.
Можно использовать разные соглашения о вызовах
В Java мне не нравится то, что она заставляет вас определять каждую функцию внутри класса. По-моему, это чушь. Это может сделать ваш код более последовательным, но также поощряет чрезмерную инженерию и плохо поддается итерационному подходу, который я описал ранее.
В моем движке C ++ некоторые функции принадлежат классам, а некоторые нет. Например, каждый противник в игре — это класс, и большая часть поведения врага реализуется внутри этого класса, как и следовало ожидать.С другой стороны, приведение сфер в моем движке выполняется путем вызова SphereCast () , функции в пространстве имен Physics . SphereCast () не принадлежит ни к какому классу — это просто часть модуля Physics . У меня есть система сборки, которая управляет зависимостями между модулями, что позволяет мне организовать код достаточно хорошо. Обертывание этой функции внутри произвольного класса не улучшит организацию кода каким-либо значимым образом.
Затем есть динамическая отправка, которая является формой полиморфизма.Нам часто требуется вызвать функцию для объекта, не зная точного типа этого объекта. Первым инстинктом программиста на C ++ является определение абстрактного базового класса с виртуальными функциями, а затем переопределение этих функций в производном классе. Это верно, но это всего лишь одна из техник. Существуют и другие методы динамической диспетчеризации, которые не вводят столько дополнительного кода или приносят другие преимущества:
C ++ 11 представил std :: function , который является удобным способом хранения функций обратного вызова.Также можно написать свою собственную версию std :: function , в которую будет проще войти в отладчик.
Многие функции обратного вызова могут быть реализованы с помощью пары указателей: указателя функции и непрозрачного аргумента. Для этого просто требуется явное приведение внутри функции обратного вызова. Вы часто видите это в чистых библиотеках C.
Иногда базовый тип действительно известен во время компиляции, и вы можете привязать вызов функции без каких-либо дополнительных затрат времени выполнения.Turf, библиотека, которую я использую в своем игровом движке, во многом полагается на эту технику. См., Например, turf :: Mutex . Это просто typedef над классом, зависящим от платформы.
Иногда самый простой подход — это создать и поддерживать таблицу необработанных указателей на функции самостоятельно. Я использовал этот подход в своем аудиомикшере и системе сериализации. Интерпретатор Python также активно использует эту технику, как упоминается ниже.
Вы даже можете хранить указатели на функции в хэш-таблице, используя имена функций в качестве ключей.Я использую эту технику для отправки событий ввода, таких как события мультитач. Это часть стратегии, чтобы записывать игровые данные и воспроизводить их с помощью системы воспроизведения.
Динамическая отправка — большая тема. Я лишь поверхностно хочу показать, что есть много способов добиться этого. Чем больше вы пишете расширяемый низкоуровневый код, что является обычным явлением в игровом движке, тем больше вы обнаружите, что исследуете альтернативы. Если вы не привыкли к такому программированию, интерпретатор Python, написанный на C, станет отличным ресурсом для обучения.Он реализует мощную объектную модель: каждый PyObject указывает на PyTypeObject , а каждый PyTypeObject содержит таблицу указателей функций для динамической диспетчеризации. Документ «Определение новых типов» — хорошая отправная точка, если вы хотите сразу приступить к делу.
Помните, что сериализация — важная тема
Сериализация — это процесс преобразования объектов среды выполнения в последовательность байтов и обратно. Другими словами, сохранение и загрузка данных.
Для многих, если не большинства игровых движков, игровой контент создается в различных редактируемых форматах, таких как .png , .json , .blend или проприетарных форматах, а затем в конечном итоге конвертируется в игровые форматы, зависящие от платформы, которые движок может загружается быстро. Последнее приложение в этом конвейере часто называют «плита». Плита может быть интегрирована в другой инструмент или даже распределена по нескольким машинам. Обычно Cooker и ряд инструментов разрабатываются и обслуживаются в тандеме с самим игровым движком.
При настройке такого конвейера выбор формата файла на каждом этапе остается за вами. Вы можете определить некоторые собственные форматы файлов, и эти форматы могут развиваться по мере добавления функций движка. По мере их развития вам может потребоваться поддерживать совместимость определенных программ с ранее сохраненными файлами. Независимо от формата, вам в конечном итоге потребуется сериализовать его на C ++.
Существует бесчисленное множество способов реализовать сериализацию в C ++. Один довольно очевидный способ — добавить функции load и save к классам C ++, которые вы хотите сериализовать.Вы можете достичь обратной совместимости, сохранив номер версии в заголовке файла, а затем передав этот номер в каждую функцию загрузки . Это работает, хотя код может стать громоздким в обслуживании.
void load (InStream & in, u32 fileVersion) { in >> m_position; в >> m_direction; if (fileVersion> = 2) { в >> m_velocity; } }
Можно написать более гибкий, менее подверженный ошибкам код сериализации, используя преимущества отражения, в частности, создавая данные времени выполнения, которые описывают структуру ваших типов C ++.Чтобы быстро понять, как отражение может помочь в сериализации, взгляните на то, как это делает Blender, проект с открытым исходным кодом.
Когда вы собираете Blender из исходного кода, происходит много шагов. Сначала компилируется и запускается специальная утилита с именем madedna . Эта утилита анализирует набор файлов заголовков C в дереве исходных текстов Blender, а затем выводит краткую сводку всех типов C, определенных внутри, в настраиваемом формате, известном как SDNA. Эти данные SDNA служат в качестве данных отражения .Затем SDNA связывается с самим Blender и сохраняется с каждым файлом .blend , который записывает Blender. С этого момента всякий раз, когда Blender загружает файл .blend , он сравнивает SDNA файла .blend с SDNA, связанной с текущей версией во время выполнения, и использует общий код сериализации для обработки любых различий. Эта стратегия дает Blender впечатляющую степень обратной и прямой совместимости. Вы по-прежнему можете загружать файлы 1.0 в последней версии Blender и новой версии .blend файлы могут быть загружены в более старых версиях.
Как и Blender, многие игровые движки и связанные с ними инструменты генерируют и используют свои собственные данные отражения. Есть много способов сделать это: вы можете проанализировать свой собственный исходный код C / C ++ для извлечения информации о типе, как это делает Blender. Вы можете создать отдельный язык описания данных и написать инструмент для генерации определений типов C ++ и данных отражения на этом языке. Вы можете использовать макросы препроцессора и шаблоны C ++ для создания данных отражения во время выполнения.И как только у вас есть данные отражения, есть бесчисленное множество способов написать на их основе универсальный сериализатор.
Ясно, что я опускаю много деталей. В этом посте я только хочу показать, что существует множество различных способов сериализации данных, некоторые из которых очень сложны. Программисты просто не обсуждают сериализацию так много, как другие системы движка, хотя большинство других систем полагаются на нее. Например, из 96 выступлений по программированию, представленных на GDC 2017, я насчитал 31 доклад о графике, 11 — об онлайн, 10 — об инструментах, 4 — об ИИ, 3 — о физике, 2 — об аудио, но только один, который касался непосредственно сериализации.
Как минимум, постарайтесь представить себе, насколько сложными будут ваши потребности. Если вы делаете крошечную игру, такую как Flappy Bird, всего с несколькими активами, вам, вероятно, не нужно слишком много думать о сериализации. Вы, вероятно, можете загружать текстуры прямо из PNG, и все будет хорошо. Если вам нужен компактный двоичный формат с обратной совместимостью, но вы не хотите разрабатывать свой собственный, обратите внимание на сторонние библиотеки, такие как Cereal или Boost.Serialization. Я не думаю, что буферы протокола Google идеально подходят для сериализации игровых ресурсов, но тем не менее их стоит изучить.
Написать игровой движок, даже небольшой, — это большое дело. Я мог бы сказать об этом гораздо больше, но для сообщения такой длины это, честно говоря, самый полезный совет, который я могу придумать: работайте итеративно, сопротивляйтесь желанию немного унифицировать код и знайте, что сериализация — это большая проблема. предмет, чтобы вы могли выбрать подходящую стратегию. По моему опыту, каждая из этих вещей может стать камнем преткновения, если ее игнорировать.
Мне нравится сравнивать заметки по этому поводу, поэтому мне было бы очень интересно услышать мнение других разработчиков.Если вы написали движок, привел ли вас ваш опыт к такому же выводу? И если вы не написали ни одной или просто думаете об этом, меня тоже интересуют ваши мысли. Что вы считаете хорошим источником для обучения? Какие части все еще кажутся вам загадочными? Не стесняйтесь оставлять комментарии ниже или пишите мне в Twitter!
Написание игровых движков на C #
Сайффирос А … теперь понятно. Были некоторые части вопроса, которые мне были непонятны. В частности, ссылка на «мягкий движок» (или «программный движок») — это термин, который, как мне кажется, не знаком в индустрии программного обеспечения, по крайней мере, среди моих коллег-разработчиков или среди множества технических материалов, которые я читаю.Хотя этот термин используется в статье davrous.com, похоже, нет четкого определения для него в Википедии или других источниках, в которых проводится различие между использованием ЦП и ГП. Итак, контекст для меня был потерян. Кроме того, за ссылкой на «мягкий движок» следовало «(с использованием только процессора, а не DirectX / OpenGL / Vulcan)». Я интерпретировал это как то, что вы хотите реализовать собственный API для графического процессора на C #, а не использовать существующий, написанный на C или C ++. Опять же, можно было бы интерпретировать ссылку на «процессор» как на графический процессор в данном контексте.Я лишь указываю на свое собственное замешательство, чтобы помочь прояснить ситуацию для всех, кто может прийти к аналогичным недоразумениям, исходя из текущей формулировки вопроса.
Издатель
отклонил мою игру из-за специального движка C ++
Если вы собираетесь продавать игры и зарабатывать на них деньги, вы знаете, что написание собственного движка займет много времени. Однако вы можете не знать, что написание собственных технологий также может стоить возможностей и партнерских отношений. Вам также нужно будет помнить об этом.Это моя история о том, как я усвоил этот урок:
Примечание: Я вошел в поиск по издателям, просто проверяя, какие возможности могут существовать, поскольку мой поток разработки игр зрители подталкивали меня попробовать.
Шаг
В сентябре 2019 я подготовил Turbo Boom! быть переданным нескольким издателям. Потратив много дней на полировку и настройку этого контента, я отправил 25-30 писем.Издатели, получившие это письмо, были выбраны на основе их интереса к гоночным играм или играм, основанным на действиях, которые достаточно похожи на Turbo Boom! В течение октября приходили ответы, большинство из которых включали «к сожалению, в настоящее время не подходят», а также достаточно информации, чтобы показать, что они восприняли мою презентацию серьезно.
Один издатель даже задал дополнительные вопросы о таргетинге на мобильные платформы после первого запуска настольных компьютеров. Я знал, что обсуждение того, что мой собственный движок C ++ не поддерживает мобильные устройства в данный момент, было бы неприятным.Поэтому я сообщил издателю, что мобильные устройства не поддерживаются, и дал реалистичную оценку того, сколько времени потребуется, чтобы добавить эту поддержку. Я был очень уверен в этой оценке, так как мой движок некоторое время частично работал на iOS.
Они восприняли этот ответ достаточно хорошо и пошли, чтобы пересмотреть его с остальной частью своей команды в течение недели или двух. К сожалению, следующим ответом было то, что они сняли крючок с не столь тонкого намека на то, что причиной был мой собственный движок и добавленный им риск.
Это имеет смысл.
У пользовательского движка гораздо больше неизвестных, особенно для издателей, которые обычно не являются разработчиками. Судя по ответу, когда использовался основной движок (Unity, Unreal), «это просто работает» в глазах не разработчиков, у моей игры мог быть издатель. Но это нормально, мне нравится делать все по-своему. Это всего лишь усвоенный урок, что специализированный механизм также может стоить возможностей, основанных на предполагаемом, и фактическом, дополнительном риске, который увеличивается с помощью специальных технологий.
Как инди-разработчик важно смотреть на вещи с точки зрения бизнеса, и я уже знал, что разработка пользовательского движка отнимает много времени, требует больших затрат и увеличивает риск. Только после этого ответа я осознал, что риск распространяется на возможности и партнерские отношения. Об этом должны знать и другие люди, идущие аналогичным путем.
Как стать разработчиком игрового движка — Гарольд Серрано
Вот шаги:
Шаг 1. Изучение линейной алгебры
Сначала изучите линейную алгебру.Нет, я не имею в виду алгебру, которую преподают в средней школе. Я имею в виду такие понятия линейной алгебры, как векторы и матрицы. Сосредоточьтесь на обучении векторным и матричным операциям, особенно скалярному произведению, кросс-произведению, пространственным преобразованиям.
Шаг 2. Изучите C ++ (или любой другой язык по вашему выбору)
Далее научимся программировать. Предлагаю изучить C ++. На этом этапе вам не нужно быть экспертом в кодировании. Но узнайте о классах, методах, наследовании, полиморфизме и инкапсуляции.
Шаг 3. Разработка математической машины
Затем используйте свои знания векторов, матриц и кодирования для разработки математической машины.Такие операции, как точечное произведение, кросс-продукт и преобразование пространства, широко используются при разработке игрового движка.
Шаг 4. Изучение компьютерной графики
А теперь самое интересное. Познакомьтесь с концепциями компьютерной графики, особенно с конвейером рендеринга и шейдерами. На данный момент избегайте кодирования и использования OpenGL API. OpenGL API сложно понять, если у вас ограниченные познания в концепциях компьютерной графики.
Шаг 5. Изучите OpenGL и выполняйте множество проектов
Когда вы освоитесь с концепциями компьютерной графики, узнайте об OpenGL API и OpenGL Shaders.Выполняйте как можно больше проектов. Узнайте, как отображать символы, как вращать и переводить символы. Узнайте, как текстурирование и освещение работают с OpenGL. Опять же, это самое интересное, и я предлагаю выполнить как можно больше проектов.
Шаг 6. Изучение шаблонов проектирования
Следующим шагом на пути к тому, чтобы стать разработчиком игрового движка, является изучение архитектуры API. Игровой движок — это просто API, фреймворк, который заботится обо всех операциях рендеринга, физике и математике. Крайне важно разработать модульный, гибкий, поддерживаемый и адаптируемый API.
Для разработки API вам необходимо изучить шаблоны проектирования. Наиболее распространенными шаблонами проектирования являются Singleton, Observer, Strategy, Composite, Factory и другие.
Шаг 7. Разработка механизма рендеринга
На этом этапе вы готовы объединить свои знания линейной алгебры, компьютерной графики, OpenGL и шаблонов проектирования для разработки механизма визуализации.
Шаг 8: Просмотрите законы движения Ньютона
После того, как вы завершили работу с движком рендеринга, пора поработать над самой сложной частью движка, т.е.е., Physics Engine.
Хорошая новость заключается в том, что вам не нужно быть физиком, чтобы разработать Physics Engine, но вам нужно знать законы движения Ньютона и то, как они реализуются с использованием таких алгоритмов, как алгоритм Рунге-Кутта.
Шаг 9: Изучение алгоритмов вычислительной геометрии
Игровой движок — это не игровой движок без обнаружения столкновений. Чтобы разработать систему обнаружения столкновений, вам необходимо узнать об алгоритмах вычислительной геометрии, таких как GJK, BVH и Sutherland-Hodgman.Эти алгоритмы используются для определения того, произошло ли столкновение, где оно произошло и какие объекты могут столкнуться с наибольшей вероятностью.
Шаг 10. Разработка физического движка
Когда вы познакомитесь с упомянутыми выше алгоритмами, вы сможете разработать физический движок с системой обнаружения столкновений.
Шаг 11. Разработайте игру, проверьте и повторите
Поздравляю, теперь у вас есть игровой движок. Разработайте как можно больше игр и максимально протестируйте игровой движок.Исправляйте ошибки, внедряйте новые функции, разрабатывайте игры и повторяйте. Поверьте мне; это лучшая часть всего.
Книги для начала работы
Вот список книг, которые помогут вам начать работу:
3D-математика
Учебник по 3D-математике для разработки графики и игр
Механизм рендеринга
OpenGL Superbible: подробное руководство и справочник
Графические шейдеры: теория и практика, второе издание
Физический двигатель
Физика для разработчиков игр: наука, математика и код для реалистичных эффектов
Разработка физического движка игры: как создать надежный физический движок коммерческого уровня для вашей игры
Обнаружение столкновений в реальном времени
Надеюсь, это поможет
Как я написал свой собственный движок для 3D-игр и за 20 месяцев выпустил игру с ним
15 октября 2017 г.
Моя игра Speebot наконец-то вышла в Steam! Если вы поклонник 3D-платформеров, не забудьте купить его, пока действует скидка на запуск.Перед покупкой можно попробовать бесплатную демоверсию.
Speebot находится в разработке с января 2016 года, и я работаю над ним в свободное время в качестве хобби. Я занимался программированием, дизайном игр, графикой и музыкой. Я также написал игровой движок с нуля.
Меня часто спрашивают, почему я решил написать свой собственный игровой движок в 201X году, когда существует несколько бесплатных движков общего пользования. Есть много причин, но, оглядываясь назад, я могу сказать, что «изобрести собственное колесо» было даже лучше, чем я думал изначально.
Одно из самых больших преимуществ специализированного движка — это абсолютный контроль кода. Я могу настроить его буквально так, как хочу, и оптимизировать для своего конкретного случая использования. Универсальные игровые движки называются так потому, что они предназначены для общего использования, что приводит к раздуванию и часто значительному замедлению работы.
Второе преимущество — контроль рабочего процесса. Я считаю, что эффективный рабочий процесс имеет решающее значение при разработке игр, и это решение позволяет мне интегрировать мои собственные инструменты таким образом, чтобы мне было проще и быстрее создавать контент.
Конечно, есть также преимущество отсутствия привязки к каким-либо Условиям использования и необходимости платить лицензионные сборы.
Кроме того, это весело. Думаю, этого должно быть достаточно.
Я начал разработку движка в январе 2016 года. Я назвал его YUME (что в переводе с японского означает «мечта»), и он написан на Haxe, C ++ и OpenGL. Я использую собственный форк библиотеки Lime, которая представляет собой легкий фреймворк, который позволяет управлять такими вещами, как управление активами и доступ к контексту GL.
Это то, на что двигатель YUME был способен в свою первую неделю.
Когда я начал работать с YUME, я почти ничего не знал о разработке 3D-игр. Мне пришлось изучить OpenGL из документации, архивных сообщений на форумах и руководств, предназначенных для программистов на Java и C ++. Для меня была особенно трудна трехмерная алгебра, и иногда я зацикливался на задачах на несколько дней. Но в конце концов я со всем разобрался, и через пару месяцев у меня появился довольно солидный 3D-рендерер.
Помимо 3D-рендерера, мне пришлось реализовать различные другие подсистемы, в том числе: 2D-рендерер, конечные автоматы, систему временного шага (подробнее об этом позже), систему пользовательского интерфейса, систему ввода с помощью мыши, систему ввода с клавиатуры, система ввода геймпада, динамические тени, трехмерная звуковая система (с использованием OpenAL), загрузка модели (в моем собственном файловом формате на основе IQM), скелетная анимация, прикрепления костей, отражения в реальном времени, рендеринг растрового текста и т. д. и т. д. .
В результате у меня получился небольшой функциональный 3D-фреймворк. Многие из перечисленных мною вещей являются важными, которые, без сомнения, можно найти в любом другом игровом движке, но есть несколько ключевых отличий, которые оправдывают раннее существование YUME. Одна из таких вещей — моя система временного шага.
Система временного шага гарантирует, что механизм отображает кадры с определенными интервалами. В отличие от большинства современных игровых движков, YUME не имеет ограничения частоты кадров, то есть не привязано к 30 или 60 кадрам в секунду.Фактически, частота кадров может составлять от 1 до 250 кадров в секунду, и игра по-прежнему будет работать с той же скоростью, независимо от частоты кадров (только экран будет обновляться с разными интервалами). Это достигается за счет отделения игровой логики от рендеринга. Рендеринг одного кадра может занимать разное время на разных компьютерах, поэтому частота кадров рендеринга зависит от производительности программы. С другой стороны, логический цикл привязан к частоте 64 тика, то есть логика игры обновляется 64 раза в секунду, независимо от частоты кадров рендеринга.Система временного шага должна учитывать несколько крайних случаев, но принцип остается тем же. В результате частота кадров снижается на более слабых компьютерах без нарушения игрового процесса.
Ранняя демонстрация YUME.
У меня был фреймворк, а не игровой движок. Пришло время начать разрабатывать свою игру и решить, какие функции мне нужно реализовать. К тому времени у меня уже было несколько идей, и я знал, что хочу поэкспериментировать с наборами тайлов в 3D.
Я начал писать систему карт, которая была похожа на 2D тайловые карты, к которым я привык, но с дополнительным измерением.Я сделал для себя редактор, чтобы ускорить процесс создания карты (предупреждение о спойлере: эта функция превратилась в специальный редактор уровней, включенный в финальную версию игры). Я сделал так, чтобы движок автоматически определял, какой тип плитки отображать, основываясь на своих соседях (некоторые называют это «автоустановкой»). Я придумал способ объединить все тайлы в одну сетку, что означает, что вся карта обрабатывалась движком как единая модель и могла быть нарисована за один вызов графического процессора. В результате производительность была действительно хорошей.Мне не нужно было составлять карты, я мог редактировать и воспроизводить их в реальном времени. Это было идеально для продуктивности.
Я написал простую физическую систему — базовые столкновения, трение, ничего слишком сложного — и начал экспериментировать с игровым процессом… Через пару недель у меня был цилиндр, который прыгал по тайловой карте в 3D.
Благодаря YUME я смог создать прототип и по-настоящему эффективно экспериментировать с игрой.
Прототип Speebot в июле 2016 года
Движок YUME развивался по мере продолжения моего прогресса в Speebot (примерно в это время я выбрал имя Speebot).Я обнаружил и распознал проблемы с моей архитектурой, когда работал с движком, и дважды реорганизовал его. У движка теперь была простая физическая система, частицы, отражения в воде, аниматоры камеры, интерактивные объекты, литье лучей… Из фреймворка он превратился в игровой движок.
Я добавлял новые игровые механики и выяснял, что работает хорошо. Я оставил то, что было забавным, и удалил или переделал то, что не было забавным. Я начал экспериментировать с художественным оформлением игры и создал в Blender маленького персонажа-робота.Я обнаружил, что мультипликационная анимация с резинкой для персонажа работает очень хорошо, они делают игру беззаботной и сочной. Я сохранил этот вид и для будущих NPC и сущностей.
Speebot начинал выглядеть и ощущаться как игра!
В тот момент я работал над игрой, а не над игровым движком. Я продолжал создавать новые карты, реквизит, NPC и механики. Редактор уровней рос с новыми функциями, как и сам движок.
Зимой 2016/2017 я взял на пару месяцев перерыв от обычной рутины разработки игр и сосредоточился на практике сочинения музыки.У меня нет формального музыкального образования, но оно мне нравится, и я написал саундтрек к своей предыдущей игре Hypnorain в прошлом. Я хотел добиться большего для Speebot, поэтому я снова погрузился в теорию музыки и сделал много тренировочных треков. Для создания музыки я использовал SunVox — модульную программу для синтезатора и трекера. В финальной версии Speebot 23 трека, что составляет около часа оригинальной музыки. Я действительно очень доволен результатами. Я продолжу совершенствовать свои навыки к следующей игре.
С этого момента я попеременно создавал новые уровни, вводил новые игровые механики, писал музыку и исправлял ошибки. Мне очень нравится этот рабочий процесс, потому что он позволяет мне контролировать каждый аспект игры, и когда мне становится скучно выполнять одно действие, я просто переключаюсь на другой.
После выпуска пары демоверсий, сбора отзывов игроков и улучшения игры — Speebot был выпущен в октябре 2017 года. Финальная игра имеет 200 этапов, 4 мира, настраиваемый редактор уровней, различные дополнительные режимы, открываемые косметические средства и другой побочный контент. .
Без сомнения, одной из самых сложных задач было сохранять мотивацию и продолжать работать над игрой каждый день после университета / работы и в выходные дни. Тем не менее, это было очень весело, и оно того стоило.
Я буду продолжать использовать и улучшать YUME в своих будущих играх. Я уже начал работать над своим следующим проектом. Скоро будет больше информации!
Speebot был моим самым амбициозным проектом и лучшей игрой.
Но моя следующая игра будет намного лучше.
Программирование на игровом движке 3D | Помогаем вам создать игровой движок вашей мечты
C ++ Fast-track для программирования игр, часть 17: AI
Как и физика, ИИ ( Искусственный интеллект ) — невероятно сложная область, и она постоянно меняется. Некоторые компании выделяют целые команды на эту тему, чтобы их игра обеспечивала увлекательный игровой процесс. Поэтому в этом уроке мы рассмотрим только несколько основных понятий.
Читать далее →
Опубликовано в Учебники по C ++, Программирование | Tagged Новичок, C ++, игра, игры, математика, программирование, учебник |
C ++ Fast-track для программирования игр, часть 16: Физика
В этом уроке вы познакомитесь с физикой игры.Это невероятно широкая область, к тому же довольно сложная, так что на самом деле вы получите только тизер. Однако это даст довольно приятные эффекты.
Читать далее →
Опубликовано в Учебники по C ++, Программирование | Tagged Новичок, C ++, игра, игры, математика, физика, программирование, учебник |
C ++ Fast-track для программирования игр, часть 15: Файловый ввод-вывод
Прежде чем мы продолжим рассмотрение типичных тем, связанных с играми, вам необходимо знать еще несколько общих приемов, которые помогут вам при написании игр.Один из этих методов — ввод-вывод файла . Файловый ввод / вывод означает ввод / вывод . Вы, конечно, уже выполняете операции файлового ввода-вывода, например, когда загружаете изображение. Однако этим занимается некоторая библиотека изображений (FreeImage). Иногда вы просто хотите хранить свои собственные данные.
Читать далее →
Опубликовано в Учебники по C ++, Программирование | Tagged Новичок, C ++, файловая система, игра, игры, математика, программирование, учебник |
C ++ Fast-track для программирования игр, часть 14: фиксированная точка
В части 9 вы работали с цветами и познакомились с благородным искусством битмаги.2a + 2a \), что эквивалентно (a << 2) + (a << 1) с использованием операций битового сдвига. Знать количество битов в переменной особенно важно, если в битах 32-битного целого числа хранится более одного числа. Так обстоит дело с 32-битными цветами: каждый из красного, зеленого и синего компонентов использует 8 бит, а альфа-компонент дополняет 32 бита для представления одного пикселя.
Читать далее →
Опубликовано в Учебники по C ++, Программирование | Tagged новичок, C ++, фиксированная точка, игра, игры, математика, программирование, учебник |
C ++ Fast Track для программирования игр, часть 13: структуры данных
Вы уже достаточно далеко изучили серию руководств по подготовке к C ++ Fast Track для игр.Если вы пришли сюда в хорошей форме, вы многому научились: вы прошли основы программирования на C ++, а также познакомились с объектно-ориентированным программированием. Тем временем вы экспериментировали с довольно большим количеством игровых концепций. В следующих частях вы расширите свои знания, добавив больше информации о битовой магии, файловом вводе-выводе, графическом программировании и разработке игр в целом. Но сначала: давайте познакомимся с удивительным миром структур данных .
Читать далее →
Опубликовано в Учебники по C ++, Программирование | Tagged Новичок, C ++, структуры данных, игра, игры, математика, программирование, учебник |
C ++ Fast-track для программирования игр, часть 12: классы
В этой части мы будем использовать код нашей работы с Tiles.Мы стремимся разместить это в более удобной и понятной структуре - вот где на помощь приходят классы.
Читать далее →
Опубликовано в Учебники по C ++, Программирование | Tagged Новичок, C ++, Классы, игра, игры, математика, Программирование, учебник |
C ++ Fast-track для программирования игр, часть 11: плитки
Пришло время познакомить вас с отличной концепцией 2D-графики на C ++, которую вы найдете очень полезной и простой в использовании: тайловых карт .
Читать далее →
Опубликовано в Учебники по C ++, Программирование | Tagged Новичок, C ++, игра, игры, математика, программирование, учебник |
C ++ Fast-track для программирования игр, часть 10: Массивы
В предыдущих эпизодах мы обычно работали с одним объектом за раз: одним шаром, одной песчинкой и так далее.На практике нам обычно понадобится несколько из них. Вот здесь и пригодятся массивы.
Читать далее →
Опубликовано в Учебники по C ++, Программирование | Tagged Массивы, Новичок, C ++, игра, игры, математика, программирование, учебник |
C ++ Fast-track для программирования игр, часть 9: цвета
В этой статье мы вернемся к числам, обозначающим цвета, как показано во второй части этой серии. Это можно сделать только с помощью чудесного мира магии bit , который, кстати, является очень приятным местом, поэтому мы исследуем его тщательно.
Читать далее →
Опубликовано в Учебники по C ++, Программирование | Tagged Новичок, C ++, игра, игры, математика, программирование, учебник |
C ++ Fast-track для программирования игр, часть 8: адреса
Одна из самых сложных концепций C ++ - это концепция указателей. Указатели имеют прямое отношение к самой природе языка: C ++ приближает вас к оборудованию, с которым вы работаете, и одной из наиболее важных частей этого оборудования является память. В этом руководстве вы научитесь использовать указатели для обращения к адресам памяти.
Читать далее →
Опубликовано в Учебники по C ++, Программирование | Tagged Адреса, Новичок, C ++, игра, игры, математика, программирование, учебник |
12 лучших бесплатных игровых движков для начинающих и экспертов
Изображение Кэмерон Митчелл Ресурсы3DИгровой дизайн По сценарию Джоша Петти Раскрытие информации: этот пост может содержать партнерские ссылки. Это означает, что если вы что-то покупаете, мы получаем небольшую комиссию без каких-либо дополнительных затрат для вас (подробнее)
С развитием инди-дизайна игр растет спрос на новые инструменты и игровые движки.
Преимущество использования игрового движка состоит в том, что решает множество универсальных проблем , применимых ко всем играм. Такие вещи, как ввод данных пользователем, физика, освещение, рендеринг и столкновение, все предварительно разработано, поэтому вы можете сосредоточиться на самой интересной части: создании игр.
Но существует так много бесплатных игровых движков, которые соревнуются за вашу творческую энергию. Как выбрать?
Прежде чем углубиться в этот список, я хотел бы сказать, что не существует «единой машины, которая бы управляла всеми ими».
У каждого двигателя есть свои сильные и слабые стороны.У каждого будут свои преимущества для определенных проектов. Кроме того, у каждого движка есть свой стиль и индивидуальный подход к пользователю.
Construct 2 нацелен на новичков и непрограммистов, в то время как Unreal Engine изначально создавался для шутеров от первого лица.
Поищите вокруг, попробуйте несколько, посмотрите, какие из них выделяются. Чем больше вы играете, тем больше узнаете о процессе разработки игры.
И не бойтесь сделать неправильный выбор! Каждый игровой движок научит полезным навыкам, имея множество общих функций.
1. Годо
Отъезд Годо
Движок Godot - ваше решение с открытым исходным кодом для настоящей кроссплатформенной разработки игр.
Это мой любимый движок для разработки 2D-игр, и он также хорошо работает с 3D. Релиз Godot 3.0 привел к серьезному обновлению 3D-функций, в результате чего она стала работать с другими современными игровыми движками, сохранив при этом бесплатную цену.
Godot также предлагает специальный 2D-движок, который работает в пиксельных координатах и упрощает разработку 2D.
Благодаря множеству доступных языков, включая C ++, C # и GDScript (вариант на языке Python), Godot легко программировать и легко изучать.
Лучшая часть движка Godot - это система сцен и узлов. Это упрощает организацию ваших игр, ускоряет разработку и улучшает масштабируемость ваших проектов.
Благодаря мощным инструментам анимации и встроенному редактору сценариев создавать игры с Godot - одно удовольствие. Определенно стоит попробовать, особенно если вы увлекаетесь 2D-проектами.
2. Оружейная
Оружейная
Вот изящный игровой движок с открытым исходным кодом, который интегрируется с программным обеспечением для 3D-анимации Blender, одним из самых популярных вариантов для всех в сообществе 3D-разработчиков с открытым исходным кодом.
Blender - популярный выбор среди инди-разработчиков, поэтому Armory решает проблему перехода между программами при разработке игр.
Для начала вам доступно несколько демоверсий, в том числе игра с двумя палками и демо-версия персонажа от третьего лица.
Перед изучением Armory полезно познакомиться с Blender и его исчерпывающим списком инструментов.
Но если вам нужен игровой движок, который популярен в мире с открытым исходным кодом, вам стоит присмотреться к Armory. К тому же, если вы никогда не изучали Blender, неплохо было бы его взять в руки!
3. Единство
Проверить Unity
Если вы ищете универсальный игровой движок, Unity - это то, что вам нужно.
Он может похвастаться доступным, но мощным набором инструментов, которые сделали Unity самым популярным игровым движком.
Благодаря мощному кроссплатформенному набору инструментов Unity использовалась для создания таких популярных игр, как Pokemon Go, Hearthstone и Rimworld.
Возможно, лучшая часть Unity - это огромное сообщество, которое обеспечивает нескончаемый запас новых активов и учебных ресурсов. Если у вас есть время и целеустремленность для изучения Unity, сообщество станет чрезвычайно ценным активом.
Используя готовые ресурсы и продвинутый движок рендеринга Unity, можно создать красивый прототип за несколько дней или недель.
Благодаря партнерству с Microsoft разработчики Unity также могут использовать Visual Studio в качестве редактора сценариев. Visual Studio предоставляет инструменты, которые предлагают значительные улучшения по сравнению с обычным интерфейсом Unity, и это полезно, если вы все равно обычно пишете код в MS Visual Studio.
Обратите внимание, что Unity - это , а не 100% бесплатный , если вы зарабатываете на игре деньги. Практиковаться и создавать свои собственные вещи совершенно бесплатно. Но загляните в их магазин, чтобы узнать цены, если вы действительно хотите опубликовать игру и заработать на ней реальные деньги.
4. Unreal Engine
Отъезд Unreal
Unreal Engine 4 действительно является рок-звездой этого списка.
Unreal Engine, отвечающий за такие игры, как Fortnite, Player Unknown Battlegrounds и даже последний вариант для Kingdom Hearts 3, предлагает всего, что вам нужно для создания потрясающих высококачественных игр.
Чтобы создать настоящую игру класса ААА, вам, вероятно, понадобится большая команда. Но это не значит, что небольшая инди-студия не может заняться чем-то здесь и начать работать над этим.
Графические возможности
Unreal конкурируют с CryEngine, но Unreal более отточен и удобен для пользователя.
Сценарии обрабатываются на C ++, поэтому вам может пригодиться некоторый опыт программирования. Но с помощью Blueprints, редактора сценариев на основе узлов, разработчики Unreal могут создавать поведение , не написав ни единой строчки кода .
Epic предоставляет множество руководств, чтобы помочь новичкам освоиться с движком. Unreal также предлагает кроссплатформенную поддержку и шаблоны как для 2D, так и для 3D-игр.
Как и Unity, Unreal имеет собственный рынок активов, где пользователи могут находить модели и инструменты для использования в своих проектах.
Несмотря на то, что в нем есть качественный контент, торговая площадка Unreal не так надежна, как магазин ресурсов Unity. Но не позволяйте этому отговаривать вас от попытки!
В конце концов, вы никогда не ошибетесь, попробовав Unreal и изучив эту платформу наизнанку. Его можно использовать практически в любой игре, поэтому то, что вы здесь узнаете, можно перенести практически на любой другой игровой движок.
5. CryEngine
Проверить CryEngine
CryEngine - это мощный движок для 3D-игр, предназначенный для создания современной графики для консолей или ПК.
Благодаря надежной поддержке виртуальной реальности и продвинутым визуальным эффектам CryEngine привлекает разработчиков, стремящихся создавать фотореалистичные игры или игры следующего поколения на такой платформе, как Steam.
В целом, этот игровой движок нацелен на контент AAA-качества с детализированными и суперреалистичными персонажами.Как и Unity и Unreal 4, CryEngine предлагает набор инструментов, упрощающих разработку игр.
Это определенно стоит изучить, если вы серьезно относитесь к высокоуровневому игровому дизайну.
С помощью редактора уровней и инструментов дизайна CryEngine эффективное редактирование уровней возможно даже с небольшим набором навыков. Разработка полноценной рабочей игры от начала до конца может быть довольно быстрой, если вы действительно изучите движок.
К сожалению, CryEngine имеет репутацию сложного в использовании и более сложного для изучения, чем большинство движков.Новичкам, вероятно, следует начать с чего-нибудь еще, чтобы хотя бы познакомиться с тем, как работает игровой движок.
Также стоит отметить, что этот движок можно использовать совершенно бесплатно, но при публикации коммерческой игры необходимо учитывать роялти. Посетите страницу регистрации для получения дополнительной информации.
6. Defold
Проверить Defold
Ищете движок для 2D-игр? Well Defold объединяет все необходимое для разработки в один инструмент.
Он позиционируется как лучший способ создавать игры для веб-дизайнеров и дизайнеров мобильных устройств.И со встроенными функциями контроля версий и управления командой они могут быть правы.
Сосредоточившись на разработке 2D-игр, Defold может предоставить оптимизированный пакет с инструментами, специально ориентированными на 2D-мир.
Начать работу легко с помощью множества подробных руководств, представленных в редакторе сразу после установки. Выполнение может занять несколько часов, но вы узнаете все основы создания платформеров с нуля, создания эффектов параллакса для фона или чего угодно!
Defold использует язык программирования Lua для написания сценариев поведения.Кроме того, он бесплатный и с открытым исходным кодом, чтобы обеспечить легкий и бесплатный опыт разработки.
7. Моногейра
Отъезд Monogame
So Monogame - это фреймворк с открытым исходным кодом, созданный специально для создания кроссплатформенных игр.
Поклонники популярной Stardew Valley будут рады узнать, что она была разработана с использованием Monogame.
Те, кто имеет опыт работы с C # или работает в среде Microsoft .NET, будут чувствовать себя в Monogame как дома.
В отличие от других движков в этом списке, Monogame не предоставляет достаточно инструментов и функций, чтобы сделать его пригодным для использования некодерами. Это поистине рай для разработчиков, поэтому, если вы ненавидите терминал или командную строку, вам нужно поискать в другом месте.
Разработчики, использующие Monogame, должны будут кодировать свои собственные столкновения и физику или использовать библиотеки, чтобы помочь с этим.
Но Monogame по-прежнему пользуется популярностью среди тех, кто знает, как ее использовать. И активное сообщество готово помочь новичкам начать работу.
8. Корона
Отъезд Corona
Я упоминал Lua ранее, и вы часто увидите, что язык Corona, 2D-движок, созданный для быстрого прототипирования и кроссплатформенного развертывания.
Дружелюбный для новичков и интересный для изучения, Corona совершенно бесплатно без скрытых лицензионных отчислений . Это очень важно, учитывая, что многие игровые движки требуют оплаты за коммерческие продукты.
Если вы хотите учиться, но не знаете, с чего начать, обратитесь за помощью к сообществу Corona, насчитывающему более полумиллиона разработчиков.У них также есть небольшой, но полезный субреддит, который вы можете просмотреть.
Во многих отношениях Corona - это больше, чем игровой движок.
Он сочетает в себе рынок пользователей, издательскую службу и игровой движок в одном лице.
Идея состоит в том, что разработчики могут больше сосредоточиться на создании игр, а не на хлопотах по продвижению и продаже своей работы.
Ориентированная на новичков и мобильных разработчиков, Corona предлагает более линейный и легкий в освоении процесс, чем то, что требовалось бы в более крупной среде IDE.
Тем, кто ищет путь наименьшего сопротивления, обязательно стоит подумать о Corona, по крайней мере, если вы новичок в игровом дизайне.
9. Phaser
Отъезд Phaser
Phaser в значительной степени основан на Flixel, бесплатной библиотеке флеш-игр.
Этот движок позволяет разрабатывать игры HTML5 для настольных и мобильных устройств прямо из браузера. Поскольку Phaser прост в освоении и управляет большим сообществом, это хорошее решение для людей, изучающих разработку 2D-игр.
Разработчики с опытом веб-разработки и Flash (теперь Adobe Animate) оценят Phaser больше всего. Хотя он нацелен на новичков и прост в освоении, многие функции Phaser заблокированы за платный доступ.
Те, у кого нет средств для разблокировки дополнительных функций, будут вынуждены использовать довольно ограниченное бесплатное решение.
Но лицензия бесплатная. Вы можете выпускать и продавать игры, которые вы разрабатываете с помощью Phaser. Кроме того, на веб-сайте Phaser есть обширный список руководств и примеров кодирования, охватывающий все, что вам понадобится для быстрого изучения разработки игр.
10. GameSalad
Проверить GameSalad
Если вы новичок в игровом дизайне и ищете простой способ обучения, вам стоит взглянуть на GameSalad.
Это игровой движок, использующий create в качестве метода обучения. Для разработчиков GameSalad предлагает невероятно простой способ создавать и публиковать игры.
Абсолютные новички будут удивлены тем, насколько легко создавать модели поведения с помощью функции сценариев перетаскивания.Для создания игр здесь не требуется никаких предварительных знаний в области программирования (хотя научиться программировать удобно!)
Тот факт, что GameSalad используется в образовательной среде K-12 для обучения навыкам программирования, свидетельствует о способности программы сделать обучение приятным процессом .
Тем не менее, вы не сможете достичь желаемого уровня детализации для готовой игры. Но это не значит, что здесь нельзя создавать веселые проекты.
Если вы что-то создадите, GameSalad может экспортировать вашу игру для ПК, мобильных устройств, Интернета и некоторых других платформ.Все совершенно бесплатно.
11. GameMaker
Ознакомьтесь с GameMaker
GameMaker - очень популярный игровой движок, отвечающий за такие игры, как Hyper Light Drifter, Orphan и Hotline Miami. Он работает как 2D-движок, но способен создавать контент AAA.
GameMaker разработан, чтобы быть простым для новичков, но достаточно мощным, чтобы удовлетворить потребности большой студии.
Благодаря динамическому физическому движку и настраиваемому языку сценариев GameMaker является хорошим выбором как для любителей, так и для профессионалов.
С GameMaker вы получите беспрепятственный доступ к специализированному 2D физическому движку, а также возможность сетевой игры, кроссплатформенного развертывания и потрясающих визуальных эффектов с использованием шейдеров. Кроме того, есть еще много всего, что можно было бы перечислить, но вам действительно нужно испытать это на себе.
Если вы ищете 2D-движок, простой в использовании, но ничем не ограниченный, GameMaker - отличный выбор.
12. Amazon Lumberyard
Проверить лесной склад
Вы можете удивиться, узнав, что Amazon тоже окунается в игровое пространство.
Lumberyard - это бесплатный игровой движок, предназначенный для прямой интеграции с Twitch. Цель Amazon Lumberyard - создавать игры, которые так же интересно смотреть, как и играть, поэтому ключевыми пунктами внимания являются качественная графика и выдающаяся производительность.
Если вы знакомы с игровым дизайном, вам, вероятно, понравится то, что вы здесь увидите. Он обеспечивает многофункциональный опыт, который включает интеграцию с облаком, встроенное многопользовательское развертывание с онлайн-инструментами и поддержку с поддержкой модов.
No related posts.