Unityclient框架笔记二（组件实体开发模式的思考）

Posted 2020-09-11 lytwajue

        Unity的Entity-Component-System实现的很美丽，很灵活。许多文章也对这样的组件实体的开发模式倍加推崇。由于它契合这么一条规则：优先使用组合而不是继承。

        可是实际开发过程中，限制于我的个人能力。想实现一个相同美丽的基于组件的MMO框架是很困难的一件事情。

        这篇文章是个人开发过程中的一些思考，实际上。所谓美丽的框架是因人而异的。而且不一定是必须的，可以用自己熟悉的方式高速的完毕项目的开发就足够了。仅仅要开发过程不会感觉别扭，代码也不会把自己或其它人恶心到，策划改动需求的时候不会骂娘。后期不会出现各种难以调试的Bug。那么就是美丽的框架。

        从理论上说，所谓ECS就是一个Entity，持有一组Component。然后通过一系列的System来维护调度组件之间的逻辑。组件之间是相对独立的，最理想的方式是通过Event来进行消息传递。从这点来说Unity已经实现的很美丽了，GameObject能够绑定随意的MonoBehaviour，脚本组件有统一的入口，而且能够通过SendMessage发送消息。也能够通过GetComponent来获取一个详细的组件。直接调用其函数。

        我反编译了一大堆线上手游的源码。差点儿没有全然依赖组件模式进行开发的，很多其它的还是依赖一套继承体系来完毕。这里我自己的感觉就是偏底层或者逻辑独立性很强的功能适合组件模式，而逻辑交互很复杂的情况，过分依赖组件模式想要达到“理想”的效果，反而会适得其反。

        比方，理论上ECS中。Entity应该像GameObject一样，仅仅维护组件。不包括不论什么其它逻辑或者代码，全部须要调度的逻辑都应该放在System中，它会关注它负责的Component。 然而，在我看来，这样反而分割了逻辑。在实际项目中。要么非常难做到这种分离，要么会让代码变得非常散，难以维护。当查Bug的时候，不会由于这种代码分离变得轻松。反而会由于结构的散乱造成无从着手的情况。

        再说组件之间的消息通信。当游戏所有以组件方式来实现，而且组件之间通过消息来完毕调用或者參数传递。这种代码非常难写，而且非常难维护。事件从哪里抛出的，谁应该接受这个事件，持有哪些參数，这些都非常不直观。尽管达到了灵活的效果，可是副作用也非常明显，代码中充斥着各种各样的Event。非常难通过简单的查看、跟踪、调试理清楚游戏的脉络。

       《Domination》是这样实现的，一个EntityController，里面包括所有的组件，而且提供相应的接口。它能够通过相应的配置文件决定创建哪个组件。而外部仅仅维护一个EntityController，不管是Soldier还是Building，它都是一个Entity。仅仅只是一个挂接的是SoldierAttackComponent。一个挂接的是BuildingUpgradeComponent。从而产生不同的行为。

这样的实现方式给我一定的启示。由于它某种程度上说是符合ECS的。可是不得不说这样的实现方式也非常奇葩。EntityController非常庞大，尽管它没有维护详细的逻辑，可是单单是维护Component的接口就让它的代码达到几千行，更不要说它概念上的庞大了。

        《永恒战士3》的实现相对正统，是现阶段我能够接受的组件模式。只是严格说来这已经不是组件模式，而是组合代替继承的一种实现方式。它有一个ActionController。里面持有各种各样的Agent，如AIAgent  AttackAgent  MoveAgent等等，外部主要与ActionController进行交互。而内部则通过这些Agent分散代码和功能。

        Unity官方出的游戏《大天使》在我看来非常的Low。

宣传视频非常酷，可是实际游戏玩起来非常渣，不管是画面表现。还是游戏可玩性。

不得不说，专业做游戏的和专业做引擎的确实不是一个工种。就其代码来说，它作为Unity官方出品的游戏。居然没有体现Unity最先进的生产力，这实在是Low爆了。它的寻路是A* Path Finding Pro，界面是NGUI，动画是老的动画系统Animation。代码组织上强烈依赖接口设计，一个Actor继承自IBuffable  IHealthable  ITakeDamage等等接口，非常正统。可是也没有什么亮点。

       一些日韩排行榜霸榜的游戏。如《白猫》《钢铁骑士团》，事实上代码结构一点也不美丽，一个StageObj有几千行。

从这点来说过分关注结构反而是没有意义的，那么多畅销游戏。事实上实现的一点儿也不灵活。

自己习惯，好用，就足够了。

        其它还有非常多游戏，只是基本上大同小异。除去一些奇葩的实现外，基本上都是通过继承体系完毕基础的对象抽象，然后通过组件将对象中比較大或者独立的功能抽离出来。如状态机组件、AI组件、动画组件、角色属性组件等等。

        另外，有一点是很统一的，就是有限状态机的使用，基本上全部的游戏都是通过FSM来完毕角色的状态流转的。ARPG尤其如此。少部分的游戏的AI部分可能用到行为树。差点儿没有见过仅仅通过行为树，而不依赖状态机控制角色的。

在我想来，行为树每次都要进行整棵树的遍历，不管是从设计上说。还是效率上说都不适合游戏角色的行为描写叙述。而行为树所擅长的AI方面。一般简单的游戏通过状态机来维护就足够了。