Implémentation d'un jeu de plateau

L’auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour j’ai un joueur qui peut se déplacer. Lorsqu’il se déplace, il vérifie si son niveau de fatigue n’est pas trop bas, auquel cas il doit se rendre dans une chambre pour se reposer.

Le problème est tout bête : une fois que le niveau fatigue est trop bas, comment le joueur notifie-t’il le jeu qu’il doit aller se reposer ?

Le code est composé d’une classe Game, une classe Player et une classe Map qui modélise la carte du jeu.

Ajouter un attribut map dans la classe Player me paraît exclu car le joueur étant responsable de lui-même selon le premier principe SOLID, il ne devrait pas disposer d’une carte pour s’orienter. Je pense que c’est le jeu qui devrait s’occuper d’aller déplacer le joueur.

Sauf que pour ça, je galère…

Édité par ache

+0 -0
Auteur du sujet

Le joueur est un élément du jeu.

MichelBillaud

D’accord ça, mais comment le joueur notifie-t’il le jeu que ce dernier doit l’envoyer dormir ? La classe joueur ne comporte aucune information sur le jeu.

Si j’essaye ta solution, la seule manière que je vois c’est que le jeu check régulièrement l’état de ses joueurs et suivant cela, leur demande d’aller se coucher.

Le problème avec cette solution c’est le single responsability principle de SOLID car alors le joueur n’est plus responsable uniquement de lui-même…

+0 -0

Cette réponse a aidé l’auteur du sujet

Comme le joueur fait partie du jeu, il devrait savoir à qui s’adresser quand il a quelque chose à signaler.

Je ne te propose pas de solution, je te dis simplement que penser le jeu et le joueur comme des entités indépendantes conduit à des gros problèmes.

Édité par MichelBillaud

+2 -0
Auteur du sujet

Je pense avoir un début de solution, qu’en penses-tu ?

public class Player {
    
    private int energy;
    private boolean needSleeping;
    
    public void doSomething() {
        if (energy > 0) {
            energy--;
            needSleeping = false;
        }
        else {
            needSleeping = true;
        }
    }
    
    // Méthode publique utilisée par game pour check l'état du joueur
    public boolean testSleeping() {
        return needSleeping;
    }
}

public class Game {
    ArrayList<Player> playersList;
    
    public void foo() {
        for (Player p: playersList) {
            if (p.testSleeping()) {
                // envoyer le joueur dormir
            }
        }
    }
}

Comme le joueur fait partie du jeu, il devrait savoir à qui s’adresser quand il a quelque chose à signaler.

Donner un attribut Game à Player serait une bonne solution ?

Édité par marius007

+0 -0

Cette réponse a aidé l’auteur du sujet

Salut,

Pourquoi un attribut needSleeping plutôt qu’une méthode qui renvoie energy > 0 (en particulier cela t’évite de faire le test et les modifications à chaque fois que tu augmentes/diminue l’énergie) ? Et ça pourrait être Game qui à chaque tick regarde si needSleeping.

Édité par Karnaj

Assez des salamis, je passe au jambon — Je fais un carnage si ce car nage car je nage, moi, Karnaj ! — Le comble pour un professeur de mathématique ? Mourir dans l’exercice de ses fonctions.

+1 -0
Auteur du sujet

Pourquoi un attribut needSleeping plutôt qu’une méthode qui renvoie energy > 0 ? Et ça pourrait être Game qui à chaque tick regarde si needSleeping.

Karnaj

Est-ce la responsabilité de Game de check à chaque tick l’état des joueurs ou bien aux joueurs à notifier le jeu qu’ils sont fatigués ? En fait c’est surtout ça que je cherche à comprendre. Dans mon projet je dois appliquer les bonnes pratiques et SOLID. Du coup, qu’est-ce qui convient le mieux dans ce cas ?

Je pense que (mais je peux me tromper) donner au jeu la responsabilité de check l’état des joueurs, c’est pas bon pour les bonnes pratiques en vertu du premier principe de SOLID, mais c’est peut être aussi parce que je n’ai pas bien compris la philosophie de ces bonnes pratiques.

+0 -0

Je vais prendre un cas analogue. Si un ennemi meurt, selon toi c’est au jeu de vérifier s’il est mort et de faire ce qu’il faut (peut-être afficher un message, ne plus afficher cet ennemi, jouer un son, le supprimer d’une éventuelle liste d’ennemis, etc.), ou c’est à l’ennemi de dire au jeu qu’il est mort ?

Et il ne faut pas perdre de vue qu’un jeu accède probablement déjà à l’état du joueur. Par exemple, est-il couché ou debout pour savoir comment l’afficher.

PS : une classe Game est déjà en soit une grosse classe. T’es-tu demandé quelle était sa responsabilité ?

Édité par Karnaj

Assez des salamis, je passe au jambon — Je fais un carnage si ce car nage car je nage, moi, Karnaj ! — Le comble pour un professeur de mathématique ? Mourir dans l’exercice de ses fonctions.

+1 -0
Auteur du sujet

Je vais prendre un cas analogue. Si un ennemi meurt, selon toi c’est au jeu de vérifier s’il est mort et de faire ce qu’il faut (peut-être afficher un message, ne plus afficher cet ennemi, jouer un son, le supprimer d’une éventuelle liste d’ennemis, etc.), ou c’est à l’ennemi de dire au jeu qu’il est mort ?

Désolé je ne vois vraiment pas. Pour moi, les deux se valent, au final le jeu recevra l’information qu’un joueur est mort et jouera le son correspondant. C’est quoi la bonne réponse ?

PS : une classe Game est déjà en soit une grosse classe. T’es-tu demandé quelle était sa responsabilité ?

Je n’en ai aucune idée. Je pense que le jeu créé les différents composants séparément et les assemble ensemble pour former le jeu. Je n’en sais pas plus.

:/

+0 -0

Cette réponse a aidé l’auteur du sujet

Si tu ne sais pas ce que fait le jeu, ça explique très bien que tu aies du mal à proposer une implémentation avec un découpage en classes qui tienne la route, avec des responsabilités précises et des interactions bien définies.

Quand on a dit "la classe Player va gérer le joueur, et la classe Board le jeu", on n’a pas avancé d’un millimètre.

Enfin si, peut être dans une mauvaise direction. On a décidé d un découpage à priori, qui va peut être dans la mauvaise direction.

Exemple si on a un plateau avec des cases notoires et blanches sur lesquelles il g à des pions blancs et noir, ça ne veut pas dire qu’il fait faire des classes plateau, case et pion avec des sous classes pour les blancs et les noirs.

+1 -0

J’ai modifié le titre afin de mieux s’y retrouver ^^

ache.one                 🦹         👾                                🦊

+2 -0
Auteur du sujet

par curiosité:

quelqu’un pourrait-il m’expliquer si j’avais placé un attribut private Game game; dans le Player, serais-ce une bonne idée pour résoudre mon problème initial ?

+0 -0

Cette réponse a aidé l’auteur du sujet

Pas forcément.

Une autre possibilité - qui serait assez logique - est de considérer qu’un Player est un sous-objet de Game, et donc de déclarer la classe Player à l’intérieur de la classe Game.

Tout ça, ça dépend des responsabilités qu’on confie à un Player. Peut-il faire partie de jeux différents ? Ou exister sans faire partie d’un jeu ? :-)

Inner classes, voir par exemple https://blog.xebia.fr/2012/11/08/back-to-basics-bien-maitriser-les-classes-internes-en-java/

Édité par MichelBillaud

+1 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte