问这种面向对象的RPG类结构足够好吗？

EN

不是的。像这样的继承树往往会倒下。尤其是在游戏里。

您更有可能使用更多的技术对象，例如：

AnimatedCharacter <-- 2dSprite

--编辑09:55 UTC，滚动新闻更新开始

因此，您要做的是将您的业务规则编成代码，或者在游戏的情况下，将您的“游戏逻辑”转换为继承树。来扩展你的例子。

Dragon : Mob
{
    override public void takeDamage(Damage damage)
    {
        if(damage.Type == Fire) { .. do nothing..}
    }  
}

问题是

它一直在扩张。所以说我发明了一个新的黑帮，萨拉曼德

FireResistantMob : Mob
Dragon : FireResistantMob 
Salamander : FireResistantMob

但这是不灵活的。假设我有一种新生物不受火和冰的伤害

RockGolem : FireResistantMob  : IceResistantMob //does not compile!!!

小的变化会产生很大的意想不到的影响。比如说我改变了火的伤害，这样它就可以燃烧库存物品。但现在我所有的耐火生物的库存并没有像预期的那样燃烧。

考虑到Mob是"Mobile“的缩写，我们需要共享和传播的功能不是与游戏规则、伤害、怪物类型等相关的功能，而是关于从一个位置移动到另一个位置的功能。如何在屏幕上显示东西，我们可以点击哪些东西等等。

一个带有变量的Mobile类可以解释所有可能的怪物类型。例：

public class Mobile : LevelContent
{
    Dictionary<DamageType, double> damageResistances;
}

喜欢组合而不是继承(请参阅堆栈溢出问题。)。创建无穷无尽的继承子类仅仅是为了向对象添加特性就会产生一个庞大的、混乱的类树。它不能很好地处理具有多个特征的对象(您必须创建更多的类)，而且更难有可修改的特征。

通常最好是有一组简单的类，每个类都有一个列表/集合/其他容器，您可以在其中添加或删除额外的特征。