Comment stocker une carte?

[Sephi-Chan]

Ouaip Séphi, mais ca marche que pour une petite carte.
Dès que tu as une grande carte ca devient plus lent qu'une base de données

Le principe, c'est de découper ta carte en plusieurs petites cartes (c'est l'intérêt de l'attribut id du nœud racine). Ainsi tu associes performances et légèreté en chargeant uniquement la carte où est le joueur et celles adjacentes si nécessaire.


Sephi-Chan

[keke]

Coucou,

Moi j'ai 2 type de carte :
- La carte générale (où les gens se déplace souvent, sur laquelle on gère l'altitude, etc...)
- la carte donjon (ben des donjons, une sorte de zoom de la case.)

La carte générale fait du 256*256. Les cases sont dans la table carte (pos_x, pos_y, altitude, id_ville_dominante, taux_humidite, etc.)
La clé primaire est sur le couplet des positions X et Y.
L'affichage de la case ne dépent pour l'instant que de l'altitude.

La carte donjon fait au plus 8000*8000 (habituellement 50*50). Les case sont dans la table map (x,y, id_donjon, id_type_terrain).
L'id_type_terrain fait référence à une table de terrain qui indique si le terrain est franchissable et l'image associée.
l'id_donjon fait référence à la table liste_donjon qui donne des infos sur le donjon (dont la taille d'une case, utilisé pour calculer le coùt de déplacement.
La clé primaire est sur le triplet des positions X, Y et id_donjon.
Dans les donjons la liste de type de terrain sont en Variable de Session (donc copiée qu'une fois)

Le fait de bien choisir la clé primaire permet en outre d'avoir l'unicité de terrain sur un point géographique donné, mais aussi accélère les calculs de type BETWEEN.

Mon choix de conserver les données en BDD au lieu du XML vient du fait que les joueurs peuvent être amené à modifier la carte. Dans le cas du XML, la simplicité veut qu'on supprime le fichier XML pour en recréer un modifié, ce qui peut être catastrophique si : la fonction ne marche correctement (perte du fichier complet si le cas d'erreur n'est pas traité); un joueur se déplace au moment où la carte se recréé; si la carte est très grande, le fichier à parser sera immense. Tout ces lacunes technique n'existent pas dans le cas de la BDD -> moins de boulot, plus d'efficacité ^^.
Maintenant Séphi, tu dois aussi avoir tes avantages, surtout sur de toutes petites cartes (< 80 cases de côté.)

Kéké qui parle beaucoup de parsing XML ... étrange.

[Sephi-Chan]

Dans mon cas, je ne peux pas garantir l'efficacité sur les grands fichiers, puisque dans mon cas, il s'agissait de carte comme Advance Wars (pour l'exemple, je l'ai utilisé ici pour l'éditeur de carte), dont le format tournait autour de 100*100.

Bon, j'ai complètement abandonné ce projet, mais je pense qu'on y gagnait réellement à utiliser XML puisque les cartes étaient effectivement assez petites et qu'avec DOM ou même SimpleXML, c'est très rapide, puisque ce sont des modules intégrés dans le noyau de PHP5.

Cela dit, je pense quand même que la base de données sera plus rapide sur de gros volumes.


Sephi-Chan

[keke]

Bha si tu y gagnais ^^ t'aurais eu tord de t'en priver ^^.
Le choix technologique repose donc exclusivement sur l'objectif final.

Kéké.

[Loetheri]

J'avoue que la question n'est pas des plus claires pour moi.
Tu souhaites pouvoir stocker une carte ou des informations sur les cases de la carte ?
Pour la carte en elle-même, il y avait eu une discussion sur TdJ où zumba (de "The Continent") a expliqué sa manière de faire avec des fichiers binaires et donc ... un outil très personnel.
Personnellement, je préfère utiliser une image combiné à une base de donnée pour gérer quelle carte choisir et pour gérer les données sur les cases.
La solution XML me semble relativement lourde, même si Sephi me prétendra le contraire ;-) La solution "simple fichier" est relativement archaïque et peu intéressante. La solution tout SQL est intéressante aussi ^ ^

[Sephi-Chan]

La solution XML me semble relativement lourde, même si Sephi me prétendra le contraire ;-)

Tu lis en moi comme dans un livre ouvert ! :o

Pour moi, l'utilisation de fichiers bruts est un peu bancale, mais pourquoi pas.


Sephi-Chan, qui aime beaucoup XML…

[phenix]

La solution XML me semble relativement lourde, même si Sephi me prétendra le contraire ;-) La solution "simple fichier" est relativement archaïque et peu intéressante. La solution tout SQL est intéressante aussi ^ ^

Que ce soit un simple fichier, un fichier XML ou une base de donnée, c'est toujours stocker dans un fichier. Seul la manière d'accéder au donnée change.

L'essentiel semble ce trouver dans la vitesse, plus le système sera rapide, mieux de sera.

Dans le cas d'un fichier XML, il semble que les limites soit la taille de la map, plus elle sera grande, moins ce sera efficace.

Dans le cas d'une base de donnée, la difficulté ce trouve sans doute dans la manière de stocker les cases et de séparé les maps. Je me suis pas trop intéresser a cette solution, je voulais absolument un système simple. Par contre, la base de donnée est peut être plus souple à l'utilisation.

La "solution archaïque" que j'ai choisi a pour principal atout la simplicité, on ouvre le fichier, on lit, on explode. Tu te retrouve avec un tableau qu'il suffit de parcourir pour retrouver les éléments de ta map.

Son principal défaut ce situe dans la fonction qui associe les éléments au image et qui installe les éléments dynamique sur la carte (joueur, montre, objet...). Le fait de ne pas avoir de position X/Y est aussi ennuyeux même si on peut les retrouver mathématiquement.

[edit]

Pour moi, l'utilisation de fichiers bruts est un peu bancale, mais pourquoi pas.

Heu ? Bha pourquoi ? Simplement parce que sa fait pas "pro" ou bien pour autre chose ?

[joshua]

le soucis dans ce cas je pense c'est la mise à jour.....
Parce que comme tu as tout en une ligne, tu veux changer un etrrain tu as des risques de collision et de perdre ta map... ENfin je pense.
Une base de donnée te gere les accès concurrentiels.
Quitte a utiliser un fichier a plat, je prendrais du sqlite...
Je voulais savoir pour toutes les cases de terrain ^^ pour le reste, je vais utiliser une base, c'est sur.

[Loetheri]

Oui, phenix, XML, Base de données ou fichiers brutes utilisent de simples fichiers.
Seulement, je me dis que le système de base de données doit être plus performant sur le long terme. Pourquoi ? Parce que le système, même s'il a un certain cout plus grand lors de l'accès à la base de donnée, est largement plus optimisé que le système que tu produiras tout seul. Maintenant, c'est mon avis strictement personnel et cela ne tient qu'à moi.

Quelque soit le système, joshua, il est possible de bloquer l'accès au système et de mettre une file d'opération. Cela peut être plus ou moins simple à mettre en place (surtout pour la file d'opération).

Cela dit, même si je n'y crois pas, tu peux aller voir dans le futur remplaçant (pour certaines applications, hein ;-) ) du XML, JSON. Même si à mes yeux, on tournera en général au niveau de solutions déjà énoncés. Mais je peux me tromper.

[Studio Gamboo]

Je me permet de mettre mon grain de sel dans la discussion en précisant que le JSON est surtout préconisé pour son utilisation avec javascript
Pour ce qui est des map, si elle sont de grandes tailles je pense qu'il n'y à aucun intérêt de les stocker sous forme de fichier.
Il est beaucoup plus simple/rapide de faire des sélections avec mysql