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).
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).
![[Image: banner.png]](http://www.laluciole.me/wp-content/uploads/2013/02/banner.png)