Bienvenue
visiteur !

Index du forum > Entraide > [RM2k3] Distance entre deux points

Mack - posté le 25/11/2023 à 16:31:36 (2290 messages postés) - ❤ 0
	Domaine concerné: Math Logiciel utilisé: RM2k3 Salut ! Je suis en train d'essayer de faire un système de choix de cible automatique, basé sur la distance entre la cible et l'attaquant, et j'aurais besoin d'un coup de main. Pour faire simple, le système de combat se base sur une double grille comme ça : Quand le héros attaque, sa cible va être choisie selon des règles précises selon l'attaque utilisé. Donc, pour la règle la plus simple, c'est juste l'ennemi le plus proche, donc pour ça je fais juste un calcul de distance basique entre deux points : Portion de code : Tout sélectionner 1 sqrt((posX_H - posX_E)² + (posY_H - posY_E)&) ( posO_H pour les positions du héros, posO_E pour les positions de l'ennemi ) Evidemment, je fais le calcul pour tout les ennemis, et j'enregistre celui avec la distance la plus basse Mais petit problème, ça me donne ça : Donc sur la fille le calcul est bon, mais sur le mec, même si le calcul est bon ( il est à 2 cases en diagonale du monstre en haut, et 2 cases en face de celui du bas ), j'ai peur que les joueurs comprennent pas pourquoi ça cible cet ennemi est pas celui d'en bas. Donc déjà, est ce que ça vous semble pas vous aussi un peu trop compliqué comme situation ? Donc pour régler ça, j'ai essayé de donner du poids à mes variables, et donc d'augmenter le poids des positions X : Portion de code : Tout sélectionner 1 sqrt(((posX_H - posX_E) * 10 + 1)² + ((posY_H - posY_E) * 10)²) Ça à l'air de marcher, mais j'ai cru voir qu'à un moment ça n'a pas ciblé le bon ennemi, et j'ai eu le problème qu'une fois. Ça vous semble okay ? ( Et tant qu'à faire, je veux créer une autre règle pour dire l'ennemi le plus en ligne, un truc comme ça : Portion de code : Tout sélectionner 1 sqrt(((posX_H - posX_E) * 10)² + ((posY_H - posY_E) * 100)²) Devrait être bon non ? )
( Je prend note de tout les commentaires, même si je n'y répond pas )

Anton_ - posté le 25/11/2023 à 17:32:40 (1523 messages postés) ❤ 0
	Ah bon, la fille a l'air d'être 2 cases en face de l'ennemi en bas, et le garçon à 3 cases en face de l'ennemi en bas & 2 cases en diag c'est une distance de 2.8 donc en dessous de 3. Mais bon c'est un peu déroutant le gros espace vide si ça ne compte pour 0 cases, si tu veux le prendre en compte, il faut qu'à la différence des X s'ajoute une grosse constante.
Raetribution | Megamike || tutos : 1 2 || TowerClimb cé bien || Rang Master sur TGM3.

Mack - posté le 25/11/2023 à 22:49:25 (2290 messages postés) - ❤ 0
	Oui, pardon, j'ai mis 2 pour le mec, mais ouais, si on compte en diagonale ça fait 2.XX, et sinon 3 cases pour les deux. ( Et évidemment, j'ai aucune foutre idée de comment RM réagi pour savoir quel est le calcul qui est fait ) Comme RM gère pas les float, c'est surement arrondi à 2 au lieu de 2.XX, et 3, d'où le fait que ça cible en haut en prio. Oui, en voyant le résultat c'est aussi ce que je me suis dit, je pense que je vais resserrer le combat ( mais surement laisser une case d'écart entre les grilles pour bien montrer qu'on peut pas aller sur le terrain adverse ), ça sera beaucoup plus lisible, et ça me laissera de la place à droite pour faire une toolbox pour expliquer la compétence.
( Je prend note de tout les commentaires, même si je n'y répond pas )

Roi of the Suisse - posté le 25/11/2023 à 23:30:26 (29836 messages postés) - - ❤ 0
Alerte neige !	Il faudrait que le grand espace entre la zone ennemie et la zone alliée soit compté, ou bien que les deux zones soient collées. Parce que là ce qu’on observe ne correspond pas à la réalité des calculs et c’est déroutant.
L'essentialisme c'est quand ta voiture a un moteur essence. | Es-tu une star ? | Kujira no Hara | Polaris 03 | Planète Glutko

cortez - posté le 27/11/2023 à 18:36:11 (523 messages postés) ❤ 0
	Le souci c'est que sur l'écran le loup du haut est le plus proche de la fille, donc elle devrait pas taper celui du bas. (idem pour le garçon) Je pense que le mieux serait de prendre les coordonnées écrans de chaque ennemi/héro pour effectuer les calculs (pour éviter les soucis de float multiplie chaque valeur par 10 ou 100 histoire d'avoir un chiffre suffisamment préçis)

Mack - posté le 27/11/2023 à 19:00:06 (2290 messages postés) - ❤ 1cortez
	Roi of the Suisse a dit: Il faudrait que le grand espace entre la zone ennemie et la zone alliée soit compté, ou bien que les deux zones soient collées. Parce que là ce qu’on observe ne correspond pas à la réalité des calculs et c’est déroutant. Oui, pour l'instant le grand espace est pas comptabilisé, mais je me suis fait la même réflexion, et je vais changer ça pour qu'il soit beaucoup moins grand, et prendre en compte le petit espace entre les deux grilles ( Comme ça en plus ça me laisserais de la marge à droite pour afficher la toolbox des sorts ) cortez a dit: Le souci c'est que sur l'écran le loup du haut est le plus proche de la fille, donc elle devrait pas taper celui du bas. (idem pour le garçon) Je pense que le mieux serait de prendre les coordonnées écrans de chaque ennemi/héro pour effectuer les calculs (pour éviter les soucis de float multiplie chaque valeur par 10 ou 100 histoire d'avoir un chiffre suffisamment préçis) Effectivement, pour l'instant je me base sur un système de case, partir sur les positions à l'écran peut être une bonne idée, j'vais voir ça EDIT : Donc j'ai resserré un peu, et j'ai essayé de passer par les pixels : Dans les coins, c'est l'ID du mobs Donc, les calculs qui sont fait par RM : 1- 96 2- 131 3- 143 4- 90 Si je fait les calculs "à la main" : 1- 97,04638066 2- 133,6637572 3- 145,361618 4- 93,34880824 ( Avec évidemment un delta, j'ai pas pris exactement le même point que RM, et en plus comme j'ai calculé avec les float, ça sera forcement légèrement différent ) Donc globalement, les calculs sont bon, et ça devrait bien être le monstre en haut qui est ciblé ( 4 ). Mais je sais toujours pas quoi en penser xD Si la seule indication que je donne au joueur, c'est "va cibler le plus proche", vous vous attendez à ce que ça cible qui ? En plus, ça veut dire qu'à partir du moment ou un ennemi est sur la première ligne, un sort qui touchera "au plus près" touchera toujours l'ennemi de la première ligne, même si on est à quelques pixel d'une cible qui "semble plus proche" Et ça ça me parait pas terrible >< ( Evidemment, il reste la solution de toujours afficher la cible avec un curseur, mais j'avoue que j'aimerais avoir une solution qui permette au joueur de jouer sans, même si le curseur sera affichable )
( Je prend note de tout les commentaires, même si je n'y répond pas )

cortez - posté le 27/11/2023 à 21:09:20 (523 messages postés) ❤ 0

hmm ... A moins que tu souhaites garder des cases carrées (visible ou pas), si tu utilise des cases rectangulaires (le plus grand coté parallèle avec le bas de l'écran) cela donnera un effet de perspective pour le placement des ennemis en plus de donner plus d'écart entre les mobs. Cet écart sera suffisant pour que les joueurs voient clairement quel est l'ennemi le plus proche. édit : si les loups occupent les 3 cases de devant ce sera dur de savoir le quel sera touché. Il faudrait pour cela étirer la grille sur un format isométrique (ou presque) Dans cet exemple, le loup du bas est le plus proche (d'environ 5 pixels plus proche que celui du haut) mais en augmentant un peu la distorsion de la grille on peut rendre cela plus net.

Mack - posté le 27/11/2023 à 21:25:21 (2290 messages postés) - ❤ 0
	C'est pas bête ouais J'suis pas fan du rendu, mais en vrai pourquoi pas, faudrait que je regarde Mais dans ce cas, si le loup 3 et la case juste en dessous, ça deviendra lui la cible prio, alors qu'il faudrait que ça reste la cible 1, donc à moins d'avoir une distorsion énorme, ça risque d'être compliqué :/ Une autre solution serait de faire le calcul par case, et de faire une espèce de A*, qui ne permettrais pas de faire de diagonale, mais ça risque d'être bien chiant à faire ( Ou simplement trouver un algo qui permettrais de dire que les calculs en diagonales coute plus cher qu'en ligne / colonne, tout en comptant en pixel et pas en cases, mais encore une fois je sèche )
( Je prend note de tout les commentaires, même si je n'y répond pas )

Tassle - posté le 27/11/2023 à 21:43:26 (5234 messages postés) ❤ 0
Disciple de Pythagolf	T'as pas du tout besoin de faire un truc compliqué pour calculer la distance en cases. Avec tes notations c'est simplement: Portion de code : Tout sélectionner 1 |posX_H - posX_E| + |posY_H - posY_E| (où |x| désigne la valeur absolue de x) D'ailleurs même avec une distance euclidienne ça ne sert à rien de prendre des racines carrées, il suffit de comparer les distances au carré pour ne pas avoir d'erreur d'arrondi. Moi je préfère la distance en cases (a.k.a. distance de Manhattan). Comme ça c'est toujours facile de comparer sans sortir sa règle.
~~

Mack - posté le 27/11/2023 à 22:44:10 (2290 messages postés) - ❤ 0
	Ah oui, merci Tassle, en modifiant un peu comme ça : Portion de code : Tout sélectionner 1 |posX_H - posX_E|*10 + |posY_H - posY_E|*15 + posY_E Je pense que j'ai un truc satisfaisant, ça me donne l'ennemi le plus proche, et si plusieurs sont à distance égale, celui en face ( même Y ), ou sinon celui le plus en haut. J'ai aussi adapté pour le ciblage de l'ennemi en ligne droite, ça donne ça : Portion de code : Tout sélectionner 1 |posX_H - posX_E|*10 + |posY_H - posY_E|*40 + posY_E Ce qui me donne en prio les ennemis en lignes horizontales. Maintenant plus qu'à voir pour faire les ennemis en lignes, mais le plus au fond, je sens que je vais bien rigoler aussi EDIT : En vrai, j'ai l'impression que : Portion de code : Tout sélectionner 1 (2-|posX_H - posX_E|*10) + |posY_H - posY_E|*40 + posY_E Suffirait, puisqu'en fait il suffit "d'inverser" la position X, ce qui fait que l'ennemi le plus à droite aurait une distance plus grande que celui le plus à gauche. ( Tout en gardant la règle sur la ligne, puisque je touche pas la partie des Y ) Si vous avez des idées de ciblage un peu du même genre, je suis preneur, là j'avais pensé à un truc pour cibler les ennemis à mis distance, j'vais essayer de voir si j'arrive à faire un truc
( Je prend note de tout les commentaires, même si je n'y répond pas )

cortez - posté le 01/12/2023 à 17:12:55 (523 messages postés) ❤ 0

Si tu pars sur une stratégie type megaman RPG (avec des choix de cible ligne et colonnes) Tu peux enregistrer la position de chaque monstre dans un tableau et utiliser des fonctions (évènement communs) pour récupérer les slots que tu cible. Si tu as 9 cases du donne les id des ennemis en fonction de leur position (comme sur un pad numérique) 1ère case en haut a gauche = 7 ... 7 8 9 4 5 6 1 2 3 donc var-ennemi1= 7 En fonction des ciblages des héros tu vérifies si les id 9 6 et 3 sont remplis et tu effectue les dmg sur les monstres de cette position. (tu peux aussi prioriser les id de forte/petite valeur pour cibler les ennemis les plus proches) Avec ce système de case avec un id tu peux aussi gérer les ennemis qui ont la bougeote et qui changent de case en cours de combat.

Mack - posté le 01/12/2023 à 17:33:20 (2290 messages postés) - ❤ 0
	En gros c'est l'idée, mais en un peu plus vénère, ça va effectivement respecter des règles comme taper en ligne ou en colonne, mais on ne choisis ni la ligne ni la colonne, donc si je fais des conditions comme ça, il m'en faudra 9 par type de visé, ce qui est vraiment pas terrible
( Je prend note de tout les commentaires, même si je n'y répond pas )

Crystal - posté le 02/12/2023 à 00:02:59 (2098 messages postés) - ❤ 0

J'appuie fortement Tassle, pour favoriser les lignes droites c'est exactement ce que te permettrait la distance de Manhattan, d'autant plus que c'est extrêmement rapide à calculer. Si tu favorises la somme des distances au carré, alors forcément les diagonales pourraient être priorisées, et si, dans ton système de coordonnées actuel, le résultat ne te convient pas, alors c'est qu'il faut inclure le centre de la scène dans la grille (de façon abstraite du moins, en ajoutant la largeur aux coordonnées X des héros). Perso je ne vois vraiment pas comment tu pourrais procéder différemment à moins de compliquer les choses pour revenir à une équivalence des solutions plus simples. Il n'y a aucun intérêt à utiliser du A* dans la mesure où c'est une zone ouverte.

Mack - posté le 04/12/2023 à 18:42:00 (2290 messages postés) - ❤ 0
	Effectivement, au final j'ai ben utilisé la méthode de Tassle, et ça donne ça : ( Evidemment, l'HUD c'est du gros WIP bien crado, mais au moins ça me permettra de vérifier que les gens comprennent à peu près ) Pour l'instant j'ai réellement codé que 3 sorts ( Au plus proche, En ligne, et En ligne ( derrière ) ), mais j'ai fait un google sheet pour faire et visualiser les calculs avant de les mettre en place, donc pour l'instant, j'ai les 3 d'avant, plus un qui cible en prio la frontline, et un la backline. J'pense essayer de faire un truc pour viser la middleline, et peut être les diagonales en prio, puis je m'arrêterais surement là, et j'essayerais d'en faire plus qu'un WIP
( Je prend note de tout les commentaires, même si je n'y répond pas )

Index du forum > Entraide > [RM2k3] Distance entre deux points