SuperMobs.lua.ecs

supermobs lua ecs unity

名词解释

• e Entity 实体
  类似于Unity的GameObject，仅仅只是一个东西，没有任何直接用处的一个东西
  可以理解为载体、容器

• c Component 组件
  组件是放在在Entity里面的东西，可以拥有各种属性
  与Unity中的Component类似，但只可以有属性，不能有方法

• s System 系统
  ecs世界里真正执行逻辑的部分，一般不可以存储任何属性
  ecs提供了一套便捷的API让每一个system都可以快速获取到要处理的数据
  各种不同的system分工合作，达到最终目的

• pool 池
  pool是entity的容器，某些情况下需要多个ecs世界并行，pool是最好的分隔方案

• matcher 匹配器
  matcher是system取数据的依据，作用对象是entity
  matcher之于ecs，相当于sql之于数据库

• group 组
  符合相同matcher的一组entity称为group
  与group相关有一些事件可以使用，例如：有新的entity加入指定group
  在group之内，可以预设排序、索引等高级查询功能

另类方式讲述ecs

有一个流水线，要做一种罐头

创建一个pool，名字叫罐头制作流水线

罐头由瓶子、盖子、水、糖浆、水果组成

我们最终要创建出的entity包含瓶子、盖子、水、糖浆、水果这五种component

流水线上有5道工序

需要5个system来实现这个过程

第一道工序，在合理的情况下（下游没有累积过多、总需求量没超），向流水线上放空瓶子

第一个system，在合适的时候，创建空entity，并添加瓶子组件

第二、三、四道工序，分别对应水、糖浆、水果，检查瓶子里没有自己要加的东西时，添加进去

第二、三、四个system，在entity上没有自己对应组件时，添加给entity

第五道工序，检查其他的都已经齐全，把盖子盖上

第五个system，当其他四个component都已经添加时，为entity添加盖子component

流水线把产品制作分成不同模块，方便分别改进优化
流水线为每个工人提供工作环境，单个工人不需要在意整体流程
产品出现问题时，可以在流水线上查找产品定位问题到单一工人
承担相同工作的工人可以在流水线上随意替换

ecs把流水线的好处带给coding

设计思路

使用ecs最大的难点是要转变设计思路，它与面向对象的程序设计思路相差甚远
下面从一个实际的需求开始讲述如何使用ecs的思路来设计解决方案

需求：服务器列表功能
1、服务器有 编号、名称、分组、排序、状态属性需要显示
2、需要自动选择玩家上次登录的服务器
3、玩家可以手动刷新服务器状态
4、服务器列表中要显示玩家在该服务器拥有的角色基本信息

一、基础数据结构设计

这一步需要设计出功能需要数据的最精简结构
这部分数据将是功能的核心数据，其他的数据都可以通过计算或者数据查询得到

在这个示例需求中，最核心的数据就是
    服务器固定信息：{编号、名称、分组、序号}
    服务器动态信息：{编号、状态}
    玩家信息：{上次登录的服务器编号}
    角色信息：{编号、名称、等级、所属服务器}
这样一个数据结构

PS：设计基础数据时要保证不同时变化的数据需要分开，示例中的服务器固定信息和动态信息
分开的好处是方便做数据匹配，可以让系统设计更加容易

二、完整的数据结构

在完整的数据结构里，将会数据的 整合、分组 设计
然后得出模块的Component设计

• 整合
  整合的过程与面向对象设计思路类似，把相关数据合在一起形成对象形式，给Entity赋予实际含义

  服务器固定信息、服务器动态信息都是服务器的数据，实际的逻辑是把这两个数据在一起使用
  玩家上次登录的服务器实际上是服务器的一个标签
  在需要的功能里，每个角色要跟随服务器来展现
  所以我们有如下的设计：
  

  ServerEntity { // 一个服务器
      ServerInfoComponent { // 服务器的基本信息
          id、name、group、order
      }
      ServerStateComponent {// 服务器状态信息
          state
      }
      isLastLogin // 是否是上一次登录的服务器
      ServerRoleListComponent {// 包含的角色id列表
          list
      }
  }
  RoleInfoEntity { // 一个角色
      RoleInfoComponent { // 角色信息
          id、name、level、serverid
      }
  }
  

• 分组
  把同类的Entity通过Component标识分组，然后加上索引或排序规则以便进行实际逻辑处理
  整合过程与面向对象思路很像，但这里绝不是简单的按照“对象类型”分组
  举一个简单的例子：

  人、汽车、空气 都可以移动
  人、汽车可以被看见，空气不行
  用面向对象思路来归类这三个东西已然GG
  在ecs的思路里，设计两个分组即可，分别是：可以移动的东西、可以被看见的东西

  这个分组概念与GO语言的interface更接近，可以参考来理解
  索引：参考sql数据的索引设计概念来理解，为分组内的数据设计快速查询方式（而不是遍历）
  排序：按照实际需求做排序规则，以便具体逻辑直接使用

  Group(ServerInfoComponent) { // 服务器数据组，ServerInfoComponent是分组标识
      index : ServerInfoComponent.id // 通过id索引一个服务器
      order : ServerInfoComponent.order // 通过order排序服务器
  }
  Group(RoleInfoComponent) { // 角色数据组，RoleInfoComponent是分组标识
      index : RoleInfoComponent.id // 通过id索引一个角色
      index : RoleInfoComponent.serverid // 通过id索引一个角色
  }
  

三、数据处理系统设计

这一步将会得到一些System的设计结论，从以下两个方向来思考

• 基础数据获得

  • 服务器固定信息：这些数据将会是游戏启动时直接获取，所有应该有两个system，一个当启动时发起固定信息请求，另一个当得到请求结果时转换数据按照设计的结构存储给ecs
  • 服务器状态信息：与固定信息类似，一个在获取固定信息后去发起请求，一个在得到请求结果后给 ServerEntity 添加 ServerStateComponent
  • 玩家信息：获取固定信息后在本地存储中读取上次登录的服务器id，然后通过Group(ServerInfoComponent)的ServerInfoComponent.id索引找到对应服务器entity，然后挂上LastLoginComponent标识；这是其一，另外还需要一个system在登录服务器时更新本地存储数据
  • 角色信息 : 启动时发起请求，得到请求结果时转换格式存储

• 完整数据结构组织

  • 在这个示例中，只有ServerRoleListComponent是计算得来的，做一个system，当角色数据和服务器数据都有了之后，通过Group(RoleInfoComponent)的RoleInfoComponent.serverid索引，把各个服务器里有的角色信息添加到ServerEntity上

四、具体功能实现

汇总一下前面的结论，所有的Component如下：

• ServerInfoComponent
• ServerStateComponent
• LastLoginComponent
• ServerRoleListComponent

• RoleInfoComponent

  所有的System如下（做了适当整合）：

• RoleRequestSystem 初始化时请求角色列表，返回数据时整理数据到ecs
• ServerRequestSystem 初始化时请求服务器列表数据，返回数据时整理数据到ecs
• ServerStateSystem 服务器列表更新时，请求状态数据，返回数据时添加到ServerEntity
• RoleListSystem 数据完整后，整理角色列表数据

lua版本API说明

Component

• ecs.component.registsingle(componentname, ...)
• ecs.component.regist(componentname, ...)
  注册组件，组件名一般使用“模块名.组件名”的形式，避免出现不同模块重名
  {...}是这个组件的属性列表，一个组件可以没有任何属性，仅仅只是一个标识，如：LastLoginComponent
  single表示这个组件在整个pool里最多存在一个，single的component拥有额外的一些接口进行数据查询

Matcher

• ecs.matcher.[componentname]
  匹配拥有componentname组件的entity
• ecs.matcher.[componentname].none
  匹配没有componentname组件的entity
• ecs.matcher.[componentname].any
  单独的一个any形式的matcher没有实际意义，需要与sub接口一起使用
• ecs.matcher.sub(...)
  将多个matcher合并一起，匹配拥有所有的没有标记的Component，拥有标记any的至少一个Component，不拥有任何一个标记none的Component

pool

• ecs.pool.create(poolname)
  创建一个名为poolname的池
• ecs.pool.get(poolname)
  获取已经创建的名为poolname的池
• pool:getgroup(matcher, ...)
  获取/创建满足matcher的group，ps：group不会重复创建，matcher相同则group相同
  可以传多个matcher，自动ecs.matcher.sub这些matcher，然后去获取group
• pool:createentity()
  创建一个entity
• pool:destroyentity(entity)
  删除entity
• pool.is[componentname] pool.has[componentname]
  限制componentname必须定义为single，使用is或者has取决于具体语义用哪一个更通顺
  读：判断pool中是否存在包含componentname的entity
  写：从false写为true,创建一个新的entity并且添加componentname组件；从true写为false，删除拥有componentname组件的entity
• pool.[componentname]entity
  获取pool中包含componentname的entity，限制componentname必须定义为single，只读
• pool:add[componentname] (...) pool:set[componentname] (...)
  与pool.is[componentname]=true基本等价，但是可以为Component的属性赋值，一般没有属性的Component使用is、has，有属性的使用add、set；另外，必须是明确当前pool中不存在包含componentname的entity才可以使用，否则将会报错，因为singleComponent只能存在一个
• pool:remove[componentname] ()
  与pool.is[componentname]=false完全等价，为提高阅读性而存在
• pool:replace[componentname] (...)
  相当于先执行remove，再执行add，比较安全的接口
• pool.[componentname]
  获取component

System

• ecs.system.create(systemname)
  创建一个system，systemname一般使用“模块名.系统名”的形式，避免出现不同模块重名
  这里创建的system并不是实际执行的实例，只是一个模板；实际调用system的方法时，传递的参数self才是真正的实例；特别是一个system在多个pool中生效时，不能明确实例，将会带来严重错误
• system:setinitialize(func(self))
  设置系统的初始化函数，在整个ecs被初始化时调用
• system:setexecute(func(self))
  设置系统为轮询式，每次被轮询，执行func

• system:setreactiveexecute(func(self, entities, count))
  设置系统为触发式，每次被轮询，如果有收集到触发的entity，就回调接口，并传入所有触发了的entity
  因性能缘故，entities并不是一般的luatable，只能使用如下方式遍历：

  for i = 1, count do
      local entity = entities[i]
      -- do some thing to entity
  end

  ps:如果一个entity触发了条件，但是在执行前被删除，或者不满足触发执行的确认条件，entities中将不包含此entity；这种情况下，count值可能为0
  

• system:addtrigger(matcher, evtType)

• system:addtrigger(triggerEvt)
  为触发式system添加触发侦听条件
  matcher代表指定的group，evtType有三种值

  • ecs.observer.eventtype.added
    entity新加入指定group
  • ecs.observer.eventtype.removed
    entity离开指定group
  • ecs.observer.eventtype.addedorremoved
    entity新加入或者离开指定group

  简单的matcher有缩写方式来指定triggerEvt
  ecs.matcher.[componentname].[added|removed|addedorremoved]
  ecs.matcher.[componentname].any.[added|removed|addedorremoved]
  ecs.matcher.[componentname].none.[added|removed|addedorremoved]

• system:setignoreselftriger()
  忽略自身操作触发的entity；默认是不忽略，自身执行触发的满足自己条件的entity将在下一次调度时回调回来
• system:setensurematcher(matcher)
  在执行回调之前，先检查触发事件的entity能够与matcher匹配，不匹配的将会过滤掉
• system:setexcludematcher(matcher)
  在执行回调之前，符合matcher的entity将被过滤掉

Group

• group:addindex(name, handler(entity))
  为group内的数据添加名为name的索引，handler是索引值的计算函数
  为性能考虑，只有与group有关的组件发生变化才会重新计算索引
  所有与group有关的函数，都适用这条规则，切记！

ecs.component.regist("A", "a")
ecs.component.regist("B", "b")
local p = ecs.pool.create("test")
local group = p:getgroup(ecs.matcher.A)
-- 用B组件的属性来做索引计算，但是group的声明中并没有涉及到B
-- ecs内部更新时，不会认为B组件的变化与这个group有任何关系
-- 所以索引值完全不正确，没法办法去使用
group:addindex("b", function(entity)
    return entity.hasB and entity.B.b or 0
end)
-- 实际的逻辑中，如果用A+B作为group的特征描述也ok，那么可以这样声明group
group = p:getgroup(ecs.matcher.A, eca.matcher.B)
-- 如果只有A可以作为特征描述，B不与特征有直接关系，那么可以这样做
-- 本质与getgroup(ecs.matcher.A)相同，但是向ecs系统说明了这个group与B有关
group = p:getgroup(ecs.matcher.A, eca.matcher.A.any, eca.matcher.B.any)

• geoup:addorder(ordername, filter(entity), compare, ...)
  为group中的entity添加一个名为ordername排序
  filter:过滤函数，nil表示不过滤，全部参与排序；函数的返回值表示是否参与排序
  compare:比较函数，排序的内部实际上就是orderdict，compare等价orderdict的参数
  {...}：排序计算使用的index，性能限制，只能使用索引值进行排序

• group:ipairs(ordername)
  按照指定的排序方式，遍历entity

for i, entity in group:ipairs("ordername") do
    print(i, entity)
end

• group:getindexentities(indexname, key)
  获取indexname索引的值是key的所有entity，返回类型是sortdict
• group:getindexentity(indexname, key)
  获取indexname索引的值是key的第一个entity（最早进入group的那个）
• group:getindexentitiesdict(indexname)
  获取indexname索引的数据，返回一个table，可用pairs遍历，key是索引的值，value是sortdict类型，包含所有索引值是key的entity
• group:getorderlength(ordername)
  获取指定排序列表的长度
• group:getorderentity(ordername, orderindex)
  获取指定排序列表中，在orderindex位置的entity
• group:destroyentities()
  删除整个group里的所有entity

Entity

• entity.is[componentname]
• entity.has[componentname]
• entity:addcomponentname
• entity:removecomponentname
• entity:replacecomponentname
• entity.[componentname]
  与pool中相应接口含义完全相同，只不过pool中只能操作singlecomponent，在entity上操作component就没有single限制了

Module

• ecs.start()
  启动ecs系统
  因性能限制，必须在ecs启动之前声明所有的component
  启动之后，ecs.component.regist、ecs.component.registsingle接口被禁用
• ecs.explicit(shorttable)
  特别声明当前脚本内的componentname缩写，类似于c#中的using
  缩写声明对所有的带有[componentname]的接口有效
  通过lua底层接口setfenv实现，如果脚本中有额外setfenv的需求，考虑使用ecs.customexplicit
  shorttable格式如下:

{
    -- using UnityEngine;
    "A.B.*",
    "C.*",
    -- using C = UnityEngine.Camera;
    c = "D.EE",
    f = "D.XXXX"
}

没有声明shorttable的情况下，ecs系统会在全局搜索以'.componentname'结尾的组件，如果只有一个，那就当做是这个组件来处理，如果不止一个，将会抛出error，"componet name XXXXX is not explicited"
以示例的shorttable来说明组件搜索过程：
1、查找“c = "D.EE"”这样的格式，如果匹配，那么就是等号右边就是组件的fullname
2、依次把componentname代入"A.B.*"这样格式，查找是否存在这样fullname的组件，如果有，查找结束
3、无视shorttable，去全局查找，有可能出现"componet name XXXXX is not explicited"的报错

• ecs.explicitrequire(shorttable, f)
  与ecs.explicit(shorttable)接近，只不过是在载入脚本时声明缩写，而不是在脚本执行时声明
  一般用于相同shorttable批量作用于一些脚本
  f：require的参数
• ecs.regmoduleandcreate(componentfiles, systemfiles, shorttable, poolname, systemsname)
  注册一个模块，推荐ecs的模块都适用这个接口来组织
  componentfiles：本模块所有的component注册文件路径，luatable的array形式
  systemfiles：本模块所有的system文件路径，luatable的array形式；将会以脚本在数组内、文件中的顺序依次注册到pool中
  shorttable：缩写声明，针对所有system文件
  poolname：自动注册system的pool的名字
  systemsname：在pool中为本模块的system创建一个组，这个参数是组名，一般使用模块名即可

编辑器的使用

• Pool Editor
  项目启动后，在Hierarchy中，DonotDestroyOnLoad下，有标注的就是为ecspool创建的GameObject
  选择GameObject，在Inspector中，可对pool执行操作
  
  常用功能:
  
  • Create Entity，在pool中创建一个新的entity
  • SortByCount，group列表按照包含entity的数量排序；默认按照group的matcher名字排序
  • 每项group后面的toggle，有勾选表示在Hierarchy中只显示勾选的group包含的entity，默认全部显示
  • clean filter，清除entity显示的过滤条件
  • Search，搜索group，过滤显示

• EntityEditor
  pool-GameObject的children是Entity-GameObject，有标识
  

  • Add Component，可以通过下拉菜单为entity添加component
  • Search，可以快速查找component，不相关的component会被隐藏
  • Retained by，列出了所在pool、所在group和当前所在的触发列表

  对于每一项component
  

  • 可以通过名字后面的"-"删除component
  • 值为null的字段，会显示CreateString（为字段赋值空字符串）、CreateNumber（为字段赋值0）
  • number类型的字段末尾有"str"按钮可以强转字段为string类型
  • string类型字段末尾有"num"按钮可以强转字段为number类型
  • Unity常见类型Vector2、Vector3、UnityEngine.Object可以使用编辑器修改
  • 任何component的值修改后都会自动执行replacecomponent

• SystemsEditor
  在Hierarchy中，DonotDestroyOnLoad下，有标注的是System-GameObject
  

• 曲线展示最近几帧包含的所有system执行消耗，纵轴单位是毫秒
• Total后面显示的是最近一次执行消耗，暂停按钮可以停止所有包含的sysytem
• 在暂停状态下，可以使用"step"按钮一帧一帧得去刷新
• 默认情况下，每个system的平均时间消耗是一直统计；使用"Reset average duration"可以调整平均消耗的统计周期，Always每帧刷新，VeryFast每30帧刷新，Fast每60帧刷新，Normal每120帧刷新，Slow每300帧刷新，Never从不刷新（默认值）；也可以使用"Rest"按钮立即刷新
• threshold，隐藏掉平均消耗在设定值以下的system
• Sort by execution duration，按照执行消耗排序system的显示；默认是按照执行顺序（与添加顺序相同）
• Search，搜索system，过滤显示
• Initialize Systems，有初始化函数的system执行消耗
• Execute Systems，有刷新执行的system的每次刷新执行消耗
• 白色的system是触发式的，灰色的system是每帧轮询的
• system中的toggle可以暂停system的执行

延伸阅读

• Entitas-CSharp，主要参考对象
• OverWatch研发团队分享ecs的使用经验