Поддержите разработчиков - страница игры на UEDC 2020

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

Слэшер-платформер Demon Skin прошел нелегкий путь длиной в 6 лет. За это время произошло немало: переход из 2D в 3D, смена движка, ребрендинг каждые два года, две неудачные краудфандинговые кампании, бесконечные смены состава команды… Несмотря на трудности, основатель проекта и по совместительству геймдизайнер Денис Листов не отказался от своей идеи и верит, что его игра будет интересна людям. Подав заявку на конкурс, он решил поделиться историей разработки и рассказать о своей заветной мечте, ради которой он в свое время не пожалел ни денег, ни времени, а в отдельные моменты даже рисковал собственным здоровьем.

Поиск единомышленников и первые контакты с инвесторами.

Все началось в 2014 году. Именно тогда Денису пришла в голову мысль сделать игру, которая воплотила бы все его задумки на экране монитора. Так как его деятельность не была связана с разработкой, он принял решение всему научиться сам. Программирование, анимация, графика — все это приходилось осваивать в свободное от основной работы время, включая выходные. Через полгода интенсивного обучения Денис понял, что в одиночку задумку не осуществить. Стал мониторить тематические форумы и искать единомышленников, попутно продолжая учиться. Но согласных участвовать в проекте за идею он так и не нашел.

Денис пришел к выводу, что раз энтузиасты не горят желанием присоединиться — нужны профессионалы, которые качественно выполнят его задумки за деньги. Следовательно, необходимо искать финансирование. Он подготовил необходимую документацию, концепты и занялся поисками инвестора. Разослал сотни писем в соцсетях успешным бизнесменам. Игрой заинтересовалась группа состоятельных молодых людей. Они были готовы профинансировать игру, но поставили условие, что Денис должен найти команду для разработки. На переговоры ушло около двух месяцев. За это время нашелся программист, аниматор и художник. А после случилось то, чем в наше время мало кого удивишь, но для новичка в игровой индустрии оказалось шоком.

Денис Листов: "Мне позвонили и сказали: “Ну вот, теперь у тебя есть команда, молодец. А мы еще раз посовещались и решили, что пока не хотим инвестировать.” Я очень удивился, ведь все это время мы позитивно общались, и казалось, что они согласятся. Можно было поседеть от расстройства…"

“Столько сил вложено, а ничего не выходит”

Так как попытка получить нужную сумму от инвесторов потерпела фиаско, Денис взял кредит, чтобы с него платить зарплату уже собранной команде и двигаться дальше. Он надеялся, что когда появятся первые серьезные результаты разработки, будет гораздо проще найти финансирование. К сожалению, на этой стадии особого прогресса не наблюдалось. Некоторые специалисты не всегда понимали ТЗ, которые ставил перед ними Денис и делали по-своему. Как итог — многочисленные переделки, которые затормаживали процесс. С другой стороны, именно на этом этапе выяснилось, что игру нужно переводить в 3D формат из-за очень большого кол-во анимаций на каждом персонаже: полигональную модель можно развернуть как угодно и не нужно рисовать каждый кадр, а значит сокращается время производства, так как некоторые анимации можно уже готовые брать.

Денис не прекращал попыток найти инвестора. У игры уже был в наличии ранний прототип под названием The Forging Destiny Hrof. В качестве эксперимента была запущена кампания на Boomstarter.

Геймдизайнер не питал особых надежд насчет этой площадки, но тестировать механику краудфандинга пришлось бы в любом случае. В итоге проект собрал всего 18 000 руб из заявленного миллиона. Но был и положительный момент: игрой заинтересовался инвестор и согласился помочь, но бюджет пришлось урезать. Так как это был единственный на тот момент вариант, чтобы продолжить работу над игрой, пришлось согласиться. В результате был собран первый билд и сделано множество моделей, большая часть которых используется в игре до сих пор. Но время шло, из-за ограниченного бюджета выплачивать полноценную зарплату сотрудникам было невозможно, не говоря уже о расширении штата. Когда деньги инвестора были исчерпаны, коллектив распался. Никто не верил, что проект может действительно когда-то выйти.

Денис Листов: "Все сотрудники твердили мне, что если я хочу что-то сделать, я должен сам всему научиться. Серьезно освоить программирование, анимацию и прочие аспекты. Но мне потребуется несколько лет, чтобы выйти на уровень выше среднего в этих специализациях, так как конкретно эта игра задает именно такую планку. И это явно не 3-4 года. А ведь в разработке есть еще другие задачи, которые нужно решать. Конечно, можно было начать с чего-то попроще. Но у меня в голове была только эта игра."

Тем временем, страница игры в VK стала набирать популярность. Люди видели, что несмотря на все невзгоды, Денис не опустил руки и продолжает работать. Некоторые участники сообщества изъявили желание принять участие в проекте на полном энтузиазме. Так к команде присоединился дизайнер, аниматор и программист. Переосмыслился геймплей, сюжет, персонажи и игра стала называться A.S.H. (About Savior Hunter).

Еще две версии персонажа. Из-за технических моментов выбрали правого.

Казалось, на новом этапе все наладится, но проблем не убавлялось. Управлять коллективом, который работает за идею, оказалось непросто. У людей нет обязательств, а значит, они запросто могут отказаться что-то переделать, если их мнение не совпадает с видением геймдизайнера. Более того, добровольцы всегда могут покинуть проект без объяснения причин, если им что-то не понравится: всегда есть оплачиваемые альтернативы.

В погоне за мечтой Денис нередко прибегал к отчаянным решениям. В разработке был период, когда движения персонажей нужно было сделать более живыми. Видя это, геймдизайнер решил прибегнуть к услугам мокап студии. Удовольствие не из дешевых, пришлось продать машину. Первый удаленный заказ на анимацию в московской студии вышел комом. И хотя геймдизайнер демонстрировал исполнителям на видео каждое движение персонажей, позже выяснилось, что их даже не смотрели. Он решился на вторую попытку, но на этот раз собирался лично приехать из Архангельска в Москву, снять студию на день, облачиться в костюм с датчиками и изобразить все необходимые движения на камеру. Согласовал дату съемок со студией и начал готовиться. Даже репетировал с палкой движения перед зеркалом. Казалось, что все продумано до мелочей…

Денис Листов: "У меня никогда такого в жизни не было. После домашних репетиций я потянул мышцу на ноге так, что не мог двигаться. В больнице мне сказали, что я восстановлюсь через полторы недели. А съемки должны состояться через 2 дня. Перенести уже нельзя, так как студия забронирована и билеты в Москву куплены. Решил ехать. Превозмогая боль, кое-как дошел до поезда. Помогло обезболивающее и в назначенный день я все же через боль смог ходить. В процессе съемок (5 часов на ногах)  боль стало невозможно терпеть , но все запланированные анимации удалось доделать. Все движения получились так, как задумывались, но это было только на видео. Когда их надевали на персонажа, что-то было не то.... В итоге, над анимациями пришлось изрядно поработать и долго их вычищать, но мы всё равно не добились нужного результата."

Спустя какое-то время Денис принял решение вновь попробовать краудфандинг и на этот раз разместить проект на Kickstarter. Из-за недостатка пиара кампания в очередной раз провалилась (хотя в этот раз удалось собрать уже 70 000 руб), а команда разбежалась, не видя перспектив. И снова основатель решил заняться поиском финансирования. Казалось, что во второй раз на грабли наступить невозможно... Новый инвестор после трех месяцев переговоров согласился поддержать проект с условием, что разработчик найдет сразу и команду, и издателя. Второе условие было фактически невыполнимым, так как прототип все еще был сырой и вряд ли бы нашелся паблишер, который поверил бы в него. Каким-то чудом все требования удалось выполнить. Издатель переговорил с новым штатом команды, все были настроены серьезно и ждали совершения сделки. Через неделю Денис получил письмо, в котором инвестор проинформировал, что принял решение взять другие проекты.

Денис Листов: "В какой-то момент на меня уже начала наседать семья, чтобы я забыл об этом проекте. Ведь столько сил вложено, а ничего не выходит. Который год все разваливается в определенный момент, а прогресс в разработке минимальный. Да, какое-то продвижение есть, но этого недостаточно. Я начал понимать, что инвесторов что-то отталкивает. А значит, нужно найти с ними больше точек соприкосновения…"

Когда упорство все же побеждает

Геймдизайнер перешел к активным действиям. Информация о проекте была размещена на сотне сайтов по инвестированию, в том числе зарубежных. Стали приходить сообщения от заинтересованных лиц из разных стран. Все утверждали, что видят в проекте потенциал, а через пару недель исчезали из виду. Так продолжалось долгое время, пока не появился один инвестор. До этого момента пришло уже около 15 отказов, поэтому в серьезность его намерений профинансировать игру поверить было сложно. Переговоры продолжались несколько месяцев, и наконец, стороны подписали договор. Теперь можно было нанять команду профессионалов и сделать играбельный билд, который не стыдно показать. К работе подключились два программиста, левел-дизайнер, аниматор, а также моделлеры с частичной занятостью.

А в последние 2 месяца намечается плотная работа со звукорежиссером и композитором. Фактически, все члены студии — это контрактеры, которые за зарплату осуществляют задумки геймдизайнера. Но при этом они крайне ответственно относятся к своей работе и стараются выполнить ее на высшем уровне. Сейчас коллектив под названием Ludus Future трудится по 12-16 часов в сутки, иногда без выходных, по собственной инициативе. Сам Денис слово “студия” не очень любит — слишком официально. А в коллективе все же преобладают дружеские отношения, несмотря на то, что все участники проекта живут в разных регионах страны.

Что же получилось в итоге?

Билд, который Денис отправил на DevGAMM Online, а затем и на UEDC-2020 — колоссальная работа, над которой коллектив трудился в течение полугода. Изменился сюжет, главный герой, а сам проект получил название Demon Skin.

Главный персонаж игры — Рой — состоит в Ордене Странников. Их основная задача — путешествовать по мирам и уничтожать зло. Во время такого похода он погнался за слугами враждебной фракции Хаоса. Но какая-то неведомая сила призывает врагов в портал, и Рой следует за ними.

После телепортации странник понимает, что оказывается в поселении, охваченном огнем: адепты трех зловещих фракций сражаются между собой, а люди в этой войне — просто пушечное мясо. Внимание Роя привлекает некий кристалл, который пытаются пробудить во время этой бойни с помощью жертвоприношений. Странник не понимает смысла ритуала, но осознает, что кристалл — главный источник зла. Так как полчища злодеев ему не убить, возможно, стоит пробраться к алтарю и уничтожить артефакт? Когда Рой разбивает кристалл, происходит кульминация ритуала, и луч с неба проходит сквозь главного героя. После этого происходит мощный взрыв, который уничтожает все живое. Когда Рой очнулся, он уже не был прежним. Из-за луча он утратил свой человеческий облик и потерял память. В этот момент из портала появляется неизвестный и забирает кристалл. Несмотря на то, что Рой ничего не помнит, разум у него остался. Обессиленный, но все еще живой, он отправляется в путь, чтобы найти артефакт и вернуть его на место.

Это уже третья версия рисованного ролика за 4 года.

Demon Skin представляет собой 3D платформер с элементами RPG, где основной акцент делается на melee-бои. В качестве основного референса геймдизайнер ориентируется на Severance: Blade of Darkness. Игре почти 20 лет, и о ней мало кто помнит. Но Денис до сих пор считает, что в этой игре была лучшая система ближнего боя.

Денис Листов: "В Severance: Blade of Darkness был один жирный минус: слишком высокий порог вхождения. Новая и поначалу сложная механика, агрессивные противники — точно не для казуалов. Люди просто не могли разобраться, как в нее играть. Возможно, она просто вышла не в свое время. Я решил создать игру со схожей атмосферой, перевел в платформер и добавил своих идей."

Как и чем убивают в Demon Skin

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

Изначально было задумано, что в этом случае персонаж будет полностью обессилен, как это было в Severance: Blade of Darkness, но такое геймдизайнерское решение жестко раскритиковали потенциальные игроки. Также была продумана система дополнительных ударов, которая появляется рандомно в бою. Когда индикатор определенной стойки начинает подсвечиваться синим цветом — можно оперативно переключиться на нее и нанести удар. Здоровья это врагу не убавит, но у игрока будет преимущество на пару секунд, например, чтобы нанести супер удар.

Если в этом случае у врага меньше 30% HP, игрок просто эффектно его добьет. Данная механика поможет как казуалам-кликерам, которых больше интересует сюжет, а не боевка, так и хардкорным игрокам в исполнении “фаталити”: не обязательно прожимать комбинации кнопок каждый раз ради эффектной казни.

С каждым убийством у героя будет накапливаться опыт и трансформироваться в очки, которые можно потратить на апгрейд базовых характеристик: HP, выносливость и атаку. При повышении уровня будут открываться новые комбо для оружия. Да и сам протагонист по мере прохождения будет внешне меняться, за счет осколков кристаллов, которые будет собирать на протяжении игры.

Арсенал героя состоит из рубящего (мечи, топоры) и дробящего (молоты) оружия. Разнообразие аргументировано боевыми свойствами: рубящее оружие наносит 100% дамаг по существам из плоти, в остальных случаях его эффективность падает на 30%. Именно поэтому перед схваткой со скелетами, панцирными насекомыми или големами рекомендуется выбрать дробящее оружие: в этом случае враг получит 100% урон.

В билде уже есть этот удар, у него интересный звук.

Все вооружение делится на три категории: обычное, именное и артефактное (аналог “легендарки”). Его качество влияет не только на характеристики, но и на мощность комбо: если комбо с именным оружием может нанести 3x-5x урон, то артефактное бьет магическими ударами мощностью 10x-15x, но только в том случае, если будет заполнена специальная шкала. Ее, в свою очередь, можно пополнять за счет убийств врагов.

Когда противник — не просто набор полигонов и анимаций.

Враги в Demon Skin представляют особый интерес. Так как Денис придерживается канонов средневекового фэнтези, в игре будут встречаться нежити, вурдалаки, некроманты, дворфы, механические големы и представители фауны. Интересно, что противники поделены по фракциям и нередко будут воевать между собой. Например, Дергер (дворф) враждебно настроен к нежити и насекомым, но не будет драться с механическим големом, так как это его творение. Также и не все животные смогут ужиться друг с другом: богомол нападет на паука, если встретит его на своем пути. Игроку придется сделать выбор, как поступить в такой ситуации.

Денис Листов: "Здесь каждый сам за себя. Например, игрок перейдет на следующую локацию, а там три дворфа сражаются против огромного богомола. В этот момент вступать в бой невыгодно: проще понаблюдать со стороны и решить, стоит вмешиваться, или нет. Так или иначе, придется пройти этот этап. Можно ударить и с помощью переката убежать от врага, но тогда игрок пропустит много экспы. А фарм опыта ограничен, так как на локациях расставлено определенное количество врагов."

Каждому противнику присуще свое поведение. Зомби и скелеты уже мертвы, поэтому просто идут вперед. Вурдалаки и оборотни хитрее: они выбирают момент для атаки. Дворф в бою может воспользоваться эвейдом игрока и выпить исцеляющее зелье, или, наоборот, выбить зелье из рук героя, чтобы тот не смог отхилиться. Завидев героя, враг может принять боевую стойку и даст понять, что с ним шутки плохи. Если это насекомое — зароется под землю или убежит из поля зрения, чтобы атаковать сверху или с противоположной стороны. Подобные детали требуют от игрока более вдумчивого подхода к энкаунтерам и избавляют от монотонных стычек. Следовательно, игра не даст заскучать, а игрок получит удовольствие от боя.

Боссов как таковых в игре нет. Геймдизайнер считает, что определение "сильный персонаж" наиболее точно в рамках геймплея Demon Skin. Как правило, бой с боссом происходит на определенной логической точке уровня. В Demon Skin появление сильных персонажей не зависит от какого-то определенного этапа: их наличие на локации обусловлено только сюжетом, поэтому с ними можно столкнуться и в середине прохождения. Возможно, по аналогии с боссами в других играх, игрок повстречает сильных персонажей и в конце уровня, но только из-за того, что там возникнет определенный сюжетный поворот.

Когда окружение оживает.

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

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

Планы на будущее

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

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

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

Омрачает ситуацию то, что этого самого времени остается не так много. Деньги, выделенные инвестором, заканчиваются уже в июле. Это значит, что команду профессионалов будет не на что содержать. Основатель проекта не хочет расставаться с коллективом, но понимает, что работникам тоже нужно на что-то жить. Сценарий не из лучших, тем более, что Денис считает, что у него работают отличные специалисты, и в перспективе с Ludus Future можно создать еще немало игр. Команде требуется еще 3 месяца на доработку и уже можно будет выставить на продажу, а потом со временем выпускать к ней обновления. Менять график разработки Денис больше не может, так как договор, накладывающий определенные обязательства, давно подписан, и его невыполнение грозит серьезными санкциями. Продажей машины в этом случае уже не отделаться.

Последние месяцы Денис активно ищет издателя, чтобы профинансировать необходимое время для разработки и найти мощную маркетинговую поддержку. Узнав на конференции DevGAMM, что конкурс UEDC-2020 начал прием работ, он решил подать заявку, в надежде, что это поможет получить проекту дополнительное освещение.

Пример Demon Skin интересен тем, игра фактически делается "под заказ". Но не стоит думать, что основатель ориентируется исключительно на свое видение проекта. В группе сообщества Денис регулярно советуется с потенциальными игроками по поводу тех или иных аспектов, ведь все эти годы игра создавалась именно для них.

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

Игрок стоит посреди деревни и почти не двигается. Постепенно наступает закат, естественного освещения становится всё меньше, наступает ночь. В тёмное время суток без фонарика почти ничего не видно, а костры освещают лишь небольшой участок вокруг себя.

Ivan Sorce реализовал управление транспортом с видом от первого и третьего лица, но этот аспект игры пока только тестируется. Автору ещё предстоит добавить модель персонажа в автомобиль и реалистичный звук движка, избавиться от неестественного скольжения во время поворотов и в целом доработать физические свойства техники.

Видео посвящено исследованию разнообразных локаций. Автор заглядывает в разнообразные здания, рассматривает окружение. Все помещения пустые, внутри некоторых из них горит свет. Что касается текстур, то местами они подобраны не совсем подходяще.

Ранее автор демонстрировал сталкеров в деревне Новичков и бункер Сидоровича.

Источник 1, Источник 2, Источник 3

Дата выхода проекта: неизвестна

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

Разгрузочный день, смотрим на щиты:)

По обычаю немного лора. Сегодня отрывок из рассказа о месте, с которым связана история основания города Вендаля - столицы гётов, откуда берет свое начало Великий род Конунгов, объединивший все северные племена в единое целое.

P.S. Собственное оформление заднего плана все еще в работе.

Всех благодарим за внимание! Комментируйте, не стесняйтесь, мы всем рады.

Группа вк - https://vk.com/club191083624

Попробуем представить мир языческой религии скандинавов и показать вам идолов (чуров) в нашей обработке. Деревянные изваяния не сохранились до наших дней, а их подробные описания у современников отсутствуют. Кроме того, напоминаем, что у нас dark fantasy, и мы не претендуем на “историчность” (но в целом опираемся на известные источники).

А вот те самые чуры, которые окружают капище и встречают в главном меню...

И немного озвучки…

Хотим представить вам голос Скегги (главного героя), сына Игмунда из рода Йомсвикингов.

А также познакомьтесь с Эгилем - персонажем из произведения “Сага об Эгиле”. Пересказ саги не гарантируем, но читавшие встретят множество знакомых моментов. Кстати, Эгиль, как и другие известные персонажи саг, будут играть не последнюю роль в мире “Хельхейма”.

Знакомство с Эгилем, сыном Скаллагрима.

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

Всех благодарим за внимание! Комментируйте, не стесняйтесь, мы всем рады.

Группа в вк- https://vk.com/club191083624

Здесь можно увидеть геймплейный трейлер

- https://www.youtube.com/watch?v=Pswexg9GuEo&feature=youtu.be

Ниже прошу написать ваши впечатления, пожелания, предложения, баги. (Гифки, видео приветствуются).

Ссылка на билд - https://drive.google.com/file/d/1AtgaKX8FAbk1wAe29dnHE1D2gdD...

Если кто -то располагает временем, то просим сделать видео на ютубе например с комментариями или без них. Или если есть возможность отправьте какого нибудь стримеру, пусть он посмотрит.

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

Комфортно-минимальные системные требования

Юнити: видеокарта на 2гб+, 4-8 гб оперативы, проц 2+ ядра на 2.5 ГГЦ+

UE4: видеокарта на 2гб+, 8-16 гб оперативы, проц 4+ ядра на 3 ГГЦ+

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

Оперативная память и её текучесть

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

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

Однако я не заметил, чтобы UE хоть как-то освобождал память самостоятельно в отличии от Unity.

Но у UE есть еще один грех: бывает, что вы откроете какую-то большую сцену и она откроется нормально, потом закроете UE, попытаетесь открыть ииии... он не открывается! Выпадает с ошибкой, потому что оперативной памяти ему не хватило (такое бывает, если ссылочная масса плохая). Приходится очищать Intermediate папку, чтобы не открывало эту сцену сразу. Можно, конечно, установить себе просто 64-128 гб и не ловить таких проблем.

Физические размеры проекта

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

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

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

Примерные размеры движка UE - 70 гб.

Примерные размеры движка Unity - 2 гб.

Но так же папка GIT\SVN и Intermediate в UE весят просто безумно много потому что все предыдущие версии ассетов там хранятся, что позволяет вам смотреть версии блупринтов через Version Check (который, к слову, очень долго грузится. По 2 минуты на каждое открытие, потому что сделано настолько топорно, что тупо грузит все данные что есть, а потом отображает, вместо того, чтобы грузить указанное количество версий ДО). А сами блупринты весят очень много относительно скриптов в юнити, поэтому и размеры проекта отличаются разительно.

Также папка Intermediate есть и в директории проекта и в директории движка и они обе копят мусор бесконечно. Т.е. для нормальной работы в UE вам нужно где-то 300-500 гб. свободных.

GIT\SVN\Система контроля версий

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

Дело в том, что все ассеты Unreal (кроме кода), включая блупринты НЕ МЁРЖАТСЯ. Т.е. если вы изменили что-то в блупринте какого-либо объекта, и кто-то уже изменил его и залил в GIT, то у вас есть возможность либо взять его изменения и по памяти (либо достав автосейв из папки проекта) копировать абсолютно всё, что вы писали и надеятся, что никто в этот момент ещё раз не залил этот ассет, иначе вам придётся всё повторять и снова надеятся, что никто его не изменит.

Т.е. ситуация такая:

ᅠ1. Вы добавляете в блупринт какой-то код минут 10

ᅠ2. Кто-то наверняка что-то залил в гит в это время, поэтому вы закрываете редактор (чтобы залить в гит, потому что с открытым редактором нельзя сделать pull из гита (отдельный лол))

ᅠ3. Делаете pull и обнаруживаете конфликт вашего блупринта - похоже кто-то его изменил! У вас есть вариант: взять вариант из гита (потеряв свои изменений), просто перетереть чужую работу своей версией (этот человек будет не рад до уровня жалобы начальнику, что вы немного оборзели).

ᅠ4. Допустим, вы берете из гита версию. Дальше вы открываете редактор, минут 5 добавляете свои прошлые изменения, еще минуты 2 проверяете, что все работает.

ᅠ5 .Закрываете редактор.

ᅠ6. Снова пытаетесь сделать pull и снова кто-то перезалил файл!

ᅠ7. И вы вот так вот маструбируете ассетом туда сюда, тратя кучу времени и нервов, чтобы залить свою работу.

По моему опыту в работе небольшой командой (6-7 человек) бывало, что приходилось сделать 4 итерации такие, чтобы залить свою работу. А если в команде человек 50? А ведь некоторые сущности Unreal существуют в одном экземпляре, типа GameInstance, GameMode, PlayerController, PlayerState, GameState.

С помощью SVN вы можете заливать свои ассеты без pull-а (т.е. не закрывая редактор), но вы просто перетираете ту версию, которая там лежит (но в SVN сложно с фичами и ветками работать) Т.е. это вариант для дизайнеров, которые сами со своими файлами работают и туда никто не лезет.

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

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

Data view/удобное отображение данных ассетов для геймдизайнеров и программистов

Постоянно в процессе разработки любой игры есть необходимость настраивать баланс. Баланс между мобами, оружием, умениями, фракциями и так далее. Какие инструменты для удобной настройки баланса могут предложить нам UE и Unity?

Общее:

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

UE:

Для хранения систематизированных данных в Анриле есть только DataTable. Ничего больше. Он просто хранит массив каких-то структур в статике. Т.е. если у вас есть типы персонажей, то вы заводите всех и общие поля в какую-то структуру и потом, в самом ассете персонажа вы достаёте данные из структуры и назначаете значения переменных ассета.

А что делать, если у определенных классов есть особые переменные? Вносить их тоже в структуру. Выходит, что рядом с общими переменными нужно создавать поля для особых переменных, которые встречаются всего в одном классе, ибо структуры не наследуются.

Удобно ли это? Нет. Это полная дичь, но вариантов нет. Зачастую, ваша структура будет иметь 20-40 полей (что очень дофига) и каждое поле вы должны будете ручками назначить для переменных. Дичь полнейшая, но других вариантов нет.

Unity:

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

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

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

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

Unreal:
Так как списком в Unreal можно смотреть только структуры, то данные оружия и патронов должны быть в структурах, а потом нужно создать класс, который содержит поле этой структуры и в констракшн скрипте берёт из таблицы эту структуру и назначает её переменной. Т.к. ссылку на структуру дать нельзя и удобно просматривать переменные классов тоже нельзя. Так как в классах от UObject нет Construction Script, то наши Ammo должны лежать в Actor классе.

Т.е. мы создали уже 6 сущностей (структуру аммо, дататейбл, класс, структуру оружия, дататейбл, класс).

Помимо этого, создавая каждый раз оружие новое или патроны, нужно не забыть добавить его в дататейбл, создать нового эктора, перегрузить его Construction Script и так далее.

Скрины:

Unity:
ᅠ1. Создаём класс weapon
ᅠ2. Создаём класс ammo
ᅠ3. Создаём инстансы классов
ᅠ4. Открываем плагин Fast Data View и видим их все в удобном списке с возможностью показать их все сразу рядом и изменить размеры, отображения, видимые\скрытые переменные, сделать выборку переменных из списков и прочее, прочее.

Скрины:

Итог:
У юнити мы создали всего 2 сущности, которые не требуют никаких извращений и получили наиболее удачное и лёгкое отображение данных, которое можно создать\изменить абсолютно для любого класса за одну минуту.

У анрила мы создали целых 6 сущностей, список которых можно видеть только в убогом оконце DataTable, вид данных изменять никак нельзя, классы нужно заранее прописывать (т.е. просто так взять любой класс и посмотреть список объектов от этого класса и значения его переменных списком нельзя).

К тому же, так как в c++ нет свойств (get; set), то мы не можем видеть там функции, которые показывали бы суммы каких-то данных, а в Unity мы видим в полях Damage и DamagePerSecond динамически изменяемые свойства (по сути функции, но на скринах не показал их, т.к. в анриле такого нет даже рядом).

Разницы в удобстве и подходе, как по мне, очевидная.

Архитектура

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

Unreal сажает вас на свою собственную архитектуру и подход от которого отойти практически нереально.

У Unity есть ряд сущностей: gameObject, prefab, scriptable object, monoBehaviour components
У Unreal: GameInstance, GameMode, PlayerController, PlayerState, GameState, Pawn, Actor, Character, Child Actor, Actor Component, Scene component, Character Movement Component и еще ряд компонентов со своими особенностями.

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

К тому же, для понимания положения, чтобы перенести какие-либо данные, либо объекты между уровнями нужно сделать следующее:
Unity: добавить на любой gameobject скрипт DontDestroyOnLoad
Unreal: добавить данные в класс GameInstance.

Т.е. у анрила есть только один объект, который может переносить информацию между уровнями и в крупных командах будет постоянно столкновение лбами на этом объекте, потому что он нужен всем и умеет переносить только типы значений. Все ссылки будут удалены. Т.е. все данные, что вы хотите переносить должны храниться в структурах и ни в коем случае не в классах. И любые объекты на сцене перенести НЕВОЗМОЖНО. Т.е. вы даже чисто теоретически не можете многие вещи сделать независимыми модулями, т.к. в ряде общих объектов вы будете вынуждены вносить какие-то данные.

Графика\качество картинки итогового продукта

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

Хоть эпики и полностью делают ставку на графику во всех своих разработках и рекламах, графика Fortnite крайне далека от показываемой ими фотореалистичности и детализированности сцены. Т.е. сами эпики своей "супер фотореалистичной" графикой в своих проектах не пользуются. Почему? Вопрос открытый.

Внешний вид редактора

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

Отладка

Отладка идентичная. Всё примерно 1 в 1. Т.к. оптимизация - это то, что мне больше всего нравится в разработке, то я изучил все тулзы и они плюс-минус идентичные.

Код

Бытует мнение, что код на ++ более "правильный" для разработки, более православный (не зря же в названии целых ДВА креста), а #, мол, для работяг, потому что на ++ написано большинство движков и игр, но вот моё мнение и аргументы на тему сравнения ++ и #, соглашаться или нет - дело ваше:

ᅠ1. Когда разработка игр набирала обороты и индустрия только появлялась, то # еще только-только появился, поэтому специалистов на нём было мало. Был С и был С++ и люди выбрали С++ из-за ООП и более строгой типизации и меньше шансов себе в колено выстрелить, но у C# в этом всём еще больше строгости и меньше вариантов ошибки. Я считаю, что если бы индустрия появлялась сейчас, то все бы выбрали C#.

ᅠ2. С# на всех проектах одинаковый, С++ на каждом проекте абсолютно разный. Подход к коду в С++ на каждом проекте абсолютно другой.

Если вы работали на UE c C++, то придя в какой-то другой проект на C++, то вы поймёте, что подход, функции и код абсолютно другой. Т.е., например, в коде UE очень не рекомендуют использовать стандартные библиотеки С++, т.е. то, что вы учили в универе вам не слишком поможет.

На С# я писал .net приложения, Unity приложения, немного сайты - все практически идентичное, кроме некоторых моментов.

Таким образом, работая с С# на Unity у вас больше возможных путей развития, чем c C++ Unreal.

ᅠ3. Омега душная история с хидерами и PCH в С++. Бывает, что копируешь все хидеры из одного класса в другой, пытаешься использовать функции из них и функции не находит! И ты бесконечно долго сидишь и ломаешь голову почему и как это решить. В C# такой ерунды нет даже рядом, поэтому обучение C# и написание кода идёт намного быстрее. Да и если ты даже немного накосячишь с хидерами в C++, то редактор может начать в разы дольше запускаться, что тоже не круто.

ᅠ4. Все модули, которые требуют высокой производительности, можно написать на любом языке и закрыть в dll (лично я в своей практике таких потребностей не встречал).

Блупринты

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

Зачем он придуман?

ᅠПотому что осилить анриловский код на С++ не только лишь все могут, а так как Unreal - это движок написанный дизайнерами для дизайнеров, то придумали блупринты.

Разработчики утверждают, что вы можете использовать блупринты или код - как захотите. Мол, если вы решили использовать блупринты, то код вам совсем не нужно писать. ЭТО ВСЁ ЛОЖЬ!

Вы обязаны использовать и код, и блупринты. Без вариантов.

Блупринтами вы не сделаете и 10% того, что можете сделать кодом, а от попытки использовать некоторые вещи в коде - вы посидеете.

Минусы работы с кодом:

ᅠ1. Если вы даже немного накосячите в хидерами и ссылочной массой, то код будет компилиться очень долго. Каждый раз при изменение кода вы будете долго сидеть и ждать пока он компильнется.

ᅠ2. Некоторые фичи использовать в коде больно физически. Например, система переводов - она нацелена на использование исключительно из блупринтов.

ᅠ3. Можно косякнуть легко.

ᅠ4. Добавив новый класс нужно ручками нажимать на "Generate Visual Studio project files".

Минусы работы с блупринтами:

ᅠ1. Не сделать большинство вещей, что приходят на ум программисту, но не приходят на ум дизайнеру. Например, взять все кнопки на всех виджетах и назначить им какой-либо звук, либо зашифровать строку, либо разрезать меш на несколько частей и тд. тп.

ᅠ2. Каждая прямая ссылка на каждый объект наращивает ссылочную массу, что повышает время запуска редактора. Если объект ссылается на объект, который ссылается в свою очередь на ссылаемый объект, то время загрузки редактора растёт. Даже если объект будет ссылаться на объект и где-то там в ссылках у этого объекта есть объект, которые ссылается на первый объект, то это повысит время загрузки редактора.

ᅠ3. Блупринты не мёржатся.

ᅠ4. В целом на блупринтах писать дольше, чем обычным кодом.

ᅠ5. Все математические вычисления в блупринтах потребляют больше ресурсов.

ᅠ6. Чтобы функции\переменные были видны в редакторе необходимо их особым способом помечать, поэтому многие вещи изначально скрыты в блупринтах. И для того, чтобы, например, юзать SteamSDK в блупринтах придётся либо пару месяцев писать обёртку под блупринты, либо купить готовый плагин обёртки за деньги (который периодически с обновлением движка ломается).

Почему блупринты в целом порочная концепция?

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

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

Звук

Я бы сказал, что он примерно одинаковый и там, и там, но я с ним не работал, поэтому за достоверность не ручаюсь. Да и по качеству звука оценить разницу не могу, но так или иначе всё равно многие крупные компании выбирают имплементировать Wwise даже при том, что он забирает 5% от доходов.

Расширений редактора

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

Подход к мультиплееру

Изначально, в UE мультиплеер как бы подразумевается как данность, т.е. все объекты имеют плашку сериализации, а все функции можно сразу помечать как мультикасты\серверные\клиентские функции и пр.

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

В Unity добавляются мультиплеерные штуки как компоненты, всё помечается атрибутами и так далее. Всё сделано как модуль и не захардкожено под самую жопу.

Относительно мультиплеерной производительность и оптимизации - всё примерно одинаково. По логике - в юнити всё более грамотно сделано, но относительно стандартного разработчики - всё воспринимается примерно одинаково.

Стандартные редакторы материалов\геймобджектов и пр
UE тут побеждает Unity с головой. Во много в UE все эти редакторы более удобные и приятные глазу, чем аналоги в Unity, но функционально всё примерно идентично.

Т.е. в Unreal редактор материалов имеет свой особый интерфейс, а в Unity шейдеры пишутся кодом (хотя вроде бы какой-то похожий редактор для Unity я уже видел), но по итогу это одни и те же шейдеры.

Проблемы в редакторе уровней

В UE есть масса проблем с редактором уровней. Например, используя синглтон какой-либо как эктора, он почему то иногда дублируется на сцену. Т.е. в рантайме появляется объект и когда сцену выключили (по esс), то он почему-то остался. Почему? Неизвестно.

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

В Unity я таких проблем пока не заметил, но не отрицаю, что они могут быть.

Система переводов

В UE есть только одна система переводов, она жестко захардкожена в движок и её никак не вынять и не заменить нормально. Она уже более 3 лет лежит под плашкой "Эксперементальная" и, скорее всего, никогда оттуда не уйдёт из-за того, что в ней много багов, однако, если работать по четко намеченным лекалам, то она вполне жизнеспособна и как-то работает, особенно, если не требовать от неё невероятных вещей, типа "нажал на кнопку и все фразы перевело на все указанные языки через гугл переводчик" и использовать её только через блупринты (не через код, потому что в коде её использовать - это ад).

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

Понятно, что гугл переводчик - это такое, но как placeholder нормальная тема.

Претенциозность платформ

Дело в том, что компания Unreal очень сильно пытается мелькать в информационном поле и во всех около игровых сферах пытается впихнуть своё Я. Например, создали свой магазин и не добавив даже поиска по играм сразу заявили, что они "убивцы стима". Это типичная маркетинговая стратегия анрила - создать какой-то некачественный и недоделанные продукт и сразу начать его рекламить и объявлять всем "войны".

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

Т.е. у Unity позиция:
ᅠEсть мы и вот наш продукт.

Позиция у Unreal:
ᅠМы двигаем индустрию вперёд, ну и что, что у нас тонны багов, зато мы постоянно добавляем новые технологии в движок, ну и что, что они работают кое-как - зато они передовые! А еще у нас магазин убийца стима, которые ориентирован как бы на разработчиков, но по функционалу отстаёт от стима лет на 10, а ещё мы создадим издателя своего и будем платить разрабам за разработку.

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

Вакансии
Вакансий на Unreal всегда намного меньше, чем на Unity. Взяв тот же hh и спросив по вакансиям получаем:
741 вакансий по Unity
186 вакансий по Unreal

Это по всему СНГ, по другим сайтам примерно всё в таком же соотношение.

Магазин ассетов

Магазин ассетов в Unreal в большинстве своём содержит только модели\текстуры и обёртки под блупринты, в отличии от магазина Unity, который содержит абсолютно всё, что можно. Но в этом всё играет роль подход Unity и UE к своим движкам.

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

Стоит отметить, что ряда вещей, которых в Unity изначально нет (но есть в магазине), изначально есть в Unreal бесплатно. Типа изменения цвета папок и пр. Как по мне, то для норм работы с Unity так или иначе 100-200$ выложить на плагины придётся, в отличии от Unreal (возможно, потому что у Unreal особо нечего покупать для удобной работы с редактором).

В магазине Unreal есть интересные бесплатные вещи, типа особого скриптового языка, который можно использовать в редакторе и не надо долго компилить, НО, докинуть еще одну сущность к коду и блупринтам - это крайне сомнительная идея. Что-то там, что-то там реализовано и если начать искать где какая-то логика реализована, то куча времени уходит чёрти куда. Да и хз как там будет с отладкой.

Итог
Unreal-------------------------------------------------------------------------------------------------------------------------------------------------------------

Unreal Engine - это движок нацеленный исключительно на дизайнеров. Все удобные тулзы - только для дизайнеров. Геймдизайнеры, контентщики, программисты - всем огромную дулю в зубы от эпиков, потому что удобные тулзы не показать в видосике и не получить "Вау" эффект как от очередной итерации графики. Действуя только из соображений маркетинга мы получаем полусырой продукт под подливой передовых технологий, который к тому же захардкожен и закостылен настолько, как будто бы его делали студенты третьего курса.

Все положительные отзывы об UE4 - это отзывы дизайнеров, моделлеров, создателей шейдеров и так далее, т.е. тех, кто работает только с графикой либо имеет мало опыта в создание игр. Графика - это единственное чем можно похвалиться UE4, но сами же эпики не создают "фотореалистичных" игр.
70% содержаний апдейтов движка - это исправление предыдущих багов, которые зачастую порождают еще баги. К тому же, некоторые баги не могут исправить уже многие годы, по типу добавления поля в BP структуру от которой ломается весь проект, ибо все места, где структура используется вдруг не могут найти эту структуру и приходится изощерятся и молится, чтобы этот баг не словить в очередной раз.

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

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

Создавать какие-либо игры кроме шутеров\платформеров\хорроров на Unreal Engine - это копать овраг чайной ложкой - сделать возможно, но долго и муторно. Так как нет никакой возможности удобно и быстро просматривать и сравнивать статические данные, настраивать баланс, которых в любых РПГ, стратегиях и пр. в разы больше, чем в шутерах.

Unity-------------------------------------------------------------------------------------------------------------------------------------------------------------

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

Unity предпочитают не заливать от своего имени тестовые фичи, предлагая пользователям огромный ассортимент торговой площадки, однако, некоторые вещи из торговой площадки, такие как Text Mesh Pro они включили в стандартные ассеты.

Интерфейс юнити никак не поменялся за последние лет 5. Юнити не хватает тулзов для дизайнеров, которые есть у Unreal, что делает работу визуальных дизайнеров не самой удобной.