Jeu en ligne (MUD), persister les données : SQL ? ORM ? Serialization ?

Bonjour à tous !

Je suis en train de coder un MUD (Multi User Dungeon) en C++. Un MUD est un jeu en ligne textuel dont on pourrait dire qu'ils sont les ancêtres des MMORPGs. Les joueurs créent des personnages, tuent des monstres, gagnent des niveaux, des sorts, trouvent des objets, se déplacent de salles en salles, etc.

D'un point de vue technique, c'est un simple serveur écrit en C++. Les joueurs se connectent via des clients MUDs (que je n'ai pas à coder, donc). Pour la partie réseau, j'utilise Boost Asio.

Mon problème :

Je suis en train de me demander de quelle façon je vais m'assurer de la persistance des données. Idéalement, j'aurais bien aimé avoir une base de données relationnelle parce que j'aimerais avoir la possibilité d'interroger facilement mes données. Concrètement, ça me permettrait d'avoir par exemple la liste de tous les orques ayant plus d'1 million de pièces d'or, ayant au moins 2 bateaux et faisant partie d'une guilde.

Ma stratégie consisterait à :
- charger toutes mes données au lancement du serveur
- pendant que le serveur est lancé, sauvegarder uniquement les objets nécessitant d'être mis à jour, toutes les minutes

Seulement voilà : je vais devoir persister un graphe d'objets relativement complexe. Les objets feront références les uns aux autres via des pointeurs. Je vais très certainement avoir des cycles de dépendances entre eux.

Et je n'arrive pas à me décider sur la façon dont je vais procéder. Ça fait des mois que j'y réfléchis sans trouver de solutions acceptable. J'ai pas mal cherché sur internet et j'ai pu lire tout et son contraire.

J'ai identifié les trois possibilités suivantes :

1) je sauvegarde tout dans une base de données relationnelle avec des Data Mapper. Je construis des requêtes SQL et j'essaie tant bien que mal de trouver un système me permettant de sauvegarder mes objets avec leurs dépendances (pas évident)
2) j'utilise un ORM comme ODB pour sauvegarder mes données dans une base de données relationnelle. Est-ce que la performance sera suffisante ? Est-ce que je ne serais pas limité dans la façon dont je conçois mes classes C++ ?
3) j'utilise Boost Serialization. Est-ce que la performance sera suffisante ? Est-ce que ça va pas allonger considérablement la durée de compilation ? Est-ce que j'arriverais à optimiser ma sauvegarde une fois le serveur lancé pour ne sauvegarder que les objets nécessitant d'être mis à jour ?

Je pense avoir une préférence pour la solution 1), parce que je pourrais tout contrôler. Mais je ne sais pas si je ne me lance pas dans une grosse galère. Est-ce que ça vous parait faisable ?

C'est pourquoi, j'aimerais bien avoir votre avis. Si vous pouviez m'aiguiller un peu, ça serait sympa.

A priori, tous les utilisateurs de C++ ont besoin de sauvegarder leurs données d'une façon ou d'une autre. J'ai du mal à concevoir que le sujet puisse être aussi complexe. En faisant des recherches sur internet, j'ai eu l'impression que c'était, peu importe la façon dont on s'y prend, TOUJOURS une grosse galère.

Merci !

Daily

Salut,

Je ne sais pas comment tu as organisé la représentation en mémoire des données que tu manipules, mais j'ai l'intime conviction qu'une approche de type ECS pourrait très largement être bénéfique.

L'idée de cette approche c'est que tout ce qui peut avoir une interaction avec "autre chose" (le joueur, le monstre, le marchant, le coffre, la porte, ...) n'est à la base qu'une entité; et qu'une entité, cela se contente ... d'exister. Ce qui est logique, car il est difficile d'interagir avec quelque chose qui n'existe pas ;)

Ensuite, vient la notion de composant, qui correspond au données brutes susceptibles d'intervenir dans les différentes interactions (la race, la quantité d'or disponible, le nom, le fait qu'il s'agisse d'une guilde, les points de vie ou de mana, ....) qui sont systématiquement associés à une entité existante, si bien que l'on pourrait envisager de dresser un tableau exhaustif de toutes les entités qui existent et des composants qui y sont associés qui pourrait ressembler à quelque chose comme

Code:

---

1 2 3 4 5 6

entité| race | or disp | nom | PDV | PDM | guilde | coffre | appartient à | créé par |... ------+------+---------+------------------+-----+-----+--------+--------+-------------------------... 1 | X |10000 | "coffre magique" | X | X | X | V | X | X 2 |Orque |100000 | "Grunch " |7500 | X | X | X | 1587 | X ... 1587 | X | X |"guilde truc" | X | X | V | X | X | 2

---

Où le X représente l'absence du composant considéré et le V représente la présence du composant en question (sans qu'il y ait pour autant besoin d'une valeur bien particulière).
A partir de ce genre de tableau, nous pourrions en déduire que

1. que l'entité numéro 1 est un coffre, nommé "coffre magique", qui n'a été créé par personne (il "existe", tout simplement) qui peut donner 10 000 pièce d'or à celui qui arrivera à l'ouvrir;
2. que l'entité numéro 2 est un orc, qui s'appelle Grunch, qui dispose de 7500 point de vie, mais d'aucun point de mana et qui appartient à la guilde représentée par l'entité numéro 1587
3. et, enfin, que l'entité 1587 est une guilde nommée "guilde truc" qui a été créé par l'entité numéro 2 (autrement dit, l'orque Grunch)

Mais bien sur, le tableau que je te montre ici serait en réalité une vue exhaustive créée de toutes pièces à l'aide des données que l'on manipule en réalité, car, en réalité, nous allons travailler avec des tableaux associatifs beaucoup plus petits dans le sens où, pour chaque type de composant que nous pourrions envisager, nous créerions une "liste de XXX" qui représente, quand elle existe, l'association d'un composant donné avec un entité particulière, par exemple

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

//La liste des association entre les entités et l'or disponible: liste_or_disponible =============== entité | or disp -------+--------- 1 |10000 2 |100000 //la liste des membre de guilde entité | numéro de guilde ------+----------- 2 | 1587 //la liste des noms liste_noms entité | nom 1 |"coffre magique" 2 |"grunch" 1587 | "guilde truc"   //la liste des guilde liste_guildes ========= entité | créé par -------+-------- 1587 |2 // et, bien sur, une liste des entités qui existent (encore) liste_entiés entité 1 2 ... 1587 .... 3958

---

Et cette représentation présente un intérêt majeur : elle correspond exactement à la manière dont je te conseillerais de sauvegarder les données de ton jeu dans la base de données ;)

Car une base de données, ce n'est jamais rien de plus qu'un ensemble de tables permettant d'accéder à des données bien spécifiques et que l'on peut mettre en relation les unes avec les autres.

La seule chose à laquelle il faille vraiment faire attention dans le cas présent, c'est à assurer la cohérence des données dans le sens où un composant quel qu'il soit ne peut pas exister s'il est associé à une entité qui n'existe pas ;)

Après, il y a la troisième partie de l'approche, le S (mis pour système ou services), qui correspond à la logique qui doit être suivie pour qu'une entité puisse interagir avec "ce qui l'entoure". Mais je ne vais pas m'étendre sur le sujet ;)