+- 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 : Création de map par l'utilisateur (/showthread.php?tid=4139)
Pages :
1
2
RE: Création de map par l'utilisateur - Zamentur - 29-06-2009
De façon alternative il est aussi possible de stocker le tableau sérialisé dans un champs texte.
Finalement comme pour la chaine de caractère plus haut, l'intérêt étant que c'est plus simple à gérer.
Sinon un des problème à mon sens c'est qu'il va falloir créer un tas d'algorithme pour gérer ces maps, car on aura pas la puissance du langage SQL...
Concernant le système de cache ou le système par fichier (ce qui revient presque au même au final) un trucs m'embête vis à vis du nombre de fichier qu'il pourrait y avoir : 50 joueurs et on a 1000 fichiers... En fait je pense qu'une bdd serait plus performante.
Pour la solution 1 enregistrement par case, c'était idiot j'avais pas pris le temps de faire le calcul pour constater qu'effectivement il y aurait trop de champs. En fait une base de donnée gérant le relationnel objet aurait pus faire l'affaire grâce aux OID et en définissant la liste des cases comme table imbriqué...
NB: pour le cas du tableau (ou même de la liste de case) il est possible d'économiser de la place en définissant un terrain par défaut (herbe/eau). Ainsi on réduit certainement de 20% au minimum la taille des données si le type de terrain est correctement choisis.
Sinon on peux aussi imaginer un système hybride, par exemple si il s'agit de jouer des parties sur les cartes on peux décider de stocker en bdd seulement les maps qui sont utilisé par des parties en cours. Ainsi on s'affranchie d'un travail long et fastidieux.
Je me demande aussi si avec l'index sur l'id de la map le temps de recherche serait si important avec la solution d'une case par enregistrement. En fait ce qui me fait peur c'est plus la taille de tout çà.
Dans les estimations les plus haute on a en fait 100 000 000 enregistrements d'environ 10 octets (pour 2000 joueurs), soit une table d'1Go avec un index portant sur environ 40 000 éléments (puisqu'il y a 40 000 map)+ l'index des positions le tout formant la clé primaire.
En fait rien ne dit que les performances seraient naze, par contre c'est pas le genre de trucs qu'on peux avoir en mutualisé vu la taille de la table!
Ici je n'ai pas tenu compte des optimisations cités plus haut.
J'essaierais peut être si j'ai le temps un de ces 4
NB: la methode par fichier sera quand à elle tout aussi lourde si ce n'est pas plus.
Donc ce que je conseille c'est de faire des tests, et choisir en fonctions
RE: Création de map par l'utilisateur - kilhom - 29-06-2009
Mais c'est pas bête du tout ça Holy !
Ca va pas mal m'aider je pense, c'est bien plus simple de manipuler des variables directement et de tout convertir après avec un serialize plutot que de tout devoir interpréter à chaque fois.
Mais du coup, tu met toutes tes infos relatives à la map dans ton serialize ?
Tu sépare en plusieurs parties ?
Merci de ton aide !
RE: Création de map par l'utilisateur - Holy - 29-06-2009
A Zamentur: à priori, le nombre de fichier n'est pas si énorme que ça, tu aurais par exemple un fichier par carte. Chaque partie a son fichier, pas chaque joueur.
Personnellement, j'utilise un système hybride. En gros, tout ce qui relève de l'environnement est conservé en fichier. La position des joueurs s'y trouve également, "en lecture" disons. Mais j'ai également une base de données en bonne et dûe forme que j'utilise principalement pour la position des joueurs en fait (c'est la variable qui change le plus sur les cartes, donc j'dois pouvoir préserver son intégrité, donc bdd) et tout ce qui ne relève pas de la carte proprement dit (armées, constructions, etc.).
Après, les outils de maintenance faut les créer soi même, mais honnêtement, ça prend pas tellement de temps. J'ai par exemple des fonctions de nettoyage qui vont récupérer la position des joueurs en bdd et qui les replace sur la map par exemple (en imaginant qu'il y aie eu un bug majeur).
Le désavantage que je n'ai pas évoqué auparavant par rapport aux fichiers, c'est le fait que si ils sont vraiment gros, les perfs peuvent en pâtir. Donc tout dépend de la taille de ta carte et des couches qui s'y trouvent (objet, sol, bâtiment, etc), mais si les fichiers commencent à vraiment devenir gros (exemple une map de 200 sur 200 avec pas mal de couches, ça grossit pas mal la taille) y a la solution de "diviser" ta carte en "zone" et donc d'avoir par exemple 4 fichiers pour une map et tu charges uniquement la partie sur laquelle se trouve le joueur (exemple: ta carte fait 32 sur 32, tu n'affiches que 16 sur 16, tu auras 4 fichiers correspondant à chaque quart de la carte).
Il y a aussi la solution évoquée par zamentur avec les éléments par défaut qui réduit la taille.
Donc, sinon, oui j'ai toutes les infos relatives à ma map dans un serialize. Après pour l'optimisation et la séparation en fichier, ça dépend vraiment de la manière dont tu "affiches" ta carte. Si par exemple la carte est toujours centrée sur ton perso, tu ne peux pas faire ce que j'ai expliqué plus haut. Mais par exemple tu peux créer un fichier pour ta map, un fichier pour tes objets, etc. Mais tout ça dépend vraiment de la manière dont tu gères tes parties. Il faut bien réfléchir à la pertinence de la décentralisation, mais je pense que ça peut être un système intéressant, au moins en ce qui concerne le montage des cartes stricto sensu.
Ca implique une organisation un peu particulière, parce que peu "traditionnelle", mais ça reste je trouve vraiment un bon système. A chaque fois que tu lances une partie, il te suffit de créer un nouveau dossier avec l'id de la partie, de copier coller la map dedans, et voilà, tu as une map "neuve" qui peut s'adapter dès qu'un mec coupe un arbre, construit une étable (lol). En fait, pour faire simple, il faut veiller à faire correspondre l'interface visuelle et environnementale avec une réalité en bdd (exemple: nouvelle étable, ajout d'une ligne "étable" en bdd pour le joueur x).
RE: Création de map par l'utilisateur - Zamentur - 30-06-2009
(29-06-2009, 06:00 PM)Holy a écrit : A Zamentur: à priori, le nombre de fichier n'est pas si énorme que ça, tu aurais par exemple un fichier par carte. Chaque partie a son fichier, pas chaque joueur.
Ben si puisqu'il est questions qu'un joueur créé lui même jusqu'à une vingtaine de carte.
Ou alors j'ai rien compris.
RE: Création de map par l'utilisateur - Holy - 30-06-2009
Si je ne me trompe pas (mais je peux me tromper :p), il s'agit de cartes réutilisables pour d'autres parties. Donc en gros, créer des cartes pour alimenter le jeu en cartes jouables. Mais j'avoue ne pas avoir tout tout bien lu en ce qui concerne le contexte d'utilisation ^^
RE: Création de map par l'utilisateur - wild-D - 30-06-2009
le problème c'est qu'il reste quelques ambiguité (en tout cas pour moi)... moi j'ai toujours pas compris si les 10-20 carte par joueur c'est des instanciations ou bien leur "modèles".
sinon holy , si j'ai bien suivis ton système à quoi te sert le serialize/deserialize plutot qu'un var_export/include ?
ne serait-il pas plus performant que tes fichiers contiennent un:
<?php return $MAP; ?>RE: Création de map par l'utilisateur - kilhom - 30-06-2009
Les 10-20 cartes sont nien des "modèles" ensuite utilisés pour des instanciations.
Mais bon 10-20 c'est une bien grosse prévisions !
En tout cas merci à tous je commence à y voir plus clair à ce niveau
RE: Création de map par l'utilisateur - Anthor - 30-06-2009
Sérialiser les fichiers peut-être utile si tu veux les récupérer avec php ou javascript par exemple.