Сериализация в компонентном игровом движке

Question

Я реализую сериализацию в своем игровом движке на основе компонентов, чтобы включить сохранение и загрузку в моей игре. Я использую Cereal, чтобы помочь мне с сериализацией. Тем не менее, две вещи, которые не ясны мне:

• У меня есть много компонентов, и эти компоненты также содержат классы и т.д. Мне нужно написать функции сериализации для всех из них? Это означало бы, что я должен написать около 100 функций сериализации. Большинство из них будут одинаковыми (просто сериализуйте все переменные-члены). Есть ли способ уменьшить объем работы?

• Что делать, если я хочу сериализовать класс, содержащий классы из другой кодовой базы? Например, я использую SDL и TinyXml. Означает ли это, что мне приходится писать функции сериализации в этих кодах?

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

Answer 1

К сожалению нет волшебства. Независимо от используемой библиотеки сериализации, будь то boost::serialization, s11n или MFC, проблема в том, что вам всегда нужно объявлять для каждого отдельного класса, как сериализовать себя.

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

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

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

Другим способом было бы разработать генератор кода, который мог бы работать на ваших заголовках и генерировать mecanically код selialization. Но это уже амбициозный проект сам по себе.

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