+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Conception de votre bdd (méthodologie) (/showthread.php?tid=370)
RE: Conception de votre bdd (méthodologie) - Helifyl - 12-11-2006
Pour mon jeu j'ai besoin d'un système de diplomatie, à savoir tel joueur fait partie de telle alliance, qui est elle même l'alliée de telle autre alliance, ennemie d'une troisième alliance.
Ce système est le centre de mon jeu, j'en ai besoin pour l'affichage de la carte, pour les calculs des combats, et même pour déterminer les actions envisageables par le joueur. Autant dire qu'il vaut mieux que ce soit nickel au niveau de la bdd. Malheureusement ce n'est pas encore le cas...
Voilà où j'en suis:
![[Image: bddalliancenr1.png]](http://img485.imageshack.us/img485/7543/bddalliancenr1.png)
Pour l'association Appartenir pas de problème: une clé étrangère dans la table joueurs qui pointe vers alliances et c'est réglé. Non le problème c'est pour modéliser la partie de droite, et l'association Intéragir. C'est là que je bloque.
Par défaut toute alliance est neutre envers les autres (d'où le (0,n) ). Pour les joueurs isolés j'hésite aussi: les considérer comme neutre envers toute alliance ou les référencer dans la table alliances comme une alliance à eux tout seul ?
Des idées ?
RE: Conception de votre bdd (méthodologie) - gtsoul - 12-11-2006
la relation interagir est du type 1..n-1..n
donc tu dois créer une table interaction_alliance (id_alliance1, id_alliance2, etat_diplomatique), id_alliance1 et id_alliance2 font office de clé primaire composée, l'ordre ne change rien
pour les joueurs neutres, si on suit ton schéma, on voit qu'il n'y a pas de relations directe entre joueur et intéragir, donc le mieux est de choisir le cas par défaut :
si pas de relation intéragir entre deux entités, leur relation est neutre.
RE: Conception de votre bdd (méthodologie) - Helifyl - 12-11-2006
Ah ok donc il me faut bien trois tables. Ca m'ennuie un peu parce que ça va faire pas mal de requêtes tout ça.
Est-ce que c'est viable de récupérer au début (à la connexion par exemple) toutes les infos relatives aux états diplomatiques dans un tableau qu'on conserve par variables $_SESSION ? Ou vaut-il mieux refaire une requête à chaque fois ?
RE: Conception de votre bdd (méthodologie) - joshua - 12-11-2006
moins de requetes, c'est toujours préférable!
RE: Conception de votre bdd (méthodologie) - gtsoul - 13-11-2006
voici un test sur mon site que j'ai obtenu en isolant diverses classes :
_ inclusion de 30 classes : 0.005s
_ 100-150 requêtes sql : 0.005s (bourrin, moi ?)
_ instanciation de grosses classes de base (connection, joueur, personnage, carte) hors requetes sql : 0.002s
_ génération du contenu propre à la page : 0.005-0.01s
j'ai remarqué que les accès sql sont très rapides; d'autant que mysql peut gérer les accès simultanés (10 par défaut pour un poste développeur; 50 sur mon serveur). Une variable de session consomme moult mémoire et moult temps car elle demande une écriture sur le disque, son utilisation doit être réduite au minimum (quand je dis moult, faut pas s'affoler mais faut pas en abuser non plus).
RE: Conception de votre bdd (méthodologie) - Helifyl - 13-11-2006
@ gtsoul: Mon précédent hébergeur galèrait au bout de 20 requêtes (sur un forum). Mais bon je vais bien voir avec le nouveau.
Sinon j'y ai encore réfléchi et je pense que je vais opter pour le système suivant:
- une table joueurs qui contiendra les infos du joueur (nom, argent, etc) et une clé étrangère id_alliance qui pointe sur la table alliances. Cet clé pourra être nulle (si le joueur n'a pas d'alliance donc).
- une table alliances qui contiendra les infos de l'alliance (nom, effectif, chef de l'alliance, qui sera un pointeur vers id_joueur de la table joueurs).
- et enfin une table diplomatie qui aura une clé primaire composée de id_1 et id_2. Ces deux attributs seront des clés étrangères pointant SOIT vers id_joueur de la table joueurs SOIT vers id_alliance de la table alliances.
Donc si un joueur n'a pas d'alliance (id_alliance=0) il sera référencé dans la table diplomatie, sinon ce sera son alliance qui sera dans la table diplomatie.
Désolé pour l'absence de schéma, je ne suis pas chez moi là. Donc c'est pour savoir si cet organisation est correcte ou pas ??
RE: Conception de votre bdd (méthodologie) - gtsoul - 13-11-2006
le fait que tu fasses figurer les joueurs dans la diplomatie est correct mais va poser moults problèmes, qu'est-ce qui se passera par exemple, si un joueur déclare la guerre à une alliance A puis rejoint l'alliance B qui est amie avec A ? Tu risques d'avoir un double enregistrement.
Je dirais que ta vision est correcte mais risquée, tu dois définir précisement tes règles. Est-ce qu'il y aura effacement de la diplomatie privée lors de l'entrée dans une alliance. Si c'est le cas, est-ce qu'il est possible de créer artificiellement des alliances pour se refaire une virginité diplomatique.
Autre question, est-ce qu'un état diplomatique est subjectif et réversif ? si A est ami de B, B est-il forcement ami de A ?
Donc si veux conserver une diplomatie vis-à-vis des privés, je te conseille la structure suivante :
id_entite1 | type_entite1 | id_entite2 | type_entite2 | etat_diplomatique
les types sont une énumération : soit alliance soit privé
les id correspondent soit à l'id d'une alliance, soit à l'id d'un joueur.
Ta clé primaire est composée de deux clés (id_entite1 | type_entite1 et id_entite2 | type_entite2), donc en fait ta clé primaire est constituée des 4 première colonnes.
L'avantage de ce système est que chaque alliance peut considérer sa relation diplomatique par rapport à un individu précis ou par rapport à son alliance. L'un prédomine forcement sur l'autre; mais il y a un historique des rapports.
Voilà si tu pouvais préciser le comportement diplomatique à adopter en cas d'arrivée/départ d'une alliance.
RE: Conception de votre bdd (méthodologie) - Helifyl - 13-11-2006
Et bien en fait j'y ai pensé. Déjà un seul état est "réciproque": si A déclare la guerre à B, B passe automatiquement en statut "ennemi de A".
Par contre pour un cessez-le-feu (retour à l'état neutre après une guerre) ou pour une alliance entre deux partis ce n'est pas automatique: si A propose une alliance à B, B doit d'abord accepter, auquel cas on modifie le statut des deux partis.
Ce qui m'amène à penser qu'une autre table est nécessaire, afin de stocker les propositions en cours. Elle sera de la forme (id_proposition, #id_parti_1, #id_parti_2, proposition). A la connexion "parti_1" recevra la proposition et pourra choisir. On efface alors l'entrée dans la table proposition et on met éventuellement à jour la table diplomatie suivant sa décision.
Pour l'entrée des "privés" dans les "alliances" il est clair qu'on ne peut pas se contenter de supprimer l'ardoise du privé. Ce que je pensais faire est que lorsqu'un privé rentre dans une alliance, ses références dans la table diplomatie disparaissent MAIS ses anciens alliés sont perdus et ses anciens ennemis reçoivent un message leur signalant l'entrée du privé X dans l'alliance A, et leur permettant de basculer l'alliance A en ennemi (si ce n'était pas déjà le cas). Pareil pour un privé Z qui quitterait une alliance B: les ennemis de l'alliance B choisissent alors s'ils veulent traiter Z en ennemi ou pas. Ces choix se feraient toujours par l'intermédiaire de la table proposition, à qui il faudra rajouter quelques attributs.
Après il faut encore que je réfléchisse à fond et que je teste pour voir si tout ça ne créé pas des aberrations ou ne permet pas des exploitations de bugs par les joueurs...
Pour ton système Gtsoul je ne sais pas si ça marcherait car ça permettrait à une alliance B d'attaquer le joueur X de l'alliance A sans pour autant être inquiétée par les autres membres de l'alliance A, si cette dernière n'est pas déclarée en guerre avec B. Non ?
RE: Conception de votre bdd (méthodologie) - gtsoul - 13-11-2006
ce point dépendra totalement de tes règles métiers. ta bdd ne fera qu'enregistrer la relation de l'individu et de son alliance vis a vis de B.
Ensuite, grâce à ta classe métier, tu consideras que l'un prime sur l'autre.
pour le coup des propositions/acceptations, il est clair que c'est encore une autre relation 1..n 1..n, donc une troisième table de jointure, tu peux aussi classer comme info la proposition de paix sous forme de text, et un time de la déclaration; c'est bien pour le rp.
RE: Conception de votre bdd (méthodologie) - Seren - 06-02-2007
Salut,
J'ai lu avec un grand intérêt ta présentation de la méthode merise, et je me rends compte que c'est exactement ce dont j'avais besoin. Intuitivement, j'avais déduit quelques règles, mais dès que je veux réfléchir sur l'ensemble de mon projet je me perds dans les détails.
Il faut vraiment que je fasse un schéma merise de toutes les intéractions possible avant de commencer à coder...
Est-ce que par hasard tu connais un bon outil open source simple* qui permet de faire la modélisation et de générer le source SQL associé ?
* simple dans le sens ou c'est assez facile à prendre en main même si c'est au détriment de quelques fonctions avancées.
EDIT : J'ai trouvé AnalyseSI qui est en court de développement et qui semble bien correspondre à mes besoins.