Réponses:
Nous l’avons fait, espérons que Ben Z expliquera mieux les raisons que moi car il était en fait l’auteur de notre base de données. La version courte est que les bases de données relationnelles ne sont pas très utiles pour les jeux, car elles ne peuvent pas stocker efficacement des données hiérarchiques fortement structurées, ce qui constitue la grande majorité des données dont un MMO a besoin pour un fonctionnement normal. Nous avons choisi de créer une base de données d’objets personnalisés faisant partie d’un système de traitement des transactions distribué, qui est maintenant en production et alimente nos deux jeux en direct.
Quant à si vous deviez faire la même chose? Probablement pas, du moins pas au début. Je recommanderais toujours d'éviter SQL, mais il y a maintenant beaucoup plus d'options dans le monde "NoSQL" qui n'existaient pas il y a quelques années.
Cela dit, la plupart des MMO fonctionnent sur des bases de données SQL (relationnelles). Je sais qu'Eve fonctionne sur une installation SQL Server reposant sur quelques RAMSAN multi-TB (je n'aurai probablement jamais de ma vie autant d'argent que cela coûterait).
EDIT: Espérons que cela ne me dérangera pas que je poste ceci ici, mais ceci est une entrée de blog avec des liens et des commentaires sur la présentation que nous avons donnée à GDC'08 à propos de notre base de données.
Ok, cette réponse est plus une observation.
Divulgation complète Je n'ai pas travaillé sur le MMORPG. J'ai travaillé sur l'un des 10 sites les plus visités du monde en 2009, et j'ai travaillé pour une société de moteurs de jeux qui pensait utiliser la technologie MMORPG (je ne sais pas si elle a été livrée).
Si vous regardez des sociétés qui ont atteint une taille considérable (Google, Facebook, Twitter, etc.), je sais qu’elles ne sont pas des sociétés de jeux, mais qu’elles méritent d’être examinées dans cet espace), j’estime que deux choses sont importantes.
Une grosse erreur est de prendre une chose chère clé en main et de s’attendre à ce qu’elle se répète comme par magie. Ça ne marche pas comme ça. La clé de la mise à l’échelle consiste à traiter chaque nouveau défi de manière appropriée. Vous avez besoin de solutions flexibles, faciles à utiliser et faciles à installer.
Je vous conseillerais donc, si vous débutiez, d'obtenir ce qui vous semble le moins mal à la tête.
En gros, il existe toute une gamme d’approches, et je pense qu’elles ont été choisies en fonction des expériences de leurs développeurs et des propriétés de la base de données. À une extrémité, de nombreux MMO utilisent des bases de données relationnelles standard - par exemple. Dark Ages of Camelot a utilisé / utilise (est-ce qu'il y en a toujours?) MySQL , FreeRealms utilisent un Postgresql modifié , etc.
En vous déplaçant le long de la balance, vous avez Guild Wars: ils utilisent SQL Server , mais ils y insèrent leurs données sous la forme d’un seul BLOB. Cela signifie qu'ils bénéficient des avantages de leurs formats binaires habituels et de certains des avantages offerts par une base de données. Il va sans dire que cette approche présente également certains inconvénients, mais pour une entreprise qui travaillait autrefois avec des fichiers plats, il s’agit probablement d’une avancée supplémentaire.
Ensuite, il y a probablement des endroits qui utilisent les différentes approches NoSQL formalisées, bien qu'il soit encore tôt. Farmville utilise la membase , qu'ils ont créée à cet effet, apparemment sur la base de mémachée. Cela partage de nombreuses fonctionnalités avec MongoDB, CouchDB, etc. Encore une fois, avec ces approches, vous créez généralement vos propres formats de stockage tout en bénéficiant des avantages de la distribution, de la mise en cache, de la redondance, etc.
Certains lancent entièrement leur propre NoSQL: Cryptic a déclaré avoir fait quelque chose de similaire, mais a également déclaré ne pas l'utiliser en production. ( EDIT : mais voir les commentaires ci-dessous.)
Et ensuite, vous rencontrez des personnes qui utilisent des fichiers texte ou binaires - si je comprends bien, les jeux plus anciens comme Ultima Online, Everquest, etc. ont tous suivi cette voie, et pour une entreprise ayant une expérience en développement de jeux mais peu d’expérience dans les bases de données, cela fonctionne bien. aussi.
Notez également que vous n’écrivez presque jamais votre propre base de données dans un sens vague - dans les jeux, vous aurez toujours des données personnalisées que vous devez gérer en mémoire ou sur disque d’une manière qui ne se prête pas à elle-même. logiciel générique. Vous ne pouvez pas effectuer de requêtes SQL à chaque fois que vous souhaitez obtenir des données; vous devrez donc refléter une grande partie de vos informations dans le code, quel que soit le traitement que vous utilisez.
Sur Pirates of the Burning Sea, nous avons démarré avec MySQL (même si, honnêtement, j'aurais préféré Postgres), et lorsqu'il a commencé à s'effondrer, nous sommes passés à Microsoft SQL Server. Honnêtement, cependant, je ne referai probablement pas cette voie dans le futur. La plupart des données PotBS sont pré-sérialisées avant même de persister. Une grande partie de la base de données n'est donc qu'un magasin de clé / valeur saturé. En plus de cela, pour obtenir de meilleures performances de notre couche de persistance et un meilleur contrôle de la mise en cache des données en mémoire, nous avons fini par écrire un serveur de mise en cache situé devant la base de données.
Donc, Kylotan a tout à fait raison, vous n'allez pas vous débrouiller seul. Les serveurs de bases de données relationnelles SQL ne sont pas conçus pour la manière dont les jeux utilisent les données. Au lieu de supposer que les serveurs de base de données relationnels constituaient la base de toutes les bases de données, nous aurions vraiment dû réfléchir davantage aux avantages que nous recherchions avant de choisir un outil.
La prochaine fois, je m'intéresserais davantage à BerkleyDB ou à d'autres bases de données de type NoSQL.
Une autre chose à noter est que si vous avez un jeu de données (relativement) statique, ne le stockez pas dans une base de données! Il n'y a pas vraiment de bonne raison de stocker vos définitions de sorts, définitions d'objet, cartes, etc. dans une base de données. Vous les interrogez rarement, sauf par leur nom. Je vois beaucoup de personnes se lancer dans le développement de jeux en stockant ces éléments à côté de données de joueurs persistantes, ce qui est une classe totalement différente.
Vous avez besoin d'un magasin de données, comme un système de fichiers, pour cela. En dehors du développement, vous n'avez pas besoin d'ACID, vous n'avez pas besoin de CRUD, vous n'avez pas besoin d'une base de données pour ce type de données. Dans le cadre du développement, vous avez besoin d’une base de données, mais vous avez également besoin d’un VCS, et votre choix de VCS fera ce choix de base de données pour vous.
(Si vous travaillez sur un jeu dans lequel les joueurs peuvent créer des sorts, des objets ou des quêtes personnalisés, eh bien, ces données sont du même type que les données du joueur et vous avez à nouveau besoin d'une base de données.)
Les MMORPG sont des applications intensives et sont une entreprise énorme. Si vous débutez avec le développement de jeux, je vous recommande fortement de faire quelque chose de plus petit.
Cela dit, vous aurez besoin de deux performances optimales hors de votre configuration. Vous allez évidemment avoir besoin d'une batterie de serveurs / ruche. Les communications réseau étant relativement coûteuses (et la plupart des MMORPG étant en temps réel), vous souhaiterez peut-être répliquer votre base de données centrale sur chacun de vos serveurs de jeux (l'équivalent d'une réplication en temps réel à faible temps de latence dans la base de données de votre choix).
Si chacun de vos serveurs dessert un segment spécifique du monde du jeu (comme WoW fonctionne); quelque chose comme des vues partitionnées distribuées . Les fichiers DPV vous permettent de segmenter les lignes de votre base de données sur différents serveurs. en fonction des contraintes sur les colonnes sur chaque serveur. MSSQL et Oracle sont suffisamment intelligents pour ne parler qu'au serveur qui contient les données comprises dans votre clause WHERE ou ON. Je ne suis pas sûr que l’une des offres open source ait des DPV.
Le résultat net de tout cela est que peu importe la base de données que vous utilisez , utilisez-en une qui porte un bon nom: MSSQL, Oracle, MySQL, PostgreSQL. Ecrivez votre base de données en ANSI SQL et voyez quel système fonctionne le mieux. C'est le seul moyen de le savoir.
La route NoSQL peut également être une bonne idée car elle est conçue pour les accès simultanés élevés. La suggestion de Pranny pourrait faire l'affaire.
J'ai utilisé MongoDB (NoSQL), c'est un magasin de documents très rapide auquel on peut accéder via TCP. Essaie! C'est génial!
Écrire votre propre base de données est une tâche ardue. Je vous suggère d’abord d’explorer ce qui existe déjà et, si vous ne trouvez rien qui corresponde à vos critères spécifiques, créez le vôtre. Oh, et n'oubliez pas d'ouvrir le code source. :)
J'imagine que cela dépend beaucoup du type de données que vous avez besoin de stocker et sous quelle forme.
Je pense que la plupart des gens utilisent des bases de données SQL "standard" pour des données "dynamiques" telles que les informations sur les joueurs, que ce soit SQL Server, MySQL, PostgreSQL.
Cependant, les données "internes" (état du monde, contenu, ...) peuvent être stockées sous n'importe quelle forme, et je suppose que la plupart des entreprises écrivent au moins partiellement des systèmes de bases de données personnalisés pour cette partie, adaptés à leurs besoins spécifiques. .
Cette question est plutôt ancienne, mais mon idée de la manière de la gérer est aussi valable que celle posée aujourd'hui.
Si vous utilisez une base de données relationnelle, vous devez en réduire la charge, alors cette idée devrait vous aider.
Stockez toutes les informations publiques sur une base de données locale sur chaque système client ainsi que dans la base de données des serveurs.
Stocker toutes les tables avec des éléments sur la base de données client. Au lieu que le client regarde le serveur lorsque vous passez la souris sur cette arme pour obtenir des statistiques, il vérifie simplement les statistiques dans la base de données locale. Le serveur dispose de sa propre base de données pour extraire des statistiques lors du calcul et pour transmettre uniquement les dommages et la santé restants aux clients.
Le pire cas avec cette idée est que tout le monde peut voir les statistiques de toutes les armes s'il parvient à entrer dans la base de données des clients. peu importe la cause, même s’ils changent les valeurs, les valeurs de la base de données sur le serveur sont ce que le calcul fait dans le jeu.