+- 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 : [Map] quoi qui serait le mieux? (/showthread.php?tid=1509)
[Map] quoi qui serait le mieux? - Ruz - 03-05-2008
Hello!
J'ai parcouru ce site, et quelques autres, et je remet toute ma structure MAP actuelle en révision.
La petite histoire
Déjà, ma carte continent vient de maigrir drastiquement (7.500.000 cases => 48450).
A la base, la carte du continent permet de se déplacer rapidement entre villes, rien de plus. Chaque case est un lien vers une sous-carte.
Initialement prévues en 750*750, tuiles hexagonales.
Sur cette sous-carte, les actions, combats, recherche de matières premières (bois, pierres, plantes, etc...)
J'étais parti sur un truc lourd, pour limiter la place occupée en BDD, à savoir:
carte continent: X et Y stockées en smallint ( soit 4 octets pour repérer chaque case)... après réduction, je joue avec 2 octets par case. (deja ca de gagné (250*190 cases))
Pour la sous-carte, je ne pouvais stocker les 562 000 (* 7 500 000) cases en bdd). J'avais l'idée de générer ces sous-cartes à la demande (10 secs de freeze à l'accès initial)... pour ca, 9 carrés de 250 cases de coté... collés ensemble (en fonction des coordonnées x et y de la case continent), et hop, peuplage aléatoire suivant une table de rencontre.
1. sous-carte
Je revois ceci à la baisse actuellement, et je cherche une solution rapide, et souple pour y arriver.
Objectif: 50 à 75 cases de coté. (environ, pas plus petit, sinon, le coté "exploration" risque d'en prendre un coup... (genre: oh, j'avance de 20 cases, et j'ai fini le tour de ce gros coin de terre, merveilleux!))
Quelques infos sur la carte continent:
- 26418 cases de "terre"
- 22032 cases de "mer"
les cases mer: seront toutes les memes... de la flotte à perte de vue... c réglé.
les cases terre: arf, moins facile.
suivant le type de terrain, j'aimerais une sous-carte à thème différent (logique), mais faudrait pas que toutes les cases "foret" aient les memes arbres au meme endroit... ca fait un peu nul comme effet.
je pourrais stocker quelques sous-carte prédéfinies en bdd... et en prendre une "au hasard" (truqué, pour que ce soit tjs le meme qui sorte pour une X-Y continent donnée), ce qui me plait bien... mais je la load où?
en bdd? => ca risque d'encombrer la base, mais c'est le plus simple... (juste penser à libérer les ressources à l'occasion)
en fichier xml? => ouaip, a voir la rapidité de lecture, traitement, etc... (jamais testé réellement)... par contre, suivant la taille, ca prend plus ou moins de place... j'ai 1Go d'espace disque actuellement... faudrait que je vois la taille d'un fichier, pour voir. Ferai ca demain, si j'ai le temps.
autrement?
bref: première interrogation: comment gérer ces sous-cartes au niveau stockage selon vous?
-----------------------------------------------------------
2.pour la gestion des persos, etc.. en sous-carte.
table perso: pleins de champs, dont x / y / z sur la carte continent.
et pour relier le tout en évitant de reperdre mes anciens 4 octets, j'avais bidouillé un correspondance X/Y continent => ID_souscarte
et une table sous-carte ID/X/Y/Terrain
trois autres tables en plus:
mini_perso (ID_perso,ID_souscarte, X,Y, ...)
mini_monstre(ID_monstre,ID_souscarte, X, Y, ...)
mini_objets (ID, ID_souscarte, X, Y, ...)
pour gérer la position des persos, monstres et objets sur ces sous-cartes.
avec le recul, je me dis que je pourrais refusionner ces trois dernières tables en une seule, en rajoutant un champ "Type" enum (perso, monstre, objet).
d'autre part... ayant diminué le nombre de cases sur le continent... ne devrais-je pas leur donner à chaque un ID unique (0-50000, ca passe sur un smallint, si je me trompe pas...), et relier ca directement, sans passer par mes dernières tables citées? (bref, gérer au niveau de la table perso: ID_continent (l'ID de la case, plus besoin des coordonnées, je peux les retrouver par calcul simple), et X/Y pour la sous-carte? (et faire pareil pour les monstres, et les objets qui trainent).
En faisant ainsi, n'aurais-je pas des problèmes pour afficher la vue du continent? (un SELECT avec x between() et y between() plus facile que de chercher les ID des cases possibles? (niveau personnages .. niveau carte, j'ai tjs les X/Y en bdd))
Quoique: avec deux requetes: la premières me charge les tuiles en vue (ID, X, Y, Terrain)... je passe ca en tableau, je vire les doublons, et j'implode => liste des ID...
2e requete: SELECT .. form perso where ID_continent in (la liste)
[réflexion profonde]Bizarre, je réfléchi mieux en écrivant... j'avais jamais remarqué avec une feuille de papier... vive les forums!!![/réflexion profonde]
Bref: comment gérer au mieux la liaison entre les deux systèmes de carte? dans la table perso? une table à part? une autre idée?
---------------------------------------------------
3. les objets, etc...
Et oui, y a des objets qui tombent des cadavres, ou qui apparaissent tous seuls (les plantes...), ou que les PJ droppent de leur inventaire car trop chargés, etc...
En plus, ils doivent à terme pouvoir couper un arbre pour récupérer du bois, miner de la pierre, etc... bref: intéragir avec l'environnement.
Là aussi, je me demande comment gérer ca au mieux.
a priori, chaque objet peut etre ramassé... action de base.
le décor (arbre, rochers, ruisseau) devrait pouvoir offrir une action en adéquation (couper, tailler, pecher)...
une table action (ID, nom_action, lien_script), et mettre un champ "action possibles" sur les décors et objets, ca devrait etre le plus simple, non?
Au niveau du stockage (j'y reviens), mettre la liste d'actions possibles dans le ficher/bdd (bref: pour chaque tuile=> cet objet à telles actons possibles, bcp de doublons), ou seulement lier ca dans la table de référence, et donc:
fichier (pour faire court): x/y => décor arbre
=> accéder à la bdd, et aller voir table "décor"=> arbre... actions possibles=25,185,265. ( et donc, dans ce cas, je ne peux pas me passer de la bdd pour simplement afficher la sous-carte...)
et hop, ni vu ni connu, 3e truc à prévoir...
Où mettre les données d'actions possibles sur un objet/décor?
Bizarrement, je m'attends déjà aux réponses...
"ca dépend de ce que tu cherches: rapidité/simplicité/stockage réduit/autre..."
réponse: un bon équilibre entre tout.
Bon, sur ce, je vais dormir... la nuit porte conseil, y parait..
(message tapé, non relu)
PS: merci d'avoir lu ce gros pavé jusqu'au bout ^^
RE: [Map] quoi qui serait le mieux? - Ruz - 03-05-2008
Pff...
Je viens de me relire...
EN gros, je crois que je me réponds aux deux dernières questions...
reste donc, en gros, de savoir comment je vais stocker les sous-cartes...
RE: [Map] quoi qui serait le mieux? - Harparine - 04-05-2008
Salut, je me demandais juste si tu voulais faire disparaître tes arbres et tes rochers quand ils sont "récoltés".
Si tu n'en as pas besoin, je crois que je stockerais chaque sous carte dans un fichier xml en ne notant que les cases qui contiennent autre chose que ton terrain de base (la plaine). Concernant les actions à réaliser sur les éléments de décors, je stockerais tout ça "en dur" dans un tableau en php (vu que tu n'auras pas beaucoup de types de décors différents) en associant une action à chaque type de terrain.
RE: [Map] quoi qui serait le mieux? - Ruz - 04-05-2008
oui, oui, un arbre "récolté" devrait ne laisser qu'une souche visible à sa place...
Je suis en train d'imaginer un système hybride...
en bdd: plusieurs "schémas" de terrains (50*50). Quand on accède à une sous-carte, je vais rechercher un de ces schémas, et je le met en XML... le joueur aura donc une "instance" de sous-carte pour lui.
IL ne fait rien... ben, tant pis... l'instance disparaitra dans quelques temps...
Par contre, si il combat, il droppe un objet, coupe un arbre, ou que sais-je... Ben, je garde cette trace... l'arbre coupé doit le rester un petit temps... puis la souche disparait, et une pousse apparait plus tard... un nouvel arbre... qui grandira (rapidement) pour revenir au stade départ...
pour les rochers... euh, je vois mal le petit cailloux devenir grand.
Enfin, bref: si les joueurs déciment des arbres à longueur de journée... ca va se répercuter sur le monde... la foret deviendra clairière, puis plaine... si trop de plaine... désert? Enfin, c'est l'idée à long terme...
néanmoins, je ne peux garder tous les XML en permanence (1.7Go de place requise, j'ai estimé)... une solution serait de stocker, pour chaque modification, ID (case continent), X, Y, nouveau décor (la transformation), et un timestamp.
Quand je recharge la carte (XML effacé, car pas accédé depuis x temps (à définir)), je charge toute la case bdd en tableau... puis je repasse une couche pour modifier les trucs modifiées par les persos... (en adaptant éventuellement, si ca fait 20 ans, l'arbre est redevenu adulte)... ca devrait pas prendre énormément de place en bdd, c'est pas trop lourd à gérer, et ca peut amener une "dynamique" au jeu.
Sinon, pour le stockage en XML, j'y pense aussi...
je pense stocker sous un format du genre (attention, pitet pas XML pur, c'est juste un schéma pas du tout final)
Citation :<map ID=xxxxx Prov=xx Milieu=xx default_sol=xx>
<L Y=0>
<c X=0 Decor=yy />
<c X=1 />
<c X=2 />
<c X=3 Decor=ZZ />
</L>
<L Y=0>
<c X=0 />
<c X=1 Decor=yy />
<c X=2 />
<c X=3 Sol=EE Decor=GG />
</L>
etc...
</map>
Maintenant, les cases qui ont un sol par défaut, et qui n'ont pas de décor... vais-je devoir obligatoirement les mémoriser? Là est une question... ca simplifierait le chargement en tableau...
Enfin, le plus dur dans cette histoire, c'est de penser à toutes les évolutions possibles... pour pas bloquer un truc con dans 6 mois, et devoir tout rechanger ^^