+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Gestion cartes immenses - comment optimiser au max? (/showthread.php?tid=1601)
Gestion cartes immenses - comment optimiser au max? - Ruz - 20-04-2008
Allez, premier gros problème sur mon projet: le système de double-carte
[ROMAN INSIDE]
En résumé, y a deux niveaux de carte... la principale (carte Kalidhia, le continent) et chaque case de cette carte correspond à une sous-carte... pour les actions
1. carte continentale
j'ouvre le document "géographie de Kalidhia", hop, mesures... 2500*3000 km, de mémoire. A la base, je me dis: 1km², une case en base de données...
alors, chaque case a :
* un terrain (ID unique d'une autre table)
* présence/absence de route
* présence/absence de cours d'eau
* lié a une province (ID unique d'une autre table)
pour les routes et cours d'eau, j'utilise un tinyint (x2) pour rapidement indiquer l'orientation des routes possibles... avec mes 256 possibilités, je peux créer toutes les intersections possibles (sans générer (256 * 256 * nombre de terrains) imaginables en image sur le serveur.
(en gros, y a 8 extrémités à chaque portion de route possible: les 4 coins d'une case, et les 4 milieux de coté. chaque possibilité recoit une valeur, en partant du milieu haut, en tournant dans le sens des aiguilles (1,2,4,8,16,32,64,128)). j'additionne ce que je veux comme portion, et hop, j'ai ma valeur inférieure à 256.
Bref: a l'affichage de la carte, si route =0 et eau=0 => image terrain simple. Sinon, je génère l'image par code.
Je devrais normalement rajouter encore un tinyint pour les deux... car je peux avoir un sentier, chemin, route, autoroute et ruisseau, rivière, fleuve, canal... 8 choix, ca tient donc aussi en 1 octect.
Enfin, bref, pour celle-ci, j'ai finalement décidé de réduire la grandeur réelle du continent, histoire de pas stocker 1Go de données dans la base. (première estimation, à la première simulation).
Là, sur le portable, j'ai 71Mo pour cette carte. (oui, je bosse sur le portable, et je met sur serveur par packet)
Sur celle-ci, si vous avez des idées pour réduire/optimiser, je prends ^^ (mais c'est pas ma priorité)
je pense aussi que ca va faire un monde très très grand, pour les joueurs... et si je ne peux accepter que 1000 joueurs, ils risquent de pas se croiser souvent... Premier sondage: quelle serait la taille idéale d'une carte d'un contient?
2. sous-carte (tuiles hexagonales, a terme - règle du jeu: 6 assaillants max par cible)
chaque sous-carte représente théoriquement 1km²... soit 1000*1000 cases. Je peux stocker la carte en bdd, pour chaque sous-carte... et hop, j'explose le serveur OVH avant meme de créer un perso (notez que c'est déjà fait avec la carte avant)
Bref: les sous-cartes se génèrent auto à l'entrée d'un perso (si pas déjà existante en bdd) et se désintègrent au départ du dernier (compteur sur le nombre de perso présent sur la carte). Je dois la générer... aléatoirement, mais reproductible, donc pas aléatoire ^^
Là, fonction maison: Je découpe chaque carré (carte) en 9 carrés plus petits. suivant X et Y du continent (+ une variable diff pour chaque case), je fais un modulo pour chacune des 9 cases (sera tjs le meme) => je récupère dans la BDD une portion de terrain de 250*250 cases pour chaque. Là dessus, je repasse deux couches: une pour les routes, et l'autre pour la flotte (pas encore au point, mais c'est l'idée)
bref: je stocke donc ce résultat en bdd pour le perso... et je désintègre le tout dès que possible.
Sauf que 652500 enregistrements, par sous-carte, ca me plait pas... je cherche à stocker ca différement. (notez que chaque enregistrement se trimballe un ID de lien avec la position de la carte continent... je remet pas le X, Y, Z du contient dans chaque, trop lourd. structure: ID, X, Y, Image)
là-dessus, je récupère les persos, les monstres (générés avec la carte) et les objets (objets, pas décors(arbres, rochers, maisons...))
Pour les décors, je fais aussi une magouille: un ID par case... si c'est un sol, no prob. (pas de décor sur la case), si c'est un décor, je récupère le dernier sol utilisé)(oui, la première case sera donc tjs un sol)
CE QUE JE CHERCHE:
puis-je me passer du stockage en bdd?
oui, certainement... je passe par des fichiers sur le serveur (cool, pas d'accès a la bdd)...
XML - serveur?
vais devoir ouvrir a chaque mouvement le fichier sur le serveur (562500 enregistrements, hein - ca tient sur +- 600Ko d'apres mes tests en "xml" perso), charger tout en mémoire pour aller lire les 50-100 cases qu'il me faut. ca me parait lourd.
XML - client?
Envoyer le fichier au navigateur, et le stocker sur le HD du joueur? (est-ce possible? comment récupérer les données? javascript? - + problème: les joueurs pourraient aller chercher/modifier le fichier (voir/modifier la carte donc, rien d'autre)
Enfin, voilà... J'expose un truc qui m'embete depuis un bon bout de temps, pour lequel j'ai une solution, mais je cherche mieux.
Grand merci à ceux qui se pencheront sur ce cas spécial.
(oui, d'habitude, c'est plutot 200*200 cases, j'ai l'impression, pour une seule map)
Ruz, cartographe cinglé
RE: Gestion cartes immenses - comment optimiser au max? - Loetheri - 20-04-2008
Il y a, me semble-t-il, deux questions/problèmes.
Le premier problème est celui de la taille tandis que le second qui découle de la taille est la façon de stocker les données.
Tout d'abord, va voir ce qui se fait dans d'autres jeux.
Je prends l'exemple de Campagne de Russie qui tourne avec environ 2200 joueurs sur une carte de 250*130. Le jeu veut qu'il y ait des interactions entre les joueurs (il faut tapper les autres). Nainwak avec ces 3200 joueurs, a (8*12*64) soit 6144 cases. Ideo tournait avec 3000 joueurs sur 400*400 (si j'ai bon souvenir). Mountyhall, je ne sais pas.
Cela dit à la lecture de ta description, est-ce qu'il faut nécessairement avoir autant de cases ? Si je compte bien, pour la carte principal, on arrive déjà 7.500.000 de cases. Si on "zoom", on arrive donc à 7.500.000.000.000 cases (en mettant tout côte à côte). Comment tes joueurs vont-ils se retrouver ?
J'ai pu lire que tu vises les 1.000 joueurs. Va regarder du côté de Rex Europae qui peine a avoir plus de 200 joueurs. L'équipe a du réduire le terrain de jeu et les joueurs (certains) ont redemandé à re-réduire pour cause d'une trop petite concentration de joueurs.
Tu parles de reproduire les cartes secondaires si personne ne s'y trouve. Ok ! Mais as-tu une idée pour faire cela ? Comptes-tu n'utiliser que PHP (souvent limité à 30 secondes de "réflexion") ? D'autant qu'un joueur pourra choisir, je suppose (et je peux me tromper), d'entrer à tout moment dans une sous-carte, d'où la nécessité que la mise en BdD soit rapide ^^
Pour les routes/cours d'eau, ne ferais-tu mieux pas de générer tous les cas possibles une fois et de tout sauvegarder gentillement quelque part ?
Pour ma part, je te conseille de te repencher sur ton projet en allant voir et discuter (par mail) avec les créateurs/administrateurs de jeu déjà existant. Certains ne te répondront pas, d'autres oui. Certaines personnes de la communauté te répondront. Mais en terme de chiffre, j'estime que tu vois largement trop gros. Pour un jeu avec 1000 joueurs planchant sur une interaction "moyenne", je dirais que 200*200 ou 250*250 est une bonne donnée avec possibilité de créer des sous-lieux ne dépassant pas les 20*20. Mais cela n'est que mon avis.
Pour gérer les données, je te conseille de faire une recherche sur le forum. Ce problème a déjà été abordé au moins une ou deux fois.
RE: Gestion cartes immenses - comment optimiser au max? - Ruz - 20-04-2008
cool... enfin des personnes qui comprennent ce que je tente de faire ^^
ca me change de mes promoteurs, qui ont tjs pas capté les bases
pour répondre a ta question: Mountyhall n'a pas de carte. Le monde est ouvert, et sur plusieurs niveaux. Je pense qu'il ne gèrent que des lieux, des objets et les monstres. Bref: pas de limites, et pas de "terrains" a garder en mémoire. Une fameuse économie de place.
Alors, pour la taille de la carte du continent, clair, si je garde ma première idée, ca va faire un monde très peu peuplé... d'où le sondage ^^
[ressort son atlas du monde en question]
300*250... 75000 cases : cases de 100km² (ca, c mon repère pour simuler l'éloignement entre les villes, la taille des provinces, etc)
150*125 (ca, ca irait plus ou moins dans la moyenne, alors...):400km²
vais tenter de faire ca, et de voir ce que ca donne...
pour les sous-cartes, diviser encore, alors... c clair, ca va bien diminuer les déplacements...
Sinon, la génération prend une dizaine de secondes... le temps de charger/sauvegarder les tuiles. c lent, mais ca n'arrive qu'une fois... enfin, tant que c pas déchargé. 20*20, c vraiment peu... mais d'un autre coté, ca limite les déplacements, et je met moins de monstres du coup...
sinon, pour générer directement toutes les possibilités eau/route, ben, ca fait du boulot, tout ca... ou alors je le fait par script, et je sauvegarde les images direct... curieux de voir la place que ca prendrait... il va etre lourd, le pack graphique ^^
enfin, merci pour ta réponse ^^
EDIT (réflexion en envoyant: de toutes manières, si je fais un pack graphique, toutes les images devront venir du pack, pas moitié/moitié... donc, oui, faut que je les génère, de base
)
RE: Gestion cartes immenses - comment optimiser au max? - phenix - 20-04-2008
Personnellement, j'ai aussi une très grosse carte, découper en petit fichier contenant la carte sous forme de chaine de caractère.
Il y a un excellent sujet ici: http://www.jeuweb.org/board/showthread.php?tid=3572
Tu y trouvera pas mal de chose qui sauront aider
RE: Gestion cartes immenses - comment optimiser au max? - Ruz - 21-04-2008
Bon, je viens de passer la soirée sur mon script préféré ^^
en résumé, je crée une carte en image... je la passe dans mon script, et hop, ma carte est générée en BDD
1 pixel = 1 couleur = 1 terrain ^^
La carte du monde vient donc d'etre revue à la baisse... 190 * 255 cases. (pour rester avec des proportions correctes du continent ^^
Bon, là dessus, je vais devoir rechanger les coordonnées de tous les persos (ca ira vite), modifier mon script d'apparition, et créer rapidement quelques tuiles manquantes...
m'enfin, ca va, j'ai tout de suite reconnu l'endroit où j'étais ^^
Bon, prochaine étape, refonte des sous-cartes.
RE: Gestion cartes immenses - comment optimiser au max? - phenix - 22-04-2008
Citation :en résumé, je crée une carte en image... je la passe dans mon script, et hop, ma carte est générée en BDD
1 pixel = 1 couleur = 1 terrain 34
Sa serais vachement bien que tu rende ce script publique, je suis très intéresser :wowowow:
RE: Gestion cartes immenses - comment optimiser au max? - Ruz - 22-04-2008
Je commente ce script, et je vous le partage ^^
Je précise qu'a la base, l'idée originelle est partie d'un auter script, qui utilisait les pixels d'image pour stocker des données... enfin, un truc du genre.
Je l'ai bien détourné de sa fonction première, et voilà...
Enfin, bref: je vais tenter de lancer un ftp sur mon serveur du boulot... si ca passe, je le commencete et l'envoit dans la journée.
RE: Gestion cartes immenses - comment optimiser au max? - Ruz - 22-04-2008
bon, je viens enfin de trouver le temps de le copier sur le portable (version modifiée), et je commence à commenter, et réduire au strict minimum (je pense que vous vous foutez de la gestion de la province de la case ^^)
Je finirai ca ce soir, une fois els petits au lit. Je l'uploaderai donc juste apres...
pour présenter un script, il vous faut quoi? le code? ou un zip avec tout le nécessaire? Enfin, je regarderai un peu les post-it dans la section, et j'aviserai.. mais autant avoir le plus gros de l'idée direct ^^
RE: Gestion cartes immenses - comment optimiser au max? - Ruz - 22-04-2008
script envoyé...
deux fois... le première, je sais aps si elle est passée ou non... j'ai zappé le message du modérateur ^^ (a moins qu'il y ai un délais limite pour poster, dans ce cas, je l'ai explosé ^^)
Bref: ca devrait arriver...
Pour le wiki, ben, je vais déjà essayer de comprendre le fonctionnement de ce machin... on verra plus tard, donc ^^