RSS FeedPathing des portes et ascenseurs
Portes et ascenseurs sont les deux principaux types de movers ayant une influence sur le bot pathing d'un niveau car ils affectent la morphologie de la map elle-même. Une porte empêche le passage lorsqu'elle est fermée et le permet lorsqu'elle est ouverte. Un ascenseur déplace physiquement le joueur et nécessite donc que le bot sache où le prendre, où en sortir et où se tenir pendant le trajet. Aucun de ces comportements n'est géré naturellement par l'intelligence artificielle et il faut donc lui indiquer comment fonctionnent ces movers.
Les actors nécessaires sont tous sous le NavigationPoint. Il s'agit de Door, LiftCenter et LiftExit.
Comme leurs noms l'indiquent, le Door permet de gérer les portes et les LiftCenter et LiftExit les ascenseurs (mais aussi plus largement tous les movers sur lesquels le bot doit monter).
Portes
Par défaut, lorsqu'une porte est placée dans votre niveau, le bot n'a aucun moyen de savoir qu'il ne s'agit pas d'un obstacle fixe qui bloque son chemin de manière définitive. En conséquence, les portes, comme tous les autres movers, sont considérés lors du rebuild comme infranchissables et le réseau de navigation ne les traverse pas. Même une fois la porte ouverte dans le jeu, les chemins étant pré-calculés par rapport à sa position initiale, généralement fermée, le bot ne tentera jamais de l'emprunter. Si la porte est par défaut ouverte, le bot ne considérera jamais qu'elle est fermée et tentera de passer même si elle se ferme devant lui. Il se bloquera alors dans la géométrie du mover et réessayera indéfiniment de passer.
L'actor spécifique Door permet aux bots de comprendre le fonctionnement des portes (et plus généralement de tout mover qui obstrue un passage en position fermée). Il se place généralement dans la porte ou à proximité immédiate et permet de créer un chemin à travers le mover, mais aussi d'indiquer au bot de quelle manière l'ouvrir.
Si les portes sont étonnamment rares dans UT2004, la map DM-Flux2 en comprend plusieurs, ce qui permet de comprendre le fonctionnement de cet actor. Chaque porte y est activée par un Trigger qui se trouve dans l'épaisseur du mover, qui s'ouvre donc lorsqu'un joueur s'approche. Le Door se trouve également dans la porte et permet de créer un chemin entre les deux côtés.
Le paramètre principal du Door est DoorTag, qui doit contenir le tag du mover lui-même (ou d'un des movers si la porte est constituée de plusieurs parties). Il suffit à indiquer au bot qu'il peut passer à travers le mover lié. Lors du rebuild, le door est utilisé comme un jalon qui "voit" à travers les movers et peut donc relier les points de navigation des deux côtés.
Si le Trigger occupe la même position que le Door et que le mover réagit à la proximité immédiate du joueur (comme dans Flux2), remplir correctement le DoorTag suffit pour que l'IA ne considère pas la porte comme un obstacle inamovible. En tentant de passer, il entrera comme par inadvertance dans le rayon du Trigger et déclenchera l'ouverture.
Un problème se pose cependant si la porte ne s'ouvre pas aussi simplement. Ainsi, si le Trigger se trouve ailleurs, le bot ne comprendra pas pourquoi le passage ne s'ouvre pas et restera bloqué sur la géométrie du mover.
Le champ DoorTrigger permet de spécifier le tag du Trigger qui commande l'ouverture de la porte. Une fois indiqué, le bot comprend le fonctionnement et se déplacera jusqu'au Trigger pour ouvrir le chemin avant de tenter de l'emprunter.
Si le Trigger est réglé pour réagir aux tirs (TriggerType = TT_Shoot), il saura qu'il doit tirer dessus pour ouvrir la porte (notez qu'il est possible qu'il tente malgré tout de marcher sur le Trigger).
Dans tous les cas, le bot comprend également que la porte bloque les tirs et ne tentera pas d'attaquer un adversaire caché derrière une porte fermée. Lorsque la porte est ouverte, en revanche, il réagira normalement à la vue d'un ennemi.
Le paramètre bBlockedWhenClosed, lui, indique au bot qu'il n'a aucun moyen d'ouvrir la porte lui-même. Dans la majorité des cas, vous ne voudrez pas que cela soit le cas car il est nécessaire que le bot puisse au contraire interagir avec elle. Cependant, si le comportement de la porte ne réagit pas au bot mais à un événement extérieur (par exemple lors de l'accomplissement d'un objectif du mode Assault), ou de manière automatique, (par exemple toutes les 5 secondes), voire de manière totalement aléatoire, ce paramètre permet de signaler aux bots que même s'ils ne peuvent pas tenter d'ouvrir la porte eux-mêmes, ils peuvent passer lorsque celle-ci s'ouvre.
Le dernier paramètre est bInitiallyClosed, qui est par défaut Vrai. Ce réglage convient au cas majoritaire, celui d'une porte fermée qu'il est nécessaire d'ouvrir. Le régler sur Faux indique au contraire que la porte est ouverte par défaut et se ferme lorsqu'elle est actionnée. Après de nombreux tests, je n'ai jamais réussi à faire fonctionner ce paramètre. S'il est réglé sur Vrai, les bots semblent toujours considérer le chemin comme ouvert et, une fois la porte fermée, ils viennent cogner contre le mover sans en démordre.
Le mover lui-même possède un paramètre dans l'onglet AI de ses propriétés : bAutoDoor.
Si ce paramètre est réglé sur Vrai, le mover génère automatiquement un actor Door lors du rebuild, qui se positionne au point le plus bas du mover et reçoit automatiquement le bon DoorTag. Cette fonction est en réalité peu utile car elle ne va pas chercher le DoorTrigger, qui doit être ajouté manuellement, et l'actor Door positionné tout en bas du mover finit le plus souvent encastré dans la géométrie du sol et donc incapable de générer un chemin, le tout accompagné d'un avertissement après le rebuild des paths.
Repositionner le Door créé automatiquement ne suffit pas car il est réinitialisé à chaque rebuild. Cela achève de rendre cette fonction inutilisable car il est alors nécessaire de reparamétrer le DoorTrigger à chaque compilation.
Il est donc préférable de placer et paramétrer manuellement l'actor Door en tenant compte du fait qu'il ne fonctionne correctement que si les portes commencent fermées.
Ascenseurs
Les ascenseurs ne se comportent pas comme les portes (grande découverte) car ils n'obstruent pas le chemin mais relient deux parties séparées du réseau de navigation. Le pathing d'un tel mover se compose d'au moins trois parties : les entrées/sorties de l'ascenseur, qui font le lien avec le reste des chemins de navigation, et un indicateur de la position initiale de l'ascenseur, qui permet au bot d'y monter.
Le premier actor nécessaire est le LiftCenter, qui indique la position de l'ascenseur. Pour signaler les entrées et sorties de l'ascenseur, on utilise des LiftExits. Placez-en un à chaque palier, que ceux-ci servent de point d'embarquement ou de sorties.
Le LiftCenter fonctionne un peu comme l'actor Door : placé au milieu de l'ascenseur, il reçoit comme LiftTag le tag du mover et comme LiftTrigger éventuel celui du Trigger activant l'engin s'il existe (et s'il est nécessaire). Le paramètre LiftTag de tous les LiftExits doit aussi contenir le tag de l'ascenseur. Le champ SuggestedKeyFrame permet au bot de savoir quelle position correspond à quelle sortie. Chaque LiftExit reçoit donc le numéro de la position du mover où il est utilisable. Dans le cas d'un ascenseur très simple, qui commence au sol et monte ensuite, on associe le LiftExit du bas à la Key 0 et celui du haut à la Key 1.
Si ces SuggestedKeyFrames ne sont pas configurées, l'IA peut tenter d'emprunter un ascenseur depuis n'importe quel LiftExit. Cela cause des situations absurdes comme des bots sautant d'en haut sur l'ascenseur, pour essayer d'arriver en bas. Si la position supérieure est la 1 (et celle d'en bas 0), l'indiquer correctement permet aux bots de comprendre qu'ils ne doivent pas utiliser l'entrée du haut si le mover est en bas et, à l'inverse, d'attendre que l'ascenseur redescende pour tenter de l'emprunter au lieu de se mettre dessous et de se faire broyer lorsqu'il revient à sa position initiale.
Il est aussi possible d'utiliser les LiftExits et leur onglet LiftJump pour donner aux bots la possibilité de faire un lift jump, un saut décuplé par la vitesse de l'ascenseur, afin d'atteindre des lieux éloignés. Placez simplement un LiftExit supplémentaire à l'endroit où le bot doit atterrir, liez-le à l'ascenseur et indiquez-lui la SuggestedKeyFrame à partir de laquelle le bot doit sauter (en général la position finale, celle où l'ascenseur est au sommet de son mouvement). Dans l'onglet LiftJump, réglez bLiftJumpExit sur Vrai.
Le bot saura alors sauter en utilisant le boost de vitesse de l'ascenseur pour atteindre des points normalement inaccessibles. Il effectuera un double-saut pour l'atteindre si besoin. Régler bNoDoubleJump sur Vrai permet de lui interdire le double-saut s'il a tendance à viser trop haut et à se cogner sur un obstacle.
Un usage créatif du LiftExit et du LiftCenter est visible dans DM-CBP2-Reconstruct, où AngelMapper les utilise pour indiquer aux bots qu'ils peuvent emprunter des passages sans sol car une sorte de pont partiel se forme automatiquement sous les joueurs lorsqu'ils mettent le pied dans le vide.
Le pont est consitué de dizaines de petits movers cachés dans les murs et activés par une série de Triggers. Comme l'effet se fait et défait presque instantanément et que les bots doivent pouvoir passer dans les deux sens, la SuggestedKeyFrame donnée aux LiftExits est la Key 0, celle de la position initiale, afin qu'ils soient prévenus qu'ils peuvent s'engager lorsque le pont est rétracté. Le LiftTag des trois actors est celui de n'importe quelle pièce du pont.
On remarque que les Triggers qui déclenchent l'assemblage ne sont pas paramétrés dans le LiftTrigger du LiftCenter. Dans un cas comme celui-ci, le bot n'a pas besoin de savoir comment activer les movers, il lui suffit d'être informé que le passage est libre.
On comprend avec cet exemple qu'est considéré comme "ascenseur" n'importe quel mover sur lequel le bot est amené à passer, indépendament de son mouvement réel : une plateforme se déplaçant latéralement utilise les LiftExits et le LiftCenter de la même façon qu'un authentique ascenseur vertical.