Projet Zuul de conception orientée objet en Java d'un jeu d'aventure
Forum des exercices du projet Zuul
Exercice 7.49
Add moving characters. These are like other characters, but every time the player types a command, these characters may move into an adjoining room.
Utiliser l'héritage à bon escient...
Ne pas oublier de lire les échanges ci-dessous pour mieux comprendre la bonne manière de réaliser cet exercice.
Bonsoir,
je ne vois pas quelle attribut en plus pourrait avoir un Movincharacter si il herite de Character, j'ai pensé à un attribut de type ROOM mais je ne sais pas comment la manipuler dans MovingCharacter.
merci d'avance
Il n'y a pas de réponse unique à cette question ; cela dépend fortement de ce que vous prévoyez comme stratégie(s) de déplacement de vos MovingCharacter.
On peut imaginer une CurrentRoom, ou une liste de Room, ou un compteur pour "tourner" entre plusieurs Room, ou un générateur aléatoire de directions, ou un Item qu'il faut lui donner pour qu'il se déplace, ou tout ce que votre imagination vous suggérera ...
Il est aussi possible de se contenter d'ajouter une méthode de déplacement rudimentaire.
Un étudiant a écrit :
Bonjour, [...] L'implémentation actuelle fait se déplacer le personnage dans une pièce adjacente choisie aléatoirement. Cependant, il risque d'entrer dans une TransporterRoom et ainsi de se retrouver n'importe où.
Pouvons-nous, à la place de choisir une pièce adjacente aléatoirement, définir un chemin que le MovingCharacter suivra ?
Bonjour, si notre Class Character possède déjà l'attribut aCharacterCurrentRoom, il nous suffit de rajouter une méthode qui le permet de le faire bouger de room, est-ce bien ça ?
Juste pour obtenir une meilleur visibilité. Je préfere avoir des variables assez explicite même si je sais que j'aurai pu garder aCurrentRoom.
Bonjour monsieur,
J'aimerai que vous m'orientez sur la manière d'écrire proprement cette classe et ses sous classes.
Je me demandait si il était judicieux de rendre la classe NPC abstraite, et de créer une sous classe pour chaque type de NPC possibles (et la casse DefaultNPC pour un NPC qui n'a pas de caractéristique spéciale). Cette classe abstraite servirait aussi a implémenter la fonction abstraite setFeatures() qui initialisera les booléens informant sur les caractéristiques d'un personnage, cette fonction sera appelée dans le constructeur de NPC. Voici mon code pour clarifier les choses:
public abstract NPC{
public boolean aIsMoving;
aIsMoving = false;
setFeatures(); // si l'on est dans la classe MovingNPC, cette procédure rendra aIsMoving true
}
public void setFeatures();
/*
setter / getter des booléens
*/
}
Une classe (abstraite ou non) NPC et des sous-classes : oui.
La "bidouille" avec des booléens : moins.
Essayez de mieux utiliser l'héritage en mettant en commun (dans la classe mère) tout ce qui peut l'être et en redéfinissant (dans des classes filles) ce qui doit l'être.
Mais chaque cas est particulier, selon la complexité (dialogues, inventaires, déplacements, ...) de vos personnages.
Très bien, mais du coup si chaque item n'a pas de booléen qui indique ce qu'il est, comment faire faire pour différencier les sous-classes dans les commandes ? Par exemple ma commande Charge ne peut fonctionner qu'avec un Beamer, hors je ne peux pas d'office convertir l'objet demandé en second mot en Beamer sans connaître sa classe. Il me faut donc un test pour déterminer la nature de l'Item, voilà pourquoi j'utilisais ces booléens.
Avant les booléens, j'utilisait ce code:
String vClassString=""+pPlayer.getItemList().getItem(getSecondWord()).getClass();
switch(vClassString){
case "class pkg_world.Beamer":
}
Mais, bien que ça fonctionne, ça ne me parait pas être une bonne solution non plus.
Quelle serait donc la meilleure manière de différentier une classe et ses sous-classe dans les commandes ?
Cette question sur les Item n'a plus de rapport avec cet exercice, mais la réflexion peut effectivement être commune, y compris à propos des Room :
Pourquoi n'avez-vous pas été obligé d'utiliser des booléens ou un switch pour utiliser la TransporterRoom ? Comment celle-ci peut-elle avoir un comportement différent de celui d'une Room "normale" ?
Pour y remédié, j'ai créé une classe RoomRandomizerForMovingChracter qui reprend exactement la même structure que RoomRandomizer. Je trouve que cela fait un peu trop "bidouillage" mais je ne vois pas comment me contenter d'une seule classe RoomRandomizer...
Réseaux sociaux