2D движок для игр: Самые популярные бесплатные движки для разработки игр / Хабр

У Unity всё плохо / Хабр

На просторах интернета, и в частности хабра, очень трудно встретить статьи с критикой игрового движка Unity. Я решил это исправить, и приготовил вам текст о переходе на DOTS, насилию над C#, знаменитых UI пакетах, MonoBehaviour, универсальности и о многом другом.

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

DOTS

Кадр из презентации DOTS. На картинке изображен спальный район Москвы через 20 лет.

В данный момент Unity активно переходит на новый стек технологий под названием DOTS. Транзит сопровождается лозунгом «Производительность по умолчанию» и идеей того, что С# может быть таким же быстрым как C++ у UnrealEngine и других движков. Главные фронтмены данного действа это Entities, Jobs и Burst.

Теория

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

Entities представляет из себя реализацию популярного в игровой индустрии паттерна ECS. ECS это паттерн, где код делится на сущности к которым добавляются компоненты с данными, состоянием компонентов у сущностей управляют системы, которые эффективно перебирают сущности с нужными им компонентами и изменяют данные компонентов по надобности.

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

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

• Хранение компонентов эффективно в памяти в соответствии с архетипом существа к которому они привязаны. Архетип это уникальное сочетание компонентов у существа. В случае Unity, компоненты хранятся в чанках по 16кб в соответствии с архетипом. Выходит, что чанки с компонентами хранятся друг за другом в памяти.

• Распараллеливание обработки существ системой. Тут всё очевидно, двигать 50 тысяч снарядов в каком-то шутере быстрее в 32х потоках одновременно. От программиста не требуется особых телодвижений для управления многопоточностью, потенциально ECS может эффективно управлять потоками самостоятельно. В Unity роль управления потоками делегирована фреймворку Jobs.

Такой паттерн хорошо подходит сложным играм, в которых есть очень много сущностей которые надо очень часто перебирать (к примеру ММО). Вдобавок, ECS управляет зависимостями, позволяя игре становиться все больше и больше без последствий.Но есть и обратная сторона медали, ECS плохо подходит играм, в которых мало сущностей и их не надо часто перебирать (например 99% мобильного рынка).

Jobs это реализация безопасной мультипоточности путем создания экземпляра «работы». Работу можно запланировать, получить ее обработчик и выполнить ее. Также работу можно запланировать после другой работы, или вместе с другими работами. Таким образом создаются целые цепи последовательных задач. Сами задачи выполняются сразу в нескольких потоках. Например, вам надо умножить все числа массива А с вместительностью в 100 элементов и положить их в массив B. Это можно сделать в десяти потоках, в каждом из них задача будет обрабатывать по 10 элементов.

Burst это компилятор, который транслирует IL байткод в оптимизированный нативный код с помощью LLVM. В основном, используется для компиляции работ с Jobs.

Имплементация

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

Начнем с того, как же команда Unity хочет сделать C# таким же быстрым, как C++, а именно:

• Создали новый компилятор для Работ с векторизацией и intrinsics (разве что без блекджека).

• Создали нессылочные альтернативы массиву, списку, очереди и т.д которые дружат с Burst’ом. Особенность в том, что эти контейнеры надо аллоцировать и после их жизненного цикла освобождать, иначе утечка. Причем, аллоцировать надо не абы как, а с правильными лейблами (Persistent/Temp/TempJob).

• Ввели в использование указатели на списки и указатели на функции. Также вам может понадобиться использовать Malloc, MemMove, MemCpy и подобные brand-new функции.

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

Ладно указатели, ладно Dispose у контейнеров, но когда вы начали писать новый компилятор для языка, можно же было что-то заподозрить! Пытаться уже третий год реализовать стек технологий на языке, который не подходит вашему стеку, и при этом переделывать* язык, это же сумасшествие!

Ещё один пример несовместимости DOTS и C# это Jobs с Работой IJobChunk и производными. Для того, чтобы проитерировать 3 компонента c помощью IJobChunk, вам надо 43 строки кода. Ситуацию могли бы спасти макросы, но они в C# предательски отсутствуют!

Следующая проблема нового стека Unity это недостаток многих функций, которые, иногда, могут вам пригодиться в создании игры, например:

• Звук. Версия пакета для звука 0.1.0-preview17 и за 3 года он так и не обновлялся.

• Интерфейс. Тут всё проще, пакета для интерфейса с поддержкой Entities просто нет.

• 2д. Существует com.unity.2d.entities, но он создан для Project Tiny и работает в общем-то только с ним, о Project Tiny тоже позже.

• Анимации. Пакет тоже существует, версия 0.9.0-preview.6, в теории использование возможно, на практике не очень.

• Всё элементы движка, которые не требуют очевидного отдельного пакета. Свет, камера, партиклы и т.д, всеми ими нельзя управлять через Entities, что угодно делайте. Можете создавать псевдо-сущность с компонентом, к примеру, камеры, и отдельной системой в главном потоке синхронизировать поля между MonoBehaviour камерой и вашей псевдо-камерой, можете другие костыли городить. За 3 года решения от Unity так и нет.

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

Проблемы

Предположим, что отсутствующие пакеты можно дописать, а текущую имплементацию можно ещё починить (в конце концов, можно переписать Roslyn!). Но проблемы самой DOTS как концепции, быстро решить не выйдет.

DOTS по умолчанию сложен. ECS требует полного понимания, как он работает, программисту надо знать на что влияет Read/Write доступ к компонентам, что такое Sync point и как сократить их количество, зачем нужен ECB, WriteGroup, гибридные компоненты и многое, многое другое. Также есть Jobs со своими контейнерами на указателях и такой же морокой с Read/Write доступом, Burst с миллиардом приспособлений для оптимизиации и примерами в документации из ассемблера.

Такая сложность явно не идёт на руку движку, одна из основных преимуществ которого простота. Unity занял свое место на рынке как «движок для дизайнеров, а не программистов», на нём делают Cuphead, Ori, Hollow Knight и другие игры которые не Factorio по сложности исполнения и требуемой оптимизации. У Unity занят рынок мобильных игр, маленьких кросс-платформенных инди игр, игр уровня «мы с парнями другие движки не знали, пришлось на этом пилить» (таким образом получаются Rust и Tarkov), в общем, идиллия. ААА игры не будут делать на Unity даже с полностью реализованным DOTS, ведь для них уже пишут отдельные движки на основе опенсоурса (UE) или вообще с нуля, а сложные инди игры делают энтузиасты на своих микро-движках, фреймворках или на том же UE.

В общем, плюсы от перехода на DOTS неочевидны, а минусы из-за нехватки ресурсов компании на поддержку и развития старых решений из уже уходящей эры MonoBehaviour присутствуют.

Project Tiny

В дополнение к выше написанному, хочу упомянуть Project Tiny. Это этакий набор мини-фреймворков для DOTS, которые должны помочь в разработке «Instant games» или, если выражаться русским языком, сделанные за 2 недели Егором из 9Б гипер казуальные игры типа тривряд. Также для Project Tiny команда Unity написала новую среду выполнения DOTS Runtime, вот вам документация (кстати в гугл доках, такого я не видел). Опять пересказывать то, что они пытаются переделать C#, смысла я не вижу, просто обозначу, что факт существования данного набора пакетов подтверждает то, что они хотят именно переделать движок с новым стеком DOTS, что в свою очередь, делает проблемы, описанные выше, ещё более значимыми.

Unity, но без DOTS

Скриншот редактора Unity. Если вы думаете, что автор не умеет удобно расставлять окна — вы правы.

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

MonoBehaviour

Начнем с основного старого архитектурного решения — MonoBehaviour. Mono потому что на C#, раньше ещё был, к примеру, JSBehaviour, но все языки кроме C# в Unity бесславно умерли, так и остался один единственный MonoBehaviour.

Если кратко излагаться, MonoBehaviour представляет из себя базовый класс для скриптов в Unity, унаследованные от него классы можно добавить на любой объект в сцене как компоненты, а публичные поля таких классов красивенько отображаются в редакторе. Код пишется в методах со спец. именем, которые ядро движка на С++ вызывает самостоятельно, такие методы называются Messages, их у MonoBehaviour целая куча, от обычных Start и Update до OnCollisionEnter и OnApplicationQuit.

Такое решение довольно простое в понимании и не требует вообще никаких навыков у программиста, у вас все под рукой. Для больших проектов это, естественно, никуда не годится. Тут нет какой-то внятной архитектуры, у вас логика приложения находится сразу же в структуре с данными (компоненте). MonoBehaviour почти не предоставляет никаких абстракций, не дает инструмента для управления зависимостями, методы для поиска объектов с MonoBehvaiour на сцене де факто антипаттерн из-за производительности, методы для вызова Message-методов у других MonoBehaviour ещё больше антипаттерн из-за ещё худшей производительности.

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

Команда Unity давным давно забила на попытки хоть как-то развить эту систему и пофиксить проблемы с производительностью.

Editor и UI

Разработчики Unity не умеют в UI. За 16 лет они не смогли создать пакет для адекватного интерфейса с xml/css/js и имплементировать редактор своего движка на нем. Для игр они сделали какой-то хлам с Canvas-ом и перетаскиванием панелей по иерархии сцены, а для редактора они предоставили что-то невообразимо ужасное с IMGUI на C# и рефлексией.

Спустя 16 лет они поняли, что шутки про использование штатного пакета для интерфейса Unity на форумах больше не смешные, и решили сделать новый пакет для интерфейса — UIElements (UIToolkit), с xml и css, но без js. Новый пакет для интерфейса непригоден для работы из-за отсутствия функционала у стилей. В нем нет анимаций, нет масок, нет полей для настроек выставления фона (только background-color и background-image), нет настроек шрифта и теней. Можете сравнить набор свойств у обычного CSS, и USS Unity.

Можно было бы сказать, что реализовать полный набор функций CSS движка довольно сложно, но вот Valve создали свой фреймворк Panorama с JS’ом, анимациями, масками, фоном, партиклами, сценами и многим другим. Благодаря ему, у игр Valve одни из самых лучших интерфейсов в индустрии. Понятно, что сравнивать Valve с Unity не совсем корректно, но это пример успешной реализации xml/css/js интерфейса в движке.

Декларируемая универсальность

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

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

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

Другое

Руководствуясь больше долгом о написании всех недочетов Unity, чем здравым смыслом, хочу отметить ещё немного мелких проблем которые не заслуживают отдельного параграфа, но заслуживают упоминание:

• Стилистика кода у биндингов Unity с префиксами m_, чрезмерным использованием internal и бесполезными комментариями наподобие «x — Left coordinate, y — Top coordinate». Пример.

• Существование авто-сериалайзера Unity который работает хуже чем любой другой из существующих в мире, я думаю что сериалайзер на конвейерах в Factorio работал бы лучше, и как минимум, поддерживал бы сериализацию словаря.

• Перезагрузка всех ресурсов с надписью «Hold on» после каждой правки кода. Команда Unity клянется что ничего не могут с этим сделать, но это нетерпимо.

• В Unity до сих пор нет поддержки C# 9, я просто напомню, что последняя версия уже C# 10. Поддержку #9 давно добавили.

• Асинхронные юнит тесты обещали, но конечно, не сделали. Приходиться создавать костыли.

Конец

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

Для небольших игр с простой 3д или 2д графикой

• Unity. Не смотря на все минусы перечисленные выше, скорее всего для простых игр он вам подойдет.

• Godot. Сам не пробовал, по ощущениям Unity v2, но опенсоурс и не будет требовать от вас деньги и ставить свой логотип в начале.

• GameMaker: Studio. Создан для 2д игр, на нем сделали Undertale. Без подписки минимум за 10$ делать ничего не хочет.

• Microsoft XNA. Не движок, но фреймворк для создания игр на C#, больше не поддерживается (но есть форки). На нем создают довольно много разных инди игр и по сей день, одна из самых популярных это Stardew Valley.

Для средних или больших игр с 3д графикой

• UnrealEngine. Больше мне советовать нечего, скорее всего он вам подойдет. Писать код на C++ это сжигание тонны времени, но блюпринты могут вас спасти.

Другое

• Amethyst. Движок на Rust, пока без своего редактора, естественно опенсоурс.
  Разработка движка прекращена.

• Bevy. Конкурент предыдущего движка, можете попробовать оба.

Из Unity в Godot. Первое впечатление / Хабр

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

Почему на нем?

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

Даже, когда я работала с Unity, он мне казался каким-то тяжёлым и неповоротливым. Он долго запускается, игры, которые должны весить 0,3-0,5 Гб, на нем весят 1,5-2 Гб. И вроде бы в современных реалиях это не такая большая беда, но мой внутренний перфекционист каждый раз хватался за сердце, когда это осознавал. Да и в целом Unity создавался для 3D игр, а нормальную поддержку 2D в нее добавили относительно недавно, да и то, по сути, костылем, а я в 3D соваться не планирую, так и зачем мне все это? Все больше и больше мне стало казаться, что я пытаюсь вырыть яму, чтобы посадить фиалку, экскаватором. Вроде бы вещь свою функцию выполняет, но мои цели иные.

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

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

ООП как по учебнику

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

В Godot все иначе. У меня создалось впечатление, что весь движок создавали вокруг идей ООП. Здесь даже, если не хочешь или не умеешь пользоваться его принципами, все равно будешь. Да, после Unity пришлось привыкать к новой организации пространства, но оно того стоит. Я не буду долго рассказывать, как там все устроено, все равно не смогу сделать это лучше и грамотнее, чем в документации, но прочтите про сцены, узлы, экземпляры. Это первое, что меня привлекло, удивило и обрадовало.

Сигналы

Мне очень понравилось, как работают сигналы в Godot. Я не знаю, как там все это устроено «под капотом», и что на самом деле происходит, когда посылается сигнал, но мне, с точки зрения пользователя, кажется очень логичным, что не нужно постоянно проверять нажата ли кнопка или не покинул ли объект экран. Здесь именно кнопка в момент нажатия или объект, который покидает экран, посылают сигналы о том, что произошло. Удобно и логично.

UI-элементы

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

А в Godot будто бы больше заботились именно о внутриигровом интерфейсе. Ту же шкалу здесь сделать гораздо проще.

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

А в Godot – характеристики игрока внутри игры.

---

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

---

Работа с изображениями

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

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

В итоге все-таки нашла, как это сделать, но только посмотрите, как неудобно.

Вы добавляете новый узел Sprite

Загружаете в него лист с изображениями

Внизу экрана каким-то чудесным способом замечаете вкладку «Область текстуры».

Выделяете необходимый фрагмент

И… Ничего не меняется на экране

Просто потому что в инспекторе вы не открыли вкладку Region и не поставили галочку напротив Enabled.

Как-то много неочевидных движений для одного такого простого действия.

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

Расположение элементов в пространстве

В основном я, конечно, о UI – элементах. В Unity с правильной настройкой Canvas в первые раза тоже пришлось немного повозиться, но, в целом, все оказалось все-таки проще, чем в Godot.

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

C# или GDscript

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

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

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

Не без противоположного мнения, конечно, — в интернете не раз встречала мысли, что у C# больше возможностей, и с GDScript будет просто невозможно сделать какие-то вещи. С другой стороны, в одном проекте тут можно использовать и оба языка, так что, проблем, вроде, возникнуть не должно.

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

---

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

Основные концепции разработки 2D-игр / Блоги / Perficient

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

Я начал исследовать это и обнаружил, что вы можете использовать что-то, называемое игровым движком, или вы можете закодировать их. У меня был ПК, который я использовал для домашних заданий и игр, но я понятия не имел, как устроено программное обеспечение, поэтому в основном я знал, как использовать ПК и программное обеспечение, и по этой причине я выбрал игровой движок вместо изучения программирования, потому что я читал, что программировать было очень сложно. Я нашел бесплатную версию Game Maker и создал игру, в которой можно было перемещать персонажа. У меня не было представления о том, какую игру я хочу сделать, поэтому я попытался добавить «приятные» функции, которые я не знал, как реализовать, но которым обучали видео на YouTube и блоги. Это было хорошо, пока я не понял, что могу «реализовать» функции, только следуя инструкциям, и это заставило меня разочароваться в себе. Я решил узнать, как все работает, и, копируя/вставляя большое количество кода сценариев, научиться программировать, когда я оглянулся назад, чтобы посмотреть, как у меня дела, я обнаружил, что люблю программирование, и это привело меня к этому моменту. моя жизнь (я изучал программную инженерию). Итак, этот блог (я планирую создать серию блогов) предназначен для предоставления очень простого пути/концепций/инструкций по разработке 2D-игр всем, кто интересуется или интересуется.0005

Давайте начнем с самых основных концепций разработки 2D-игр.

Инструменты

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

Game Engine

Это программное обеспечение, разработанное в основном для быстрой разработки игр (Game Engine, n.d.). Большинство современных движков включают в себя модули для различных его областей (редакторы уровней, управление активами, редактор частиц, сценарии IA и т. д.).

Вы когда-нибудь использовали Microsoft Paint? Я уверен, что у вас есть. Paint позволяет пользователю выбрать инструмент, цвет и сразу начать рисовать. Игровые движки пытаются делать то же самое, однако вместо того, чтобы рисовать 2D-изображения, они помогают пользователю создавать игры как можно быстрее. Разработчики игр не должны заботиться о разработке подсистем, а должны использовать их только для воплощения своей идеи в жизнь.

Существует несколько игровых движков, большинство из них бесплатны (или имеют бесплатную версию), могут использоваться для 2D- и 3D-игр, являются мультиплатформенными (разрабатывайте игры для ПК, телефонов, консолей и т. д.) и хорошо задокументированы (разработчиками, сообществом и крупными компаниями по разработке игр!). Просто упомянем несколько (Petty, nd): Unreal Engine, Unity, Godot, CryEngine.

Game Frameworks

Выбор глобального партнера по разработке программного обеспечения для ускорения вашей цифровой стратегии

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

Получить руководство

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

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

Вы можете найти игровые фреймворки для большинства существующих языков программирования, так что вы можете выбрать любой предпочитаемый язык и найти подходящий. Большинство из них имеют открытый исходный код и имеют сообщества значительного размера. SFML (C++), SDL (C), LÖVE (LUA), LibGDX (Java), XNA (C#) и Phaser (JS) являются примерами игровых фреймворков.

Библиотеки

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

Если вы выберете этот путь (на мой взгляд, трудный путь), вам нужно будет написать гораздо больше кода, чтобы иметь очень маленькое окно, рисующее что-то. Иногда они плохо документированы, или сама документация требует от вас много знаний о низкоуровневых системах. OpenGL, OpenAL, XInput, Microsoft DirectX — вот несколько примеров библиотек, которые можно использовать для разработки игр.

Подсистемы

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

• Рендеринг: Это процесс создания графики из модели (могут использоваться структуры данных) (рендеринг (компьютерная графика), нд).
• Моделирование физики: Используется для моделирования физики реального мира в различной степени. Широко используется платформерными играми.
• Обнаружение столкновения: Процесс обнаружения столкновения двух или более объектов (Lin, n.d.). Это можно разделить на 2 фазы: широкая фаза и узкая фаза.
• Разрешение столкновений: В то время как обнаружение определяет, сталкиваются ли 2 или более объектов или нет, разрешение столкновений — это процесс удаления объектов друг от друга, чтобы они не перекрывались, поскольку это будет странно для игрока (вы когда-нибудь видели человека, сливающегося со стеной?).
• AI: Искусственный интеллект использовался в видеоиграх с самого начала, и его использование и реализация также развивались. ИИ (в видеоиграх) не всегда настолько сложен, как в других вычислительных областях.
• Частицы: Имитирует частицы реального мира для достижения графических эффектов, которые в противном случае было бы трудно реализовать (Nystrom & Smith, n.d.). Они широко используются для взрывов, дыма, жидкостей, фейерверков и т. д.

Более конкретные понятия

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

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

• Текстура: Изображение, которое может использоваться различными спрайтами, иногда это файлы, которые живут на диске (PNG — это формат текстуры, широко используемый в видеоиграх).
• Игровой цикл: Игровой цикл — это программный цикл, выполняющий 3 основных процесса навсегда (или, по крайней мере, до конца игры): обработка пользовательского ввода, обновление игровых объектов и рендеринг. Может быть выполнено больше процессов, и порядок может варьироваться.
• FPS: Кадров в секунду — это количество раз, которое процессы внутри игрового цикла выполняются за секунду. 24 кадров в секунду достаточно для плавной анимации, но более современные игры могут работать со скоростью более 60 кадров в секунду. Они различаются в зависимости от производительности компьютера, а также от оптимизации игры.
• Шейдер: Шейдеры — это небольшие программы, которые выполняются на фиксированном шаге конвейера графического процессора и используются для постобработки видеоэффектов (Шейдер, n.d.). Тип определяет момент, когда он запускается и чего с его помощью можно добиться.
• Анимация: Это изменение свойства чертежа с течением времени. Например, мы можем перемещать шарик на 3 пикселя влево каждые 1/60 секунды.

Заключение

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

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

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

Ссылки

• Движок игры. (н.д.). Википедия. Получено 4 февраля 2022 г. с https://en.wikipedia.org/wiki/Game_engine
.
• Лин, MC (nd). Обнаружение столкновения. Википедия. Получено 4 февраля 2022 г. с https://en.wikipedia.org/wiki/Collision_detection
.
• Нистром, Б., и Смит, А. Р. (nd). 2D система частиц | [«Двумерная система частиц»]. Виктор Масо. Получено 4 февраля 2022 г. с https://nintervik.github.io/2D-Particle-System/#2-what-is-a-particle-system-and-why-do-we-care 9.0052
• Петти, Дж. (nd). 12 лучших бесплатных игровых движков для начинающих и экспертов. Империя концепт-арта. Получено 4 февраля 2022 г. с https://conceptarttempire.com/free-game-engines/
.
• Рендеринг (компьютерная графика). (н.д.). Википедия. Получено 4 февраля 2022 г. с https://en.wikipedia.org/wiki/Rendering_(computer_graphics)
.
• Шейдер. (н.д.). Википедия. Получено 4 февраля 2022 г. с https://en.wikipedia.org/wiki/Shader
.

лучших движков для 2D-игр, использующих Java, Python для ПК и мобильных устройств в 2022 году — Блог Хемендры Сингха

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

Игры определенно здесь, чтобы остаться!

 

Согласно отчетам, доход мирового игрового рынка в 2021 году составил 178,2 миллиарда долларов. Ожидается, что к 2022 году эта цифра вырастет до 196 миллиардов долларов.97, рост выручки был намного выше за последние семь лет благодаря технологическим достижениям.

 

Разработка игр – это, конечно, не шутки. По сравнению с 2D-играми, 3D-игры требуют часов моделирования и анимации, а также сложного трехмерного кодирования. Обычно они дороже в создании и требуют больше ресурсов.

 

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

 

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

 

Список лучших движков для 2D-игр 2022 года Это бесплатное приложение с открытым исходным кодом, поддерживающее 2D- и 3D-игры. Сообщество финансирует проект через Patreon. Его пользовательский интерфейс похож на Unity. Кроме того, его программирование использует GDScript, язык, подобный Python. Если хотите, можете использовать C++ или C#. Кроме того, среда разработки совместима с несколькими операционными системами, такими как Linux, macOS и Microsoft Windows.

 

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

 

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

 

Unity

Скорее всего, вы слышали об этом. Сейчас это самый популярный игровой движок. Unity в основном используется для создания 3D-игр, хотя его также можно использовать для создания 2D-игр. Он включает в себя большое сообщество с множеством полезных руководств и магазин ресурсов Unity с множеством полезных инструментов и ресурсов для создания игр.

 

Почти 50 % мобильных игр создаются с помощью Unity. Это важно, потому что подразумевает, что у него гораздо больше информации и руководств, чем у конкурентов. Unity не разрабатывалась специально для создания 2D-игр. Проекты 2D-игр иногда могут быть раздуты ненужными инструментами или элементами движка, предназначенными для 3D, и требуют зависимостей или инструментов, не включенных в редактор.

 

Game Maker Studio 2

GameMaker Studio 2 является преемником GameMaker и может похвастаться рядом замечательных функций. Движок может создать целую игру без какого-либо дополнительного программного обеспечения. Он поставляется с довольно мощным движком для создания спрайтов, системой анимации, редактором уровней и многим другим.

 

Благодаря чрезвычайно быстрой установке и простому в освоении языку программирования GMS 2 отлично подходит для быстрого начала работы и разработки игр. Вы можете создавать игры с помощью интерфейса перетаскивания (DnD) или языка GameMaker (GML). Хотя этот язык широко не используется, он связан с Java и C#. Документация подробная и информативная, а также несколько отличных обучающих каналов на YouTube.

 

Solar2D

Solar2D, ранее известный как Corona, — это бесплатный игровой движок с открытым исходным кодом, предназначенный для создания мобильных игр. Однако отдельные лица также могут использовать его для разработки игр для различных платформ. Вам придется использовать Lua для кодирования. Это простой язык, обычно используемый в скромных 2D-игровых движках. Corona особенно важна, поскольку позволяет вам вносить изменения в игру в режиме реального времени, поэтому предпринимаемые вами действия сразу видны.

 

RPG Maker

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

 

RPG Maker идеально подходит для создания игр без программирования, поскольку большая часть игрового дизайна выполняется в редакторе. Скрипты в RPG Maker написаны на Ruby или JavaScript, в зависимости от версии. Он также может похвастаться гостеприимным сообществом с множеством полезных руководств и компонентов, созданных пользователями. Движок может экспортировать в Windows, Android и iOS, среди других платформ.

 

libGDX

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

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

 

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

 

Рен’пи

Рен’пи — уникальный двигатель. Он уникален тем, что построен на популярной теме. Он имеет встроенный язык сценариев, который прост в освоении, с поддержкой Python, если требуется большая сложность. Это бесплатное приложение с открытым исходным кодом, которое экспортируется в Windows, Linux, OSX, Android и iOS с поддержкой HTML 5 в разработке.

 

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

 

Конструкция 3

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

 

Хотя количество пользователей Construct 2 по-прежнему велико, движок регулярно обновляется, а сообщество довольно активно. В целом, это хороший движок для разработки простых игр, которого достаточно для создания коммерчески жизнеспособных игр. Движок поддерживает публикацию на большинстве систем, кроме Switch и PlayStation.

 

Cocos2d

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

 

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

 

Кроме того, вам придется использовать Javascript для Cocos Creator. Документация по этому движку хорошо организована, а форумы оживленные. Хотя этот движок имеет меньше уроков по сравнению с предыдущими, его вполне достаточно для завершения проекта.

 

GDevelop

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

 

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

 

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

 

Заключение

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

 

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