Unreal Engine vs Unity Engine⁠⁠

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

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

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

Также пост имеет одну рекламную интеграцию, ради которой, в сущности, и писался этот пост, т.к. администрация пикабу верно заметила, что плюсики - это не та оплата, которая интересна, чтобы писать крупные, полезные и интересные посты, поэтому прошу отнестить к этому с пониманием, так как данная интеграция дополняет взгляд на проблему. Требования сообщества требуют того, чтобы ссылка была либо в начале, либо в конце поста, поэтому я ставлю её тут: это ссылка плагин для Unity - Fast Data View.

Пост построим по типу: название рассматриваемой части движка + пояснение.

Комфортно-минимальные системные требования

Юнити: видеокарта на 2гб+, 4-8 гб оперативы, проц 2+ ядра на 2.5 ГГЦ+

UE4: видеокарта на 2гб+, 8-16 гб оперативы, проц 4+ ядра на 3 ГГЦ+

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

Оперативная память и её текучесть

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

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

Однако я не заметил, чтобы UE хоть как-то освобождал память самостоятельно в отличии от Unity.

Но у UE есть еще один грех: бывает, что вы откроете какую-то большую сцену и она откроется нормально, потом закроете UE, попытаетесь открыть ииии... он не открывается! Выпадает с ошибкой, потому что оперативной памяти ему не хватило (такое бывает, если ссылочная масса плохая). Приходится очищать Intermediate папку, чтобы не открывало эту сцену сразу. Можно, конечно, установить себе просто 64-128 гб и не ловить таких проблем.

Физические размеры проекта

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

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

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

Примерные размеры движка UE - 70 гб.

Примерные размеры движка Unity - 2 гб.

Но так же папка GIT\SVN и Intermediate в UE весят просто безумно много потому что все предыдущие версии ассетов там хранятся, что позволяет вам смотреть версии блупринтов через Version Check (который, к слову, очень долго грузится. По 2 минуты на каждое открытие, потому что сделано настолько топорно, что тупо грузит все данные что есть, а потом отображает, вместо того, чтобы грузить указанное количество версий ДО). А сами блупринты весят очень много относительно скриптов в юнити, поэтому и размеры проекта отличаются разительно.

Также папка Intermediate есть и в директории проекта и в директории движка и они обе копят мусор бесконечно. Т.е. для нормальной работы в UE вам нужно где-то 300-500 гб. свободных.

GIT\SVN\Система контроля версий

Основная тема, по которой UE просто в салат проигрывает и по которой многие крупные команды просто дропают UE и уходят на другие движки.

Дело в том, что все ассеты Unreal (кроме кода), включая блупринты НЕ МЁРЖАТСЯ. Т.е. если вы изменили что-то в блупринте какого-либо объекта, и кто-то уже изменил его и залил в GIT, то у вас есть возможность либо взять его изменения и по памяти (либо достав автосейв из папки проекта) копировать абсолютно всё, что вы писали и надеятся, что никто в этот момент ещё раз не залил этот ассет, иначе вам придётся всё повторять и снова надеятся, что никто его не изменит.

Т.е. ситуация такая:

ᅠ1. Вы добавляете в блупринт какой-то код минут 10

ᅠ2. Кто-то наверняка что-то залил в гит в это время, поэтому вы закрываете редактор (чтобы залить в гит, потому что с открытым редактором нельзя сделать pull из гита (отдельный лол))

ᅠ3. Делаете pull и обнаруживаете конфликт вашего блупринта - похоже кто-то его изменил! У вас есть вариант: взять вариант из гита (потеряв свои изменений), просто перетереть чужую работу своей версией (этот человек будет не рад до уровня жалобы начальнику, что вы немного оборзели).

ᅠ4. Допустим, вы берете из гита версию. Дальше вы открываете редактор, минут 5 добавляете свои прошлые изменения, еще минуты 2 проверяете, что все работает.

ᅠ5 .Закрываете редактор.

ᅠ6. Снова пытаетесь сделать pull и снова кто-то перезалил файл!

ᅠ7. И вы вот так вот маструбируете ассетом туда сюда, тратя кучу времени и нервов, чтобы залить свою работу.

По моему опыту в работе небольшой командой (6-7 человек) бывало, что приходилось сделать 4 итерации такие, чтобы залить свою работу. А если в команде человек 50? А ведь некоторые сущности Unreal существуют в одном экземпляре, типа GameInstance, GameMode, PlayerController, PlayerState, GameState.

С помощью SVN вы можете заливать свои ассеты без pull-а (т.е. не закрывая редактор), но вы просто перетираете ту версию, которая там лежит (но в SVN сложно с фичами и ветками работать) Т.е. это вариант для дизайнеров, которые сами со своими файлами работают и туда никто не лезет.

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

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

Data view/удобное отображение данных ассетов для геймдизайнеров и программистов

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

Общее:

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

UE:

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

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

Удобно ли это? Нет. Это полная дичь, но вариантов нет. Зачастую, ваша структура будет иметь 20-40 полей (что очень дофига) и каждое поле вы должны будете ручками назначить для переменных. Дичь полнейшая, но других вариантов нет.

Unity:

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

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

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

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

Unreal:
Так как списком в Unreal можно смотреть только структуры, то данные оружия и патронов должны быть в структурах, а потом нужно создать класс, который содержит поле этой структуры и в констракшн скрипте берёт из таблицы эту структуру и назначает её переменной. Т.к. ссылку на структуру дать нельзя и удобно просматривать переменные классов тоже нельзя. Так как в классах от UObject нет Construction Script, то наши Ammo должны лежать в Actor классе.

Т.е. мы создали уже 6 сущностей (структуру аммо, дататейбл, класс, структуру оружия, дататейбл, класс).

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

Скрины:

Unity:
ᅠ1. Создаём класс weapon
ᅠ2. Создаём класс ammo
ᅠ3. Создаём инстансы классов
ᅠ4. Открываем плагин Fast Data View и видим их все в удобном списке с возможностью показать их все сразу рядом и изменить размеры, отображения, видимые\скрытые переменные, сделать выборку переменных из списков и прочее, прочее.

Скрины:

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

У анрила мы создали целых 6 сущностей, список которых можно видеть только в убогом оконце DataTable, вид данных изменять никак нельзя, классы нужно заранее прописывать (т.е. просто так взять любой класс и посмотреть список объектов от этого класса и значения его переменных списком нельзя).

К тому же, так как в c++ нет свойств (get; set), то мы не можем видеть там функции, которые показывали бы суммы каких-то данных, а в Unity мы видим в полях Damage и DamagePerSecond динамически изменяемые свойства (по сути функции, но на скринах не показал их, т.к. в анриле такого нет даже рядом).

Разницы в удобстве и подходе, как по мне, очевидная.

Архитектура

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

Unreal сажает вас на свою собственную архитектуру и подход от которого отойти практически нереально.

У Unity есть ряд сущностей: gameObject, prefab, scriptable object, monoBehaviour components
У Unreal: GameInstance, GameMode, PlayerController, PlayerState, GameState, Pawn, Actor, Character, Child Actor, Actor Component, Scene component, Character Movement Component и еще ряд компонентов со своими особенностями.

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

К тому же, для понимания положения, чтобы перенести какие-либо данные, либо объекты между уровнями нужно сделать следующее:
Unity: добавить на любой gameobject скрипт DontDestroyOnLoad
Unreal: добавить данные в класс GameInstance.

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

Графика\качество картинки итогового продукта

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

Хоть эпики и полностью делают ставку на графику во всех своих разработках и рекламах, графика Fortnite крайне далека от показываемой ими фотореалистичности и детализированности сцены. Т.е. сами эпики своей "супер фотореалистичной" графикой в своих проектах не пользуются. Почему? Вопрос открытый.

Внешний вид редактора

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

Отладка

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

Код

Бытует мнение, что код на ++ более "правильный" для разработки, более православный (не зря же в названии целых ДВА креста), а #, мол, для работяг, потому что на ++ написано большинство движков и игр, но вот моё мнение и аргументы на тему сравнения ++ и #, соглашаться или нет - дело ваше:

ᅠ1. Когда разработка игр набирала обороты и индустрия только появлялась, то # еще только-только появился, поэтому специалистов на нём было мало. Был С и был С++ и люди выбрали С++ из-за ООП и более строгой типизации и меньше шансов себе в колено выстрелить, но у C# в этом всём еще больше строгости и меньше вариантов ошибки. Я считаю, что если бы индустрия появлялась сейчас, то все бы выбрали C#.

ᅠ2. С# на всех проектах одинаковый, С++ на каждом проекте абсолютно разный. Подход к коду в С++ на каждом проекте абсолютно другой.

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

На С# я писал .net приложения, Unity приложения, немного сайты - все практически идентичное, кроме некоторых моментов.

Таким образом, работая с С# на Unity у вас больше возможных путей развития, чем c C++ Unreal.

ᅠ3. Омега душная история с хидерами и PCH в С++. Бывает, что копируешь все хидеры из одного класса в другой, пытаешься использовать функции из них и функции не находит! И ты бесконечно долго сидишь и ломаешь голову почему и как это решить. В C# такой ерунды нет даже рядом, поэтому обучение C# и написание кода идёт намного быстрее. Да и если ты даже немного накосячишь с хидерами в C++, то редактор может начать в разы дольше запускаться, что тоже не круто.

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

Блупринты

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

Зачем он придуман?

ᅠПотому что осилить анриловский код на С++ не только лишь все могут, а так как Unreal - это движок написанный дизайнерами для дизайнеров, то придумали блупринты.

Разработчики утверждают, что вы можете использовать блупринты или код - как захотите. Мол, если вы решили использовать блупринты, то код вам совсем не нужно писать. ЭТО ВСЁ ЛОЖЬ!

Вы обязаны использовать и код, и блупринты. Без вариантов.

Блупринтами вы не сделаете и 10% того, что можете сделать кодом, а от попытки использовать некоторые вещи в коде - вы посидеете.

Минусы работы с кодом:

ᅠ1. Если вы даже немного накосячите в хидерами и ссылочной массой, то код будет компилиться очень долго. Каждый раз при изменение кода вы будете долго сидеть и ждать пока он компильнется.

ᅠ2. Некоторые фичи использовать в коде больно физически. Например, система переводов - она нацелена на использование исключительно из блупринтов.

ᅠ3. Можно косякнуть легко.

ᅠ4. Добавив новый класс нужно ручками нажимать на "Generate Visual Studio project files".

Минусы работы с блупринтами:

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

ᅠ2. Каждая прямая ссылка на каждый объект наращивает ссылочную массу, что повышает время запуска редактора. Если объект ссылается на объект, который ссылается в свою очередь на ссылаемый объект, то время загрузки редактора растёт. Даже если объект будет ссылаться на объект и где-то там в ссылках у этого объекта есть объект, которые ссылается на первый объект, то это повысит время загрузки редактора.

ᅠ3. Блупринты не мёржатся.

ᅠ4. В целом на блупринтах писать дольше, чем обычным кодом.

ᅠ5. Все математические вычисления в блупринтах потребляют больше ресурсов.

ᅠ6. Чтобы функции\переменные были видны в редакторе необходимо их особым способом помечать, поэтому многие вещи изначально скрыты в блупринтах. И для того, чтобы, например, юзать SteamSDK в блупринтах придётся либо пару месяцев писать обёртку под блупринты, либо купить готовый плагин обёртки за деньги (который периодически с обновлением движка ломается).

Почему блупринты в целом порочная концепция?

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

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

Звук

Я бы сказал, что он примерно одинаковый и там, и там, но я с ним не работал, поэтому за достоверность не ручаюсь. Да и по качеству звука оценить разницу не могу, но так или иначе всё равно многие крупные компании выбирают имплементировать Wwise даже при том, что он забирает 5% от доходов.

Расширений редактора

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

Подход к мультиплееру

Изначально, в UE мультиплеер как бы подразумевается как данность, т.е. все объекты имеют плашку сериализации, а все функции можно сразу помечать как мультикасты\серверные\клиентские функции и пр.

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

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

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

Стандартные редакторы материалов\геймобджектов и пр
UE тут побеждает Unity с головой. Во много в UE все эти редакторы более удобные и приятные глазу, чем аналоги в Unity, но функционально всё примерно идентично.

Т.е. в Unreal редактор материалов имеет свой особый интерфейс, а в Unity шейдеры пишутся кодом (хотя вроде бы какой-то похожий редактор для Unity я уже видел), но по итогу это одни и те же шейдеры.

Проблемы в редакторе уровней

В UE есть масса проблем с редактором уровней. Например, используя синглтон какой-либо как эктора, он почему то иногда дублируется на сцену. Т.е. в рантайме появляется объект и когда сцену выключили (по esс), то он почему-то остался. Почему? Неизвестно.

Также бывает, что есть объект имеет на себе много child экторов и этот объект удаляем со сцены, то иногда все эти чайлд экторы не удаляются вместе с объектом, а просто падают в сцену.

В Unity я таких проблем пока не заметил, но не отрицаю, что они могут быть.

Система переводов

В UE есть только одна система переводов, она жестко захардкожена в движок и её никак не вынять и не заменить нормально. Она уже более 3 лет лежит под плашкой "Эксперементальная" и, скорее всего, никогда оттуда не уйдёт из-за того, что в ней много багов, однако, если работать по четко намеченным лекалам, то она вполне жизнеспособна и как-то работает, особенно, если не требовать от неё невероятных вещей, типа "нажал на кнопку и все фразы перевело на все указанные языки через гугл переводчик" и использовать её только через блупринты (не через код, потому что в коде её использовать - это ад).

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

Понятно, что гугл переводчик - это такое, но как placeholder нормальная тема.

Претенциозность платформ

Дело в том, что компания Unreal очень сильно пытается мелькать в информационном поле и во всех около игровых сферах пытается впихнуть своё Я. Например, создали свой магазин и не добавив даже поиска по играм сразу заявили, что они "убивцы стима". Это типичная маркетинговая стратегия анрила - создать какой-то некачественный и недоделанные продукт и сразу начать его рекламить и объявлять всем "войны".

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

Т.е. у Unity позиция:
ᅠEсть мы и вот наш продукт.

Позиция у Unreal:
ᅠМы двигаем индустрию вперёд, ну и что, что у нас тонны багов, зато мы постоянно добавляем новые технологии в движок, ну и что, что они работают кое-как - зато они передовые! А еще у нас магазин убийца стима, которые ориентирован как бы на разработчиков, но по функционалу отстаёт от стима лет на 10, а ещё мы создадим издателя своего и будем платить разрабам за разработку.

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

Вакансии
Вакансий на Unreal всегда намного меньше, чем на Unity. Взяв тот же hh и спросив по вакансиям получаем:
741 вакансий по Unity
186 вакансий по Unreal

Это по всему СНГ, по другим сайтам примерно всё в таком же соотношение.

Магазин ассетов

Магазин ассетов в Unreal в большинстве своём содержит только модели\текстуры и обёртки под блупринты, в отличии от магазина Unity, который содержит абсолютно всё, что можно. Но в этом всё играет роль подход Unity и UE к своим движкам.

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

Стоит отметить, что ряда вещей, которых в Unity изначально нет (но есть в магазине), изначально есть в Unreal бесплатно. Типа изменения цвета папок и пр. Как по мне, то для норм работы с Unity так или иначе 100-200$ выложить на плагины придётся, в отличии от Unreal (возможно, потому что у Unreal особо нечего покупать для удобной работы с редактором).

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

Итог
Unreal-------------------------------------------------------------------------------------------------------------------------------------------------------------

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

Все положительные отзывы об UE4 - это отзывы дизайнеров, моделлеров, создателей шейдеров и так далее, т.е. тех, кто работает только с графикой либо имеет мало опыта в создание игр. Графика - это единственное чем можно похвалиться UE4, но сами же эпики не создают "фотореалистичных" игр.
70% содержаний апдейтов движка - это исправление предыдущих багов, которые зачастую порождают еще баги. К тому же, некоторые баги не могут исправить уже многие годы, по типу добавления поля в BP структуру от которой ломается весь проект, ибо все места, где структура используется вдруг не могут найти эту структуру и приходится изощерятся и молится, чтобы этот баг не словить в очередной раз.

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

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

Создавать какие-либо игры кроме шутеров\платформеров\хорроров на Unreal Engine - это копать овраг чайной ложкой - сделать возможно, но долго и муторно. Так как нет никакой возможности удобно и быстро просматривать и сравнивать статические данные, настраивать баланс, которых в любых РПГ, стратегиях и пр. в разы больше, чем в шутерах.

Unity-------------------------------------------------------------------------------------------------------------------------------------------------------------

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

Unity предпочитают не заливать от своего имени тестовые фичи, предлагая пользователям огромный ассортимент торговой площадки, однако, некоторые вещи из торговой площадки, такие как Text Mesh Pro они включили в стандартные ассеты.

Интерфейс юнити никак не поменялся за последние лет 5. Юнити не хватает тулзов для дизайнеров, которые есть у Unreal, что делает работу визуальных дизайнеров не самой удобной.