Ant Hill
Année 2007-2008
Enseignants: G. Blin(), E. Duris, R. Forax
gblin at univ-mlv.fr, duris at univ-mlv.fr, forax at univ-mlv.fr Présentation générale
Le but de ce projet est de réaliser un jeux permettant de programmer une fourmilière et de voir celle-ci évoluer au cours du temps.
Travail demandé
Il faut créer trois choses: le jeu en lui même, un ensemble de classe et d'interface visible par dieu pour que celui-ci puisse jouer. Il ne faut pas que dieu puisse essayer de contourner les règles. Et un dieu particulier qui joue avec votre jeu.
Fonctionnement de la fourmilière
Dieu est un objet1 dont la classe est indiquée lors du démarrage du jeu. Il possède un ensemble de méthode qui seront appelé par le jeu pour lui permettre de savoir ce qui se passe dans la fourmilière.
Dieu connaît la fourmilière et sait lorsqu'une nourriture est créer (pas si celle-ci est régurgiter et sans savoir où elle apparaît), où se situe chaque fourmi, si la reine est morte, de plus il sait certaines caractéristiques du jeu comme le nombre d'insectes du jeu, combien cela coûte en point de
nourriture de créer une fourmi, etc.
Lors du démarrage du jeu, le jeu appellera la méthode run de dieu avec en paramètre la fourmilière.
Si la reine est morte, dieu devra arrêter de jouer :) Dieu sait que:
La fourmilière permet de savoir quel est la taille de la fourmilière (largeur x hauteur en case) et l'ensemble des choses qu'il y a sur une case particulière de la fourmilière.
Une fourmi peu se déplacer, manger de la nourriture ou régurgiter celle-ci.
Une fourni possède un certain nombre de point de vie que dieu peut connaître pour chaque fourmi et meurt si son nombre de point de vie atteins zéro.
La reine des fourmis (il n'y en a qu'une) est une fourmi classique qui peu en plus créer de nouvelles fourmis.
Un insecte peu de déplacer et enlève des points de vie à l'ensemble des fourmis situer sur sa case (lorsque la fourmi rentre sur une case occupée par un insecte ou lorsqu'un insecte rentre sur une case occupée par des fourmis). Un insecte ne peut pas se déplacer tant qu'il reste des fourmis sur la case sur laquelle il est.
La nourriture est quelque chose qui est sur une case qui ne se déplace pas et qui peut être mangé par
1 Et Java son prophète ...
où régurgiter par les fourmis. La nourriture apparaît périodiquement, s'il n'y en a pas déjà, sur une des cases fixées au démarrage par le serveur (mais inconnu de dieu). La nourriture disparaît lorsqu'elle est mangé par une fourmi, ré-apparaît si une fourmi la régurgite.
Une fourmi possède un certains nombre de point de nourriture correspondant au nombre de fois que celle-ci a mangé de la nourriture. Chaque fourmi peut ingéré qu'un nombre fini de nourriture fixé lors du démarrage et connu de dieu.
Si la reine des fourmis mange de la nourriture, elle peut utiliser cette nourriture pour créer de nouvelle fourmi.
Le déplacement des choses qui se déplace se fait en demandant à la chose de se déplacer soit à gauche, à droite, en haut où en bas. Si un mur bloque le mouvement, la chose ne se déplacera pas et ne signalera pas d'erreur.
Lawrence
Ce projet requiert un affichage graphique. Pour cela vous utiliserez la bibliothèque graphique lawrence disponible à l'adresse suivante:
Un peu avant la soutenance
Il vous sera demander de créer un dieu pour un jeu d'un autre binôme.
Le but sera de créer un dieu qui triche et qui arrive à faire le maximum de chose interdite (planter le programme fait partie des choses interdites :)
Donc pour vous qui développé aussi le jeu, veillez à ce que votre logiciel ne puisse pas planter, est une architecture de sécurité, etc.
Détail du rendu
Ce projet est à faire en binôme (cela veut dire deux personnes pas trois ni une), un seul groupe de 3 personnes est admis. Le rendu s'effectuera par mail sous forme d'une pièce jointe au format ZIP contenant l'ensemble des programmes et documents. Le mail devra être envoyé avant minuit aux trois adresses données au début de ce document. Le fichier s'appellera nom1_nom2.zip - nom1 et nom2 étant les noms respectifs des personnes formant le binôme triés dans l'ordre alphabétique - et devra être envoyé au plus tard le 4 mars à 23h59:59.
Voici les noms des répertoires et fichiers qui doivent être contenus dans l'archive zip.
1. un fichier readme.txt indiquant comment compiler le programme, comment exécuter le frontal, où se trouve la documentation, etc.
2. un fichier Ant build.xml permettant de compiler les sources du programme, et de créer le jar javaodb-impl.jar ainsi que le jar exécutable javaodb-ui.jar dans bin.
3. un répertoire src contenant l'ensemble des sources (.java), en utilisant un ou plusieurs paquetages.
4. un répertoire test contenant l'ensemble des tests unitaires (.java) au format JUnit 4 (junit.org), en utilisant un ou plusieurs paquetages. Il doit y avoir au moins un test pour chaque stratégie que vous avez implantée.
5. un répertoire classes contenant l'ensemble des classes (.class) correspondant aux sources et
aux tests.
6. un répertoire lib contenant les jars javaodb-lib.jar, javaodb-impl.jar et javaodb-ui.jar 7. un répertoire docs contenant deux documents au format PDF :
1. La documentation utilisateur user.pdf contenant en plus des informations classiques (comment compiler, exécuter, etc.) une description de l'application graphique, et comment l'utiliser.
8. La documentation développeur dev.pdf contenant :
• Une diagramme de classe (UML) de chaque paquetage 9. Les stratégies que vous avez utilisées dans votre implantation
1. pour gérer les différentes sémantiques 10.pour gérer le mixage des sémantiques
11.pour gérer les transactions imbriquées
12.pour gérer les drops des classes si des transactions existent déjà.
Vous profiterez de la description de chaque stratégie pour fournir une description détaillée de chaque classe que vous avez implantée. Évitez les copier/coller de la javadoc, essayer plutôt de décrire en français les classes par leur responsabilité (ce qu'elles font et comment elles le font) et dans un ordre logique. Pour expliquer les enchaînements d'appels entre les objets, vous utiliserez des diagrammes de séquences (UML).
13.Une liste des bugs connus (s'il y en a) détaillant le scénario permettant de générer un bug ainsi que la raison pour laquelle celui-ci se produit.
En plus des deux documents, le répertoire docs devra contenir un sous répertoire api contenant la documentation complète du logiciel au format javadoc.
