A votre avis : Les parametres d'affichages (la case sur laquelle la carte est centree, la taille de la carte affichee, le zoom... ect) doivent il rester des parametres d'entree de la methode afficher_carte() ou serait il preferable qu'il soit des variables de la class carte ? (en sachant qu'une carte n'est pas toujours censée être affichée)
Par ce que je comment à faire passer quasiment tous ces paramètres dans des méthode prive appelées par la methode afficher_carte car ils me servent pour les calculs...
Ex : La methode afficher_carte va appelé pleins de fois la methode creer_case, or cette methode a besoin de quasiment tout les parametre d'affichage pour correctement fonctionner...
Merci d'avance.
Edit : En fait ma problematique est encore plus vaste puisque je suis en train de travailler sur les cases adjacentes à celle du joueur (afin de les munir d'un lien de deplacement)
Le problème étant que, puisque je parcours ma carte de y en y, de x en x, je vais rencontrer mon joueur après avoir etudier quelques unes des cases adjacentes à la sienne...
Séparation de la génération du html et les informations d'affichage de chaque case ? ><
Une case, pour s'afficher, à besoin de :
- ses coordonnees dans la carte complete (x, y)
- le decalage par rapport à la carte complete de la carte partielle (x_decalage, y_decalage) (communs à toutes les cases)
- ses coordonnees dans la carte partielle (affichée) (xc, yc) (dépendent de x, y, x_decalage, y_decalage)
- zoom (taille d'un coté de l'hexagone > "n") (communs à toutes les cases)
- largeur ( l ), hauteur ( h ) (dépendent de n)
- sa position (posX, posY) (dépendent de x (si crenelage en x), y (si crenelage en y), xc, yc, n)
- du mode d'affichage (mode = 2D, 2Diso) (communs à toutes les cases)
- la taille de la carte partielle (taillex (si crenelage en x), tailley (si crenelage en y)) (communs à toutes les cases)
Donc si je veux faire une étape intermediaire, c'est à dire que la methode afficher va d'abord stocké toutes ces infos dans un tableau, puis ce tableau sera ensuite interpréter en HTML (ce qui laisse la possibilité de l'interpreter dans d'autre langage
). Entre ces 2 étapes je pourrai alors modifier des cases déjà évaluées.
Qu'en pensez vous ?
ComG, en mode monologue x)
Donc au final, les seules infos particulières à UNE case, et qui ne peuvent pas se déduire des infos GLOBALES sont :
- xc (on peut en deduire x par x_decalage)
- yc (on peut en déduire y par y_decalage)
Ensuite les informations finalement affichées :
- hexa (structure) (n'a aucune raison d'être modifié par une case évalué après)
- texture (n'a aucune raison d'être modifié par une case evalué après)
- objet/batiment/decor (n'a aucune raison d'être modifié par une case evalué après)
- personnage (n'a aucune raison d'être modifié par une case evalué après)
- informations sur la case (n'a aucune raison d'être modifié par une case evalué après)
- liens (deplacement pour une case adjacente, interaction pour une case où se trouve un autre joueur, juste acces aux infos pour une case dans le champs de vision, aucune infos pour les cases hors champ de vision...) <<< On peut donc jouer juste sur une valeur qui classe la case selon cela
soit =>
Avec type =
- adjacente
- adjacente + autre joueur
- dans le champs de vision
- dans le champs de vision + autre joueur
- hors champ de vision
On pourrait alors diviser ce "type" en 2 champs
Ou distance serait le nombre de case entre la case courant et la case du joueur actif et joueur prendrait l'ID d'un autre joueur
Bien entendu, tout cela par rapport à une seule case qui est la case du joueur actif !
Il faudra cependant gerer le cas ou la carte prend en compte ce joueur actif (champs de vision), ou bien s'il ne s'agit que d'une navigation sur la carte...
Par ce que je comment à faire passer quasiment tous ces paramètres dans des méthode prive appelées par la methode afficher_carte car ils me servent pour les calculs...
Ex : La methode afficher_carte va appelé pleins de fois la methode creer_case, or cette methode a besoin de quasiment tout les parametre d'affichage pour correctement fonctionner...
Merci d'avance.
Edit : En fait ma problematique est encore plus vaste puisque je suis en train de travailler sur les cases adjacentes à celle du joueur (afin de les munir d'un lien de deplacement)
Le problème étant que, puisque je parcours ma carte de y en y, de x en x, je vais rencontrer mon joueur après avoir etudier quelques unes des cases adjacentes à la sienne...
Séparation de la génération du html et les informations d'affichage de chaque case ? ><
Une case, pour s'afficher, à besoin de :
- ses coordonnees dans la carte complete (x, y)
- le decalage par rapport à la carte complete de la carte partielle (x_decalage, y_decalage) (communs à toutes les cases)
- ses coordonnees dans la carte partielle (affichée) (xc, yc) (dépendent de x, y, x_decalage, y_decalage)
- zoom (taille d'un coté de l'hexagone > "n") (communs à toutes les cases)
- largeur ( l ), hauteur ( h ) (dépendent de n)
- sa position (posX, posY) (dépendent de x (si crenelage en x), y (si crenelage en y), xc, yc, n)
- du mode d'affichage (mode = 2D, 2Diso) (communs à toutes les cases)
- la taille de la carte partielle (taillex (si crenelage en x), tailley (si crenelage en y)) (communs à toutes les cases)
Donc si je veux faire une étape intermediaire, c'est à dire que la methode afficher va d'abord stocké toutes ces infos dans un tableau, puis ce tableau sera ensuite interpréter en HTML (ce qui laisse la possibilité de l'interpreter dans d'autre langage
). Entre ces 2 étapes je pourrai alors modifier des cases déjà évaluées.Qu'en pensez vous ?
ComG, en mode monologue x)
Donc au final, les seules infos particulières à UNE case, et qui ne peuvent pas se déduire des infos GLOBALES sont :
- xc (on peut en deduire x par x_decalage)
- yc (on peut en déduire y par y_decalage)
Ensuite les informations finalement affichées :
- hexa (structure) (n'a aucune raison d'être modifié par une case évalué après)
- texture (n'a aucune raison d'être modifié par une case evalué après)
- objet/batiment/decor (n'a aucune raison d'être modifié par une case evalué après)
- personnage (n'a aucune raison d'être modifié par une case evalué après)
- informations sur la case (n'a aucune raison d'être modifié par une case evalué après)
- liens (deplacement pour une case adjacente, interaction pour une case où se trouve un autre joueur, juste acces aux infos pour une case dans le champs de vision, aucune infos pour les cases hors champ de vision...) <<< On peut donc jouer juste sur une valeur qui classe la case selon cela
soit =>
Code :
xc | yc | type- adjacente
- adjacente + autre joueur
- dans le champs de vision
- dans le champs de vision + autre joueur
- hors champ de vision
On pourrait alors diviser ce "type" en 2 champs
Code :
xc | yc | distance | joueurBien entendu, tout cela par rapport à une seule case qui est la case du joueur actif !
Il faudra cependant gerer le cas ou la carte prend en compte ce joueur actif (champs de vision), ou bien s'il ne s'agit que d'une navigation sur la carte...