1）播放器：状态机+基于组件的体系结构。
播放器的常用组件：HealthSystem，MovementSystem，InventorySystem，ActionSystem。这些都是像的类class HealthSystem。
我不建议使用Update()有（这使得在通常情况下是没有意义的有卫生系统更新，除非你需要它的一些行动有每一帧，这些很少出现的一个情况下，你也可以想到的-玩家被下毒，你需要他有时会失去健康-我在这里建议使用协程；另一种会不断再生健康或运行能力，您只需掌握当前的运行状况或能量，并在时间到时调用协程以补充该水平。他被损坏了，或者他又开始跑了，依此类推。好吧，这有点离题，但我希望它很有用。
状态：LootState，RunState，WalkState，AttackState，IDLEState。
每个状态都继承自interface IState。IState在我们的案例中，仅以4种方法为例。Loot() Run() Walk() Attack()
另外，我们在class InputController哪里检查用户的每个输入。
现在InputController来看一个真实的例子：在我们中，检查玩家是否按下了WASD or arrows，然后是否也按下Shift。如果他只按了，WASD那么我们会_currentPlayerState.Walk();在这种情况发生时打电话给我们，并且currentPlayerState必须等于，WalkState然后WalkState.Walk() 我们拥有该状态所需的所有组件-在这种情况下MovementSystem，让玩家移动public void Walk() { _playerMovementSystem.Walk(); }-您看到我们这里有什么吗？我们有第二层行为，这对于代码维护和调试非常有用。
现在转到第二种情况：如果我们按WASD+会Shift怎样？但是我们以前的状态是WalkState。在这种情况下Run()将被调用InputController（不要混淆，Run()之所以调用是因为我们有WASD+ Shift签入InputController不是因为WalkState）。当我们调用_currentPlayerState.Run();的WalkState-我们知道，我们必须切换_currentPlayerState到RunState，我们在这样做Run()的WalkState，并用不同的状态下，再次调用它里面的方法，但现在，因为我们不想失去这个行动框架。现在我们当然打电话给_playerMovementSystem.Run();。
但是，LootState如果玩家在释放按钮之前不能走路或跑步，该怎么办？好了，在这种情况下，当我们开始掠夺时，例如E按下按钮时，我们调用_currentPlayerState.Loot();我们切换到LootState现在从那里调用它的调用。例如，我们在那里调用collsion方法来获取范围内是否有东西需要抢劫。我们在有动画或在哪里开始动画的地方调用协程，并检查玩家是否仍然按住按钮，如果协程没有中断，如果是，我们在协程结束时给予他战利品。但是如果玩家按下该WASD怎么办？- _currentPlayerState.Walk();被称为，但是这是关于状态机的漂亮之处，LootState.Walk()我们有一个空的方法，它什么也不做，或者像我将做的那样-玩家说：“嘿，我还没有洗劫，您可以等吗？” 当他结束抢劫时，我们转到IDLEState。
另外，您可以执行另一个脚本，该脚本class BaseState : IState实现了所有这些默认方法的行为，但是有这些脚本，virtual因此您可以override按class LootState : BaseState类的类型进行操作。
基于组件的系统很棒，唯一让我困扰的是实例，其中很多。而且它需要更多的内存并用于垃圾收集器。例如，如果您有1000个敌人实例。它们全部具有4个组件。4000个对象而不是1000个对象。如果考虑统一游戏对象具有的所有组件，那么Mb并不是什么大问题（我还没有运行性能测试）。
2）基于继承的体系结构。尽管您会注意到我们无法完全摆脱组件-如果我们想要干净且有效的代码，这实际上是不可能的。另外，如果我们要使用强烈建议在适当情况下使用的设计模式（也不要过度使用它们，则称为过度设计）。
想象一下，我们有一个Player类，该类具有退出游戏所需的所有属性。它具有健康，法力或能量，具有移动，奔跑和使用的能力，具有存货，可以制作物品，战利品，甚至可以建造路障或炮塔。
首先，我要说的是，库存，制作，移动，构建应该基于组件，因为拥有这样的方法不是玩家的责任AddItemToInventoryArray()-尽管玩家可以拥有一个这样的方法PutItemToInventory()来调用前面描述的方法（2层-我们可以根据不同的图层添加一些条件）。
建筑的另一个例子。播放器可以调用诸如之类的东西OpenBuildingWindow()，但Building会处理其余所有工作，并且当用户决定建造某些特定建筑物时，他会将所有所需的信息传递给播放器，Build(BuildingInfo someBuildingInfo)然后播放器便开始使用所需的所有动画来构建它。
SOLID-OOP原则。S-单一责任：这是我们在先前示例中所看到的。是的，但是继承在哪里？
此处：玩家的健康状况和其他特征是否应由其他实体处理？我想不是。没有健康就不会有玩家，如果有健康，我们就不会继承。例如，我们有IDamagable，LivingEntity，IGameActor，GameActor。IDamagable当然有TakeDamage()。
class LivinEntity : IDamagable {
private float _health; // For fields that are the same between Instances I would use Flyweight Pattern.
public void TakeDamage() {
....
}
}
class GameActor : LivingEntity, IGameActor {
// Here goes state machine and other attached components needed.
}
class Player : GameActor {
// Inventory, Building, Crafting.... components.
}
因此，在这里我实际上无法从继承中划分组件，但是我们可以像您看到的那样混合它们。例如，如果我们有一些不同的类型并且我们不想编写超出需要的代码，我们还可以为Building system创建一些基类。确实，我们也可以拥有不同类型的建筑物，实际上没有基于组件的好方法！
OrganicBuilding : Building，TechBuilding : Building。您无需创建2个组件并在其中编写两次代码即可进行通用操作或构建属性。然后以不同的方式添加它们，您可以使用继承的功能，以后可以使用多态性和封装。
我建议在两者之间使用一些东西。并且不要过度使用组件。
我强烈建议您阅读有关游戏编程模式的书-在Web上免费。