design-patterns - 任何棋盘游戏建模的模式？

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

5年前关闭。



Improve this question




为了好玩，我正在尝试将我儿子最喜欢的棋盘游戏之一编写为一个软件。最终我希望在它之上构建一个 WPF UI，但现在我正在构建对游戏及其规则进行建模的机器。

当我这样做时，我不断看到我认为许多棋盘游戏常见的问题，也许其他人已经比我更好地解决了这些问题。

(请注意，玩游戏的 AI 以及围绕高性能的模式对我来说并不有趣。)

到目前为止，我的模式是:

表示游戏盒中实体的几种不可变类型，例如骰子、跳棋、卡片、棋盘、棋盘上的空格、金钱等

每个玩家的对象，其中包含玩家资源(例如金钱、分数)、他们的姓名等。

代表游戏状态的对象:玩家、轮到谁、棋盘上棋子的布局等。

管理转弯顺序的状态机。例如，许多游戏都有一个小的前游戏，每个玩家都滚动看谁先走；那是开始状态。当一个玩家的回合开始时，他们首先滚动，然后移动，然后他们必须在原地跳舞，然后其他玩家猜测他们是什么品种的鸡，然后他们获得积分。

是否有一些我可以利用的现有技术？

编辑:我最近意识到的一件事是游戏状态可以分为两类:

游戏神器状态 . “我有 10 美元”或“我的左手是蓝色的”。

游戏序列状态 . “我投了两次 double ；下一次把我送进 jail ”。状态机在这里可能有意义。

编辑:我在这里真正寻找的是实现多人回合制游戏(如国际象棋、拼字游戏或大富翁)的最佳方式。我确信我可以通过从头到尾的工作来创建这样的游戏，但是，就像其他设计模式一样，可能有一些方法可以使事情变得更顺利，如果不仔细研究，这些方法并不明显。这就是我所希望的。

Answer 1

似乎这是我现在才注意到的一个 2 个月大的线程，但到底是什么。我之前设计并开发了一款商业网络棋盘游戏的游戏框架。我们有一个非常愉快的工作经验。

你的游戏可能会处于(接近)无限数量的状态，因为玩家 A 有多少钱，玩家 B 有多少钱等等……因此，我很确定你想要远离状态机。

我们框架背后的想法是将游戏状态表示为具有所有数据字段的结构，这些数据字段一起提供完整的游戏状态(即:如果您想将游戏保存到磁盘，您可以写出该结构)。

我们使用了 Command Pattern代表玩家可以进行的所有有效游戏 Action 。这是一个示例操作:

class RollDice : public Action
{
  public:
  RollDice(int player);

  virtual void Apply(GameState& gameState) const; // Apply the action to the gamestate, modifying the gamestate
  virtual bool IsLegal(const GameState& gameState) const; // Returns true if this is a legal action
};

所以你看到为了决定一个 Action 是否有效，你可以构造那个 Action ，然后调用它的 IsLegal 函数，传入当前的游戏状态。如果有效，并且玩家确认了 Action ，则可以调用Apply函数来实际修改游戏状态。通过确保你的游戏代码只能通过创建和提交合法的 Action 来修改游戏状态(换句话说，Action::Apply 系列方法是唯一直接修改游戏状态的东西)，然后你确保你的游戏状态永远不会无效。此外，通过使用命令模式，您可以序列化玩家所需的 Action 并通过网络发送它们以在其他玩家的游戏状态上执行。

这个系统最终有一个问题，结果证明它有一个相当优雅的解决方案。有时 Action 会有两个或多个阶段。例如，玩家可能降落在大富翁的一处房产上，现在必须做出新的决定。从玩家掷骰子到决定是否购买房产之间的游戏状态是什么？我们通过展示游戏状态的“ Action 上下文”成员来管理这样的情况。 Action 上下文通常为空，表示游戏当前不处于任何特殊状态。当玩家掷骰子并将掷骰子 Action 应用到游戏状态时，会意识到玩家已经降落在一个未拥有的属性上，并且可以创建一个新的包含玩家索引的“PlayerDecideToPurchaseProperty” Action 上下文我们正在等待来自的决定。当 RollDice Action 完成时，我们的游戏状态表示它当前正在等待指定的玩家决定是否购买房产。除了“BuyProperty”和“PassPropertyPurchaseOpportunity”操作外，所有其他操作的 IsLegal 方法现在很容易返回 false，它们仅在游戏状态具有“PlayerDecideToPurchaseProperty”操作上下文时才合法。

通过使用 Action 上下文，在棋盘游戏的生命周期中，游戏状态结构永远不会完全准确地代表当时游戏中正在发生的事情。这是您的棋盘游戏系统非常理想的特性。当您可以通过仅检查一种结构来找到您想知道的有关游戏中发生的事情的所有信息时，您编写代码就会容易得多。

此外，它非常好地扩展到网络环境，客户端可以通过网络将他们的 Action 提交给主机，主机可以将 Action 应用于主机的“官方”游戏状态，然后将该 Action 回显给所有其他客户端以让他们将其应用于他们复制的游戏状态。

我希望这是简洁和有帮助的。