Modélisation d'une map par joueur

[popayan]

Bonjour,

J'aurais besoin de l'avis des personnes aguerries pour une question de modélisation de données.

Quelle serait la meilleur façon de stocker les informations d'une carte pour un joueur?
Sachant que dans mon idée générale, le joueur ne connait rien au départ et apprend en fonction de ses déplacements, il y aura pas mal de joueur donc beaucoup de données dupliqués et il faut que ca soit modifiable facilement.

Si quelqu'un a un avis, une idées, c'est le moment!

PS: je laisse le sujet un peu vague car pour le moment peu de chose sont en place de mon coté.

[Kihmé]

tu pourrais découper ta carte en plein de petits morceaux, chaque morceau à une relation avec ton joueur caractérisée par un boolean qui passe de false à true. Ou bien tu relis un morceau à un joueur uniquement si il l'a découvert.

[popayan]

Ah oui, la carte sera (grosse probabilité) découpé en case hexagonale (type jeu de plateau en fait)

[NicoMSEvent]

pour moi, chaque case a un identifiant (ID) (table terrain), j'ai une table a coté avec mes joueurs (table joueurs) avec un identifiant aussi, et j'ai une table annexe avec les cases découvertes par mes joueurs, et elle a la structure suivate : id_joueur, id_case . J'ai donc une ligne par case et par joueur. Comme je n'ai que deux identifiants, cette table ne sera pas trop grosse

(j'ai aussi des cases hexagonales, mais ça n'entre pas en compte ici, ça sera pareil pour toutes les formes de cases)

[Argorate]

Salut, voilà les solutions qui me viennent a l'esprit :

comme NicoMSEvent, faire une table. Par contre une id_case donne quel avantage? Bref j'aurais dit: id_joueur, x, y, mais ça revient au même ^^

Sinon y a la solution du binaire (la plus économe? pas sur...). tu mets un champs texte dans une table et un enregistrement par joueur: avec des 1 et des 0 à la chaine (0 voulant dire inconnu et 1 connu, tu peux mettre d'autres chiffres si tu veux associer plus dinformations aux cases...).

Et dernière solution que je vois: créer une image par joueur, où chaque pixel représente une case (et du coup si tu as tel couleur de pixel cela veux dire tel truc etc)

[NicoMSEvent]

j'avais pensé a la manip d'image, mais le problème est que c'est assez lourd point de vue calcul. Ma carte fait (a peu près) 2000*1000 cases, une image de cette taille met au moins 10 sec a etre chargée (sans compter les modifs a faire dedans). Donc, pour mon cas précis, ce n'était pas une solution envisageable.

l'avantage de deux identifiants plutot que id_joueur,x,y est qu'il y a un champ de moins, étant donné le nombre important d'enregistrement, ça chiffre vite! (surtout que je suis limité a 25Mo pour la DB)

Sinon y a la solution du binaire (la plus économe? pas sur...). tu mets un champs texte dans une table et un enregistrement par joueur: avec des 1 et des 0 à la chaine (0 voulant dire inconnu et 1 connu, tu peux mettre d'autres chiffres si tu veux associer plus dinformations aux cases...).

pourquoi un champ texte? tu manipuler rapidement un bit d'un nombre contenu dans $var grâce a ceci (les nombres prennent 4 octets pour 32 bits)

if( $var&(1<<3) ) pour tester le 3eme bit de la variable

$var|=(1<<3) pour mettre le 3eme bit à 1

$var&=~(1<<3) pour mettre le 3eme bit à 0

[keke]

J'ai aussi un table carte mais avec 4 dimensions : (id_carte, x, y, altitude). L'id_carte prend une valeur différente selon que l'on est sur la carte générale, les cartes des donjons, des villes, des maisons, etc.

Selon comment tu images les choses, je pense qu'il n'y a au moins 2 choix :
- Soit tu indexes ta table carte pour avoir un id_unique (dans mon cas on pourrait imaginer l'id (id_carte & '_' & x & '_' & y '_' & altitude : exemple d'id : 2001_30_-50_1230 ). A partir de cet id, tu l'associes à un joueur dans une nouvelle table : connaissance_carte (id_unique_carte, id_joueur)
- Soit tu subdivises ton monde en zone (des carrés de 15 cases * 15 cases par exemple). Lorsqu'un joueur franchi une zone, il a la connaissance de toute la zone. Dans ce cas, tu créé une table connaissance_carte (id_zone, id_joueur).
En procèdent ainsi, tu limites la taille de la table connaissance carte si cela t'effraie.

D'autres alternatives son imaginable ... genre si tu possèdes plus de 90 % de la connaissance d'une carte tu peux accorder une connaissance global du niveau.

Sinon concernant la taille, il faut, pour te donner une idée, que je te parle de ma table log qui contient le listing de tous les déplacement de mes joueurs ... c'est encore plus lourd qu'une table connaissance_carte car elle contient en prime l'heure du déplacement. De plus, si je repasse sur une même case ca fait 2 enregistrement log bien distinct ...

Ces pourquoi mes tables logs font 70 Mo ... pour 90 Mo de bases de données. (ma table la plus grosse après les logs étant la table Objet). Je purge régulièrement les informations vieilles de plus de 1 mois dans mes tables logs.

Kéké

[Anthor]

25 Mo, c'est dur, tu vas très vite la remplir.

[NicoMSEvent]

juste ma carte fait déja 20mo ^^

quand je passerai en version finale, je me prendrai une DB supplémentaire de 100 ou 250 mo

[Anthor]

juste ma carte fait déja 20mo ^^

quand je passerai en version finale, je me prendrai une DB supplémentaire de 100 ou 250 mo

Je me doute bien, moi-même pour 6 mois de logs d'actions, j'en ai déjà pour 40mo !