Почему игры почти никогда не выходят вовремя: техническая кухня переносов

“Релиз перенесен” – фраза которая уже давно перестала кого-то удивлять. Журналисты относятся к датам осторожно, а в комментариях под анонсами геймеры почти всегда предсказывают будущий перенос – задолго до официального объявления… Остается лишь скептически ждать, осознавая, что релиз, скорее всего, затянется на пару месяцев, а то и лет.

И причины мы чаще всего ищем на поверхности, а главной видим одну: “ленивые разработчики, которые опять ничего не успели”. Но действительно ли разработчики так не хотят работать, или есть другие, более объективные и весомые причины для переносов долгожданных игр?

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

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

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

Один из самых удачных сценариев для анализа – Creation Engine (далее CE) от Bethesda. Он изначально был некой эволюцией движка Gamebryo, на котором построены Fallout 3, Fallout: New Vegas, и, разумеется, The Elder Scrolls III: Morrowind и Oblivion. Корни уходят аж в 2000-ые. В результате определенных доработок родился CE, который подарил нам все игры студии, начиная от Skyrim и заканчивая Starfield. И можно подумать, что это настолько гениальная разработка, что её можно использовать десятилетия! Но каждая новая игра сталкивалась с системными ограничениями старой архитектуры: проблемы с физикой, анимациями и ИИ. Разумеется, со временем они решались, но решались по мере обнаружения и разработки уже запланированных к релизу проектов.

Похожая ситуация была и у CD Project RED с движком REDengine. Он отлично подходил для RPG вроде второго и третьего ведьмака, но оказался плохо приспособлен для задач Cyberpunk 2077. Плотный город, увеличенная вертикальность местности, сложный ИИ NPC.. Да даже поддержка большого количества платформ, (но об этом немного позже) тоже сказывается на на работе с движком. В результате студии приходилось дорабатывать движок прямо по ходу разработки, фактически, перестраивая основу проекта. В итоге мы имеем – 4 переноса, огромное количество багов, которые проявились сразу после релиза.

Ну, и как можно не упомянуть Frostbite от DICE. Изначально движок создавался под шутеры Battlefield, и он действительно отлично подходил для сетевого экшена. Но когда EA попытались использовать его для других проектов, начались трудности… Mass Effect: Andromeda находилась в разработке 5 лет, но основное количество контента было сделано за последние 18 месяцев. А куда потрачено все время до? Конечно же на оптимизацию неподходящего движка… С Anthem ситуация повторяется: 7 лет разработки, а сборка игры за последний год. Dragon Age: Inquisition и даже серия Need for Speed – проекты, которые буквально противоположны по своим механикам изначальному плану движка. В итоге – огромные траты времени и сложности в переработке, а в следствие этому – баги и переносы.

А теперь давайте затронем студии, которые отказались от собственного движка и перешли на Unreal Engine “где-то в середине разработки”: Respawn Entertainment, которая на ранних этапах Jedi: Fallen Order отказалась от модифицированного Source-стека в пользу Unreal Engine 4. И уже в какой раз упомянутые CD Projekt Red – при переходе с REDengine на Unreal Engine 5 в разработке следующей саги во вселенной The Witcher.

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

Но здесь очень важно понимать: подобные “переселения” редко возникают из-за ошибки выбора движка. Обычно проект меняется вдоль и поперек за 2-3 года разработки, а изначально выбранная платформа оказывается неподходящей для масштаба, который вырос в процессе. То, что изначально планировалось как линейная игра, может превратиться в полуоткрытый мир.

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

Фраза: “выходит на всех платформах” звучит очень красиво в трейлере, но для разработчиков это почти всегда источник хронической боли…

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

На этих факторах изменчивость, разумеется, не заканчивается. Но я думаю, что для рассмотрения проблемы мы остановимся “на поверхности”.

Теперь давайте ближе переходить к сути. На консолях разработчики оптимизируют продукт под конкретные конфигурации железа, которые известны заранее. Сложности здесь в том, что они хоть и ограничены, но различны… Консоли Xbox на +-20% мощнее синего конкурента. Но вот память Sony, как постоянная, так и оперативная – на те же +-20% быстрее. И это тоже очень важный фактор, ведь при разработке для консолей – нужно максимально использовать ресурсы. А здесь – разные конфигурации, и, следовательно – разный подход к оптимизации.

ПК – это вообще отдельный мир. Протестировать игру на всех возможных конфигурациях практически невозможно. Разные видеокарты, процессоры, версии ОС, да даже объем и скорость ОЗУ. Игра может идеально работать на одной сборке, и сильно тормозить на другой, хотя – все соответствует требованиям.

И снова затронем Cyberpunk 2077 – это самый яркий пример. Это амбиции нового поколения, которые должны были поддерживаться на “четвертой плойке”... Колоссальная разница в производительности оказалась критичной. Итог – переносы, скандал, патчи и в результате отказ от поддержки старых версий в дальнейшем развитии. Добавим к этому Nintendo Switch, где крупные игры приходится переписывать и буквально “ужимать” – снижать качество текстур, упрощать рендер освещения, оптимизировать практически каждый мегабайт памяти… Это уже можно назвать отдельной веткой разработки изначального продукта.

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

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

Есть интересный миф о том, что длительное тестирование лечит все проблемы и костыли… Но к сожалению, это остается лишь мифом. Современная игра – система с огромным количеством переменных, которые раскрываются по разному как на разном железе, так и при разном подходе к геймингу. Даже сочетание разных механик может вызвать нестабильности приложения. ИИ может повести себя нестабильно при высокой или разноплановой нагрузке, а еще, например, сохранения могут оказаться “битыми” только через пару десятков часов геймплея… И все это довольно трудно спрогнозировать и проверить заранее.

Давайте посмотрим немного в прошлое, на очень красивую дату: 11 ноября 2011 года. Мир увидел Skyrim – это был просто взрыв индустрии: технологии, графика, огромный мир, отличный геймдизайн… И при всем масштабе тестирования, игра все равно вышла с кучей багов, которые всплывали постепенно… Думаю, кто-то с теплотой вспомнит, как улетал “в космос” от удара великана, а кто-то с негодованием вспомнит какой-нибудь квестовый ключ, который проваливается под текстуры…

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

А вот релиз Assassin's Creed Unity дал нам очень важный урок – насколько технические проблемы перечеркивают впечатление от проекта. По крайней мере, выпадающий из мира Арно, или NPC с зубами без лиц… Оставили не самые приятные впечатления. Это, как я вижу, уже начало наталкивать геймеров на мысль, что переносы не так уж и плохо, по сравнению с сырыми проектами.

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

Теперь, разобрав и тестирование, посмотрим, какие еще могут быть проблемы переносов. И что нам остается рассмотреть – это онлайн и сертификации.

С сервисной моделью все просто и сложно одновременно. В лабораторных условиях разработчики, конечно, тестируют нагрузку. Но тестовая среда – это десятки или сотни людей. Релиз – количество игроков часто переваливает за сотни тысяч. Именно поэтому запуск Diablo 3 обернулся печально известной ошибкой 37. Игра была готова, а вот сервера… Они оказались просто не готовы к реальному объему геймеров. Из-за этого появились и проблемы с одиночной игрой, ведь была необходима связь с сервером, которому и так было не сладко. Хочу упомянуть и GTA Online, который стартовал с проблемами соединения и потери прогресса. Причина снова из этого же поля – сложность сетевой части, которую было просто невозможно полностью смоделировать в лабораторных условиях.

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

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

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

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

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

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

Техническая кухня объясняет, почему игры трудно выпускать вовремя, но изначально это “вовремя” определяется менеджмент-составом проекта, и почему сложности разработки изначально неправильно оцениваются – тоже стоит задать именно им.

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

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

#Игры #Геймдев #РазработкаИгр #ИгроваяИндустрия #ПереносыИгр #ИгровыеДвижки #ТехническийДолг #Мультиплатформенность #Оптимизация