Arquitectura de juego y estrategia de diseño 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 and Two Smoking Barrels .

He estado leyendo sobre algunos de los temas sobre SO relacionados con el desarrollo de juegos, aunque principalmente esta pregunta . Esto ha ayudado a renovar la forma original en que estaba creando los objetos.

Un problema en particular que estoy teniendo es definir el estado del juego. Mi enfoque inicial fue separar todo (por ejemplo, mantener las pilas de fichas dentro de una clase de Player ) pero después de leer las respuestas a la 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 alguna acción:

public interface IAction
{
    string Name { get; }

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

Ahora estoy convencido de que esto está derrotando 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 aumentara la apuesta, estaría creando un RaiseAction que implementa IAction , pero el IAction la interfaz solo acepta el estado actual del juego, lo que no creo que sea ideal si las pilas de fichas se almacenaran dentro de la clase Player .

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

Answer 1

En los juegos en línea que utilizan el comando-patrón (su IAction) es el estándar, Y comprobado, forma de hacerlo. No está orientado a objetos en el sentido del jugador, pero las acciones están orientadas a objetos, por lo que, desde un punto de vista puramente teórico, es un patrón de diseño sólido, supongo. Y en la práctica, así es como cada juego en línea exitoso 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 convierten en una especie de flujo.

Editar:

Mucho tiempo después de responder esto, regresé aquí y me di cuenta de que otra solución a este problema es implementar los Jugadores, Decks, etc. de GameState, como se deriva de una clase IState con una < strong> Aplicar (acción de acción) miembro. De esta manera, los objetos aplican acciones sobre sí mismos, en lugar de que la aplicación aplique acciones sobre objetos, esto asignaría acciones y estado a patrón-visitante en lugar de un patrón de comando. Cualquiera de las soluciones funcionará, donde el visitante tenga una mayor sobrecarga y más encapsulación, mientras que el comando es la solución más fácil con menos encapsulación.

Answer 2

Parece que podrías estar orientado a objetos por el bien de los objetos ...

Parece que el problema juego de bolos de Bob Martin.

EDITAR: -Resumen-
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 grupo enorme con muchas Clases y polimorfismo a 20 o 30 líneas de código elegantes. ¿Por qué? Porque realmente no tenían que estar allí en primer lugar