Architecture de jeu et stratégie de conception pour un jeu de cartes multijoueur

Question

Le développement de jeux étant relativement nouveau pour moi, j’ai donc décidé de créer un projet de loisir à partir de rien, à la fois pour l’expérience et pour le divertissement. Le jeu spécifique est similaire au poker connu sous le nom de Brag des trois cartes . Le jeu est joué dans le film Verrouiller, stocker et deux barils fumeurs .

J'ai lu plusieurs articles sur SO concernant le développement de jeux, bien que la plupart cette question . Cela a aidé à réorganiser la manière originale de créer les objets.

Un problème particulier que je rencontre est la définition de l’état du jeu. Mon approche initiale consistait à tout séparer (par exemple, en conservant les piles de copeaux dans une classe Player ), mais après avoir lu les réponses à la question Comme mentionné précédemment, il semble que tous les états possibles du jeu doivent être conservés dans un objet GameState . Voici ce que je viens de dire:

abstract class CardGameState
{
    protected List<Player> _Players;
    protected Player _CurrentPlayer;
    protected Dictionary<Player, int> _Chips;
    protected Dictionary<Player, Hand> _CurrentHand;
    protected Dictionary<Player, PlayerStatuses> _PlayerStatus; // PlayerStatuses.InHand, PlayerStatuses.Folded, PlayerStatuses.SittingOut, etc.
    /* etc. */

où chaque CardGameState est modifié par une action:

public interface IAction
{
    string Name { get; }

    CardGameState Apply(CardGameState state);
    bool IsLegal(CardGameState state);
}

Maintenant, je sens vraiment que cela va à l'encontre de l'objectif de la programmation orientée objet, car les données spécifiquement liées au lecteur (dans ce cas, sa pile de puces, sa main et son statut actuel) ne sont pas encapsulées par le Lecteur objet.

Par contre, si un joueur relançait la mise, je créerais un RaiseAction qui implémenterait IAction , mais le IAction interface n'accepte que l'état de jeu actuel, ce qui, à mon avis, ne serait pas idéal si les piles de puces étaient stockées dans la classe Player .

En gros, ma question est la suivante: puis-je avoir le meilleur des deux mondes, de sorte que je puisse avoir une représentation exacte de l'état du jeu tout en conservant simultanément toutes les données relatives à un objet dans cet état du jeu?

Answer 1

Dans les jeux en ligne, le modèle de commande (votre IAction) est la norme, et prouvé, moyen de le faire. Ce n'est pas un objet orienté dans le sens du joueur, mais les actions sont orientées objet, donc d'un point de vue purement théorique c'est un modèle solide, je suppose. Et dans la pratique, c’est la façon dont tous les jeux en ligne réussis que je vois l’appliquent, mais notez que les jeux d’action utilisent normalement de très petites actions / paquets discrets, jusqu’à ce qu’il devienne pratiquement un flux de toutes sortes.

Modifier:

Longtemps après avoir répondu à cette question, je suis revenu ici et j'ai compris qu'une autre solution à ce problème consiste à implémenter les joueurs, les decks, etc. de GameState, dérivés d'une classe IState avec un < strong> Appliquer (action IAction) membre. De cette manière, les objets appliquent des actions sur eux-mêmes. Au lieu d’appliquer des actions à des objets, cela mapperait les actions et les indiquerait à un motif-visiteur au lieu d'un motif de commande. L’une ou l’autre des solutions fonctionnera, lorsque le visiteur aura une surcharge plus importante et plus d’encapsulation, alors que la commande sera la solution la plus facile avec moins d’encapsulation.

Answer 2

On dirait que vous pourriez être orienté objet pour l'amour d'objet orienté ...

Cela ressemble au classique problème de jeu de quilles de Bob Martin.

EDIT: -Sommaire-
C'est une longue lecture, mais en gros, grâce à TDD et à la refactorisation, une application de notation de bowling est passée d'un énorme cluster avec beaucoup de classes et de polymorphisme à 20 ou 30 lignes de code élégantes. Pourquoi? Parce qu'ils n'avaient pas vraiment besoin d'être là en premier lieu