Stockage d'une maps dans la BDD

[Nonovitch]

Bonjour,

Je suis en train de me poser une question concernant la façon de faire une maps pour mon jeu par navigateur, sachant qu'il doit y avoir plusieurs maps différentes (1 maps/ 8 joueurs)



Elle doit avoir un nombre de cases pré-définies (je n'ai pas encore décidé de la grandeur mais minimum 30x30)
Le joueur peut se déplacer sur toutes les cases et sur chaque case il peut trouver plusieurs objets, et en réalisant une action particulière (fouiller) il peut trouver d'autres objets plus rares. Des nouveaux objets peuvent être régénérés sur la maps chaque jour

Ma question se pose au niveau du stockage de la maps dans la base de données, sous quelle forme le faire?
Je pensais à une table:

• maps1
  

1. int x // Coordonnées de la case en x
   
2. int y // Coordonnées de la case en y
   
3. ??? objets // Liste d'objets qui sont sur la case
   
4. ??? objets_fouille // Liste d'objets qui sont sur la case et qui sont trouvés uniquement en réalisant l'action "fouiller"
   

• maps2
  [..]
  

L'autre question qui se pose à moi est aussi le stockage des objets dans une case: un varchar avec des id d'objets séparés par virgule par exemple: 1,17,24,6 ?
Y a t-il une autre façon de procéder?

Merci

[Xenos]

Salut,

int x ; int y me semble être une bonne approche si tu ne gardes que des cartes "tableau" (à cases carrées). Si, à l'avenir, les cartes deviennent exotiques, alors tu auras tout le temps de basculer vers l'extension MySQL Geometry ( https://toile.reinom.com/les-astuces-et-...n_Geometry ) ou l'équivalent sur ton SGBD. N'oublies pas d'indexer les deux colonnes dans une clef UNIQUE ( https://toile.reinom.com/les-astuces-et-...s_colonnes )

Pour les objets, il te suffit de les stocker dans une seconde table "objets", sous la forme (int id AUTO_INCREMENT, id_case; type_objet, description, etc) et d'ajouter une colonne "int id" à ta table de cases et une clef étrangère faisant référence entre id_case de la table objet et id de la table cartes te suffira à faire le liant. C'est une relation 1-N classique. Idem pour la fouille (là, soit tu fais une autre table objet_fouille s'il y a des méta données en plus, soit t'ajoutes juste une colonne TINYINT(1) à la table "objets" indiquant si l'objet est disponible en fouillant ou directement.

Ne sérialise pas avec des virgules. C'est une anti-solution de chiasse ( https://toile.reinom.com/la-serialisatio...gbd-mysql/ ). Dans ton cas, c'est une simple relation 1-N qu'il faut faire. Pour rappel:
• Relation 1-1: 1 entité est rattaché à 1 seule autre, cela se modélise facilement en créant 1 seule table pour les deux entités (ie: 1 compte d'un joueur n'a qu'un seul email, donc l'email est stocké dans la table des comptes)
• Relation 1-N: 1 entité (table A) est rattachée à 0, 1 ou N entités (table B), cela se modélise facilement en donnant un ID à cette entité et en y faisant référence dans les N autres entités (la table B a une colonne "ID_tableA")
• Relation N-N: N entités (table A) sont rattachées à N autres entités (table B) [en gros, la situation est "c'est le bordel"], cela se modélise en donnant un ID à toutes les entités (une colonne ID dans la table A et une autre dans la table B) et en créant une troisième table de relation (table R) qui indique quel ID de A est rattaché à quel ID de B

Tu trouveras plus d'infos sur le net sur les relations 1-1/1-N/N-N en SQL.

[Nonovitch]

Merci pour ta réponse

Je vois le principe du 1-N j'ai étudié ça avec les BDD, cependant j'ai regardé ta solution et à moins d'avoir oublié une partie je tombe sur ça:


En jaune ce sont les objets qui vont être sur la case d'id 0, et en bleu clair sur la case d'id 1 (via clef étrangère).
Mais ça implique une grosse redondance non? Pour le coup de l'or, si je veux qu'elle soit sur 2 cases, il faut 2 objets or différents, ou alors j'ai mal compris?

[Xenos]

Non, t'as bel et bien tout compris.

Il n'y a pas de redondance dans le modèle de carte: ta redondance vient d'un cran plus loin, dans le modèle d'objet. Ici, ton "objet" est en fait une "instance" d'un type d'objet donné. Bon, histoire de ne pas mixer le vocabulaire OO avec celui de la conception, je vais le formuler un peu différemment: il te faut une nouvelle table, "objet_type", qui listera le nom et la description de chaque type de "truc" se trouvant sur les cases. Ensuite, chaque ligne de "objet1" fera référence à l'ID d'un de ces types d'objets, en ajoutant éventuellement une quantité si nécessaire.

De cette manière, tu auras des types de ressources qui seront centralisés, et des cases dans une table "map". Une sorte de table N-N (objet) fera alors le lien pour dire "sur telle case de la carte se trouve telle quantité de tel type de ressource, et il [ne] faut [pas] fouiller la case pour le trouver".

[Nonovitch]

D'accord donc je crois que je confondais la table "objet1" avec la table que tu dis "objet_type".
"objet_type" recense les dizaines d'objets du jeu et les lignes de la table "objet1" contiennent uniquement l'id de la case, l'id de l'objet de la table objet_type, ainsi que sa quantité.
Maintenant que tu me dis ça je trouve ça tout à fait logique.
Je teste ça dès que j'arrive à la gestion des objets merci de ton aide

[Xenos]

C'est ça. De rien

Le modèle de BDD est hyper-important, c'est ce qui va constituer bien... la moitié du jeu (voire les 3/4 si, comme moi, tu délègue finalement tous les traitements de données au SGBD et aux procédures stockées). Donc ça vaut le coup de s'attarder dessus