帮助解耦游戏设计答案

【问题标题】：Help with decoupling a game design帮助解耦游戏设计
【发布时间】：2011-02-03 14:52:21
【问题描述】：

这是当前的依赖关系图（TheTXI 带有手绘圆圈）

游戏中有玩家和他们之间共享的单个棋盘。玩家还可以访问棋盘，以便能够从中添加/移动/移除单位。玩家可以访问其拥有的单位，无论是在棋盘上还是棋盘外（一个单位也知道它的所有者，但可能可以将其删除并进行查找）。板上有单位并且知道单位的位置。单位有能力（玩家可能也有）

我无法弄清楚的最大问题是单位的能力。他们应该能够影响游戏中的任何东西，治疗/伤害玩家/单位，重新定位棋盘上的东西，甚至可能是游戏本身（目前还没有必要，但它可能会出现）。

如果我没有对所有事物的参考，我如何才能拥有可以影响任何事物的能力？我意识到每个能力都可以而且应该只引用它需要的东西，但是一个单位类有内置的能力，所以如果一个单位的能力影响董事会，它需要以某种方式从单位获得对董事会的引用？

我试图让设计尽可能灵活，因为规则还没有一成不变（我们正在创建一个游戏，而且还很早，所以它正在尝试一些东西，看看感觉如何，更改规则直到游戏感觉正确）

即使是否有棋盘/地图仍然悬而未决，所以单元应该与其当前的状态解耦。没有全局状态或任何“上帝对象”（目前），我想保持这种状态。

特别是在 Python、webapp 中，因此虽然问题本身与语言无关，但当然欢迎任何基于具有一流功能的动态语言的细节。

【问题讨论】：

:( 手绘圈子也没有回复？

标签： language-agnostic dependencies decoupling

【解决方案1】：

首先，让我为您指出精彩的gamedev StackExchange。您可能会更幸运地在此处发布此问题。

就您的问题本身而言，我认为一种解决方案是将触发能力的对象的通知传递给游戏对象，然后游戏对象将解析这些通知并将它们分发给特定的玩家或棋盘，并且从那里到特定单位。

很难解释，所以让我试着用伪代码写出来……

Game {
 getMe(); //Returns reference to singleton class. 
 list of players
 list of boards
}

Board { 
 list of units 
}

Unit {
 int health
}

function Unit.notifyAbility(source, targeting-condition, ability-code) {
  Game::getMe()->sendNotification(source, targeting-condition, ability-code);
}

function Game.sendNotification(source, targeting-condition, ability-code) {
 for each unit in list of units {
   if(unit matches targeting condition) {
     apply ability-code
   }
 }
}

目标条件和能力代码本身可以是传递相关信息的数据结构。更好的是，使它们成为虚拟类并使用某种形式的多态性来处理独特的情况。

例子：

AbilityCode {
 virtual function applyToUnit(target Unit)
 virtual function applyToPlayer(target Unit)
}

AbilityGainHP: child of AbilityCode {
 function applyToUnit(target Unit) { target.hp+= gainAmt; }
 int gainAmt;
}

希望这是有道理的。

【讨论】：

+1 因为我认为这是一个有用的答案，但是单人游戏对我来说不是一个选择，因为一次会进行不止一个游戏。我将需要一种方法，以一种不太复杂或与其他任何东西相结合的方式在游戏中注册能力。

【解决方案2】：

你可能想多了。

请记住，您希望能够使用您的代码库，因此即使您已经有一段时间没有处理过该特定部分，您也可以轻松理解您的代码，这一点很重要。

如果您用文字来描述您的游戏，您很可能会使用以下内容：这是 X 玩家的游戏，在 (specfics) 的棋盘上玩。每个玩家控制 Y 个单位。

所以，像这样开始你的设计。游戏（无论是您的完整代码，还是只是程序的 PLAYING 状态）都需要引用棋盘和玩家。

现在，董事会将处理您的大部分问题。如果玩家与游戏互动，他很可能会在棋盘上做点什么。

从一个简单的系统开始，它允许你移动你应该可以移动的东西，而不能移动你不应该移动的东西。

这些能力很可能是一个列表，其中包含整个列表中当前可用的选项。这些将取决于单元，也可能取决于董事会的其他元素。

根据游戏类型，您可以使用事件通知单位发生了变化，也可以在需要时获取信息。

不要添加比实际需要更多的抽象层。根据您的描述，这些能力似乎是您最想花时间的部分，以确保您可以轻松更改和添加它们。

从其他部分的简单设计开始，如果您发现在某些点需要额外的层，请进行重构。这将避免分析瘫痪。特别是。当你想要做一个“整洁的设计”时，很容易把事情复杂化。

你想让游戏运行起来。您希望能够轻松阅读（并理解）您的代码。即使在进行项目时，您的编码风格和知识也会发生变化，并且您还会在编码时获得新的想法。

【讨论】：