RAPPORT A3P Equipe 2K

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>>