Как игры обрабатывают сохраненный контент?

Я не вижу ответа на этот вопрос здесь, на SO, который заставляет меня бояться, что это невероятно просто, и я просто что-то пропустил, но здесь идет.

Фон, не стесняйтесь пропустить: мне нужен один курс для моей степени бакалавра, который я пропустил много лет назад. Теоретически это компьютерная графика, но с тех пор, как я ее покинул, стало больше Game Development. И это здорово, потому что для меня это более интересно, чем алгоритмы заполнения и переводы, и то, что было раньше. Это 4-й курс, который предлагается только раз в год, но мне удалось поговорить с отделом, чтобы позволить мне пройти 4-летнее независимое исследование по той же теме и назвать это достаточно хорошим.

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

/фон

У меня есть приятель, которому нравится разрабатывать игровые системы для удовольствия. Я планирую взять одну из своих настольных игр и превратить ее в компьютерную игру, используя XNA.

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

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

Или случай диалога NPC. Когда я натыкаюсь на Merchant # 853, он случайно выплевывает один из трех разных приветствий.

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

Я занимаюсь веб-разработкой в течение многих лет, поэтому мой ум автоматически перескакивает на "базы данных!". База данных - это решение любой проблемы. И я вижу, как он может работать здесь, но накладные расходы кажутся довольно крутыми. "Здесь моя компиляция с 6mb... oh и установка MySQL на 68mb". Или даже хуже, поскольку я использую XNA, может быть, мне нужно найти способ связывания SQL Server.:)

Я думал, может быть, XML, но мне это тоже не нравится. Как это будет работать, если я захочу запустить XBox? Или Зуне? (Это не обязательно для того, что я делаю, но там должно быть решение, которое учитывает их.)

Кто-нибудь знает секрет? Или все-таки есть идеи?

Спасибо Джефф

Ответ 1

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

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

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

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

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

Ответ 2

Один из подходов - использование сериализации .net.

Убедитесь, что состояние игры - это полностью связанный граф, и каждый класс на этом графе помечен как Serializable (с SerializableAttribute), для сохранения (и загрузки) вы можете использовать стандартную сериализацию .net.

Вы можете посмотреть код для Project Xenocide (игра с открытым исходным кодом XNA), чтобы посмотреть, как это было сделано.

Ответ 3

Вы можете использовать базу данных SQLite с SQLite.NET обертка. Я использовал это и нашел это довольно простым. Вся DLL составляет всего 850 КБ, а сама база данных находится в одном файле (при необходимости создаются временные файлы). Поэтому у ваших пользователей не должно быть проблем.

Но вы также можете использовать простой XML файл или домашний формат двоичного кода. Все зависит от того, как вы собираетесь запрашивать данные и сколько данных задействовано. Нет ответа.

Ответ 4

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

Ответ 5

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

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

Теперь предположим, что вам нужно сохранить состояние/местоположение вещей, таких как пакеты здоровья, ящики, враги, здоровье персонажей и предметы, которые вы выбрали, и т.д. У вас может быть несколько сотен из них максимум, что будет легко меньше 10 КБ.

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

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

EDIT: Что касается формата файла... используйте любой способ, удобный для типа данных! XML - отличный способ сделать что-то. Не уверен, насколько эффективна база данных, поскольку для RPG каждый фрагмент данных может быть очень различным; У вас может быть множество столов с одной строкой каждая.

В большинстве игр используются собственные, двоичные, форматы файлов. Во-первых, это значительно сокращает объем хранения. Во-вторых, это помогает предотвратить обман пользователей путем редактирования игры сохранения вручную - если у вас есть XML, например <health value="10"/>, очень легко отредактировать файл для чтения <health value="100"/>. Недостатком двоичного файла является то, что для отладки гораздо сложнее.

Ответ 6

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