Продолжая сравнение топовых 3D-движков — Unreal Engine 4 и Unity, на этот раз мы рассмотрим их достоинства и недостатки при разработке 2D-проектов. Мы выясним, чем хорош Unreal для 2D, как организована работа с основными элементами двухмерной игры и какими средствами можно реализовать 2D-персонажей со скелетной анимацией.

Мы уже сравнивали Unity 5 и UE4 применительно к 3D-играм. Если кратко, мы пришли к выводу, что Unreal крут и его вполне можно использовать для разработки качественных трёхмерных игр. Но какая ситуация складывается в мире 2D-игр? Сравним Unity 5 и Unreal Engine 4.16.

image
Unreal Engine 4 vs Hollow Knight (Unity)

Если популярность Unreal для 3D не вызывает сомнений, то, например, коммерческих 2D-проектов, сделанных на нём, практически нет. Поэтому возникает вопрос: стоит ли вообще использовать Unreal для 2D и не слишком ли он избыточен для подобных проектов?

Рассмотрим этот вопрос на примере игры Hollow Knight (на заднем плане скриншота). Она сделана на движке Unity, PC-версия занимает 8,5 Гб, весьма мощный проект. Если делать подобную игру на Unreal, runtime-библиотеки займут в сборке проекта около 100—200 Мб. Для масштабных проектов это не так страшно, ведь даже мобильные игры порой весят пару гигабайт.

Чем же нам может помочь Unreal при создании 2D-игры?


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

Unreal Engine Blueprint

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

UE4 Blueprint logic
Реализация управления игровым объектом через блупринт

Как вариант, если вы только начинаете создавать игры, попробуйте сделать первую игру именно в 2D, потому что она по определению проще 3D-игры. Для 2D потребуется меньше компонентов, сама игровая механика «плоская». Конечно, в таком проекте вы всё равно можете использовать 3D-модели в качестве фона, если понадобится. Начинающему разработчику проще разобраться в системе блупринтов, чем изучать язык C# для Unity или С++ для UE4.

Если вы уже пробовали Unreal, возможно, вам знакома система Unreal Gameplay Framework — это целый набор сущностей движка, от средств управления персонажем (player controller) до HUD’а, игрового интерфейса и анимации. Несмотря на то что набор 2D-компонентов немного отличается от тех, что используется для 3D, общие принципы работы в них несомненно присутствуют.

image

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

2D в Unity


Unity 2D Editing

Что нам даёт Unity для 2D-игр? Для начала — компонент Sprite Renderer, на котором основана игровая 2D-графика. Мы можем переносить спрайты из папки контента в сцену в редакторе, строить на основе них элементы уровня и игровые объекты. Сразу отметим, что в Unreal схожая механика редактирования сцен. Мы можем перетаскивать компонент спрайта в сцену, обычный drag-and-drop. Для реализации спрайтовой (покадровой) анимации Unity предлагает два способа:

  • Путём замены спрайтов в Animation Controller (используются те же средства анимации, что и для 3D-объектов), в итоге получается несколько спрайтов и один графический объект, а анимация меняет текстуру этому спрайту.
  • Путём создания атласа из текстур. Можно сделать анимацию через скрипт UV-анимации. Благодаря смещению UV-координат получается движущаяся картинка. При этом один или несколько клипов анимации расположены в одной текстуре.


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

2D в Unreal


image

В Unreal Engine 4 создание проекта или прототипа часто начинается с выбора шаблона, поэтому рассмотрим этот шаг. Чтобы разработчикам было с чего начать, существует шаблон проекта 2D Side Scroller. Это аналог 3D шаблона Side Scroller, но графика в нём основана на стандартном плагине Paper2D. Он даёт нам поддержку 2D-спрайтов, т. е. тех самых основных графических элементов, из которых собирается игра.

Кроме спрайтов, есть анимационные клипы, они называются flipbook. Похоже на блокнот, когда мы рисуем по одному кадру на каждой странице, а потом быстро перелистываем, чтобы получилась движущаяся картинка. Флипбуки — средство простейшей двухмерной анимации. Их, как и спрайты, можно импортировать из программы Texture Packer, она позволяет настроить параметры компоновки текстурного атласа. Загрузив атлас в Unreal, мы получим каждый спрайт в виде отдельного ассета (Asset), который потом просто перетаскивается на сцену.

UE4 2D Side Scroller

Здесь мы видим скриншот редактора с проектом 2D Side Scroller. В нем реализовано управление персонажем, взаимодействие персонажа с миром (физика) и переключение анимации. Несмотря на 2D графику, физика в проекте трёхмерная. Это связано с тем, что экспериментальная 2D-физика, реализованная на Box2D, есть только на платформе Windows. Из-за этого 2D-спрайты крепятся к трёхмерному физическому представлению. Подход немного странный, поэтому для персонажа PaperCharacter существует специальный флаг, который ограничивает его перемещение в заданной плоскости.

В движке Unity, в отличие от Unreal, элементы для 2D-физики полностью поддерживаются: есть коллайдеры, Rigid Body (твёрдые тела) и другие компоненты.

Создание 2D-уровней в Unreal


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

UE4 Tilemap

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

Также Unreal позволяет связывать элементы уровня блупринтами. Можно безо всяких специальных инструментов реализовывать такие скрипты, как «При открытии этой двери появляется монстр» или «Если бочка взорвётся, то произойдёт какое-то событие».

UE4 Level Blueprint
Фрагмент «блупринта уровня» в UE4 с реализацией реакции на вхождение игрока в зону триггера

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

2D-персонажи в Unreal


Плагин Paper2D в Unreal предоставляет нам компонент PaperCharacter. Это персонаж, основанный на Flipbook, т. е. на системе спрайтовой покадровой анимации. У нас будет сам персонаж и его физическая модель в виде 3D-капсулы.

Flipbook Animation

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

UE4 old school physics
Old-school physics enabled!

А что насчёт персонажей со скелетом? Как в Unreal, так и в Unity 5 нет встроенного компонента для двумерной скелетной анимации, но мы этот вопрос рассмотрим дальше.

Spine для двухмерной скелетной анимации


Программа Spine — это комплексный пакет и SDK для создания двумерных персонажей. С помощью неё создаётся скелет персонажа, к нему крепятся спрайты, причем они необязательно прямоугольные: можно придать им нужную форму. Анимация получается скелетной, полностью аналогичной той, что используется для 3D-персонажей. В отличие от спрайтовой, она будет плавной за счёт того, что между ключевыми кадрами анимации выполняется интерполяция движения костей. Файлы анимации при этом весят меньше, плюс Spine позволяет привязывать к персонажам объекты.

Spine
Главное окно программы Spine с отображением костей персонажа

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

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

Из-за такого специфичного набора возможностей и многообразия поддерживаемых платформ сама система Spine часто идёт в отрыве от основной системы анимации в движке. Если в Unity, например, можно создать иерархию костей, которая изначально была в персонаже (это одной кнопкой делается), то в плагине для Unreal такого пока нет. Там можно создать специальные компоненты для привязки экторов к костям. Мы задаём, например, название кости, и объект к ней привязывается.

Spine для Unreal Engine 4


В последних версиях Unreal была исправлена ошибка, которая мешала собираться плагину Spine’а, и сейчас его можно использовать. Все примеры работы со Spine реализованы на блупринтах, а доступ к API есть как из кода, так и из блупринтов. Например, есть примеры с движениями персонажа, блендингом анимации и воспроизведением звука по событиям анимации.

UE4 Spine

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

Spine Play Animation

Основной недостаток Spine в том, что система анимации на самом деле не связана с анриаловской. Всё, что нам дает Unreal (управление анимацией через Animation Blueprint, различные схемы блендинга, редакторы анимации и их последовательностей), — всё это мы не можем использовать для Spine и 2D-анимации. Придётся управлять анимацией и её переключением вручную, в функции Tick, и скорее всего, для этого понадобятся дополнительные таймеры и состояния. Чем-то такой подход напоминает старую систему анимации в Unity 4, в которой приходилось пользоваться функциями Play, Blend и CrossFade в компоненте Animation.

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

Оптимизация 2D в Unreal Engine 4


Типичный способ оптимизации — упаковка спрайтов уровня в атласы. Это избавляет нас от переключения текстур. В Unreal Engine, если вы перетащите на сцену даже несколько одинаковых спрайтов, получится столько же drawcall’ов. Встроенная автоматическая оптимизация рендеринга для 2D отсутствует, поэтому имеет смысл выделять некоторые части уровней, группировать с помощью инструмента MergeSprites. Команда Merge Sprites аналогична Merge Actors для 3D-объектов, она объединяет несколько объектов в один. Merge Sprites также объединяет коллизии объектов.

UE4 sprite mesh editing
Редактирование геометрии спрайта

Также в движке есть инструмент редактирования геометрии спрайтов. Как показано на картинке, он позволяет вместо стандартной прямоугольной формы спрайта задать свою. Например, вырезав прозрачность, можно уменьшить overdraw и тем самым увеличить производительность.

Как и в трёхмерной графике, в 2D актуальна оптимизация через material instance. Можно по привычке, как в Unity, копировать материалы, но в Unreal так делать не стоит. Лучше делать один или несколько базовых материалов, которые фактически описывают шейдер рендеринга, а на его основе сделать инстансы материала с набором изменяемых параметров (цветов, текстур и констант). За счёт этой оптимизации движку не нужно будет создавать большой набор скомпилированных версий шейдеров, что сэкономит размер проекта после сборки, освободит некоторые количество оперативной и видеопамяти, повысит производительность.

2D-ассеты (Marketplace)


Ускорить разработку прототипа игры зачастую позволяют ассеты, которые можно приобрести в магазине. По аналогии с Unity Asset Store у Epic Games есть Marketplace для UE4. 2D-ассетов в нём мало, но они есть. В основном это наборы арта: уровни и персонажи. Иногда встречаются шаблоны целых проектов типа платформеров, раннеров и т. п. Их можно использовать как основу проекта или для создания прототипов. Но, к сожалению, нет специальных инструментов для 2D-проектов, а также эффектов, ориентированных на 2D. В этом плане в Unity Asset Store всё гораздо лучше: больше возможностей, даже систем для 2D-анимации штук пять: Puppet2D, Anima2D и т. д.

Примечательные фичи UnrealEngine 4 в 2D


Мне удалось найти в анриале и несколько примечательных фич. Например, в спрайтовой анимации Paper2D flipbook можно для каждого кадра задать свой физический коллайдер. То есть вы сможете одним таким ассетом сделать необычный объект, например магические ворота, которые открываются и закрываются анимацией. Наверно, менять в каждом кадре collision не очень оптимально, но тем не менее такая возможность есть.

Sprite Shadows

На скриншоте трёхмерного персонажа окружают спрайты, отбрасывающие реалистичные тени. На самом деле они двумерные, и можно, не создавая специальных инструментов и костылей, включить от спрайтов 2D-тени и даже реакцию на освещение. Это делается заменой материала, используемого для спрайта. Для этого есть материалы Sprite Lit и Sprite Lit Shadows. Это может пригодиться, если ваша 2D-игра содержит в себе 3D-окружение, т. е. уровни трёхмерные, а сами персонажи при этом плоские. Например, в игре Ori And The Blind Forest есть такие элементы.

Также можно в настройках проекта включить специальную сортировку спрайтов. Если у вас обычный 2D-проект с видом сбоку, то вам, вероятно, не очень важно, как производится сортировка. Какие-то спрайты вы можете просто отодвинуть на задний план. Но если у вас изометрическая игра и нужен порядок расположения динамических объектов, то, возможно, имеет смысл выставить ось сортировки в виде оси вверх, и тогда они автоматически сами будут сортироваться.

Я встречал Unity-проект, в котором подобная сортировка была сделана в скрипте для каждого объекта. В Unity есть параметр для сортировки спрайтов — sorting layer offset, и каждый скрипт каждый кадр рассчитывал величину смещения на основе текущих координат объекта. Конечно, такой способ не может не повлиять на производительность. Ось сортировки спрайтов решает подобную задачу одним кликом.

Производительность UE 4 на мобильных устройствах


Есть миф, что на UE4 плохая производительность. Но на самом деле на нём вполне можно создавать эпичные по своей красоте проекты, даже в 3D. Впрочем, как и во всех движках, производительность и оптимизация связаны между собой. Просто надо учитывать это при разработке и своевременно заниматься профайлингом и оптимизацией. Что касается 2D, некоторые моменты я уже перечислил. Кроме того, возможно, вы захотите некоторые 2D-спрайты рисовать через canvas. Многое зависит от контекста и проекта в целом.

UE4 vs Unity 5: 2D


Подведём итог. Стоит ли вообще использовать Unreal и какие фичи критичны для разработки 2D-проектов, а какие нет? Я составил список в порядке важности фич.

Фича Unreal Engine 4 Unity 5
2D-физика Только Windows Да
Батчинг спрайтов Ручной Автоматический
Эффекты спрайтов Нет Да
2D-инструменты в Store Мало Да
Тени от спрайтов Да Нет
Визуальный «скрипт уровня» Да Нет
Тайловый редактор уровней Да Нет
Анимация модели столкновения Да Нет

Рассмотрим каждый пункт немного подробнее.

2D-физика. С моей точки зрения, основная проблема заключается в том, что в Unreal сейчас нет двумерной физики для большинства платформ, существует лишь экспериментальная реализации для Windows. Пока на большинстве платформ нет 2D-физики, это будет причинять боль и физику придётся делать через 3D-компоненты и искусственные ограничения.

Батчинг 2D-спрайтов. В Unity не пишется количество drawcall’ов для 2D-спрайтов, если мы добавим в сцену много 2D-спрайтов, это не будет отображено в окне статистики, но производительность говорит сама за себя — движок их всё-таки объединяет в группы при рендеринге. А в Unreal придётся использовать инструмент Merge Sprites или, возможно, ждать, когда появится более хорошее решение, чем существующая система Paper2D.

Эффекты спрайтов. В Unity можно найти различные ассеты для эффектов на спрайтах, в Unreal Engine этого пока нет.

2D-инструменты в Store. Для Unity есть различные инструменты в Store, т. е. и плагины, и расширения, и эффекты. В Unreal Marketplace, к сожалению, только 2D-проекты и их шаблоны, инструментарий почти отсутствует.

Дальше идут фичи, которые понадобятся не всякому проекту, например тени от спрайтов. Преимуществом Unreal можно считать визуальный скриптинг, в том числе блупринт логики уровня — Level Blueprint. Тайловый редактор уровней пригодится, если вы захотите сделать в Unreal олдскульную игру с «пиксельной» графикой. Почему бы и нет? И анимация модели коллизий — тоже интересная экспериментальная фича.

Заключение


Если подвести итог: в Unreal есть самые базовые инструменты для 2D, несмотря на наличие некоторых интересных фич. Если вы захотите использовать скелетную анимацию, вам придётся дополнительно изучать сторонние инструменты. Увы, пока нет удобства, аналогичного тому, которое Unreal предлагает в 3D. Основная проблема Unreal — отсутствие встроенной 2D-физики на всех платформах, кроме Windows.

Скорее всего, для большинства 2D-проектов разумнее взять какой-нибудь другой движок вместо Unreal. Но это всегда зависит от самого проекта, от ваших желаний, целей, потребностей.

Комментарии (23)


  1. Feelnside
    09.11.2017 14:33

    Видимо сравнения шли с Unity 5, т.к. в Unity 2017 очень много плюшек завезли для 2D разработки. К примеру Tilemap присутствует в Unity 2017.2 (https://unity3d.com/ru/unity/whats-new/unity-2017.2.0).


    1. ASDDeveloper Автор
      09.11.2017 14:38

      Да, сравнение Unity 5 и UE4 4.16


  1. o1o1o1o1o2
    09.11.2017 14:38

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


  1. bezarius
    09.11.2017 17:15

    Вообще то тени от спрайтов в юнити есть.

    image


  1. Senyaak
    09.11.2017 17:15

    Основная проблема Unreal — отсутствие встроенной 2D-физики


    Объясните пожалуйста зачем нуженo отдельнo 2D-физикa


    1. ASDDeveloper Автор
      09.11.2017 17:17

      Проще для реализации игровой механики, меньше багов, приносимых попытками "побороть" третье измерение, выше производительность. Не будет случаев, когда из-за физики объект улетит за границы 2D мира "в глубину".


      1. Watcover3396
        09.11.2017 19:15

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


        1. IamNoExist
          10.11.2017 10:15

          Это искусственное ограничение, всё будет по прежнему работать по избыточным алгоритмам которые учитывают 3d координаты. Просто третья координата всегда будет статичной. И если вам нужно много физики, то той пиковой производительности которые позволяют достичь алгоритмы которые учитывают 2d координаты, вы никогда не достигните. Но в большинстве случаев это конечно да, решение.


          1. Senyaak
            10.11.2017 10:49

            1. Не оптимизирует ли UE4 под копотом фиксирование позиций в определённой оси?
            2. Нужна ли такая оптимизация в нынешнее время, думаю даже мобильные дивайсы способны выполнять эти вычисления без влияния на производительность?


            1. Senyaak
              12.11.2017 15:43

              Только что глянул — в плагинах есть Paper2d, этого разве не достаточно?


  1. Virusmater
    09.11.2017 17:32

    Кто-нибудь может подсказать как правильно настроить камеру для создания псевдо 3д платформера, как, например, этот:

    Скрин
    image


    1. Tenebrius
      09.11.2017 17:45

      Если не ошибаюсь, это не псевдо, это вполне себе 3D, глубина же присутствует. Хотя персонажи спрайтовые. А камеру, получается, под углом ставить.


      1. Virusmater
        09.11.2017 18:39

        В том то и проблема, что персонажи не в 3D, а все остальное — 3D. Получается что ящик объемный, а персонаж — плоский. И если на плоский персонаж будет смотреть камера под углом, то геометрия персонажа нарушится и он станет сплюснутым. Следственно спрайт надо тоже под углом к камере располагать. И тогда если персонаж будет стоять около задней стены, то его часть уйдет в стену.


        1. Deosis
          10.11.2017 07:20

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


    1. lgorSL
      09.11.2017 19:08

      Элементарно, можно же вручную задать коэффициенты у матрицы камеры.
      Допустим, у нас есть какие-то внутриигровые координаты (x,y,z) — 'x' и 'z' по горизонтали, 'у' повертикали, и камера располагается на x_camera, y_camera.
      Нужно подобрать матрицу, чтобы её произведение с нашими координатами давало координаты на экране.
      Как видно, х_screen = x — z — x_camera
      y_screen = y + z — y_camera
      чтобы видеокарта рисовала более близкие элементы поверх далёких, можно ещё сделать z_screen = z.
      Из этого получается, что матрица камеры будет такой:


      (1, 0, -1, -x_camera)
      (0, 1, 1, -y_camera)
      (0, 0, 1, 0)
      (0, 0, 0, 1)

      Ну или транспонированной от этой.


      1. Virusmater
        09.11.2017 23:32

        Понятно что можно сделать что угодно высчитывая позицию камеры и игроков скриптами в той же Unity. Я про то, что обычными OOTB drag'n'drop методами Unity3d тут не обойтись


    1. Neuyazvimy1
      10.11.2017 12:23

      Там ортографическая камера + параллакс.


  1. AxisPod
    09.11.2017 17:49
    +1

    Увы, аркады может мелкие и норм на UE4 делать, но вот сложная логика и скриптинг на C++, лютое зло, учитывая, что документация вечно устаревшая, еще ладно на нормальные функции, но когда суют кругом макросы и документация по ним в большинстве своём вообще неактуальная, то это лютое зло. Да и полностью забить на идиологии разработки на C++. В итоге так и не стал использовать UE4.


  1. asknarin
    10.11.2017 14:20

    Не понимаю почему в первую очередь, говоря об анреале, точнее его преимуществах, говорят о блюпринтах? Они же годятся максимум для несложных прототипов и не более. Я лично пронаблюдал среди нескольких своих знакомых которые пробовали делать достаточно простые инди поделки без особых изысков и думали что смогут сделать на блюпринтах. Результат предсказуем (хотя во всех случаях я предупреждал что так будет) — один пошел делать на юнити и с# и выпустил 4 игры уже на айос. Двое других в итоге бросили свои начинания. Причём один ещё ладно достаточно быстро понял что без нормального программирования он не сможет реализовать свои идеи, а связываться с с++ нет желания просто забил. Другой же полтора года (!) убил на попытки таки довести всё на блюпринтах. Во всех трёх случаях это были очень простые в плане графики 2д игры — т.е. люди полезли в анреал не за графоном (а тут сложно критиковать — у анреала из коробки очень мощный инструментарий и хорошая оптимизация для графики близкой к фотореалистичной), а именно начитавшись статей и насмотревшись видео на ютюбе где восторженно расказывали что ВОТ! Вот всё теперь не надо ничего программировать! Даже если вы не программист вы можете без строчки кода сделать игру!
    Чувак который таки выпустил в итоге 4 игры на юнити потом сказал что конечно хорошо что научился в юнити работать на первых двух проектах которыебыли совсем простые но сейчас бы он их на гейммейкере сделал бы.
    Вобщем история про гвозди и микроскоп.


    1. ASDDeveloper Автор
      10.11.2017 14:37

      Unreal сам по себе весьма непростой движок, поэтому полтора года, особенно если человек начинающий, не так много. У многих инди проектов судьба печальная и зачастую не сильно зависит от используемого движка. Как говорится, "нельзя так просто взять и зарелизить свой первый проект". Конечно, базовые знания программирования (функции, циклы, переменные и т.п.) необходимы, чтобы хоть что-то реализовать на блупринтах. Блупринты хвалят, так как они предоставляют средства, которыми могут пользоваться не только программисты. В сложных проектах они тоже используются вовсю, просто основная часть сложных систем реализована на C++, а для блупринтов доступны функции взаимодействия с ними.


    1. Heinhain
      11.11.2017 09:49

      Больше всего удивляют высказывания вроде «на UE4 можно создать игры БЕЗ программирования!» — вот, где реальная подмена понятий и откровенная ложь. Справедливости ради, простые игры типа марио или какой-нибудь метроидвании вполне реально собрать на принтах, но идея, как ни крути, сомнительная.


  1. asknarin
    10.11.2017 20:15

    я то сам не против визуального программирования как идеи — я сам работаю много в такой программе как Houdini в которой почти всё на этом построено. Для работы с шейдерами на хай левеле это вобще идеальный практически подход — он и в оффлайн рендер системах стал стандартом уже давно (даже реньше чем сами блюпринцы появились).
    Понятно что профессионал будет знать какой инструмент лучше подходит для каких задач и будет использовать когда это выгодно — и блюпринты, и юнитевские разнообразные аналоги типа плеймейкера.
    Моя же претензия не к технологии, а к тому как сами Эпики и всевозможные популяризаторы движка агрессивно пиарят эту тулзу как панацею от необходимости кодить. Это приводит к тому что новички ставшие жертвой этого маркетинга убивают кучу времени впустую и часо просто бросают это всё вапще. Что может быть и неплохо но не очень честно.


    1. asknarin
      10.11.2017 20:28

      Добабавлю, чувак который свичнулся на юнити+с# никогда не программировал, исключительный гуманитарий (образование режиссёрское, работал режиссёром монтажа) — идельная ЦА для маркетинга таких инстурментов «шоб не программировать». В итоге без проблем освоил шарп и на третьей игре уже осилил клиент-сервер архитектуру для мультиплеера реюзая куски чужого кода и готовые модули, естествено.