Comment stocker les données d'un MMORPG

[Helldream]

Bonjour,

J'espère poster dans le bon forum (j'ai eu du mal à savoir où poster ma question)... Je m'intéresse au mmorpgs (pas pour concurencer les mmorgs, existant, mais juste pour apprendre la théorie).

Et ma question est de savoir comment stocker les données relatives à un mmorpg, et plus précisément aux joueurs, par exemple...

Je vois un peu tout ce qu'il faut stocker (la position des joueurs, leur argent, objets, compétences, la position des objets (dans le cas où les joueurs peuvent déposer des objets en décoration chez eux, par exemple, la date de fin de validité de l'abonnement, son inscription, les objets équipés, etc)... Et je me dis que stocker autant de données, ca doit être lourd à consulter, dans une base de données (imaginons qu'il y ai rien que 1000 joueurs enregistrés, et que chacun d'eux aient une centaine d'objets, ca fait deja une bonne base)...

Donc existe-t'il des moyens pour pouvoir stocker/acceder efficacement aux données? (faudrait-il mieux créer un ficher par joueur, avec toutes les infos le concernant, ou stocker le tout dans une big base de données contenant tous les joueurs, tous les objets existants etc, ou encore d'autres solutions...)

Je ne sais pas si ma question est claire, mais je fais de mon mieux pour l'etre :p

[TrizoLakai]

Personnellement, pour mon petit RPG qui gère plusieur joueur(pas en simultanée ;))
Je crée un fichier par joueur.Avec des balises, genre
, ..., ...;

[SëB]

Bah normalement, ca se fait plutot dans une bdd...

Apres, en cogitant un peu, je m'étais demandé si on ne pourrait pas le faire dans un fichier xml qui serait transféré vers la bdd à la connexion du joueur...

Comme ca, meme si tu as 200 joueurs qui font 10 perso chacuns (soit 2000 perso au total), si il ne sont que 200 à jouer, ce n'est pas un probleme...
Tu sauvegardes la bdd à chaque fois que necesaire et qd le joueur ne donne pas signe de vie (déco), tu repasses le tout dans un xml...

Mais bon, je pense que les bdd sont prévues pour supporter bcp plus de 2000 enregistrement (si suffit de voir les pages jaunes, ou meme, plus simplement, le forum du GCN qui doit qd meme avoir une sacré bdd...)

Tu peux jeter un oeil à des serveurs de MMORPG (il y en a pour Lineage 2, Ragnarok, et Ultima Online je crois) qui sont gratuits et trouvables sur google.

Woilou :)

[Ark]

Je pensais faire un alternative de mon coté, charger en mémoire au lancement du serveur les données importantes de la base de données (par exemple les infos sur les zones), toute les infos qui ne requiert pas de modification en gros.

Ou encore charger toute les données en mémoire et faire des backups régulier sur la base de données ^^. Bien sur là tout dépend de la taille de la bdd. :D

[chaos]

je travaille actuellement sur monteur de jeux online et les infomation sont stocké dans une base de donnée MySQL qui a l'avantage d'etre rapide.

[Helldream]

C'est vrai que mysql est rapide, mais imagine un vrai mmorpg (comme Star Wars Galaxies)... il doit y avoir pas mal de joueurs (comptons 2000 enregistrer, mais il doit y en avoir bcp plus), chaque joueur peut avoir plus de 100 objets... Rien qu'en comptant ca, on atteint déjà plus de 200.000 enregistrements lol

C'est pas un peu trop pour la pauvre BDD? :) les requetes dessus ne risquent pas d'être longues à s'éxécuter?

[Ark]

C'est pas comme si ton programme allais chercher en permanence tout les objets de tout les joueurs dans base de données :p

En passant un mmorpg commercial qui marche a peu près bien, c'est environ 5000 personnes connectés en MEME TEMPS, PAR SERVEUR (voir FFXI).

[IronRaph]

Toutes les données doivent être stockées sur le serveur et que sur le serveur pour éviter qu'un petit malin s'amuser à augmenter ses perfs d'ailleurs tout le moteur du jeu est sur le serveur...

En gros tu fais une action elle est transmise au serveur qui donne la réponse...
C'est pas le client qui va toucher un monstre c'est le serveur.
C'est pas le client qui va faire marcher le joueur c'est le serveur.
Tu appuie sur la touche avancer ça envoi la requête au serveur puis le serveur te file ta nouvelle position!

Pour stocker les données c'est de la ddb genre postgré sql.

[Helldream]

Donc avec 5000 clients connectés, et facilement 10 fois plus enregistrés... et (que) 100 objets par personnes, on arrive à 5.000.000 d'éléments. Et une bdd peut arriver à suivre? ou il faut appliquer un autre méthode pour pouvoir gérer ce genre de cas?

[Ark]

Perso si c'est que les objets, dans ta bdd il y aura que des identifiant (entier), tu va pas stocker le nom de l'objet, la description de l'objet etc dans ta base de données.

Si toutes les décisions sont prisent par le serveur, tout l'aspect "descriptif" est géré coté client. Ca marche pour les objets, mais aussi pour tout le reste (les zones, les armes...). Essayer de rendre ta bdd la plus light possible. Mais honetement faire sans BDD je sais pas si c'est vraiment possible, les temps d'accès risquent d'être plus long pour un/des fichier(s).

[Helldream]

En gros, la BDD servirait à dire que tel perso a l'objet 1483 et 0873... Et le client aurait un "table de correspondance" disant que l'objet n°1483 est un bout de camembert bleu, etc... c ca?

[Ark]

c'est ca en effet

[IronRaph]

De toute façon dis toi qu'un serveur de MMORPG c'est un monstre et souvent ils sont clusturisez... :)

[Cellimo]

juste une remarque, pour les sois disants 5.000.000 enregistrements...
il suffit d'avoir plusieurs serveurs (pas trop dur) et de désigner pour chaque serveur un nombre quelconque de joueurs, par exemple une base contiendra toutes les informations concernants les joueurs dont les noms commencent par a b et c ou tout les joueurs qui sont chez yahoo, ou gmail etc

[Majime]

C'est vrai que mysql est rapide, mais imagine un vrai mmorpg (comme Star Wars Galaxies)... il doit y avoir pas mal de joueurs (comptons 2000 enregistrer, mais il doit y en avoir bcp plus), chaque joueur peut avoir plus de 100 objets... Rien qu'en comptant ca, on atteint déjà plus de 200.000 enregistrements lol

non, vu que tu transféres chaque paquet sous forme de string avec un séparateur de variables, pendant la partie il suffit ensuite à ton programme d' envoyer dans ses paquets seulement les données relatives aux positions et l'action en cours comme dans un FPS multijoueur, et les autres données pendant les phases de commerce, d'échange d'equipement...

[minirop]

Donc avec 5000 clients connectés, et facilement 10 fois plus enregistrés... et (que) 100 objets par personnes, on arrive à 5.000.000 d'éléments. Et une bdd peut arriver à suivre? ou il faut appliquer un autre méthode pour pouvoir gérer ce genre de cas?

wikipedia a une BdD maitre et plusieurs esclaves.

[Flamaros]

Je dirais que ca depend du type de requete que tu fais surtout, si elles sont tres precise ca va plus vite que si tu sors plein de resultats d'un coup.
Perso j'ai deja pu faire des requettes sur des bases contenant des listes d'appels telephoniques (nombre incroyable d'entre par table) et ca se passe tres bien (quelque centieme de seconde il me semble).

[Helldream]

OK. Merci bcp de vos réponses, elle me sont bien utiles ^^

[Edward]

Si tu veux savoir sans te prendre la tete comment ca marche essaye de faire un MMORPG avec PHP et MySQL. Ca aide a comprendre (meme si c'est pas aussi difficile qu'en C++)

[listorien]

Perso, je stocke tout dans des fichiers XML stockés sur le disque. Ensuite, dès qu'un joueur arrive, je charge le XML en mémoire et le converti en objet (C++/C#/VB...)
Et dès qu'un joueur s'en va ou déconnecte, je recrée le XML et je le sauvegarde sur le disque.
Donc le joueur arrive -> XML se charge et le joueur s'en va -> XML sauvegardé.
Le XML ne me sert qu'à la sauvegarde sur disque, je ne modifie pas sa structure quand le joueur est connecté, je modifie l'objet du joueur en mémoire.

Ensuite, je fais des sauvegardes toutes les 5-10 min des joueurs sur disque au cas ou le serveur crashe ou qu'il y ai une panne de courant.

Je n'utilise pas de BDD mais je pense qu'on peut s'en passer en classant les sauvegardes des joueurs dans des répertoires, par exemple par ordre alphabétique (à partir de 10000 fichiers dans un répertoire, windows a du mal...)

Je pense qu'il faut utiliser une structure genre XML et non une BDD avec des colonnes pour les armes et le reste car ça risque de devenir ingérable si on désire faire des évolutions genre :

- Des armes/objets enchantés (il faut recréer des colonnes dans la BDD pour associer l'enchantement aux armes du perso)
- Des armes/objets qui peuvent s'user (il faut aussi conserver cette infos en parallèle avec l'arme du perso)
- L'IA et le paramètrage des personnages non joueurs.

La solution BDD me parait mauvaise car ça risque d'être l'usine à gaz !

Bref, je ne vois pas l'intérêt d'une BDD, sauf si c'est pour y stocker le XML en lui même, quoique le système de fichiers me parait être une solution plus souple pour modifier les sauvegardes des joueurs en cas de bugs/triche/test beta ou autre problème.

De plus, il est hors de question de stocker des infos directement dans les tables SQL pendant le jeu, par exemple, dès qu'un joueur rammase un objet -> insert into ... Les performances du serveur s'écroulerait...

Bien sûr, pour un jeu en PHP, c'est une solution inévitable mais là je parle d'un MMORPG avec un client lourd.

a+
Listorien

[Flamaros]

Alors dans ce cas pourquoi tout les MMO tournent sur des BDD?

Et les requetes sont du genre extrement rapides, il suffit de quelques centieme de seconde pour effectuer une requete. Il me semble que SQL n'ecrit pas en permanence dans les fichiers les bases de donnees restent en memoire vive sur les serveurs.

[IronRaph]

Y a tout un système de bufferisation comme partout d'ailleurs...

En gros il attend d'avoir pas mal de trucs à écrire pour tout écrire d'un coups c'est bien plus rapide que de faire tout le temps de petits accès disque :)

[listorien]

Alors dans ce cas pourquoi tout les MMO tournent sur des BDD?


Ben je ne sais pas, mais même avec un système de cache pour SQL, je trouve que c'est super lourd. Immaginez qu'à chaque fois que le perso se déplace ou parle, il y a une écriture dans la BDD ! Pour peut que le serveur SQL se trouve sur un autre serveur il y a une entrèe/sortie sur les 2 serveurs à chaque fois qu'un joueur fait une action. Même en local, il y a une communication qui se crée entre le serveur de jeu et la BDD. Bonjour la perte de performances ! Pour un MMORPG avec des milliers de joueurs, le serveur ne peut pas se permettre de perdre un dizième de secondes.
Il y a un truc qui m'échappe là...

Ou alors, le système de BDD est utilisé seulement pour les sauvegardes et pour partager l'info entre les différents serveurs. Par exemple, chaque serveur à sa zone de jeu et dès qu'un joueur sort d'une zone, il est envoyé dans la BDD et récupéré par un autre serveur, quoique qu'un socket permanent entre les serveurs ferait parfaitement l'affaire...

Non, je pense que la BDD est utilisé pour les sauvegardes uniquement, en simplifiant, il n'y a qu'une table qui contient le login des joueurs en clé primaire comme ça le serveur peut récupérer l'objet du joueur dans la BDD et le charger en mémoire où il y restera jusqu'au backup ou à la déconnexion du joueur.

Pour résumer mon scénario conçernant les joueurs uniquement :
- BDD et serveur démarre
- le serveur n'interroge pas encore la BDD
- un joueur se connecte
- le serveur fait une requête SQL et récupérer l'objet xml du perso (contenant sa vie, mana, équipement, position, etc...)
- le serveur charge l'objet xml en mémoire dans un array contenant les joueurs
- le joueur joue, pendant ce temps, le serveur ne parle plus avec la BDD, seul l'objet en mémoire est modifié si le joueur parle ou ramasse des objets
- le joueur déconnecte
- le serveur transforme l'objet du joueur en xml et l'envoi à la BDD
- le serveur detruit l'objet du joueur en mémoire et le supprime du monde

C'est comme ça que je fais pour mon MMORPG, sauf que je n'utilise pas de BDD mais le système de fichiers.

Listorien

[Flamaros]

Pour ton information j'ai fait un stage dans une boite de telephonie sur IP et les bases de donnees sont plutot bien remplies et tres solicite. Les serveurs sont des machines specifiques qui ont generalement beaucoup de RAM et un CPU qui peut etre relativement lent (genre un PIII 500Mhz avec 2Go) et ca tout simplement parceque les acces disques sont differe par rapport aux requetes, les tables les plus utilisees sont en permanence en RAM pour avoir les meilleurs temps de reponses, les modifications sur les fichiers doivent intervenir quand les disques sont dispo et intervals regulier.

Le probleme avec tes fichiers XML c'est que si tu as 1000 personnes qui se connectent dans la meme minute tes disques vont en prendre un saccre coup, Alors qu'avec SQL ben les infos sont dans la RAM du serveur.
N'oublie pas que plus tu sollicites un disque dur plus il te lachera tot or le but d'un serveur c'est d'eviter qu'il plante, il faut menager le materiel.

Les bases de donnees sont a mon avis pas du tout un moyen de faire des sauvegardes (fichiers peux sollicite), bien au contraire.

En plus avec des fichiers tu dois toi meme faire les verifications que tu n'as pas de doublon alors qu'en utilisant les clefs tu n'auras pas ce probleme la requete te renvoyant qu'elle a echouee.

PS : je pourrais surement vous apporter plus d'info sur leur fonctionnement vu que je dois en creer une cette annee.

[listorien]

Oui avec cet argument, tu as raison, je pense qu'une base SQL, c'est bien mieux qu'un système de fichiers.
Pour en être certain, il faudrait faire le test de charger 1000 fichiers XML d'un coup sur disque et charger 1000 fichiers xml d'un coup depuis une BDD (dans des requêtes séparées).
Les bases de donnees sont a mon avis pas du tout un moyen de faire des sauvegardes (fichiers peux sollicite), bien au contraire.
Je ne comprend pas là...
En plus avec des fichiers tu dois toi meme faire les verifications que tu n'as pas de doublon alors qu'en utilisant les clefs tu n'auras pas ce probleme la requete te renvoyant qu'elle a echouee.
La vérification de doublons ne se fait qu'à la création du perso pour vérifier si le joueur n'est pas déjà enregistré. A part à cet instant, je ne vois pas ou il faudrait en faire. Pour tester si un perso est déjà connecté, on interroge pas la BDD mais la RAM du serveur.

[Bahamut]

c'est même plus complexe que ca. Prenons l'exemple de l'inventaire d'un joueur : il s'agit d'une liste d'objets qui ont chacuns des caractéristiques :
- le type d'objet (collier/armure/botte/épée/pistolet/nourriture/fiole)
- la nature du type d'ojbet(fiole de vie, fiole de mana, épée en fer, épée en verre, etc.)
- la taille de l'objet (grande épée/petite épée/moyenne épée)
- magie associée à l'objet (botte enchantée avec +2 en vitesse, casque de vision de nuit, etc.)
- usure de l'objet
- couleur de l'objet (rose/rouge/gris/etc.)
- prix de l'objet
- si objet est cassable
- si objet peut etre amélioré (mécaniquement/par magie)
- si objet peut etre utilisé dans la main gauche du personnage
- si objet peut etre porté par la classe de personnage (genre interdit aux sorciers)
- etc. etc.

En résumé : juste pour un inventaire d'un seul joueur , on peut l'associer à des centaines de paramètres (j'ai bien des 100 ! et juste pour ses objets).

Ensuite , il y a d'autres parametres comme le statut du personnage :
- son age
- ses points de vie
- ... de mana
- ca résistance au feu
- sa force, vitalité, intélligence, etc.

D'ou, pour un seul joueur, on peut atteindre RAPIDEMENT plus de 150 parametres.
Maintenant, si on calcule un ptit peu, pour 1000 joueurs, obtient :
- 150000 parametres

(au passage, je laisse deviner que le jeu World Of warcraft ne fonctionne pas avec une base de donnée MDL (format de Microsoft Access) )


AVEC XML :même si on peut regrouper tous les parametres pour un joueur donné dans 1 ou 2 GROS fichiers au format XML... il s'agit de bcp d'informations qu'il va falloir "parser"...et ca prendre du temps.

AVEC une BDD : il s'agit juste d'une requete... Il faut savoir que les BDD peuvent retourner la valeur et SANS PROBLEME parmi des centaines de milliers de paramètres.

Premiere Conclusion : les bdds permettent de gagner du temps.

Autre point important : la maintenance des données
Le gameplay d'Un MMORPG est fait pour évoluer. Par exemple, il faut proposer aux joueurs de nouveaux sorts de magie, des nouveaux monstres, etc.
Des qu'il faut modifier un parametre qui touche au fichier de chaque joueur, je laisse deviner le desastre si la méthode de sauvegarde est XML.
Juste au passage, ajouter un nouveau sort avec une base de donnée = une seule requete.

Donc 2eme conclusion : la BDD permet de maintenir Facilement les données du joueur.

Je ne dis pas que le XML est "mal" mais de très loin inadapté à ce style de jeu.
Evidemment, tu ne comptes peut etre pas atteindre les 1000 joueurs mais saches qu'avec 100 joueurs..tu gagneras quand meme à passer par les BDD.
Amicalement,

Bahamut

PS : je travaille actuellement sur des grosses BDD pour mon boulot pour préciser que je ne parle pas ds le vent ^^

[ffomnislas]

les fichiers ca fragmente aussi , surtout sous windows.

Les info des joueurs ... sont à sauvegarder dans une base de données comme postgress ou autre ( non je ne citerais pas microsoft :D). Il ne faut même pas penser aux fichiers ;)

[Flamaros]

Les bases de donnees sont a mon avis pas du tout un moyen de faire des sauvegardes (fichiers peux sollicite), bien au contraire.

Ce que je veux dire c'est tout simplement que les sauvegardes sont generalement la duplication des donnees (a un endroit sur) et pas vraiment l'ecriture de simple fichier qui correspond juste a un enregistrement des donnees.


La grosse difference entre les BDD et la methode que tu cites c'est que les BDD font totalement abstraction des fichiers qui sont sur les HD du serveur. Et je pense egalement que les algorythmes de recherche sont bien plus optimise que ceux que tu peux coder. Les conteneurs de la STL ne te permettent pas une rapidite importante sur des demandes complexes par exemple.

[Bahamut]

Une remarque supplémentaire :

Des accès temps réels dans une BDD n'est pas gourmand en terme de temps.
Les vraies bases de données professionnelles sont très rapides. Effectuer une requête SELECT est rapide à condition que la base soit très bien structurée et qu'on sache utiliser de façon optimale les index... mais il s'agit d'un métier professionnel à part entière (il faut réellement prendre ca en compte).

Et si on veut pousser encore plus loin, il est possible en SQL de regrouper plusieurs requêtes pour intéragir plus rapidement avec la base en une fois : transactions. Mais je le redis encore... c'est tout une profession. Utiliser une BDD n'est pas anodin dès qu'il s'agit d'enregistrer des dizaines de millier de paramêtre.

Mal organiser une BDD (mauvaises tables/index/colonnes...), c'est comme créer une mauvaise conception objet en C++...et les conséquences peuvent être catastrophiques en temps d'accès.

Voila ^^
Si tu veux plus de détails, n'hésites pas.

[listorien]

1) Je ne suis pas totalement d'accord avec ceci :
c'est même plus complexe que ca. Prenons l'exemple de l'inventaire d'un joueur : il s'agit d'une liste d'objets qui ont chacuns des caractéristiques :
- le type d'objet (collier/armure/botte/épée/pistolet/nourriture/fiole)
- la nature du type d'ojbet(fiole de vie, fiole de mana, épée en fer, épée en verre, etc.)
- la taille de l'objet (grande épée/petite épée/moyenne épée)
- magie associée à l'objet (botte enchantée avec +2 en vitesse, casque de vision de nuit, etc.)
- usure de l'objet
- couleur de l'objet (rose/rouge/gris/etc.)
- prix de l'objet
- si objet est cassable
- si objet peut etre amélioré (mécaniquement/par magie)
- si objet peut etre utilisé dans la main gauche du personnage
- si objet peut etre porté par la classe de personnage (genre interdit aux sorciers)
- etc. etc.

Au lancement du serveur, celui-ci charge le monde et par conséquent, il charge aussi la liste de tous les objets possibles. Les caractéristiques d'un l'objet sont donc déjà connus avant que le perso se connecte.
Les objets sont forcément près chargés, connu du serveur mais aussi du client. Car pourquoi envoyer l'info au client que l'objet hache0587 est rose, fait 58cm de longueur alors que celui-ci pourrait déjà avoir l'info sur le DVD d'installation du jeu ? C'est une économie de bande passante énorme.

Dans la sauvegarde du perso, il n'y a pas toutes ces infos. La sauvegarde ne contient qu'un identifiant vers un objet + éventuellement des modificateurs propres à l'instance de l'objet que possède le perso comme l'usure ou l'enchantement .Pourquoi sauvegarder la taille, la nature, le type, la main gauche, etc... dans le fichier de sauvegarde si le serveur a déjà ses infos ?

2) Un fichier XML se compose à peu près comme ceci :


<perso>
<login>abcd</login>
<password>abcd</abcd>
<x>53</x>
<y>48</y>
<monde>maisondegargamel</monde>
<vie>21</vie>
<mana>25</mana>
<attaque>45</attaque>
<equipement>
<objet>
<id>epeelonguebronze</id>
<usure>45</usure>
<usuremax>100</usuremax>
</objet>
<objet>
<id>camembertbleu</id>
</objet>
<objet>
<id>bouclier</id>
<usure>58</usure>
<usuremax>200</usuremax>
<enchantement>boostattaque(1)</enchantement>
</objet>
<objet>
<id>carquois</id>
<usure>15</usure>
<usuremax>30</usuremax>
<contenu>
<flechesmagiques>75</flechesmagiques>
<flechesbois>12</flechesbois>
</contenu>
</objet>
</equipement>
</perso>

Quand on a le fichier de sauvegarde du joueur, les infos de l'équipement, on les a déjà, et ceci sans faire la moindre requête ! On récupère le fichier dans la BDD (ou sur le disque peut importe) quand le joueur se connecte et on lit tranquillement les infos pour les recopier en mémoire. L'avantage du XML est la hiérachie d'infos qu'il nous propose. Pas besoin de faire des requêtes dans 50 tables. Dans ce cas, une lecture mémoire d'une stream XML est plus rapide qu'une lecture en BDD. Chaque objet a ses propres caractéristiques qui sont crées lorsque le programmeur code l'objet. Le principal but du XML est non pas d'accéder aux données le plus vite, mais de reproduire un objet joueur dans la RAM du serveur. Une BDD c'est pour accéder à des infos précises avec une grande facilité : A t'on besoin de savoir quels sont les joueurs avec une épée, situé dans le monde des schtroumphs et avec moins de 30 pièces d'or ???

3) Une BDD/fichier XML se sert qu'aux sauvegardes (et éventuellement aux stats) c'est vrai car le serveur travaille avec ses infos en mémoire et non avec une BDD. La BDD/XML est là pour quand le joueur quitte le jeu ou pour faire une sauvegarde des infos programmées en cas de coupure de courant.
Lorsqu'un perso entre dans une nouvelle zone avec 50 joueurs autour de lui. Le serveur va lui envoyer la liste des joueurs avec leur position et leur aspect visuel. Il est impensable qu'il utilise une BDD pour obtenir cette info ! Et ceci parce qu'il n'a pas de temps à perdre. Même si la BDD est ultra rapide, il se sera bien écoulé quelques millisecondes avant que le serveur les récupère. A celà, il faut encore rajouter quelques ms, le temps qu'il les envoi au client. La désynchro risque d'être critique ! Il prend les infos qu'il a en RAM et les envoi directement c'est pour ça que je dis qu'une BDD ne sert qu'à la sauvegarde.

Une fois, je jouais au jeu MMORPG runescape sur www.runescape.com A un moment je me suis retrouvé déconnecté brutalement du jeu sans raison. En fait le serveur venait de planter ou il y avait eu un problème avec. Quand j'ai réussi à me reconnecter, mon perso avait fait un bon de 10 min dans le passé. C'est à dire que les données venaient d'être restaurées à partir des fichiers ou de la BDD. Enfin, c'est ce qui était écrit dans un message d'administration...

Autre chose, j'ai testé le temps que met le serveur postgres du boulot pour renvoyer le résultat d'une requête simple sur une table de 6000 enregistrements : environ 10 millisecondes en local et 20 ms en réseau. Pour une requête compliquée, on tourne au delà de 100ms. C'est très rapide pour accéder à des infos pour pages web, pour un jeu en temps réel, c'est inadmissible. C'est pour ça que je dis que le serveur de jeu doit uniquement travailler avec la RAM en chargeant un max d'infos et utiliser la BDD/système de fichier qu'occasionnellement.
Pour info, j'ai mis un benchmark sur le chargement de mes fichiers de sauvegardes de joueurs et le taux moyen pour parser et loader un fichier est de 25ms (avec mon disque dur de portable 4200tr/min)

Donc pour résumer :
- Système de fichiers, pourquoi pas mais risque de lenteur si trop de joueurs se connectent en même temps. Il faut aussi oublier les fichiers dans le cas où il y a plusieurs serveurs de jeux attaquant les mêmes données.
- BDD ok mais pas trop souvent. Nécessite plus de maintenance qu'un fichier XML car ce dernier n'est qu'une image mémoire d'un objet en RAM. Si 1000 joueurs se connectent en même temps, le serveur s'écroule 100ms * 1000 = 100 secondes pour charger 1000 players On se retrouve donc dans le même problème que les fichiers.

La solution idéale (pour moi) a vous de me contredire, est donc une BDD contenant les fichiers XML ou une structure d'objets quelconque avec des accés à celle-ci strictement nécessaire: Login - Backup - Déconnexion

PS : je travaille actuellement sur des grosses BDD pour mon boulot pour préciser que je ne parle pas ds le vent ^^

Est-ce que tu peux nous dire quel est le temps mis en ms par tes BDD pour répondre à une seule requête de sélection sur une dizaine de table et sur une vingtaine de colonnes ? Et la même requête mais sur une mise à jour (par exemple si le perso perd 1 point de vie). Attention au cache de la BDD.

a+
Listorien

[Octopod]

Prenant l'exemple de WOW (auquel je joue), certaines actions solicitent uniquement la mémoire des serveurs (coords du perso, nivo energie, nivo mana, armes et effets magiques en cours, etc) alors que d'autres solicitent les BDD (connexion, deconnexion, les manipulations sur l'inventaire ou l'arbre des talents, la validation des quêtes, l'envoi de mail, la consultation du hall des ventes, qui prennent toujours quelques centaines de ms, voir quelques secondes qud ça mouline).

En RAM sur le serveur maitre (celui avec qui tu parles) ce qui doit l'être pour te permettre de jouer avec un bon ping, et sur les serveurs esclaves et en BDD le reste (ce qui n'appartient pas au 'feu de l'action').

En ne gardant en RAM que ce qui compte, le serveur décharge à la BDD et aux autres serveurs esclaves ce qui ne demande pas de retour rapide au joueur.

Pour un très gros MMORPG, oubliez le XML, notamment parcequ'il faut pouvoir administrer les bases d'infos de milliers de joueurs, de centaines de PNJ, de centaines d'objets ou d'indicateurs divers (des manip que les bases de données font à merveilles puisqu'elles servent à ça) pour mettre à jour des valeurs, faire des stats, etc. Les BDD actuelles sont hyper optimisées et tiennent largement les performances d'une solution de stockage 'maison', surtout si leur cache RAM est bien rêglé.

Maintenant, c'est comme pour tous les jeux, il n'y a pas une architecture unique à suivre, mais une architecture qui correspond à la charge demandée par le jeu : serveur 256Mo RAM avec tout en XML sur 1 disque ou serveur maitre 16Go RAM + 8 esclaves 2Go avec BDD en RAM ? ben ça dépend du jeu, c'est selon les actions possibles et des infos à manipuler, le tout multiplié par le nombre de joueurs.

Alexis.