• Aucun résultat trouvé

Romain MARECHAL ESIEE Paris IPO

N/A
N/A
Protected

Academic year: 2022

Partager "Romain MARECHAL ESIEE Paris IPO"

Copied!
18
0
0

Texte intégral

(1)

1

(2)

2

I- Autours du jeu………..3

A) Auteurs………3

B) Thème……….3

C) Résumé du scénario complet………..3

D) Plan………3

E) Scénario détaillé………..4

F) Détails des lieux, items et personnages………..4

G) Situations gagnantes perdantes………4

H) Mini-jeux, énigmes……….4

I) Commentaires………4

II- Réponses aux exercices………5-11 III- Mode d’emploi………..17

IV- Déclaration anti-plagiat………18

(3)

3

A) Auteurs

Romain MARECHAL, élève en 1ère année, classe C3.

B) Thème

« Phrase thème » : Dans une ville, une famille doit trouver les ingrédients d’un antidote pour sauver leurs fils et éviter une épidémie.

C) Résumé du scénario complet

Dans la petite ville de Valadilène, un mystérieux virus apparaît chez l’enfant de la famille Walter. Ayant un doute sur la contagiosité du virus, Mr et Mme Walter, vont mener l’enquête afin de trouver un moyen pour sauver leurs fils. La famille Walter réussira-t-elle à trouver un antidote à temps pour guérir leurs fils afin d’éviter une épidémie de la ville !?

D) Plan

Ancien château

Salon

Centre-ville Autoroute Chambre

(fils)

Cuisine

Littoral (mer)

Forêt Maison des

Walter Bibliothèque

Bureau

Même étage

Étage supérieur

Téléporteur

Piège

(4)

4

E) Scénario détaillé

La maladie du fils est en réalité liée à un virus apparut au XVIIIème siècle qui n’était pas réapparut depuis.

Le couple Walter devra se renseigner notamment à la bibliothèque d’une ancienne bâtisse, le château de Valadilène, afin de trouver des ouvrages scientifiques leurs permettant de comprendre l’origine du virus.

Ils comprendront également l’existence d’un antidote, découvert par les médecins de l’époque, qui permettrait de guérir contre la maladie. Les Walter, voyageront dans différents lieux (en mer, forêt…) afin de réunir les ingrédients nécessaires à la confection du remède. Celui-ci permettra de remettre sur pied leurs fils et évitera une épidémie dans la ville de Valadilène.

F) Détails des lieux, items, personnages

Lieux : Maison des Walter (+pièces intérieurs), Ancien château, bibliothèque du château, Centre-ville, Autoroutes menant à la forêt à la mer, pièce piégée (trapped door), salle de téléportation (Teleporter Room)

Items : livres, argents, encre de seiche, champignon, etc...

Personnages : Mr et Mme Walter, le fils Walter, habitants de la ville (Centre-ville), conseiller bibliothèque, commerçants du marché, etc…

G) Situations gagnantes et perdantes

L’antidote est créé à temps, le fils est guéri = gagnant.

Les parents n’ont pas trouvé tous les ingrédients où met trop de temps à fabriquer l’antidote, l’épidémie démarre, une crise sanitaire débute = l’objectif n’est pas atteint, le joueur a perdu.

H) Mini-jeu, énigme

La liste des ingrédients à posséder est à deviner depuis l’ancienne brochure.

I) Commentaires

Il est nécessaire d’avoir un logiciel permettant d’ouvrir ces extensions de fichier pour le jeu:

- .pdf : lecture de documents dans le jeu (brochure, livres…) – Ex : Adobe Acrobat Reader https://get.adobe.com/fr/reader/

- .mp3 : lecture de musiques (musique d’ambiance, victoire…) – Ex : VLC https://www.videolan.org/vlc/index.fr.html

NB : En plus des exercices j’ai ajouté deux commandes : read et music. Read permet de lire les œuvres de la bibliothèque. La commande music permet de jouer la musique d’ambiance du jeu.

En outre, j’ai modifié l’aspect des boutons (couleurs fond et texte) ainsi que la police d’écriture de l’interface (hors boutons).

Site internet du jeu : https://perso.esiee.fr/~marechar/Projet%20Zuul/index.html

(5)

5

7.5) La procédure printLocationInfo() est créé dans la classe Game permettant d’éviter la duplication de code entre les procédures printWelcome() et goRoom(). Celle-ci permet d’afficher les informations de la pièce courante (notamment ses sorties).

7.6) La procédure getExit() est créé dans la classe Room, par principe d’encapsulation (fait de passer par des accesseurs car les attributs doivent être privés en toutes circonstances ce qui n’était pas le cas jusque-là) le couplage diminue entre les classes permettant d’améliorer le code, ici la procédure permet de gérer les attributs de Room et donne les sorties. La procédure est dorénavant aussi utilisé dans Game, au niveau de goRoom()) .

7.7) La méthode getExitString() est créé dans la classe Room, afin d’éviter la encore une duplication de code, par ailleurs, c’est la classe Room qui donnera les chaînes de caractère au lieu de Game.

7.8) Ajout de la classe HashMap (java.util.HashMap). Celle-ci permet d’intégrer à nouveau type d’attribut de type HashMap (ajout constructeur), qui marchera avec le principe de « clé, valeur ». Nous dans notre cas, la clé sera la String de direction et la valeur la Room associé. Cela permettra ainsi d’améliorer, en particulier, le createRoom(), où l’on spécifiera dorénavant uniquement les sorties possibles pour chaque pièce. Ex : vSalon.setExits(« south », vCentre_ville). La modification de setExits() est donc également nécessaire, les sorties peuvent être définies.

7.8.1) Ajout de deux directions « haut (up) » et « bas (down) ».

7.9) La méthode key.set() (appartenant à HashMap), permet de renvoyer les clés « keys » du HashMap (sorte de « bibliothèque » clé-valeur, ici direction-pièce) en lien avec ses valeur, ici la direction et sa pièce (si elle existe) en fonction de la pièce courante.

7.10) La méthode getExitString() renvoie toutes les sorties possibles d’une pièce sous forme d’une String. Les

« keys » de keySet() sont mis dans vKeys (de type Set), la variable locale contient maintenant toutes les « clés », la boucle for va donc défiler les clés et déterminer celles qui correspondent pour la pièce courante, il va en résulter les pièces trouvées sous forme d’une String.

7.10.1) Suite de l’écriture du javadoc.

7.10.2) Génération du javadoc.

7.11) La méthode getLongDescription() est créé dans la classe Game retourne la position actuellement prise par le joueur et donne les sorties, le tout sous forme d’une String. La procédure printLocationInfo() est modifiée du fait de l’implantation de la méthode getLongDescription().

7.12) Optionnel Diagramme en commençant le jeu (ex Zuul) & exécutant le « go … » (… : direction ou rien)

game1 Parser

vOutside

CommandWords

Sorties possibles

createRoom() aCurrentRoom est de base :

Méthodes exit(s) montre :

Mot tapé Vérifié

Autres pièces, ou

message (erreurs…)

Direction tapé correct

(6)

6

7.13) Optionnel Ajouté sur 7.12)

7.14) La procédure look() est créé dans la classe Game (et la commande dans CommandWords), permet au joueur se savoir où il se situe.

7.15) La procédure eat() est créé dans la classe Game (et la commande dans CommandWords), il s’agit d’une nouvelle fonctionnalité du jeu (l’action de manger), pour l’instant cela renvoie uniquement un message sur la console.

7.16) La procédure showAll() est créé dans la classe CommandWords, associé avec la procédure showCommands dans la classe Parser, celle-ci permet d’afficher de façon dynamique les commandes disponibles du jeu (auparavant on utilisait un S.o.p dans le printWelcome() pour les afficher mais on était du coup obligé de changé ce S.o.p pour chaque nouvelle commande ajoutée…).

7.17) Optionnel Oui, si l’on ajoute une commande on doit changer la classe Game, on doit notamment dire ce que provoque cette commande.

7.18) Dans la classe CommandWords la méthode showAll() est changé en getCommandsList(), cela permet à l’avenir de gérer les commandes disponibles depuis la classe CommandsWords. Dans la classe Parser, la procédure showCommands() devient une String. Il faut donc dans la classe Game, au niveau de printHelp() ajouté la méthode System.out.println pour aParser.showCommands() étant maintenant une String.

7.18.1) Comparer son projet avec zuul-better. Code similaire dans la majorité.

(7)

7

7.18.2) Optionnel Étude StringBuilder, changement de la méthode getExitString() avec l’utilisation de StringBuilder. Ce type permet une économie de la mémoire de l’ordinateur.

7.18.3) Images à chercher pour les pièces.

7.18.4) Titre « Panique à Valadilène »

7.18.5) Création dans la classe Game, création de l’attribut aListRoom de type HashMap<String, Room>, dans la méthode CreateRoom() on initialise cet attribut et l’on définit pour chaque pièce de la forme

this.aListRoom.put("Maison", vMaison) ce qui permet aux autres classes d’accéder aux pièces.

7.18.6) Étude projet zuul-with-images, ajout de deux nouvelles classes GameEngine (qui se charge en majorité de reprendre les méthodes de Game, c’est le « cœur » du jeu) et InterfaceUser (qui gère la partie graphique du jeu), dorénavant nous n’utilisons plus la console de BlueJ native. Par ailleurs on peut maintenant intégrer des images au format .gif, .png ; jpeg… sous forme d’une String (insérer dans la classe GameEngine) au code.

7.18.7) L’interface ActionListener en remplacement de Scanner permet avec ses méthodes d’interagir quand une commande est tapée. L’interface contient en particulier, void actionPerformed(ActionEvent e). Le addActionListener() permet de retenir qu’une action au eu lieu (au niveau de la saisie, qui semble être

matérialiser avec JTexField) sur l’interface (donc de UserInterface), cela entraîne l’appelle de actionPerformed() qui se contente d’appeler processCommand() ;. ActionEvent() est une classe permettant de réagir notamment en stimulant ActionListenener quand on clique sur un bouton. getActionCommand() retourne la String correspondant au texte figurant sur le bouton (si on clique dessus) et getSource() retourne la référence vers le composant qui a généré l'évènement (ici le bouton ou le champ de commande).

7.18.8) Ajout d’un bouton, l’aide et les documentations sur Internet, permettent de connaître le type du bouton pour l’interface graphique utilisé, il s’agit du JButton. On crée donc un nouvel attribut dans la classe UserInterface (un attribut par bouton), je l’ai d’abord crée pour la commande « help », on l’initialise dans la méthode createGUI(), this.aBoutonHelp = new JButton("help");, on l’ajoute sur un coté de l’écran vPanel.add(

this.aBoutonHelp, BorderLayout.WEST);, ce bouton doit être reconnu comme une action

this.aBoutonHelp.addActionListener( this);. On modifie enfin la procédure actionPerformed, dorénavant on va tester sur quel bouton on a cliqué (par exemple si c’est le bouton help, c’est la méthode printHelp() de GameEngine appelé par interpretCommand(String), ici la String sera remplacé par « help »), sinon c’est le champ de commande qui est pris en compte (toujours en appelant processCommand()). (V1) J’ai créé dorénavant un panel pour que je puisse intégrer plusieurs boutons au même endroit. (V2)

(V1)

(V2)

(8)

8

actionPerformed V2

7.19) Le MVC (Modèle-Vue-Contrôleur) est une façon de conception de programme visant à le rendre clair et structuré. On a le « modèle » qui contient la gestion de donnée, la « vue » qui correspond à présentation de l'interface graphique et le « contrôleur » qui équivaut à la l’interprétation des commandes de l’utilisateur.

7.19.1) Implanter le modèle zull-mvc dans zull-with-images.

7.19.2) Toutes les images (au format .gif), sont stockés dans le dossier « Images » situés dans le dossier racine du Projet, les String sont de la forme Images/nomimage.gif

7.20) Ajout d’une nouvelle classe Item dans le but d’ajour Items dans le jeu, deux attributs (aDescription et aPoids), un constructeur, deux accesseurs et deux modificateurs. Création dans la classe de GameEngine, de la méthode createItem() (création de l’item et association avec la pièce). Changement dans Room de

getLongDescription() qui analyse si un objet est présent ou non dans la pièce (donne l’objet ou renvoie qu’il n’y a pas d’objet dans la pièce).

7.21) Réponses questions. 1) Toutes les informations d’un Item présent dans une pièce doivent être produites dans la classe Room (car l’Item est dans une pièce), en particulier dans la méthode getLongDescription(). 2) La classe qui doit produire la String décrivant l’Item, on pourrait nommer cette méthode

getItemLongDescription(). 3) La classe qui devrait l’afficher est la classe GameEngine, c’est celle-ci qui s’occupe des affichages.

7.21.1) Optionnel Changement dans look() : si 2ème mot Item, renvoie sa description,.

7.22) Création de la méthode addItem(), permettant d’ajouter un objet, getItemStrings(), permettant de connaitre les items présents dans la pièce et modification de getLongDescription() afin d’ajouter la présence ou non des items (avec messages).

7.22.1) Optionnel On utilise ici le HashMap car cela permet de choisir l’appartenance d’un item à une pièce ou non, de plus, cela permet de retrouver les items déjà enregistrés plus facilement.

7.23) Ajout d’une commande « back » permettant de revenir par la commande à la pièce précédente. Création d’un attribut aPreviousRoom de type Room dans Game Engine, initialisation de aPreviousRoom dans

createRoom() et goRoom(). Ajout dans InterpretCommand de « back », création de la procédure back(). Ajout de la commande dans CommandWord étant une commande valide dorénavant.

(9)

9

Back (avec stack) 7.24) Optionnel Test si 2e mot après « back »

7.25) Optionnel Si « back » tapé 3 fois…

7.26) Utilisation de la classe Stack, permettant d’utiliser « back » successivement, la classe Stack permet de compiler des Objets, ici des Rooms. Changement du type de aPreviousRoom par Stack<Room>, on modifie son initialisation dans createRoom(), ajout de la méthode push pour aPreviousRoom permettant de garder la pièce actuelle (qui est mis en haut de la « pile » du Stack). La procédure back() est donc modifier, elle va tester si le Stack est vide avec empty() (dans le cas où l’utilisateur n’a pas bouger de la pièce initial), utilisation de pop permettant de changer la pile (supprimer la pièce courant et change pour la pièce que l’on vient de quitter), enfin donne les informations de la pièce en ayant utilisé back().

En résumé, la class Stack permet de créer une « pile » (d’objets, de rooms ici). Elle a plusieurs méthodes dont : push() qui envoie l’objet en haut de la pile, pop() qui supprime l’objet le plus haut de la pile et le renvoie, empty() qui test si la pile est video et peek() qui examine l’objet en haut de la pile mais ne le supprime pas, pop() qui supprime l’objet le plus haut de la pile et le renvoie.

7.26.1) Générer les deux javadocs (habituelle avec méthode publiques, et complètes (développeurs) avec méthode privées en plus).

7.27 – 7.28) Optionnel Nous modifions en profondeur la structure du code (création GameEngine,

UserInterface…) ainsi que les fonctionnalités (items, back…), nous devons tester si les anciennes (go, help, up…) commandes marchent toujours et tester les plus récentes. On peut par exemple automatiser des tests ou l’on

« taperais » une suite de commande, possible avec Scanner dans sa version « lecture de fichier », on peut ajouter une commande « test » qui permettrait de tester une combinaison de commandes (enchainées).

7.28.1) Création de la commande « test », qui va appeler une procédure test(). On va utiliser cette procédure afin de tester de manière automatique une liste d’instructions que l’on aurait tapé successivement dans le champ de saisie. Dans test on va utiliser la classe Scanne qui va nous permettre cette-fois ci de « lire un fichier » et le retranscrire sous forme d’instructions virtuelles. J’ai repris en parti la méthode de D.Bureau dans la rubrique « Plus de technique » sur icampus.esiee.fr. La commande test devrait en plus comporter en tant que second mot le nom du fichier .txt dans lequel on aura renseigner les commandes, Scanner va lire les commandes et les donner à interpretCommand() pour qu’il le retranscrit sur le jeu.

La classe Scanner se définit généralement comme un analyseur de texte (dans l’exo 7.2.1 on l’avait utilisé comme un analyseur mais adapté à ce qu’on écrivait dans le champ de saisie de l’interface graphique de base de BlueJ), ici Scanner est utiliser pour lire un fichier externe notamment un .txt, le type File (classe exactement) permet de créer sous code Java la transcription d’un chemin d’accès, ici on l’utilise pour le fichier .txt. Scanner comporte plusieurs méthodes : hasNextLine() qui renvoie vrai s'il y a une autre ligne dans le code lu par scanner, nextLine() qui avance ce scanner au-delà de la ligne actuelle et renvoie l'entrée qui a été ignorée (elle permet le saut à la ligne du Scanner). En revenant à l’exemple du scan du fichier, si le fichier n’existe pas ou incorrect, on va utiliser une classe notamment FileNotFoundException pour signifier qu’aucun fichier n’est trouver, en définitive, on va tester les commandes successives (avec le code scan) avec l’instruction try et gérer s’il y a une erreur (notamment que le fichier n’est pas trouvé dans try) avec le catch (qui renvoie une chaîne de caractère « Fichier non trouvé »).

(10)

10

7.28.2) Fichier tests créés : court.txt test 3 commandes, normal.txt test les commandes permettant de gagner, et inutile.txt qui teste divers commandes aléatoires (mêmes inutiles, pour tester toutes les possibilités).

7.28.3) Optionnel Exercice suggérant d’approfondir les tests de commandes (2è mot…)

7.29) Création d’une nouvelle classe, Player, celle-ci permet de décharger la classe GameEngine qui commence à se densifier. Cette classe va permettre dorénavant de gérer un joueur qui aura quelques spécificités, son emplacement dans le jeu (sa pièce courante), un nom, sa pièce précédemment visité ainsi qu’un nombre d’objets limites (que sera défini plus tard). La classe contient des accesseurs et des modificateurs.

Changement : création de l’attribut aPlayer de type Player dans GameEngine, changement de aCurrentRoom par aPlayer.getCurrentRoom() (pour connaître la pièce courante) ou aPlayer.setCurrentRoom(pNomParamètre) le paramètre dépend de la méthode ou il est utilisé, la pièce du début passe de this.aCurrentRoom = vMaison ; qui est maintenant insérer dans la création du player aPlayer = new Player ("joueur", 2,

aListRoom.get("Maison"));, on utilise ici la HashMap (attribut) aListRoom nous permettant d’accéder aux pièces en dehors de createRooms().

7.30 & 7.31) Ajout de deux commandes « take » permettant de prendre un item et « drop » permettant de reposer l’objet, ajout de ces commandes dans la classe de CommandWord, ajout de leurs actions quand les commandes sont tapés dans interpretCommand(), la possibilité d’avoir plusieurs items dans le 7.31) implique la création d’un inventaire qui permettra au joueur d’avoir plusieurs items. On crée donc un attribut

HashMpa<String, Item> aInventory, initialisé dans Player(), création de la méthode takeItem() (permettant d’ajouter à l’inventaire l’item de la pièce courante) et dropItem (déposer dans la pièce l’objet), accesseur getItem (regarder dans l’inventaire dans l’objet), et gtInvotory (lié erreur Drop). NB : pour une raison inconnue BlueJ voulait bien utiliser getItem pour take mais impossible pour drope (void ne peut renvoyer un item) alors qu’il s’agit de la même dans take, au lieu de getItem(vCommandIte) on a getInventory().get(vCommandIte), ce qui revient au même (getItem étant plus rapide), problème résolue (getItem renvoie un type Item et non void).

(11)

11

7.31.1) Création de la classe ItemList permettant la gestion de listes d’items des room et du player, création de l’attribut aItemList de type HashMap<String, Item> reprenant donc l’utilisation précédemment de aItems dans Room et Player. Création d’accesseurs comme getAItemList() (renvoie aItemList) et de la méthode StringBuilder notamment getItemList. Ajout d’un attribut de type ItemList aItemList dans Player et Room. Modification dans Player de getItem(), takeItem() et dropItem(), dans Room, getLongDescription(), addItem(), getItem() et removeItem()

NB : le addItem et takeItem reprennent put de HashMap, dropItem et removeItem reprennent remove de HashMap, et les deux get reprennent get de HashMap…

7.32) Création dans Player d’un attribut aPoidsMax de type double permettant de limité le nombre d’items en fonction de leurs poids, une limite sera choisi, en fonction de cela un joueur pourra ou non prendre une objet, création de l’accesseur, d’une méthode PoidsTotal permettant d’additionner les poids des items, une méthode booléenne hasEnoughSpace est créé afin de vérifier si le joueur a assez de place, celle-ci est utilisé dans la méthode take de GameEngine afin d’ajouter ou non à la ItemList du joueur l’item de la room !

7.33) Ajout de la commande « items » qui permet de savoir quels items sont stockés dans l’inventaire du joueur. Ajout de la commande valide dans la classe CommandWord, ajout de son impact dans

interpretCommand, création d’une méthode de type String itemsString qui donne donc la String nous renseignant sur les items du joueur. Ajout d’une procédure itemInfo dans la classe Player, afin de rassembler les objets obtenus par le joueur (éviter également un code trop long pour itemsString).

7.34) Création d’un item cookie que l’on peut manger avec la commande « eat cookie » ce qui permet de doubler l’espace disponible de l’inventaire du joueur. Pour cela, on change la méthode eat dans lequelle on va tester si la commande eat possède un second mot donc par if (!pCommand.hasSecondWord()), sinon il faut vérifier si le second est cookie et que l’item est dans l’inventaire du joueur par if

(pCommand.getSecondWord().equals("cookie") && this.aPlayer.hasItem("cookie"))

7.34.1) Les fichiers test ont été mises à jour jusqu’au dernières commandes.

7.34.2) Les deux javadocs ont été régénérées et mises à jour.

7.35) Étude de zuul-with-enums-v1. Plusieurs modifications dans le jeu, création d’une classe CommandWord (« enum ») dans lequel on insère des enums traduisant nos commandes correctes

(12)

12

Dans la classe CommandWords changement du type de aValideCommands par un HashMap<String,

CommandWord> permettant un nouveau système de vérification (ajout de la classe HashMap par import…), initialisation dans le constructeur et ajout de chaque commande valide sous forme

this.aValidCommands.put("go", CommandWord.GO);

Changement de la méthode isCommand() par return aValidCommands.containsKey(pString);

Dans la méthode getCommandList(), vous avoir accès au clé du au HashMap on utilise aValidCommands.keySet()

Création de la méthode getCommandWord() inclus dans le fichier .jar

Dans la classe Command modificateur du type de l’attribut aCommandWord initialement String en

CommandWord, modification dans le constructeur, l’accesseur, la méthode isUnknown est écrit de cette façon return this.aCommandWord == aCommandWord.UNKNOWN;

Dans Parser, changement de vWord1 par this.aCommandWords.getCommandWord(vWord1) (car le premier mot est un CommandWord maintenant)

Dans GameEngine, dans la méthode interpretCommand() changement du type pour vCommandWord de String à CommandWord (afin d’utiliser la classe CommandWord), on change également les tests booléens comme suite (la commande inconnue UNKNOWN ne semble marcher…)

NB : problème du UNKNOWN résolu, il fallait changer le null par CommandWord.UNKNOWN car on utilise maintenant les enums et plus un String pour le mot inconnu dans Parser.

(13)

13

7.35.1) On change les tests booléens if / else par le switch, ce qui permet un gain de place de place dans le code.

Un switch permet, au même titre que des if /else, de gérer des conditions (comme des variables). Il va tester dans notre exemple, les énumérations de CommandWord. Chaque cas (condition remplie, ou non) dit case est défini en fonction d’un type (qui peut être primitif, objet ou enum) d’enum dans notre cas. Le break est une instruction permettant de sortir du switch si un cas est rempli (condition validée). Enfin le cas default le ‘on écrit directement default : (sans case avant) permet de définir une instruction par défaut (si aucune des autres cas définis n’est validés)

7.37) Depuis la création de la HashMap dans CommandWords, il suffit, en effet, de changer les String défini pour la HashMap afin de changer la langue

7.38) En modifiant le « help » en « aide » (grâce à la HashMap) cela change le nom de la commande, mais cependant, le message d’accueil reste le même, il faut ainsi changer le printHelp()

7.41.1) Modifications par rapport à zuul-with-enums-v2. Modification dans la classe « enum » CommandWord, des enums avec l’ajout de leur String, ajout du constructeur et de la méthode toString(). Dans la classe

CommandWords, changement du constructeur pour celui de la v2.

(14)

14

Une énumération (enum) est un type de données particulier, dans lequel une variable ne peut prendre qu'un nombre restreint de valeurs. La méthode statique values() retourne un tableau de toutes les valeurs énumérées disponibles. La méthode toString() retourne une chaîne de caractères qui porte le nom de la constante considérée (comme EAT). Un attribut est une caractéristique d’un objet, un constructeur permet d’instancier les attributs d’une classe.

7.41.1) Modification par rapport à zuul-with-enums-v2. Dans l’enum CommandWord, modificiation des enums en y ajoutant une String sur le modèle GO("go"), QUIT("quit»)… On y ajoute l’attribut aCommandString ainsi que des méthodes CommanbdWord et toString().

Dans la classe CommandWords, on remplace la suite des .put par une boucle comme suite dans la méthode :

7.42) Création d’une notion de « time limit », je l’ai intégré en tout que nombre limite de pas. Pour cela, j’ai créé dans la classe Player, deux attributs aNbPas et aNbPasMax étants des int. J’initialise le aNbPas à 0 aNbPasMax à 20 (20 déplacements max pour l’instant). J’incrémente pour le changement de pièce le nombre de pas soit par aNbPas++;. Enfin je crée une méthode boléenne afin de vérifier que le aNbPas est inférieur à aNbPasMax;

Le contrôle principal se fais dans le GameEngine, dans la méthode goRoom on test le nombre de pas effectué, si celui-ci est dépassé, un message apparaît et le jeu s’arrête :

(15)

15

7.42.1) Temps réel, exercice non traité.

7.42.2) Modification faite pour les boutons changement de couleurs.

7.43) On peut tout d’abord supprimer un setExits d’un pièce dans createRoom() de GameEngine. Dans mon cas j’ai créé une pièce nommée Trapped ou je n’ai mis aucune sortie. J’ai modifié le back, en ajoutant un else if afin de ne pouvoir utiliser la commande permettant de revenir en arrière et donc de « tricher » (j’ai également ajouté la pièce Trapped à la HashMap aListRoom pour pouvoir faire le booléen).

7.44) Ajout d’un item Beamer permettant la téléportation, en effet, cet objet permet de sauvegarder une pièce avec la commande charge et permet dans une autre pièce avec la commande fire se téléporter à la pièce sauvegardée. La création de cet item à neccessité plusieurs choses. Création d’une classe Beamer héritant de la classe Item (puisqu’il s’agit d’un item) ayant deux attributs aCharged, un boolean permettant de vérifier que le beamer est chargé et la Room sauvegardé appelé aRoomCharge. Dans le constructeur prise en compte des paramètres de la classe Item avec super, initialisation du booléen aCharged à false. Création des deux accesseurs (is charged(), getRoomCharged()) et modificateurs (setCharged(), setRoomCharge()). Ajout dans CommandWord de deux enums CHARGE(« charge ») et Fire(« fire ») . Ajout dans interpretCommand de deux cases pour les deux enums précédents. Création de deux méthodes dans GameEngine, charge() et fire().

7.45) Optionnel. Exercice non traité.

7.45.1 & 7.45.2) Fichiers test modifiés, et javadocs regénérées.

7.46) Création d’une pièce spéciale (transporterRoom ou pièce téléporteur), quand l’on va sortir de celle-ci, on va se retrouver dans une pièce aléatoire du jeu. Création de deux classes TransporterRoom et

RoomRandomizer. La première classe permet la création d’une pièce (room) de type « téléportation », caractéristique l’on a présenté ci-dessus. Cette première classe possède uniquement un attribut de type RoomRandomizer. Le constructeur possède une String pDescription et pImahe permettant de décrire la pièce où l’on sera téléporté. Un modificateur setAllRooms permettant d’incorporer la spécificité de la pièce en sortant (dans GameEngine), enfin, on procède à une redéfinition de la méthode getExit() afin de déterminer aléatoirement la sortie de la pièce téléporteur. La classe RoomRandomizer s’occupe du cœur du mécanisme de la pièce téléporteur. On a deux attributs aAllRooms de type HashMap<String, Room> et aRoomsArrayList de type ArrayList<Room>. Dans le constructeur, on initialise ces deux attributs et l’on complète l’ArrayList de Rooms qui va être utilisé par la pièce téléporteur afin de « séléctionner » une pièce au hasard. Création d’une méthode completeArrayList, enfin, création de la méthode findRandomRoom. C’est cette dernière méthode qui va permet un choix aléatoire de la pièce, une variable locale vRandom de type va être créée, c’est l’utilisation de la classe Random qui va permettre ce choix aléatoire. On intègre bien entendu, les import nécessaires Random, HashMap et ArrayList si la classe en utilise.

(16)

16

A savoir expliquer :

Random est une classe ou une instance de celle-ci de générer un nombres pseudo-aléatoires. nextInt() renvoie la valeur pseudo-aléatoire (un int) pouvant être défini dans les paramètres de la méthode, dans notre cas, ce nombre est relié à une pièce. Une seed (ou graine en français, aléatoire en général) est un nombre utilisé pour l'initialisation d'un générateur de nombres pseudo-aléatoires, dans notre cas elle est utilisé dans la classe Random.

7.46.1) Exercice non traiter je ne vois comment déterminer une valeur qui est aléatoire.

7.46.2) L’héritage a été utilisé pour la classe Beamer (hérité de Item notamment), pour la locked exercice, exercice que je n’ai pas encore fait, je pense que l’éritage de Room est nécessaire.

7.46.3 & 7.46.4) Les commentaires sont ajoutées et javadocs regénérées.

(17)

17

- Afin de jouer dans de bonnes conditions, il est nécessaire d’avoir les logiciels expliquées dans le I.

- Le joueur peut taper « help » s’il ne connait pas les commandes du jeu.

- Il peut se reporter au plan des pièces afin de mieux connaître l’univers du jeu.

- Le joueur dispose de 25 déplacements afin de relever le défi ! Au-delà, il a perdu !

- Il possède un espace de 15 unités dans son inventaire, chaque objet du jeu à son propre nombre d’unité(s).

Commandes du jeu :

- go xxx = se déplacer vers xxx (north, south, east, west)

- help = aide du jeu, renseignant sur les commandes disponibles et le lieu courant - quit = quitter le jeu

- look xxx = look uniquement permet d’avoir des informations sur le lieu courant, l’ajout de xxx permet d’avoir des informations sur l’item xxx (description, poids…)

- eat xxx = commande permettant de manger, avec le xxx pour un aliment comme le cookie - back = commande permettant de revenir dans la pièce précédente

- test xxx = réservé aux programmeurs (exécutant une liste de commandes définie) - take xxx = prendre l’item xxx dans son inventaire

- drop xxx = poser l’item xxx dans la pièce courante

- items = avoir un aperçu de son inventaire (items, poids…)

- charge = charger la pièce courante dans le beamer (objet de téléportation) - fire = téléportation vers pièce chargée par le beamer

- read xxx = lire l’œuvre xxx de la bibliothèque - music = lancer la musique d’ambiance du jeu - antidote = donner l’antidote à l’enfant Walter

Bon jeu =)

(18)

18

Hormis les déclarations ci-après, je certifie avoir conçu l’intégralité du jeu « Panique à Valadilène » (idée, ressources, code).

- Merci à Alice ROLLIN (C3) pour son aide, notamment au début avec la méthode printLocationInfo()

- Merci à Thomas VELU (C3) pour son aide concernant un exercice optionnel, le look item permettant de connaître la description d’un item.

- D. Bureau pour ses pistes dans la réalisation de la commande test, code inclus.

- DevNami (YouTube), fragment de code repris pour l’implémentation d’une fonctionnalité permettant l’ouverture de fichiers (notamment pdf et mp3).

- Les droits d’auteurs des documents écrits et sonores sont stipulés

Références

Documents relatifs

- Par ½ journée, revoyez 2 ou 3 chapitres : relisez soit les fiches que vous avez faites, soit le cours dans le cahier avec le manuel!. - Récitez sur une feuille ou

• Au brouillon, pour chaque question, notez les éléments qui composeront votre réponse. • Rédigez ensuite avec soin sur

- La nouvelle route du Littoral à La Réunion pour favoriser les communications entre les pôles urbains et économiques (port/ aéroport ; pôles touristiques) malgré les

…et en vous appuyant sur des exemples vus en classe , décrivez la diversité et les atouts des espaces de faible densité en France.. La consigne donne le plan à suivre et il

Dans le cadre d’une recherche Internet portant sur « L’initiation sur le tableur MS Excel 2007 », vous trouvez un fichier intéressant en format «.pdf » dont la taille est 4Mo.

Triple alliance (Allemagne, Autriche, Empire Ottoman) contre Triple entente (France, Royaume-Uni, Russie et colonies) on parle de guerre mondiale car elle implique des pays de

PTOM (Pays et territoires d’Outre-mer) : Groenland, Nouvelle-Calédonie, Polynésie française, Terres australes et antarctique françaises, Wallis-et-Futuna, Mayotte,

En rédigeant un développement construit, vous décrirez et expliquerez la marche vers l’indépendance et les problèmes de développement auxquels les îles Fidji sont