Hellkeeper.net RSS Feed

Index Archives UnrealEd Tutorials Miscellaneous Maps Special Maps Links Hellkeeper Files Contact Administration

Bot pathing

Les bots d'Unreal utilisent un système de jalons, afin de naviguer dans l'espace selon des chemins prédéfinis dans le but de se procurer des objets de plus en plus puissants, le tout en combattant les autres joueurs sur leur chemin et en réalisant les objectifs s'ils ne sont pas en DeathMatch (capture du drapeau adverse, objectifs du mode Assaut...), tout en se maintenant en vie en récupérant de la santé et des boucliers. La quasi-totalité des actors nécessaires à la mise en place de ces chemins se trouvent dans l'actor browser en tant que dérivés de la classe NavigationPoint.

Ce premier tutorial expliquera comment mettre en place un réseau de navigation simple, adapté à une map sans grosse coupure (étages séparés, zones sans lien qui doivent être liées par des téléporteurs, etc.). Les actors nécessaires aux cas plus complexes seront étudiés dans d'autres tutoriaux.

Réseau de base

Un réseau se compose d'au moins deux types de jalons : les PlayerStarts, qui définissent les lieux où les joueurs et bots peuvent apparaître, et les PathNodes, qui forment le réseau en étant disséminés dans la map. Une fois les jalons de toutes sortes répartis, les chemins doivent être rebuildés pour que les bots puissent les utiliser en jeu. On peut ensuite afficher les chemins en faisant un clic droit dans l'en-tête d'un des viewports et en choisissant View puis Show Paths. Des flèches relient alors les jalons. C'est ce réseau de flèches entre tous les jalons et tous les items qui constitue le réseau de navigation. Toute zone dépourvue de chemins et de jalons sera inaccessible aux bots.

La couleur des flèches dépend de la largeur du chemin et de la facilité qu'auront les bots à l'emprunter. Les chemins établis automatiquement peuvent être de trois couleurs différentes. Un chemin blanc sera extrêmement large et facile à prendre, correspondant généralement à de grands espaces ouverts, par exemple en extérieur. Un chemin vert sera moins libre qu'un chemin blanc, mais sans être étroit : la plupart des maps en intérieur, même lorsque les couloirs sont très larges, sont surtout couvertes de vert. Un chemin un bleu sera considéré comme d'accès plus difficile. Si le moteur considère que deux points sont impossibles à relier (ils ne se voient pas ou le passage entre eux est trop étroit), aucun chemin ne sera établi.

Enfin, les items tels que les armes (ou leurs bases), les fioles de santé ou les pilules d'adrénaline sont eux-mêmes considérés comme des sortes de jalons car le jeu ajoute par défaut un jalon invisible, l'InventorySpot, à leur emplacement lors du rebuild des chemins. De même, les objectifs (drapeaux de CTF, balle et buts de BR, points de domination ou relais d'ONS, etc.) sont automatiquement rattachés au réseau. Il n'est donc pas nécessaire d'ajouter des jalons dessus pour que les bots sachent les utiliser.

De plus les jumpers et les téléporteurs, étant constitués de jalons spécialement paramétrés, sont automatiquement utilisables par les bots du moment qu'ils sont fonctionnels pour les joueurs humains.

Lors du rebuild du bot pathing, le menu Build propose deux options : Rebuild AI Paths et Rebuild Changed AI Paths. La première option supprime tout éventuel réseau de navigation déjà existant et recalcule à nouveau tous les chemins. Au fur et à mesure que le nombre de jalons et d'items augmente, l'opération peut devenir très longue. La seconde option permet donc de supprimer le réseau déjà existant mais de ne calculer que les éléments considérés comme "modifiés", c'est-à-dire les items ou jalons ajoutés ou déplacés depuis le dernier rebuild du réseau. Les modifications des paramètres ne sont cependant pas considérées comme des modifications et leur effet ne sera calculé qu'après un rebuild complet.

PathNode

Le PathNode est le premier élément nécessaire. Il se trouve dans le menu contextuel par défaut qui apparaît lorsque l'on fait un clic droit dans une des vues.

Il s'agit du jalon de base qui, réparti de manière homogène dans toutes les zones navigables de votre map, permet au bot de se tracer des chemins vers un item. Ainsi, si votre bot se trouve d'un côté de votre map et qu'il désire atteindre un objet de l'autre côté, il suit les PathNodes jusqu'à lui.

Le PathNode apparaît sous la forme d'une petite pomme brune. Afin que le moteur puisse les relier ils ne doivent pas être éloignés de plus de 1000 unités et chacun d'eux se reliera à tous les autres PathNodes à portée qui sont visibles de sa position. Un bot ne pourra pas rejoindre un PathNode s'il ne peut pas suivre des chemins établis entre différents points jusqu'à celui-ci.

Dans le cas de ces deux couloirs se coupant à angle droit, les PathNodes de chaque couloir ne peuvent pas voir (et donc se relier à) ceux du couloir perpendiculaire. Le réseau ne permet donc pas au bot de changer de direction à l'embranchement. Il faut pour cela ajouter un autre PathNode capable de se relier à tous les autres.

Le bot ne suit alors plus une direction unique sans "voir" le croisement : il rejoint le PathNode central et peut alors choisir de changer de direction.

Créer un réseau basique se résume à placer des PathNodes à tous les embranchements possibles et un peu partout pour quadriller grossièrement toute la zone jouable.

Si un bot spawne ou se retrouve, en cours de match, dans une zone sans chemins (par exemple parce qu'il y a été poussé suite à une chute), il tentera de rejoindre le réseau autant que possible. S'il est totalement isolé ou s'il n'y a aucun chemin, il se contentera d'errer dans une petite zone, accroupi, en attendant d'être surpris par un ennemi. Il pourra combattre normalement (et même rejoindre le réseau de navigation par accident suite à des sauts ou si une explosion le projette à proximité).

La plupart du temps, il n'est pas utile d'aller changer les options du PathNode. Cependant, parce qu'il s'agit du jalon de base, c'est un bon exemple pour voir les propriétés de l'onglet NavigationPoint, qui sont communes à tous les autres points de navigation.

• bAlwaysUseStrafing et bNeverUseStrafing : Ces deux paramètres permettent, si l'un d'eux est activé, de passer outre la stratégie par défaut de l'IA et d'interdire au bot l'usage d'un certain type de déplacement ou au contraire à l'y contraindre.
• bBlocked : Par défaut réglé sur faux. S'il est vrai, empêche d'utiliser le jalon pour passer. Un chemin est cependant tout de même créé lors du rebuild.
• bMakeSourceOnly : Si vrai, le jalon sélectionné ne pourra pas servir de destination à un chemin, seulement de source.
• bNoSuperSize et bVehicleDestination : Ces deux paramètres influent sur la façon dont les bots aux commandes d'un véhicule voient le chemin vers ce point. Voyez le tutorial dédié.
• bOneWayPath : Si ce paramètre est activé, le chemin sera considéré à sens unique. Dans ce cas, la direction empruntable sera définie par l'orientation du jalon. S'il s'agit d'un actor directionnel, comme le PlayerStart, une flèche rouge indique le sens dans lequel l'actor est tourné. Si ce n'est pas le cas, on peut activer la flèche dans les propriétés de l'actor : Advanced => bDirectional = vrai. Un bot ne pourra alors emprunter le jalon choisi que dans le sens de la flèche. Lors du rebuild, aucun chemin ne sera créé depuis le jalon vers un point situé "derrière" lui. Notez que les chemins s'établissent avec tous les points visibles jusqu'à 90° de la direction choisie.

• bPropagatesSound : Vrai par défaut, indique qu'un bot passant sur ce point est audible à la ronde. Cela signifie que les autres bots à proximité seront conscients qu'un de leurs congénères se trouve à cette position.
• ExtraCost : Permet de donner un "coût" additionnel au chemin vers ce jalon. Cela revient à indiquer au bot que ce chemin est plus long ou plus compliqué à atteindre et donc à rendre ce chemin moins attractif. Par exemple, si deux routes mènent à un même point mais que les bots n'en utilisent qu'une, ajouter un ExtraCost à un PathNode stratégique (un que les bots doivent obligatoirement utiliser, par exemple dans un goulet d'étranglement), permet de rééquilibrer l'usage des deux routes en rendant la plus fréquentée moins intéressante aux yeux de l'IA.
• ForcedPaths : Ce paramètre permet de forcer manuellement l'établissement d'un chemin entre deux points lorsque le moteur ne le fait pas. Il faut pour cela ajouter le nom du jalon ciblé à la liste des ForcedPaths (ce nom se trouve dans les propriétés de l'actor, Object => Name). Au rebuild suivant, le moteur créera obligatoirement un chemin, qui sera affiché en jaune, entre les deux points de navigation, même s'ils sont normalement trop éloignés pour se relier.

• ProscribedPaths : Il s'agit de l'inverse : il interdit le passage vers un jalon dont le nom est indiqué. Après rebuild, le chemin depuis le jalon qui possède un ProscribedPath en direction du jalon dont le nom est indiqué sera bien établi, mais il sera affiché en rouge et inutilisable par l'IA.

PlayerStart

Le PlayerStart définit un point de spawn utilisable par les joueurs et les bots. Si aucun PlayerStart n'est présent dans la map, les joueurs seront spawnés aléatoirement sur n'importe quel PathNode. Si au moins un PlayerStart est présent, alors seuls les PlayerStarts seront utilisés pour spawner, ce qui permet de choisir où les joueurs commencent la partie. La règle est d'en ajouter plus que le nombre de joueurs conseillé dans une map afin d'éviter, s'il n'y en a pas assez, que des joueurs soient en attente d'un point de départ libre pour apparaître. En effet, contrairement à Unreal ou UT99, UT2004 s'assure qu'un PlayerStart est disponible avant de l'utiliser pour ajouter un joueur à la partie, ce qui évite que deux joueurs n'apparaissent simultanément au même endroit et que l'un deux soit téléfragué.

Comme le PathNode, le PlayerStart se trouve par défaut dans le menu contextuel.

L'éditeur l'affiche sous la forme d'un petit joystick. Il s'agit d'un actor directionnel avec une flèche qui indique la direction à laquelle le joueur fera face au moment du spawn. Il possède, en plus des mêmes paramètres que le PathNode, des propriétés spécifiques.

• bCoopStart : Résidu des actors de UT99 qui eux-mêmes l'ont hérité d'Unreal, ce paramètre permet d'utiliser ce PlayerStart en jeu coopératif. Par définition, il n'a aucun effet dans UT2004.
• bEnabled : Définit ce PlayerStart comme activé ou non. Notez que si votre map ne contient qu'un seul PlayerStart, il sera utilisé même si bEnabled est faux. Le PlayerStart ne peut pas être activé ou désactivé à volonté, mais il possède une sous-classe, TriggeredPlayerStart, qui peut changer d'état à l'aide d'un Trigger. Il est donc possible de définir quels points de départ sont utilisables à quels moments.
• bPrimaryStart : Ce paramètre est par défaut vrai et permet d'utiliser le PlayerStart dans n'importe quelle situation. S'il est réglé sur faux, alors le PlayerStart considéré ne sera utilisé que si tous les autres PlayerStart pour lesquels bPrimaryStart = vrai sont occupés.
• bSinglePlayerStart : Une autre relique d'Unreal. Lorsqu'une campagne solo est jouée, le joueur spawne au premier PlayerStart pour lequel ce paramètre est vrai.
• TeamNumber : Lorsque le mode de jeu répartit les joueurs en équipe, il est possible de définir quelle équipe peut utiliser un PlayerStart. En CTF, par exemple, chaque équipe spawne généralement dans sa base et dans les environs. Pour l'équipe rouge, TeamNumber doit être 0 et l'équipe bleue correspond à 1. Lorsque l'on mappe pour un mod avec plus de deux équipes, comme CTF4, qui ajoute deux autres factions au mode CTF classique, l'équipe verte correspond à 2 et l'équipe jaune à 3.

Notez que dans le cas du mode Assaut, les PlayerStarts activés et désactivés successivement au fur et à mesure que les attaquants avancent ont tous bEnabled = vrai et qu'aucun TriggeredPlayerStart n'est utilisé. Gérer les points de départs disponibles pour chaque camp est en effet compliqué par l'inversion des équipes à chaque round. En conséquence, la gestion de l'activation et de la désactivation des groupes de PlayerStarts se fait via un actor spécifique, le PlayerSpawnManager, sous-classe d'Info.

Enfin, en mode ONS, les PlayerStarts sont automatiquement liés au relais ou au générateur le plus proche. Ainsi, un PlayerStart n'est utilisable que par les joueurs de l'équipe possédant le relais le plus proche et le jeu gère seul leur activation et leur désactivation pour les deux équipes.

Une dernière variante du PlayerStart, xFieldPlayerStart semble inutilisée. Aucune information n'est donnée sur son fonctionnement, mais il semblerait qu'il ait été conçu pour faire spawner les joueurs à des positions données d'après leur numéro de joueur, à l'instar de joueurs de football ou de rugby dont la position sur le terrain est liée au numéro de maillot.

Une fois la map couverte de PathNodes et les PlayerStarts disposés aux lieux appropriés, la map est navigable pour les bots. En revanche, ils seront incapables de sauter sur des plateformes ou d'utiliser le téléporteur en mode CTF ou BR. Le réseau de base se limite aux zones où le bot peut se déplacer en courant et lui permet au mieux de se jeter du haut d'un niveau peu élevé vers le niveau inférieur.

Sauts et téléportation

Pour indiquer aux bots les lieux où un saut ou une téléportation est nécessaire, on utilise le JumpSpot. Il se trouve sous JumpDest dans l'actor browser.

Le JumpSpot doit être placé à l'endroit visé par le saut ou la téléportation, c'est-à-dire par exemple sur une plateforme en hauteur ou de l'autre côté d'un ravin que le bot ne peut pas franchir à pied normalement. Pour qu'un bot utilise le JumpSpot comme point d'arrivée d'un saut ou d'une téléportation, il faut mettre son nom dans les ForcedPaths des PathNodes qui doivent y conduire.

Ses options permettent de déterminer quel type de saut doit être utilisé par l'IA pour réussir à atteindre la position. Ces options sont divisées entre deux onglets des propriétés de l'actor, JumpDest et JumpSpot.

• bForceDoubleJump : Force le bot à exécuter un double-saut pour atteindre ce point. Utile si le bot rencontre un problème et n'arrive pas à accéder à la destination avec un saut normal mais n'essaye pas de faire un double-saut.
• bDodgeUp : Ce premier paramètre de l'onglet JumpSpot permet, si vrai, de paramétrer le saut comme un dodge jump le long d'un mur incliné pour glisser jusqu'au sommet. Il s'agit du type de saut réalisé dans DM-Rankin.

• bForceAllowDoubleJumping : Ce paramètre permet de convaincre le bot qu'un double-saut permet de franchir l'obstacle. L'IA par défaut d'UT2004 considère certains sauts tout juste faisables comme impossibles et ne tente pas de les exécuter. bForceAllowDoubleJumping = vrai promet au bot que le saut est faisable.
• bNeverImpactJump : Permet, si activé, d'interdire aux bots de tenter un impact jump pour atteindre le JumpSpot.
• bNoLowGrav : Si vrai, le JumpSpot sera ignoré lorsque la gravité est réduite.
• bOnlyTranslocator : Définit un emplacement qui n'est accessible que grâce au téléporteur mais pas par un saut.
• TranslocTargetTag : Permet d'indiquer au bot de lancer la balise du téléporteur en direction d'un point précis en mettant le Tag de l'actor ciblé. Ce paramètre est utile dans les cas où le JumpSpot ne doit pas être visé directement, par exemple si un ricochet est nécessaire.
• TranslocZOffset : Censé permettre d'ajuster la hauteur du tir de la balise. Difficile à jauger. À utiliser si les bots n'arrivent pas à envoyer leur balise au bon endroit (si elle est bloquée par un obstacle comme un plafond bas ou un rebord un peu trop haut). On indique alors la hauteur à laquelle viser au-dessus du JumpSpot.

Il est possible d'utiliser le JumpSpot et son paramètre TranslocTargetTag en conjonction avec un actor spécifique, le TransbeaconTeleporter. Le système est utilisé dans CTF-Chrome où le JumpSpot a comme TranslocTargetTag le Tag de ce TransbeaconTeleporter et ce dernier a comme JumpSpotTag le Tag du JumpSpot. Lorsque la balise touche ce dernier, elle est téléportée directement au niveau du JumpSpot.

Une limitation importante du JumpSpot est qu'il ne peut pas être paramétré pour amener le bot à faire un wall jump afin de franchir un obstacle.

Jeu en équipe

Plusieurs actors permettent de paramétrer des comportements spécifiques aux modes de jeu en équipe. Comme vu plus haut, les PlayStarts reçoivent un numéro d'équipe dans le paramètre TeamNumber pour définir quelle équipe spawne dessus.

ShootSpot

Pour une map BR, il existe un actor spécial, le ShootSpot. Il existe en deux versions : BlueShootSpot et RedShootSpot.

Ils se placent dans la map aux endroits d'où les bots porteurs de balle peuvent tenter de tirer vers le but au lieu d'essayer de passer à travers. Les noms sont trompeurs : le BlueShootSpot se positionne aux endroits où les bots rouges doivent tirer vers le but bleu et le RedShootSpot se place là où les bots bleus doivent tirer vers le but rouge.

Ces actors n'ont aucun paramètre spécifique hors des paramètres communs des NavigationPoints.

Scripts et points de défense

Lorsque les bots reçoivent l'ordre de défendre en CTF ou en BR, il est possible de définir les positions vers lesquelles ils se dirigent. Il faut pour cela paramétrer un actor qui n'est pas une sous-classe de NavigationPoint, l'actor UnrealScriptedSequence, enterré plusieurs niveaux sous le Keypoint.

C'est un dérivé de la ScriptedSequence normale qui permet de contrôler les bots en leur donnant des instructions précises. L'UnrealScriptedSequence est pré-paramétrée pour servir de point de camping.

Elle se place à l'endroit où le bot doit camper et orientée dans la direction que le bot doit surveiller (il s'agit encore d'un actor directionnel). Pour servir de point de défense d'une base, il faut ensuite la lier à l'objectif à défendre : générateur d'ONS, drapeau de CTF, but de BR. Ils possèdent un paramètre spécifique : DefenseScriptTags.

Si ce champ contient le même Tag qu'une ou plusieurs UnrealScriptedSequences, ces dernières seront considérées par les bots comme des bons points pour camper s'ils sont en défense.

L'UnrealScriptedSequence a également quelques options spécifiques qui permettent un réglage plus fin.

• bDontChangeScript : Si un bot est interrompu (par exemple par un adversaire) il reviendra à ce script si ce paramètre est vrai. Autrement, il passera à une autre position s'il y en a. Permet de ne pas laisser un bot à une position où il a déjà été repéré, par exemple.
• bNotInVehicle : Le point est ignoré si le bot est dans un véhicule.
• bRoamingScript : Si vrai, le bot ne reviendra pas à ce script après l'avoir utilisé.
• bSniping : Indique au bot qu'il doit sniper.
• EnemyAcquisitionScriptProbability : Plus ce chiffre est proche de 1, plus le bot a de chances d'utiliser le script paramétré dans le champ suivant.
• EnemyAcquisitionScriptTag : Tag du script (une autre UnrealScriptedSequence) à exécuter après repéré un ennemi. Permet de faire accomplir une action spécifique à un bot en cas d'arrivée d'un ennemi dans son champ de vision.
• SnipingVolumeTag : Permet de définir la zone surveillée par le bot en indiquant le Tag d'un volume. Le bot sera attentif à tout adversaire entrant dans ce volume et cherchera à l'abattre.
• Priority : Si vous avez plusieurs scripts que le bot peut utiliser, vous pouvez leur donner des ordres de priorité, par exemple pour vous assurer que la position la plus critique soit toujours pourvue d'un défenseur.
• WeaponPreference : L'arme que le bot privilégiera en exécutant la séquence.

Par défaut, le script attire le bot pour 3 secondes, mais il suffit d'augmenter la valeur du PauseTime de l'Action_WAITFORTIMER du script pour définir un temps plus long pendant lequel le bot l'exécutera.

Les UnrealScriptedSequences qui ne sont pas associées à un objectif particulier peuvent être utilisées par les joueurs qui ne sont pas dans un rôle d'attaque ou de défense. Cela inclut à la fois les joueurs "libres" (ceux qui ont reçu l'ordre "chercher et tuer") d'un match en équipes et la totalité des bots dans un mode de jeu sans équipes (par exemple un DM). Les attaquants, eux, ignorent ces points et leur comportement est déterminé par la configuration des AssaultPaths.

Les bots se répartissent aléatoirement les rôles entre attaquants, défenseurs et libres s'ils ne reçoivent pas d'ordre précis de la part du joueur. Le long tutorial de Blitz sur le sujet explique en détail le mode de pensée des bots.

Notez qu'en DM, il est universellement recommandé soit de n'avoir aucune UnrealScriptedSequences, soit d'en avoir en assez grand nombre pour que les bots n'occupent pas en boucle une poignée de positions les rendant totalement prévisibles.

Autres actors

Certains actors intéressants permettent de s'occuper de cas particuliers et sont détaillés dans des tutoriaux à part. Les derniers actors ne correspondent qu'à des cas très rares et sont donc traités ici.

BlockedPath

Le BlockedPath est un point de navigation avec bBlocked = vrai par défaut, qui indique qu'un chemin est inaccessible. Tant que c'est le cas, les bots ne tentent pas de passer. Il peut ensuite être déclenché par Trigger pour devenir franchissable et permet donc d'ouvrir et de fermer à volonté des parties de la map à la navigation des bots. Il est notamment employé dans des maps du mode AS pour permettre aux bots d'accéder aux nouvelles parties de la map qui s'ouvrent à eux lorsque les objectifs sont accomplis.

Lorsque la porte de l'usine d'AS-RobotFactory est détruite, par exemple, le BlockedPath qui se trouve devant est activé et devient donc un passage libre. Comme tous les chemins vers l'intérieur de l'usine passent par lui, l'activer permet donc d'ouvrir ou d'interdire l'accès aux bots.

Échelles

Bien qu'aucune map du jeu n'en fasse usage, il est possible de créer des échelles dans UT2004.

Elles se paramètrent en plaçant un LadderVolume près du mur. Il possède une flèche sur son pivot, en son centre. Si l'on lui applique une rotation, la flèche reste fixe. Elle se dirige à travers le vecteur défini dans le champ WallDir des propriétés du volume. Dès que le volume est créé, l'échelle est fonctionnelle pour le joueur, mais les bots ne savent pas l'utiliser.

Par défaut, les LadderVolumes ont un paramètre bAutoPath réglé sur vrai. Lors du rebuild, le volume génère automatiquement des actors AutoLadder à son sommet et à son pied. Ces actors sont des équivalents automatiques de l'actor Ladder qui se trouve sous le SmallNavigationPoint. On peut désactiver bAutoPath et placer les actors à la main.

L'actor Ladder, généré automatiquement ou non, n'a aucun paramètre. Il est directionnel, mais son orientation ne semble pas importante. Les actors Ladder sont automatiquement reliés l'un à l'autre s'ils sont dans le même LadderVolume et cela suffit à rendre l'échelle utilisable par les bots. Ces derniers éviteront d'ailleurs d'utiliser une échelle si quelqu'un est déjà en train de l'utiliser (si le volume est occupé par un autre joueur).

Afin que le bot puisse sortir de l'échelle au sommet, il faut que le Ladder supérieur soit relié au réseau de navigation. Pour cela, il faut que le LadderVolume dépasse légèrement le haut de l'échelle (pour que l'actor AutoLadder ait une vue dégagée sur un point de navigation sur l'étage du haut) ou utiliser un Ladder placé manuellement et le sortir légèrement au-dessus du volume pour qu'il se relie au réseau tout en restant associé au Ladder inférieur (placé trop haut, l'association ne se fera plus).

Les paramètres de l'échelle se gèrent au niveau du LadderVolume lui-même.

• bAllowLadderStrafing : Permet d'autoriser ou non le déplacement latéral sur l'échelle. Par défaut, un joueur agrippé ne peut se déplacer que vers l'avant ou l'arrière (haut et bas).
• bAutoPath : Active ou désactive la génération automatique du pathing de l'échelle. Conrairement à l'actor Door, qui peut aussi être généré automatiquement pour les portes, les actors générés suffisent dans la majorité des cas.
• bNoPhysicalLadder : Si vrai, le joueur sera considéré comme montant à l'échelle au moment où il touchera le volume (sa limite extérieur est donc la surface de l'échelle). Si faux, le joueur devra être dans le volume, collé à la limite intérieur ou à un objet se trouvant dans ses limites, face à la direction de la flèche du volume, pour être considéré comme sur l'échelle.
• ClimbingAnimation et TopAnimation : Permettent d'indiquer les animations à jouer.
• WallDir : La direction de l'échelle. Lorsque le joueur entre dans le volume, il est considéré comme "sur l'échelle" lorsqu'il touche un objet en regardant dans cette direction.

Débuggage

L'éditeur et le jeu proposent tous les deux quelques outils pour débugger les problèmes de pathing. Le premier est Tool => Review Paths dans UnrealEd. Cette commande teste le réseau de navigation pour s'assurer que :

• Les objectifs peuvent être rejoints depuis n'importe quel point de la map. Cela permet d'éviter qu'un drapeau ou un but soit inaccessible aux bots et donc qu'ils soient incapables de jouer la partie correctement.
• Tous les movers ont un pathing correct, à moins qu'ils soient paramétrés en bNoAiRelevance = vrai.
• Aucun point de navigation n'a une valeur d'ExtraCost inférieure à zéro.

En revanche, cet outil relève un certain nombre d'erreurs qui n'en sont probablement pas : il signale un manque de PlayerStarts tant qu'il y en a moins de 16, par exemple.

Le plus pratique reste cependant de lancer la map et d'observer le comportement des bots. Vous pouvez en ajouter avec la commande addbots X, où X est le nombre de bots à spawner. Une fois la map peuplée, un certain nombre de commandes permettent de vérifier que tout fonctionne bien.

• SoakBots : Si un bot a un problème, le jeu se mettra en pause et vous présentera un log avec l'erreur rencontrée.
• ViewBot : Place la caméra en mode spectateur sur un bot. Cela revient à lancer la map en mode spectateur pour observer le comportement de l'IA. Attention, votre avatar reste présent en jeu et pourra être attaqué.
• ShowDebug : De nombreuses informations en temps réel sur l'état du bot regardé.
• ShowAI : Vous montre la "pensée" du bot à chaque instant, ainsi que le chemin qu'il suit.

Si votre map contient des JumpSpots, la commande ReviewJumpSpots est capitale car elle permet de passer en revue chaque JumpSpot de plusieurs façons. Par défaut, la commande spawn un bot avec le skin par défaut (un brave Jakob) qui se téléporte automatiquement à chaque point de navigation relié à un JumpSpot et tente d'atteindre ce dernier en se téléportant, puis en faisant des impact jumps, et enfin en faisant des sauts en basse gravité. Si des JumpSpots sont paramétrés pour n'être accessibles qu'avec certaines méthodes, les méthodes interdites ne seront pas testées pour rien.

Vous pouvez également choisir quel type de saut tester :

• Si vous tapez ReviewJumpSpots Jump, le bot va essayer d'atteindre les JumpSpots en sautant et en faisant des impact jumps.
• Si vous tapez ReviewJumpSpots Transloc, le bot va essayer d'atteindre les JumpSpots avec le téléporteur.
• Si vous tapez ReviewJumpSpots LowGrav, le bot va essayer d'atteindre les JumpSpots avec les paramètres de basse gravité.
• Si vous tapez ReviewJumpSpots Combo, le bot va exécuter le combo d'adrénaline Vitesse et essayer d'utiliser ces sauts décuplés pour atteindre les JumpSpots. Ce type de saut n'est pas testé par défaut si vous ne le demandez pas spécifiquement.

Ces tests sont intéressants car vous pouvez voir ce qui ne va pas : un test manqué vous montrera clairement, par exemple, que le bot n'arrive pas à lancer la balise de son téléporteur à cause d'une décoration trop proéminente, etc.

Lorsqu'une map comporte beaucoup de JumpSpots, il peut être très long de tous les tester. Avec la commande Slomo x, où x est un chiffre supérieur à 1, on peut accélérer le temps. Avec une valeur de 8, le jeu ira à toute vitesse. Il devient impossible de suivre les tests à l'œil nu, mais le résultat de chaque essai sera enregistré dans le log d'UT2004 (/System/UT2004.log). À chaque JumpSpot testé, une ligne notera le type de saut testé, le point de départ et le point visé :

ScriptLog: Test translocation from CTF-Senate.JumpSpot55 to CTF-Senate.JumpSpot21
ScriptLog: Success!

Si le saut ne marche pas, le log le notifiera :

ScriptLog: FAILED to reach Autoplay.JumpSpot2

Le nom du JumpSpot étant de nouveau présent, on peut isoler le point problématique et tester de façon plus poussée sans devoir tester l'intégralité des sauts à chaque fois.

Lien utile : la présentation des actors par Steve Polge.