company_banner

UE4 и мобильная разработка: мифы и реальность


    Широко распространено мнение, что Unreal Engine 4 — слишком «тяжелая» технология для мобильных игр. В то же время число проектов, выпущенных на этом движке в мобильных сторах, растёт с каждым днём.


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


    Данная статья является является текстовой версией доклада, прочитанного 9 февраля 2017 года на мероприятии Unreal Engine Meetup в Mail.Ru Group. Несмотря на дату публикации исходного материала, представленная информация является не только тем самым наступившим «сегодняшним днём» и содержит в себе актуальные цифры, но и подтверждает прогнозы, высказанные автором на самом мероприятии.


    Миф первый: Unreal Engine никто не использует


    Последние четыре года я занимаюсь мобильными играми. И постоянно сталкиваюсь с мифами о разработке на Unreal 4, циркулирующими в мировом сообществе. Один из таких мифов гласит: «На этом движке очень мало игр, с ним сложно работать. Давайте возьмем Unity, на нём десятки и сотни тысяч различных игр». Когда-то именно так всё и было. Но сегодня это уже не соответствует действительности. Вот наиболее яркие свежие мобильные игры, сделанные на UE4:



    Этот миф развенчать очень легко. Монстры индустрии начинают активно использовать Unreal. Примеров гораздо больше, их уже десятки. Недавно вышедшие игры начали разрабатывать год-полтора назад. Так что сегодня мы наблюдаем результат начала активного использования Unreal Engine в мобильном сегменте.


    С чем это связано? Unreal Engine 3 имел очень много ограничений. Во-первых, требовалась полная лицензия, которая стоила определенные деньги. Бесплатный UDK позволял собирать приложения только для iOS. Нельзя было вносить множество изменений, разработчики пользовались только скриптовым языком и никак не могли модифицировать движок.


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


    2017-й можно назвать годом больших релизов в мобильном сегменте на Unreal Engine 4. Можете набрать в Google «Unreal Engine mobile», и увидите десятки игр, начиная от инди и заканчивая крупнейшими тайтлами.


    Миф второй: низкая производительность


    «Unreal Engine медленный. С ним невозможно работать, я создал простую сцену, у меня всё тормозит, невозможно с этим играть, давайте возьмем Unity, можно сделать миллионы треугольников». Если вы хотите отображать просто миллионы треугольников, которые ничего не делают, то, наверное, стоит взять Unity. Если мы говорим о реальной производственной задаче, о смоделированных персонажах, ландшафте, сцене, эффектах — то мы начинаем рассматривать уже не синтетические, а реальные тесты.


    Скриншоты некоторых наших внутренних разработок:





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


    Также у нас много эффектов, огонь, магия, взрывы. По нашим тестам было более 30 кадров на iPhone 5S. Сегодня этот телефон можно рассматривать как минимальную платформу. О каких тормозах речь?


    Речь всегда о том, как вы работаете с движком. Если сделать каждого персонажа по 10-15 тыс. полигонов, то если их будет больше двух в сцене, то это убьёт любой мобильник. Так что производительность движка — это вопрос проектирования игры, а не возможностей самой технологии.


    Второй пример:




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


    На карте более 2500 динамических объектов. Их можно разрушить, подвигать, с ними можно как-то взаимодействовать. Это не просто заранее подготовленная сцена, которая рендерится определенными батчами. Каждый из таких объектов занимает свой draw call, память, имеет свой жизненный цикл.


    Статических объектов — около 500.


    Поверхность земли покрыта травой — foliage в терминологии движка. В сцене может быть около 5000 экземпляров травяных кустиков. Самая частая жалоба на foliage в Unreal Engine: «Я наставил много травы — у меня всё тормозит». Причём на десктопах. А у нас на том же движке 5000 экземпляров — и ничего не тормозит. Что я делаю не так и причём здесь движок?


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


    Если вы начали разрабатывать мобильные игры полгода или год назад, то должны ориентироваться на такие системные требования:


    iOS 9/10 (Metal 1.1)


    • iPad Air: 697 / 1024 Мб /68%
    • iPad Mini retina: 696 / 1024 Мб /68%
    • iPhone 5S: 646 /1024 Мб /63%
    • iPhone 6: 645 /1024 Мб /62%
    • iPhone 6+: 645 /1024 Мб /62%

    Минимальные целевые устройства — iPad Air, iPad Mini retina (второй и выше), iPhone 6 и iPhone 5S. «Минимальность» определяется размером оперативной памяти. Рассматривать более старые устройства нет никакого смысла. Вся техника Apple, которая не поддерживает Metal, не является вашим целевым рынком. Более того, вы можете спокойно выпускать в App Store приложения, которые требуют iOS 9 или 64-битную систему, и тогда автоматически получаете эти устройства в качестве минимально необходимых. Это уже поддерживается на уровне платформы, и далеко не первый день. Не стоит пытаться оптимизировать игры под совсем древние устройства.


    Более того, если вы начали разрабатывать игру сегодня, то стоит забыть уже и про эти устройства. Через год их почти не будет. Например, iPhone 5S попал в список просто по традиции, по факту стоит рассматривать iPhone 6 как минимальное устройство. Целевые гаджеты завтрашнего дня:


    iOS 10 (Metal 1.2+)


    • iPad Air 2: 1195 /2048 Мб /58%
    • iPhone 6S: 1396 /2048 Мб /68%
    • iPhone 6S+: 1195 /2048 Мб /58%

    Чем они отличаются от предыдущего поколения? Процессор не особенно важен, главное — оперативная память. Это бутылочное горлышко мобильной разработки. Все уже привыкли работать с неограниченной памятью на десктопах. Но когда вы делаете мобильную игру, то должны помнить, что у геймера может не быть 2-3 Гб доступной памяти.


    Я специально не привожу примеры Android-устройств, там есть свои подводные камни. В частности, для Unreal не важно, сколько у вас ядер. Важно, какое из них наиболее быстрое. Поэтому все эти «айфоны», включая семерку, у которой два ядра, работают, как ни странно, быстрее. Хотя у Android есть свои преимущества.


    Миф третий: высокие системные требования


    В группе официального сообщества каждую неделю по два-три раза поднимается тема: «Для работы в Unreal Engine нужен очень мощный компьютер». На эту тему пишутся мануалы, на форуме Epic Games постоянно создаются темы: «у меня есть столько-то денег, подскажите, что купить?» или «сколько надо десятков тысяч долларов, чтобы я мог работать?».


    Рабочая конфигурация компьютера у меня выглядит вот так, там куча всего нашпиговано.



    Моя вторая рабочая конфигурация выглядит вот так — это коробочка с интегрированной видеокартой, по-моему, Intel 3000.



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


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


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


    Миф четвёртый: Unreal тормознее, чем Unity


    Миф возник во времена UDK. Созданные на нём проекты уступали аналогичным на Unity. Я сам с этим сталкивался. Это было обусловлено ограничениями самого UDK, и каждый раз приходилось доказывать, что ты не верблюд.


    По каким параметрам можно сравнить производительность движков?


    • Потребление аккумулятора. «Крутая картинка, клёво. А почему телефон греется? Почему поиграл полчаса, и закончилась батарея?» Даже выходят игры, в которых графики особо нет, но при этом сжирают батарею… Будут пользователи играть в такую игру? Вопрос.
    • Потребление оперативки. Это ваш естественный ограничитель. Если у вас в памяти много текстур и объектов, то игра будет падать. Это особенно актуально для iOS-устройств, у которых памяти гораздо меньше, чем у Android-гаджетов. За все годы разработки под Android я не столкнулся ни с одним падением из-за нехватки памяти. На iOS же постоянно приходится выкручиваться и придумывать, как жить в условиях очень ограниченного объёма оперативки.
    • Производительность рендеринга. Вот количество кадров в секунду, которое при определенных условиях выдают движки:


    Они близки, но Unreal выигрывает чаще, если речь идёт о большом количестве одинаковых объектов, потому что он очень хорошо умеет их инстансить. Если мы говорим про разные объекты, то разница в 1-2 кадра.


    Поэтому выбирайте инструмент в зависимости от проекта.


    Игра на Unity весит гораздо меньше, чем на Unreal


    Если вы делаете маленькую игру, это будет так. Если мы соберём пустой проект, то на Unreal он будет весить 70-80 Мб, а на Unity 10 Мб. Но из чего состоит размер билда? В первую очередь из ассетов, которые присутствуют в игре. Если в игре 80 различных персонажей, у которых по 20 видов мечей и 10 карт, то размер билда на любом из движков будет исчисляться гигабайтами. Какая разница, бинарник какого размера лежит рядышком? Да, на Unity 10-15 Мб, а на Unreal 60 Мб. Но при гигабайтных ассетах это не имеет значения. А если вы делаете маленькие казуальные игры, либо игры с 2D-графикой, то Unreal вам не нужен.


    У обоих движков свои особенности. У Unity можно всё отрезать и оставить 2D-графику. Unreal Engine вообще не является 2D-графическим движком. Он рассчитан на 3D-игры с хорошим качеством графики. Да, поддержка 2D имеется, но как дополнительный бонус. Повторюсь: выбирайте инструмент в зависимости от проекта. Размер билда не критичен, если вы делаете 3D-игру. Опять же, разница в 200 Мб не имеет значения: это уже больше 100 допустимых на Google Play, чтобы загружать по 3G.


    Длительность итерации


    Как долго билдится проект на Unreal? Всё зависит от того, как вы работаете с ассетом. В целом, длительность итерации в несколько раз больше, чем на Unity. Однако в Unreal Engine есть прекрасный режим предпросмотра для мобильных устройств. Чем он хорош? В отличие от многих других решений, в том числе от Unity, он выдает на десктопе идентичную картинку с Android и iOS. С точно такими же настройками, цветами и качеством, как это будет на мобильных устройствах.



    Если вы берете топовое мобильное устройство, то картинки будут идентичными. Это огромное преимущество. Можно проходить итерации гораздо быстрее. Вам не надо каждый раз собирать игру на устройстве, чтобы посмотреть, как она будет выглядеть. Играбельность — другой вопрос, это может потребовать времени. Но как она будет выглядеть, работать с графикой — это можно узнать на десктопе за считанные секунды. В выходящей скоро 15 версии добавили превью и для Metal: можно оценить возможности, которых нет в OpenGL 2.0.


    Расширяемость и модернизация движка


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


    Проблемы мобильной разработки: Slate и процессор



    В Unreal Engine интерфейс реализуется с использованием технологии Slate. Она глубоко встроена в движок, её нельзя просто выключить в какой-то момент. Slate обрабатывает устройства ввода, в том числе через операционную систему. У неё есть свои проблемы. Она оптимизирована в первую очередь для работы на настольных устройствах. Во вторую очередь — для мобильных.


    Не используйте Slate для HUD — интерфейса, в котором происходят основные действия игры, где критична производительность. Допустим, 10 солдат с одной стороны сражаются с 10 солдатами с другой. Всё должно летать. В этот момент не стоит использовать Slate. Лучше переключиться на Canvas — ручной способ. Дедовский метод, который существует десятилетиями, но он работает быстрее с точки зрения потребления CPU.


    Грубая оптимизация на уровне движка — это тоже оптимизация. Если вы уже доросли до оптимизации, то не надо этого бояться — берите и правьте движок. Обычно такие вмешательства носят ситуативный характер и зависят от проекта. Например, мы брали связанный со Slate код и прокидывали туда свои связи. Хотя ни одного экрана со Slate не отображалось, но по умолчанию всё равно выполнялось очень много обработки. Тогда мы просто отключили её. Правда, если есть хоть один виджет, то обработка присутствует. А если виджетов нет, то вызывается очень простая функция, которая ничего не делает. Это криво, это не универсально, но работает. Когда вы делаете проект для пользователей, он в первую очередь должен отлично работать, а не быть универсальным решением.


    Проблемы мобильной разработки: оперативная память


    Это касается любого 3D-приложения — нужно больше памяти. Как быть?



    Начну с самого простого — разрешения и количества текстур. Если у вас огромное количество разных текстур, и все они большого разрешения, то это может выглядеть круто. Но вы делаете игру под мобильные устройства, так что нужно соблюдать баланс. Делайте атласы, какие-то текстуры используйте многократно. Организуйте свою работу так, чтобы использовать их по минимуму. К примеру, на огромной карте на полкилометра мы используем всего пять текстурных атласов, color и нормали. То есть всего 10 текстур покрывают огромнейшую карту со статическими объектами. А благодаря мастерству художника вы не найдете двух одинаковых мест на этой карте.


    Используйте текстурные атласы. Сейчас есть две открытые технологии — VaTexAtlas и Paper2D (требуется весь модуль Paper2D). Если вы не используете какие-то возможности последнего, не работаете с 2D-графикой, то проще его отключать ради уменьшения билда. Paper2D сжирает примерно 40 Мб.


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


    Аккуратно используйте Merge Actors. Эта функциональность очень помогает оптимизировать draw call: стоят вдали 20 домиков, вы их объединили и получили одну модель, скажем, на 10 тыс. полигонов. Эти 10 тыс. вертексов загружаются в память и висят там. Поэтому очень легко заоптимизировать карту с точки зрения draw call, и получить огромное потребление памяти. Важен баланс, не забывайте.


    И первое по важности: контролируйте количество шейдерных пермутаций. Что такое material instance? Набор параметров, который применяется в материале. То есть используется материал, уже находящийся в памяти, и в нём меняются параметры. После их применения эта же область памяти отправляется дальше на отрисовку. С точки зрения памяти всё было бы хорошо. У вас есть базовый материал, допустим, после компиляции весит 10 Мб; у вас есть 20 material instance, каждый для своего персонажа, они весят по 5-10 Кб, в памяти они занимают столько же. Допустим, вы использовали master material, в котором применены переключатели. Они позволяют иметь один большой материал на все случаи жизни, но здесь надо быть очень аккуратным. Если вы включаете какой-то switch, любой параметр типа boolean, который заставляет иначе работать поток выполнения компиляции материала, то после упаковки этот material instance становится материалом. Не просто набором параметров, но и набором шейдерных инструкций. Допустим, вы создали материал для правой и левой руки. Правая рука рисуется золотом, левая — серебром. Материал один, в руках переключатели. И при этом для каждого персонажа сделан свой material instance, и в каждом стоит галочка — это для левой руки, это для правой. Добро пожаловать в мир шейдеров: у вас сразу же потребляется 200 Мб памяти, только потому, что вы забыли про эту ситуацию.


    Лучше всего создать два material instance уже от базового материала, и в каждом поставить эту галочку. А потом у этих material instance менять только числовые параметры. Такой подход сокращает потребление памяти и места на диске, потому что шейдеры загружаются в память целиком. Если очень много всего сгенерируется, то билд может разростись до 1,5 Гб, хотя у вас всего один уровень. Я сам с этим сталкивался: однажды игровая карта с несколькими персонажами заняла больше 1 Гб. На Apple больше 1 Гб, на Android — 300 Мб.


    Проблемы мобильной разработки: потребление CPU


    На iOS-устройствах обязательно используйте Metal, выжимайте из него всё. На Android вас спасёт такая вещь, как Vulkan. На обеих платформах есть и OpenGL 3, но под Android потребление процессора будет выше.



    Переносите свои вычисления на GPU, ведь графический чип чаще всего простаивает. В первую очередь — визуальные эффекты. У них есть часть, которая рендерится, и часть, которая генерирует и обрабатывает. Меньше частиц — больше их визуализации. И не забывайте про баланс.


    Не обрабатывайте то, что не видит игрок. В движке не всегда есть оптимизации для мобильных устройств. Если ваш персонаж стоит где-то за спиной игрока, не надо проигрывать у него анимацию, не надо отслеживать его перемещения, движения костей. Достаточно смотреть, где находится его капсула. Отключите ему всё, в том числе физику. Более того, если он у вас за спиной, обсчитывайте его раз в 10 тиков, например.


    Отсекайте лишнее. Во многих играх не нужны способности, заложенные в Character. Это достаточно «жирный» класс, в котором много логики, рассчитанной на шутеры, на десктопные игры с огромным числом возможностей, где можно бегать по потолку, прыгать, прокладывать маршруты, двигаться по физике. Чаще всего мы говорим о персонаже, который идет из точки А в точку Б. Напишите свой movement controller, сделайте steering behavior. Это задача для ученика старшей школы, есть куча технологий. Если вам нужно только движение — лишь его и используйте, не надо тащить за собой всё остальное. Это тоже одна из вещей, которая пугает тех, кто приходит с Unity.


    Физика — это не просто. Любые физические вычисления работают в определенном потоке. Если у вас 300 различных кубиков бегает по сцене — у вас будет низкий FPS. Шаг второй — ограничьте их по группам, и так далее.


    И одно из самых важных решений — Blueprint Nativization. Это огромный прорыв в оптимизации движка. Если сами по себе blueprint'ы в 10–30 раз медленнее исходного кода. Задача нативизации blueprint'ов очень обширна, не получится просто включить галочку в настройках. Это тема отдельного разговора. Но для начала хотя бы начните пользоваться нативизацией, это уже даст ускорение скорости работы blueprint'ов на порядок.


    Проблемы мобильной разработки: рендеринг


    Самое простое, о чём уже говорили: используйте вертексную развертку вместо пиксельной. Считайте ваши UV на нодах как Custom UV. Никаких модификаций UV на пиксельном канале. Можно легко делать океаны: 200 с чем-то инструкций, и отлично играет на всех проектах.


    Если вы всё это перенесете в пиксельные шейдеры — у вас будут проблемы. Если вы будете считать UV scale, допустим: scale земли близко с одним масштабом, scale ландшафта с другим — дальше расплывается. Сделаете это на пиксельном шейдере — и сразу же получите проблему. На вертексном тоже, но не факт, что игрок это заметит. Потому что при виде от первого лица этот переход можно скрыть лесенкой. Игры — это мастерство фейка. Никогда не пытайтесь получить чистые шейдеры, чистую картинку в каждом пикселе. Используйте сильные стороны, скрывайте слабые.


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


    Чем меньше skeletal mesh и анимации, тем быстрее это всё считается. Опять же, есть оптимизации по расстоянию, которые пропускают кадры, их надо использовать. Мы написали свою, ещё более грубую отсечку, но для мобильных игр это оправдано. Кого интересует персонаж в 15 пикселей? То, что у него пропущено три кадра анимации и отрисовка раз в секунду — это надо ещё постараться заметить. Когда у вас жаркие бои, то какая разница, сколько кадров в секунду анимации у этой ёлочки, 1 или 30?


    VFX можно убить эффектами, контролируйте этот момент.


    Прототипируй!


    Главный мой совет в мобильной разработке — в первую очередь делайте прототипы.






    Если хотите сделать игру с сотней персонажей, создайте хотя бы синтетический тест. Не делайте их уникальными. Возьмите одну модель и сделайте сто экземпляров. Однажды у нас была адская работа: сделали сто разных персонажей. Они выглядели одинаково, но формально, а главное, с точки зрения памяти и рендеринга, были разными. 20 классов и 100 персонажей. Мы потестировали и поняли — не работает. Пришлось сокращать и оптимизировать.


    Прокладка маршрута и движения: взяли 10 character — тормозят. Переписали движение, посмотрели, не тормозит — отлично. Физику тоже проверяйте на прототипах. Вас устраивает, как это работает? Вас устраивает производительность? Не надо делать графику, расписывать лор, не надо всё программировать. Выделите критичные части и прототипируйте их.


    Какое будущее у мобильной разработки?


    Сегодня iOS, благодаря развитию Metal, является более предпочтительной платформой для нагруженных 3D-игр. Эта технология сильно оптимизирует нагрузку на процессор. Там не получается какой-то огромной выгоды в кадрах, в основном снижает потребление энергии. Кстати, при прочих равных Unreal Engine нагружает процессор меньше, чем Unity. Это за счет того, что на многих устройствах вычисления переносятся на более энергоэффективный GPU.


    Будущее мобильной разработки — это Vulkan. Я всё жду, когда он появится на iOS. На Android он практически обеспечивает возможности десктопной графики. Чего только стоит screenspace reflexion в реальном времени.



    Vulkan работает быстрее, ещё более оптимизирован, даёт больше возможностей, позволяет реализовать на мобильных устройствах картинку на уровне больших компьютеров. К примеру, последние полтора года художники меня чуть ли ни каждый день спрашивают: давайте добавим динамический ambient occlusion. Сегодня эта задача не решается в мобильном сегменте. Надеюсь, что с приходом таких технологий, с приходом нового железа мы сможем себе позволить, в том числе, и ambient occlusion.


    ПОСЛЕСЛОВИЕ


    В силу времени, прошедшего с момента составления данного текста, некоторые вещи из "планируемых" успели стать "реализованными". Так, Lineage 2: Revolution вышла в мир, а Unreal Engine 4.18 привнёс функционал дескопного рендеринга на iOS (очень круто!). Тем не менее, описанные подходы не теряют своей актуальности.


    The future is now.

    Mail.Ru Group 517,69
    Строим Интернет
    Поделиться публикацией
    Похожие публикации
    Комментарии 29
    • +2
      Забавно, не ожидал когда-либо увидеть статью в защиту Unreal против Unity. В целом согласен, начиная с определённого масштаба игры и квалификации разработчика разница в простоте использования движков становится несущественной и на первый план выходят более продвинутые фичи. Если взять те же LOD'ы, то в юнити до сих пор реализация весьма убогая, только недавно начались какие-то подвижки в эту сторону.
      • 0
        Хорошая статья, спасибо. Очень люблю игры, но плохо понимаю, как устроены (и как они разрабатываются). Теперь стал не понимать чуть подробнее :)
        • –1
          Никогда не нравились эти холивары Unreal vs Unity. По моему каждый разработчик выбирает движок изходя из его опыта и знании в языках программировании и технологиях. Я сам предпочел Unity и этот выбор был сделан как раз из-за того что там язык c#, а до этого я был Android(Java) разработчиком. Можно конечно быстро изучить нужный язык программирования, но это в том случае если изучаемый ЯП вам по душе так сказать.
          • 0
            Я сам весьма настороженно отношусь к холиварам, но приветствую «pros vs cons» сравнение технологий, в первую очередь со стороны бизнеса. Выбор технологии отдельным разработчиком, и выбор компанией/студией — несколько разные вещи.
          • +2
            Я за анриал, но не могу удержаться:
            «Да, на Unity 10-15 Мб, а на Unreal 60 Мб. Но при гигабайтных ассетах это не имеет значения. А если вы делаете маленькие казуальные игры, либо игры с 2D-графикой, то Unreal вам не нужен.»
            Все имеет значение. 45 Мб это 9 несжатых фонов в FullHD. Мб можно этот параметр как-нибудь улучшить?

            «Даже выходят игры, в которых графики особо нет, но при этом сжирают батарею… Будут пользователи играть в такую игру? Вопрос.»
            Так что больше потребляет на среднем билде в средней игровой ситуации? Вот хартстоун(юнити) просто жрет на глазах аккумулятор. Просто нонсенс — эмулятор PS1 потребляет значительно меньше ресурсов(+заряда), чем «нативная» оптимизированная игра под юнити.
            • 0
              А что в нём при этом запущено?
              • 0
                Все имеет значение. 45 Мб это 9 несжатых фонов в FullHD. Мб можно этот параметр как-нибудь улучшить?

                Можно, но в ущерб тем или иным вещам. Лично я не вижу в этом никакого смысла совершенно — лучше потратить время и силы на совсем другие вещи :) «Маленькие игры» — это отдельный бизнес.

                Так что больше потребляет на среднем билде в средней игровой ситуации?

                К сожалению понятия «средний» для такой ситуации нет — все слишком зависит от конкретной игры.
              • +3
                Какая-то странная статья немного. Раньше считалось, что Unity тормозная, а UE шустрая из-за плюсовой начинки, а тут что-то наоборот решили сравнить.
                • –1
                  Признать, я честно удивлен что «раньше считалось именно так» :) Хорошо, если такое мнение уже стало преобладающим.
                • +3
                  Статья какая-та продажная.

                  Миф первый: Unreal Engine никто не использует
                  На юнити очень много продуктов от крупных компаний. Alto Adventure, Lara Croft Go, все части The Room, Monument Valley, Royal Blood, Cuphead и множество других серьезных проектов, которые не простыми разработчиками были созданы. Я не говорю, что Unreal Engine никто не использует, я клоню к тому, что сравнивая два движка (один из которых вы так сильно пытаетесь унизить), стоило указать — сколько компаний разочаровались в Unity и перешли на Unreal Engine. Этот показатель был бы более наглядным.

                  Миф второй: низкая производительность
                  Ну вот вы ярко расписываете, что игра прекрасно работает на iPhone 5s, да ещё и намекаете, что завтра он войдет в историю, и уже iPhone 6\6s будет минимальным целевым устройством. Android вы решили благополучно опустить, правда не понятно почему. Вон samsung в 2017 году выпустил Samsung Galaxy A3, который купят-купили огромное количество человек, а он по производительности почти в два раза хуже iPhone 5s, причем стоит этот самсунг 205евро (первая попавшаяся цена), не сказать что жутко бюджетный, за такие деньги можно найти гораздо мощнее смартфон. И сколько ещё подобных устройств приобрели за 14-15-16-е года? Если идет речь про мобильную разработку, то ставить планку iPhone 5s не лучшее решение (если конечно не идет речь о поддержке Android, но раз речь идет о мобильной разработке, Android было бы глупо исключать).

                  Миф третий: высокие системные требования
                  Забавно использовать для разработки мобильных игр Intel 3000. Сейчас топовые устройства спокойно вытягивают динамическое освещение, пост эффекты (блюм и прочее), не знаю как с минимальным комфортом можно что-то делать при такой конфигурации. А уж запекание лайтмап (для мобильных игр это немаловажная технология) вообще станет ужасом. Но тут по сути точно такая же ситуация и в Unity (хотя для лайтмап в Unity выпустили прогрессив версию, которая в режиме реального времени кусками будет строить лайтмапы, в зависимости от текущего обзора камеры, причем без сильной потери производительности). В целом, хочешь комфортно работать, запасайся мощным железом, независимо от того, Unity у тебя или UE.

                  Миф четвёртый: Unreal тормознее, чем Unity
                  Не понятно для кого были построены графики. По вашим графикам UE выигрывает чаще и оперируете вы это тем, что если речь идёт о большом количестве одинаковых объектов, то UE очень хорошо умеет их инстансить. Ну чушь же, в Unity так же есть инстансинг на GPU, или batching (dynamic/static) на CPU. Как вы сравнивали, не понятно. Что было включено, что выключено, какое освещение было, какие настройки рендеринга были (forward/deffered) какие шейдеры применяли к вашим Tree и Objects. В общем, сравнение какое-то пустое, не несет никакой смысловой нагрузки.

                  Игра на Unity весит гораздо меньше, чем на Unreal
                  Честно, не знал, что билд на UE настолько жирный. Вы оперируете тем, что если речь идет о гигабайтных ассетах, то это не важно. Но подождите же, сейчас жирные тайтлы по 1-2Гб это исключение из правил, в основном все игры пытаются подгонять под <100мб на андроид и под <150мб под iOS. Вы утверждаете, что "если вы делаете маленькие казуальные игры, либо игры с 2D-графикой, то Unreal вам не нужен.", но когда речь идет о мобильной разработке, то казуальные игры/аркады будут в топе. В таком случае UE подходит только для разработки массивных 1-2Гб игр, а это очень маленькая целевая аудитория (среди потенциальных разработчиков). Причем Unity вполне комфортно будет вести себя при разработке таких массивных игр. Итого совсем не понятно, в чем тут плюс UE.

                  Длительность итерации
                  Тут вы ярко описываете, что в UE можно увидеть картинку с мобилки прямо на десктопе. Ещё и примеры привели. Ещё и сказали, что на Unity такого нет. Ну как нет, если на юнити точно так же выбираешь платформу Android и вместо красивых размытых динамических теней мы получаем «лесенки». Unity точно так же выдает картинку, которая будет на девайсе, вплоть до того, что можно эмулировать Open GL ES 3.0/2.0 + бегать между Shader Hardware Tier 1/2/3. С Metal точно такая же ситуация, выбираешь платформу iOS и там уже можно включить Metal API для редактора. Компилировать игру на девайс вовсе не нужно, все безумно легко проверять-смотреть прямо на десктопе. С помощью editor-скриптов можно настроить управление на клавиатуре (вместо тачей) и с легкостью тестировать её прямо в редакторе (тут полагаю в UE так же можно сделать), а про Unity Cloud Build и вовсе молчу, если машина слабая (или проект жирный) и сборка занимает много времени, Unity Cloud Build может очень серьезно в этом плане помочь. В результате так и не понятно, в чем UE выигрывает в этом плане.

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

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

                    Мне тоже так показалось…
                    Интересно, а зачем и кому Mail.ru «продаёт» UE?
                    • +1
                      Самоуспокоение. Выбрали анрил, построили на нем разработку, теперь слезть не могут. А хотят на Юнити. Вот и оправдывают сами себя.
                      Шучу, конечно же.
                      • 0
                        Статья не просто продажная, она абсолютно оторвана от жизни. Если бы товарищ был в курсе, то не заливал бы про вулканы и gles3 на андроидах, а плакал от актуальных 25% gles2 mali400.
                        • 0
                          К сожалению, статистику по железу юнитеки выпилили у себя (а там была замечательная разбивка по вендорам и вообще), поэтому можно ориентироваться по официальной статистике гугля (ближе к концу есть таблица — 37% gles2): developer.android.com/about/dashboards/index.html
                          • 0
                            Что и означает 2/3 отличнейших девайсов на GLES 3.x :)
                            • 0
                              Нет, это означает значительную потерю потребительского рынка, потому что половина gles3 устройств — это просто «gles3 ready» как раньше делали наклейки «directx 10 ready» для офисного железа. Основная проблема у мобилок — это всегда разрешение, китайские братья любят ставить дохлый или средний гпу на 2k и выше разрешение — это тоже может пройти как gles3, но будет хуже hd разрешения на том же mali400mp2.
                              • 0
                                Да нельзя охватить весь рынок, никак. Вы всегда чём-то жертвуете, особенно на андроиде. И тут встаёт выбор — либо вы работаете под лоу энд девайсы, со всеми вытекающими, либо ставите адекватные рамки — для игровых устройств. Разные ниши, разные пользователи, разные деньги. Sdk 21 версии относительно скоро будет уже минимальным для стора, впереди 64 бит и прочие радости.

                                Для китайских собратьев есть даунскейл. Хуже, когда сам чип GPU беден как ни крути :(
                                • +2
                                  Вот мы плавно и подошли к тому, что unreal неприменим к половине android устройств, а значит нецелесообразен, т.к судя по тестам в статье разница с юнити в 1-2фпс, а ресурсов он жрет в 2 раза больше, чем юнити. Вот она — суровая реальность, а не мифы о мифах в статье.
                                  • 0
                                    К половине прекрасных андроидовских устройств скоро будет применён лейбак «не поддерживается Гугл плеем», о чем вы? Если вы ставите работу над играми в Гугл плее равенство «работа под лоу энд», то это уже не так. Посмотрите хотя бы игры из начала статьи, прекрасные примеры как можно делать продукт, мега успешный на рынке, не оглядываясь на девайсы такого типа.
                                    • 0
                                      Это еще с чего? Не поддерживается все ниже android 4.0 или 4.1, а это по сути не меняет статистики по железу. Через полтора года да, потребуется поддержка arm64, но полтора года — это целая мажорная версия юнити :)

                                      Посмотрите хотя бы игры из начала статьи

                                      Я прочитал тот абзац как
                                      Давайте возьмем Unity, на нём десятки и сотни тысяч различных игр». Когда-то именно так всё и было. Но сегодня это уже не соответствует действительности. Вот меньше десяти игр, которые хоть как-то шевелятся и их не стыдно показать, сделанные на UE4

                                      Десятки-сотни тысяч против отборного десятка — плохой пример целесообразности применения unreal. Скорее пример адекватности остальных участников мобильного игростроя, не применяющих неоправданно тяжелые решения на ограниченном железе в угоду покрытия наибольшего количества устройств и увеличения ЦА.

                                      Ну и самый эпик-фейл, что вспомнился — как делали flappy bird на unreal, который в итоге подергивался на топовом тогда железе. А в довесок еще и оказалось, что unreal в принципе не умеет батчить спрайты, а если кому надо, то пусть напишет сам.
                                      • 0
                                        Спасибо, я вашу позицию понял ;)
                      • –1
                        один из которых вы так сильно пытаетесь унизить

                        Еще раз повторюсь — выбирайте инструмент в зависимости от проекта. Сравнение в одной из плоскостей с Unity это лишь небольшой, и совершенно не главный кусочек доклада ;)

                        Ну вот вы ярко расписываете, что игра прекрасно работает на iPhone 5s, да ещё и намекаете, что завтра он войдет в историю, и уже iPhone 6\6s будет минимальным целевым устройством. Android вы решили благополучно опустить, правда не понятно почему.

                        Я даже не намекаю, я это весьма уверенно утверждаю :) На текущий момент, разрабатывая игру для iOS, девайс iPhone 6 можно смело считать минимальным. И да, эппл как был, так и остаётся самой денежной мобильной платформой, в то время как Android — обладает большей пользовательской массой. Если вы целитесь в лоу-энд девайсы андроида — это тоже свой рынок, но лишь его часть -есть и другая, весьма многочисленная, часть андроид устройств с прекрасной производительностью.

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

                        Мой основной поинт — в хорошую игру будут играть не смотря на размер, а для стран, где проблемы со сторами аля китай, легко выпускается версия, где докачка контента происходит уже в самой игре. А плохую игру или треш — сейчас уже просто так «из-за размера» качать никто не будет. Да, «меньший размер» — это плюс, но далеко не в первых рядах. И речь ведь не только о «гигабайтных ассетах» — игра 300-400 метров это уже не 150, но и далеко не гигабайты.

                        Unity точно так же выдает картинку, которая будет на девайсе, вплоть до того, что можно эмулировать Open GL ES 3.0/2.0 + бегать между Shader Hardware Tier 1/2/3.

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

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

                        А на самом деле — нет, это весьма «составит труда», и вообще одна из главных печалей тех, кто делает серьезные проекты на юнити. Прям такая, что немало слёз разработчиков об этом пролито.
                        • 0
                          А на самом деле — нет, это весьма «составит труда», и вообще одна из главных печалей тех, кто делает серьезные проекты на юнити. Прям такая, что немало слёз разработчиков об этом пролито.

                          Можно этот момент закрыть, в юнити есть корпоративная подписка (как раз для серьезных проектов от серьезных компаний), где дается полный доступ к исходному коду.
                        • +1
                          Справедливости ради,
                          Ну как нет, если на юнити точно так же выбираешь платформу Android и вместо красивых размытых динамических теней мы получаем «лесенки». Unity точно так же выдает картинку, которая будет на девайсе, вплоть до того, что можно эмулировать Open GL ES 3.0/2.0 + бегать между Shader Hardware Tier 1/2/3.
                          должен предупредить, не стоит по части шейдеров слишком сильно на этот режим эмуляции надеяться, сталкивался с ситуацией когда в нём всё норм, а на итоговой сборке шейдер глючит.
                          Как у анрила хз.
                          • Вы утверждаете, что «если вы делаете маленькие казуальные игры, либо игры с 2D-графикой, то Unreal вам не нужен.», но когда речь идет о мобильной разработке, то казуальные игры/аркады будут в топе. В таком случае UE подходит только для разработки массивных 1-2Гб игр, а это очень маленькая целевая аудитория (среди потенциальных разработчиков). Причем Unity вполне комфортно будет вести себя при разработке таких массивных игр. Итого совсем не понятно, в чем тут плюс UE.


                            Это классификация «на балконе стояла мама, папа и банка помидор».

                            Мелкая казуальная игра и крупных 3D-проект на одном и том же движке — это одно название что проект называется одинаково.

                          • 0

                            Тоесть статью можно сократить до "Писать крутые игры под мобилки можно и нужно!". Но с кучей ограничений: количество полигонов, разрешение, пе-ре-жа-ты-е тектстуры всякими PVR RGBA4444/RGBA5551, мержить статическую геометрию и симплигонить, атласы под всёёё-ё, лоды-куллинг, небольшие баттле-арены. Тоесть пофакту получает поколение PS3-X360. и по уровню графона из заморочек. Только vtbl уже бояться не нужно.

                            • +2
                              забивая на момент, что это была реклама мобильной армы…

                              Железо для билдов «из коробки» — для анриала требуется в 2 раза сильней.
                              Отдельный момент — это место на жестком под проект и ассеты, там сразу на порядок разница.
                              Анриал ооочень требовательный. Возможно, Ваша кастомная версия для разработчика армы отлично оптимизирована, но многим компаниям дешевле просто юнити из коробки взять.

                              Цена ассетов различается на порядок, количество — уже на 2 порядка. И все не в пользу анриала. Как минимум прототипирование из-за этого проще на юнити.

                              «Мой основной поинт — в хорошую игру будут играть не смотря на размер» — будут, но с эмулятора на пк и не будут платить.
                              Основная масса топа мобилок борется за каждый мегабайт.
                              Лишний мегабайт = лишняя секунда загрузки apk = % отвала пользователей.

                              Нет сравнения портирования на платформы, а на юнити платформ больше, проще портирование и куча партнеров (CloudMoolah, FacebookGoogle, Intel, Microsoft, Oculus, OTOY, Samsung, Vuforia, Xiaomi)

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

                              Анриал — хороший и самый мощный инструмент, но далеко не самый выгодный для мобильной разработки в данный момент.
                              • 0
                                забивая на момент, что это была реклама мобильной армы…

                                Как публикация доклада, прочитанного ровно год назад?.. :)

                                Железо для билдов «из коробки» — для анриала требуется в 2 раза сильней.…
                                … Возможно, Ваша кастомная версия для разработчика армы отлично оптимизирована, но многим компаниям дешевле просто юнити из коробки взять.

                                Ну… нет. В разработке используем обычную версию из лончера. Никаких сверхтребований к железу редактор не предъявляет ни разу. Даже маки без выделенных GPU используются на ура. CPU наше всё, но это очевидно когда работаешь с C++, а не скриптовыми языками.

                                А вот место на жестком диске да, анрил к нему всегда был требовательным. Но SSD в 240 Гб, доступный каждому уже несколько лет как, более чем достаточен для связки ОС + движок + проект.

                                Цена ассетов различается на порядок, количество — уже на 2 порядка. И все не в пользу анриала. Как минимум прототипирование из-за этого проще на юнити.

                                Наши художники только что узнали много нового… :) Цена ассетов и количество никак не зависят от движка при правильной организации пайплайна разработки. Это вообще нонсенс. PBR он и в Африке PBR, всё остальное — вторично.

                                Лишний мегабайт = лишняя секунда загрузки apk = % отвала пользователей.

                                Глобально есть разница только «доступно по LTE» и «недоступно».

                                Нет сравнения портирования на платформы, а на юнити платформ больше, проще портирование и куча партнеров (CloudMoolah, FacebookGoogle, Intel, Microsoft, Oculus, OTOY, Samsung, Vuforia, Xiaomi)

                                Да и доклад вообще не про Unity vs UE4… Оо
                                У анриала тут свои вкусности, у юнити — свои. О «простоте портирования» можно ой многое рассказать) Поддержка платформенных вещей встроенная у анриала слабовата, но уже кучей весьма классных плагинов расширена.

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

                                Юнити для мобилок старше анриала на несколько лет. Всё успеется, подождите. Это ж самый первый пункт в статье выше :)
                                Про % вопрос с Эпиками решаем был всегда.

                                Анриал — хороший и самый мощный инструмент, но далеко не самый выгодный для мобильной разработки в данный момент.

                                Ключевой вопрос — смотря для чего.
                              • 0
                                Эх, Lineage 2: Revolution требовательная. Мой калькулятор не берет ее.

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

                                Самое читаемое