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

> Après plusieurs semaines à se poser la question avec mon binôme,
C'est beaucoup trop !  Vous devez poser la question sur ce forum au bout de 1 ou 2 jours maximum.

> on ne comprend toujours pas l'utilité de la dualité Game/GameEngine tel que ces classes sont présentées dans zuul_avec_images.
> En effet, il semble que GameEngine ait littéralement aspiré tout ce que Game faisait et on ne retrouve dans Game que quelques lignes.
> Personnellement je vois cette version de la classe Game comme un encapsulage inutile de GameEngine.
La différence essentielle avec la version précédente est la répartition des rôles entre GameEngine et UserInterface.
Game ne sert plus alors qu'à créer ces 2 parties. Mais dans la suite, Game devra créer un joueur, puis gérer les versions applette et application de votre jeu.

> Pour le moment, nous avons pris la liberté de ne pas créer de classe GameEngine. Faut-il absolument en créer une où est-ce réellement sans importance ?
Compte tenu des explications ci-dessus, cette classe doit être créée pour représenter ce qu'on appelle dans beaucoup d'autres langages "le programme principal".

1) une rapide recherche dans google ou dans un dictionnaire nous apprend que deprecated veut dire "obsolète"

2) le message vous précise qu'il s'agit de la méthode enable(boolean) de la classe Component

3) la javadoc de la classe Component dit :
void enable(boolean b) Deprecated. As of JDK version 1.1, replaced by setEnabled(boolean).

Pour le savoir, il faut lire le code de cette méthode :
    public void setGUI(UserInterface userInterface)
    {
        gui = userInterface;
        printWelcome();
    }
En la récrivant plus proprement, cela donne :
    public void setGUI( final UserInterface pUserInterface )
    {
        this.aGui = pUserInterface;
        this.printWelcome();
    }
ce qui facilite la compréhension, j'espère que vous en conviendrez.

Son rôle est donc de mémoriser dans l'attribut gui du GameEngine, la UserInterface qu'on lui passe en paramètre, ce qui permettra ensuite au GameEngine d'appeler des méthodes sur la UserInterface. Accessoirement, elle appelle aussi printWelcome() pour bien débuter le jeu.

1) "J'ai lu que ça pouvait concaténer plusieurs types d'objets."
C'est surtout fait pour concaténer des String, d'où son nom !

2) Bien que log ne soit pas un StringBuilder mais une TextArea, append fonctionne de la même manière en concaténant des String (ici, le texte à ré-afficher qui s'allonge à chaque commande tapée).

Vous n'avez pas vu la méthode setGUI qui initialise bien l'attribut gui.
Ensuite, il faut chercher où/quand elle est appelée. Peut-être dans la classe Game ?

Sur quoi appelez-vous la méthode showCommands ?  Sur la classe Parser !?  Donc le compilateur vous dit que cette méthode devrait être statique.
Par contre, il n'y a pas de raison que cette méthode soit statique puisque vous disposez d'une instance de la classe Parser ... 

Veuillez également noter que le nom showCommands n'est plus adapté à cette méthode qui ne montre rien, mais qui retourne désormais une String ; getCommandList semble plus adapté dans ce cas.

C'est tout à fait normal que vous ne compreniez pas cet extrait de code.

Il fait en sorte que fermer la fenêtre du jeu provoque bien l'arrêt du programme.

Cette syntaxe bizarre est équivalente à :

Vous avez raison !

Cette ligne est une réminiscence de la version zuul-bad qui permettait de sortir de la boucle d'exécution des commandes, mais qui n'a plus lieu d'être dans cette version sans boucle dans processCommand.

1)

"L'erreur semble être que input est censé être un String mais n'en est pas un ..." est un mauvais diagnostic puisque la déclaration "String input =..." montre bien que la variable input est une String.

Donc, si le compilateur ne trouve pas la méthode interpretCommand(java.lang.String), c'est que cette méthode n'a pas un paramètre de type String ou bien que vous avez mal orthographié son nom ... Dans les deux cas, il faut aller le vérifier dans la classe de cette méthode. 

2)

"input se référe donc a entryField.getText() or je ne sais pas ce que cet élément est ..."

Il suffit de regarder la déclaration d'entryField pour savoir de quelle classe elle est, puis d'aller voir dans la javadoc de cette classe pour savoir ce que c'est et à quoi sert la méthode getText().

3)

"Il y a beaucoup d'entryField dans le programme mais il y a un seul getText() ..."

Il n'y a qu'une seule déclaration de la variable entryField, plusieurs utilisations de cette variable, dont l'une consiste à appeler la méthode getText() sur l'objet dont la référence est stockée dans entryField.

Comparez la signature de votre classe UserInterface avec celle de la même classe dans le projet zuul-with-images ...

... et ajoutez ce que vous avez oublié.

(si vous voulez plus d'explications sur le message d'erreur, demandez !)

Sans voir le programme, je dirais que vous avez conservé une ancienne version du Parser qui scanne directement le clavier, au lieu de scanner la String que la UserInterface a lu dans l'entryField.

Si ce n'est pas ça, mettez le projet sur votre compte esiee et venez en 5356.

L'erreur ne provient pas de la partie "Your command words are: " mais de la partie aParser.showCommands()

Pour que vous puissiez l'écrire après un +, il faut que ce soit une fonction qui retourne quelque chose ; or, le compilateur vous dit que cette méthode est void.

Il vous faut donc faire en sorte que cette méthode (en lui donnant un nom plus approprié) retourne une String contenant les commandes, plutôt qu'elle cherche à les afficher (comme on le faisait avant d'avoir une UserInterface).

Vous pourriez comprendre le problème :
- input est une String
- vous appelez interpretCommand en lui passant cette String
- alors que cette méthode attend un paramètre de type Command

Ce problème est probablement dû au fait que vous n'avez pas fait toutes les adaptations apportées par zuul-with-images, notamment la "nouvelle" méthode interpretCommand qui prend un paramètre de type String, et peut-être aussi le nouveau Parser.

Effectivement, comme au 7.18.1, il n'y a pas de raison de supprimer la méthode printLocationInfo qui nous sert notamment à chaque fois qu'on change de pièce.

Par contre, il faut modifier son corps pour qu'elle n'appelle plus System.out.println et qu'elle utilise l'instruction que vous indiquez.

Si vous voulez que je puisse vous aider, il faut être plus précis :

1) "je n'arrive pas à lancer le jeu" : que se passe-t-il exactement ?

2) quelle ligne de code provoque le message d'erreur que vous indiquez ?

1) oui, et aussi pour rendre explicite la liste des classes du JDK utilisées dans cette classe

2) oui, je ne crois pas qu'il y ait besoin d'une classe de ce paquetage ;
    comme dit dans l'énoncé, supprimez tous les import, puis corrigez les erreurs en ajoutant à chaque fois la classe signalée en erreur