Unreal engine или unity что легче
Unity против Unreal. Какой движок выбрать начинающему разработчику
На рынке инди-игр когда-то доминировал движок Unity, и по сей день он силён в своём сегменте, но постепенно сдаёт позиции Unreal Engine 4. Сегодня мы поговорим о том, почему так происходит и попробуем помочь определиться с выбором сердца вашей будущей игры.
Когда Unity появился на рынке, большинство серьезных движков для разработки игр были платными. Бесплатные программы, такие как RPG Maker, предлагали лишь часть функций, а остальное скрывались за комиссионными. Поэтому, когда мир увидел полноценную и бесплатную альтернативу, многие решили сломить свой страх и заняться разработкой. Unity развивался, предлагая всё больше интересных решений как для 3D, так и для 2D-игр.
Сегодня самый большой конкурент Unity – Unreal Engine, который превратился в ещё одну бесплатную и удобную для пользователей среду.
У двух движков обширные наборы инструментов, включающие редактор ландшафтов, симуляцию физики, анимацию, улученное освещение, поддержку VR и многое другое. Но в последнее время можно заметить, что многие разработчики с небольшими или средними проектами, выполненными в Unity, начинают переключаться на продукт Epic Games. Некоторые даже пытаются делать свои первые полноценные игры на Unreal Engine 4. Почему?
Больший эффект меньшими усилиями
В сегодняшнем стремлении к лучшей графике избалованный ААА-проектами игрок чувствует себя матёрым продюсером, поэтому любой продукт с небольшим бюджетом и без художников с 20-летним опытом считается как минимум посредственностью. Лучший пример – игры-выживания, которые часто выглядят неплохо, но не обеспечивают настолько высокого качества, как у Gears of War, God of War и даже Days Gone. Поэтому, начиная создавать игру, разработчики думают, как добиться крутых эффектов самым простым способом, и здесь однозначно выигрывает Unreal Engine 4. После первого запуска он даёт пресловутый «вау-эффект» с демонстрацией красивого освещения, детализированных моделей и мощных инструментов для изменения графики.
В Unity мы видим грубую, устаревшую сцену. Чтобы добиться хорошего эффекта, похожего на UE4, придётся потрудиться: изменить систему рендеринга с нормальной на HDRP, заменить свет и скайбокс на более приятные. Но даже после трансформации такой же результат не получится. В основном это связано с тем, что Epic, как разработчик движка с 90-х годов, накопила большой опыт и каждый раз создавала что-то новое, а остальным приходилось догонять. Unity больше ориентирован на небольшие проекты, сделанные в основном в 2D и для мобильных устройств.
Простота и интуитивность
Еще одно важное преимущество Unreal Engine 4 – большая интуитивность. Если вы хотите сделать что-то с игрой в программе Epic Games, у вас всегда под рукой есть масса хороших решений, работающих всесторонне по умолчанию. Не нужно беспокоиться о каких-либо дополнительных вещах, которые необходимо загружать или переписывать вручную, чтобы заставить работать. В Unity придётся покопаться в правильных инструментах для создания того же, что в Unreal есть изначально. Где-то потребуется больше работы по программированию, а значит времени и средств.
Не секрет, что большая часть денег на реализацию игры оценивается в количестве рабочих часов хорошего программиста. Поэтому, если у нас ограниченный бюджет (а он обычно ограниченный), хочется сделать как можно больше, не вовлекая дорогостоящего специалиста во все мелочи. В Unity нет такой же массы полезных опций, поэтому подготовка прототипа игровой сцены дизайнером иногда ограничивается тем фактом, что у нас нет нужных вещей, и необходимо ждать, пока кто-то их напишет. В Unreal Engine 4 нужно изучить небольшие правила визуального написания сценариев, и можно делать практически всё.
В качестве примера возьмем две простые вещи: анимацию дверей и поставочную сцену. Чтобы сделать интерактивную анимацию открытия двери в Unity, нужно знать, как правильно запрограммировать такую механику на C#, подключить обнаружение столкновений и подготовить последовательность анимации – это три разных окна и требование знания языка программирования. Также возможна реализация и через инструмент визуального программирования Bolt – летом 2020 года он стал бесплатным.
В Unreal Engine 4 всё, что нужно сделать – создать соответствующий Blueprint (элемент визуального скриптинга), в который можно сразу добавить столкновение, последовательность анимации и подготовить рабочий механизм с помощью нескольких простых подключений. Процесс на двух движках во многом схож.
Второй пример – ролики, относящиеся к игровому процессу. В Unity вы должны ознакомиться с инструментом Cinemachine (предпочтительно в связке с Timeline) – на освоение уйдёт день-два. В UE4 всё, что нужно сделать – открыть инструмент Cinematic, вручную настроить камеру, одним щелчком отделить кат-сцену от остальной части игры, начать запись и простым щелчком сохранить то, что было создано в игровой мир. Буквально за 5 минут (возможно, немного дольше) можно показать раскачивающийся мост, растущие деревья или движущиеся объекты и использовать их в игровом процессе.
Поддержка и удобство
Когда мы создаем что-то в Unreal Engine 4, нужно просто выбрать одну конкретную версию, например, 4.26, и больше не стоит беспокоиться о том, что она будет обновляться каждую неделю и быстро устареет. Когда UE4 получает патч в одной редакции, переход практически незаметен.
В случае с Unity нужно подумать о том, в какой версией мы хотим работать, потому что не каждая получит долгосрочную поддержку от компании. Если это произойдет, патчей будет дюжина, и переход, например, с Unity 2020.1.2 на Unity 2020.1.12 связан с техническими проблемами.
Epic обеспечивает полную поддержку, помогает с решением даже маленькой проблемы и предлагает подробную документацию по своим инструментам.
С Unity всё немного сложнее, и иногда быстрее найти решение через сообщество, чем от самой компании. Кроме того, документация и учебные пособия по Unity могут быть сложными и нечитаемыми, в то время как Epic Games даже финансирует компании, которые создают хорошие учебники для сообщества Unreal Engine.
После приведённых сравнений может показаться, что начинать делать игры лучше в Unreal, но это не так.
Cuphead сделана на Unity
За и против
Если спуститься на уровень кода, то Unity выиграет тем, что это C#, писать на котором легче. У Unity огромное сообщество, и на YouTube можно найти много инструкций, поэтому даже без навыков программирования с помощью этого движка можно реализовать что-то несложное.
UE4 отлично подходит для быстрого прототипирования, больших игр, у него открытый код, но для работы требуются знания в области C++. Большое преимущество – возможность создать полноценную игру практически без кода.
У Unity слегка ниже системные требования, сам движок и проекты на нём занимают меньше места на диске.
Два движка способны выдавать примерно одинаковую графику. Изначально она лучше в UE4, но всё зависит от опыта разработчиков.
С другой стороны, при создании небольших 2D и 2,5D-игр, Unity – лучший выбор, особенно когда речь о продукте с сенсорным интерфейсом. Обратная сторона – закрытый код Unity и без Bolt (инструмент виртуального программирования) нужно научиться программировать. Но обучение относительно простое из-за множества бесплатных и платных курсов.
Как видим, всё зависит от того, какими проектами хочет заниматься студия. Если это мобильная игра в 2D или 2,5D – разработчики явно выберут Unity из-за простоты. Unreal не создавался для 2D-игр и реализация проекта добавит ненужную сложность. Но если планируется файтинг, гонка, серьёзный шутер – предпочтительней выбрать Unreal Engine 4.
Days Gone сделана на Unreal
Мнений по поводу каждого движка уйма и многие субъективны. Оба инструмента мощны и эффективны, а документации по ним много, поэтому однозначно сказать, что у UE4 явное преимущество по всем составляющим, нельзя.
Если вы начинающий разработчик и стоите перед выбором – рекомендуем учиться и творить в Unity. После того, как придёт опыт и захочется создать что-то грандиозное можно переключиться на Unreal – это идеальный движок, если вы хотите выжать максимум из графики и игрового процесса.
Орёл или решка: сравнение 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 против Unity: на чем лучше разрабатывать мобильные игры?
Здравствуйте, уважаемые читатели!
У нас переведена и готовится к выходу книга Джона Хокинга о программировании в Unity, о которой мы уже писали.
А не так давно нам попалась на глаза интересная статья о разработке мобильных игр с применением Unity (от 12 августа 2015 года); правда, ключевое достоинство статьи заключается в том, что в ней этот инструмент сравнивается с основным конкурентом: Unreal Engine.
Именно с этим замечательным исследованием мы предлагаем вам познакомиться в пятничный вечер. В комментариях будем рады увидеть рекомендации по изданию книг о UE, а также надеемся на плодотворную дискуссию.
Статья переведена с небольшими сокращениями
Мы (компания OnlineFussballManager GmbH) в настоящее время приступаем к разработке нового проекта для мобильных устройств. Мы собираемся создать захватывающую и уникальную комбинацию пошаговой стратегии и игры типа «футбольный менеджер».
Игроки смогут планировать и создавать собственные клубные площадки и спортивные комплексы, тренировать команду и работать над ее тактикой. Игроки команды будут не просто юнитами в пронумерованных футболках, а реалистичными личностями со своими чертами и даже выражением лица. Все будет происходить в изометрическом представлении различных помещений и площадок клуба, где анимированные здания будут располагаться в специально определенной сетке.
Итак, момент истины настал, когда мы взялись за разработку визуального представления.
Учитывая поставленные перед нами требования и тот факт, что мы должны разработать эту игру и для iOS, и для Android — как реализовать этот проект технически?
Один из первых вопросов, который предстояло решить — создавать ли собственный движок или воспользоваться уже имеющимся. Разумеется, первый вариант оптимален, если вы желаете полностью контролировать все, что происходит в вашем исходном коде, тулчейне, а также вполне представлять, каковы будут ваши доходы от этой игры. Недостаток такого подхода заключается в том, что подобная разработка потребует немалых усилий — из-за чего сроки всего проекта увеличатся, и он существенно подорожает. От этой идеи мы быстро отказались, поскольку хотели удержать стоимость и сроки проекта в рамках разумного.
Далее предстояло определиться, какой движок будем использовать. Вариантов было множество: от Stencyl, GameMaker до Cocos2d и Marmalade и, наконец, Unreal и Unity.
Конечно, можно привести массу доводов о том, какой движок лучше и для каких целей. Сколько людей — столько мнений. Должны признаться, на какой-то момент и мы ощутили такой субъективизм. Команда активно поддержала Unreal Engine. Однако, сколько мы ни присматривались к UE, никто не мог охарактеризовать его объективно, без апелляции к личному мнению.
Итак, мы решили не отвлекаться от фактов и принялись исследовать другие, более известные инструменты.
GameMaker вскоре был отвергнут, поскольку он более ориентирован на новичков, только приступающих к разработке игр. Таким образом, изучить его довольно легко, но возможности GameMaker явно не дотягивали до того, что мы хотели сделать.
Далее пришел черед Cocos2D, который на первый взгляд казался многообещающим. Как понятно из названия, Cocos2D оптимизирован под разработку двухмерных игр. Поэтому возникал вопрос: хотим ли мы создать нашу изометрическую сетку зданий в истинном 2D или в фактическом 3D с фиксированной точкой обзора. После некоторых дополнительных исследований мы выбрали реализацию в 3D. В таком случае Cocos2D нас, очевидно, не устраивал.
Мы обратились к Marmalade. Ведь при помощи Marmalade были созданы такие известные игры как »Plants vs. Zombies« и »Godus«. Но, хотя мы и нашли у этого движка немало достоинств, оставались проблемы, вынудившие нас обратиться к другим вариантам. Один из наиболее существенных недостатков заключался в том, что сообщество специалистов по Marmalade довольно невелико.
Итак, из крупных альтернатив остались только Unreal и Unity. Но даже к этому моменту мы не могли уверенно выбрать один из двух без посторонней помощи.
К счастью, приближалась игровая конференция GDC в Сан-Франциско, поэтому мы воспользовались шансом слетать туда и посоветоваться с коллегами.
Встретились там с ребятами из Epic, вплотную познакомились с Unreal Engine, попробовали Paper 2D, их инструмент для просмотра превью мобильных приложений и спросили, чем бы нам воспользоваться: их движком или Unity?
Ребята нам удружили, сказав примерно следующее: «Unreal классный, но и Unity неплох. Попробуйте и то, и другое».
Тогда мы отправились к разработчикам Unity и присмотрелись к Unity 5 — как он повышает производительность в iOS. В конце концов, задали им такой же вопрос и получили аналогичный ответ.
На данном этапе мы решились на основательное техническое исследование. Спроектировали прототип, в достаточной степени напоминающий наш проект, чтобы проверить на разных мобильных устройствах, как пойдет процесс сборки и какова будет производительность. При этом мы также хотели выяснить, какие подводные камни и проблемы могут нас подстерегать при разработке на первом и на втором движке.
Поскольку все наши программисты были заняты на текущих проектах, мы поручили работу над прототипом специалистам из компании Bit Baron.
Исследование движков, выполненное в компании Bit Baron
Компания »Online Fußball Manager« (OFM) планировала создать мобильную игру. Нас попросили о помощи, чтобы увереннее определиться, какой движок лучше всего подходит для их проекта. До тех пор мы занимались исключительно разработкой браузерных игр, но решили, что справимся с задачей. Было предложено сравнить два варианта: Unity и Unreal. В настоящее время это два «локомотива» в мире программирования игр. Существует немало отчетов, подробно иллюстрирующих мельчайшие различия между ними. Но особенность нашей работы заключалась в том, что мы написали для сравнения два практически идентичных тестовых приложения и охарактеризовали их показатели в соответствии с системой контрольных точек (эталонное тестирование).
Написав два аналогичных приложения, мы смогли протестировать оба на ровном игровом поле, сообщить OFM, какая версия работает лучше и подчеркнуть дополнительные проблемы.
Мы хотели создать такой эталонный тест, который бы предоставил OFM информацию, непосредственно связанную с типом создаваемой ими игры. Заказчики указали, что в прототипе должно быть несколько анимированных зданий и деревьев. Поэтому мы создали 3D-сцену, где пользователю предлагалось самостоятельно расставлять эти объекты на карте. Размеры сетки составляли 11×16, она вмещала до 176 зданий. Каждый квадрат сетки поддерживал до 6 деревьев, таким образом, в сцене могло быть свыше 1000 деревьев. Мы добавили простой пользовательский интерфейс, где можно было добавить в сцену указанное количество деревьев и зданий. Также добавили функцию добавления зданий в конкретных местах — для этого нужно было щелкнуть по карте в желаемой точке. Что касается организации программы, мы построили сетку на плоскости, а просмотр сцены сделали через камеру, расположенную «над головой» пользователя. Мы также добавили специальный функционал камеры, чтобы пользователь мог масштабировать и панорамировать сцену. Поскольку этот прототип создавался, чтобы определиться с движком для разработки, мы сделали все возможное, чтобы в обоих вариантах сцена выглядела почти одинаково. В противном случае было бы невозможно сравнить визуальное качество первого и второго варианта. Для этого пришлось повозиться, поскольку некоторые вещи обрабатываются в Unreal и в Unity по-разному. В итоге у нас получились две очень похожие сцены.
Чтобы унифицировать тестирование производительности, мы хотели применить в обеих системах идентичные модели деревьев и зданий. Для деревьев использовалась мобильная модель SpeedTree, включавшая как раз около 1000 многоугольников и позволяла хорошо оценить, насколько мелкие инкременты в отображаемых треугольниках сказываются на кадровой частоте. Что касается анимированных зданий, нам не удалось найти для них такую модель, которая работала бы с обоими движками, поэтому мы применили две разные модели. Обе были рассчитаны чуть более чем на 16 000 многоугольников каждая, у них были практически идентичные настройки материалов. Мы полностью отключили уровни детализации (LOD), чтобы в обоих вариантах на любом расстоянии от камеры отображалось одинаковое количество треугольников. Тест проектировался не только с целью отразить различия производительности между двумя движками, но и чтобы показать разницу в качестве рендеринга. Кроме того, приходилось внимательно следить за стандартными шейдерами Unreal Engine. Заметив, что Unreal выглядит явственно лучше, мы обнаружили, что в камере действует ряд шейдеров, затратных с точки зрения производительности. После их отключения сцена визуально почти не изменилась. Освещение представляло совсем другую проблему, поэтому нам понадобилось некоторое время, чтобы довести его до ума.
Заказчики интересовались не только тестами рендеринга, но и тем, каковы будут впечатления от разработки на первом и втором движке. В конце концов, что толку от производительности, если вы не успеваете написать игру в установленные сроки. Чтобы очертить эти впечатления, мы сравнили и такие факторы, как длительность сборки, имеющуюся документацию, сложность развертывания в мобильной среде, а также сложность итераций кода. Мы полагали, что именно по этим показателям Unity будет сильнее (как флагман в области разработки мобильных игр).
Прототип в Unity. На карте нанесено 200 деревьев
Это картинка из редактора Unity. Нам очень повезло, что мы смогли дополнить его нашими собственными сценариями
Значения кадровой частоты 37 против 32. В статистической панели Unity видим оценочные данные для автономного приложения, которые не совпадают с реальными
Вот как проект выглядит в редакторе Unreal. Здесь есть много специализированных вложенных редакторов, некоторые из которых сравнимы по функционалу с целыми программами
В UE сделан такой же экранный снимок, кк и в Unity (см. выше), причем мобильные настройки оставлены по умолчанию, без освещения деревьев
Когда настройки были откорректированы, деревья получились лучше, но все равно не так хорошо, как в Unity
Чертежи превосходны при решении простых задач, их интеграция с C++ просто фантастическая. Но если задействуется более сложная логика, то они быстро приходят в беспорядок, и разобраться с ними становится непросто.
Результаты эталонного тестирования. Кадровая частота
Удивительно, но при тестировании кадровой частоты (FPS) на разных устройствах мы получили очень несхожие результаты. На некоторых устройствах Unity выигрывал при любой конфигурации. В других случаях Unreal обставлял Unity в тех тестах, где было много зданий. В принципе, Unreal выиграл, но дорогой ценой. Качество изображения и согласованность в Unity были существенно лучше. Текстуры Unreal на некоторых устройствах выглядели расплывчато, деревья получались значительно хуже. Разница в качестве была отчасти обусловлена тем, что отображается с одной стороны в редакторе Unreal и мобильном превью, а с другой – на реальном мобильном телефоне. Эта проблема была особенно очевидна, если говорить об освещении сцены. Было очень сложно подобрать настройки так, чтобы правильно настроить свет, весь сеттинг на мобильных устройствах зачастую выглядел затемненно. В этом отношении Unity оказался гораздо последовательнее, изображение на любых смартфонах было таким же, как и при предварительном просмотре в редакторе.
Результаты для обоих движков оказались гораздо лучше, чем мы рассчитывали (как вы помните, в наших тестовых моделях было примерно в 10 раз больше треугольников, чем в обычных мобильных играх).
В iOS оба движка примерно с одинаковым успехом отображали анимированные модели. Однако тесты с деревьями на этом устройстве оказались безрезультатными, поскольку Unreal не отобразил никаких текстур на моделях деревьев. Мы попытались найти причину этой модели, но не смогли ее разрешить. Кроме того, должны отметить, что при развертывании с применением этих движков у вас под рукой должен быть компьютер Apple. Это очень неудобно, но виновата в такой ситуации сама компания Apple. Заказчики также просили нас выполнить эталонное тестирование на Windows Phone. К сожалению, Unreal пока не поддерживает развертывания на Windows phone, поэтому здесь Unity победил по определению. Поскольку пока Windows Phone занимает очень небольшую долю рынка, развитие Unreal в этом направлении не считается приоритетной задачей.
В конечном итоге, эталонное тестирование лишь показало, что два движка почти равны по силе. Поэтому особенно важно обращать внимание на конкретные достоинства и недостатки каждого из них. В конце концов, если производительность настолько близка, то на первый план выходит удобство и скорость разработки для каждого из этих движков.
Другие контрольные параметры
Вот еще некоторые интересные результаты, которые удалось выяснить в ходе наших тестов:
По результатам исследования нам многое понравилось в обоих движках. Кроме того, мы обнаружили много областей, где эти инструменты можно улучшить, чтобы программисту было удобнее работать. Ни один из движков не имел существенного перевеса над другим, учитывая, как быстро изменяются их возможности и поддержка. Тестирование рендеринга показало, что оба продукта выжимают из устройства максимум и, в принципе, вполне сопоставимы. Опять же, в этой ситуации на первый план выходит удобство использования и интуитивная понятность разработки. Учитывая все, что мы узнали об этих движках, и с какими проблемами столкнулись при разработке, мы оказались перед непростым выбором, но в итоге отдали предпочтение Unity.
Несмотря на то, что изначально мы ставили на победу Unreal Engine, в настоящее время Unity все-таки более выигрышный вариант, как минимум, если говорить о разработке мобильных игр.
Вот основные доводы в пользу нашего решения:
Мы хотели бы подчеркнуть, что наши результаты следует расценивать в контексте сделанного прототипа. То, что подходит для одной компании, не подходит для другой. Кроме того, существует еще множество игровых движков, некоторые из которых могут лучше соответствовать вашей конкретной задаче. В некоторых компаниях, обладающих достаточным временем и ресурсами, будет целесообразнее даже написать собственный движок. В разработке игр универсального решения не существует. Окажите себе услугу и поэкспериментируйте как следует. Тем более, что многие из них удешевляются или вообще становятся условно бесплатными как Unreal. Мы не удивимся, если Unity также последует примеру Unreal и либерализует ценовую модель.
Интересно отметить, что и ребята из Bit Barons до создания прототипа советовали нам взять Unreal Engine для нашего проекта. Учитывая, что и мы в OFM изначально отдавали предпочтение Unreal Engine, возможно, итоговое решение оказалось неоптимальным.
Конечно, нелегко спроектировать, написать и протестировать прототип, особенно если требуется просто определиться с движком для проекта. Но вопрос такого выбора критически важен.
Наконец, мы учли еще некоторые факторы, которые могли бы изменить наше мнение. А именно: насколько легко найти опытных специалистов по каждому движку в настоящее время, и каковы имеющиеся в распоряжении бизнес-модели?
По кадровому вопросу мы посоветовались с опытными рекрутерами, чтобы узнать более-менее реальные цифры. В данный момент на каждого специалиста по Unreal приходится примерно четыре профессионала по Unity. Что касается бизнес-модели, Unreal не предусматривает первичного фиксированного взноса, а требует лицензионных отчислений. В Unity все ровным счетом наоборот. Оба упомянутых фактора были для нас важны, и в результате мы все-таки остановились на Unity.