Почему игры от Bethesda всегда такие глючные?

"Большинство из нас, и я в том числе, не смогли бы
даже заставить прямоугольник двигаться по экрану,
не то что создать такой шедевр как Skyrim."
Кристофер Дэй

Почему игры от bethesda такие глючные?

Отвечают эксперты и просто пользователи и игроки.

Трэвис Аддайр, ведущий софтверный инженер Uber

Сложность. Сложнее = больше багов. Вопреки распространѐнному мнению, нет, это происходит не из-за того, что «они используют этот ужасный движок Gamebryo вот уже 15 лет». Я уже говорил об этом, отвечая на вопрос «Что не так с графикой в Fallout 4?», но повторю:
- Игровой движок – это просто набор повторяемого кода.
- Со временем код изменяется и развивается.
- Заявление о «новом» игровом движке практически всегда - маркетинговый ход.

Даже такой «современный» движок как Unreal – это всего лишь более усовершенствованный движок Unreal, впервые представленный 20 лет назад в 1998 году. Так же странно утверждать, что игровой движок должен быть нестабильным в современных системах по причине того, что часть его кода была написана очень давно. Вот если бы это был устаревший код, который бы не изменился за 20 лет, тогда да, я бы ожидал проблем. Но, опять же, мы говорим о коде, который стабильно работал на протяжении всего своего существования. Для сравнения, ядро Linux было выпущено 26 лет назад, в 1991, но я ни разу не слышал, чтобы кто-нибудь жаловался на ужасные баги и нестабильность, потому что оно чертовски старое.

В любом случае, мало какие из известных ошибок в Skyrim или Fallout 4 можно отнести именно к движку. У вас могут быть проблемы с физикой или сбой рендеринга, но на этом всѐ, что, безусловно, обычное дело для игр Bethesda.  А если это не игровой движок, тогда что именно становится причиной этих забавных (в лучшем случае) и раздражающих (в худшем случае) багов?

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

Но что происходит, когда игрок имеет возможность принять N решений в одной ситуации, и через некоторое время игрок сталкивается с другим набором N решений: Внезапно количество вероятностей, которые нужно протестировать, удваивается! И становится только хуже. Каждая дополнительная переменная,  которую вы включаете в систему, добавляет новую итерацию в количество тех вещей, которые вы должны учитывать во время тестирования. Это самый настоящий комбинаторный взрыв. Тут начинают возникать проблемы, потому что нет никакой возможности проверить N^10000 различных состояний.

Bethesda разрабатывает одни из самых сложных игр на рынке. Поиграйте во что-то вроде Grand Theft Auto, попытайтесь создать максимальный хаос и посмотрите, что будет через час. Всѐ магическим образом вернѐтся в первоначальное состояние. В играх Bethesda данное состояние сохраняется, что приводит к безумно сложным игровым процессам. Я не знаю ни одной игры, которая могла бы сравниться с их проектами в сложности.

А теперь, если честно, некоторые из этих проблем Bethesda может решить, ограничив сложность игр в самом движке. Но тогда мы вполовину меньше будем наслаждаться «лучшими безбашенными моментами» на YouTube.

И где же тогда веселье?

Крис Лодердейл, бакалавриат «Дизайн и разработка видеоигр»,
Университет Балтимора

Главное отличие игр Bethesda от любых других в том, что они не стирают объекты. Как-то раз я бросил лист бумаги на мелководье рядом с большим городом в Oblivion. Спустя десятки часов игрового процесса я вернулся, а лист находился на том же месте. В основном, в играх Bethesda нет «сброса». Всѐ, что перемещено или изменено, остаѐтся таким, если не запрограммировано иначе. С одной стороны, это реалистично и не предполагает каких-либо ограничений, но, в результате это приводит к увеличению размера сохраняемых игрой файлов, поскольку записывается местоположение каждой сырой куриной грудки, которую вы оставили на своѐм столе. Кроме того, если они не назначены с определѐнной целью, их существование может стать бессмысленным для NPC. На них так же влияет ваша игра.

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

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

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

У Bethesda очень органичный игровой опыт, но когда рандомный случай провоцирует проблемы, отсутствие внутренней структуры значительно затрудняет их устранение.  Большинство игр проходят тестирование до того, как они выпущены для публики, и количество сбоев минимально. В отношении Bethesda происходит так, будто они допиливают игру «по ходу дела», так что проблемы случаются чаще.

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

Натаниэль Токич, менеджер проекта

С моей точки зрения, вот ряд проблем, в отношении которых Bethesda испытывает трудности.
Процесс создания игр Bethesda – это странная причуда, которая напоминает мне фильм Брендана Фрейзера «Взрыв из прошлого», а не то, что я считаю приемлемым для текущих реалий рынка. Лично я никогда ничего бы не разрабатывал на этом движке, не потому что он не работает, а потому что есть серьѐзные проблемы, которые, как по мне, делают это бессмысленным. (Плюс ко всему, я перфекционист, когда дело касается оптимизации материала.)

Оптимизация. Creation Engine или новый Gamebryo – это кошмар оптимизации. Многие современные движки, когда они рендерят или компилируют уровень, проходят процесс удаления нежелательных граней из завершѐнного продукта. Смысл заключается в том, чтобы значительно уменьшить объѐм работы для компьютера в процессе представления конечного результата игроку. Это удаление нежелательных граней или плоскости, образованных по крайней мере тремя вершинами в точках (точки, содержащиеся в определѐнном классе объектов, созданные из указанных вершин или местоположений входных объектов), позволяет разработчикам  впихивать больше информации более эффективным способом. Сейчас этот процесс проходят большинство современных движков, и даже некоторые более старые, вроде Source от Valve. (Если кому-то любопытно, взгляните на исходный движок Valve и каким образом его можно оптимизировать, он должен быть стандартным для идеальной оптимизации.)

Функции движка, которых не хватает, но они крайне необходимы:
Функциональность, позволяющая разработчикам уровней вручную выбирать грани, которые должны быть удалены из конечного продукта. Отсутствие данной возможности лишает полноценного пространства для манѐвра. Например, Сэнкчуари в Fallout 4 - катастрофа. Если у вас когда-нибудь будет возможность взглянуть на все игровые ассеты (цифровые объекты), смешанные вместе в этом пространстве, вы поймѐте, что я имею в виду. Все ассеты буквально перекрывают друг друга в нескольких слоях, при этом большинство ассетов видны менее чем на 50%. Обычно я бы сказал, что виной такому беспорядку - лень, но у движка просто нет необходимых инструментов для удаления всего лишнего.

Возможность сделать сборки ассетов движка, что иногда даѐт возможность очень многое реализовать в создании ассетов, отрисовке текстур, перекрытии кодом и проверке на работоспособность. Прекрасный пример того, как движок Bethesda обрабатывает определѐнные события, это дополнение Broken Steel для Fallout 3. В частности, поезд до конечной области представляет собой не что иное как «шляпу», прикреплѐнную к персонажу по умолчанию, который быстро следует по заранее заданному пути. Серьѐзно, как это оптимизировано? Я понимаю, что это хорошая работа, всѐ функционирует, однако это неэффективный процесс решения такой задачи.
В этом случае возможность заполнить ресурсную систему пригодными для эксплуатации объектами, созданными в рамках движка, была бы идеальна.

Освещение. Блин, освещение в Creation Engine как будто из 90-х. Не поймите меня неправильно, это «работает», но это уж точно не то, что можно назвать оптимальным. Освещение в Creation Engine напоминает масштабный пресет, который делает невозможным создание любых реалистичных условий освещения. Причина этого кроется в том, что большая часть света, используемая движком, проектируется со «статичных» источников, и лишь малая часть, - с динамичных.

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

Отличный способ приблизиться к устранению неполадок – система утечек Valve, которая в прямом смысле функционирует, проверяя окружение на любую «пустоту», которая нарушает геометрию и освещение игры, как дыра в космическом корабле, которая вытягивает весь воздух.
Creation Engine серьѐзно нуждается в чѐм-то подобном, потому что многое в расчѐтах игры направлено именно на проверку освещения окружения, и это могло бы позволить разработчикам продвинуться дальше.

В Creation Engine серьѐзно необходимо нормальное обнаружение столкновений.
Creation Engine осуществляет обнаружение столкновений очень простым, но расточительным образом. Многие столкновения определяются ограничивающими прямоугольниками, невидимыми стенами (что очень расточительно) и невидимыми объектами. Слой Collision Layer и Navigational Mesh для объектов – это ненадѐжная функция, которая чаще всего приводит к смешным проблемам, связанным с игрой.

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

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

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

Чрезмерная зависимость от дизайна шаблонов. Почти все разработки ассетов Bethesda основаны на шаблонах или модульных системах. Пока такие системы являются функциональными и рабочими, для большинства открытых миров они создают окружающую среду и персонажей предсказуемо примитивными. И хотя наличие рутины само по себе не плохо, но в данном варианте ассеты, персонажи и практически всѐ остальное рассматриваются как модульные, а не уникальные. Интересный факт о текстурах, - можно ссылаться  на один и тот же файл для различных элементов игры, чтобы уменьшить количество объѐма и запроса данных. Отличным примером является наличие UV, который может поддерживать несколько игровых ассетов. Например, 3-4 оружия могут использовать один и тот же файл UV/текстуры и по-прежнему быть хорошего качества. Однако у Bethesda файлы текстур часто бывают единичными и малоэффективными.

Компиляция – это монстр в Creation Engine для большого окружения. В игровой среде это «живая нагрузка», которая полезна для быстрого тестирования выполненной в ней работы. Однако, отсутствие более глубокой системы компиляции заставляет игру работать практически исключительно как систему плагинов и игровых ассетов, направленную на неизменные неотъемлемые свойства ассетов, вместо того, чтобы позволить разработчику вмешиваться вручную для извлечения нежелательных переменных.

Плагины – ужасная система для загрузки данных. Эти интуитивные и простые в использовании наборы данных загружаются поверх основного файла, который будет работать в тандеме с кодом главной программы. Это требует того, чтобы движок загружал несколько наборов данных в заданное время вместо использования более эффективной системы. Некоторые из наиболее эффективных систем используют древовидную схему, основанную на неструктурированном наборе данных, который загружается как главный файл. В этом случае объект может загружать определѐнные строки кода из определѐнного, заранее загруженного файла, который используется всеми структурами. Однако в Creation Engine плагинами сильно злоупотребляют, что часто приводит к загрузке нескольких плагинов для правильной работы одного объекта.

Хотя движок не «плохой», годы работы говорят о многом, даже при условии его обновлений для обеспечения модернизации. Поэтому многие потребители продуктов Bethesda, которые привыкли к более эффективным системам, сталкиваются с разными странностями. Это ещѐ больше усугубляется сложностью устранения неполадок движка с различных персональных компьютеров игроков. В этом случае, к сожалению, невозможно уладить все проблемы перед выпуском просто потому, что не всѐ аппаратное/программное обеспечение будет реагировать определѐнным образом на эти игры. В связи с этим требуемый объѐм тестирования должен имитировать игру в массивном объѐме переменных, что просто невозможно.

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

Томас Сала, креативный директор и основатель компании Little Chicken Game Company, магистр искусств, университет искусств Утрехта

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

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

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

 Сэм Михан, бакалавр информатики, университет Кардиффа

Так много тестировать, так мало времени.

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

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

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

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

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

Лилдог Рулз

Потому что их сделал Тодд Говард!

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

Выборочный перевод Monday и KsenyKsy


А вы сталкивались с багами? И если да, насколько это было плохо и смогли ли вы как-то это исправить? В чем, по-вашему, дело, и можно ли было этого избежать? Что скажете?