Estrategia de diseño y arquitectura del juego para un juego de cartas multijugador

Question

Soy relativamente nuevo en el desarrollo de juegos, así que decidí que quería crear un proyecto de hobby desde cero tanto para la experiencia como para el entretenimiento. El juego específico es similar al póker conocido como Three Card Brag. El juego se juega en la película Lock, Stock y Two Smoking Barrels.

He estado leyendo sobre algunos de los temas en SO con respecto al desarrollo de juegos, aunque en su mayoría this question. Esto me ayudó a renovar la forma original en que estaba creando los objetos.

Un problema particular que estoy teniendo es definir el estado del juego. Mi enfoque inicial fue separar todo (por ejemplo, mantener pilas de fichas dentro de una clase Player) pero después de leer las respuestas al question que mencioné anteriormente, parece que todos los estados posibles del juego deberían mantenerse dentro de un objeto GameState. Lo que se me ocurrió es esencialmente esto:

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

donde cada CardGameState se modifica mediante algún tipo de acción:

public interface IAction 
{ 
    string Name { get; } 

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

ahora me siento muy fuertemente que este es derrotar el propósito de la programación orientada a objetos , porque los datos específicamente relacionados con el jugador (en este caso, su pila de fichas, mano y estado actual) no están encapsulados por el objeto Player.

Por otro lado, si un jugador fuera a subir la apuesta, estaría creando un RaiseAction que implementa IAction, pero la interfaz IAction sólo acepta el estado actual del juego, que no creo que sería ideal si el las pilas de fichas se almacenaron dentro de la clase Player.

Básicamente, mi pregunta es: ¿puedo tener lo mejor de ambos mundos para que pueda tener una representación exacta del estado del juego y al mismo tiempo mantener todos los datos relacionados específicamente a un objeto dentro del estado del juego dentro de su objeto dado?

Answer 1

En juegos en línea usando el command-pattern (su IAction) es la manera estándar y comprobada de hacerlo. No está orientado a objetos en el sentido del jugador, pero las acciones están orientadas a objetos, así que desde un punto de vista puramente teórico es un patrón de diseño sólido, supongo. Y en la práctica es así como cada juego exitoso en línea que he visto lo implementa, pero tenga en cuenta que los juegos de acción normalmente usan acciones/paquetes discretos muy pequeños, hasta que prácticamente se convierte en una especie de flujo.

Editar:

mucho tiempo después de que responder a esta, he vuelto aquí y se dio cuenta de otra solución a este problema es poner en práctica los jugadores de gamestate, cubiertas, etc ...como derivado de una clase IState con un miembro Aplicar (acción de acción). De esta forma, los objetos aplican acciones sobre sí mismos, en lugar de que la aplicación aplique acciones sobre los objetos, esto correlacionaría las acciones y el estado en un visitor-pattern en lugar de un patrón de comando. Cualquiera de las soluciones funcionará, donde el visitante tiene una sobrecarga mayor y más encapsulación, mientras que el comando es la solución más fácil con menos encapsulamiento.

Answer 2

parece que es posible que sea por el bien de objeto-orientar orientizing a objetos ...

que parece ser un problema clásico de Bob Martin bowling game.

EDIT: -Summary-
Es una lectura larga, pero, básicamente, a través de TDD y refactorización, una aplicación de puntuación de bolos pasó de un gran grupo con un montón de clases y el polimorfismo a 20 o 30 líneas elegantes de código. ¿Por qué? Porque en realidad no necesitaban estar allí en primer lugar