:: Enseignements :: Master :: M1 :: 2010-2011 :: Java Avancé ::

Bots Battle

Bots Battle est une simulation de combat entres robots. Les robots évoluent dans une arène surpeuplée. Ils ont donc naturellement décidé de s'entre-tuer à l'aide de bombes. L'arène est représentée par un damier fixé au départ du jeu par l'utilisateur. Il existe deux types de cases, les cases vides et les murs. Les murs sont des cases inaccessibles. Le jeu se déroule au tour par tour. Durant un tour de jeu, chaque robot pourra effectuer un déplacement sur une case adjacente ou poser une bombe (mais pas les deux). Les déplacements en diagonale sont interdits. Les bombes posées explosent au bout d’un nombre de tours fixé par le robot à la pose de la bombe. Quand une bombe explose, elle détruit tous les robots qui se situent à l'horizontal ou à la verticale de cette bombe. Toutefois, le souffle de la bombe est arrêté par un mur. Si une autre bombe se situe sur la trajectoire de l'explosion, elle explose elle aussi.

Mise en place

On vous demande d'écrire le jeu, de manière objet. Le jeu doit être paramétrable, et vos projets doivent être compatibles entre eux, au sens défini plus loin dans le sujet du projet. On vous impose certaines contraintes sur l'architecture du projet. Votre projet aura une interface graphique. Des classes vous facilitant le developpement de cette interface graphique vous sont données (leur utilisation est obligatoire).

Deroulement technique

Nous détaillons maintenant le déroulement technique du jeu. Au départ, le jeu, qu'on suppose installé dans le répertoire botsBattle, est lancé par l'utilisateur comme suit:
java fr.umlv.botsBattle.StartGame -arena arena.txt -robotsDir robots -radarSize 3 -armyLimit 4 -turnDuration 1000 -bombDuration 3

L'option -arena sur le ligne de commande permet de spécifier un nom de fichier texte contenant la description de l'arêne. Un exemple vous est donné plus bas.
L'option -robotsDir permet de spécifier le nom d'un sous-répertoire de botsBattle qui contient la description des armées de robots qui vont s'affronter sur l'arêne. Une armée de robots doit y être décrite dans un fichier au format jar, contenant en particulier une classe implantant l'interface Bot. Cette classe (qui peut éventuellement être reliée à d'autres), contient la description du comportement de chaque robot de l'armée. La classe devra posséder une annotation @BotImage dont la valeur est le nom d'un fichier image: ce fichier image sera utilisé pour représenter graphiquement chaque robot de l'armée dans l'arêne. Elle devra également contenir une annotation @BotsNumber, dont la valeur (un entier) représente le nombre de robots qui composent l'armée. Le jar doit contenir un MANIFEST dont l'entrée Bot-Class est le nom complet de la classe implantant l'interface Bot.
L'option -radarSize permet de spécifier un champ de vision pour chaque robot appartenant au jeu. Pour prendre sa décision d'action, chaque robot voit autour de lui, avec son radar, dans un rayon déterminé par la valeur de ce paramètre
L'option -armyLimit précise le nombre maximum de robots que peut creer une armée. Le nombre de robots pour une armée est donné par min(armyLimit, x), où x est la valeur de l'annotation @BotsNumber pour l'armée en question.
L'option -turnDuration exprime, en millisecondes, la durée d'un tour. Si par exemple cette durée est fixée à 1000 millisecondes, alors chaque robot a 1 seconde à chaque tour pour informer le jeu de l'action qu'il veut exécuter. Passé ce délai, le jeu passe au tour suivant.
L'option -bombDuration exprime le nombre de tours qui s'écoulent entre la pose et l'explosion des bombes.

Si l'utilisateur oublie une option, le jeu doit lui donner une valeur par défaut.

Une fois le moteur du jeu démarré, il consulte le répertoire contenant les descriptions des différentes armées, et par introspection, instancie les différentes armées, et place les robots au hasard sur l'arène. Chaque robot sera implanté par un processus léger séparé, dont le jeu est responsable de la gestion (en particulier, c'est au jeu de créer/démarrer/arrêter les processus légers qui exécutent le code des robots). Un contexte d'évolution est fourni par le jeu à chaque robot, à sa création (voir les interfaces qui vous sont fournies). En particulier, le contexte contient une méthode radar() qui permet au robots de consulter ses alentours. Chaque robot peut à n'importe quel moment demander au jeu d'exécuter une action (poser une bombe, se déplacer). La demande d'action est bloquante passive. Elle est prise en compte à chaque tour par le jeu, dans l'ordre où elle est arrivée. Par exemple, si un robot R1 demande une action pour le tour de jeu suivant avant un autre robot R2, alors le jeu garanti que l'action de R1 sera exécuté avant celle de R2. Un robot peut demander au jeu des informations sur le jeu, par exemple sur les autres robots de la même armée (voir les interfaces qui vous sont données).

Le jeu reconsulte periodiquement le répertoire contenant les descriptions des robots. Si une nouvelle armée y est apparue, alors le jeu la créé. Ainsi, on peut rajouter des armées dans le jeu à n'importe quel moment de son déroulement, simplement en ajoutant un fichier dans le répertoire de description des armées. La période de consultation du repertoire, exprimée en nombre de tours, est fixée par l'option -dynamic de la ligne de commande. Elle doit valoir 0 par défaut (pas de consultation du repertoire une fois le jeu démarré).

Le jeu se termine quand il ne reste plus qu'une armée dans l'arêne et que toutes les bombes ont explosées (remarque: il est possible que des jeux ne se terminent jamais (pas de gagnant) et d'avoir des parties qui terminent sans gagnant).

A tout moment de l'exécution du jeu, l'utilisateur, en tapant sur une touche, doit pouvoir demander la sauvegarde de l'état courant du jeu pour l'arrêt et le reprendre plus tard. Des options au lancement du jeu doivent permettre de reprendre un jeu qui a été sauvegardé.

Implantation

Il vous est demandé d'écrire :

Au moins une implantation d'armée.
Toutes les classes nécessaires à la gestion du moteur du jeu, ainsi que d'utiliser une bibliothèque permettant un rendu graphique du jeu (située ici).
Les classes de chargement et de lancement du programme.
Quelques damiers de test.
La compatibilité entre votre jeu et les robots des autres groupes doit être assurée (votre jeu doit fonctionner avec n'importe quelle description d'armée, y compris celle des autres projets).
Vous devez utiliser la sérialisation pour la sauvegarde d'un jeu et sa reprise. Vous devez activer l'architecture de sécurité de la plateforme d'exécution pour interdire aux classes composant les robots de créer des processus légers, d'acceder au système de fichiers, ou de faire de l'introspection.
Le jeu doit utiliser l'introspection pour analyser les annotations des classes d'armées, et instancier ces classes
Vous écrirez un code commenté ET documenté au format Javadoc. On demande qu'il soit écrit en anglais (commentaires compris).

De nombreuses améliorations sont possibles (comme, par exemple, la présence de mur destructible par une bombe ou d'autres implantations de robots). Laissez votre imagination parler! Cependant, avant toute amélioration, concentrez-vous sur l'implantation de ce qui est imposé par le sujet, sur le caractère objet et bien codé de vos sources ainsi que sur la documentation.

Il vous est interdit de modifier les codes sources qui vous ont été donnés.

Interface du projet

Attention : les sources sont données ici à usage consultatif, vous ne devez pas les inclure dans votre projet, utilisé le jar pour cela.

Conditions de rendu

Le projet est à rendre en déposant votre projet dans les deux repertoires portant les noms des deux binômes dans la zone de dépôt suivante sur etudiant (accessible par FTP) :
/home/shares/igm/prof/Projet_Java_M1_02012011
avant le 2 janvier 2011, 23h59 (le dépôt est fermé en écriture automatiquement). Le format de rendu est une archive au format zip contenant:

un répertoire src contenant les sources du projet et les éventuelles ressources (images, sons, etc.) à recopier à côté des classes;
un répertoire docs contenant le manuel de l'utilisateur (user.pdf) et le manuel qui explique votre architecture (dev.pdf) au format PDF;
un répertoire classes vide dans l'archive et qui contiendra les classes une fois compilées
un jar exécutable BotsBattle.jar qui fonctionne avec java -jar BotsBattle.jar et donc qui possède un fichier manifest adequat;
un build.xml qui permet de
- compiler les sources (target compile)
- créer le jar exécutable (target jar)
- executer votre projet (target run)
- générer la javadoc dans docs/doc (target javadoc)
- nettoyer le projet pour qu'il ne reste plus que les éléments demandés (target clean)

Cette archive zip aura comme nom Nom1Nom2_BotsBattle.zip, où les noms sont ceux des membres du binôme par ordre alphabétique. L'extraction de cette archive devra créer un répertoire de nom Nom1Nom2_BotsBattle pour contenir tous les éléments demandés ci-dessus.

Notation

Cas de 0 sans aucune correction:
- projet rendu par mail
- projet non effectué en binôme (i.e. 2 personnes !) sans l'accord préalable de l'intervenant de TD. Un seul projet pour éventuellement être effectué seul (en cas de nombre impair d'étudiants)
- projet rendu après la date
- reception d'une archive qui n'a pas comme nom Nom1Nom2_BotsBattle.zip, où les noms sont ceux des membres du binôme par ordre alphabétique
- fichier d'archives dont l'extraction ne produit pas un répertoire dont le nom est Nom1Nom2_BotsBattle
- fichier d'archive foireux (vérifiez l'extraction après le dépôt)
- l'absence de Java Doc
Base de la notation:
- la propreté et la lisibilité du code auront un poids très important dans la note
- l'architecture que vous aurez définie (interfaces, classes abstraites, concretes ...) devra être donnée dans les documents PDF et aura également un poids très important dans la note
- la réutilisabilité et donc la factorisation de votre code (e.g. peut-on facilement faire des évolutions sans tout refaire dans votre code)
- la présence de code inutile
- les différents rapports et, par conséquent, l'orthographe !
- la soutenance (dirigée entièrement par vous!)