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

Question

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

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

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

/ Фоновая

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

Один из подходов заключается в использовании .net сериализации.

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

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

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

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

РЕДАКТИРОВАТЬ: Что касается формата файла ... используйте любой способ, который удобен для типа данных! XML - очень хороший способ работы. Не уверен, насколько эффективной будет база данных, поскольку для RPG каждый фрагмент данных может сильно отличаться; Вы можете получить несколько таблиц с одной строкой в ​​каждой.

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

Answer 6

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