Comment stocker une carte?

[Sephi-Chan]

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 ?

Ah non, pas pour la question de faire pro, mais plutôt parce qu'il n'y a pas d'API, c'est au développeur de créer son interpréteur à coup d'explode successifs, etc. C'est pas pratique, quoi.


Sephi-Chan

[Zamentur]

Bon pour faire part de ce que j'ai pus essayer
Sur Ragol au départ on avait une map SQL avec les colonnes représentant les X et les lignes les Y.

Autant dire qu'on a finis par changer

On a alors fait une map SQL avec id,X,Y, + champs d'info

Et cette méthode me parait très satisfaisante pour une map par case.
Toutes les cases étaient modélisées pour des raisons de simplicité de code.
Faut dire qu'il y avais beaucoup d'info entre les objet sur la case, le type de terrain, les perso présent, les bâtiments, l'énergie attribué à la case, la colonie possédant de la case et d'autre...

La map sql permet aussi de faire des modifs très rapide (en SQL c'est pas le cas) Faut dire que la map changer tout le temps puisque même les joueurs pouvait la modifier (terraformation, construction/destruction de bâtiment, distribution de l'énergie des "centrales photonique",télééchange,téléportation ...)
Du coup la carte était modifié presque à chaque connexion, donc SQL s'était imposé.

Et puis j'avais réussis à faire un genre de paint pour permettre aux admin et animateur principal de modifier la carte

Donc pour une carte très dynamique je vois mal comment se passer d'une base de donnée.

Note la map faisait 40 000 enregistrements et avec les index sur X, Y çà passait impec.

C'est vrai que pour du multimap on peut se demander si il ne faut pas plusieurs tables, mais MySQL est censé gérer çà bien et j'ai déjà fait des test sur des tables de plus de 500 000 enregistrements, donc mon avis c'est que pour du 100*100 soit 10 000 une table avec une colonne çà devrait être bon

Enfin en ce moment je réfléchis à une autre manière que case par case inspiré des modèle d'image vectorielle. Je crois que c'est une solution mais elle est plus complexe à mettre en oeuvre

[NicoMSEvent]

j'ai une carte de 500*500 (donc, 250.000 enregistrements).
J'ai les tables suivantes
"monde" avec les champs id,x,y,type_case_id
"type_case" avec les champs id,titre (qui appraitra en résumé dans une info-bulle), description (qui appraitra autre part, qui sera plus complet), bonus_attaque, bonus_defense, bonus_secacher, bonus_trouveritem, ...
Quand je place mes perso, je ne modifier que id_case dans ma table "perso" (un perso ne peut se trouver que sur une case... logique non? ^^)

[Spoutnik]

Bonjour,

J'utilise un système similaire à NicoMSEvent:

J'ai une table "sol" qui stock x,y,id_carte,type_sol,id_entree,is_move.

-x et y sont les coordonnées de la carte.
-id_carte est l'id de la carte (en effet les bâtiments sont en fait des sous-cartes)
-type_sol est le type du sol (int) qui permet ensuite d'obtenir les infos que je veux sur le type de la case (l'image à afficher en fond, si un criminel peut réapparaitre dessus, etc.)
-id_entree est égal à -1 par défaut, sinon ce champ contient une chaine du type "id_carte;x;y" c'est-à-dire l'id de la carte vers laquelle le joueur va être amené et les coordonnées de cette carte.

Pour ce qui est des personnages, des bâtiments, des criminels (comprendre les monstres), des Pnj, ils sont gérés dans une table à part (une table par type) avec x,y,id_carte (pour leur situation).

Ce système a l'avantage d'être assez évolutif je trouve et ne nécessite que 5 requêtes pour être affichées (et encore, j'espère réussir à faire moins un jour avec les jointures et ramener ce nombre à 2 mais bon ^^'). Comme l'a dit Zamentur, les index bien placés, et hop

Bonne journée à tous, Spoutnik.