Implémentation d'un jeu de plateau

Le problème exposé dans ce sujet a été résolu.

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…

+0 -0

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…

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.

+1 -0

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 ?

+0 -0

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.

+1 -0

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.

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

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

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.

:/

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.

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/

+1 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

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