Strategia di gioco e strategia di progettazione per un gioco di carte multiplayer

Question

Sono relativamente nuovo allo sviluppo del gioco, quindi ho deciso di creare un progetto per hobby da zero sia per esperienza che per intrattenimento. Il gioco specifico è simile al poker noto come Three Card Brag. Il gioco è giocato nel film Lock, Stock e Two Smoking Barrels.

Ho letto alcuni degli argomenti su SO relativi allo sviluppo del gioco, anche se principalmente this question. Questo ha aiutato a rinnovare il modo originale in cui stavo creando gli oggetti.

Un problema particolare che sto riscontrando è la definizione dello stato del gioco. Il mio approccio iniziale era quello di separare tutto (ad esempio mantenendo stack di chip all'interno di una classe Player) ma dopo aver letto le risposte allo question che ho menzionato in precedenza, sembra che tutti gli stati possibili del gioco debbano essere mantenuti all'interno di un oggetto GameState. Quello che mi è venuta è essenzialmente questo:

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

dove ogni CardGameState viene modificato da qualche azione:

public interface IAction 
{ 
    string Name { get; } 

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

Ora mi sento molto fortemente che questo sta sconfiggendo lo scopo della programmazione orientata agli oggetti , poiché i dati relativi al giocatore (in questo caso, il suo stack di chip, la mano e lo stato corrente) non sono incapsulati dall'oggetto Player.

D'altra parte, se un giocatore dovesse aumentare la scommessa, mi sarebbe la creazione di un RaiseAction che implementa IAction, ma l'interfaccia IAction accetta solo l'attuale stato del gioco, che non credo sarebbe l'ideale se il gli stack di chip sono stati memorizzati nella classe Player.

Fondamentalmente, la mia domanda è: posso avere il meglio di entrambi i mondi in modo tale che possa avere una rappresentazione esatta dello stato del gioco mantenendo contemporaneamente tutti i dati relativi ad un oggetto nello stato di gioco all'interno dell'oggetto dato?

Answer 1

Nei giochi online usando lo command-pattern (il tuo IAction) è il modo standard e collaudato di farlo. Non è orientato agli oggetti nel senso del giocatore, ma le azioni sono orientate agli oggetti, quindi da un punto di vista puramente teorico è un modello solido di design, immagino. E in pratica questo è il modo in cui ogni gioco online di successo che ho visto lo implementa, ma si noti che i giochi di azione normalmente usano azioni/pacchetti discreti molto piccoli, finché non diventa praticamente un flusso di sorta.

Edit:

Molto tempo dopo che io rispondere a questa, sono tornato qui e realizzato un'altra soluzione a questo problema è quello di implementare giocatori di gamestate, ponti, ecc ...come derivato da una classe IState con un elemento Apply (azione IAction). In questo modo gli oggetti applicano le azioni su se stessi, invece di fare in modo che l'applicazione applichi azioni sugli oggetti, ciò assocerebbe le azioni e lo stato a uno visitor-pattern anziché a un modello di comando. Entrambe le soluzioni funzioneranno, dove il visitatore ha il sovraccarico maggiore e più incapsulamento, mentre il comando è la soluzione più semplice con meno incapsulamento.

Answer 2

Sembra come si potrebbe essere oggetto-orientizing per amor di Object-Orient ...

Sembra come classico bowling game problema di Bob Martin.

EDIT: -Summary-
sua una lunga lettura, ma in fondo, attraverso il TDD e refactoring, un'applicazione bowling punteggio è passato da un enorme cluster con un sacco di classi e polimorfismo a 20 o 30 linee eleganti di codice. Perché? Perché non avevano davvero bisogno di essere lì in primo luogo