Discussion :

[Oberown]

(Je ne sais pas si c'est le bon endroit pour poser ma question. Si elle ne serait pas mieux adapter à la partie UML, diagramme de classe)

J'ai un labyrinthe 2D, représenté par des cases carrés. Ces cases peuvent avoir des murs sur chaque côté, ou être une case rempli (une case où on ne peut pas rentrer). On ne peut se déplacer en diagonale.

J'ai donc un objet labyrinthe qui contient un tableau d'objet case.

Mon objet case contient ces attributs qui sont tous des booleans:
- Mur Haut
- Mur Droite
- Mur Bas
- Mur Gauche
- Rempli

Est-ce que ma solution est bonne ou est-ce qu'on peut faire mieux ?

[dazz_x]

Ben en fait, tout dépend de ce que tu veux faire....

Là, à froid, je me dis que tu vas vouloir te balader dans ton labyrinthe et donc que tu vas devoir à chaque case parcourir ton tableau pour visiter une case voisine, non ?
Alors, bon, ça vaut ce que ça vaut, mais une p'tite structure de donnée qui maintiendrait pour chaque case une liste des cases voisines (accessibles et non accessibles), ça pourrait peut-être t'éviter des problèmes par la suite... Genre une structure de graphe avec des arcs labelisés, ou tout autre délicieuse entité imaginée par tes soins

[Oberown]

Mon tableau d'objet case est à 2 dimensions. Donc suffit de modifier les coordonées.

Sachant que par la suite les cases peuvent se déplacer, donc déplacer la case sur le tableau est plus simple que de refaire les graphes à chaque fois.

[khayyam90]

L'un des inconvéniants à stocker pour chaque case
- Mur Haut
- Mur Droite
- Mur Bas
- Mur Gauche
- Rempli

c'est la redondance d'info. Deux cases voisines auront un mur en commun mais deux infos pour parler du même mur (et je te raconte pas si les deux infos sont différentes).

Tu aurais pu t'en sortir en ne stockant que le mur haut et le mur gauche (le mur droit serait le mur gauche de la case de gauche, idem pour le mur bas) [gain de beaucoup de booléens], j'avais fait comme ça pour une génération de labyrinthes. mais si tes cases peuvent bouger ça risque de prendre pas mal de temps pour recréer la structure de données. Donc je pense que tu as fait le bon choix.

Il faut juste bien faire gaffe à une chose : pour qu'un mur soit franchissable, il faut que les deux côtés du mur le soient (oui, on peut consédirer les deux infos sur un mur comme étant les infos des deux côtés du mur)

[Oberown]

Sur les cases il peut aussi avoir des portes. (placé sur un des 4 côtés)
Donc mes attributs contiendrait un objet selon le placement.
- Côté haut
- Côté droit
- Côté bas
- Côté gauche

[koala01]

Salut,

Il faut juste bien faire gaffe à une chose : pour qu'un mur soit franchissable, il faut que les deux côtés du mur le soient (oui, on peut consédirer les deux infos sur un mur comme étant les infos des deux côtés du mur)

Ou, cerise sur le gateau, ca crée des "passages à sens unique" dans les murs (raccourcis, mais qui ne peuvent etre pris que dans un sens...)

[buzard]

Je ne sais pas si ça peut d'aider. Mais l'information importante c'est les murs et pas les cases qui sont essentiellement vides. Le principe consiste à donner de l'épaisseur aux murs :

si ton labyrinthe est de taille N x M, tu peut utiliser (indexation à partir de 0):

1°) soit un tableau T : 2N+1 x 2M+1
dont les éléments seront :
- " " case vide
- "#" mur horizontal
- "#" mur vertical
- "." intersections de mur (ou coins)

le type d'un éléments dépend de sa position

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
.#.#.#.
# # # #
.#.#.#.
# # # #
.#.#.#.

avantages :
- typage des murs : décoration, porte, entrée, sortie, pas de mur, ...
- typage des cases : ennemi, trésors, ...
- Pas trop difficile de faire des permutation de case (il faut juste penser à bouger les quatres murs autour)
- Localisation faclie

inconvénients :
- nécéssite quatre fois plus de place
- stock les coins qui ne servent pas à grand chose


2°) soit un tableau S : N+1 x 2M+1
ou seuls les murs sont renseignés, en ne considérant que les cases murs du tableau précédent. Car ils sont sur les cases de même couleurs d'un damier, on aurais alors la relation (par exemple si tu contracte les lignes):

S [i] [j] = T [2*i+(j+1%2)] [j]

avantages :
- peu de gaspillage de mémoire
- typage des murs

inconvénient :
- localisation difficile (calculs nécéssaire)
- mouvements des murs dificile à mettre en oeuvre


Donc, personnelement je pencherais pour l'utilisation du deuxième tableau, le plus gros certe, mais comme il n'est pas sensé en avoir des milliers, c'est le mieux.