Терабайта видеопамяти будет мало: размышления о негативном влиянии на игропром развития Unreal Engine

Привет. Давеча скинули мне пост, где некий разработчик на Unreal Engine вещал про растущие системные требования, дескать 8 Гб видеопамяти уже недостаточно и вообче, оптимизировать долго и сложно, "давайте ориентироваться на 12 Гб VRAM". Пост: https://dtf.ru/1734717

После прочтения данного текста хочется ударить кулаком по столу и возопить: “Криворукие разрабы совсем обленились! Ещё вчера 4 гб памяти было достаточно, а сейчас уже восьми мало, но игры никак не поменялись!”

Эту мысль можно сформулировать как теорему:

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

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

Хочется также абстрагироваться от поверхностных предъяв, вроде того, что все игры на Unreal Engine выглядят одинаково. Люди так рассуждающие видимо не знают, что Море Воров и Атомное Сердце сделано на Unreal. Про реюз ассетов тоже говорить не буду, так как это проблема свойственная всем движкам.

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

Unreal Engine - воистину потрясающий инструмент. Epic Games со скоростью пулемета представляет новые, прорывные технологии: графические Nanite и Lumen, генерация ландшафтов, бесплатная библиотека Megascans и визуальное программирование. Всё это вы слышали на рекламах курсов по становлению мидлом за 3 наносек. Жалко, но они не расскажут про отвратительную документацию, крайнюю сырость новых технологий, что им самое место быть в бета режиме, максимально контр-интуитвное программирование на плюсах и так далее. Попробуем рассмотреть эти проблемы ближе и определить их причины.

Начнем из далека. Сильно так из далека.

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

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

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

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

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

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

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

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

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

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

На Хабре есть коротенькая статья о истории игровых движков:

И автор даёт там объяснение, что же такое игровой движок:

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

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

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

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

Качественный путь развития

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

Количественный путь развития

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

Не трудно догадаться какой конкретно способ более эффективный. И не трудно догадаться, какой путь преимущественно выбрала Epic Games. Да, мы наконец то добрались до Unreal Engine! Я, растекшись мыслёй по древу, наконец-то перешёл к теме разговора, поздравляю дочитавших!

Представьте себе пустыню. Огромную, бескрайнюю. Вот фоточка сверху для того чтобы было легче. Представили?

А теперь представьте, что посреди этой пустыни ставят четыре сколоченные доски, получается такая песочница, и в это песочницу сажают детишек. Представили?

Так вот, пустыня - это возможности Unreal Engine, детишки - разработчики, а песочница - это доступные, задокументированные для простого смертного технологии. Именно так Epic Games решила поставленную проблему. Вот самый наглядный пример такого подхода:

Как вы скорее всего знаете, Unreal Engine предоставляет два основных инструмента для написания игровой логики. Это Blueprints и C++. Краткая справка для тех, кто не в курсе:

Blueprints (далее блюпринты) - система объектов, программа которых состоит из соедененных последовательно нод. Ноды - кирпичики, которые выстраиваются в порядке выполнения определенных команд. Каждая нода - это какая-то команда или действие.

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

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

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

Таким образом Епики убили того самого зайца, решили проблему сложности инструментария, просто сделав лайт версию, которая удовлетворит 99 процентов зевак. А на остальной движок положим болт, так как поддерживать это плюсовое болото ради одного процента не имеет смысла, ведь даже ААА студии в этом не заинтерисованы! Примеры чуть далее, после краткой главы про плюсы.

Вот какие ассоциации у меня вызывают плюсы в контексте Unreal Engine. Во первых нулевая документация, о чём дальше. Во вторых дурацки реализованная компиляция. Сейчас поясню, что я имею в виду:

Лучшей практикой создания объектов в Unreal Engine являтся создание базового плюсового класса с объявлением всех дефолтных переменных. От него создается дочерний класс блюпринт, у которого мы в редакторе выставляем эти самые дефолтные значения. Так вот, если вы так сделали, а потом изменили что - то в плюсовом классе, то изменения в блюпринте наследнике могут применится, а могут и нет. Это рандом ага. Если хотите, чтобы изменения применились точно, перезагрузите редактор. И вообще, желательно после любых изменений компилировать код с закрытым редактором. Недавно фича Live Coding перестала быть эксперементальной, она призвана облегчить этот процесс. Работает через раз. Да, это далеко не Unity, где просто сохранил и всё, тут надо компилировать и перезагружать редактор.

А еще те кто что-то делают в Unity, помните, какие кайфовые подсказки в Visual Studio? Так вот, в Unreal Engine настроить это просто какая-то нереальная задача (да, это всё надо настраивать). У вас тупо всё будет гореть красным, вы это красное свечение отключите, отключите автоотступ после макросов, попытаетесь прикрутить подсказки, половина которых будет работать. Интеграция нулевая.

Как решение есть потрясающий Rider от JetBrains, по сути единственный умный инструмент для работы в Unreal. Жалко, его в России не купить.

Документация, это 50% плюс одна акция от вашего инструментария. Именно по документации люди будут познавать ваш движок, но, помните, я что-то писал про то, что при количественном пути развития на документацию можно задвинуть? Так вот, Unreal Engine - это апогей плохой документации. Для наглядности хочу провести параллели с другим популярным движком - Unity.

Давайте ка вспомним какую нить объективную проблему игр на Unreal Engine и попробуем найти связь между этой проблемой и документацией. Ну вот допустим проблема, когда игра нормально задействует пару потоков, хотя у процессора их 24: https://youtu.be/uI6eAVvvmg0?t=441

Вот я разраб, хочу чтобы моя игра работала не на одном потоке, для этого я что? Верно, лезу в гугл чтобы узнать, как это реализовать в моём любимом движке. Набираю: unreal engine multithreading в гугл и что я вижу? Пару сообщений на форуме от пользователей, которые сделали какой-то свой велосипед:

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

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

FRunnable! Кроссплатформенный абстрактный интерфейс потока в Unreal Engine! Бежим его гуглить в официальной документации и видим:

Мда. Лучше почитаю этого чувака, у него и картинки красивые и расписано всё классно. А Эпики тупо забили болт.

И для контраста набираем Unity multithreading:

Первая же ссылка на документацию! Воу. А так можно было? Ладно, давайте глянем что там внутри:

Ого, вводный заголовок про мультипоток, с ссылами, а слева что за замечательные менюшки:

ОГО! Примеры кода с картинками! Невероятно. Невозможно. Знаете, я использовал юнити какое-то время, и каждый раз у меня документация этого движка вызывает такое лицо:

Хотя на самом то деле, это просто документация, какой она должна быть и не более. И теперь сложите два плюс два и подумайте, а почему же в играх на Unreal Engine проблемы с мультипотоком?) Чёрт, зато мы каждые полгода представляем инновационные технологии, освещение там, нанит всякий, а у нас как будто времена amd fx, когда потоки есть, а игры их не используют. Спасибо Епики, за возвращение в 2007.

Еще пример

Сейчас я делаю игру, где у условных персонажей есть какие-то способности, ну вроде такой фан рогалик поржать. Сначала я начал для него писать плагин, который содержит логику абилок, артефактов и так далее. А потом узнал, что есть уже готовый плагин Gameplay Ability System. Он очень популярный и используется в Fortnite. По сути делает всё тоже самое, что и мой, только написан профи и имеет в сто раз больше функций, так ещё и мультиплеер поддерживает. Приятно. Документация околонулевая, но она есть! Ладно, дело даже не в этом. В этом плагине одна из главных фич - привязка к InputSystem. Тоесть абилка сама привязывается к каким то клавишам вашего контроллера, которые вы выберете в настройках проекта. Круто, но вот проблема в том, что InputSystem с 5.1 версии движка deprecated. Тоесть использовать её принципиально можно, но на самом деле нельзя, так как она не поддерживается. Теперь используется EnhancedInputSystem, но вот незадача, функции привязки к Gameplay Ability System теперь нет. Информации в документации по привязке нет. Делайте что хотите, любой велосипед на ваше усмотрение.

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

УПД: Важная вещь, о которой я забыл, из-за чего слишком сгустил краски. Исходный код Unreal Engine сейчас опубликован и находится в открытом доступе. Любой желающий может при достаточной квалификации разобраться с теми или иными вещами. Это просто гигантский плюс движка и одно из весомых его преимуществ.

Опять немного пофантазируем.

Вот мы условная Arkane, хотим сделать игру около ААА или АА+. Писать свой движок мы понятное дело не осилим никогда в жизни, старички, которые делали dishonored на третьем анриле разбежались и опытных специалистов у нас мало, да и четверка сильно отличается от тройки. Какой движок нам выбрать для нашего проекта?

Unity? Всё бы хорошо, но графончик там не тот, а современному геймеру графончик нужен. Модифицировать Unity нам совершенно лень, да и вообще, это движок для мобилок.

CryEngine? Полуживой проект хоть и очень интересный, но у него маленькое коммунити и ведь тоже, картинка в нём из коробки не такая, как в Unreal.

Unigine? Мы делаем симулятор вампира на марсе?

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

И тут самое интересное, у нас есть два стула: Блюпринты и плюсы. И что же мы выберем? Плюсы, куча ошибок, невнятный кодинг, отвратительная документация или гладкие стерильные блюпринты, которые такие приятные и удобные. А ещё нас уверяют, что на блюпринтах можно полностью игру сделать даже человеку незнакомому с программированием, а значит, можно немножечко сэкономить на плюсовых специалистах! Их очень мало, потому что учиться движку без документации это дело титаническое, поэтому мы выигрываем со всех сторон. В итоге получается редфолл.

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

Епики создали образ сверхумного движка, который способен сам всё делать, сам всё пофиксить. Им подпевают бесконечные дебильные курсы из разряда “Научись создавать игры без навыков программирования” и вереница поверхностных туториалов на ютубе, 99 процентов которых на блюпринтах. И там у них ведь действительно всё просто!

Вы думаете это не так? Почитайте например эту статью:

Цитата:

Особо умиляет про "более творческий процесс", хотя автор тупо купил велосипед со всей логикой, тоесть 99% процентов геймплея. Помните я говорил про то, что технический прогресс должен бороться с шаблонами? Удивительно, но мы пришли совершенно к другому, у нас теперь шаблонные игры, все как под копирку!

Шаблонный класс для персонажа. Шаблонная логика перемещения. Скачай модельку из ассетстора и выбери ее в настройках. Скачай текстуру земли. Сгенерируй шаблонный мир. Люди смотрят на это и восхищаются: как просто! Можно вообще ничего не делать! Модельки скачаем. Текстурки купим. Логика уже есть готовая. Дело не просто в том, что именно игры с визуальной точки зрения будут одинаковые, игры будут геймплейно мёртвыми.

И движок ведь это поощрает!

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

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

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

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

Хотя погодите, кто вам сказал, что ваша 4080 это потянет?

#unrealengine #indie #development #лонгрид #лонг