Soucis jeu multi map

[rwk]

Voilà j'explique mon soucis. Ce n'est pas un soucis de codage mais de conceptualisation ^^.

J'explique l'idée, le jeu se déroule sans une ville gigantesque. L'idée est que toute l'intrigue repose sur ce jeu. Chaque quartier a est quand même une grande partie de la ville (genre map en 50*50).

J'me suis fais un petit script de maping pour poser mes batiments, mes murs mes terrains, le soucis, c'est que tout passe par la bdd... Créer des nouveaux quartiers, c'est à dire, une insertion dans la ligne quartier et une nouvelle table comprenant la place de chaque objet dans le quartier

du coup, au niveau de la bdd c'est agencé comme suit :

Code :

DROP TABLE IF EXISTS quartiers;
CREATE TABLE quartiers (
  id_quartier INT AUTO_INCREMENT,
  nom VARCHAR(255),
  taillex INT(3),
  tailley INT(3),
  spawnable INT(1),
  table_ref VARCHAR(255),
  PRIMARY KEY(id_quartier)
);

DROP TABLE IF EXISTS quartier1;
CREATE TABLE Marche_de_Braggon(
  id INT AUTO_INCREMENT,
  x INT(3),
  y INT(3),
  type VARCHAR(20),
  PRIMARY KEY(id)
);

j'explique rapidement :
la table quartiers recence l'ensemble des quartiers du jeu.
On y a l'id, le nom et sa taille (il peut donc etre carré ou rectangle ^^)
La colonne spawnable signifie "peut on s'y incarner à l'inscription ou lors d'une réincarnation" : 1 pour oui, 0 pour non.

Et table_ref est le nom de la table qui contient les données du quartier.

De là vient donc la table quartier1 (qui est donc dans la table quartier) qui est un quartier du jeu (le seul pour l'instant :p).
On a donc l'id d'un objet, sa position en x/y son type (herbe,goudron,batiment, arbre...)

-------------------
Donc le soucis, c'est que sur une map en 50*50, j'me rentrouve avec 2500 entrées dans la BDD, et si je créé un deuxieme quartier... de taille "réduite" (50*50, quand on place des batiments, des objets non traversable et tout, c'est pas énorme ^^) ca me fait vite fait pas mal d'entrées...

Donc j'vous laisse imaginer 10 ou 15 quartiers...

Donc c'est là ou j'arrive à mon soucis...

Dois-je faire une map immonde et super grande genre en 500*500 avec tout stocké en bdd ... (250000 entrées et faut se les remplir...)

Ne pas stocker mes quartiers dans des BDD mais dans des fichiers ?(mais dans ce cas là, ca devient chaut d'extraire mes données)

Bref, voilà ou est mon soucis de conceptualisation... y a quelquun qui a une idée ?

[zneman]

Je ne peux pas t'aider sur ce coup, je ne my connais pas assez mais si je peux me permettre, essaye de viser moins gros pour le début :p la c'est parti pour un boulot de plusieurs centaines d'heures rien que pour la BDD :/
Bonne journée

[Plume]

~~> Cache ? Téléchargement d'image sur le poste client ?

[despe]

bah du moment que ta bdd est bien optimisé 25 000 entrees c rapide.. j ai administrer un jeu de 250 000 entrees par map (y en avait 5) sur des bases differentes et pas trop de soucis question affichage

peut etre dans ta table met uniquement les donnes minimales pour ta map et tu utiliseras une autre table pour lié par exemple

[Sephi-Chan]

MySQL est fait pour les gros traitements donc ça devrait aller. Puis 2500 enregistrements sur une table indexée c'est pas tant que ça en fin de compte.

Je pense que tu ne devrais pas avoir peur de te lancer.
Il serait même peut-être possible de mettre en cache (dans un fichier) la map affichée (enfin là je connais moins le sujet :p).


Sephi-Chan

[Byleth]

Perso, ma map a un terrain par défaut qui est donc traversable(de la terre).
Tous les autres sont stockés dans une base de données, donc je divise direct mes entrées par 2.

Après, j'ai un éditeur qui me fait gagner énormément de temps pour créer la map (je mettrais le tuto en ligne un jours surement ^^ si tu veux des infos, MP moi), mais ça reste extrêmement long, donc je déconseille de tout créer soit même, fait toi aider ^^.

[rwk]

Bah comme je l'ai dit j'ai mon interface de création de map

tu cliques sur un pixel (un pixel en 100*100pixel en fait :p) et tu choisis quoi mettre à cet endroit.

Donc créer des map c'est pas dur ^^

C'est juste que j'avais peur avec une BDD de 10 ou 15 map allant de 50*50 à 250*250 et un nombre de joueur d'une bonne 200aine, de faire péter ma bdd ^^

Donc j'vais garder mon systeme du coup ^^...

Car une idée m'a traversé mais sa réalisation est chiante, chaude voir impossible...

Mais peut être que des personnes voudraient m'aider à "developper" ce systeme qui serait pas un mal pour une communauté de codeur.

------------------
J'explique le concept...

Prendre une image en jpeg/gif/bmp, n'importe... une image.

et récupérer chaque pixel de l'image et de mettre sa valeur en bdd
un truc qui donnerait :
pixel1 0 0 green
pixel2 0 1 green ...

Mais en php je sais pas si on peut parcourir une image de la sorte... pourtant je crois avoir vu un truc en javascript qui donne la couleur d'un pixel d'une image rien qu'en passant dessus...

Voilà l'idée... ainsi pour le maping, il suffirait de dessiner une carte sous paint, la passer au script php et avoir son résultat en bdd :]...

:]

[khiguard]

Dois-je faire une map immonde et super grande genre en 500*500 avec tout stocké en bdd ... (250000 entrées et faut se les remplir...)

En fait ca dépend si il y a beaucoup de modification sur ta base de quartier et de map de quartier. Si tu va souvent faire des update ou bien si tes joueurs vont modifier le terrain (dans ton cas je ne pense pas que ca soit utile) alors tu peut meme mettre tout dans la même base.
En rajoutant l'id du quartier dans ta table "quartier_map".

En fait ce qui ralentis une table, ce n'est pas la lecture mais l'écriture. J'ai déjà fait des tests sur des maps de 2000*2000, 5000*5000, a la lecture, ca reviens au même. Donc une base, même si il y a plusieurs millions d'entrée mais que tu ne fait que des lectures, ne ralentira pas avec le poid de celle ci. (si elle est bien indexée bien sure)

Perso, je gère une map de 750*750 cases avec des update au moins toute les heures et ca pose pas encore trop de problème. Donc ne t'en fait pas pour ca.

J'explique le concept...

Le concept existe depuis plusieurs année, c'est d'ailleur comme cela que IDEO gère sa carte. Donc il faudrait voir avec eux si ca tourne bien et si ca peut être plus rapide qu'en DB.
Je pense même qu'il y a un post la dessus sur Tour de jeu.
@+

[Sephi-Chan]

La technique des pixels de couleurs m'a l'air particluièrement affreuse. Ce n'est absolument pas "humain" de penser en pixel.

C'est plutôt : On à une table entités qui donne le nom de chaque élément (tonneau, mur, porte), ses coordonnées, puis à l'affichage de la map, on pose ces entités sur la carte. On peut également le faire avec des entités plus grosses si on à pas besoin d'une précision accrue, genre forge, maison, chateau.

La table carte, elle, contiendrait le type de terrain, du genre : Cette "case" est de l'eau, celle la est de l'herbe, etc.


Sephi-Chan

[Byleth]

Ca me parait mieux aussi parceque sinon, d'une t'es pas rendu, et de 2 ce sera moche même si plus varié que les techniques actuelles.

Ton éditeur de map me semble affreux pour une seule raison : le temps.

J'ai voulu faire mes essais et c'est très long. J'y ai réfléchi avec un copain admin d'apocalypses's dove. Lui a 2 cartes de 400*400 et a complètement délégué la création de carte à un staff.

Lui a une technique avec des zones (genre je sélectionne de x=15 à x=18 et y=78 a y=83) où il applique le même terrain.

Mon système à moi est beaucoup plus beau (à mon avis).

En fait, j'ai plusieurs interface, très proche cependant niveau code donc c'est très rapide à faire.

Pour l'instant j'en ai codé qu'un seul : comme je l'ai dis, mon système repose sur soit un terrain de base, soit des décors stockés dans ma base de donné. A la place du terrain de base, l'éditeur m'affiche des cases à cocher. Je n'ai plus qu'à cocher toutes les cases du même genre (comme l'eau), je choisis l'eau et hop, toutes les nouvelles cases d'eau sont stokées dans la bdd.

C'est très efficace, mais dans une carte en 400*400, il y'a 160 000 cases donc même comme ça, c'est extrêmement long...