Configuration Plugin Quel système de Data choisir ?

[DarkFurie96]

Bonjour,

Je veux me lancer dans un projet assez gros et je n'arrive pas trop à savoir qu'est ce qui serait le plus optimisé pour stocker toutes les données de mes joueurs et du gameplay !

Le serveur serait un MMORPG, pour cela il faut que je retienne beaucoup d'information pour chaque joueur ! Mais aussi pour le gameplay lui même.

Pour les informations des joueurs, je pensais d'abord stocker tout cela dans une Base de donnée type MySQL pour pouvoir les récupérer sur le site aussi. Mais dans ces données il y aura par exemple les joueurs qu'il a ajouter en ami, sa guilde, les membres de celle-ci, ... Mais aussi des données qu'il faut plus souvent actualiser je pense, comme le nombre de mort du joueur, le nombre de mob tué, le nombre de block parcouru, ...

Et aussi les informations sur son personnage: l'xp, le niveau, les quests qu'il a déjà accompli, son agilité, endurance, force, ... Toutes des informations qu'on a besoin souvent en jeu !

Niveau Gameplay il y a toutes les informations des Donjons, mais ça je pensais le stocker en Json ou un truc du genre.

Donnez moi votre avis sur le système de données de que je devrais utilisé pour optimiser tout cela ! (Json, MySQL, d'autres ?)

Merci d'avance pour votre aide !

 

[DiscowZombie]

Salut,

enfin un sujet qui n'est pas du support dans cette catégorie, yeahhh.

Bref, passons au sujet !
La solution de stockage la plus adapté pour toutes les données de type "joueur" est sûrement une base de données, jusqu'à là, je ne t'apprends sûrement pas grand-chose. Les principaux avantages d'une base de données étant qu'elle est ordonnée et plutôt facile d'accès (serveur mais aussi site comme tu le soulèves). Le problème de performances, que tu soulignes avec inquiétude, a trouver solution plutôt simplement. Le but étant de mettre en place un cache dans l'application (l'application étant ton plugin d'API ici). Ainsi, les requêtes de lecture passent uniquement par le cache et l'écriture passe d'abord dans le cache avant d'être réellement répliqué dans ta base de donnée. Pour l'écriture dans ta base de données, tu as plusieurs choix :

• tu peux répercuter directement l'écriture à ta base de données de façon asynchrone
• faire un système qui fusionne les éventuellement multiples changements en un seul et fait des requêtes toutes les X minutes...

Voici deux possibilités pour l'écriture dans ta base de données, évidemment il en existe d'autre en fonction de comment tu conçoit le serveur (en interne).

Mais aussi des données qu'il faut plus souvent actualiser je pense, comme le nombre de mort du joueur, le nombre de mob tué, le nombre de block parcouru, ...

Pour les données qui sont plus volatiles comme celle-là, tu as encore plusieurs choix. Soit tu décides de les stocker avec le reste (méthode décrite plus haut avec mise en cache) soit tu souhaites les répliquer immédiatement dans une base de données, disons que tu as besoin qu'elles soient constamment à jour, même hors du serveur (site par exemple), et, dans ce cas, je te conseille de regarder du côté des bases de données dites No-sql. Ces bases de données, contrairement à leurs homologues, fonctionnement sans la partie relationnelle, simplement avec un système clé-valeur. Le gros avantage de ces bases de données, est leur temps d'écriture ridicule par rapport à celui d'une base de données relationnelle. Pour avoir fait le test, avec Redis (BDD non relationnelle) on est sur du ~25ms alors qu'on arrive facilement à plus de ~150ms pour des BDD relationnelles.

Niveau Gameplay il y a toutes les informations des Donjons, mais ça je pensais le stocker en Json ou un truc du genre.

Yep, ici le Json me semble un choix cohérent. Les données ne seront pas amenées à bouger, tu as simplement à les charger au démarrage et éventuellement répliquer les changements à la fermeture donc le Json fera très bien le boulot. Pendant que ton application tourne, pas de lecture sur disque, les données étant des Objects dans la mémoire de l'application.


PS: Je te conseille de laisser Mysql de côté, c'est un SGBD qui commence à se faire assez vieux. Si tu veux rester dans de la syntaxe Mysql, tu as MariaDB, bien plus à jour et tu gagneras en performances ! Et si tu veux un SGBD plus lourd, il y a l'excellent PostgreSQL même si là les requêtes vont différer de celles Mysql.

 

[DarkFurie96]

Merci beaucoup pour tout ces bon conseil DiscowZombie !
Je vais donc passer sur du PostegreSQL l'ayant vu en cours, je connais ! Par contre, MySQL avait un chouette interface comme Phpmyadmin, est-il possible de faire la même chose avec PostegreSQL ? Un truc en ligne accessible à tout les développeur ? Comment je peux gérer ma base de donnée facilement ?

 

[Alex Fatta]

Bonjour !

https://stackoverflow.com/questions/5725216/postgresql-visual-interface-similar-to-phpmyadmin

AlexFatta

 

[DiscowZombie]

Re,

et pour modéliser ta base de données (l'équivalent de MySQLWorkbench), tu as pgModeler.

N’hésite pas si tu as encore des questions.

 

[DarkFurie96]

Re,

et pour modéliser ta base de données (l'équivalent de MySQLWorkbench), tu as pgModeler.

N’hésite pas si tu as encore des questions.

Pour modéliser ma DB j'utilise un site d'habitude, lucidchart.com qui est hyper simple mais qui ne permet de pas de faire énormément de chose comme les Triggers ou autre.

Je me demandais, j'aurais aussi un système de métier et chaque joueur pourra en avoir entre 2 et 5 ! Et pour chacun je veux stocker le niveau du joueur dans ce métier, le nombre de ressource ramasser, ... Et du coup je ne sais pas ce qu'il vaut mieux faire, Base de donnée ou JSon ? Je ne sais pas non plus si je voudrais pouvoir réutiliser ces infos sur le site ou autre.

 

[DiscowZombie]

Salut,

Je me demandais, j'aurais aussi un système de métier et chaque joueur pourra en avoir entre 2 et 5 ! Et pour chacun je veux stocker le niveau du joueur dans ce métier, le nombre de ressource ramasser, ... Et du coup je ne sais pas ce qu'il vaut mieux faire, Base de donnée ou JSon

j'ai eu l'occasion de développer quelque chose de similaire donc j'ai bien une idée. Pour moi, c'est une donnée qui mérite amplement sa place en BDD, ce n'est pas spécialement volatil et le stocker à part (Json) me semble assez inutile : ça casse un peu le stockage Sql. Au niveau de l'organisation, il te faut une simple relation Many-to-Many en Sql.