Map Toroïdale

[Argorate]

Bonjour,

j'aurais besoin de vos avis/idées/conseils concernant le fait de rendre la map d'un jeu toroïdale (en forme de tore, ça veux dire que le nord est relié au sud et l'est à l'ouest).

Pour le moment sur ma V5.0 j'ai juste dis que quand on se déplace en -1 ça va de l'autre coté et vis versa. Ça marche donc simplement pour le mouvement.

Mais le problème est par exemple pour la gestion des relais.
Dans mon jeu, les relais conduisent l'énergie un peu comme des pilonnes électriques en partant du QG comme générateur. Je fais donc un appel récursif pour déterminer les relais reliés en regardant pour chaque relai s'il a un relai relié dans sa portée autour de lui.

Pour ce faire, je calcule la distance entre les deux relais [ MAX( ABS(x1 - x2), ABS(x1 - y2) ) ] de la comparaison en cours et je regarde si Distance <= Portée.
Logique donc, mais ça ne marche plus si on veux faire du toroïdale !

Ma Map fait 135*135 cases, donc si j'ai un relai en 2 ; 20 et un autre en 134 ; 20, il ne rempliront pas les conditions alors qu'ils devraient.


Une idée d'algorithme pour gérer ça?


Merci.

[niahoo]

bah tu changes ta formule mathematique non ?

[Myrina]

Pourquoi ne pas faire 5 fois le calcul (x2=, y2=):
- un pour le centre : X + 0, Y + 0
- un pour l'ouest : X - 135, Y + 0
- un pour l'est : X + 135, Y + 0
- un pour le nord : X + 0, Y - 135
- un pour le sud : X + 0, Y + 135

Et tu peux même gérer les diagonales

[Xenos]

Sur une map toroïdale, type [n,m] répétée à l'infinie à l'horizontale et à la verticale, il y a une infinité de vecteurs qui vont de [x,y] à [u,v], sous la forme:

Code :

Vecteurs( [x,y] [u,v] ) = { (p,q) entiers relatifs: [ u-x+p*n, v-y+q*m ] }

Maintenant, si tu cherches la distance entre [x,y] et [u,v], on va considérer que tu cherche le vecteur de cette famille dont la longueur est la plus faible, puis que tu prend la longueur de ce vecteur. En d'autres mots, tu cherches la plus courte distance entre [x,y] et [u,v] en te servant (ou non) du fait que la map "boucle" N/S et E/O.
Les modulos sont là pour cela!

Code :

Distance( [x,y] [u,v] ) = sqrt( ((u-x+n/2)%n)² + ((v-y+m/2)%m)² )

Avec le [0,0] au centre de la map, et une map qui va de [-n/2, -m/2] à [n/2, m/2] et donc les points sont modulo [n,m] (un peu comme les angles d'un cercle qui vont de -Pi à Pi, et qui sont modulo 2Pi).

Je vais quand même vérifier l'équation, pour être sûr

---

Petit oubli des -n/2 et -m/2:

Code :

Distance( [x,y] [u,v] ) = sqrt( ((u-x+n/2)%n - n/2)² + ((v-y+m/2)%m - m/2)² )

Cela marche également avec la norme infinie que tu utilises:

Code :

Distance( [x,y] [u,v] ) = ABS((u-x+n/2)%n - n/2) + ABS((v-y+m/2)%m - m/2)

Mais ici, je considère que les modulo sont les restes positifs dans la division par n ou par m. Or, dans la plupart des langages (dont PHP), on a:

-13 % 64 = -13

Ce qui ne nous arrange pas...
Je vais réarranger la formule pour ces langages-là.

---

Pour des langages dont le modulo % renvoie "-13 % 64 = -13", comme PHP, il faut employer:

Code :

Distance1( [x,y] [u,v] ) = ABS((u-x+3*n/2)%n - n/2) + ABS((v-y+3*m/2)%m - m/2)
Distance2( [x,y] [u,v] ) = sqrt( ((u-x+3*n/2)%n - n/2)² + ((v-y+3*m/2)%m - m/2)² )

---

Au fait, attention avec les map toroïdales:
Un rayon infini lancé à l'horizontal sur une map toroïdale touchera forcément une cible, soit il touchera le lanceur en lui revenant dans le dos, soit il parcourra toute la map et touchera forcément une cible, s'il en existe une qui possède une surface. S'il n'y a que des points sur la map, je ne suis pas certain de ce qui se passera...

[niahoo]

xenos toujours premier sur les math ^^

pour ton dernier point faut juste pas avoir de portée qui dépass la taille de la map ça limite les embrouilles

[Argorate]

Ce que j'ai fais finalement:

je test le cas normal:

SI ( distance <= portée ) return true
return ( taille_map - distance_des_x <= portée ET taille_map - distance_des_y <= portée )

Ca marche bien apriori