Архитектура игры и стратегия дизайна для многопользовательской карточной игры - PullRequest
Новая
       15

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

9 голосов
/ 03 марта 2009

Я относительно новичок в разработке игр, поэтому я решил, что хочу создать хобби-проект с нуля, как для опыта, так и для развлечений. Эта игра похожа на покер, известный как Трехкарточный брэг . В игру играют в фильме Запирание, сток и две дымящиеся бочки .

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

Одна конкретная проблема, с которой я сталкиваюсь, - это определение состояния игры. Мой первоначальный подход состоял в том, чтобы разделить все (например, хранить стеки в классе Player), но после прочтения ответов на вопрос , о котором я упоминал ранее, кажется, что все возможные состояния игры должны быть сохранены. внутри объекта 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.

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

Ответы [ 2 ]

6 голосов
/ 03 марта 2009

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

Редактировать:

Спустя долгое время после того, как я ответил на это, я вернулся сюда и понял, что еще одно решение этой проблемы состоит в том, чтобы реализовать PlayerState's Players, Decks и т. Д. ... как производные от класса IState с Применить (действие IAction) участник. Таким образом, объекты применяют действия к самим себе, вместо того, чтобы приложение применяло действия к объектам, это отображало бы действия и состояние в шаблон посетителя вместо шаблона команды. Любое решение будет работать, когда у посетителя большие издержки и больше инкапсуляции, а команда - более простое решение с меньшим количеством инкапсуляции.

1 голос
/ 03 марта 2009

Похоже, вы ориентируетесь на объект ради Ориента на объект ...

Похоже, классическая игра в боулинг Боба Мартина проблема.

РЕДАКТИРОВАТЬ: -Сумма-
Приложение для боулинга превратилось из огромного кластера с большим количеством классов и полиморфизма в 20 или 30 элегантных строк кода. Зачем? Потому что им действительно не нужно быть там с самого начала

...