gokudomatic a écrit :



c’est bien sympa d’ouvrir les sources, mais il nous faut aussi la doc. Par exemple, j’ai regardé un peu et j’arrive pas à savoir où se trouvent les fichiers concernant l’IA.





IA et Serious Sam, sérieux ?

Tu es d’humeur joueur aujourd’hui.





cadeau voici le code :

while (!me.active) {

me.active = me.isSeriousSamVisible()

}

while (! me.isDead())

if me.inAmmoRange(seriousSam) {

shoot(me.direction(seriousSam))

}else{

me.moveTo(seriousSam)

}



“HAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA!!! ”

Beheaded Kamikaze - Serious Sam

Du A comme dans “AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA !!” ?

Pour la 2D, c’est un faux problème, a la fois parce que pour la plupart des mob, il ne se déplace que sur le sol donc si l’on ne considère qu’il n’y a qu’un seul plan par axe de hauteur, ça s’applique sans réfléchir plus que ça, et même si il y a plusieurs plan, en faite, ça ne change pas tant que ça (tu adapte ça à un mesh plus qu’à un quadrillage simple). Et dans enfin, même si c’est en 3D, l’algo fonctionne quand même, il est générique et n’est pas dépendant de ce genre de problème, il fonctionne même en 4 dimension.



As-tu vraiment jouer à Serious Sam, l’IA est un copié collé de celle de Doom, elle est même moi développée, dans Doom elle devait choisir une cible qui pouvait être autre chose que le joueur. C’est pas pour rien que la déplacement de base c’est le strap sur le coté en tournant.

Je ne sais pas trop. Je ne suis pas sûr.



Mais voilà comme je vois les choses (dans la façon simple, mais ça peut être rafiné). Tout d’abord tu places les noeud de ton graph, ceux-ci sont tous les bords d’objet infranchissable(coins des murs…) le mob et le joueur. Maintenant, de ces noeud, tu place un arc entre chaque nœud qui est possible de passer directement (sans croiser donc un mur infranchissable).

Maintenant, tu applique la première partie de l’algo de l’A* avec une distance euclidienne en 3D en partant du joueur sur tout les nœuds. Il ne te reste plus qu’à appliquer le reste en considérant le graph que tu as construit (Dijkstra s’applique aussi, mais il est un peu lourd).



Tu peux gagner du temps en précalculant les noeuds, les arcs et leur poids associés au terrain. A voir si c’est intéressant, mais tu peux aussi limiter la taille des arc et mettre des nœud intermédiaires (ça peut peut-être simplifier le calcule dans le cas d’un A* je pense), tu peux encore plus affiner ce dernier point en considérant que les arcs associé au joueur ne sont, eux, pas compressibles (quelque soit la distance, l’arc d’un noeud vers le joueur existe dès qu’il est possible). Ensuite, et ça je pense que c’est fait dans plein de jeu, tu limites la recherche de chemin, si au bout d’un certain temps il ne trouve rien, tu arrêtes la recherche et tu fais déplacer ton mob par le chemin qui a donner le meilleur résultat, ça permet de ne pas se bloquer quand le chemin est trop complexe ou inexistant (on vois par exemple dans SS les mob qui se colle sur le mur en contrebas lorsqu’ils n’arrives pas a t’atteindre).

Sinon, toujours dans les nœuds et les arc, tu peux aussi avoir différent niveau de granularité, avec par exemple un niveau “global” qui ne considère que les “portes” (l’entrée d’un pont par exemple) des pièces comme des noeuds et des chemin prédéfini d’une porte à une autre dans la même pièce.



Bon, le pathfinding dans les jeu vidéo, c’est une problématique récurrente. Ce que je te donne là, c’est ce que je ferais personnellement sans documentation.

Mais un ravin, ça doit être considéré par l’IA comme un mur infranchissable ? Godot doit bien avoir l’équivalent d’un mur pour l’IA qui n’est pas un mur pour le moteur physique, non ?



Sinon, pour le cas des grandes plaines, j’essayerais un peu l’équivalent de la tesselation autour du joueur pour les noeud (affine le chemin sur des distance proche, donner des chemin tenant compte d’un modèle très grossier du terrain sur des distance lointaine quite à passer à 4m du ravin on s’en fout).







Le développement de jeu, je ne connais pas du tout. Une IA doit-elle absolument être aussi régulièrement mise à jour ? Ne peut-elle pas juste décider dans combien de temps il faut qu’elle mettent à jour son comportement en fonction de différent critère comme la distance du joueur, son état d’alerte… ?

gokudomatic a écrit :



C’est possible. J’ai créé de tels murs pour faire des tests (je voulais qu’ils restent confinés dans une région). Mais je n’ai pas envie de devoir implémenter dans le level design des murs pour tous les trous. C’est source de problèmes sans fin. Les monstres qui volent ne doivent pas être bloqués par le mur. Ils doivent aussi pouvoir aller sur une plateforme mobile, mais seulement quand elle est présente. Que d’exceptions à gérer.







Hum… L’exception ici, c’est plutôt les monstre volant, et eux doivent justement ignorer les murs “de ravin”. Mais sinon, oui, effectivement, je vois un peu le problème des plateformes mobiles. Cela demande de rendre le mur “de ravin” franchissable lorsqu’il ne représente qu’une certain épaisseur , ça doit être possible de faire ça, mais long.







gokudomatic a écrit :



L’optimisation est indéniablement primordiale. Chaque opération économisée quand c’est acceptable est intéressante. Donc c’est vrai que certaines tâches lourdes, tel que le calcul de trajectoire, ne se font que toutes les x secondes. Mais l’IA doit de toutes façons constamment recalculer sa vitesse et faire le déplacement à proprement dit, incluant les glissement contre les murs en cas de collision.

Mais ceci mis à part, dans godot et contrairement à la majorité des moteurs de jeux, il y a des objets fournis par le framework qui font leur petite cuisine à chaque frame. Vu que c’est compilé en C, c’est le plus performant, mais ça peut vite devenir un piège à débutant en terme de performance. Les senseurs dont je parlais en sont un exemple. Un seul senseur est très performant pour détecter s’il y a collision, mais 500 le sont nettement moins. Et malheureusement, dans mon algorithme j’ai besoin que tous les senseurs soient actif pour réagir rapidement à la présence d’un trou. Car tomber ne serait-ce qu’une seule fois n’est pas acceptable.





Je considère que le gain dû au langage n’est pas une source d’optimisation fiable. Le gain en effet n’est qu’un simple facteur multiplicatif qui est ridicule à coté de la loi de moore qui est exponentielle. Ce que tu fait un C aujourd’hui sera possible dans quelques années avec un langage de script. Le vrai gain de performance est effectivement plus dans l’algorithme qu’il faut le chercher.

C’est effectivement un problème. Mais j’ai du mal à voir ce qui différencie finalement ce problème à celui du moteur de collision qui lui fonctionne très bien. J’ai toujours l’impression d’avoir juste un cas particulier de mur dont son existence est “conditionnelle”.