看代码发现UnitFactory的create函数在服务器和客户端是不一样的。
服务端的create函数通过UnitType走不同的switch,往unit上挂载不同的component,实现创建不同的unit类型。
而客户端的create函数则是直接使用服务器传过来的proto数据UnitInfo反序列化出了unit。
所以我理解unit其实就相当于拥有一些共同component及其处理,同时可以通过type的不同,自己再挂载另一些逻辑的东西。如果自己程序的Entity有需要统一处理的东西,那这些处理可以放在unit类似的机制中。
个人觉得demo中的unit最精彩的是实现了一套在服务器创建,在客户端反序列化的机制,至于其他的component,可以根据自己的需求增删,mailbox基本还是都需要的,movement大部分也需要。
自己根据unitType增加的component,也会在反序列化中递归得在client挂载上去,所以基本上unitType对unit的修改只要写一份在server的unitFactory中就行
至于在论坛里看到的另一个关于不能动的entity能不能用unit的讨论,个人觉得,理论上可以做另一套类似unit的机制来实现,但现实中估计没人会这么做。。。只要unit上多的功能不影响效率就不会去管它,都用unit会方便很多
不过现在有个问题,这样写的话,unit下所有类型都是扁平的,如果某几个unitType想归为一个小组(类似之前的派生类那种关系的感觉,A派生自unit,B,C派生自A,有逻辑需要寻找所有A及A子类进行处理),是通过判断是否包含某个特定的component进行确认么?或者有什么别的设计方法可以使用的?