RotoFight

Objectif général

Condition de rendu

Cahier des charges

1. Les tableaux
   Chaque tableau est spécifié dans un fichier au format texte. La taille horizontale et verticale n'est pas fixée. En revanche, le tableau doit être un rectangle entouré de murs.
   Voici un exemple de tableau très simple.

             WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
             W                                                        W
             W                                                        W
             W     WWWWWWWWW  WWWWWWWWWW    WWWWWW   WWWWW  WWWWWW    W
             W                                                        W
             W        O                                               W
             W                                                        W
             W                                                T       W
             W                                                        W
             W     WWWWWWWW   WWWWWWWWWW    WWWWWW   WWWWW  WWWWWW    W
             W                                                        W
             W                                                        W
             WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
           

   
   Dans ce tableau, W correspond à un mur (wall), O est l'emplacement initial du premier joueur (one) et T est l'emplacement initial du second joueur (two).
   Les touches '+' et '-' permettent de zoomer ou dé-zoomer sur le tableau, sachant que l'on ne peut pas zoomer si cela rend une partie du tableau non visible et que l'on ne peut pas dé-zoomer si chaque case fait moins de 16 pixels de côté.
   Le programme devra vérifier qu'un tableau est valide, rectangulaire et pas trop grand, avant de démarrer le jeu.
2. Joueurs
   Chaque joueur est symbolisé par un cercle (un peu épais) et des sourcils. Le joueur 1 est rouge, le joueur 2 est bleu.
   Chaque joueur est controlé par un ensemble de touches différents ce qui permet à deux joueurs humains de controler deux joueurs en même temps. (pour le mapping des touches débrouilez vous !)
   Les sourcils permettent d'indiquer le mouvement qu'est en train de faire le personnage. À vous de trouver une bonne façon de faire, mais cela doit permettre de toujours savoir dans quelle direction les coups d'épée vont partir. De plus, si le joueur n'appuie pas sur les touches de mouvement, au bout d'un certain temps, le personnage doit hausser les sourcils.
   Un joueur peut se déplacer vers la gauche, vers la droite ou sauter. Lors de la montée ou la descente suite à un saut, le joueur peut toujours déplacer le personnage pour contrôler un peu mieux le saut. Il n'est par contre pas possible de sauter de nouveau pendant un saut.
3. La gravité
   Le combat se situant dans l'espace, la gravité, qui représente le fait que le personnage soit attiré vers une certaine direction, est particulière. En fait, il existe plusieurs types de gravité, on choisit au début du jeu celle avec laquelle on veut jouer.
   
   • Gravité 1
     La gravité est vers le bas et ne change pas.
   • Gravité 1/2
     La gravité alterne entre gravité vers le haut et gravité vers le bas.
   • Gravité 1/2/3/4
     La gravité alterne entre gravité vers le haut, la droite, le bas et la gauche (dans cet ordre) de façon cyclique.
   • Gravité 360
     La gravité change par pas de 20 degrées jusqu'à atteindre 360, auquel cas, la gravité revient vers le bas
     (ce mode n'est pas demandé par défaut).
   
   Lorsque la gravité change, les sourcils des personnages bougent pour rester perpendiculaires à la direction de la gravité et toujours dans la zone haute du visage (comme des vrais sourcils).
4. Lancer des épées
   Comme tous les jeux de baston, le but est de « tuer » l'adversaire. Pour cela, chaque joueur peut lancer des épées pour essayer de toucher l'adversaire. Chaque fois qu'un joueur est touché, les deux sourcils se transforment en X pour indiquer que le joueur vient de perdre une vie. Le jeu recommence alors, en replaçant chaque personnage à sa position initiale. Le jeu est terminé dès qu'un joueur a perdu toutes ses vies.
   Les épées sortent des flancs du personnnage, dans la direction à laquelle il fait face (ou dans la direction dans laquelle il a bougé précédemment) et de façon perpendiculaire à la gravité.
   Une épée qui touche un mur disparait. Pour chaque joueur il y a un nombre maximal (configurable) d'épées visibles à tout moment durant le jeu. Si toutes les épées ont été tirées, alors le joueur doit attendre qu'une épée disparaisse pour pouvoir en tirer une nouvelle.
5. Commande
   Il est possible de paramétrer le jeu en ligne de commande à l'aide des options suivantes :
   • --level name: nom du fichier contenant le tableau du jeu ;
   • --gravity 1|2|4|360: permet de choisir la façon dont la gravité fonctionne ;
   • --gravity-phase value: durée en milisecondes entre deux changements de direction de la gravité ;
   • --swords value: nombre maximal d'épées à l'écran pour un même joueur ;
   • --player value: nombre de joueurs (optionnel) ;
   • --bonus: active le mode avec les bonus (optionnel).
   
   Les valeurs par défaut sont respectivement : le fichier default-level.txt, la gravité à 2, une gravity-phase à 10 000, 20 swords, player à 1 et pas de bonus.
6. Affichage
   Pour l'affichage, on vous demande d'utiliser la bibilothèque Zen 5.
   Attention à bien appeler la méthode render une seule fois par frame du jeu, pas plus sinon votre jeu va se transformer en sapin de noël (c'est la saison, c'est beau aussi, mais ça fait mal à la tête).
7. Amélioration possibles
   Attention, les autres parties du jeu devront être finies avant que vous commenciez à considérer les améliorations suivantes :
   
   • ajouter le mode gravité 360 ;
   • ajouter des murs cassables (par les épées) ;
   • ajouter un système de bonus qui permet d'acquérir des épés supplémentaires pendant un temps donné ;
   • ajouter un mode où l'on peut jouer seul (l'autre joueur est contrôlé par l'ordinateur).
   
   Toute autre amélioration sera considérée négativement.

Références

Conditions de rendu

• un répertoire src contenant les sources du projet ;
• un répertoire docs contenant le manuel de l'utilisateur (user.pdf) et le manuel qui explique votre architecture (dev.pdf) au format PDF avec une section dédiée aux améliorations/corrections apportées depuis la soutenance bêta ;
• un répertoire classes vide dans l'archive et qui contiendra les classes une fois compilées ;
• un répertoire lib contenant les libraries dont dépend l'application ;
• un jar exécutable rotofight.jar qui fonctionne avec java -jar rotofight.jar et donc qui possède un fichier manifest adéquat ;
• un fichier build.xml (écrit à la main) qui permet de :
  • compiler les sources (target compile) ;
  • créer le jar exécutable (target jar) ;
  • 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).

Notation

• Cas de 0 sans aucune correction (mort subite) :
  • projet non effectué en binôme (c'est-à-dire 2 personnes !) sans l'accord préalable de l'intervenant de TD ;
  • absence à la soutenance bêta ;
  • projet envoyé après la date ;
  • projet non déposé sur elearning ;
  • une archive qui n'a pas le bon nom ;
  • fichier d'archive dont l'extraction ne produit pas un répertoire qui a le bon nom ;
  • le projet utilise une ou des librairies externes autre que celles indiquées dans le sujet ;
  • présence de code copié / collé du net ;
  • l'utilisation de classes de java.io autre que InputStream/OutputStream, Reader/Writer et l'exception IOException ;
  • l'absence de javadoc, ou javadoc pas en anglais.
• Critères de notation :
  • Rémi Forax Junior (6 ans) doit pouvoir jouer à votre jeu ;
  • 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 ...) devra être donnée dans les documents PDF et aura également un poids très important dans la note ;
  • pas de méthodes de plus de 20 lignes ! ;
  • pas de duplication de code, et respect des principes de programmation objet ;
  • pas de variable globale;
  • pas de code inutile ;
  • présence des différents rapports et, par conséquent, orthographe correcte !
  • prise en considération des remarques faites lors de la bêta pour le rendu final.