Projet Zuul de conception orientée objet en Java d'un jeu d'aventure
Forum des exercices du projet Zuul
Exercice 7.43
1) Une trap door n'est pas une trap room. La pièce concernée doit avoir au moins deux sorties, mais l'une d'entre-elles ne doit être franchissable que dans un seul sens. A ce stade, une solution très simple peut être utilisée.
2)
Mais comment doit se comporter la commande back ?
Si on veut empêcher la commande back d'autoriser le franchissement "à l'envers" de la trap door, il serait pratique de disposer dans la classe Room d'une
nouvelle méthode isExit(Room) qui renvoie vrai ou faux selon que la Room passée en paramètre est une des sorties de la pièce ou pas.
3)
Ajoutez une 2ème trap door quelque part dans votre jeu.
Attention !
Si vous avez dû modifier plus d'une ligne de code, c'est que l'exercice n'est pas bien réalisé.
Contraintes (pour ne pas faire de mauvaise implémentation de cette fonctionnalité) :
- Le nom ou la description des pièces ne doivent jamais être utilisés dans les tests
que vous ferez pour déterminer si vous êtes dans le cas d'une Trap Door.
- Il devra être possible d'ajouter autant de Trap Doors que l'on souhaite
sans ajouter de vérifications supplémentaires dans le code.
- Il doit aussi être possible de positionner plusieurs Trap Doors
dans une même pièce.
- Si une Trap door est positionnée dans la première pièce du jeu, celle-ci
doit posséder au moins une autre sortie qui peut être franchie dans les deux sens.
Aide :
Si vous ne trouvez pas une méthode dans la classe Stack, cherchez dans les méthodes de la classe Vector puisqu'elle en hérite.
Précision :
Il n'est pas nécessaire de créer une classe Door (l'exercice 7.45 est optionnel).
Ne pas oublier de lire les échanges ci-dessous pour mieux comprendre la bonne manière de réaliser cet exercice.
La solution serait-elle :
du moment que l'on traverse ce "trapdoor", on doit supprimer toute les "room" dans le Stack grace à une méthode de la Class Stack ?
Bonjour,
Pour cette question, nous avons crée une HashMap<Room, Door> dans la class Room. Celle ci associe à une Room (correspondant à une sortie de la Room actuelle) une porte de la classe Door.
On place les portes de la Room actuelle grâce à :
public void setExit(final String pDirection, final Room pNeighbor, final Door pDoor)
Cependant, cela nous oblige à créer dans GameEngine toutes les portes...
N'y a t'il pas une autre méthode?
La question ci-dessus et ma réponse ci-dessous concernent plutôt l'exercice 7.45.
Si.
L'idée est plutôt de "mimer" la HashMap des sorties et donc de définir une HashMap<String,Door> en fonction des directions.
Ensuite, la procédure setExit devrait créer la porte en interne et l'ajouter à la HashMap, ce qui n'ajouterait pas de lignes dans createRooms.
Est-ce correct si nous n'avons pas créer de classe Door pour cette exercice?
Je ne vois pas l'intérêt de cette classe pourriez-vous expliquer car j'ai fais cet exercice seulement en ne définissant aucune Room de sortie pour la Trap Room ce qui ne permet donc pas de retourner en arrière ni avec la méthode goRoom ni la méthode back.
Quels attributs devra avoir cette classe? Quelle sera son rôle?
De plus pourriez-vous détailler ce que vous entendez par "créer la porte en interne"?
Cordialement.
> Est-ce correct si nous n'avons pas créer de classe Door pour cette exercice?
oui, tout à fait, cette classe n'est utile qu'à l'exercice (optionnel) 7.45 ;
par contre, une fois cet exercice fait, il peut être nécessaire de revenir sur le 7.43 ...
> Je ne vois pas l'intérêt de cette classe pourriez-vous expliquer car j'ai fais cet exercice seulement en ne définissant aucune Room de sortie pour la Trap Room
Attention !
On ne demande pas une trap room mais une trap door !
La Room dans laquelle se trouve cette trap door est censée avoir d'autres sorties.
> ce qui ne permet donc pas de retourner en arrière ni avec la méthode goRoom ni la méthode back.
si vous adoptez une méthode simple comme celle que vous évoquez, il faudra probablement modifier la commande back pour qu'elle ne permette pas le retour "à l'envers de la trap door"
> Quels attributs devra avoir cette classe? Quelle sera son rôle?
> De plus pourriez-vous détailler ce que vous entendez par "créer la porte en interne"?
Si vous décidez de faire l'exercice 7.45 et que que ces questions sont toujours d'actualité, posez-les sur le forum de l'exercice 7.45.
Bonjour,
je voulais savoir s'il vous plait si pour implémenter cette trapdoor il suffit de supprimer une des exit et de supprimer ce qui a dans la pile une fois on passe par le trapdoor.
Cordialement.
Bonjour, est-il possible de récupérer une clé d'une Hashmap? car je ne vois pas de moyen de tester si l'on s'apprête à rentrer dans la salle où se trouve la TrapDoor...
Dans ma commande back:
if (command.getSecondWord() == "North" && aCurrentRoom.getString() == "Donjon")
gui.println("La porte est fermée à clef!");
J'aurai pu me passer de la String associée à cette Room mais cela revient au même puisque je n'arriverait pas à comparer la Room dans le if...
Quelqu'un peut m'aider?
Je ne vois pas comment répondre à votre question, mais quelques remarques :
1) On peut récupérer toutes les clés d'une HashMap grâce à la méthode keySet.
2) Une trap door n'est pas une porte fermée à clef, mais une porte qu'on ne peut franchir que dans un seul sens.
3) Lorsqu'on va d'une pièce A vers une pièce B, on peut toujours vérifier qu'il y a bien une sortie de A vers B.
4) Il n'y a pas de second mot pour la commande back.
En espérant que cela vous aidera à remanier votre code.
L'étudiant a répondu :
Alors, effectivement, je pourrais récupérer les clés de la HashMap mais je n'aurait que des Nord, Sud etc... et pas des Room.
1) 'Alors, effectivement, je pourrais récupérer les clés de la HashMap mais je n'aurait que des Nord, Sud etc... et pas des Room.'
Si ! Quand vous demandez à votre HashMap ce qui est associé à la clé "North", elle vous retourne bien une Room !
2) Je ne suis pas sûr qu'il faille tester tout ce que vous décrivez. Une 'porte normale' entre les pièces A et B se franchit dans les deux sens uniquement parce-que vous avez prévu une sortie de A vers B et une sortie de B vers A. Une 'trap door' ne doit pouvoir être franchie que dans un seul sens : la solution paraît donc très simple ... non ?
L'étudiant a répondu :
J'ai trouvé une alternative en testant: si mes seules sorties sont nord, est et ouest et que je vais au nord alors stack vidée. Mais j'ai pu faire cela, seulement parce qu'il se trouve que je n'ai qu'une salle ayant ces sorties précises dans mon jeu. Mais, si cela n'avait pas été le cas, j'aurai été obligé de passer par ce que je vous ait expliqué dans le paragraphe ci-dessus, non?
La solution décrite dans votre 'alternative' n'est évidemment pas correcte, puisque comme vous l'avez très bien remarqué, elle ne fonctionnerait pas si une autre Room avait les mêmes sorties.
Dans la commande back, pour savoir si vous venez de franchir une 'trap door', ne suffit-il pas de regarder s'il existe ou pas une 'exit' dans l'autre sens permettant de revenir à la pièce précédente ?
Un étudiant a écrit :
if(aPlayer.getCurrentRoom().getDescription().equals(" dans la salle de cours, tu ne peux plus retourner dans l'escalier il semblerait qu'il ai bouger ! ") ) {
"La solution serait-elle :
du moment que l'on traverse ce "trapdoor", on doit supprimer toute les "room" dans le Stack grace à une méthode de la Class Stack ?"
Du
coup, pour vider le Stack, j'effectue un teste dans le goRoom après
avoir affecté la valeur de la nextRoom à l'attribut currentRoom. Ce
teste regarde si le nom de l'image de la currentRoom est identique à
celle de la trapDoor. J'aurais pu comparer la description des room (au
lieu des nom de l'image).
J'avais
au départ pensé à comparer les room entre elles mais impossible car
nous créons les room avec des variables locales situées dans le
createRoom().
Donc ma question est, y aurait-il un autre moyen plus "rigoureux" dont je serai passé à côté afin de comparer la currentRoom et la trapRoom (au lieu de faire comme j'ai fait avec les noms des images)?
Même s'il n'y avait pas d'autre moyen, ce code est à l'évidence faux, puisqu'il dépile systématiquement 100 fois sans savoir combien d'éléments ont été empilés !
Vous pourriez donc au moins écrire une boucle qui ne dépile que ce qui a été empilé.
Mais vous avez raison, il y a un autre moyen, en un simple appel de méthode.
Par contre, je ne connais "JavaPlateform" !?
Il faut tout simplement regarder dans la Javadoc (taper java 8 Stack dans google).
Attention ! J'ai ajouté une aide dans l'énoncé, car la méthode clear que vous cherchez est dans les méthodes héritées (inherited), et non directement dans la classe Stack.
Réseaux sociaux