Je travaille sur un jeu multijoueur en temps réel qui nécessitera une base de données (pour des fonctionnalités telles que les profils des joueurs, les amis, les déverrouillages, les actualités, etc.) Il s'agit d'un jeu PC standard (non basé sur un navigateur) et utilisera un client-serveur architecture. Je suis novice dans l'utilisation des bases de données et j'ai fait des recherches au cours des derniers jours lorsque je suis tombé sur un débat houleux: RDBMS vs NoSQL. Actuellement, je penche pour NoSQL, mais après avoir lu les utilisations de chacun (RDBMS et NoSQL), je suis tenté d'utiliser les deux. Je sais que cela peut sembler étrange, mais permettez-moi d'expliquer ma situation:
Mon équipe a un package d'hébergement Web partagé qui offre un stockage et une bande passante mySQL illimités, la seule mise en garde étant que nous ne pouvons avoir que 25 connexions ouvertes en même temps (règle d'hébergement partagé). J'ai l'intention de l'utiliser pour mon site Web (une utilisation typique sans aucun doute) afin de publier des mises à jour de nouvelles, de prendre en charge les fonctionnalités de la communauté (comme les commentaires, le téléchargement de fan art, etc.) et autres. C'est très bien et bon - mais! c'est là que les choses deviennent intéressantes ... Je veux afficher ces mêmes informations qui sont affichées sur mon site Web, dans le jeu. Cela signifie utiliser mySQL pour mon site Web et mon jeu. En plus des articles de presse et autres, je prévois de l'utiliser dans le jeu pour des choses comme le chat et une liste de serveurs. Je m'inquiète principalement de cette règle des 25 connexions.
Ce qui m'amène à poser la question n ° 1: cela fonctionnera-t-il et existe-t-il une meilleure alternative?
Maintenant, en plus de cela, j'ai lu à quel point NoSQL fonctionne bien et convient aux jeux en temps réel (je peux me tromper, j'ai traversé une énorme guerre de flammes RDBMS vs NoSQL pour arriver ici et je suis probablement brûlé). Fondamentalement, je voudrais utiliser MongoDB pour toutes mes données d'objet de jeu.
Et encore une fois, il sera utile de fournir un certain contexte: j'ai trouvé un hôte (MongoLab) qui propose gratuitement un paquet MongoDB de 240 Mo, que j'ai l'intention d'utiliser jusqu'à ce qu'il soit nécessaire de mettre à niveau. Compte tenu de 240 Mo, j'ai calculé que je serais en mesure de stocker environ 60 000 joueurs (si chaque joueur fait environ 4 Ko et que nous ignorons les autres éléments qui pourraient être stockés). L'espace de stockage, et devoir payer plus cher à l'avenir (si notre jeu réussit) n'est pas un problème. La seule raison pour laquelle j'ai actuellement l'intention d'utiliser MongoDB pour toutes mes données d'objet de jeu est la fréquence à laquelle ces données d'objet de jeu seront consultées (par exemple, lorsqu'un joueur est tué, ramasse un objet, tire une arme à feu, etc.) I comme les documents simples sans schéma (qui facilitent la cartographie des données d'objets de jeu). Je dois noter qu'à un moment donné,
J'ai l'intention d'utiliser le même MongoDB dans mon site Web, pour afficher les informations de profil du joueur (je ne suis pas concerné par la cohérence complète, un certain retard par rapport aux mises à jour en jeu est très bien). Ce qui m'amène à ma deuxième question, question n ° 2: est-ce une bonne idée ou y a-t-il quelque chose de mieux que je devrais faire?
Le jeu aura une expérience de démarrage similaire à celle-ci:
- Le client se connecte (MongoDB)
- Le client se trouve sur la page d'accueil du jeu avec des salles de discussion (MySQL)
- Le client accède à la liste des serveurs (MySQL)
Le client se connecte à un serveur et y joue
Le serveur communique les mises à jour pour tous les joueurs (MongoDB)
C'est juste la façon dont j'imaginais que cela fonctionnerait. Cela vous semble-t-il bien ou avez-vous des suggestions sur la façon dont ce plan peut être amélioré?
Réponses:
Ma suggestion est de faire communiquer votre jeu à un service Web que vous avez créé et qui lui-même traite de l'interrogation de la base de données. À ce stade, il est très simple d'essayer différents types de bases de données en "commutant" les implémentations de services Web (votre interface de service Web reste toujours la même afin que votre jeu ne se casse pas) et de décider laquelle vous convient.
Il est également beaucoup plus sûr de ne pas exposer directement votre base de données à Internet.
la source
C'est plus que suffisant pour votre jeu. Le problème est que si votre site Web utilise plusieurs connexions, vous risquez de manquer. Vous devez configurer votre serveur Web pour n'en utiliser qu'un petit nombre, laissant le reste à votre serveur de jeu. Votre serveur de jeu n'a pas vraiment besoin de plus d'une connexion, mais il pourrait être avantageux d'en avoir une poignée.
C'est un peu un faux argument, car aucun des systèmes n'est assez rapide pour être utilisé comme magasin principal pour un jeu en temps réel au rythme rapide - vous devez vraiment conserver et manipuler les valeurs en mémoire. Donc, vous ne frappez la base de données que lorsque vous en avez absolument besoin, ce qui pourrait juste être de sauvegarder le personnage entier de temps en temps (par exemple, une fois par minute), à quel point les différences de vitesse deviennent négligeables.
Ce qui est drôle, c'est que si vous ajustez MongoDB pour la vitesse maximale, vous pouvez à peu près arriver à un point où il serait assez rapide pour que vous puissiez effectuer des écritures synchrones à partir d'un jeu raisonnablement rapide, mais ce serait au prix d'intégrité des données car les écritures sont mises en mémoire tampon. Cela signifie que vous perdez ces données en cas de plantage, il n'y avait donc aucun intérêt à effectuer l'écriture, et c'est toujours plus lent que si vous veniez d'effectuer l'édition en mémoire et de l'enregistrer plus tard, de sorte que vous obtenez le pire des deux mondes .
Demandez-vous pourquoi vous devez écrire dans la base de données lorsqu'un joueur tire avec une arme à feu. Pourquoi cela ne peut-il pas être simplement géré en mémoire sur le serveur de jeu? Si votre jeu plante et redémarre plus tard, et que le joueur découvre qu'il a 3 balles de plus que prévu, est-ce un problème commercial critique?
C'est une bien meilleure raison de choisir une approche NOSQL que le problème de performances.
C'est bien et sensé. Plus tard, vous voudrez peut-être utiliser une instance distincte, afin que les lectures Web ne soient pas en concurrence avec les lectures et les écritures de jeu, mais ce problème est trivial à résoudre par rapport au problème de devenir suffisamment populaire pour que cela soit un problème.
Personnellement, je choisirais simplement l'une des deux bases de données, en fonction de celle qui serait moins de travail pour moi, et normaliserais cela - mais il n'y a aucune raison que vous ne puissiez pas en conserver deux si vous le souhaitez.
la source
Toutes les données en temps réel doivent être conservées dans la mémoire de l'application, tout le reste serait idiot.
Garder les données de connexion des utilisateurs, les statistiques, etc. est une tâche assez légère, donc je vais être audacieux et dire que vous pouvez utiliser à peu près tout ce que vous voulez. Bien que vous souhaitiez être prudent avec le site Web, des éléments tels que les listes d'utilisateurs pourraient augmenter considérablement les performances de la base de données si vous ne créez pas un système de mise en cache approprié.
Et comme l'a dit bummzack, vous devez tout garder dans le même réseau. En plus de cela, méfiez-vous des trucs gratuits, le stockage de base de données gratuit de 240 Mo semble bon, mais comme la machine est probablement partagée entre un grand nombre d'utilisateurs gratuits, le service peut être assez lent.
la source
Faites-vous confiance à vos 60 000 utilisateurs par base de données? Sinon, vous devez supprimer l'idée "accès à la base de données à partir du client", à moins que votre niveau d'expertise dans la sécurité du logiciel de base de données soit de premier ordre et que vous soyez confiant que vous pouvez prendre en charge tous les problèmes qui en découlent.
la source