RAPPORT A3P Equipe 2K I. NOTRE JEU • Créateurs : LIM Alain & SALAHKAR Vincent • Thème : Dans un fort médiéval, notre héro -un singe- doit libérer des prisonniers. Son parcours sera alors semé d'embûches illustrées par des énigmes auxquelles le joueur devra répondre • Résumé du scénario : Tout commence à l’entrée du château fort. Le héros, vous –un singe-, doit retrouver des prisonniers. Ces derniers sont cachés quelque part dans le fort, et votre but est de les délivrer. Comment allez-vous vous y prendre ? Dans chaque salle, vous aurez des énigmes ; à la fin de chaque énigme, vous aurez le choix entre deux nouvelles directions et ce, à chaque salle. Bien entendu, un seul itinéraire est possible et là se trouve la difficulté du jeu. • Les lieux : • Les items : En fonction de chaque salle, ils seront différents. • Situations gagnante//perdante : Trouver les prisonniers grâce au bon itinéraire ; si le mauvais est emprunté, le jeu recommence depuis le début. • Le site web du jeu : www.esiee.fr/~salahkav/ • Sources : aide de Naji ASTIER, et images dans livre « Vivez l’aventure » II. LES EXERCICES ZUUL-BAD Organisation du binôme : nous avons chacun fait les exercices de notre côté, puis mis en commun nos projets. Ils se faisaient en simultané de manière à s’entraider. • Exercice 7.1 : What does this application do ? Zuul-bad est un jeu “mal” codé en java, d’où l’extension bad. Ce jeu permet au joueur d’explorer un monde grâce à des déplacements basiques. What commands does the game accept ? Il accepte des commandes comme: go, help, look, quit. What does each command do ? - - go permet un déplacement, il doit être suivie d’une direction (north, east, south, west). Exemple : « go north » permet un déplacement vers le nord et ainsi de suite… help permet d’obtenir de l’aide. look permet d’acquérir la description de la salle où le joueur se trouve. quit permet de quitter le jeu. How many rooms are in the scenario ? Il y a 5 salles dans le Zuul-Bad initial : outside // theatre // pub // lab // office. • Exercice 7.2 - Game : C’est la classe principale du jeu. C’est la classe qui lit les commandes afin de les exécuter. Elle tourne en boucle jusqu’à ce que la commande « quit » soit entrée. - Room : « Salle » en anglais, c’est la classe qui crée les salles et initialise leurs sorties menant alors aux autres. - Command : C’est la classe qui permet au joueur d’entrer une commande. Cette dernière est divisée en deux : le premier et le second mot. En effet, elle vérifie si celles-ci sont valides, ou non. - CommandWord : Les commandes valides pour le jeu doivent être rangées dans cette classe. Par exemple nos commande go, help, look et quit sont dans cette classe. - Parser : C’est la classe qui interprète les commandes de l’utilisateur. Elle lit les mots entrés, les analyse et leurs attribue leur fonction. • Exercice 7.2.1 La classe Scanner sert à lire des entrées. • • Exercice 7.3 (voir le I.) Exercice 7.4 Méthode createRooms permettant la création des salles et l’initialisation de leurs sorties. • Exercice 7.5 Méthode permettant au joueur de savoir où il se trouve et quelles sont les sorties à sa disposition. • Exercice 7.6 getExit est un accesseur permettant d’observer les sorties de chaque salle. • Exercice 7.7 Création de la méthode getExitString permettant de retourner les sorties disponibles. • Exercice 7.8 Implémentation du nouveau code de la classe Room avec une utilisation de la HashMap. Celle-ci associe des une Room à chaque direction ce qui forme le tableau associatif qu’est la HashMap. Grâce à celle-ci, la nouvelle méthode setExit est simplifiée, et l’ajout de sorties diverses et variées est alors possible (frontRight//dive//tunnel etc.) • Exercice 7.9 keySet crée un objet Set avec toutes les keys dans l’objet Hashmap. • Exercice 7.10 Accesseur permettant de retourner les sorties contenues dans le keySet, à l’aide d’une String. • Exercice 7.11 On ajoute à la classe Room une nouvelle méthode : getLongDescription qui rassemble toutes les méthodes de description du lieu, à savoir la position, et les sorties disponibles. Et à la classe Game : • Exercice 7.14 Ajout de la commande look permettant d’obtenir la description de la sale dans laquelle le joueur se situe à la fois dans CommandWords : Et dans la classe Room : Méthode processCommand Méthode look : • Exercice 7.15 Ajout d’une méthode « eat » permettant de manger. Elle ne fait en réalité qu’afficher un message. De la même manière que « look », on rajoute la méthode « eat » dans CommandWords et dans la méthode processCommand. • Exercice 7.16 Utilisation de showAll de manière à afficher le listage complet des nouvelles commandes. On modifie dans les différentes classes : - Game : - CommandWords : - Parser : • Exercice 7.17 Non, nous n’avons pas changé Game car la méthode showAll permet d’obtenir toutes les commandes. • Exercice 7.18 On modifie les précédentes méthodes dans les classes : - Game : - CommandWords : - Parser : • Exercice 7.18.8 Pour créer un bouton, on utilise la classe UserInterface qui englobe l’aspect extérieur du jeu. On se sert de plusieurs classes du JDK en important : Par ailleurs, on utilise plusieurs classes : JFrame est la fenêtre de jeu, JTextArea est la fenêtre d’entrée des commandes, JLabel permet d’insérer les images, et JButton, les boutons. On divise la fenêtre comme on le souhaite en plusieurs « zones » (NORTH, EAST, SOUTH, WEST) et on leur attribue leur contenu : (Les images seront dans la partie haute (NORTH) de la fenêtre). JPanel est une division de fenêtre. Ici on en crée 2 : panel et panel2 qui contiendront images-listScroller (le déroulement du jeu)-entryField (le texte entré par le joueur) [panel] et les boutons [panel2]. Pour créer un bouton, on en crée un nouveau avec le texte affiché à l’intérieur : On le place dans une des divisions de panel qui dispose de sous-divisions, les mêmes (NORTH, EAST etc.) : On lui dit qu’il aura une fonction grâce à addActionListener : On lui attribue une commande grâce à la méthode actionPerformed : • Exercice 7.20 Création de la classe Item pour plus de cohésion (plutôt que des items dans la classe Room). Cette classe contient pour l’instant deux attributs : aItemDescription et aItemWeight. Elle contient des accesseurs et une méthode description pour les items. • Exercice 7.21 Quand une pièce est créée, nous avons à disposition les items qui s’y trouvent également. En effet, c’est la classe Item qui produit la description de l’item (nom, poids, description) qui sera alors affichée par la classe GameEngine (nouvelle classe Game qui elle désormais, lance le jeu et son interface). • Exercice 7.22 Modification de classe Room où l’on ajoute une HashMap de la même manière que pour les sorties des salles avec une méthode addItem. Désormais, on peut directement ajouter des items dans la méthode createRooms de la classe GameEngine : • Exercice 7.23 Ajout de la commande back permettant de retourner à la salle où le joueur était précédemment. On se sert des propriétés d’une Stack pour que la commande « back » soit sans faille (Exercice 7.26) • Exercice 7.26 Utilisation d’une Stack pour la commande back. C’est ce qu’on peut appeler une « pile » dans le sens « entassement » d’objet. En effet, dans ce cas-ci, elle « entasse » les salles quittées et à l’appel de la commande « back », donnera la dernière salle de la pile (salle juste quittée). On se sert alors des propriétés de la Stack, à savoir : - Peek : regarde l’objet en haut de la pile sans le supprimer de celle-ci. - Push : met un item sur le haut de la pile. - Empty : regarde si la pile est remplie. - Pop : enlève l’objet sur le haut de la pile et le livre. • Exercice 7.26.1 Pour générer les deux javadoc, on peut créer un fichier .bat avec la liste des commandes, à la racine de son compte ; il est modifiable par simple clic droit « modifier ». Il suffit de créer un bloc-notes, donner le bon chemin vers les bon dossiers, taper les commandes, l’enregistrer en .bat et l’exécuter ensuite. • Exercice 7.28.1 et .2 On crée une nouvelle commande test. Celle-ci accepte un second mot (comme la commande back, afin de décider soit même du fichier à tester. Ce fichier contient des commandes basiques (les mêmes que le jeu) comme « go …. », back, help, etc. qui seront alors exécuter. On importe la classe Scanner qui sera une variable ici, qui permet de lire le texte du fichier. On crée une boucle while qui ordonne à la méthode de continuer à lire tant qu’il y a une ligne ensuite (de manière à parcourir l’ensemble du fichier). La méthode se sert de catch et try qui permettent respectivement de connaître le type d’exception qui doit être capturé et ce qu’il faut tester. Pour utiliser la commande, il suffit d’entrer le nom du fichier suivi de son extension comme .txt. Si le nom du fichier est incorrect, catch va capter le nom de fichier erroné et va informer le joueur. • Exercice 7.29 Création d’une classe Player à laquelle on ajoute plusieurs attributs : Cette classe simplifiera le jeu, et permettra au joueur de porter des items. Sa position dans le jeu, la salle précédente, mais aussi les items seront liés au Player. • Exercice 7.30 Implémentation des commandes take et drop permettant au Player de ramasser ou de jeter des items. • Exercice 7.31 et 31.1 Pour pouvoir porter plusieurs items, on crée une nouvelle classe, ItemList, qui disposera d’une HashMap d’items. Désormais, ce sera cette classe qui disposera des noms, descriptions et poids des objets. • Exercice 7.32 Pour ce faire, on va paramétrer le Player et lui ajouter un poids maximal. De plus, on va créer une nouvelle méthode, getLongInventory dans la classe Player, qui regroupera la liste d’items et retournera leur poids maximal. On ajoutera également les méthodes setMaxWeight, getMaxWeight qui donneront et retourneront respectivement le poids maximal. getLongInventory utilise la méthode getTotalWeight dans la classe ItemList, qui retourne le poids de total des items portés à l’aide d’une HashMap. • Exercice 7.33 Création dans la classe GameEngine d’une nouvelle méthode items qui affiche l’inventaire d’items dont dispose le joueur. • Exercice 7.34 Il s’agit de créer un nouvel item « Magic Cookie » qui, lorsqu’on le prend et qu’on le mange, augmente la force du Player et lui permet alors de porter plus d’items. On utilise la méthode eat de GameEngine, que l’on va modifier. Elle fonctionne comme la méthode drop : elle cherche l’item à manger (jeter), vérifie si on l’a prise (take) et dans ce cas, exécutera la méthode eatCookie de la classe Player qui gère les items portés. Une fois mangé, l’item n’est plus dans la liste, comme drop. • Exercice 7.35 Création de la classe CommandWords <<enum>> qui veut dire « énuméré ». En effet, on va lui attribuer les commandes valides du jeu, ce qui modifie la classe CommandWords où on va rajouter une HashMap de commandes valides. - CommandWords : Et CommandWords<<enum>>
© Copyright 2024