По данным портала Vginsights, в 2024 году только 10% выпущенных в Steam игр использовала собственные игровые движки. Остальные перешли либо на открытые решения, либо на лицензируемые движки.

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

1. «Общие». Их всего два: Unreal Engine и Unity. Это лидеры рынка, доля которых растёт и которые доступны для использования любому;

2. «Небольшие бесплатные». Сюда входят Godot, Gamemaker и Ren’Py. Используются эти крохотульки в небольших проектах и не предполагают лицензионных отчислений;

3. «Большие частные». Это большие специализированные решения, не уступающие Unity или Unreal Engine (ну или обладающие сопоставимыми возможностями) основными пользователями которых являются сами разработчики. К ним относятся Source, Frostbite, Creation Engine, ReEngine, Decima.

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

Массовый переход на лицезируемые движки начался примерно в 2012 году и продолжается до сих пор:

Лидером рынка достаточно быстро стал Unity, на котором до сих пор делается практически половина игр. Однако, в последние годы его начал теснить Unreal Engine. Кроме того, путь и небольшой, но стабильный рост показывают GameMaker и Godot.

А вот с точки зрения денег (у нас всё же капитализм, куда без них?) всё не так однозначно:

Тут Unity никогда не был в лидерах, сумев максимально подняться до 27%. Unreal Engine показывал примерно похожие результаты. В общем, игры, которые приносили деньги, большей частью использовали свой собственный движок. Только в 2024 году ситуация изменилась за счёт перехода на Unreal Engine.

Если тенденции продолжатся, то к 2030 году уже 40% проданных копий будет приходиться на игры, сделанные на Unreal Engine. Unity увеличить свою долю если и сможет, то незначительно.

Все на UE5!

Несмотря на постоянно ругаемый Unreal Engine пятой версии, дела у движка идут хорошо. За прошедшие с выхода три года на него пересели уже 72% разработчиков:

Хотя UE5 набирает популярность медленней, чем UE4, он находит применение во всё большем количестве игр. За последний год на UE5 вышли Palworld, Senua's Saga: Hellblade II, Black Myth: Wukong, Tekken 8, Satisfactory и S.T.A.L.K.E.R. 2. В общем, Epic Games железной рукой загоняют всех в счастье.

Больше всего на Unreal Engine делают игры жанров Action RPG, Souls like, FPS, Platformer. Open World Survival Craft и City Builder.

О переходе на решение от Epic Games уже заявил ряд крупных компаний вроде Crystal Dymamics, Respawn Entertainment, CD Projekt Red, Square Enix, Eidos Montreal, Obsidian и ряд других. Причина банальна — развитие своего движка стоит мало того что дорого, так ещё и требует обучения приходящих специалистов.

А бесплатная альтернатива?

Единственный движок, который заметно прибавил популярности за прошедшие годы — Godot:

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

А что там с Unity, кстати?

А с ним всё не слишком хорошо. Сверху его поджимает Unreal Engine, снизу — Godot. С ходу захватив огромный кусок рынка, компания так и не сумела конвертировать его в хороший денежный поток.

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

Если, например, у Epic Games есть Fortnite, на котором оттачивается работа Unreal Engine, то тысячи специалистов Unity смогли осилить только невзрачный ролик на движке:

Сравните это с Warhorse Studio, которая за несколько десятков миллионов долларов коллективом в меньше чем 300 человек смогла выпустить две успешные игры на стороннем движке.

Как итог: компанию накрыли волны увольнений, последняя из которых произошла буквально только что. На мороз отправились очередные сотни людей, включая целые отделы. Понять, что будет с компанией дальше, трудно. Есть вариант, что пухнущая от денег, которые приносит Fortnite, Epic Games приобретёт Unity и станет практически монополистом.

P.S. Ещё у меня есть бессмысленные и беспощадные ТГ-каналы (ну а как без них?):

О науке, творчестве и прочей дичи: https://t.me/deeplabscience

Об играх и игровой индустрии: https://t.me/gameprodev

RPG Maker VX (яп. RPG Tsukuru VX) — программа для создания игр в жанре jRPG и ему подобных без необходимости владеть языками программирования. Релиз продукта состоялся в 2008 году компанией KADOKAWA games Принадлежит к серии RPG Maker. Сильно отличается от предыдущих программ из серии, в особенности улучшенным скриптовым языком RGSS2, старой простой системе маппинга с одним слоем, стилем игр, разрешением и размером ресурсов. Для многих разработчиков является прорывом в данной серии. Также на его базе был создан более совершенный движок VX ACE, который на данный момент является самым популярным из серии, несмотря на наличие новейшей версии — MV.

Ссылка на раздачу:

https://store.steampowered.com/app/220700/

Также имеются бесплатные DLC:
https://store.steampowered.com/app/476041/

https://store.steampowered.com/app/445450/

https://store.steampowered.com/app/329823/

https://store.steampowered.com/app/1076430/

https://store.steampowered.com/app/1691910/

Довел я наконец ядро до состояния "Теперь оно мне даже почти нравится". Избавился вообще от define, вытащил ряд проверок в compile time. Избавился от ряда ненужных сущностей. Добавил несколько новых. Итак: что поменялось.

Добавилось - template контейнер для "правильного" наследования Object. Имеет он такой вид:

,где ClassType - это собственно класс, который мы собираемся написать, BaseObjectBasedClass, класс, от которого будет происходить наследование, с проверкой, что он имеет базовым классом Object и Флаги. Их не много, хотя возможно потом добавятся еще и они определяют поведение класса,. На данный момент они следующие:
None - класс не имеет никаких особенностей (ставится по умолчанию, поэтому можно сказать что None, это когда для класса не указано вообще флагов). Он должен иметь овнера, и он умрет как только умрет его Owner, или по вызову delete
Abstract - Класс является абстрактным (даже если все методы определены). Инстанцию класса невозможно создать никоем образом, но от него можно наследоваться.
RootObject - Этот класс не может быть удален GC автоматически. Нужно его вручную пометить на удаление. Следовательно, Owner ему не обязателен и может быть null. Хорошо использовать в паре с NoInstantiate.
NoInstantiate - Класс не может иметь инстанций. Это означает, что в памяти будет создан только DefaultObject. Такой вот синглтон на стеройдах. Если не указан RootObject, то удалится, если не будет овнера(!).
FreeDefaultNoInst - а вот этот флаг будет играть важную роль в оптимизации проекта. ПО умолчанию политика GC такова, что если мы удалили последнюю инстанцию класса, то в памяти все равно остается болтаться его DefaultObject. Этот флаг переопределяет эту политику, и DefaultObject будет удален вместе с последней инстанцией класса. Из-за особенностей работы флага его нельзя использовать вместе с NoInstantiate и компилятор ругнется если увидит их вместе.
В результате это теперь выглядит вот так:

также, наконец-то, сделал рабочий delete оператор, который работает с GC как ему и положено. Теперь он не очищает память сразу, но сообщает GC, что программист изволил желание объект грохнуть. И GC уже запускает свой танец PendingKill -> Destroyed.

Работа GC так-же была пересмотрена. Был удален Стейт PendingReg. Теперь объекты сразу считаются зарегистрированными и сразу попадают в общий стек. Но, добавился стейт Destroyed, а само удаление теперь проходит в два дополнительных тика движка. В первый тик удаляется сам объект, его отражение в GC получает State Destroyed, а само отражение удалится на следующий тик. Это нужно для того, чтобы не зависимые напрямую от него объекты, могли узнать, что указатель больше не является валидным.

Также добавилась концепция подсистем (Subsystem). Это особые классы RootObject и NoInstantiate, которые имеют дополнительные методы Startup и Shutdown и не требуют явного создания. Они управляют функциональными расширениями движка. Каждая интеграция будет иметь свою подсистему. Рендер, Звук, Сеть, итд. В общем концепт такой: все что не ядро - то подсистема. Это позволит мне менять части движка, можно сказать, на лету, не особо запариваясь с зависимостями. На данный этап есть только одна подсистема Script (для интеграции с Lua).

Собственно над этой интеграцией и работаю прямо сейчас. Подсистема уже через атом Scriptable умеет прокидывать C++ класс через DefaultObject в стек lua со всеми нужными нам методами (указываются явно). Однако есть проблема с вызовом этих методов из lua, надо придумать как типизировать вызываемые объекты и список аргументов так, чтобы их можно было разбирать в runtime (ибо в compile time это не реально, хотя было бы сильно проще).

На будущее еще нужно будет предусмотреть автоматическое создание DefaultObject для Scriptable объектов, чтобы была возможно с ними работать со стороны скриптов, когда в самом движке не было создано ни одного экземпляра нужного класса. Сейчас же, отражение класса в Lua появится только с созданием первой инстанции класса (которое приводит к созданию DefaultObject).