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

В семидесятых Джордж Акерлоф в своей работе про «рынок лимонов» объяснял, что если покупатель не может визуально отличить качественную б/у машину от «хлама» (lemon), то цена на рынке усредняется, качественные машины уходят, и рынок заполняется теми самыми лимонами.

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

C‑level менеджменту и продюсерам продают не хорошую архитектуру UE5, но красивую демо‑сцену на купленных ассетах, громкие фичи и слайды с логотипами других студий, которые «шмагли» выпустить ремейк. И когда презентация в таком движке говорит «наша новая система управления виртуализированной геометрией или автоматическим LOD'ингом решает все проблемы с памятью и арт‑пайплайном», я уже вижу как уволят половину моделеров, потому что менеджмент понял это как возможность сэкономить бюджет на них.

Чего нет в маркетинговых презентациях, так что архитектурный дизайн этой системы предполагает постоянную перезапись GPU‑буферов, вызывая просадки на любых конфигурациях, кроме идеальной тестовой стойки вендора с сотней гигабайт оперативки и четырьмя 5090 в слае.

Что при выходе за пределы условных «100 объектов в кадре» алгоритм начинает экспоненциально деградировать и что отладить это внутри «черного ящика» с закрытым кодом или полудокументированным C++ будет стоить студии шести месяцев работы ведущих помидоров, но увольнением моделеров уже запланировали. Моделеров уволили и часть прогеров, а без них перф пожрали долгоносики, Милорд.

Если кто‑то заикается про срезание костов, маркетинг уже выиграл... но деньги уже освоены, моделеры уже уволены, игра уже запущена в разработку, а инженерное мнение... штож... на рынке B2B‑инструментов оно ценится не дороже вашего утреннего кофе. Нам катастрофически не хватает своего Кайла Кингсбери, который будет говорить, что эта хваленая новая фича усложнит разработку на 10%, удешевив её на 2%.

buy vs build

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

[ Собственная игра ] 
        │ 
        ├─► [ Чужой UI-движок ] ──► (Выделяет 1000 мелких объектов в глобальной куче)
        ├─► [ Чужой Physics SDK ] ──► (Игнорирует Alignment для SIMD-инструкций вашего CPU)
        └─► [ Чужой Analytics SDK ] ──► (Блокирует главный поток на 15мс для HTTP-запроса)

Каждый из этих модулей по отдельности прошел внутренние тесты вендора, читай запустился и не скрашил движок, но вместе они превращают вашу память в кашу. Когда у вас in‑house движок, ваш архитектор может принять волевое решение и сделать что «все алокации для UI происходят из заранее выделенного аллокатора», что конечно занимает некоторой количество строчек кода и возможно даже отдельного инженера, но работает быстро и в парадигме вашего движка. Но если вы купили UI‑решение, вы подписываетесь на тысячу мелких проблем внутри чужого закрытого кода, фрагментацию и регулярные фризы, потому что сторонний модуль ничего не знает про ни про архитектуру памяти вашей игры, ни про вашу игру и её потребности и правила.

Культурная слепота

Самый опасный аргумент против написания своего движка или подсистемы уже давно не деньги. Это культурное давление поколения инженеров и менеджеров, за эти пятнадцать лет как‑то незаметно выросших в концепции «своё пишут только сумасшедшие».

И если вы придете к руководству и скажете «нам нужно потратить 4 месяца и написать свой специализированный тайловый рендер/ui/физику/напишите свое» под наш замечательный изометрический проект, на вас поссмотрят как на неадекватного «insane employee». Потому что большие студии сидят на Unreal/Unity, неужели ты умнее тысячи инженеров из Epic? А если у нас не U/U, то мы не сможем нанять людей с рынка, потому что никто не знает как работать с нашим самописным кодом, а те кто знают хотят в два раза больше денег.

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

Моя компания, делает стратегию с десятками тысяч мелких 3д‑объектов на уровне, и все попытки применить стандартный граф отрисовки UE5 и Unity, упираются в обработку трансформаций объектов и съедают весь бюджет CPU в 30мс. Свой движок на эту задачу тратит меньше 5мс раскладывая все что можно в плоские массивы флоатов и обрабатывая их через AVX‑инструкции, но этот движок был написан (вероятно богами) десять лет назад, совершенно для другого железа и так давно не делают... ни богов, ни движков.

Культурная норма сейчас диктует взять что‑нибудь поуниверсальнее да побольше, а потом нанять 20 человек для «оптимизации» того, что по дизайну не оптимизируется, половина из них уволится через полгода, потому что «нешмагла», вторую половину отправят на фикс багов, потому что надо дотянуть до релиза и как‑то выпустить игру с системными требованиями и потреблением небольшой АЭС.

Core Competency

«Если это ваша ключевая компетенция, то делайте это сами. Если нет, тогда покупайте» Джоэл Спольски

И тут руководство большинства студий решает, что раз мы не можем в технологию, то пусть core competency будет про игровой дизайн, сценарий и арт... Ну мы же игры делаем, для игроков... а всё, что ниже (рендер, сетевой код, пайплайны сборки ресурсов, управление памятью) это всё «просто инженерия», которую можно сдать на аутсорс разработчикам движков.

Но во многих видеоиграх технология уже и есть геймплей и вы не можете сделать Factorio без специализированного движка, умеющего обновлять сотни тысяч сущностей за кадр. Вы не можете сделать No Man's Sky или Minecraft на стандартном артовом пайплайне традиционных коммерческих движков без глубокой переработки процедурной генерации. Вы не можете сделать отзывчивую драку‑файтинг, если у вас между нажатием кнопки на геймпаде и отрисовкой кадра лежит двадцать слоев абстракции покупного фреймворка.

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

Экономика ремейков

Это естественный продукт страха студии, потерявшей технические компетенции и перешедней на универсальный движок, перед риском и деградацией внутреннего R&D. Когда производство современного AAA‑блокбастера по стоимости догоняет запуск космической программы, менеджменту и инвесторам больше не нужны инновации.

Им нужна предсказуемая доходность на капитал, и ремейк или ремастер с точки зрения этих корпоративных двухстульщиков выглядит идеальным решением. Ваш маркетинговый бренд уже создан и проверен временем, дизайнерские решения отвалидированы 20 лет назад, а «инновация» сводится к натягиванию современного физически корректного рендеринга и high‑poly ассетов на старую сову. Это предельное проявление рынка B2B‑“лимонов” и потери культуры core competency, и вместо того чтобы инвестировать в новые механики или создавать прорывные движки, студии превращаются в высокотехнологичные конвейеры по переупаковке ностальгии, где единственный реальный риск при продаже «лимона» сводится к том, что 16к‑текстуры будут грузиться на три секунды дольше.

Почему вы продолжите покупать «лимоны»

Изменится ли ситуация? Вряд ли. Рынок B2B сейчас прекрасно защищен от естественного отбора и когда игра проваливается из‑за ужасной производительности, статтеров или багов сетевого кода, ответственность переладывается на дизайнеров, те винят инженеров, инженеры винят движок, вендор движка выпускает патч v5.4.2.2.1.4.5.6.7.83.beta, где «улучшена стабильность», и продает её вам. Профит... все довольны, и это лишний раз убеждает менеджмент, что сделать с нуля будет дороже.

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

Есть небольшая прослойка студий, сохраняющая инженерную культуру и не боящаяся писать свой железобетонный говнокод, и оказывается, что их игра почему‑то работает в 60 FPS на устаревшем железе, загружается за секунды, не требует 150 ГБ на диске и слай на четыре видюхи. Видимо там работают инопланетяне...