## Système Multi Agents

### Projet Warbot

#### DEA Informatique – 19 Février 2004

##### Par

###### COUSY Guilhem

MOIROD Guillaume

###### RAYMOND Gilles

Dans le cadre du projet Warbot, notre soucis a été de réaliser une architecture multi agents la plus souple possible afin de gérer des tactiques de combat. Nous avons ajouté au modèle groupe, agent, rôle une architecture de buts et de tactiques la plus exhaustive possible ainsi qu’un automate de détermination de rôle s’appuyant sur cette architecture.

Ainsi, le comportement d’un agent est déterminé par son rôle, ses tactiques et ses buts qui évoluent en fonction de ses percepts et ses communications inter agents.

Nous avons respecté une convention de codage et de nommage lors du développement en nous autorisant une liberté au niveau de la complexité des algorithmes.

Conception objet

Schéma des classes

Fonctionnement global des agents

A chaque tour un agent :

1. Reçoit les messages,

2. Traite les percepts,

3. Actualise son rôle,

4. Actualise sa tactique,

5. Actualise son but,

6. Agit.

Nous effectuons des pré-traitements sur la réception des messages (tri en fonction du type de message : Annonce, Requête, Ordre) ainsi que les celle des percepts (tri en fonction du type).

Un agent ne va changer de rôle que si il en reçoit l’ordre ou à la mort de son supérieur (sergent pour un RL, chef pour une base).

Nous avons divisé les buts d’un agent en plusieurs types certains d’entre eux n’étant valides que pour un type d’agent :

- inconnu,

- déplacement,

- rassembler (ordonner un regroupement à ses troupes pour un sergent),

- rassemblement (effectuer un regroupement),

- suivre un ami,

- attaquer une cible,

- organiser (création des groupes),

- appeler un groupe (sert au sergent pour connaître les soldats de son groupe),

- compter le nombre d’agents dans le groupe.

Stratégies globales

Nous avons remarqué que dans Warbot l’union faisait la force et donc nous avons établi une stratégie de déplacement en groupe d’agents de taille paramétrable. Dans chacun de ces groupes les agents ont des rôles différents : un RocketLauncher(RL) "chef", plusieurs RL "soldat" et éventuellement un Explorateur "éclaireur" qui gravite autour du groupe.

Lorsqu’un agent (Base, RL, Explorateur) détecte un ennemi il prévient tous les agents et les plus proches vont à l’attaque selon un ordre de priorité sur de la nature de l’ennemi.

La création des groupes et les affectations des rôles sont centralisées par une base "Chef" à l’initialisation de la partie. Ces rôles peuvent changer au cours du match.

Dans un premier temps les agents d’un même groupe vont se rassembler puis les groupes vont se disperser sur la carte. Une fois dispersés, ils adoptent une exploration en forme de spirale. Ainsi, nous couvrons une grande partie du terrain. Ces stratégies tendent à éliminer en premier lieu les ennemis mobiles, et dans le cas général être en surnombre par rapport à l’ennemi.

Gestion de l’évitement

Un agent mobile pour éviter les obstacles calcule l’union des angles interdits induits par chacun des obstacles qu’il perçoit (murs, autres agents) et choisit l’angle optimal pour atteindre sa cible tout en évitant les collisions.

Gestion des tirs

Avant de tirer, un RocketLauncher regarde s’il n’y a pas d’obstacle gênant le tir. Dans cette éventualité le RL ne tire pas et se déplace de façon à obtenir un angle de tir sur sa cible.

L’existence d’un angle de tir est calculée en fonction des arcs interdits par les obstacles. De plus, il n’est pas nécessaire au RL de voir sa cible pour lui tirer dessus. En effet, un agent peut indiquer la position de l’ennemi aux autres agents du groupe. Ceci permet de tuer les ennemis sans être vu.

Cependant le défaut de cette technique est qu’un agent qui ne perçoit pas sa cible est incapable de s’assurer qu’il n’y a pas d’obstacles entre la limite de son percept et l’ennemi. Mais il serait très compliqué d’intégrer ces obstacles dans la gestion des perceptions indirectes.

Il en résulte des dommages collatéraux possibles mais cela n’affecte pas l’efficacité globale de notre équipe.

Conclusion

Notre modélisation se veut hiérarchisée afin de pouvoir gérer séparément la tactique, la stratégie et les actions individuelles.

Les comportements finaux de nos agents sont évolués et coopératifs. Cependant, il subsiste des dommages collatéraux.

Nous avions envisagé diverses stratégies lors de la conception du modèle mais toutes n’ont pas été implémentées. Par exemple, la fuite d’un groupe en cas d’infériorité numérique au combat, tenter d’appâter des ennemis dans des pièges, etc…