La visualisation

Figure: Visualisation des plans de l'agent

Nous avons été assez rapidement confrontés au problème de la visualisation des actions de nos agents: dans un milieu dynamique où les conditions de jeu sont rapidement changeantes, il est nécessaire à l'expérimentateur de posséder une bonne idée des buts de ses agents et des paramètres mis en uvre dans les actions entreprises (notamment, les paramètres physiques de localisation). Typiquement, il est nécessaire de connaître le chemin qu'un agent désire emprunter pour se rendre à un point donné et la représentation textuelle seule est insuffisante pour ce type d'informations. Dans un univers discrétisé, la visualisation de telles informations est relativement aisée. Mais dans un environnement non discrétisé comme c'est le cas pour la simulation de la RoboCup, il est nécessaire d'opter pour une visualisation imparfaite (complétée au besoin par des informations textuelles) et spécifique ou alors de développer un mécanisme de visualisation vectorielle et symbolique (le symbolisme est notamment nécessaire pour garantir la généricité de la visualisation et le maintien d'une information dynamique). Nous avons opté pour l'implémentation d'un mécanisme de définition, de maintenance et d'affichage d'objets vectoriels, qui peuvent être initialisés et utilisés par l'un ou l'autre des composants de notre agent.

En raison de l'aspect dynamique et mobile des symboles à visualiser (joueur, balle, chemins, vecteurs, angle de vision, etc.), nous avons mis en place deux systèmes de coordonnées, le premier étant cartésien et absolu (l'origine étant le centre du terrain) et le deuxième étant polaire et relatif à une origine. Un objet graphique utilisant des coordonnées polaires doit hériter de la classe PolarObject, qui possède toutes les méthodes nécessaires à la maintenance d'une origine et à la transformation des coordonnées relatives polaires en coordonnées absolues cartésiennes.

Nous avons souhaité introduire une fonctionnalité supplémentaire à notre implémentation de la visualisation graphique: celle de l'indépendance du médium. Les mécanismes de visualisation se limitent souvent à un seul paradigme de représentation (écran d'ordinateur ou image bitmap, affichage vectoriel PostScript, sortie brute des coordonnées dans un fichier texte, etc.). Nous considérons ce mécanisme comme limitatif, notamment car la transformation d'un paradigme à l'autre est souvent destructive ou approximative. Ainsi, nous avons développé un mécanisme d'abstraction du support d'affichage nous permettant:

Figure: Exemple de hiérarchie d'objets graphiques

1. de définir des primitives géométriques de bas niveau, indépendantes du support d'affichage ;
   

2. de définir des interfaces entre le support d'affichage (ou périphérique) et les primitives graphiques de bas niveau: nous avons défini des correspondances entre les primitives d'affichage bas niveau et les primitives d'affichages spécifiques, mais aussi des mécanismes d'initialisation du support graphique, d'allocation et de cache de couleurs ;
   

3. de définir des objets graphiques de haut niveau, symboliques et faisant appel aux primitives graphiques de bas niveau pour s'afficher sur le support graphique.
   

Nous avons déjà implémenté un périphérique d'affichage basé sur les primitives graphiques de la bibliothèque Xlib, qui permet de visualiser les objets graphiques dans une fenêtre X11. Nous envisageons le développement d'un périphérique PostScript (dont l'utilité prend tout son sens dans la production de documents écrits), d'un périphérique MPEG (par exemple en utilisant la bibliothèque libfame, disponible sur le web à l'URL http: //fame.sourceforge.net/libfame/overview/), afin de produire de manière native des séquences animées (fichiers vidéo) et d'un périphérique OpenGL, permettant une visualisation en trois dimensions.