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

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

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

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

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

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

Кроме того, вы должны обязательно учитывать свой собственный опыт и цели при взвешивании всего этого. Если у вас нет большого опыта в создании игр, вам будет гораздо труднее сделать движок (и вам обязательно нужно получить некоторый опыт в создании игр, прежде чем пытаться сделать движок в любом случае). Если вы хотите заниматься 3D, вам будет гораздо труднее, чем просто делать 2D.

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

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

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

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

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

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

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

• Инициализация системы : открытие окна, получение контекста OpenGL/DirectX/Vulkan, инициализация звука. SDL справится со всем этим за вас, так что просто используйте SDL. На самом деле, SDL на данный момент является отраслевым стандартом для пользовательских движков, поэтому нет причин делать эту часть самостоятельно.
• Управление синхронизацией кадров : Вы хотите, чтобы ваша игра работала со скоростью 60 кадров в секунду, поэтому вам нужен какой-то таймер и цикл, который контролирует, когда происходят обновления и рендеринг.
• Ввод : Вы должны уметь реагировать на нажатия кнопок. Есть много разных способов реагировать на нажатия кнопок, может быть, вы просто хотите иметь возможность запрашивать текущее состояние кнопки, или, может быть, вы хотите регистрировать события, это не имеет большого значения. SDL сообщит вам о вводе кнопок, если вы уже используете его для инициализации системы, вы должны использовать его и здесь. Вы можете построить действительно мощную и гибкую систему ввода поверх этого, но сначала нет необходимости делать что-то большее, чем основы.
• Рендеринг : Большинство игр, как минимум 75%, так или иначе используют графику, и это абсолютно то, за что должен отвечать ваш движок. Если вы делаете 2D-игру, минимальный рендерер просто должен иметь возможность отображать на экране простые текстурированные четырехугольники. Шейдеры, буферы вершин, цели рендеринга, меши, материалы и многое другое — все это прекрасно, но они могут появиться позже, когда они вам понадобятся. Если вы хотите запачкать руки OpenGL или Vulkan или чем-то еще, вы можете полностью отказаться от своего собственного рендерера, но опять же, нет ничего постыдного в использовании существующей библиотеки, такой как Ogre3D, для покрытия рендеринга. Всецело зависит от ваших целей и потребностей, а также от того, какие проблемы вам действительно интересно решать.
• Математика и прочее Утилиты : я не считаю «векторы и матричные математические вычисления» полной «системой», но это то, что вам, вероятно, следует иметь в качестве библиотеки утилит, к которой имеют доступ как движок, так и код игры. Плюс любые другие случайные полезные функции и формулы, которые вы найдете в процессе разработки. STB — невероятно отличный ресурс для случайных утилит, которые могут вам понадобиться.

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

• Управление игровыми объектами/сценами : Кодирование всего в одной большой функции обновления на самом деле не так уж плохо, как кажется, но если ваша игра становится хоть немного сложной, вам понадобится какая-то система для обрабатывать отдельные игровые объекты и наборы игровых объектов. В каком-то смысле это оказывается самой важной системой в вашем движке, поскольку именно она управляет логикой вашей игры. Являются ли ваши объекты большими деревьями наследования? Состоят ли они из более мелких компонентов? Вы используете ЭКС? (примечание: вам, вероятно, не следует использовать «чистую» ECS, если у вас нет действительно конкретного варианта ее использования) На какие типы событий они реагируют? Как вы запрашиваете другие объекты для взаимодействия? Вы заботитесь о структуре памяти? Это все, что должна охватывать ваша система управления игровыми объектами/сценами. Для этого есть несколько существующих библиотек, особенно для чистой ECS, однако, поскольку это система с больше всего влияет на то, как выглядит код вашей игры, здесь я склоняюсь к принципу «сделай сам». Использование существующего решения заставит вас постоянно думать о том, как вписать логику вашей игры в эту форму. Точно в обратном направлении от того, что вы обычно хотели бы. Вы хотите, чтобы ваш движок был разработан для поддержки того способа, которым вы хотите выразить игровую логику, а не наоборот.
• Аудио : Звуковые эффекты и Музыка здесь представляют собой отдельные системы, хотя обе объединены в «Аудио». Основные функции, которые вам нужны, — это возможность запускать и останавливать звуковые циклы (музыку) и возможность полностью воспроизводить отдельные звуковые эффекты. Аудио — это гораздо больше, чем просто это, но вы можете продвинуться очень далеко, используя только основы. Раздражает то, что стандартные отраслевые звуковые фреймворки (FMod и Wwise) являются коммерческими и имеют множество лицензионных ограничений, но многие из них с открытым исходным кодом просто очень раздражают в использовании (привет OpenAL). Лично я нахожу FAudio довольно простым и довольно замечательным, и я использую его как основу для построения более сложного поведения.
• Загрузка файлов и управление ими : Все игры должны загружать файлы. Вам нужен способ загрузки файлов. Вы, вероятно, не хотите повторно загружать/декодировать файлы, которые уже были загружены, поэтому вам нужен какой-то базовый менеджер, который обрабатывает все это. Возможно, вы захотите иметь возможность создавать поддержку модов или динамическую загрузку/выгрузку или что-то еще, пока у вас есть основы здесь и когда-либо загружаете файлы только через файловый менеджер, вы можете легко добавить любые другие функции, которые вы хотите в это позже. Вам не нужно это немедленно, так как вы можете просто использовать встроенную загрузку файлов в качестве заполнителя, но в конечном итоге вы захотите иметь систему управления файлами / ресурсами, как только вы начнете использовать файлы чаще.
• Сеть : Хорошо, работа в сети (сетевой многопользовательский режим) ОЧЕНЬ необязательна (если вам не нужен сетевой многопользовательский режим, не беспокойтесь), однако это исключительно сложная система, которую можно прикрепить к движку, который не был разработан с учетом многопользовательской игры. , так что если вы делаете многопользовательскую игру, вам нужно подумать об этом заранее, потому что само ее существование влияет на дизайн буквально каждой другой системы.

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

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

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

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

Сразу к делу: Делайте игру одновременно с созданием движка . Это нерушимое правило. Единственное нерушимое правило. Изучите основы как можно быстрее, а затем сразу же приступайте к созданию игры на их основе. Движок ничего без игры.

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

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

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

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

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

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

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

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

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

В поисках идеального игрового движка 2D

Прошло много времени с тех пор, как я в последний раз делал игру с помощью Flash, и почему-то я хочу сделать это снова для удовольствия. Но я действительно поражен выбором игровых движков! Их много, и почти все они доступны. Теперь вы можете бесплатно разрабатывать и публиковать игры на Unreal Engine. Это что-то трудно представить десятилетие назад. Как изменилась индустрия.

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

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

Так почему я не собираюсь просто использовать Юнити?

Потому что это не всегда оптимально в определенных случаях использования. например (в моем случае):

• Слишком сложно для моих нужд. Конечно, это мощно, но для простой игры это перебор. Требуется некоторое время, чтобы изучить способ работы с Unity. Они также быстро развиваются, например: недавний переход на новую архитектуру под названием DOTS, которая является более сложной, но также запутанной для новичка.
• Не лучший в 2D. Хотя 3D — это здорово, инструменты 2D значительно улучшены, но есть и другие движки, которые делают 2D проще и компактнее.
• Большой размер файла сборки.
• Заставка в бесплатной версии. Я абсолютно согласен с заставкой. Однако у некоторых людей игры Unity с заставками имеют плохую репутацию низкокачественных игр. Надеюсь, это не тренд.
• C#, я просто плохо с ним знаком
• Производительность на бюджетных устройствах
• Веб-сборка плохо работает на мобильных устройствах 

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

• 2D гиперказуальные игры
• производительный движок с минимально возможным размером сборки,
• скриптовый язык, который проще и удобнее в использовании.
• html5 в качестве основной платформы и вторая андроид.
• Я также ценю возможность создавать apk одним щелчком мыши без использования компиляции или собственных мобильных инструментов.
• бесплатно. Предпочтение отдается открытым исходным кодам. Таким образом, нет никаких первоначальных затрат и гибкости, чтобы пожертвовать / внести свой вклад в разработку.
• Support Metal, в случае необходимости выпуска на платформе Apple.

Soo после некоторых первоначальных исследований Моими лучшими кандидатами являются: Godot, Defold, Cocos Creator и Solar2D.

Годо

Этот двигатель В последнее время становится очень популярным. это как версия единства с открытым исходным кодом. Я часто читал, что он делает 2D лучше, чем Unity. Godot — это полностью открытый исходный код с наиболее разрешительной лицензией.

Основным языком является GDScript (подобный Python), но также поддерживаются C#, C++ и т. д. Различные языки имеют разную зрелость и производительность. Большинство из них являются усилиями сообщества.

Многофункциональный, поддерживает 2D и 3D. Редакторы тоже приятные, маленькие и быстрые. Много батареек в комплекте. Имеет встроенную анимацию/кость, редактор тайлов и т. д. Он также расширяем.

Документация хорошая. Есть также много статей и учебных пособий на YouTube.

Размер сборки APK составляет около 7,1-11,8 МБ (модули могут быть удалены при компиляции). Для html5 наименьший (сжатый) составляет около 2,9 МБ.

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

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

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

Defold

Defold — игровой движок на основе Lua с визуальным редактором. Просто в этом году получил «открытый аутсорсинг», что делает его еще более привлекательным.

Он был частью King (компания, разработавшая суперпопулярную Candy Crush Saga), но теперь является независимым фондом Defold Foundation.

Возможности кажутся ограниченными, но тщательно отполированными, и обратите внимание на высокую производительность/низкие накладные расходы двигателя. размер сборки впечатляет. Сборка html5 весит всего около 800 КБ (сжатый gzip). размер apk ~1.7mb.

Документация хорошая. Это требует от нас следовать способу дефолта (например, передача сообщений между объектами).

Для достижения зрелости Kings используют его в некоторых своих популярных играх (однако Candy Crush Saga использует другой движок). Так что Дефолд как бы проверен в бою в этом масштабе.

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

Cocos Creator

Я попробовал Cocos Creator и пока у меня хорошее впечатление. Я просто не знаю, почему так сложно найти статьи/ресурсы об этом движке. Может быть, это популярно только в Китае. Это от создателя популярного движка Cocos2d-x, но с Visual IDE аля Unity и использует javascript. Я знаком с этим языком (он также поддерживает Typescript), так что для меня это плюс. Редактор/IDE основан на Electron, без официальной поддержки Linux.

Оптимальный размер сборки для HTML. всего ~ 155 КБ в сжатом виде, так как он использует собственный js. Идеально подходит для мгновенных игр Facebook или встроенных игр приложения чата. Самый маленький apk, который я могу получить, составляет около 6 МБ. 11 МБ, если включить библиотеку armv7 и arm64bit. Обратите внимание, что он создает настоящее нативное приложение для мобильных устройств. Не только гибридные приложения, такие как Apache Cordova.

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

IDE не пытается делать все. У него даже нет встроенного редактора кода. Он довольно хорошо интегрируется с внешним редактором кода, таким как VS Code, и популярными сторонними 2D-инструментами, такими как tiled и dragonbones/spine.

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

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

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

Почетные упоминания

Corona SDK/Solar 2D

Solar2D — это ответвление Corona SDK с открытым исходным кодом. Который, к сожалению, прекратил свою деятельность в этом году, это не имело никакого отношения к пандемии COVID, но рад, что они изменили название. Когда он был еще коммерческим, заставка была обязательной для бесплатной версии, и на ней было написано: «Corona, powered by Corona Labs». Только представьте реакцию вашего игрока, когда он увидит его в 2020 году. 

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

Solar2D использует Lua. размер сборки в порядке, я забыл, вероятно, около 6 МБ APK как для armv7, так и для 64-битной версии. Я сделал простую игру с ним. Никаких проблем с производительностью, даже на бюджетных устройствах.

Сообщество небольшое, но приятное. У них есть форум и Discord.

Минусы, хотя сборка html5 поддерживается, это все еще бета, так что есть подводные камни. Версия Vulkan/Metal тоже не готова, но я думаю, что она все еще работает.