Орёл или решка: сравнение Unity и Unreal Engine
Портал 80.lv опубликовал краткое сравнение самых популярных современных игровых движков — Unity 3d и Unreal Engine 4. Его подготовил инди-разработчик и видеоблогер Jayanam.
DTF публикует перевод статьи.
Первая область сравнения — UI-редакторы для создания уровней, которые, по мнению автора, очень похожи. В них есть браузеры контента для ассетов, скриптов и других файлов проекта. Игровые объекты можно перетаскивать в область сцены и таким образом добавлять в её иерархию.
Объекты в редакторе сцены изменяются с помощью инструментов перемещения, поворота и масштабирования — они похожи в обоих движках. Свойства Unity-объектов отображаются в Inspector, а UE4 — в части Details. Jayanam также сравнивает возможности Unity Prefabs c Blueprints.
В обоих движках есть статические меши (static meshes) — их можно двигать, поворачивать, и масштабировать — и скелетные меши (skeletal meshes) — геометрические объекты, привязанные к костям скелета и используемые для анимирования персонажей. Их можно создавать в программах вроде Blender или Maya.
Анимации, включённые для скелетных мешей, также можно импортировать. В Unity они прикрепляются к импортированному объекту, как клипы анимации (animation clips), а в UE4 называются последовательностями анимации (animation sequences). В первом движения управляются с помощью контроллеров анимации (animation controllers), а во втором по тому же принципу действуют анимационные Blueprints.
В обоих движках есть стейт-машины, определяющие переходы из одного состояния ассета в другое. В UE4 система называется Persona, а в Unity — Mecanim. Также возможно применение скелетных мешей одного скелета к другим, но в Unity это в основном используется для анимирования гуманоидов.
В UE4 анимации можно редактировать, в Unity — практически нет, особенно плохо дело обстоит с движениями гуманоидов. По мнению автора, движки не подходят для профессионального анимирования персонажей — лучше использовать программы вроде Blender или Maya, а результат импортировать в виде FBX-файлов. Прикреплённый к объектам материал добавляется в проект, но его свойства вроде шейдера или текстур придётся применять вручную.
Для этого в Unity нужно задать материалу шейдер и добавить в его слоты текстуры — карты шероховатостей, нормалей или диффузии. Собственные шейдеры придётся писать самостоятельно или с помощью сторонних инструментов вроде Shader Forge или ASE. А в UE4 встроен очень мощный редактор материалов, основанный, как и система Blueprints, на нодах.
Для программирования в UE4 используется язык C++, который не все любят из-за сложности и продолжительности компилирования. Однако Jayanam считает, что у движка понятный API и приемлемый период компиляции. В UE4 очень мощная и проработанная система визуального скриптования — Blueprints, с помощью которой можно достичь практически тех же результатов, что и c C++.
Unity 5 поддерживает языки C# и UnityScript. API и его концепт очень похож на аналог из UE4. При использовании управляемого языка вроде C#, программист не обязан использовать указатели (pointers), компилирование происходит быстро. В Unity нет системы визуального скриптования, и чтобы использовать что-то подобное, разработчик вынужден покупать сторонние дополнения вроде Playmaker.
Для 2D-разработки в Unity есть великолепные инструменты — sprite creator, sprite editor и sprite packer. UE4 также поддерживает спрайты в Paper 2d, но решения из Unity мощнее, кроме того, в последнем есть отдельный физический движок для 2d-объектов.
В UE4 встроен постпроцессинг. К сцене можно применять bloom-эффект, тонирование и антиалиасинг как глобально, так и к отдельным её частям (при помощи компонента PostProcessVolume).
В Unity есть стек постпроцессинга, который можно скачать из магазина ассетов движка. Система менее гибкая, чем в UE4 — эффекты применяются только стеком или скриптами к камере.
Sequencer в UE4 можно использовать для создания синематиков. Это мощный инструмент, работающий по принципу добавления объектов на временную шкалу. К настоящему моменту в Unity 5.6 нет системы для синематиков, но timeline-редактор добавят в Unity 2017.
В заключении автор подчёркивает, что оба движка — мощные, но UE4 более гибок. В то же время, для создания 2D-игры он бы выбрал Unity 5, а вот дорогой 3D-проект с открытым миром делал бы на UE4.
Израильская компания AppReal-VR, занимающаяся решениями для виртуальной реальности, также сравнивала движки, но применительно к мобильной и VR-разработке.
У каждого из движков есть свои сильные стороны для разных задач. Unity подойдёт новичкам и любителям, в то время как Unreal — строго для профессиональных разработчиков.
Набор функций Unreal Engine лучше подходит для трёхмерных проектов, в то время как у Unity огромный послужной список на мобильных устройствах. Если вы собираетесь делать мобильную игру, или у вас VR-проект с небольшим бюджетом — выбирайте Unity. Если же вы делаете дорогую игру для консолей с опытной командой разработчиков — используйте Unreal Engine 4.
А каким был ваш опыт работы с Unity 3D и Unreal Engine 4? Поделитесь в комментариях.
Для VR у Unity более качественный антиалиасинг. В UE4 forward renderer, необходимый для MSAA, поддерживает не все фичи. Для 2D тоже Unity подходит лучше. В остальном у UE4 абсолютный приоритет. Что тут обсуждать, это AAA-движок с большой историей. Многое из того, что он может из коробки, Uniiy просто не поддерживает. Получить качественные шейдеры в нем в разы проще, чем в Unity.
Пытался начинать с юнити. И, честно говоря, мало что понял. При работе с ue4 достаточно быстро разобрался. Но, к сожалению, в решении всех задач приходится ковыряться в иностранных источниках. По юнити материалов гораздо больше.
Короче говоря, два года назад я бы рекомендовал всем юнити, но сейчас рекомендую ue4.
Я начинал делать игру в Unity3d. Купил необходимые ассеты для удобной работы, но в итоге, так и забросил. Для работы в юнити, нужно знать программирование (js, а лучше c#) на хорошем уровне. Другое дело UE4. Блупринты спасут любого, а что то серьёзное можно взять фрилансера.
Фраза "Для работы в юнити, нужно знать программирование" говорит совсем не в пользу UE.
Да, у автора была неточная формулировка, но думаю, это простительно, раз уж «many in the Unity development community (and even in the Unity corporation) refer to UnityScript and JavaScript as if they were equivalent or interchangeable».
Поправили и добавили ссылку, спасибо!
Часто говорят, что там дескать JS, да. Но мне как джаваскриптизеру с десятилетним стажем проще было писать на C#, чем на этом якобы JS. И вот почему:
* Никаких встроенных в JS объектов, функций и API там нет. У массивов, строк и объектов другие свойства и методы. Прокидываются вещи из рантайма юнити, надо искать, что и где.
* Некоторые, казалось бы, очень простые и очевидные, синтаксические конструкции тупо не работают.
* Классы не похожи ни на ES6, ни на TypeScript, ни на CoffeeScript
* Явное указание типов вроде не обязательно, но иногда компилятор в самый неожиданный момент не может вывести тип автоматически и надо идти и прописывать. Опять так декларация типов не совсем такая, как в TypeScript или ActionScript, а как описать сложные типы не всегда очевидно.
* Нет нормального редактора (MonoDevelop таким не является), который бы поддерживал этот синтаксис, подсвечивал ошибки, давал навигацию и так далее (я уж молчу про linting и рефакторинг).
В общем, нельзя просто взять и начать писать на UnityScript. Может быть, если JS (или ActionScript) у вас первый и единственный язык, это проще, чем, скажем, учить C# с нуля, но и то не факт, ибо по шарпу дофигалиард учебных материалов.
Простите за лонгрид и технические подробности, накипело:)
Да и я бы не советовал UnityScript там использовать. Юнитишники сами жалеют, что когда-то его ввели. И каждый раз проскакивают мысли о том, что они хотят выпилить его совсем. Так что, предполагаю, что в ближайшую пару лет они его совсем выпилят и оставят только C#.
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?
Общее:
Вы можете открывать ручками каждый ассет и сравнивать их переменные между собой, имея уйму вкладок на экране. Это очень долго и тупо.
Для хранения систематизированных данных в Анриле есть только 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 Engine — это движок нацеленный исключительно на дизайнеров. Все удобные тулзы — только для дизайнеров. Геймдизайнеры, контентщики, программисты — всем огромную дулю в зубы от эпиков, потому что удобные тулзы не показать в видосике и не получить «Вау» эффект как от очередной итерации графики. Действуя только из соображений маркетинга мы получаем полусырой продукт под подливой передовых технологий, который к тому же захардкожен и закостылен настолько, как будто бы его делали студенты третьего курса.
Все положительные отзывы об UE4 — это отзывы дизайнеров, моделлеров, создателей шейдеров и так далее, т.е. тех, кто работает только с графикой либо имеет мало опыта в создание игр. Графика — это единственное чем можно похвалиться UE4, но сами же эпики не создают «фотореалистичных» игр.
70% содержаний апдейтов движка — это исправление предыдущих багов, которые зачастую порождают еще баги. К тому же, некоторые баги не могут исправить уже многие годы, по типу добавления поля в BP структуру от которой ломается весь проект, ибо все места, где структура используется вдруг не могут найти эту структуру и приходится изощерятся и молится, чтобы этот баг не словить в очередной раз.
Но маркетинговый отдел у Epic работает хорошо. Но всё это выглядит так, будто бы Unity — это нож, который особо в рекламе не нуждается и работает хорошо в большинстве ситуаций, а Unreal — это набор различных приблуд для кухни с AliExpress, который работает хорошо только в рекламных роликах, а когда начинаешь их использовать, то понимаешь, что это мусор, но так как приблуды красивые, интересные и их много, то про них можно рассказывать очень долго в рекламных роликах.
Ни в одной из статей я не встречал упоминания того, что UE очень слабо работает с системами контроля версий, а размер проекта растёт как на дрожжах. Видимо, это считают несущественными деталями.
Создавать какие-либо игры кроме шутеров\платформеров\хорроров на Unreal Engine — это копать овраг чайной ложкой — сделать возможно, но долго и муторно. Так как нет никакой возможности удобно и быстро просматривать и сравнивать статические данные, настраивать баланс, которых в любых РПГ, стратегиях и пр. в разы больше, чем в шутерах.
У Unity проблема с маркетингом. Плохая репутация, обусловленная тем, что для старта он настолько простой, что любой школьник может склепать простой инди-хоррор из бесплатных ассетов магазина.
Unity предпочитают не заливать от своего имени тестовые фичи, предлагая пользователям огромный ассортимент торговой площадки, однако, некоторые вещи из торговой площадки, такие как Text Mesh Pro они включили в стандартные ассеты.
Интерфейс юнити никак не поменялся за последние лет 5. Юнити не хватает тулзов для дизайнеров, которые есть у Unreal, что делает работу визуальных дизайнеров не самой удобной.
Unreal vs Unity или какое "U" выбрать
Всем доброго оборота земли вокруг своей оси в вашей широте и долготе дней. Сей опус будет полезен “Сомневающимся” и поможет пролить немного излучения звезды по имени Солнце на коварную маркетинговую кампанию самых популярных игровых движков. Я занимаюсь разработкой игр уже больше 10 лет, поэтому нескромно могу выразить свое ЛИЧНОЕ мнение о всех достоинствах и недостатках. Добро пожаловать ниже…
Итак, начнем немного с истории. Unreal Engine — движок созданный профессиональной командой разработчиков игр серии Unreal Tournament в 1998 году для создания одноименной игры, а Unity3d в 2005 году профессиональной командой разработчиков, но отнюдь не игр. Целью Unity было создание движка нового поколения, который существенно должен был понизить порог вхождения для новичков в разработке игр и максимально упростить портирование готовых игр на различные платформы. Во главе угла стояла простота использования. Юнити стал по настоящему первым “Народным движком”. Я могу вспомнить ещё несколько популярных на то время, но они все погибли. В то дикое время под каждую игру писали свой собственный велосипед, потому что до Юнити получить готовый движок без огромного количества денег(десятки и даже сотни тысяч долларов) на лицензирование просто не было возможности.
Unity сразу обрел огромную базу фанатов и разработчиков за счет своей простоты и удобства, а Unreal в это время мог оперировать только обученными профессионалами с большим опытом. Порог вхождения в Unreal неприлично высок, чтобы начать программировать игры на нём, вам нужно знать С++ и тонну мелких деталей работы движка, а это не один год обучения на программиста и изучения самого движка. В юнити любой человек не обделенный логикой и азами Pascal сможет написать простенькую игру за неделю. В Unreal на подобное уйдет в 10 раз больше времени и это неоспоримый Факт.
Epic Games (разработчики Unreal) знают свои слабые и сильные стороны, поэтому выпуск Blue Print не заставил себя долго ждать и действительно понизил порог вхождения в UE, но всего лишь для “прототипирования”. Серьезные проекты по прежнему “крайне рекомендуется” писать на С++ со всеми последствиями. На рынке сейчас “на глаз” разработчиков на Unreal 1 к 10 или даже к 20 по сравнению с Unity.
Отсюда следует основной минус UE — Разработка под него на порядок Дороже и Сложнее. Специалистов мало, по факту хороших спецов учат только “уже состоявшиеся спецы” из самой Epic или других крупных контор, которые годами разрабатывают игры на Unreal. Если вы маленькая команда или Indie разработчик, то ваш предел в играх на Unreal это уже готовые мультиплеер FPS стрелялки, по тому что по факту UE был и остается движком для игры Unreal Tournament. Вся логика движка заточена под шутеры от первого/третьего лица по сети. На этом историю закончим, потому что писать об этом я могу часами, далее рассмотрим конкретные примеры работы в каждом движке.
Работа с редактором
Unreal Editor — это просто издевательство над художниками и всеми кто так или иначе связан с созданием арта, звука, анимаций, текстур и прочего. Его основной и гигантский минус — не связанность с файловой системой вашего PC, то есть нельзя просто перетащить файл из папки в папку или даже “О Б-ЖЕ!!” в само окно редактора. Теперь любой файл 3д модели или текстуры вам придется Импортировать с помощью КНОПКИ и никак иначе. Если вам надо немного поменять модель, то вам придется Удалять Руками Импортнутые объекты и Заново их Импортировать столько раз, сколько вы захотите улучшать ваш файл. Реимпорт там конечно “существует”, но он работает настолько нестабильно, что у меня теряется дар речи. Например Vertex Color никогда не реимпортится заново, все созданные клипы анимаций затираются при реимпорте и т д. Если вы не отстрадали своё в этом редакторе огромное количество времени, то готовьтесь к тому что 80% времени вы будете заниматься импортом и реимпортом, а если объектов в вашей локации 100-200-300….
Просто знайте, нельзя нажать кнопку экспорт в вашем любимом 3д пакете и получить всё в том же виде в UE, вам придется каждый объект заботливо расставлять руками, про материалы и прочее естественно забудьте тоже, потому что UE кроме Diffuse+spec+Ao+metallic импортировать ничего не будет, не говоря уже про второй UV канал на назначенной текстуре или тайлинг и прочие подробности. Я страдал достаточно для того чтобы написать свой собственный экспортер из 3ds max Vray в Unreal и потратил на это несколько месяцев лишь бы не мучаться с редактором Unreal. Это позволило переводить сцены с 1000 объектов в Unreal за каких то 30 минут компьютерного времени, но даже это не помогло мне 🙂
Если вы хотите делать мобильные игры, то приготовьтесь к Аду, каждый ребут редактора отключает Mobile Preview режим и вам придется вручную каждый раз включать его заново и ждать пока перекомпилируется весь рендер движок под мобильные устройства, а это занимает несколько минут. Умножьте это на поистине Эпичную стабильность редактора, который может крашится каждые 10 минут, запускается заново несколько минут на топовом железе…
Новые Фичи приходят в движок в таком состоянии, в котором разобраться в них без бутылки зачастую непредставляется возможным, потому что набор галочек и консольных команд для работоспособности “фичи” переходит все разумные границы. Хотите крутую ткань? Волосы? Плоские отражения не пост эффектом ? Будьте добры прочитайте всю документацию 5 раз, и через двое суток с красными глазами вы узнаете, что фича не доступна, пока вы не нажмете галочку в меню о котором даже не слышали ни вы, ни весь чат разработчиков UE в телеграме.
После этого Unity Editor покажется вам МАННОЙ НЕБЕСНОЙ. Это абсолютно понятный, простой в использовании механизм, полностью контролируемый и безусловно его киллер фичей является то, что писать под него плагины можно на самом Unity, а вот написать простейший скрипт в UE редакторе по расстановке объектов — только на С++ используя исходники движка. Отсюда и нереальное количество плагинов для юнити и единицы полезных для UE.
Но при этом UE до сих пор является лидером рынка по Графену, потому что им заведуют всё теже Профессиональные Разработчики Игр, которые двигают индустрию вперед. В Epic Games проблема решается просто — Нужен качественный персонаж? Берем специально обученного человека и даем ему месяц на задрачивание этого персонажа и так с каждым более менее сложным игровым объектом. Студии по разработки на УЕ насчитывает ГИГАНТСКОЕ количество людей, которые работают в редакторе со своими отдельными объектами.
Epic очень богатая контора и она может себе позволить многое: бесплатный движок (в первую очередь для того чтобы хоть как то выращивать новых специалистов для их внутренних потребностей в разработке игр), провальные игры и щедрость с ними связанную (PARAGON) в отличии от Unity, которая перебивается продажами самого движка и подписок, если бы денег было больше, то отставание в графическом плане не было бы настолько заметным, но даже сейчас 2018 версия уже не слишком сильно уступает UE.
Вывод простой, если вы богатый успешный разработчик с большим опытом и уверенностью в себе и вы любите красивую 3д графику и мультиплеер — ваш выбор UE, во всех остальных случаях — Unity.
Надеюсь кому то поможет эта статья, а я могу лишь напомнить, что это моё личное мнение и опыт, некоторые слова можно трактовать как то иначе, потому что выверять каждое предложение и слово у меня просто нет времени. Всем удачи и приятной разработки игр. Помните, что главное в этом деле — это любовь к своей работе, если разработка не приносит вам удовольствия — срочно меняйте работу, движок и всё что угодно связанное с этим. Адьёс Амигос.
Чем отличается Unity от Unreal и о навыках Unity-разработчиков — Вадим Воробьёв
Вадим Воробьёв шесть лет в геймдеве. За это время успел поработать в четырёх игровых студиях, в том числе и в одной из известнейших в Беларуси Vizor Games. Разрабатывал игры и на Unity, и на Unreal.
И теперь Вадим делится своими знаниями с другими как по одному движку, так и по другому являясь инструктором этого курса разработки игр на Unity (а также и на Unreal Engine)
Мы посчитали, что Вадиму есть что рассказать на тему игровых движков, и задали ему пару вопросов.
Приобретенные навыки
Взаимодействовать с игровым движком Unreal Engine 4
Писать код на С++
Программировать на Blueprints
Создавать игры для разных операционных систем
Работать с виртуальной реальностью
Создавать CGI-ролики для кино
Организовывать работу команды
Скидка на обучение
О различиях
Разница между Unity и Unreal Engine 4 фундаментально огромная. И в техническом плане, и в лицензионном, и в финансовом, и в сообществе, но обо всём по порядку.
Анрил появился в 1998 году. В те времена еще не было даже понятия «движок». Ребята просто делали классную игру, которая должна была использовать самые современные возможности компьютерного железа. В этом плане их философия остается такой до сих пор — выжать максимум из железа.
Юнити в этом плане появился в 2005 году — чтобы делать игры на компьютерах от Apple и для компьютеров от Apple. И на волне смартфонов ребята быстро оседлали волну технологического прогресса под лозунгом «чем больше платформ, тем лучше».
Историю выше надо знать. Потому что эти вещи легли в основу философии обоих компаний. Компания Epic Games зарабатывает тем, что делает и продает игры. Компания Unity Technologies зарабатывает тем, что делает и продает игровой движок. Это объясняет и разницу между экосистемами.
Unity — движок для всех. Компания предоставляет кучу сопутствующих услуг: формальное обучение и сертификаты, соответственную аналитику и рекламу.
Epic Games — движок для выжимания технологического максимума. С продвижением в массы у них поскромнее, но зато есть гранты. Они просто дают денег тем, кто им понравится.
В плане работы юнити сделан простым, а анрил — эффективным. Это прослеживается в работе с файлами, в том как пишется игровая логика, даже в том, как выглядит стартовый проект.
Одно из важных отличий — система блюпринтов в анриле, мол «можно делать игру без программиста» и «можно делать шейдеры без программиста». Это был огромной фичей, но её скоро не станет. Unity совсем недавно добавила аналогичную возможность, или вот-вот добавит.
В интернете часто можно встретить заявление «Юнити для мобилок, анрил для пк и консолей». Противоречивое утверждение, и может даже устаревшее. Unity в последнее время сделали довольно много для 2D-игр. Но и для улучшения картинки и производительности они сделали немало. Unreal же давно обзавелся 2D-инструментами, просто их редко используют.
О взаимодействии
Для работы с Unity надо знать две небольшие вещи: язык программирования C# и сам движок. С# нужен для создания скриптов. Иначе говоря, чтобы сделать что угодно — это нужно написать на С#.
В Unreal надо взаимодействовать с одним большим — с самим движоком. Он похож на кухонный комбайн с тысячью функций. И выучить несколько маленьких вещей всегда проще, чем одну большую.
Обратная сторона медали в том, что без программирования в Unreal можно сделать достаточно много, и не обязательно изучать весь комбайн. Скриптинг в Unreal делаются с помощью их визуального языка — Blueprints. Но На С++ можно писать и игровую логику, и расширения для движка.
В том же Fortnite к примеру 80% игровой логики написано на блюпринтах, и оставшиеся 20% на С++ . В Unity же 100% игровой логики пишется на C#. И из этого вытекает второе различие.
В индустрии часто случается так, что если команда разрабатывает на Unity, то с движком работают только программисты. Художники и геймдизайнеры предоставляют им контент и сами движок вообще не трогают. Иногда даже доходит до такого, что в отделе появляется «специалист по вставлению контента в движок».
С Unreal же работает вся команда — художники, которые сами вставляют в движок контент, и геймдизайнеры, которые сами пишут правила игры на блюпринтах. Так происходит не во всех студиях, но движок способствует такому подходу.
О возможностях
Поговорим о стандартной работе по найму — офис, полный день. Unity с этой позиции конечно более актуальный. Если открыть список объявлений, то соотношение вакансий на Unity и на Unreal будет примерно 8 к 1.
Обратная сторона медали — проекты. В них куда меньше романтики. Чаще всего это мобильные проекты, типа три в ряд или ферма-ферма. В работе на большую компанию всегда так: есть вещи, которые работают, а есть непроверенные, и неизвестно как они себя поведут.
Забавный факт: опытные разработчики игр на Unity могут перекочевать на роль Unreal-специалиста — и наоборот. Рынок в этом плане гибкий.THE GODLIKE Alpha Version In-Game Footage
Вадим работал над сетевым кодом The Godlike. Под его руководством были еще два разработчика.
Если говорить про стартап, когда ты сам собираешь команду энтузиастов и делаешь то, к чему лежит душа — то у Unreal Engine потолок возможностей выше.
Во-первых, есть гранты, о которых я упоминал. Если проект прям классный — Epic Games могут отсыпать денег и помочь с технической стороны.
Во-вторых, у Unreal есть свой магазин игр, Epic Game Store, в котором хорошие условия для разработчиков.
Ну и раз уж речь о деньгах, то Unreal просто берут 5% от выручки, если вы зарабатываете больше 3000$ за 3 месяца. Unity в этом плане условно-бесплатный. До 100000$ в год они ни просят ничего, но потом нужно платить минимум 480$ в год за каждого члена команды.