[Перевод] Unreal против Unity: на чем лучше разрабатывать мобильные игры?23.10.2015 17:48

Здравствуйте, уважаемые читатели!

У нас переведена и готовится к выходу книга Джона Хокинга о программировании в 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-сцену, где пользователю предлагалось самостоятельно расставлять эти объекты на карте. Размеры сетки составляли 11x16, она вмещала до 176 зданий. Каждый квадрат сетки поддерживал до 6 деревьев, таким образом, в сцене могло быть свыше 1000 деревьев. Мы добавили простой пользовательский интерфейс, где можно было добавить в сцену указанное количество деревьев и зданий. Также добавили функцию добавления зданий в конкретных местах — для этого нужно было щелкнуть по карте в желаемой точке. Что касается организации программы, мы построили сетку на плоскости, а просмотр сцены сделали через камеру, расположенную «над головой» пользователя. Мы также добавили специальный функционал камеры, чтобы пользователь мог масштабировать и панорамировать сцену. Поскольку этот прототип создавался, чтобы определиться с движком для разработки, мы сделали все возможное, чтобы в обоих вариантах сцена выглядела почти одинаково. В противном случае было бы невозможно сравнить визуальное качество первого и второго варианта. Для этого пришлось повозиться, поскольку некоторые вещи обрабатываются в Unreal и в Unity по-разному. В итоге у нас получились две очень похожие сцены.

Чтобы унифицировать тестирование производительности, мы хотели применить в обеих системах идентичные модели деревьев и зданий. Для деревьев использовалась мобильная модель SpeedTree, включавшая как раз около 1000 многоугольников и позволяла хорошо оценить, насколько мелкие инкременты в отображаемых треугольниках сказываются на кадровой частоте. Что касается анимированных зданий, нам не удалось найти для них такую модель, которая работала бы с обоими движками, поэтому мы применили две разные модели. Обе были рассчитаны чуть более чем на 16 000 многоугольников каждая, у них были практически идентичные настройки материалов. Мы полностью отключили уровни детализации (LOD), чтобы в обоих вариантах на любом расстоянии от камеры отображалось одинаковое количество треугольников. Тест проектировался не только с целью отразить различия производительности между двумя движками, но и чтобы показать разницу в качестве рендеринга. Кроме того, приходилось внимательно следить за стандартными шейдерами Unreal Engine. Заметив, что Unreal выглядит явственно лучше, мы обнаружили, что в камере действует ряд шейдеров, затратных с точки зрения производительности. После их отключения сцена визуально почти не изменилась. Освещение представляло совсем другую проблему, поэтому нам понадобилось некоторое время, чтобы довести его до ума.

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

Проект Unity

Прототип в Unity. На карте нанесено 200 деревьев

Хорошее

Основные элементы Unity – это объекты (»GameObject«) и компоненты (»MonoBehaviour«). Освоив эту концепцию, вы уже можете работать с Unity. Если правильно пользоваться этой системой, она позволяет значительно улучшить организацию проекта.
В Unity включено много компонентов, обеспечивающих вас всем необходимым для создания игры – кроме игровой логики как таковой. Как было указано выше, компонент может быть таким маленьким, как Plane (в Unreal отсутствует), который мы использовали для построения сетки. Новейшие дополнения движка — компоненты »UI« и »Layout«, обеспечивающие создание мощных и масштабируемых графических пользовательских интерфейсов.
Редактор можно расширять собственными сценариями, кроме того, в Asset Store доступна масса ресурсов на все случаи жизни. Хранилище Asset Store также содержит множество полезных сценариев, моделей материалов и пр. Они будут особенно кстати при прототипировании — можете просто загрузить все необходимое в виде временных ресурсов и пользоваться этим как подручными имитационными моделями.
Unity был одним из первых общедоступных движков, поддерживавших мобильную разработку. Поэтому он очень удобен при развертывании в мобильной среде, выглядит и действует там практически так же, как и в редакторе. Система постоянно совершенствуется, и развертывание протекает очень гладко. Это был существенный фактор, благодаря которому мы решили делать мобильный прототип.
Пожалуй, Unity может похвастаться самым широким сообществом специалистов среди всех игровых движков, поэтому если у вас возникнет вопрос — скорее всего, ответ на него найдется. Пусть Unity и поддерживает множество языков для написания сценариев, документация по каждому из них очень основательная. Более того, даже если вы найдете ответ, касающийся другого языка, логика этого ответа будет вам, тем не менее, понятна, и вы сможете адаптировать ее для решения своей проблемы.
В Unity проделана огромная работа по оптимизации рендеринга для множества однотипных объектов. Чтобы добиться сопоставимой производительности в Unreal, пришлось бы задействовать Instanced Rendering, а этот механизм обычно менее гибок, чем рендеринг в Unity.

Плохое

Исходный код движка закрыт. Если вы обсуждать с Unity цену исходного кода, то с этим придется смириться. Поэтому возможны проблемы, если откажет та или иная возможность, на которую вы полагаетесь — придется ждать обновления.
Новая система UI вполне хороша. В ней отсутствует специальный редактор, все изменения вносятся прямо в сцене — а сцена-то очень большая. Когда вы открываете сцену и хотите отредактировать UI, вам сначала придется изрядно увеличить масштаб интересующей вас области.

Это картинка из редактора Unity. Нам очень повезло, что мы смогли дополнить его нашими собственными сценариями

Ужасное

C новой системой UI в Unity есть две проблемы. При нажатии пальцем по сенсорному экрану вы не сможете определить, был ли нажат конкретный графический элемент. Допустим, пользователь хочет панорамировать экран при помощи слайдера. Но если мы наследовали класс GraphicsRaycaster, то можно открыть любые желаемые данные, которые могут быть сделаны общедоступными. Если заменить GraphicsRaycaster в объекте холста, то можно проверить, был ли нажат элемент UI.
Вторая проблема с пользовательским интерфейсом Unity связана с масштабированием под дисплеи различного размера. В принципе, у объекта холста есть опции масштабирования с некоторыми параметрами. Но организовать их предпросмотр было очень сложно, пришлось несколько раз развертывать приложение на устройстве, пока мы не подобрали нормальную конфигурацию.
Кроме того, нас очень озадачила статистическая панель Unity. Реализовав внутриигровой счетчик кадровой частоты, мы сравнили его значение с тем, что выводилось на статистической панели редактора Unity. Эти значения отличались. Поискав в Интернете другие варианты реализации, мы нашли ответ: статистическая панель дает оценку того, сколько кадров промотала бы игра, если бы работала автономно, а не в редакторе. Поэтому логика нашего счетчика кадров была совершенно правильной.

Значения кадровой частоты 37 против 32. В статистической панели Unity видим оценочные данные для автономного приложения, которые не совпадают с реальными

Проект Unreal

Вот как проект выглядит в редакторе Unreal. Здесь есть много специализированных вложенных редакторов, некоторые из которых сравнимы по функционалу с целыми программами

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

Когда настройки были откорректированы, деревья получились лучше, но все равно не так хорошо, как в Unity

Хорошее

Пробная версия Unreal совершенно бесплатная. В ней вы получаете полнофункциональный редактор. В Unity также есть бесплатная версия, но переход на Pro обойдется в кругленькую сумму.
В Unreal есть мощный редактор, заключающий в себе несколько узкоспециальных редакторов. Если вы знакомы с этими «вложенными» редакторами, то они очень помогут вам в разработке, а зачастую предоставят и такую информацию, которой в Unity вы не увидите. Есть редакторы, которые даже могут послужить полноценной заменой некоторым программам. Взаимодействие всех этих подсистем — просто шедевр.
Движок поставляется вместе со всем исходным кодом. Поэтому в нем можно покопаться и понять, как функционируют отдельные детали. Более того, вы даже можете исправлять баги в движке или самостоятельно дополнять его функционал.
Визуализация в редакторе великолепна. Просто глаза разбегаются от изобилия опций рендеринга (связанных, например, с освещением или со сложностью шейдеров). Здесь вы найдете массу ультрасовременных шейдеров, которые также поставляются вместе с движком. В принципе, Unreal предлагает наилучший механизм рендеринга на рынке. Можно создавать удивительно красивые сцены.
Чертежи (blueprints) удобны для того, чтобы быстро создать что-нибудь простое и реализовать базовую игровую логику. Они превосходно интегрируются с C++, и такое решение принято неслучайно: оно не только открывает широчайшие возможности как для начинающих, так и для опытных разработчиков, но и позволяет им взаимодействовать друг с другом.
Общая интеграция с C++ великолепна. Как и горячая перезагрузка.

Чертежи превосходны при решении простых задач, их интеграция с C++ просто фантастическая. Но если задействуется более сложная логика, то они быстро приходят в беспорядок, и разобраться с ними становится непросто.

Плохое

При разработке на Unreal Engine сложно набрать темп. Даже если вы отлично знаете C++, потребуется немало времени для изучения различных макросов и функций UE4. Это может быть очень сложно для тех, кто одновременно занимается изучением C++.
В чертежах можно очень быстро запутаться. Когда логика включает десятки узлов, в каждом из которых находится чертеж, то ее иногда удается упростить до пары строк кода, написанных на обычном C++. Обычно это не проблема, поскольку вполне можно работать и с C++, но с некоторыми вещами, например, »UMG« (система UI) использовать чертежи необходимо, поэтому и возможна путаница.
Мобильный симулятор оказался очень непоследовательным. Он выдавал предупреждения, когда мы пытались использовать шейдерные функции, не используемые в мобильной среде, но даже если шейдер проходил валидацию, то мог не сработать. В принципе, этот симулятор – хорошая вещь, но его визуальные качества оставляют желать лучшего.
Хотя Unreal и обладает большим сообществом разработчиков, мы редко получали там ответы на вопросы. Кроме того, почти вся оказанная нам поддержка касалась чертежей. has a big community, we rarely got any answers to our questions. Additionally, nearly all of the Unreal Engine 4 активно наращивает сообщество, это уже удается неплохо, складывается ощущение, что специалисты стремятся развиваться и помогать. Но сообщество Unity все-таки лучше.

Ужасное

Серьезно не хватает документации по C++. Онлайновый справочный материал по классам C++ неудобен. Кроме того, из-за постоянных обновлений многие возможности быстро устаревают. Будьте внимательны, просматривая справочные видеоролики, поскольку там может описываться неактуальная версия движка и функции, которые больше не используются.
Работая с GUI, мы использовали инновационную систему »UMG«. Она основана на чертежах и может быть очень полезна. Немного поработав, нам удалось унаследовать класс C++ и немного навести порядок с чертежами. Однако система по-прежнему сырая, в ней недостает некоторых элементов управления, например, кнопок-переключателей. Кроме того, соответствующая документация по C++ практически отсутствует. Редактор несколько раз отваливался, пока мы разрабатывали UI. Неожиданные отказы могут стоить целых часов рабочего времени, они изрядно нервируют. Разработка этой системы продолжается, но пока она далека от совершенства.
Мобильная разработка с Unreal медленная. Программа развертывается на устройстве очень долго. В Android возникали некоторые визуальные проблемы — например, там были расплывчатые очертания и неосвещенные деревья. В iOS проблемы были гораздо серьезнее. UE4 поддерживает сборку для устройства с iOS лишь при условии, что ваше приложение состоит только из чертежей. Это вина Apple, но мы проделали весь путь по импорту ключей разработки (можете себе представить), прежде чем столкнулись с этой проблемой. В iOS текстуры деревьев, построенных на основе SpeedTree, не отображались, деревья стояли серые и голые, без листьев. Итак, поддержка мобильной разработки в Unity существенно выигрывает по сравнению с Unreal.

Результаты эталонного тестирования. Кадровая частота

Удивительно, но при тестировании кадровой частоты (FPS) на разных устройствах мы получили очень несхожие результаты. На некоторых устройствах Unity выигрывал при любой конфигурации. В других случаях Unreal обставлял Unity в тех тестах, где было много зданий. В принципе, Unreal выиграл, но дорогой ценой. Качество изображения и согласованность в Unity были существенно лучше. Текстуры Unreal на некоторых устройствах выглядели расплывчато, деревья получались значительно хуже. Разница в качестве была отчасти обусловлена тем, что отображается с одной стороны в редакторе Unreal и мобильном превью, а с другой – на реальном мобильном телефоне. Эта проблема была особенно очевидна, если говорить об освещении сцены. Было очень сложно подобрать настройки так, чтобы правильно настроить свет, весь сеттинг на мобильных устройствах зачастую выглядел затемненно. В этом отношении Unity оказался гораздо последовательнее, изображение на любых смартфонах было таким же, как и при предварительном просмотре в редакторе.

Результаты для обоих движков оказались гораздо лучше, чем мы рассчитывали (как вы помните, в наших тестовых моделях было примерно в 10 раз больше треугольников, чем в обычных мобильных играх).

В iOS оба движка примерно с одинаковым успехом отображали анимированные модели. Однако тесты с деревьями на этом устройстве оказались безрезультатными, поскольку Unreal не отобразил никаких текстур на моделях деревьев. Мы попытались найти причину этой модели, но не смогли ее разрешить. Кроме того, должны отметить, что при развертывании с применением этих движков у вас под рукой должен быть компьютер Apple. Это очень неудобно, но виновата в такой ситуации сама компания Apple. Заказчики также просили нас выполнить эталонное тестирование на Windows Phone. К сожалению, Unreal пока не поддерживает развертывания на Windows phone, поэтому здесь Unity победил по определению. Поскольку пока Windows Phone занимает очень небольшую долю рынка, развитие Unreal в этом направлении не считается приоритетной задачей.

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

Другие контрольные параметры

Вот еще некоторые интересные результаты, которые удалось выяснить в ходе наших тестов:

Оба движка почти не отличались по потреблению памяти. На устройствах с Android немного выигрывал Unity, на устройствах с iOS — Unreal.
Проект Unity существенно компактнее (Android: 42 MB / iOS: 100 MB) чем Unreal (Android: 101 MB / iOS: 173 MB).
Unity примерно втрое быстрее развертывается на устройстве. Кроме того, в Unity гораздо быстрее компилируется код.
Unreal значительно экономнее расходовал батарею. Спустя два часа работы со 150 анимированными моделями на экране Unreal успел разрядить батарею Android на 42 процента и iOS – на 36 процентов. percent on iOS. Unity потребил примерно 72 процента на Android и 47 процентов на iOS при такой же настройке и длительности работы.

Выводы

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

Несмотря на то, что изначально мы ставили на победу Unreal Engine, в настоящее время Unity все-таки более выигрышный вариант, как минимум, если говорить о разработке мобильных игр.

Вот основные доводы в пользу нашего решения:

Unity визуально выглядит более согласованно на всех устройствах, кроме того, быстро развертывается «одним щелчком» на любой платформе.
Unity занимает на устройстве гораздо меньше места, меньше сказывается на работе конечного пользователя. Компактный размер особенно важен в Google Play Store, где APK приходится делить на части, если этот файл оказывается крупнее 50mb.
Unity гораздо проще изучить и понять. Вооружившись Unity, неопытный пользователь может приступить к работе быстрее и создавать продукты, поддержку которых гарантирует большое сообщество специалистов.
Длительность итерации в Unity гораздо меньше (развертывание и компиляция исходного кода происходит быстрее, шейдеры компилируются почти мгновенно)

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

Заключение

Интересно отметить, что и ребята из Bit Barons до создания прототипа советовали нам взять Unreal Engine для нашего проекта. Учитывая, что и мы в OFM изначально отдавали предпочтение Unreal Engine, возможно, итоговое решение оказалось неоптимальным.

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

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

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