SCI TP 1-2-3 : Systèmes multi-agents

Axel ANTOINE, Xavier STREEL

3 octobre 2016

1 TP1 : S.M.A Architecture générale classique

1.1 Introduction
Pour ce premier TP de simulation centrée individus, nous devons réaliser
un système multi-agents minimal, permettant à des agents de types particules
d’interagir entre eux en rebondissant dans une grille 2D discret.

1.2 Architecture
Chaque particule est un agent, et est régi par les mêmes règles de décision :
il peut se déplacer dans son voisinage de Moore (8 pixels voisins), selon sa
direction. celle-ci variant en cas de collision avec les murs (si l’on choisit un
environnement non torique et donc fini), ou en cas de collision avec une autre
particule. Dans ce cas, les deux particules échangeront leur direction.
Un autre objet, le SMA, s’occupe de placer initialement les agents dans une
grille et d’attribuer la parole à chaque agent lors d’un tour (ticks), et de notifier
la vue de rafraı̂chir l’affichage. Le tour de parole peut lui aussi être paramétré
de telle sorte à être équitable, aléatoirement ou alors séquentiel (injuste donc
pour les derniers agents). Il est à noter que les agents seront évalués de manière
séquentielle, jamais simultanément quel que soit le choix d’ordonnanceur voulu.

1.3 Ordonnanceur
Les graphiques ci-dessous montrent deux tours de paroles différents : fair et
sequential. Le nombre de ticks est de 30 et le nombre de particules est de 5.
En abscisse on retrouve les 30 ticks appelant les 5 agents.
En ordonnée, le numéro de l’agent appelé.

1.4 Questions performances

Nous avons testé plusieurs configurations afin de mesurer les performances
de notre système. Sur un PC de type “ultrabook” (core i5 5200u, 8Go ram),
avec un scheduling “fair”, dans une grille carrée de 200 cases, pour 100 ticks à

1
Figure 1 – Ordonnancement du choix des agents selon les modes faire et se-
quential

50ms de délai entre 2 ticks, nous devrions effectuer la simulation en 5 secondes.

Observations pour les cas ci-dessous :
— 5.000 particules : pas de ralentissements observés ;
— 10.000 particules : pas de ralentissements observés ;
— 20.000 particules : ralentissements, la simulation prend environ 7s au lieu
de 5.
Pour une grille de 300*300 cases, avec toujours 20.000 particules, la simula-
tion ralentit également (6.5s au lieu de 5).
10.000 particules semble être une limite raisonnable sans ralentissements ob-
servés pour cette configuration. Nous pourrions éventuellement investiguer plus
en détails les différentes tâches afin d’analyser les méthodes les plus coûteuses
sachant que l’affichage graphique est plus coûteux que le calcul des collisions.

1.5 Conclusion
Nous avons implémenté un système multi-agents minimal fonctionnel. L’ob-
jet du modèle de type agent a été abstrait au maximum afin de pouvoir adap-
ter notre solution très facilement pour de nouveaux type d’agents à l’avenir.
De même, le choix de développer une interface graphique pour choisir les pa-
ramètres nous a paru judicieux afin de pouvoir modifier rapidement ceux-ci sans
devoir relancer le programme. De plus, ces paramètres peuvent être très facile-
ment gérés en interne, car nous avons utilisé la réflexivité de Java pour générer
et gérer le formulaire d’édition des paramètres, encore une fois dans le but de
pouvoir s’adapter facilement aux changements lors de prochaines itérations.

2
2 TP2 : S.M.A. Travail sur les comportements
2.1 Introduction
Cette semaine, nous avons travaillé plus en détails sur les comportements
des agents, en réalisant un système multi-agents comportant cette fois-ci deux
types d’agents, les proies et les prédateurs.
Voici les régles de la simulation :
Les deux agents peuvent se reproduire après un certain nombre de tours,
seulement s’ils ont pu bouger lors de ce tour. Les proies ont un temps de gestation
plus court que celui des prédateurs, de manière à proliférer plus rapidement.
Les prédateurs mangent les proies pour survivre. Après un certain temps sans
manger, ces derniers meurent.
L’objectif principal de cette simulation est de trouver les paramètres initiaux
permettant à la simulation de perdurer dans le temps : c’est à dire, les deux
agents survivent indéfiniment.

2.2 Architecture
Nous avons repris le code de notre projet précédent, celui-ci ayant déjà été
abstrait le plus possible tant au niveau du modèle (classe abstraite Agent), qu’au
niveau de l’interface et des paramètres de simulation.
Deux classes étendent maintenant la classe Agent, la classe Fish et la classe
Shark, modélisant le comportement de nos deux entités.
Nous avons gardé l’interface du premier TP en rajoutant 2 fenêtre pour
afficher 2 graphes temps-réel, la courbe d’évolution des deux espèces dans le
temps ainsi que la la courbe du rapport entre le nombre de poissons et de
requins. Les paramètres spécifiques aux deux entités (nombre d’entités initiales,
temps de gestation et d’extinction sans manger) ont également été ajoutés à
notre fenêtre de paramètres.

2.3 Simulation
2.3.1 Tour de parole
A chaque tour de paroles, la grille du jeu est balayée pour récupérer l’en-
semble des agents actuellement en vie. Quel que soit l’ordonnancement choisi
(les mêmes qu’au premier TP, à savoir fair, sequential ou random), les agents
effectuent leur comportement l’un à la suite de l’autre. De ce fait, il est forte-
ment possible qu’un requin R effectue son mouvement avant un poisson P alors
que ce même poisson P n’ait pas encore eu l’occasion de parler durant ce tour.
Ainsi, quand vient le tour au poisson P de prendre la parole, il lui est impossible
puisqu’il est mort. La condition d’être en vie est nécessaire pour qu’un agent
puisse décider.

3
2.3.2 Comportements
Poisson Les poissons effectuent leur tour de parole dans l’ordre suivant :
1. Si le poisson vient de naı̂tre alors, on lui attribue une autre couleur (pour
le différencier des adultes).
2. Si il peut bouger, alors il effectue un mouvement aléatoire parmi les
directions libres. (Voisinnage de Moore, 8 voisins.)
(a) Si le poisson est adulte alors il peut se déplacer. De plus, s’il se déplace
et que sa période de gestation est atteinte, il se donne naissance à un
nouveau poisson à son ancienne position
(b) Après s’être reproduit, son temps de gestation est réinitialisé

Requin Le comportement du requin est plus complexe que celui du poisson,

même s’il possède quelques caractéristiques communes à ce dernier :
1. Si le requin vient de naı̂tre alors, on lui attribue une autre couleur (pour
le différencier des adultes).
2. Si le requin a atteint sa période maximale sans manger, il meurt.
3. Le requin cherche des poissons dans son voisinnage de Moore. Si il en
trouve au moins un :
(a) Le requin choisit aléatoirement une victime parmi le(s) poissons voi-
sins trouvés, et le mange. Le poisson meurt et est retiré du simulateur.
Le requin se déplace et prend la palce du poisson mort.
(b) Après avoir mangé une proie, son compteur de faim est réinitialisé.
(c) Si sa période de gestation est atteinte ou dépassée, il se reproduit.
(Un nouveau requin apparaı̂t à l’ancienne position du requin parent
avant son déplacement.)
(d) Après s’être reproduit, son temps de gestation est réinitialisé
4. Si il ne trouve pas de poissons mais qu’il peut bouger, alors il effectue un
mouvement aléatoire parmi les directions libres. (Voisinnage de Moore,
8 voisins.)
(a) Si le requin a pu bouger et que sa période de gestation est atteinte ou
dépassée, alors il se reprodit (Un nouveau requin apparaı̂t à l’ancienne
position du requin parent avant son déplacement.)
(b) Après s’être reproduit, son temps de gestation est réinitialisé

2.4 Résultats
Nous avons décidé d’afficher les courbes d’évolutions des poissons et requins
en temps réel.

4
2.4.1 Performance de calculs
Nous avons mené nos tests sur un environnement carré de 150*150 cases,
soit 22500 cases, en spécifiant l’environnement comme étant torique. Peu im-
portent les paramètres choisis, nous obtenons des performances relativement
satisfaisantes. Pour un délai entre les ticks nul, nous parvenons à exécuter et
afficher environ 17 itérations par seconde. En désactivant l’interface graphique,
nous arrivons a exécuter environ 20 ticks par seconde. (Mesures réalisées sur un
ultrabook core i5-5200u et 8Go RAM).

2.4.2 Performances des simulations

Simulation 1 Nous avons d’abord testé les paramètres suivants :
— Poisson : breedTime à 2 et nombre initial à 300
— Requin : breedTime à 5, starveTime à 5 et nombre initial à 10
Certaines simulations perdurent dans le temps (nous considérons une simulation
comme perdurant dans le temps lorsque les deux espèces survivent après 10.000
ticks), mais pas toutes. Souvent, les requins finissent par disparaı̂tre, entrainant
la surabondance de poissons.

Simulation 2 Nous avons tenté ensuite les paramètres suivants :

— Poisson : breedTime à 2 et nombre initial à 500
— Requin : breedTime à 8, starveTime à 3 et nombre initial à 100
Ici, nos paramètres semblent faire perdurer la simulation dans le temps. (10
seeds différents testés.) Nous considérons ce modèle comme stable. Nous avons
également testés avec succès ces paramètres dans un environnement non torique.
L’ordonnancement ”random” nous donne logiquement une simulation moins
prévisible à l’oeil, mais perdure également. Enfin, l’ordonnancement ”sequen-
tial” tourne également, et nous semble indifférenciable du ”fair”.

Figure 2 – Variation du nombre d’agents poissons et requins dans le temps

(paramètres cités ci-dessus, environnement torique et ordonnanceur ”fair”

2.5 Conclusion
Notre système multi-agents comporte deux types d’agents qui interagissent
directement l’un sur l’autre. De ce fait, à partir de règles simples et paramétrables,
il est possible d’obtenir des convergences vers plusieurs états possibles du système,

5
de l’environnement. Le premier où l’océan est rempli de poissons, puisqu’ils
peuvent survivre seuls. Le deuxième, la mort des deux espèces, puisque les re-
quins ne peuvent vivre sans poissons. Enfin, un état, qualifié de stable, quand
l’océan oscille entre une plus grande quantité de poissons ou de requins sous
forme de sinusoı̈de, le cycle de la vie de notre environnement. Celui-ci est très
bien représentée sous forme d’ellipse quand on affiche le nombre de poissons en
fonction du nombre de requins au cours de la simulation.

6
3 TP3 : SMA, Avatars et motion planning
3.1 Introduction
Ce TP s’oriente plus vers un simple jeu qu’une simulation. Sur le même
principe que le jeu Pacman, un Avatar, contrôlé par le joueur humain, doit
récupérer 4 pièces (Defenser) pour faire apparaı̂tre une porte (agent Winner) et
sortir du labyrinthe formé par des murs (agent Wall) pour gagner la partie. Si
l’avatar se fait attraper par un chasseur (agent Hunter), la partie est perdue.
Pour modéliser ce jeu, on peut utiliser un systême multi-agents.

3.2 Comportements
3.2.1 Génération du labyrinthe
Pour générer le labyrinthe, nous remplissons de murs une ligne sur deux les
cases lorsque le tirage d’un nombre aléatoire n’est pas modulo 3. Ceci devrait en
effet permettre (statistiquement parlant) d’avoir les lignes bien remplies (pro-
bablement continues en général) avec des trous. Pour combler les autres lignes
encore blanches, on rempli une case si le tirage aléatoire est modulo 7 (on en
veut moins) ET qu’il n’y a pas de case vide au-dessus et au dessous. En effet,
on veut favoriser la création de couloirs. Ce comportement assez simple permet
d’avoir un environnement aléatoire et acceptable en terme de labyrinthe.

3.2.2 Avatar
L’Avatar est l’agent principal du jeu. Le joueur humain le contrôle grâce
au clavier (Z,Q,S,D) et peut le déplacer sur les cases vides de l’environnement.
A chaque fois que l’Avatar change de case, il calcule lui-même l’algorithme de
Dijkstra afin que les chasseurs puissent récupérer le tableau des distances.
Afin de faciliter le contrôle du personnage, nous avons implémenté un buffer
de direction permettant d’anticiper et faciliter la navigation dans le labyrinthe, à
la manière du jeu pac-man. L’Avatar se déplaçant vers la droite et l’utilisateur
appuyant sur la flèche du bas, et qu’il n’est pas possible de se déplacer vers
le bas actuellement (il se heurte à un mur), le système va retenir le choix de
l’utilisateur jusqu’à ce que l’Avatar puisse se déplacer vers le bas, et continuer
à avancer vers la droite tant qu’il ne peut pas changer de direction.

3.2.3 Hunter
Les hunters possèdent tous le même comportement. Leur objectif est d’at-
teindre l’agent Avatar pour le faire perdre la partie. Ils se rapprochent de celui-ci
en utilisant le plus court chemin grâce à la matrice des distances calculé dans
l’Avatar lui-même grâce à l’algorithme de Dijkstra. Ces agents se déplacent bien
moins rapidement que l’Avatar. Cependant, nous avons rajouté une règle pour
corser la difficulté : à chaque Defender attrappé par l’Avatar, la vitesse des
Hunters est augmentée de 1, afin d’augmenter progressivement la difficulté.

7
3.2.4 Defender
Un Defender est un agent immobile, que l’Avatar doit attrapper afin de
gagner la partie (après 4 Defenders attrapés). Nous avons choisi de les faire
apparaitre au centre du labyrinthe, afin qu’il soit plus compliqué de les attraper
(sans se faire avoir par un Hunter) que si ils étaient apparus aux extrémités.

3.2.5 Winner
Une fois 4 Defenders attrappés, un nouveau agent unique apparait, l’agent
Winner. Immobile lui aussi, l’Avatar devra se déplacer dessus pour gagner la
partie.

3.3 Conclusion
Nous avons basculé cette semaine sur un système multi-agents se présentant
comme un jeu, basique certes mais tout à fait fonctionnel, ce qui nous laisse
entrevoir toutes les possibilités que ces systèmes peuvent apporter dans un jeu-
vidéo plus poussé.
Nous avons réutilisé le code de la semaine précédente à beaucoup d’aspects,
nous contentant d’adapter les paramètres dans l’interface pour les spécificités
de ce nouveau environnement. Nous restons également sur les mêmes bases tant
au niveau de l’interface que du modèle, la classe abstraite Agent n’ayant pas été
modifée, les nouveaux agents héritant d’Agent comme précédemment.
Le point le plus délicat du TP fut finalement de calculer correctement l’al-
gorithme de Dijkstra, ce fut aussi le point le plus enrichissant.
R : redémarre une partie
space : play/pause le jeu
nbHunters = nombres de chasseurs ;
SpeedHunter = vitesse des chasseurs ;
DefenderLifetime = durée de vie d’un défenseur (ticks) ;
DefenderApparition = délai d’apparition défenseur(ticks) ;
DefenderVulnerability = durée de la vulnérabilité (ticks) ;