enum build in en paramêtre de fonctions + pathfinding :)

Coucou,
imaginons que je veuille hacker la fonction Walk d'AGS pour en recoder une. Puis-je utiliser les enums de type BlockingStyle et WalkWhere en paramêtre de ma nouvelle fonction ? Si oui, comment ? Comme ça ?

Code:

function U8D_Walk(int x, int y, enum BlockingStyle = eBlock, enum WalkWhere = eWalkableAreas) {
  if (x - player.x >= y -player.y) {
    if (WalkWhere = eWalkableAreas) {
      if (GetWalkableAreaAt(x, y-x) != 0){
        if (BlockingStyle = eBlock) {
         
          player.Walk(x, y-x , eBlock);
          player.Walk(x, y, eBlock);
        }
      }
    }
 
  }
  else {
   
  }
}

Merci !

Salut Billbis,

Aucun soucis pour utiliser des types prédéfinis, mais justement, ce sont des types, pas des variables. Donc pas besoin de les faire précéder de enum dans ta liste de paramètre : ce faisant, tu déclares deux types successifs à ton paramètre.

Là dans ton code, tu déclares deux paramètres de type enum, l'un dont le nom est BlockingStyle et l'autre dont le nom est WalkWhere.
Ce que tu veux c'est plutôt que le type de la première variable soit BlockingStyle et que le type de la seconde variable soit WalkWhere.

Du coup tu fais comme ça :

Code:

function U8D_Walk(int x, int y, BlockingStyle blocage, WalkWhere zonesEmpruntables) {
  if (x - player.x >= y -player.y) {
    if (zonesEmpruntables = eWalkableAreas) {
      if (GetWalkableAreaAt(x, y-x) != 0){
        if (blocage = eBlock) {
       
          player.Walk(x, y-x , eBlock);
          player.Walk(x, y, eBlock);
        }
      }
    }
 
  }
  else {
 
  }
}

Je n'ai pas mis de valeur par défaut pour tes paramètres (eBlock et eWalkableAreas) puisque cela se fait uniquement dans la déclaration d'importation de la fonction, si je ne m'abuse.

Je vois sinon que tu te penches sur le problème de valoulef, j'ai dans l'idée de me pencher moi aussi dessus, on pourra comparer nos solutions

Merci beaucoup Kitai !

Kitai a écrit:

Je vois sinon que tu te penches sur le problème de valoulef, j'ai dans l'idée de me pencher moi aussi dessus, on pourra comparer nos solutions.

En effet, tu as bien deviné mes intentions ! En revanche, tu as vu l'intégralité de mon script pour l'instant
Je suis encore loin de pouvoir proposer quelque chose, donc. Mais en tout cas tu m'as sacrément débloqué !

Franchement les gars, vous êtes géniaux !

Je vais essayer de comprendre en détails vos codes, ça ne peut que me faire grandement progresser dans mon apprentissage du langage d'AGS, et puis si jamais je peux apporter ma pierre à l'édifice, comptez sur moi !

Alors ne pouvant pas tester pour l'instant le module dans de bonne conditions, je me suis amusé à faire un peu de théorie.

Sur le topic de ton module, tu détermine deux points intermédiaire pour un déplacement "ne pouvant pas" se faire en ligne droite. C'est déjà très bien, mais comme tu le remarque, si ces deux points sont inaccessibles, on est obligé d'abandonner le principe. On est bien d'accord, ce qui suit est de la théorie, je serais bien incapable d'appliquer ça en formules ou en script, il s'agit juste d'imaginer la solution hypothétique idéale. Après comme vous vous êtes déjà penché sur la question, vous avez peut-être déjà tout ça en tête, mais j'aime bien mettre les choses noir sur blanc (en l'occurrence blanc sur bleu-nuit !) pour y voir plus clair.

Me basant sur le même principe que ton schéma, j'ai dessiné une liste non exhaustive de trajectoires possibles n'ayant qu'un seul point intermédiaire (à la base je pensais faire une liste exhaustive mais il y a en fait une multitude de possibilités, dont beaucoup très improbables voire obsolètes) :

Chacun des points permet donc de passer du point A au point B en une seule bifurcation. En admettant que le script permette de calculer chacun de ses points, il faudrait ensuite qu'il détermine un ordre de priorité du trajet le plus court à celui le plus long. Ici, la solution préférable serait P1 ou P2, puis P3 ou P5, et enfin P4 ou P6.

Maintenant, compliquons un peu les choses (parce que je suis sûr que vous trouvez ça trop simple ) :


En gris, notre Walkable Area. En rouge, sur le P1, un obstacle (qui au passage ne peut-être qu'un personnage si je ne m'abuse).  Le programme calcule d'abord les hypothétiques points intermédiaires (avec toujours 1 seul point par trajet potentiel) sans tenir compte ni des Walkable Area, ni des obstacles. Une fois les points déterminés, il vérifie lesquels se trouvent sur une Walkable Area. Il trouve uniquement P1. Puis il vérifie s'il y a des obstacles sur les trajets restants. Ici il n'y a qu'un trajet, avec un obstacle. Il n'y a donc aucun point réunissant les deux conditions. Qu'à cela ne tienne, le programme choisit P1 comme point le plus pertinent.

Admettons donc que notre personnage commence à se déplacer vers P1. Il est obligé de s'arrêter devant l'obstacle, mais il s'est déjà approché de son objectif. A partir de là on reprend tout de zéro, et de nouveaux points sont déterminés. Cette fois, on élimine les points qui nous obligent à passer par cet obstacle, vu que cet obstacle nous bloque immédiatement. Le point "direct" le plus pertinent se trouve proche de P2 sur le schéma. Il est en dehors d'un Walkable Area, mais on n'a pas d'autre choix possible. Le trajet du personnage suit la deuxième flèche jaune. Arrivé à la limite de la walkable area, le nouveau calcul nous donne un point "idéal", situé entre la 3ème et la 4ème flèche jaune. Il n'y a plus qu'à passer par là et le tour est jouer.


Quoi ? Ma théorie est déjà incodable ? Pourtant, on "peut" encore faire mieux. Voici le trajet le mieux optimisé à mon avis :


Le programme choisit toujours P1 comme direction à prendre. Mais cette fois, il anticipe sur l'obstacle. Comme le trajet vers P1 va être forcément interrompu, le programme continue de calculer des points de passage en temps réel (ou à l'avance, en prenant comme référence chaque coordonnée X situé entre le point A et l'obstacle). Dès qu'il en trouve un qui se situe dans une walkable area et qui n'a aucun obstacle sur sa trajectoire, il le choisit. Le personnage bifurque alors (deuxième flèche rose) va jusqu'à ce point et se rend au point B (3ème flèche rose).



J'aurais peut-être pu en venir à cette solution plus tôt, mais je raisonne un peu en même temps que j'écris. Bref, récapitulons les grandes étapes :

- Le programme calcule un certains nombre de points, un par trajet potentiel "direct" (c'est à dire qui ne bifurque qu'une fois). Si un ou plusieurs de ces points sont accessibles, il choisit le plus pertinent, et le personnage s'y rend. De là, le personnage se rend au point B.

Si aucun de ses points n'est accessible :
- Le programme choisit malgré tout le point le plus pertinent.
- Il répertorie toutes les coordonnées x (selon l'exemple, parce qu'on est à l'horizontale) situées entre le point A et l'endroit où on ne peut plus avancer (obstacle ou WA).
- Pour chacune de ces coordonnées, il recalcule des points comme si le personnage s'y trouvait (si on nomme A', un point situé entre A et l'obstacle, alors on recalcule à partir de A'.x, A.y).
- Dès qu'il trouve un point accessible à partir de là, il l'enregistre. Appelons le P'1.
- Le personnage suit alors le trajet suivant : A - A' - P'1 - B (j'ajoute ces points sur mon schéma pour plus de clareté).



Voilà, c'est une piste très théorique (et sûrement très perfectible) pour pallier aux limites de ton module, même si celui-ci, s'il fonctionne, doit déjà être très satisfaisant.
C'est beaucoup de complications pour pas grand chose, mais c'est assez intéressant de se pencher sur la question et mine de rien ça pourrait grandement améliorer le réalisme des déplacements dans certains jeux. Après, ça serait sûrement un travail de titan à coder, à vrai dire je ne me rends pas bien compte... je suis en tout cas curieux de connaître votre avis sur tout ça.

Désolé pour l'énorme pavé, peut-être pour pas grand chose, mais en tout cas j'aurais au moins essayé de proposer des pistes (faute de mieux pour l'instant ).

On est complétement hors sujet là. Mais comme on est plus modéré, allons y gaiment !

Post intéressant. je vais essayer de répondre de façon intelligible, mais je ne garantie rien.

Tout d'abord, je vais commencer par me citer:

Billbis a écrit:

Pour le nom, j'ai hésité avec Pinap (pour Pinap Is Not A Pathfinder) ou encore Onepup (pour Onepu N'Est Pas Un Pathfinder) mais finalement, je suis resté sur Use 8 Directions (U8D).

Mon module n'est donc pas un algorithme de pathfinding, c'est juste un petit bout de code vite pondu et assez sale qui ne répond que moyennement au problème donné.

Mais ça n’empêche pas de parler théorie du pathfinding.

Comme tes explications le montre bien, faire un vrai algorithme de pathfinding est quelque chose de très complexe. A tel point que fréquemment, des équipes professionnelles se plantent encore lamentablement et nous pondent des pathfinding incohérents dans nos jeux commerciaux préférés (au hasard, les pnj de skyrim...).

D'ailleurs, le pathfinding d'AGS est relativement lourd en temps de calcul. C'est lui qui est responsable des fort ralentissements qu'on peut rencontrer dans les très grandes rooms scrollables.

Technocrat a écrit:

The common complaint is that when the room gets too large, the game slows down dramatically, and this has been blamed in the other threads on the pathfinding system.

(ici)

Donc si je devais me lancer, moi je partirai direct sur une grille de points :


L'espace entre les points dépend du rapport précision/rapidité du calcul qu'on veut atteindre. Plus c'est granuleux, plus ce sera rapide, moins ce sera précis.

Ensuite, il faut détecter quels sont les points qui tombent dans un walkable area et ceux en dehors qu'on annulera. On peut le faire en direct (lourd), à l'entrée dans la room (compliqué à mettre en place car toute les walkeable areas ne sont pas forcément activées à ce moment là...) ou à la compilation (mais là, il faut recoder AGS...).

Le second problème arrive lorsqu'il faut récupérer la zone de blocage des personnages et objets bloquant (car oui, les objets peuvent être bloquant aussi...). Là, il faut le faire en direct (les personnages et les objets peuvent se déplacer), et il faut même le faire régulièrement pendant le mouvement, si jamais les objets et personnages se déplacent en même tant que notre cible. Tant qu'on y est, on peut même anticiper le mouvement des objets et personnages en déplaçement, mais là c'est histoire de peaufiner là chose.

Une fois qu'on a notre matrice de point accessibles, il nous reste à trouver le point sur lequel est le personnage, et le point le plus proche de la destination (voulu par le joueur, ou entré en paramètre de la fonction walk par le concepteur).

Puis il faut trouver le chemin le plus court entre les deux points, en passant par les lignes que j'ai dessiné.
Ce n'est jamais qu'un problème NP complet... Mais nos GPS y arrivent bien, alors bon...

Et comme je l'ai dit, réactualiser le trajet régulièrement pour prendre en compte les déplacements des autres personnages et objets.

Bien sur, notre algorythme soit être parfaitement débuggé et logique, pour ne pas irriter le joueur avec des blocages et autres pathfinding incohérents. Et aussi être rapide pour ne pas ralentir le jeu.

Tu comprends bien que je n'ai que moyennement envie de me lancer dans une telle tâche !

AGS fonctionne un peu comme je l'ai écrit, avec une grille de 3x3 :
D'après khris :

Khris a écrit:

I think it's save for me to divulge that AGS uses a grid of 3x3 squares, improving the performance to 900% compared to a single pixel grid.
That's why walkable areas (and non-walkable areas) have to be at least three pixels wide.
(At least this is what I believe is being done, mind you.)

(ici)

Sinon, pour info, de célèbres algorythmes de pathfinding existent déjà,
-le A*
-sa variante Djikstra, utilisé par AGS (scource)

Pour revenir sur tes suggestions, passer par P3 et P5 si P1 et P2 sont indisponibles, pourquoi pas (après tout, ça ne fait que doubler la longueur du script de mon module !), mais P4 et P6 vont faire trop bizarre, donc non.
Cela dit, si P1 et P2 sont pris, il y a de forte chance que P3 et P5 le soient aussi, donc autant faire confiance à AGS pour les situations problématiques.

Oulala déjà que je m'arrache les cheveux comme un malade à déterminer quelques simples équations (oui j'ai fait L, ça peut compliquer les choses...) que tu avais d'ailleurs déterminé toi même en deux temps trois mouvements (mais je n'ai pas encore tout compris à ton script), maintenant je vois que j'avais pas prévu la moitié des choses à prévoir... !

Billbis a écrit:

On est complétement hors sujet là. Mais comme on est plus modéré, allons y gaiment !

Oui c'est de ma faute, j'aurais pu poster sur le topic du module mais je ne voulais pas le "polluer", alors j'ai posté ici même si je reconnais que ce n'était pas idéal.

Billbis a écrit:

Tu comprends bien que je n'ai que moyennement envie de me lancer dans une telle tâche !

Certes, loin de moi l'idée de te demander ça, d'autant que tu t'es déjà bien donné ! Comme je l'ai déjà plus ou moins dit, je chipote pour essayer de trouver la solution parfaite (pas tellement pour moi, c'est plus pour l'idée) mais ton module permet doit déjà permettre de régler en partie le problème. D'ailleurs je crois que je ne me serais même pas penché plus profondément sur la question si tu ne l'avais pas fait avant moi.

Cela dit, sans pour autant atteindre la perfection, ça me paraît jouable (en se basant sur le principe de ton module) de trouver des alternatives aux points situés en dehors des walkable areas. Car c'est bien celles-ci qui poseraient problème pour l'extrême majorité des cas. Je vais donc quand même essayer d'y réfléchir encore un peu, quitte à me rendre compte que je me plante complètement ! Mais bon c'est histoire de.

Billbis a écrit:

Pour revenir sur tes suggestions, passer par P3 et P5 si P1 et P2 sont indisponibles, pourquoi pas (après tout, ça ne fait que doubler la longueur du script de mon module !), mais P4 et P6 vont faire trop bizarre, donc non.
Cela dit, si P1 et P2 sont pris, il y a de forte chance que P3 et P5 le soient aussi, donc autant faire confiance à AGS pour les situations problématiques.

Mes points sont assez arbitraires, les points essentiels restent effectivement P1 et P2, mais les autres peuvent être utile dans le cas ou la walkable area aurait une forme de "U" qui passe par le point A et le point B, par exemple. Pour le coup, j'imagine qu'AGS gère ça de lui même, mais toujours sans tenir compte des 8 directions. Après c'est pas le plus important, j'en conviens.


Bon pour en venir à mes équations, si tu pouvais me dire mathématiquement par quel calcul tu obtiens les points P1 et P2, ça m'intéresse. J'ai bien des éléments de réponse, mais j'ai t'endance à m'embrouiller . Je crois que j'ai vu ça en seconde (ou au collège je sais plus), mais c'est pas ce qui m'est le plus resté de mes cours de maths !

Valoulef a écrit:

Bon pour en venir à mes équations, si tu pouvais me dire mathématiquement par quel calcul tu obtiens les points P1 et P2, ça m'intéresse. J'ai bien des éléments de réponse, mais j'ai t'endance à m'embrouiller .

Ha oui, cette partie là...
C'est à cause de ça que j'ai écrit:

Billbis a écrit:

et par Pidem pour la partie théorique.

Billbis a écrit:

De toute façon, il est fortement déconseillé de comprendre le code de ce module sous peine d'attraper un sérieux mal de tête.

Billbis a écrit:

Script is barely inteligible. Do not try to understand the relations between x, player.x, xbis and PlusOuMoins unless riscking heavy headache.

Donc je t'expliquerai tout ça demain.
Mais en gros, P1 c'est (x,y):
(x+ybis*PlusOuMoins, this.y )
avec ybis = U8D_Abs(y - this.y);
et PlusOuMoins = (this.x - x) / U8D_Abs(this.x - x);

this étant le personnage en question, U8D_Abs retourne la valeur absolue de l'int rentré.

Prépare la réserve d'aspirine !

Préambule :
Ce module est MAL codé. Il a été pondu par un débutant amateur. Il est déconseillé de le prendre comme un standard non critiquable et non améliorable.
Le code du module sera modifié dans les versions suivantes, ce qui suis pourra donc ne plus être identique au code définitif.
Cela dit, les principes mathématiques exposés resteront vrais pendant encore une petite éternité.


Partie 1 : les subdivisions du codes indépendantes des coordonnées.
Le code de la fonction U8D_Walk est divisés en plein de fragments selon les conditions remplies. Parmis elles, il y a la bifurcation correspondant au paramètre WalkWhere. Soit la fonction tient compte des WA (walkeable area), soit elle n'en tient pas compte.
Il s'agit des lignes de types :

Code:

if (zonesEmpruntables == eWalkableAreas)

Soit les lignes 22, 47, 60 et 85.
L'autre bifurcation du code tient compte du paramètre WalkWhere.
On la retrouve à de nombreuses reprises sous la forme :

Code:

if (blocage == eBlock) {

Si on est en eBlock, tout ce passe dans la fonction. Si on est en eNoBlock, la deuxième partie du mouvement se fait dans le repeatedly_execute() un peu en dessous.
Tout ceci n'est donc que de la cuisine interne à AGS, relativement classique et à faible potentiel d'induction de céphalées aigües, contrairement aux parties suivantes.

Partie 2 : coordonnées et le début de la migraine.
Commençons par définir nos coordonnées et nos notations.

Code:

function U8D_Walk(this Character*, int x, int y, BlockingStyle blocage, WalkWhere zonesEmpruntables) {

La destination finale est entrée en paramètre de la fonction walk sous la forme d'une coordonnée x est d'une coordonnée y qui s'appellent respectivement x et y, ou encore (x,y).

Code:

function U8D_Walk(this Character*, int x, int y, BlockingStyle blocage, WalkWhere zonesEmpruntables) {

Le premier paramètre de la fonction est le personnage spécifiée. Il s'appelle dans la suite du code this. (cette notation permet de passer ce paramètre sous la forme cEgo.U8D_walk(x,y) plutôt que sous la forme U8D_walk( cEgo, x, y) ).
Les coordonnées du personnage this au début du mouvement peuvent être obtenu via this.x et this.y. J'utiliserai par commodité ces appellations dans le futur.
Ces coordonnées s'applique dans un référentielle (origine, direction, taille de l'unité) imposé par AGS, et qui est définit comme suit :
L’origine (0,0) correspond au coin supérieure gauche de la room (et non de l'écran).
x va de gauche à droite et y de haut en bas. Notre unité vaux ici 1 pixel (et c'est bien pratique). Les coordonnées (x,y) sont donc des int, essentiellement positif.
En résumé (le départ A, et l'arrivée B) :


Partie 3 : Où l'on commence à ne plus comprendre
Abordons maintenant le problème à bras le corps. Nous voulons trouver les coordonnées d'un point intermédiaire P1 entre A et B qui permette à notre personnage de ce déplacer horizontalement, verticalement, ou selon les quatre diagonales ("à 45°").
Trois cas de figures se présentent à nous :
-1) soit on a eu de la chance : le personnage et sa destination sont déjà sur la même horizontale, sur la même verticale ou sur la même diagonale. Il s'agit de cas triviaux pour lesquels le module ne sert à rien et qui sont traités de façons transparente par ce dernier. P1 est dans ces cas de figures confondu soit avec le point de départ, soit avec le point d'arrivé.
-2) soit il faut combiner une verticale et une diagonale pour arriver à l'arrivée.
-3) soit il faut combiner une horizontale et une diagonale pour arriver à l'arrivée.
Le cas 2 à lieux lorsque la distance verticale séparant le point A du point B est plus grande que la distance horizontale (et le cas 3 dans la situations inverse).

Comment mesurer la distance horizontale AB et la distance verticale AB, appelés pour l'occasion xbis et ybis ?

Et bien, de manière intuitive :
xbis = x - this.x
ybis = this.y - y
En pratique, en fonction des positions relatives de nos deux points, on passera par la valeur absolue de x - this.x et y-this.y.
La valeur absolue correspond à la grandeur positive de notre valeur. C'est une fonction très utilisé en mathématique, mais curieusement absente d'AGS. Je l'ai donc rapidement recodé U8D_Abs.

Code:

function U8D_Abs(int x) { // Retourne la valeure absolue
  if (x >= 0) return x;
  else return -x;
}

Et nos distances sont calculé lignes 18 et 19.

Code:

int xbis = U8D_Abs(x - this.x);
int ybis = U8D_Abs(y - this.y);

Nos deux cas n°2 et n°3 sont pour l'instant traités à deux endroits différents de la fonction, ligne 20 et 58.

Code:

  if (U8D_Abs(x - this.x) >= U8D_Abs(y - this.y))

A noté que j'aurais pu / du écrire :

Code:

  if (xbis >= ybis)

Partie 4 : l'heure du choix

Une fois qu'on sait qu'il faut faire une horizontale et une diagonale, il faut encore choisir si on commence par l'horizontale, ou si on commence par la diagonale. Moi, j'ai choisit les chemins de gauche d'abord, et de droites sinon:

donc d'abord horizontale pour (horizontale + diagonale) et d'abord diagonale pour (verticale + diagonale). Je trouvais ça plus esthétique, mais après je peu me tromper.

A noter qu'il aurait sans doute été plus logique et cohérent de partir plutôt sur ce genre de choix :


Partie 5 : Prendre le problème par le bon bout de la raison.

Comment donc obtenir les coordonnées du Point P1 losqu'on veux aller en B1,B2,B3 ou B4 ?

La coordonnée Y de notre point P1 est facile à trouver, elle vaut this.y !

Pour la coordonnée X, réponse en image :

Une diagonale à 45° trace donc un triangle isocèle rectangle dont le côté horizontale mesure la même distance que le côté verticale. Magie du Triangle Isocèle Rectangle.
La coordonnée X de P1 vaut donc x - ybis pour le point d'arrivée B1 et B2.
Pour le points B3 et B4, je vous laisse refaire un petit schéma :

Vous devriez trouver :
x + ybis

Il y a une petite astuce pour savoir lorsqu'on doit ajouter ybis ou plutôt le retrancher.
C'est la qu'intervient la variable PlusOuMoins (astuce de Pidem), qui vaut +1 ou -1 !
Elle est définit comme ça (ligne 21):

Code:

  int PlusOuMoins = (this.x - x) / U8D_Abs(this.x - x);

Si B est a droite de A, alors this.x - x est négatif, et PlusOuMoins vaut -1, donc
x + ybis*PlusOuMoins = x - ybis

Si B est a gauche de A, alors this.x - x est positif, et PlusOuMoins vaut +1, donc
x + ybis*PlusOuMoins = x + ybis

D'où la magnifique mais incompréhensible ligne 25 :

Code:

this.Walk(x+ybis*PlusOuMoins, this.y , eBlock, eWalkableAreas);

Je vous laisse comprendre le principe de diagonnale + verticale comme des grand.

C'est tout pour aujourd'hui !

Exercice d'application
On a réussit à trouver une unique équation pour quand A était à gauche ou à droite de B.
Essayer de trouver une Unique équation pour les gouverner tous et dans les ténébres les lier qui calcul nos coordonnées de P1 quelques soit les tailles relative xbis et ybis (ou donc qui regroupe les cas horizontale + diagonale et verticale + diagonale)
Je ramasse les copies dans une boite de dolipranne 500 !


C'est ce que je vais faire pour la version béta 0.2 du module histoire d'éclaircir (ou d'obfuscer ?) mon code un peu plus.
Deux pistes au choix, soit partir sur les priorité P1 P2 suivantes :

Soit garder nos priorités déjà spécifiés et faire intervenir une variable ZeroOuUn, qui vaudra... 0 ou 1 !

Oh my god ! Tu assures, par contre tu m'excuseras si je ne lis pas tout ça ce soir ?

Bien évidement. Tu n'es même pas obligé de lire du tout. Je l'ai écrit plus pour l'exercice de style.

Billbis a écrit:

Partie 3: Où l'on commence à ne plus comprendre

Ça, ça me plait ! Au moins une référence que j'aurais comprise, justement

Billbis a écrit:

Partie 5 : Prendre le problème par le bon bout de la raison.

Idem Sais-tu que Le mystère de la chambre jaune est un des éléments qui m'ont inspiré L'affaire Aspirox (même si ça ne se verra pas ou peu) ?



EDIT : Bon ben finalement j'ai tout lu... et (à peu près tout compris !). Mais c'est dû aux 5 heures que j'ai passé hier à essayer à faire ces équations. Sauf que je me suis un peu compliqué la vie avec toutes les situations et j'arrivais à 10 points par situations dont il fallait établir l'ordre etc etc mais j'étais à deux doigts de tout trouver ! Il me manquait surtout la notion "PlusOuMoins" mais je m'en approchais quand j'ai commençais à voir l'écran de mon ordi se déformer sous les yeux avec une brutale envie de vomir (véridique).

Billbis a écrit:

Exercice d'application
On a réussit à trouver une unique équation pour quand A était à gauche ou à droite de B.
Essayer de trouver une Unique équation pour les gouverner tous et dans les ténébres les lier qui calcul nos coordonnées de P1 quelques soit les tailles relative xbis et ybis (ou donc qui regroupe les cas horizontale + diagonale et verticale + diagonale)
Je ramasse les copies dans une boite de dolipranne 500 !

C'est plus ou moins (sans jeu de mot) ce que j'essayais de faire. Mais du coup, j'en vois pas trop l'intérêt, puisque ça marche dans ton code. Enfin je veux bien essayer, c'est rigolo quand l'écran de mon ordi se déforme

Citation :

Idem sourire Sais-tu que Le mystère de la chambre jaune est un des éléments qui m'ont inspiré L'affaire Aspirox (même si ça ne se verra pas ou peu) ?

Chouette ! Ce jeux à de belles sources d'inspiration dit dont. Dommage que ma tentative de te soutirer une image sur ce sujet n'a pas fonctionné.

Pour l'exercice, ne t’embête pas avec ça, je m'en occupe.

Billbis a écrit:

Chouette ! Ce jeux à de belles sources d'inspiration dit dont.

Cela dit* ne t'attends pas à ce que le jeu rappelle le livre. Ils n'ont rien à voir. Cela dit* je vais essayer de glisser une ou deux références quand même. J'avais pensé à m'inspirer du vrai nom de rouletabille (joseph josephin) pour le personnage mais bon j'ai rien trouvé de bien.

Billbis a écrit:

Dommage que ma tentative de te soutirer une image sur ce sujet n'a pas fonctionné.

Ah oui héhé, mais bon la rom en question n'est pas complètement terminée. Je ne vous en montrerai pas trop parce qu'il n'y en a pas beaucoup et je veux que la majorité du jeu soit découverte en jouant. Celle là c'est la première, donc je vous la montrerai sûrement. Enfin dans l'idée ça ressemble au croquis que j'ai posté (mais en propre).

Billbis a écrit:

Pour l'exercice, ne t’embête pas avec ça, je m'en occupe.

Ah oui j'avais oublié ça. Mais en fait l'équation "unique" est déjà dans ta fonction. Je me rappelle plus exactement et je t'avoue que j'ai la flemme de tout retrouver mais en gros si tu remplace "plusoumoins" par ce que ça signifie mathématiquement (donc this.x - x / this x - x je crois), ça donne ton équation, non ? Donc ça reviendrait au même... Ou alors j'ai rien compris


*EDIT : Je dis beaucoup trop "cela dit"

Juste pour informer que la solution de recoder un pathfinding me semble au final beaucoup trop coûteuse : ça prend un temps fou pour calculer le chemin lorsque la zone de déplacement forme une virgule. Chose assez bizarre parce que AGS est censé exécuter le code assez rapidement, et l'algorithme A* que j'utilise est censé lui aussi être plutôt rapide. Bref, tant pis pour cette solution, et puis Billbis a codé un beau module qui fait l'affaire