Unreal Engine vs Unity vs GoDot. Что нужно знать, если ты не программист

Доброго времени суток, дорогие хабражители. Продолжаем разбор строения игр, игровых движков и их особенностей с точки зрения человека, которому никогда в жизни не говорили «тыжпрограммист». Сегодня на повестке дня выбор игрового движка из двух гигантов игростроя: Unity и Unreal Engine.

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

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

Нет, и вот почему:

• Во-первых, создать игру за две недели без долгих лет обучения и практики — задача почти невозможная (жду в комментариях тру-хард гд-соло, которые написали свою игру на С# за одну ночь после двухнедельных курсов с нуля до про ;-) ).
• Во-вторых, миллионы на своих играх и крупные студии не всегда могут заработать. Это называется ошибка выжившего — мы слышим историю успеха одного человека, но даже не представляем, с какими трудностями и легкостями он столкнулся на самом деле. А о сотнях его коллег, которые проходили тот же путь, но ничего не добились, мы никогда не услышим.
• И, в-третьих (хотя надо было сказать это в начале), мне не нужны лавры. Конечно, было бы приятно получить хоть какое-то признание, пусть и в узких кругах, и монетизировать свое творчество в этом ключе, но главное для меня — рассказать пару историй. Для кого-то они будут интересны, для кого-то непонятны, кто-то (обязательно найдется такой человек) скажет, что это было у Шекспира/Шелли/Никитина/сына маминой подруги (нужное подчеркнуть). Впрочем, полностью оригинального творчества не существует, а осознанно плагиатить кого-то я не буду.

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

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

Здесь вас встретят три глобальные проблемы:

• Выбор движка под ваши нужды
  
• Программирование 
  
• Добавление ваших ассетов в игру
  
• Менеджемент времени
  
• Тест-плей
  
• Компиляция/оптимизация/реализация и т. п.
  

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

Движок

 
Первоначально эта статья должна была выходить в двух-трех частях. Но в процессе написания случилось непредвиденное.

В прошлых статьях я немного говорила про юнити, и, соответственно, какое-то количество тестовых сцен с пресетами (предварительно настроенными параметрами, моделями, сценариями и физикой) были сделаны в Юнити. Но… это было на старом компе. На новый, естественно, весь обвес в виде программ, библиотек, пресетов, конвертеров и прочего пришлось устанавливать заново. И, само собой, версии я выбирала поновее, чем те, которые кушал ноутбук.

Минутка предыстории

Последние несколько лет я работала исключительно на ноутбуке. Стареньком, не слишком мощном, по современным меркам — вообще картошка, но зато привычном. На нем были все необходимые для работы с 3D-движками модификации вроде специальных драйверов, библиотек C++ и Python, конвертеров со скриптами и плагинами. Причем часть из этих плагинов тоже с кастомными пресетами, пускай эти модификации и заключались в изменении одного-двух параметров с единственной строчке кода. А еще на нем были установлены три движка для игр и целый ряд программ для 3D-моделирования и рисования. 

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



Провозившись с этой историей больше двух недель и попробовав самые дикие варианты, я пришла к выводу, что жестянке (жесткому диску) кранты, ибо в его районе и была сама большая вмятина на кулере, а при проблемах с чипом или видеопамятью была бы другая симптоматика в биосе и командной строке. Ну а поскольку смена рабочей техники давно напрашивалась, коллективно всей семьей решили купить компьютер. Ждать три месяца доставки запчастей и делать свою сборку я не стала (все-таки по части железа я тот еще рукоzhop), поэтому купили готовую сборку. Спасибо Хабру за то, что не пришлось залезать в кредиты — половину стоимости закрыли отложенные доходы от статей.

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

Для ноутбука, кстати, позже приехал новый винчестер, хотя и по объему, и по скорости хуже, чем тот, что был, и при замене и установке винды никаких проблем не возникло. Так что да, поврежденным был именно ЖД. Вывод — не покупайте ноутбуки в пластиковых корпусах, если дома дети или домашние животные!

И при запуске Unity выскочило такое предупреждение:


    
Что-то я уже не уверена, что ноутбук помер от физического повреждения…

В версии Windows 11, которая стоит у меня, большая часть движков (да и в десятке тоже такое было) запускается только от имени администратора. Поэтому предупреждение о том, что библиотеки Юнити в таком режиме могут повредить функциональные части системы, меня насторожило. Немного посерфив по форумам на тему «юньки», я прочитала, что это, в принципе, обычное дело, и, мол, нечего беспокоиться. Но позже я наткнулась и на комментарии, что после работы в юнити и неправильно сохраненных неочевидных файлов пришлось чуть ли не чистить реестр и откатывать винду. И это в 2020 году!

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

Еще я планировала упомянуть Gamemaker и GoDot, но, как и с юнити, за пару лет моего отсутствия как гейммейкер, так и годот, претерпели некоторые изменения (шутка ли, почти исключительно инди-движки стали почти массовыми, а годот стал полностью трехмерным, да еще и с возможностью описывать любой функционал на любом языке, хоть на трех сразу).

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

Но перейдем к главному вопросу: как выбрать движок?

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

Вот наш главный герой:

     
Знакомьтесь, КНОПК-А, карманный персональный робот-навигатор (KNOPK-A). Со времен этой тестовой анимации моделька претерпела некоторые изменения.

Сюжет крутится вокруг маленького немного сломанного робота, который потерял хозяйку во время неудачной посадки летательного аппарата (спойлеры, спойлеры, спойлеры) и теперь должен отыскать ее и уцелевшие части аппарата. Попутно КНОПК-А должен будет встречаться с местной агрессивной флорой и фауной, находить детали для себя и запчасти для остатков аппаратуры, а также развлекать игрока намеками на жизнь, быль и гибель некой высокоразвитой цивилизации. 

Визуальный стиль будет умеренно-упрощенным (за гиперреализмом мы не погонимся, как и за упрощением до состояния аниме начала 2000-х). В процессе игры, как и в процессе создания, компьютер не должен сильно нагружаться, а свобода действий игрока должна быть ограничена (все-таки играем за робота, хоть и с искусственным интеллектом). Ну, и некоторая камерность должна создавать у игрока ощущение, что он — маленькое и почти беспомощное существо, которое легко загнать в угол. А значит, нужны рамки действий.

Исходя из этого, составляем список сущностных характеристик, которые будут важны для разработки нашей игры:

1. По пространству, доступному для игрока, мы делаем 2D-игру. В двух измерениях игрока зажать куда проще, и сбежать от вражеской гусеницы уворотом вбок не получится — либо дерись и рискуй быть сломанным, либо думай, как избежать угрозы заранее. Да и технически это намного проще, не говоря уже о производительности.
   
2. По типу геймплея у нас будет платформер-адвенчура с элементами шутера и эпизодическими головоломками: робот сможет бегать, прыгать, взбираться на некоторые предметы и одновременно с этим атаковать противников ближним и дальним оружием. Битемап, пулевой ад, тру хард метроидвания (это когда весь экран заполняют эффекты-партиклы от нескончаемых вражеских атак) ни мне, ни моей сестре не нравятся. А чистокровный шутер или платформер мало того, что скучны, так еще и не вписываются в концепцию и задумку игры. Адвенчура же — универсальное название игр, где большую часть времени вам нужно куда-то идти, карабкаться, искать приключения на свою… на свой корпус. Головоломки позволят отдохнуть от прыжков по полочкам и пострелушек, да и в задумке имеют куда больше смысла, чем шутерные механики.
   
3. По жанру, очевидно, научная фантастика, хотя в некоторые моменты по ходу прохождения появятся сомнения, а только ли это фантастика или в происходящем замешаны не только законы физики и биологии. И дизайн многих уровней, кроме внутренностей летательного аппарата, будет всеми силами отвлекать вас от вылизанного сай-фай антуража.
   
4. По поджанру/подтипу геймплея — роуг-лайт (rogue-lite). Умирая… то есть, ломаясь, робот перезапускается с контрольной точки. Поначалу это будет лишь материнская коробка рядом с пультом управления аппарата, потом добавятся чекпоинты в других местах. Потому что рогалики нам нравятся. И потому что это подходит по задумке. Ну и дополнительный дискомфорт игроку, который вынужден будет опять пилить до босса качалки своими маленькими ножками.
   
5. По стилистике и дизайну — полуреализм. Эдакий немного прилизанный, но достаточно проработанный рисунок с более-менее адекватными пропорциями и без целлшейдинга (cell shader — это то, благодаря чему существуют 3D-аниме игры, имитация эффекта рисунка на целлулоиде со сплошной заливкой цвета и простыми тенями). Это позволит сэкономить производительность на мегасканах (зачем нам овердокучи полигонов и 8к текстуры, когда можно обойтись четырехполигональным плоскатиком?) и время на проработке текстур.
   
6. Вариативность прохождения. Фича платформеров в том, что некоторые места можно обойти, если у тебя прямые руки и ты научился точно прыгать с маневрированием в воздухе. Но далеко не все игроделы ее используют, оставляя варианты на перепрохождение или только в виде срезов к точке сохранения, как в GRIME. Мы же попытаемся сделать так, чтобы у игрока был выбор: переть напролом, игнорируя возможные последствия боестолкновения, или обойти, филигранно попрыгав по платформам или просто выбрав другое направление, как в Hollow Knight. Другими словами, карта локаций должна быть обширной и иметь возможность обойти целые куски с опасными зонами. Конечно, без обязательных «кишочных» коридоров не обойдется, как и без приснопамятного «с этой стороны не открыть». Да и некоторые зоны потребуют определенных предметов или условий для доступа. 
   
7. RPG-элементы. Хотя настоящего деления по классам и дерева навыков не предусмотрено (какие классы? Это стандартный робот-компаньон серийной модели!), всё же элементы прокачки и развития в игре планируются. Так, разрешено будет подбирать определенные предметы и встраивать их в свой корпус для получения новых характеристик. Скажем, панцирь каменного краба увеличит вашу защиту и снизит заметность, хотя будет мешать прыжкам, а клешня увеличит урон в ближнем бою. Плюс в ключевых местах ваш выбор будет влиять на состояние робота и на концовку игры. По крайней мере, по задумке.
   
8. 3D-графика. Возможно, некоторые посчитают, что спрайтами или плоскатиками (плоскими фигурами с рисунком) было бы проще реализовать подобное, но нам больше нравится 3D. (Да, привыкайте, многое из того, что упоминается, добавлено потому что оно нравится авторам.) Плюс, лично на мой субъективный вкус и с точки зрения моих личных навыков, проще один раз сделать модель и десяток анимаций для нее, чем нарисовать сотню спрайтов и написать к ним один единственный переключатель атласа (утрировано, но все же). Плюс изменять анимацию проще, чем перерисовывать спрайты. При этом фон частично будет плоским (непосредственно фоновое изображение дальнего плана и фоновые элементы наподобие растений в виде плоскатиков).
   
9. Все это должно выглядеть красиво, но идти на не слишком мощных компах, вроде моего ноутбука, а в перспективе иметь шансы быть адаптированным под мобилки. Это, конечно, сверхзадача, но оптимизация действительно должна быть высокой. Хотя бы для того, чтобы потом знать, как оптимизировать полновесный проект, чтобы не получилось, гм, новых «павших лордов».
   

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

Что обновленный GoDot, что Unity, что Unreal Engine вроде бы отвечают всем запросам

• 2д-строительство игры — чек;
  
• роуг-лайт механики — чек;
  
• полуреализм — чек;
  
• вариативность — зависит от прямоты ваших рук, но чек;
  
• RPG-элементы — чек (тоже проверяем руки);
  
• 3D-графоний — чек (но с оговорками, об этом дальше);
  
• оптимизация для слабых устройств — как будто бы чек, но тоже с оговорками.
  

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

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

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



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

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

Зато усиленно нахваливаемый анрил с загрузкой ядер справляется отлично. Я бы даже сказала, с запасом. Попробуйте запустить какого-нибудь Алана Вейка или Lords of the Fallen на компьютере чуть старше пары лет — лаги, фризы, и комнату зимой можно не отапливать. И начинающие игроделы, впервые его запуская и загружая тестовые ассеты из библиотеки, молча офигевают с того, как оно виснет уже в окне предпросмотра. Зато на мощных ПК рендеры выглядят не хуже тизеров высокобюджетных голливудских фильмов (а некоторые на нем и создавались). А почему такая разница?

ИСТОРИЯ UE и U

Некоторые считают, что движок Unity проще и легче, потому что старше и реже обновляется. Однако первая игра на Юнити вышла в 2005 году, тогда как начало Unreal Engine было положено аж в 1998 году. Да и обновления на движок Юнити выходят ежегодно. С чего тогда такая разница?

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

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

Плата за установку. Недавно по сети пролетел слух, что правообладатели Unity обяжут разрабов (всех включая инди, а не только крупные студии) платить за то, сколько раз их игру установили. Да, именно установили — не купили. Конечно, и ранее юнити обязывала разрабов платить от 5 до 15% доходов с продажи игр на их движке при условии высокого числа продаж. Интернет завопил, кое-кто демонстративно бросил движок, разработчики вроде как пошли на попятную (на самом деле нет, просто дали пояснение), и в итоге репутация разрабов все больше опускается вниз.

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

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

Файловая система и навигация

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

В плане удобства люди хвалят годот за простоту интерфейса и архитектуры файлов игры. Нативные импортированные FBX-файлы (самый распространенный формат для моделей с костями и анимациями) хранятся в своем же FBX-формате и там, куда вы их поместили. С одной стороны, круто — сам положил, сам запомнил. С другой, в годоте нет автоматической индексации файлов.То есть вы сами должны запомнить, где у вас модели, где текстуры, где элементы окружения и т. п., или сами создавать метки и систематизировать свои ресурсы. Но если вы работаете над проектом долго или затрудняетесь в классификации при работе с чужими файлами, можно запутаться. Юнити хранит все модели вместе с текстурами в формате Unity asset file (.uasset), а действующие модели персонажей скрыты глубоко в недрах файлов.

Вот, например, путь до файлов моделей из игры Arena of Valor:


Большая часть известных MOBA (мобильных многопользовательских онлайн-арен), включая Arena of Valor, Mobile Legends Bang Bang и других, сделаны на базе Unity

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


Файлы AoV. Такая организация файлов иногда называется вертикальной: часть игровых элементов находится в «неглубоких» папках, а по мере снижения важности для базового функционирования «погружаются» вглубь в подпапки. Так, опциональные ресурсы высокодетализированных моделек в Arena of Valor находятся в папке com.ngame.allstar.eu\files\Extra\AssetBundle\Show\Hero

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

Но даже на мобилках проблема однопоточности и длинного пути проявляется. Вы никогда не задумывались, почему в MOBA-играх почти всегда участвуют не более 10 человек одновременно? Это не только дань уважения, но и ограничения движка. Новые телефоны неплохо справляются с отрисовкой десяти цветастых фигурок вместе со сценой, по которой они бегают, скайдома (купола или сферы вокруг арены), какого-то количества маркеров взаимодействия и эффектов от навыков.

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

     
Содержимое папки Binaries. В подпапке Third party хранятся ресурсы, не критичные для запуска игры, либо вспомогательные ресурсы других систем и движков, интегрированные в игру. Например, дополнительная система физики разрушения, ресурсы для трассировки лучей, файлы поддержки игровых магазинов Steam, EGS и GOG и т. п.

Организация файлов в Unreal может показаться странной. Вот в первом приближении у нас есть две папки: Binaries и именная папка игры. В папке Binaries хранятся скрипты, важные для распознавания и запуска игры (в папке Engine) и другие вспомогательные файлы. В именной в подпапке Content находятся файлы движка, таинственные блюпринты, звуки, текстуры, модели и скрипты.

    
    Файловая система Agony — игры на Unreal engine 

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

Вес безобразия

 
Одной из главных претензий к постоянно обновляющимся версиям Unreal и играм на ней — большой вес движка и сделанных на нем играх. Шутка ли, базовый Unity весит около 200 мегабайт без набора шейдеров, когда Unreal Engine 4 — от 40 до 60 гигабайт.

В принципе, это справедливо: посмотрите на объем, занимаемый Lords of the Fallen — больше 45 Гб при объеме локаций, сравнимом с Dark Souls PtDE, который весил немногим больше десяти гигабайт. Но тут есть нюанс. Даже два. Или три.



Первый нюанс: текстуры высокого разрешения. Например, базовая версия игры Century: Age of Ashes, разработанной на Unreal Engine 4, занимает около 12-14 Гб. При этом версия для Xbox занимает около 60Гб, будучи разработанной на том же движке. Отчего такая большая разница?

Дело в текстурах. Текстуры драконов steam-версии в среднем имеют разрешение 1024x1024, а в версии для Xbox — около 4096х4096. Текстуры эффектов, окружения тоже в среднем в 2-4 раза больше. Модели и все внутреннее наполнение абсолютно то же. Да, только большие текстуры могут увеличить объем игры в шесть раз.

Особенно ощутимо это с нынешними «стандартами», когда в AAA-играх «хорошим тоном» считаются текстуры не меньше 4к. Зачем? Да просто так красивее играть на ультрашироких мониторах и экранах телевизоров. Хотя при запуске той же стим-версии Century с подключением к телевизору я особого дискомфорта не испытала. Возможно, я просто не так избалована высокой четкостью. А может мой телик старый и ненамного лучше обычного моника.

Еще одна причина высококачественных тяжелых текстур — инновационные системы, встроенные в Unreal Engine. Их аж несколько, но на слуху самая новая — позволяющая сжимать текстуры и модели прямо во время игры, адаптируя под мощности компьютера. Действительно, зачем делать дополнительный набор текстур и моделей более низкого качества, когда сам движок способен сжимать их в режиме real-time. 

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

Кстати, в Elden Ring и других соулсах от основателей поджанра есть дополнительные текстуры низкого разрешения для почти всех объектов, включая волосы, доспехи и тело персонажа: 


Одна из декомпрессованных текстур Elden Ring. Слева — версия с высоким разрешением, справа — с пониженным. Кроме разрешения в пикселях, такая текстура меньше по цветовой палитре, хотя это почти незаметно глазу.

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


Текстуры и модели в Lords of the Fallen живут своей жизнью. Все окружение более-менее прилично загрузилось, а одежда героя и статуя превратились в мыло. И при приближении не исправились.

Третья причина излишнего веса игр на UE (особенно UE5) — оптимизация. Мы уже сказали про разрешение текстур, однако то же самое относится и к моделям. Но не только к ним, хотя модели в последнее время в играх грешны излишком полигонов там, где это не нужно (здесь могла быть шутка про полигоны на филейной части леди Димитреску, но это совсем не шутка, особенно в последних играх Final Fantasy). Не моделями едиными — очень многие разработчики (не только на Анрил, но на нем заметнее всего) оставляют после себя много мусора в управляющих директориях игр. 

Это и загруженные, но не востребованные блюпринты, неиспользованные скрипты, невошедшие в игру объекты и карты и прочее. Думаю, вы не раз слышали о том, что датамайнеры в той или иной игре нашли вырезанный контент размером с DLC. Но если в видосиках фигурируют в основном единичные модельки противников и боссов, редко с анимациями, то геймдизайнеры могут найти еще пару килограмм (вернее, гигабайтов) мусорных элементов движка. Иногда попадаются добросовестные разработчики (как Playwing, создатели Century), которые вычищают за собой все лишнее. Иногда нет.

Промежуточный итог

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

Пока что можно остановиться на том, что Unreal Engine — движок для тех, кто не хочет пилить вспомогательные элементы сам, но может взять тяжеловесные заготовки из бесплатных и платных пакетов. Можно сказать, для ленивых и бесталанных (как я). А Unity — «дистиллированная» версия движка, где можно прикрутить все что угодно, воспользовавшись напильником и смекалкой.

С вами была Людмила Хигерович. На сегодня у меня все. Всего хорошего и не болейте!

---

НЛО прилетело и оставило здесь промокод для читателей нашего блога:
— 15% на заказ любого VDS (кроме тарифа Прогрев) — HABRFIRSTVDS