Игровая архитектура и стратегия дизайна для многопользовательской карточной игры

Question

Я относительно новичок в разработке игр, поэтому решил, что хочу создать проект для хобби с нуля для развлечения и развлечений. Конкретная игра похожа на покер, известный как Three Card Brag. Игра воспроизводится в фильме Замок, сток и два ствола для курения.

Я читал некоторые из тем, касающихся SO относительно разработки игр, хотя в основном this question. Это помогло обновить оригинальный способ создания объектов.

Одна конкретная проблема, с которой я сталкиваюсь, определяет состояние игры. Мой первоначальный подход состоял в том, чтобы отделить все (например, сохранить чипы в классе Player), но после прочтения ответов на question, о которых я упоминал ранее, кажется, что все возможные состояния игры должны поддерживаться в пределах объекта GameState. То, что я придумал, по существу, это:

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

где каждый CardGameState модифицируется какое-то действие:

public interface IAction 
{ 
    string Name { get; } 

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

Теперь я чувствую себя очень сильно, что это поражение цели объектно-ориентированного программирования , поскольку данные, конкретно связанные с игроком (в данном случае его стек фишек, рука и текущий статус), не инкапсулируются объектом Player.

С другой стороны, если игрок поднять ставку, я бы создать RaiseAction, который реализует IAction, но интерфейс IAction принимает только текущее состояние игры, что я не верю, было бы идеально, если чипы были сохранены в классе Player.

В основном, мой вопрос: могу ли я иметь лучшее из обоих миров, чтобы я мог точно представлять состояние игры, одновременно сохраняя все данные, относящиеся конкретно к объекту внутри игрового состояния внутри его заданного объекта?

Answer 1

В онлайн-играх с использованием command-pattern (ваш IAction) это стандартный и проверенный способ сделать это. Это не объектно-ориентированный в смысле игрока, но действия объектно-ориентированные, поэтому, с чисто теоретической точки зрения, это сплошной дизайн, я думаю. И на практике, как каждая успешная онлайн-игра, которую я видел, ее реализует, но обратите внимание, что в играх с действиями обычно используются очень маленькие сдержанные действия/пакеты, пока они практически не станут потоками.

Edit:

Долгое время после того, как я, отвечая на это, я вернулся сюда и понял другое решение этой проблемы заключается в реализации Игроки GameState в, палуб и т.д ...как получено от IState класс с Применить (действие IAction) участник. Таким образом, объекты применяют действия самостоятельно, вместо того, чтобы приложение применяло действия над объектами, это отображало бы действия и указывало бы на visitor-pattern вместо шаблона команды. Любое решение будет работать, где посетитель имеет большие накладные расходы и больше инкапсуляции, а команда - это более легкое решение с меньшим количеством инкапсуляции.

Answer 2

Похоже, вы могли бы быть объектно-orientizing это ради объектно-Orient в ...

Похоже классической bowling game проблемы Боба Мартина.

EDIT: -Summary-
Его долго читать, но, в основном, через TDD и рефакторинг, приложение для боулинга скоринг пошел из огромного кластера с большим количеством классов и полиморфизма до 20 или 30 элегантных строк кода. Зачем? Потому что им действительно не нужно было в первую очередь