Discussion :

[vmolines]

Bonjour,

ayant une culture d'informaticien de gestion, je connais les principaux SGBDR et leurs particularités. Cependant je me demandais comment fonctionnaient les MMORPG (j.d.r. massivement multijoueurs) ?

Est ce qu'un SGBDR classique comme oracle peut être utilisé pour ce genre d'application ? J'y connais rien mais j'ai l'impression que ce genre d'application nécessite des mécanismes particuliers.

L'exemple qui m'est venu à l'idée est le suivant :

un personnage se déplace > en permanence ses coordonnées doivent être réactualisées. C'est où je me dis qu'un SGBDR n'est pas adapté...

Mes suppositions sont elles exactes ? Si oui alors quels sont les concepts utilisés ? J'ai du mal à trouver de doc sur le net sans mot clé.

Merci

[Admin]

Oui on utilise un SGBDR classique.

Mais attention l'architecture est un peu différente du client-serveur SGBD
Là tu as un serveur propre au jeu.
Donc le schema serait plutot :

Client <---web--->Serveur Jeu<---LAN--->Serveur SGBDR

Sachant que pour chaque client connecté au serveur de Jeu tu peux creer une instance d'un objet, et donc stocker par exemple la position du joueur non pas en SGBD mais en mémoire car il change trop souvent.

En SGBD tu vas stocker les choses importantes, l'inventaire, le niveau, la répartition des points d'XP etc,etc...

Cela dit rien ne t'empeche de stocker tout en mémoire, et d'updater la base de donnée uniquement au moment de la deconnexion utilisateur ou un timeout.

[vmolines]

Que tu me dises que les données régissant le monde persistant soient hébergées par une application serveur orientée objet, ça me va totalement.

Par contre qu'il y aie une appli serveur orientée objet ET un SGBDR pour stocker différentes partie du modèle ... ça m'étonne fortement.

[Admin]

Le SGBD est là pour stocker les données importantes, soit les données du joueur.

Prenons par exemple un jeu auquel je joue en ce moment, Guild Wars, voila comme il fonctionne:

Tu peux croiser tout les autres joueurs dans les "avant-postes", les villes en quelques sorte.
Par contre, une fois que tu sors des villes, tu possède une carte instancié ou tu es seul (ou avec ton groupe), chaque groupe possède sa propre carte, et aucune interaction entre les différents groupes est possible (tu ne vois même pas).

Pour moi, l'objet instancié répond clairement à cette problèmatique.

[vmolines]

Je suis pas super convaincu du tout par l'utilisation d'un SGBDR pour un MMOG mais plutot par une grosse appli serveur orientee objet. Qu'on soit seul à évoluer ou pas, c'est pour moi une autre problématique : séparer efficacement la charge sur plusieurs bécane. Et c'est ce qui se passe lorsqu'on te fait évoluer en nombre limité sur une nouvelle instance d'un monde (maitrise de la charge sur l'appli serveur). Chose qui n'est pas maitrisée et donc plus dure a affronter dans un vrai mmorpg > tout le monde au meme endroit = 1 appli serveur qui en prend plein la tronche.

Je me trompe peut etre totalement, mais je le ressens a fond comme ca.

[Admin]

Les solutions de cluster sont justement là pour faire du load-balancing.
Sachant que pour Guild Wars, meme sur une carte instancié, je peux parler avec n'importe quel autre joueur, qu'il soit ou non présent sur la même carte que moi.

Une notion très connu des joueurs online est le time warp, lorsque le serveur crash, l'editeur recharge une base de données à jour (j'ai déjà vu des warp de plus de 8h), et tout ce que tu as fait depuis les x heures est perdu.

Je peux déjà te donner le nom d'un jeu, La Quatrième Prophetie qui est l'un des premiers MMORPG qui utilisait Oracle.

PS : je parle par experience des MMORPG, là ou tu as une continuité sur la durée, pour tout ce qui est Counter Strike like, je ne pense pas qu'il y ai une base de données derrière.

[vmolines]

Ok merci pour tes infos et pardonne mon sceptiscisme, je suis comme ça