Как видеоигры эффективно хранят/извлекают большие объемы данных?

Ответ 1

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

Чтобы показать, насколько велика мегабайт, это 8 миллионов бит. Этого достаточно для кодирования состояний 2 ^ 8000000 = 10 ^ 2666666. Для сравнения, во Вселенной есть только 10 ^ 80 атомов. Теперь в (save) игре есть несколько подсистем с разными состояниями; например в RPG каждый NPC имеет свое собственное состояние. Но сколько из них существует, правда? Их положение в городе может быть сохранено как 16 бит (помните ли вы их точное положение, если они все равно ходят?). Их настроение/расположение/и т.д. Как еще 8 бит, и это позволяет больше эмоций, чем некоторые люди.

Когда речь заходит о хранении такого рода данных в игре, типичной структурой данных является QuadTree. Это структура данных, которая позволяет определять объекты в определенной области X-Y в O (log N). В некоторых случаях разработчикам игр проще предусмотреть разделение мира в зонах. Это уменьшает количество вычислений времени выполнения. Хорошим примером был Doom. На его картах была предварительно рассчитана видимость; для каждой точки можно быстро определить, к какой зоне она принадлежала, и для каждой зоны было предварительно рассчитано количество видимых объектов. Это уменьшило количество объектов, требующих проверки видимости во время выполнения.

Ответ 2

Он может просто отображать объекты или NPC в координатную плоскость X, Y, Z. Эта информация хранится дешево.

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

Ответ 3

Я думаю, вы переоцениваете сложность того, что хранится/извлекается. Вам не нужно хранить 3D-модели для объектов или их текстуры или любые вещи, составляющие большие части размера игры на диске.

Прежде всего, как упоминалось в хаосе, необходимо хранить информацию о вещах, которые были перемещены. Даже тогда вам, вероятно, нужно только сохранить для каждой из них новую позицию и ориентацию (предполагая, что не задействованы другие переменные, например "поврежденные" ). Так что два вектора для каждого объекта, которые будут составлять в общей сложности 24 байта на объект. Это означает, что вы можете хранить информацию для 40 000 объектов на мегабайт. Это ужасное множество объектов, которые нужно было перемещать.

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

Ответ 4

В Fallout 3, в частности, карта разделена сеткой. Вы можете видеть только текущий квадрат и те, что сразу. Тип хранилища данных не очень важен - может быть база данных SQLite, может быть деревом, сериализованным на диск, или может быть чем-то другим.

... у вас есть гигантский массив каждого объекта в игры и постоянно обновлять список, который содержит видимые объекты для рендеринг?

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

Произошло бы, если бы вы в конце концов коснулись каждого объекта в игре? Ваше спасение игра становится все больше и больше?

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

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

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

Ответ 5

Если вы думаете об информации, которую вам нужно сохранить, это не так много;

например.

• Позиция
• Ориентация
• Инвентарь
• Здоровье
• Objective-состояние

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

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

Что касается того, как данные извлекаются/модифицируются, я не совсем уверен, что понимаю. Это просто данные в памяти консолей. Когда плеер сохраняет его, записывается в запоминающее устройство, и когда он загружает его.

Ответ 6

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

Ответ 7

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

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

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

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

Ответ 8

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

Ответ 9

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

Скажите, что у вас есть класс Player, и вы хорошо разбираетесь в истории, когда вы нажимаете сохранить возможные данные, которые можно сохранить:

• Где находится игрок, находящийся в уровень/карта
• Каковы его атрибуты: здоровья, маны, прочность, интеллект и т.д.
• Какие навыки у него есть.
• На каком уровне он.

В глобальном масштабе мы также можем иметь:

• Сколько ссылок (имена, которые позволяют движку собирать объект из списка) на объекты хранятся на этом определенном уровне, другими словами, когда вы загружаете, какие объекты должны быть загружены вдоль с этим.
• Используем ли мы физику, если да, кто ее использует.

И еще много. У Fallout 3 есть один тип сохранения, в другой игре будет другой. Это действительно зависит от жанра и используемого двигателя.