Каким образом в играх сохраняются данные?

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

К примеру каким образом хранятся данные в игре "Космические рейндежры"? У каждого НПС есть свой корабль, свое оборудование и характеристики, он не пропадает из игры и не появляется в рандомном месте мира, его положение всегда известно. Помимо этого в игре есть поиск по всем объектам. Если игра использует БД, то как именно она выглядит и реализуется? (Я понимаю что это может быть не известно, но хотя бы теоретически, или как бы вы реализовавали подобное)

Заренее спасибо.
  • Вопрос задан
  • 4530 просмотров
Решения вопроса 2
Стоит сейчас похожая задача, есть pet project по типу КР и других подобных игр. В процессе решения данного вопроса, делаю примерно так:
  1. В игре, разумеется, есть некая модель вселенной. В моем случае это звездные системы, которые являются контейнерами для SpaceObject'ов, в которые уже входят планеты/корабли и другие объекты.
  2. Таким образом, состояние игры можно сохранить как звездные системы и их содержимое, ну и не забыть сериализовать вспомогательные коллекции, типа капитанов кораблей и другой глобальной информации.
  3. Сериализация вселенной происходит в json. Я пишу игру на unity3d, поэтому мне кажется удобным использовать местный JSONUtility, умеющий проводить сериализацию простых классов (т.е. публичные поля и простые коллекции). Процесс таков: для всего, что я хочу (де)сериализовать, создаю класс-прокси, отражающий в простой форме (без всяких конструкторов, свойств, приватных членов и всего такого) содержимое нужного мне класса, с которым я уже и работаю.

Цикл сохранения/загрузки, к примеру, звездной системы, такой:
  1. Создаем прокси для StarSystem, он в себя копирует информацию о системе.
  2. Когда доходим до списка объектов, для каждого из них создаем уже класс-прокси объекта и результирующий экземпляр уже заносится в прокси StarSystem.
  3. И т.д., пока сложные объекты не закончатся.
  4. В итоге, имеем матрешку из прокси-классов. С помощью JSONUtility она одной строчкой может быть переведена в json или восстановлена из него.
  5. Ну а сами сериализуемые классы должны уметь получать информацию из своих проксей при загрузке из сохранения.


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

Раз уж написал, буду благодарен, если более опытные разработчики укажут на крупные грабли в таком подходе, если они есть.
Ответ написан
@MiiNiPaa
Когда нибудь делали задания типа: «Создайте структуру описывающую диски с фильмами. Реализуйте добавление нового диска, просмотр дисков, сохранение и запись в файл»? То же самое. Создаём структуру описывающую корабль, сохраняем в файл. При загрузке считываем структуру, разбираем и готово.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
bingo347
@bingo347
Crazy on performance...
Есть два подхода:
1) сохранять все изменения в реалтайме, чаще используется в онлайн играх, так как в них не нужна возможность откатится назад. С этим подходом лучше использовать какую-либо БД
2) сохранение по событию, чаще используется в одиночных играх, так как позволяет игроку откатится на одно из предыдущих сохранений, тут лучше использовать файлы в которых будет хранится сериализованная объектная модель игры
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы