Projet Zuul: Exercice 7.49

Forum des exercices du projet Zuul

Exercice 7.49

Vous n'êtes pas abonné à cette discussion. Cliquez pour vous abonner.

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 ?

Oui l'essentiel dans cet exercice est de créer une classe de personnages qui changent de pièce.

Un tel personnage peut soit bouger dans une pièce adjacente, soit suivre le joueur, soit suivre un chemin pré-déterminé, ou toute autre philosophie de déplacement.

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 ?

Oui, mais il faut s'assurer que le GameEngine demande aux MovingCharacters de se déplacer ...

Petite remarque : pourquoi ne pas avoir conservé le nom aCurrentRoom ?

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.

Je comprends, mais cela nuit à la généralisation, et vous empêcherait par exemple de mettre en commun cet attribut dans une classe dont hériteraient Player et Character ...

Peut-ont au lieu de définir une nouvelle classe MovingCharacter crée la méthode public void move() dans Character avec un corps vide et donc redéfinir cette méthode seulement pour nos personnage qui doit bouger ?

Redéfinir move, mais où ???

--> dans MovingCharacter !

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;

public NPC (...){

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

Utilisez le même mécanisme pour le Beamer ...

J'aimerai faire en sorte qu'un Character se déplace de manière aléatoire. Mais peut-on limiter les Room où le Character peut se trouver ?

Oui, bien sûr.
(voir aussi mes réponses des 3 janvier et 19 avril 2014 ci-dessus)

Je rencontre une petite difficulté : pour pouvoir obtenir une Room aléatoire parmi une liste de Room (pour pouvoir déplacer mon MovingCharacter), j'ai pensé à réutiliser la classe RoomRandomizer (créée pour les TransporterRoom). Sauf que je rencontre un problème : ma classe RoomRandomizer possède des attributs statics. Ce qui fait que je ne peux pas utiliser cette classe pour ma TransporterRoom ET pour les MovingCharacter.

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

Pour moi, la question est : pourquoi y a-t-il des attributs statiques dans RoomRandomizer ?

Si vous parvenez à les remplacer par des attributs d'instance, vous aurez résolu votre problème.

Projet Zuul de conception orientée objet en Java d'un jeu d'aventure

Forum des exercices du projet Zuul

Exercice 7.49

Navigation

Administration

Navigation

Administration