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