我现在正在做的一件事与游戏有一些相似之处。出于说明的目的,我将使用一个虚构的假设游戏中的示例来解释我的问题。
让我们称之为DeathBlaster 4: The Deathening 吧。在 DB4 中,您有许多在移动时Ship会定期随机遇到的对象Phenomena。一个给定的在遇到它的时候Phenomenon可能有零个、一个或多个。例如,我们可能有四种和三种。EffectsShipShipsPhenomena
现象
===========================================
船舶重力井黑洞星云场
------------ -------------------------------------- ----
红船 +20% 速度 -50% 力量 -50% 护盾
BlueShip 无效果 无敌死亡 各种效果
绿船 -20% 速度死亡 +50% 护盾 船上现象
YellowShip 死亡 +50% 功率无效果
此外,Effects还可以相互交互。例如,GreenShip同时在 aGravityWell和 a中的 a 可能会在生成的和NebulaField之间产生某种协同作用。在这种情况下,协同效应本身就是一种——例如,这种相互作用可能会产生一种。除了作用于 a的集合之外,不需要任何信息来解决最终结果应该是什么。SpeedEffectShieldEffectEffectPowerLevelSynergyEffectEffectsShip
您可能会开始看到这里出现的问题。作为一种天真的第一方法,要么每个Ship人都必须知道如何处理每个人Phenomenon,要么每个Phenomenon人都必须知道每个人Ship。这显然是不可接受的,因此我们想将这些责任转移到其他地方。显然这里至少有一个外部类,可能是一个Mediator或Visitor某种。
但是最好的方法是什么?理想的解决方案可能具有以下属性:
Ship添加一个新的就像添加一个新的一样容易Phenomenon。- 不产生影响的交互是默认的,不需要额外的代码来表示。约定优于配置。
- 了解
Effects彼此之间的交互方式,并能够管理这些交互以决定最终结果。
我想我已经决定了我的方法,但我很想听听最佳设计共识是什么。你会从哪里开始?你会探索哪些途径?
后续更新:谢谢大家的回复。这就是我最终要做的事情。我的主要观察是,相对于可能的×交互的数量,不同的数量Effects似乎很小。即,虽然有许多可能的交互组合,但这些交互的结果种类数量较少。PhenomenaShips
可以看到,比如表格中虽然有12种交互组合,但效果只有五种:速度修改、力量修改、护盾修改、无敌、死亡。
我引入了第三个类 ,InteractionResolver来确定交互的结果。它包含一个映射Ship-Phenomenon对的字典Effects(基本上是一个执行效果的委托和一些元数据)。当计算交互的结果完成时,每一个都会Ship被传递EffectStack给它正在经历的对应。Effects
Ships然后使用EffectStack来确定它们的实际结果,方法是Effects向它们现有的属性和属性添加修饰符。
我喜欢这个,因为:
Ships 永远不需要知道Phenomena。Ship-关系的复杂性Phenomena被抽象为InteractionResolver.- 如何解决多种可能复杂的效果的细节由
InteractionResolver. 船只只需在必要时应用效果。 - 这可以进行其他有用的重构。例如,船舶处理效果的方式可以通过制作
EffectProcessorStrategy. 默认可能是处理所有效果,但是,比如说,aBossShip可能会通过使用不同的EffectProcessorStrategy.