+- 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 : Structure BDD Carte/Lieux/Batiments (/showthread.php?tid=3933)
Pages :
1
2
Structure BDD Carte/Lieux/Batiments - comg - 28-04-2009
Bonjour à tous !
Cela faisait longtemps que je n'étais pas passé par ici (pour ceux qui s'en souviennent j'avais à l'époque un projet de jeu sur une simulation de vie d'etudiant, que j'ai du malheureusement mettre entre parenthese, mais je ne lâche pas l'affaire
)J'ai depuis quelques semaines ressorti un vieux projet des placards, un RPG en ligne.
J'aurai besoin de votre aide pour la construction de ma "carte".
Voilà :
- Le monde est divisé en REGIONS
(Une ville est une REGION)
- Chaque région est divisée en LIEUX
(Un lieu peut être une foret pour une region exterieur, ou bien un magasin pour une ville)
- Le lien entre les REGIONS se fait via une table
id_region1 | id_region2
- Pour passer d'un lieu à l'autre DANS UNE MEME REGION il faut obligatoirement se trouver dans le lieu "exterieur" de la région (le lieu "par défaut"... ex : la rue pour une ville, l'exterieur pour une région)
Comment structuriez vous vos tables ? Car j'ai commencé à m'emmeler les pinceaux...
>>> Ma BDD <<<
Merci d'avance de votre avis avisé ^^
Bonne journée
.
PS : Si vous pouviez aussi me donner votre avis sur le fait de séparer les différents attributs des joueurs dans plusieurs tables (le caracteristique d'un coté, l'etat forme/vie d'un autre, les infos du compte dans un autre... ect)
RE: Structure BDD Carte/Lieux/Batiments - keke - 28-04-2009
Heu, c'est un peu charabiaique ton biniou.
Table REGION :
- id_region
- nom_region
Table LIEU :
- id_lieu
- id_region
- nom_lieu
- id_lieu_par_defaut
Et tu considères à la création de tes éléments lieux qu'il ne faut définir qu'un seul id_lieu_par_defaut pour chaque région.
Par contre, je trouve ton système assez bancal ou pas assez détaillé ^^. Ou moi qui me fait vieux ...
Une ville ne pourrait pas avoir 2 portes de sortie ?
Kéké
RE: Structure BDD Carte/Lieux/Batiments - comg - 28-04-2009
J'ai du mal m'exprimer.
Tu arrives en ville/dans une région, tu arrive dans la rue.
Depuis cette rue (qui est le "lieu par défaut") tu peux aller vers l'ensemble des lieux de la ville/région et c'est seulement depuis ce lieu par défaut que tu peux quitter la ville/changer de région.
Si je ne suis toujours pas clair je m'en excuse :/
Dans ton idée, le id_lieu_par_defaut ne devrait il pas etre dans la table REGION ?
Ensuite mon vrai problème n'est pas tant de définir le lieu par défaut, mais plutot pour qu'ensuite chaque lieu soit associé à batiment unique (le magasin Chez Dudu ou l'auberge Chez Keke)
RE: Structure BDD Carte/Lieux/Batiments - Allwise - 28-04-2009
S'il y a une seule rue / un seul extérieur dans ta région qui permette de rejoindre les lieux, tu n'as pas besoin d'une table intermédiaire pour lier les lieux aux régions.
En reprenant l'idée de Keke et en ajoutant une table rue ( que tu appelles comme tu veux ) :
Table REGION :
- id_region
- nom_region
Table Rue
- id_rue
- id_region
Table Lieu_Rue
- id_lieu
- id_rue
Table LIEU :
- id_lieu
- nom_lieu
Avec ce schéma, ton joueur peut se trouver dans un lieu ( table lieu ) ou dans une région. Mais s'il est dans une région, il se trouvera forcément dans une rue / un chemin ( table rue ). Et ces chemins mènent aux lieux grâce à la table lieu_rue.
Tu pourras toujours connaître la région d'un joueur, qu'il soit dans une rue, ou dans un lieu. Dans ce dernier cas, il te faudra y remonter avec une requête avec 2 jointures.
Je vois pas de raison particulière qui justifie de séparer les attributs d'un joueur en plusieurs tables, sauf si l'ensemble de ces attributs que tu regroupes dans des tables sont des entités à part entières. Par exemple, un lot de certaines caractéristiques pourraient être regroupées pour devenir un comportement, et être attribuées à plusieurs persos / monstres...
Plus il y a de tables, plus il y aura de jointures. Vu qu'il s'agit a priori de relations 1-1, il y aura autant d'enregistrements dans toutes les tables. Les fichiers seront juste un peu plus légers.
RE: Structure BDD Carte/Lieux/Batiments - comg - 28-04-2009
C'est vrai que l'idée de faire des rues une table à part entière ne m'avait pas effleuré l'esprit
Mais le truc c'est qu'un joueur NE DOIT PAS se retrouver dans un LIEU ET dans une RUE en même temps !
Mais l'idée est trés bonne (il me suffira de considérer que si le joueur n'est pas dans un LIEU alors il est dans la RUE correspondante...)
Merci pour cette idée qui me semble pas mal du tout !
(Même si elle allourdi un peu le truc... mais bon, avec un bon traitement cela devrait bien passer !)
![[Image: scheman.jpg]](http://img168.imageshack.us/img168/8613/scheman.jpg)
Vert : Regions
Rouge : Rues
Bleu : Lieux
RE: Structure BDD Carte/Lieux/Batiments - keke - 29-04-2009
Pour te rassurer, Magdales utilise :
une carte générale puis
une carte détaillée
les villes sont positionnés par une table
position sur l'une des 2 cartes.
Mes villes sont découpées en rue
chacune d'elle contenant des parcelles numérotés
Avec potentiellement un batiment de dessus.
Chaque ligne correspondant à une table dans mon jeu ^^. (respectivement, carte, map, ville, position, rue, parcelle, batiment)
Un joueur peut donc être : sur la carte (générale), ou sur une petite carte détaillée, dans une rue, sur une parcelle vide, ou dans un batiment. Pour reprendre ta manière d'expression, quand on rentre en ville, on arrive sur la rue "par défaut".
Il faut pas hésiter à bien réfléchir à son modèle et aux évolutions que tu souhaiterais apporter par la suite. Dans mon jeu, par exemple, j'avais à l'origine une relation ville -> batiment toute simple... puis la quantité de batiment se créant, il a fallut en urgence modifier une grande partie de mon code et tout retester... J'aurais pu m'éviter un sacré bout de travail si j'avais réfléchis à cette évolution, y'a 5 ans.
kéké
RE: Structure BDD Carte/Lieux/Batiments - Ruz - 29-04-2009
alors, Supra Online:
deux cartes: continents et lieux (les villes seront des lieux prochainement)
tables:
- continent
- data (données de base des lieux)
- routes (données complémentaires lieux)
- fleuves (données complémentaires lieux)
- ponts (données complémentaires lieux)
=> copie instanciée dans une table "lieux"
en plus de ca, j'ai des tables contenant les détails des décors, des monstres et des sols (le tout en cache fichier)
Bcp de relations, mais ca m'évite d'avoir des lieux qui sont sorti d'un moule à 4 modèles.
un joueur a une position continent (suivant la case continent, je sais quel lieu prendre) et des coordonnées XY (position dans les lieux)
RE: Structure BDD Carte/Lieux/Batiments - comg - 29-04-2009
C'est vrai que j'ai tendanceà vouloir tout mettre dans un minimum de table pour la carte, alors que c'est complétement idiot !
Je vais réfléchir dans ton sens je pense, c'est simple mais efficace.
Regions (id_region, nom)
Lieux (id_lieu, id_region)
Parcelles (id_parcelle, id_lieu)
Batiments (id_parcelle)
Merci.
Edit : Eih merci Ruz, j'avais pas vu ta réponse !
Keke : Comment tu connais la position de tes joueurs ? Pour chaquun tu stocke une valeur rendant à chaque table ?
RE: Structure BDD Carte/Lieux/Batiments - keke - 29-04-2009
Une base de donnée devrait contenir le strict et le nécessaire de tes données. Éviter les redondances, éviter d'avoir un manque d'information
(29-04-2009, 11:56 AM)comg a écrit : Keke : Comment tu connais la position de tes joueurs ? Pour chaquun tu stocke une valeur rendant à chaque table ?
Hou la bonne question ^^.
En fait pour ce point j'ai un peu improvisé. Et je t'encourage à faire mieux que moi ... c'est totalement faisable.
J'ai une table position contenant X et Y et un mystérieux id_lieu.
Puis un système de conversion étrange.
Code :
Ainsi, id_lieu = 0. Le X et Y représente les coordonnées sur la carte générale.
Si le id_lieu est négatif, le X et Y représente les coordonnées sur la carte détail dont l'id est égale à -id_lieu (qui devient donc une valeur positive).
Si le id_lieu est compris entre 0 et 1000, le joueur est dans une ville. Il se déplacera sur la rue "par défaut" en cas de besoin.
Si le id_lieu > 1000, le joueur est dans la parcelle dont l'id est (id_lieu - 1000). S'il y a un batiment a cet endroit, il rentre dedans. S'il n'y a pas de batiment à cet endroit, il est simplement sur la parcelle.Remarques :
- dans mon jeu, les X et Y ne sont utiles dans mon cas que pour les déplacements en dehors des villes.
- L'information "rue" est stockée en variable de session. Toutes les rues sont accessibles à tout moment du moment qu'on est en ville. Un hackage de l'id_rue est faisable, mais totalement inutile. A la connexion on apparait donc sur la rue "par défaut" (souvent la place du village), ce qui est dans mon jeu, totalement acceptable.
Ce système complexe est très moche. Je te décourage d'en faire un aussi laid ^^.
L'avantage que je trouve à ce système, c'est qu'il recouvre mes besoins en termes fonctionnels (j'aurais jamais plus de 1000 villes, j'ai la possibilité d'avoir une infinité de rue, de donjons, de lieux, de parcelles ...).
De plus, il me permet d'avoir un système sans possible collision. Malgré un plantage de base de donnée, un personnage ne peut être qu'à un endroit.
Dans ton système, tu peux gérer une table position en fonction de tous tes champs :
Table position : id_position, id_region, id_lieux, id_parcelle, id_batiment
Si l'un des id_lieux, id_parcelle, id_batiment est égale à 0, alors le joueur est dans le container au dessus;
id_region = 2, id_lieux = 80, id_parcelle = 12, id_batiment = 0
indiquera que ton joueur est dans la parcelle 12, dans le lieux 80 de la région 2.
Cependant ce système me dérange un peu dans la mesure où des cas (non-souhaité bien sur) peuvent avoir lieu.
Le système de créer un "type de positionnement" par table ... peut avoir son intérêt si tu comptes employer des coordonnées X et Y pour chacun de tes régions, lieux, parcelle, batiment. Sinon, je trouve le système plutôt lourd ...
Il y a surement un système miracle, mais je l'ai pas trouvé.
Pour le reste, dès que tu as choisis ton modèle de donnée, je t'encourage à faire très vite une couche abstraction de ton modèle de donnée. En POO, en fonction, ou n'importe, mais que tu aies à disposition des méthodes simples pour : rentrer dans la région, sortir de la région, rentrer dans lieux, sortir du lieux, rentrer dans parcelle, sortir de parcelle ... + des fonctions de cohérences + des fonctions d'agrégation de données (lister les joueurs d'une région par exemple ...) + fonctions de zones (liste des régions accessible par une autre + fonctions de calcul de chemin (pour aller d'un batiment à un autre, quel chemin ? le plus court ? le moins dangereux ? le plus empreinté ? le plus accessible sans compétence d'escalade, de natation ...) + d'autres fonctions propre à ton jeu...
En te souhaitant maintenant bon courage,
kéké
PS : la POO semble tout indiqué pour ce type de problèmatique, mais je suis pas le mieux placé pour parler de ça.
RE: Structure BDD Carte/Lieux/Batiments - comg - 29-04-2009
C'est vrai que le fait de ne pas pouvoir avoir de "double position" ou de "position impossible" est un sacré avantage, et que faire comme tu me le conseilles est risqué. Mais je vais y réfléchir et te remercie
Pour ce qui est de la couche d'abstraction :
Cela tombe bien que tu m'en parles car justement c'est un truc que je ne faisais pas avant et que je commence à faire.
Je suis sûr qu'il n'y a pas de solution miracle mais quelle est la meilleure démarche à suivre d'après vous ?
Qu'appelles tu "fonctions de cohérence" ?
Merci beaucoup en tout cas !