Concevoir l'intelligence artificielle pour les jeux vidéo

Reproduire la vue d'une entité correspond au niveau le plus fondamental des capacités perceptives de l'agent. Vous pouvez le faire en demandant à vos entités de détecter tout ce qui se trouve dans leur champ de vison. Vous pouvez choisir que votre entité s'intéresse à la première chose qui passe dans son champ de vision ou lui donner une liste de choses auxquelles réagir de sorte que votre agent puisse prendre la bonne décision en fonction de son environnement immédiat.

Cette configuration fonctionne parfaitement pour les jeux simples, mais lorsque votre jeu est plus complexe, comme un jeu d'infiltration ou un FPS tactique, vos agents devront être plus sélectifs en fonction de ce qu'ils « voient ». Si vous ne voulez pas que vos agents aient des yeux derrière la tête, vous pouvez réduire la liste des potentiels et supprimer tout ce qui passe à l'extérieur du champ de vision de l'entité. Vous pouvez accomplir rapidement cette tâche en faisant quelques calculs :

1. Calculez le vecteur entre l'agent et l'entité en question en soustrayant la position de la cible à la position de l'agent ;
2. Calculez l'angle entre ce vecteur et la direction dans laquelle votre agent regarde. (Si ce n'est pas déjà un vecteur, vous pouvez également calculer cette valeur.) ;
3. Si la valeur absolue de l'angle est supérieure au préréglage de l'angle de vue de l'agent, votre agent ne verra pas l'entité.

Dans des jeux plus complexes, vous devrez peut-être tenir compte du fait que le joueur ou que d'autres entités sont cachés par différents obstacles. Pour ce type de jeu, vous devrez effectuer un tracé de rayon (parfois appelé ray cast) pour voir si quelque chose bloque la cible potentielle. Un tracé de rayon est un moyen mathématique de vérifier si un rayon coupe quoi que ce soit, à partir d'un seul point et dans une direction déterminée. Le moteur du jeu propose une fonctionnalité de tracé de rayon, mais si vous voulez savoir comment faire, consultez l'article Deux cerveaux valent mieux qu'un.

La méthode précédente vous indique si quelque chose a occulté le centre de la cible, mais cela peut se révéler insuffisant pour dissuader votre agent. Il est possible que le centre de l'agent soit occulté, mais que sa tête dépasse au-dessus de l'obstacle. L'utilisation de plusieurs tracés de rayon à des points d'intérêt spécifiques sur la cible peut vous aider à déterminer non seulement si la cible peut être touchée, mais l'endroit où la cible peut être touchée.

De  prime abord, on peut se dire qu'en matière d'IA l'ouïe est identique à la vue. Si vous pouvez voir une entité, vous pouvez certainement l'entendre. Effectivement, si votre agent a repéré une entité, l'agent peut activement détecter tout ce que fait cette entité jusqu'à ce qu'il ne soit plus dans son champ de vision. Cependant, ajouter un niveau supplémentaire en dotant vos agents de l'audition vous permet d'améliorer le fonctionnement de la vision. Suivre le bruit que font les entités en tant que niveau de perception est la clé de tout jeu basé sur la discrétion et l'infiltration.

Tout comme pour la vue, vous devez obtenir une liste des entités proches afin de réagir en fonction. Pour ce faire, vous pouvez vous contenter de configurer une distance précise, mais pour une meilleure audition de votre entité vous devez modifier cette distance en fonction des éléments de la liste.

Chaque action que peut effectuer l'entité doit avoir un niveau sonore propre. Vous pouvez préconfigurer les niveaux sonores (pour optimiser l'équilibre du jeu) ou les définir en fonction des niveaux sonores réels des effets sonores pendant l'action (agréable en termes de réalisme, mais inutile). Si le son est généré dépasse un certain seuil, votre agent percevra cette entité.

Si vous voulez tenir compte des obstacles, vous pouvez à nouveau limiter cette liste en effectuant des tracés de rayon dans votre environnement de jeu pour voir si quoi que ce soit pourrait arrêter le son. Étant donné que peu de matériaux arrêtent entièrement les sons, vous devez être plus créatif lorsque vous choisissez les entités de votre liste.

Les fonctionnalités de base utilisées pour la vue et l'ouïe de vos agents suffisent pour simuler d'autres sens. Voici une liste des autres sens que vous pouvez ajouter aux entités d'un jeu si les graphismes le permettent :

• L'odorat : l'idée d'avoir des agents intelligents qui peuvent repérer et suivre les joueurs grâce à leur odeur a été ajoutée dans des jeux récents comme Call of Duty 4*. Ajouter le sens de l'odorat dans un jeu est relativement simple : donnez à chaque entité dans le jeu une certaine capacité olfactive. L'intensité de l'odeur détermine deux facteurs : le rayon dans lequel l'odeur est repérable et de la longueur de la piste laissée derrière l'entité. Les joueurs actifs laissent souvent des traces de leur passage derrière eux pour de multiples raisons (nous parlerons des pistes plus loin dans cet article). L'une de ces raisons peut être d'aider les entités à les repérer grâce à leur odeur. À mesure que le joueur avance, l'intensité de l'odeur laissée diminue, la piste refroidit. Lorsqu'un agent doit « sentir » la piste à nouveau, il doit vérifier les odeurs alentour comme il le ferait avec le son : inspecter son rayon. Avec l'odeur, le facteur de succès est donc basé sur la puissance de l'odorat de l'entité et de l'intensité de l'odeur à détecter sur la piste ;
• Le radar : certains jeux permettent aux joueurs de disposer d'un radar individuel, ce qui rend la détection encore plus facile. Il suffit de faire une simple vérification de rayon. L'IA peut alors vérifier les résultats. Pour les jeux en équipe, le radar lui-même peut devenir plus intéressant. Pour développer une IA dans un jeu en équipe, chaque équipe doit disposer d'une liste de radars affichant les entités trouvées par le radar. Chaque membre de l'équipe peut alors contrôler son rayon qui révélera la liste des entités repérées afin de coordonner l'action de l'équipe. L'équipe peut ajouter des éléments à la liste en utilisant un équipement radar (dans des jeux comme Enemy Territory : Quake Wars*) ainsi que chaque membre de l'équipe en ajoutant tout ce qui est « vu ». Ce comportement permet aux entités de fonctionner comme une seule entité, car chacun d'eux alerte les autres de ce qu'il voit ;
• Le toucher : e sens est une sorte de « contact » où le système de collision du moteur de jeu réagit automatiquement. Vous devez simplement vous assurer que vos agents intelligents réagissent aux dommages et événements de collision ;
• Le goût : je ne suis pas sûr de savoir comment ce sens pourrait être mis en œuvre dans un jeu. Ce serait sans doute un sens qui se rapprocherait des propriétés de l'odorat, mais exigerait que les agents soient actifs et « goûtent » ce qu'ils trouvent.

Être capable de ressentir le monde qui nous entoure est une bonne chose, mais qu'est-ce que les agents sont supposés ressentir ? Vous devez préciser et être en mesure d'identifier les choses qui peuvent être observées dans les paramètres de vos agents. Lorsque vous reconnaissez ce que vous voyez, vos agents peuvent réagir sur la base de règles qui régissent l'entité.

Les entités temporaires sont en réalité des effets visuels dans l'environnement de jeu. Elles sont semblables à des entités, elles ont une structure de classe globale qui définit une entité temporaire, mais elles se distinguent des entités, car elles ne « pensent » pas, ne réagissent pas, et n'interagissent pas avec les entités de l'environnement du jeu ou avec les joueurs. Leur seul but est d'agrémenter le jeu, en ajoutant des détails supplémentaires au jeu pendant un laps de temps déterminé et disparaissent ensuite. Les entités temporaires sont utilisées pour des éléments comme les trajectoires de projectiles, la fumée, les étincelles, les giclées de sang, et même les empreintes.

La nature des entités temporaires implique qu'elles sont simples à mettre en œuvre et n'ont pas vraiment besoin de détecter des obstacles ou de prendre en compte les collisions (au-delà des collisions simples). Le problème est que certaines entités temporaires donnent aux joueurs un indice visuel sur des événements passés (les impacts de balles, traces de brûlé indiquent une récente bataille, des empreintes de pas dans la neige peuvent conduire à une cible potentielle), alors pourquoi vos agents intelligents ne pourraient-ils pas utiliser ces indices à leur tour ?

Il existe deux façons de résoudre ce problème : vous pouvez améliorer votre système d'entité temporaire pour permettre le tracé de rayon (ce qui irait à l'encontre du principe d'entité temporaire), ou vous pouvez ajouter une entité vide à proximité de vos entités temporaires. Cette entité vierge ne pensera pas et n'aura pas d'existence graphique, mais vos agents seront capables de la détecter, et seront associés à l'entité temporaire pour fournir des renseignements à votre agent. Donc, lorsque vous ajoutez une traînée de sang sur le sol, vous pouvez également ajouter une entité invisible au même endroit qui informera vos agents de ce qui se passe. Pour les empreintes, c'est la piste qui compte.

Dans de nombreux jeux de tir, il est préférable que vos agents soient assez intelligents pour se dissimuler derrière des obstacles lorsque cela est possible plutôt que de rester à découvert en situation de combat. Ce problème est un peu plus spécialisé que d'autres sujets abordés jusqu'ici. Alors, comment vos agents déterminent-ils s'il y a une zone où ils pourront se mettre à couvert ?

Ce dilemme réside dans deux problèmes : comment déterminer la zone où l'entité peut se mettre à couvert dans la géométrie de l'environnement du jeu, et la façon dont les entités prennent la décision de se mettre à couvert (comme la bande dessinée ci-dessus le suggère). Pour déterminer si une entité est capable de bloquer les attaques en se mettant à couvert, vous pouvez faire une vérification simple en prenant en compte la taille de la zone de couverture potentielle. Vous devez ensuite vérifier si votre entité peut se dissimuler derrière elle. Pour ce faire, créez un rayon qui évalue les positions de tir et la zone à couvert. Utilisez ce rayon pour déterminer si la zone est totalement à couvert (à partir de votre point de tir), et marquez cet espace comme prochaine cible pour votre agent.

Le crash and turn, est l'un des moyens les plus élémentaires de générer les mouvements d'une entité. Voici comment cela fonctionne :

1. Déplacez-vous en direction de votre cible ;
2. Si vous rencontrez un mur, tournez dans la direction qui vous rapprochera le plus rapidement de la cible. Si aucun choix n'est préférable à un autre, optez pour un choix aléatoire.

Cette approche fonctionne assez bien pour les jeux simples. D'innombrables jeux ont utilisé cette méthode pour déterminer la façon dont les monstres poursuivent le joueur. La méthode crash and turn amène souvent les entités à rester coincées derrière des murs ou dans des coins concaves en essayant de poursuivre le joueur, cette méthode est idéale pour les jeux avec des zombies.

Si le jeu nécessite un peu plus de finesse dans les mouvements de ses agents, vous pouvez élargir la méthode crash and turn et donner une capacité de mémoire à vos agents. Si les agents peuvent garder une trace de l'endroit où ils sont déjà passés, ils peuvent commencer à prendre des décisions plus pertinentes sur le chemin à suivre. Lorsque toutes les possibilités directionnelles ont été essayées, vos agents peuvent revenir en arrière et faire des choix différents. Ainsi, votre agent fera une recherche systématique du chemin vers une cible. Voici comment cela fonctionne :

1. Déplacement vers la cible ;
2. Choix parmi ceux disponibles ;
3. Lorsque l'entité arrive dans une impasse, elle reviendra en arrière, au niveau du dernier choix et en fera un autre ;
4. Si tous les chemins possibles sont explorés, l'entité abandonnera.

Cette méthode a l'avantage d'être facile à mettre en œuvre, vous pouvez donc avoir un grand nombre d'entités sans ralentir le jeu. Cette méthode est également optimale pour le multithreading. L'inconvénient de cette méthode c'est un immense gaspillage d'espace, chaque agent pouvant potentiellement couvrir toute la carte.

Heureusement, vous pouvez éviter cela en permettant à vos agents de se souvenir des chemins déjà empruntés dans une mémoire partagée. Un problème de conflits de parcours peut alors se poser, vous devez donc conserver les chemins de vos entités dans un module distinct que tous les agents peuvent ensuite consulter au fur et à mesure qu'ils se déplacent et envoyer des mises à jour lorsqu'ils découvrent de nouvelles voies. Le module de la carte de parcours (Path Map Module) peut ensuite analyser les résultats pour éviter les conflits.

Les parcours générés par la méthode crash and turn sont parfaits pour s'adapter à des cartes évolutives. Dans les jeux de stratégie, les joueurs ne peuvent pas attendre que leurs unités trouvent leurs repères. De plus, ces cartes peuvent être gigantesques, et l'orientation se fait comme dans un goulot d'étranglement.

Trouver son chemin est essentiellement un problème de développement du jeu. Dans des jeux du même âge que le premier Starcraft* (Blizzard Entertainment*), un grand nombre d'entités étaient toutes capables de trouver leur chemin dans de vastes cartes complexes.

L'algorithme de base de parcours était « A* » (prononcez Eh-Star), qui pouvait être utilisé pour découvrir un chemin optimal entre deux points sur un graphe (dans ce cas, la carte). Une simple recherche sur Internet permet de découvrir un algorithme propre qui utilise des termes descriptifs comme F, G et H. Je vais vous l'expliquer plus clairement.

D'abord, vous devez établir deux listes : une liste de nœuds qui n'ont pas été vérifiés (Unchecked) et une liste de nœuds qui ont été vérifiés (Checked). Chaque liste est composée d'un nœud de position, de la distance estimée de l'objectif, et d'une référence à son parent (le nœud précédent dans la liste). Au départ, les listes sont vides.

Vous ajoutez ensuite votre position de départ à la liste non vérifiée et le parent. Puis, entrez l'algorithme :

• sélectionnez le meilleur nœud de la liste ;
• si ce nœud est l'objectif, vous avez terminé ;
• si ce nœud n'est pas l'objectif, ajoutez-le à la liste des vérifiés ;

• pour chaque nœud adjacent à ce nœud :

  • si le nœud n'est pas praticable, ignorez-le,
  • si le nœud est déjà dans une liste (cochée ou décochée), ignorez-le,
  • ajoutez tous les autres à la liste non vérifiée, en définissant ces nœuds comme parents et en réestimant la distance à l'objectif (une vérification de la distance brute suffit).

Lorsque l'entité atteint l'objectif, le chemin peut être établi en traçant l'itinéraire des parents vers le nœud qui n'a pas de parent (le nœud de départ). Vous aurez alors le chemin optimal que l'entité pourra alors suivre. Ce processus devant uniquement se faire lorsqu'un agent a reçu un ordre ou a décidé de se déplacer de sa propre initiative, il peut vraiment profiter au multithreading. Un agent peut envoyer une demande de parcours pour retrouver un chemin déjà trouvé sans affecter les performances de l'IA. Le système peut rapidement obtenir des résultats ; mais dans le cas d'un grand nombre de demandes de parcours, l'agent peut soit attendre ou tout simplement commencer à se diriger dans la bonne direction (il peut notamment utiliser la méthode crash and turn). Sur de très grandes cartes, le système peut être décomposé en régions, et des chemins possibles entre les régions (ou points de passage) peuvent être précalculés. Dans ce cas, pour trouver le bon parcours, il vous suffira d'afficher le meilleur chemin et de transmettre immédiatement les résultats. Le module de suivi de parcours peut simplement observer les changements sur la carte - comme un joueur qui construit un mur - et relancer ensuite les vérifications de parcours si nécessaire. L'algorithme peut donc s'adapter sans affecter les performances du reste du jeu.

Dans le sous-système, pour trouver les parcours, le multithreading peut également améliorer les performances du système. Parfait pour un jeu de stratégie en temps réel (RTS) ou dans un système avec un grand nombre d'entités où chacun cherche un chemin potentiellement unique. Plusieurs parcours peuvent être trouvés simultanément par différentes entités. Bien sûr, le système devra garder une trace des chemins découverts. Le même parcours n'a pas besoin d'être découvert plusieurs fois.