[boost::serialization] Conception et serialisation de pointeur

Bonjour,
Je travaille depuis plusieurs jours sur un projet de jeu vidéo, ou une majorité des entités se présentent comme ceci :

• Un modèle : Il contient des attributs qui ne peuvent pas changer (nombre maximum de PV, etc.) et sont sérialisés dans des fichiers
• Une instance : Elle contient des attributs qui peuvent changer en cours de jeu (nombre actuel de PV, etc.) ainsi qu'un pointeur vers un modèle

Cependant, lors de la sérialisation, je ne veux pas que si je sauvegarde l'instance le pointeur vers le modèle entraine également la sérialisation du modèle dans le fichier de sauvegarde de partie.

Ainsi, j'avais pensé à créer un gestionnaire qui fait une correspondance std::string -> modèle* mais cela reste pas mal confus dans ma tête, en plus je trouve cette solution pas très propre, mais je n'ai rien d'autre qui me viens à l'esprit.

Auriez-vous des idées pour faire en sorte que lors de la sérialisation l'instance ne sauvegarde pas le modèle en lui-même mais par exemple une clé qui pourrais retrouver le pointeur plus tard ?
D'autres solutions vous viennent ?

Merci d'avance ;)
darkrojo.

Bonjour,

J'ai envie de dire que la mode en ce moment consisterait plutôt à tout sauvegarder, ou au moins à ne pas se poser ce genre de question. L'espace disque n'est vraiment pas quelque chose que l'on optimise en ce moment.

First : make it work.

Citation:

---

Envoyé par darkrojo

Auriez-vous des idées pour faire en sorte que lors de la sérialisation l'instance ne sauvegarde pas le modèle en lui-même mais par

---

Mais comme je ne suis pas toujours tellement d'accord avec les dérives de cette mode, je pense qu'en effet, ce que tu veux faire, c'est simplement serializer un id.

Code:

---

1 2 3 4

void MonTank::serialize(boost::archive::binary_oarchive& ar, const unsigned int version) { ar & GestionnaireDeModeles::getId(m_pModeleDeTank); }

---

Code:

---

1 2 3 4 5 6

void MonTank::serialize(boost::archive::binary_iarchive& ar, const unsigned int version) { GestionnaireDeModeles::Id id; ar & id; m_pModeleDeTank = GestionnaireDeModeles::get(id) }

---

C'était la question ?

Oui, c'est un peu l'idée.

Je ne suis pas au courant de cette mode mais je trouve cela totalement horrible de re-sauvegarder tout les modèles présents à chaque partie !

Cependant, dans ton exemple de code, on dirais que tu passes par un singleton. Le truc c'est qu'avant de charger ou enregistrer une partie, on aura un gestionnaire de modèles qui chargera une std::map dont les entrées seront du type "nom_du_fichier" -> Modèle*

Je ne sais pas si un singleton s'avère être la bonne solution ici, j'ai pas beaucoup pratiqué avec ce principe (juste un peu en python, mais je ne trouve pas ça très propre).

Citation:

---

Envoyé par darkrojo

Je ne suis pas au courant de cette mode

---

Tu as raison : le terme est peut-être mal choisi. La tendance dans l'industrie aujourd'hui consiste à optimiser le rapport fonctionnalité/temps de développement.
Seuls les amoureux du "bien faire" passent encore du temps à optimiser l'espace disque ou le temps de process à moins d'y être obligés.

Je connais même des gens qui te diraient que la bonne méthode aujourd'hui pour faire ce que tu veux faire c'est de sauvegarder tes n-milles informations identiques puis (si nécessaire) de compresser ton fichier de sauvegarde.

On peut comprendre leur point de vue :
- C'est plus rapidement codé.
- En cas d'évolution qui impacte la taille du fichier, le travail est déjà fait
- Le résultat est sensiblement le même.
- Seule différence : le chargement des données sera 1 seconde plus lent sur pratiquement toutes les machines modernes.

Citation:

---

Envoyé par darkrojo

Cependant, dans ton exemple de code, on dirais que tu passes par un singleton.

---

Beurk non. Je ne propose qu'un gestionnaire de modèles.
Tu peux l'implémenter comme tu veux, si tu choisis un singleton, c'est toi qui voit.

Tu peux passer ce manager à tes classes comme bon te semble (membre, membre statique, en reconstruire un à chaque fois ...)


Au fait. Tu peux aussi vouloir regarder : boost::Flyweight. Mais je ne connais pas l'interface entre boost::Flyweight et boost::Serialize

Ce n'est pas de l'optimisation ici ; pour donner une idée ça reviendrai à sauvegarder les modèles 3D lors de la sauvegarde d'une partie, c'est tout bonnement impensable !

Je pense que je vais me rattacher à un manager temporairement membre lors de la sérialisation (ce n'est pas très propre, mais bon faute de mieux...)

Citation:

---

Envoyé par darkrojo

Ce n'est pas de l'optimisation ici ; pour donner une idée ça reviendrai à sauvegarder les modèles 3D lors de la sauvegarde d'une partie, c'est tout bonnement impensable !

---

Je me fais l'avocat du diable hein : pourquoi pas ?
De toute façon à partir du moment où tu compresse le tout et où il n'y a que trois ou quatre sauvegardes par machine ...
Tu as sans doute pu constater toi même le temps qu'il faut pour charger/sauvegarder sur un Call of Duty ou un Fallout.

L'exemple de Dungeon Siege nous montre que :
1. Il est possible de faire des jeux sans aucun temps de chargement
2. Ces jeux là ne se vendent pas mieux que les autres

Subséquemment que passer du temps à gérer les temps chargement revient ni plus ni moins à jeter son argent par la fenêtre.

Bon après, moi je suis comme toi, lorsque je développe pour le plaisir, je préfère faire de "beaux" programmes. C'est à dire des programmes du code desquels je puisse être fier.

Citation:

---

Envoyé par darkrojo

Je pense que je vais me rattacher à un manager temporairement membre lors de la sérialisation (ce n'est pas très propre, mais bon faute de mieux...)

---

S'il est temporaire, une solution serait d'en faire un membre non-pas de tes entités, mais de ton archive:

Code:

---

1 2 3 4

class MonArchive : public boost::archive::binary_oarchive { Manager* m_pManager; }

---

Code:

---

1 2 3 4 5

void MonTank::serialize(MonArchive & ar, const unsigned int version) { ar & ar.getManager()->getId(m_pModeleDeTank); }

---

Où alors carrément de surcharger les opérateurs & pour ton archive, mais cela devient un peu compliqué pour rien.