帮助解耦一个游戏设计

Question

下面是当前的依赖关系图（用自由手绘的圆圈来表示 TheTXI)

一个游戏有玩家和他们之间共享的一个棋盘.一个玩家也可以访问棋盘，可以添加移动移动单位.一个玩家可以访问它所拥有的单位，包括棋盘上和棋盘外的单位（单位也知道它的主人，但可能可以删除，只做一个查询）.一个棋盘上有单位，并知道单位的位置.单位有能力（玩家可能也可以）.

我最不明白的是单位的能力。他们应该能够影响游戏中的任何东西，治疗伤害玩家单位，重新定位棋盘上的东西，甚至可能影响游戏本身（目前还没有这个需要，但它可能会出现）。

我怎么能拥有可以影响任何东西的能力，而不需要它们对所有东西都有参照物呢？ 我意识到每个能力可以也应该只对它需要的东西有参照物，但是一个单位类的能力是内置的，所以如果一个单位的能力影响到棋盘，它就需要以某种方式从单位获得对棋盘的参照？

我在尽量保持设计的灵活性，因为规则还没有定下来（我们正在创建一个游戏，而且还是很早期的游戏，所以是尝试一些东西，看看感觉如何，改变规则，直到游戏感觉正确为止）。

甚至是否有一个boardmap根本还没有定论，所以单位应该与之脱钩，目前就是这样。没有全局状态或任何 "神对象"（还没有），我希望保持这种状态。

具体来说是用Python，webapp，所以虽然问题本身是语言不可知的，但任何基于动态语言的一级函数的具体内容当然是欢迎的。

Answer 1

首先，让我给你指出精彩的 gamedev StackExchange. 如果你把这个问题发在那里，可能会有更多的运气。

至于你的问题本身，我想一个解决方案是将触发能力的对象的通知传递给游戏对象，然后游戏对象会解析这些通知，并将它们传递给特定的玩家或板块，再从那里传递给特定的单位。

这很难解释，所以让我试着用suedocode写出来......

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
   }
 }
}

Targeting-condition和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;
}

希望这能让你明白

Answer 2

你可能想得有点多。

请记住，你希望能够与你的代码库一起工作，因此，即使你有一段时间没有在那个特定的部分上工作，你也可以轻松地理解你的代码，这一点很重要。

如果你用文字描述你的游戏，你很可能会使用这样的内容:这是一个X玩家的游戏，在一个(specfics)的棋盘上进行.每个玩家控制Y个单位。

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

现在，棋盘将处理你的大部分问题.如果一个玩家与游戏互动，他很可能会在棋盘上做一些事情。

从一个简单的系统开始，允许你移动你应该能够移动的东西，同时不能移动你不应该移动的东西。

能力将最有可能是一个包含当前可用选择的列表，从整个列表中.这些将取决于单位，也许是棋盘的其他元素。

根据游戏的类型，你可以使用事件来通知单位有什么变化，或者只是在你需要的时候获得信息。

不要添加比你实际需要的更多的抽象层.从你的描述来看，能力似乎是你想花最多时间的部分，以确保你可以很容易地改变和增加它们。

从其他部分的简单设计开始，如果你发现你在某些点上需要额外的一层，就重构，这样可以避免分析瘫痪。Esp.当你想做一个 "整洁的设计 "时，很容易把事情搞得过于复杂。

你想让游戏运行起来。你希望能够轻松地阅读（和理解）你的代码.你的编码风格和知识甚至在项目工作时也会改变，你也会在编码时获得新的想法。