面向数据设计与Unity3d ECS笔记

acecase

1、部分历史

• 2002 GDC,《A Data-Driven Game Object System》 http://scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.pdf 用组合不用继承来实现游戏对象的实例，运行时组合带来了不少优势
  
• 2006 《Out of Tar Pit》http://curtclifton.net/papers/MoseleyMarks06a.pdf 感觉这个可以认为是面向数据方法或ECS在软件工程方面的理论基础
  
• 2007 《Entity Systems are the future of MMOG development》Entity Systems are the future of MMOG development - Part 1 这个系列基本上已经把ECS的概念阐述的很清晰了
  
• 2010 《 Introduction To Data Oriented Design 》面向数据的性能优势在这里已经基本总结出来了
  
• ？~2018《 Data-Oriented Design》 Richard Fabian https://www.dataorienteddesign.com/dodbook/ 作者应该跟进面向数据挺长时间了，软件工程层面与性能方面都有涵盖，但感觉作者比较偏激，不能除了面向数据就不能有别的开发方法了吧
  
• 2015 《 Comments on Data Oriented Design》 Comments on Data Oriented Design – Part I Comments on Data Oriented Design – Part II 一些思考，似乎没有新的东西
  
• 2020 《 Data oriented design is not about SoA and ECS》 Data oriented design is not about SoA and ECS – Alex Dixon 继续一些思考，好像也没啥新东西
  

2、概念

• Entity---仅仅标识实体，没有方法、没有数据
  
• Component---代表数据，没有方法
  
• System---与某类或几类Component相关的行为，主动处理，集合处理
  
• 依赖某种查询机制，来获取一个Entity集合上各Entity的符合条件的Component集合
  
  
  
  • 游戏对象数据库（key/Data/Query）
    
  • 关系数据库与关系代数
    
  • Unity3d ECS的EntityQuery
    
  
  

3、FRP范式论文《Out of Tar Pit》

• 复杂性是软件工程的核心问题
  
  
  
  • 三种复杂性来源
    
    
    
    • 状态引起的复杂性（State）
      
    • 控制引起的复杂性（Control）
      
    • 代码量引起的复杂性（代码量的增长需要脑力的平方增长来理解）
      
    
    
  
  
• 三种主要的编程范式
  
  
  
  • 命令式（以面向对象为代表讲述）
    
  • 函数式（Haskell、ML、Lisp）
    
  • 逻辑编程（Prolog）
    
  
  
• 降低复杂性的解决方案
  
  
  
  • 分离状态与控制，亦即用户数据与核心逻辑
    
  • 分离本质状态、逻辑与偶然状态、逻辑，消除不必要的偶然状态、逻辑
    
  
  

• 提出一种新的编程范式—函数关系式（FRP）
  

4、提升性能的原理

• Cache友好（0~10倍提升）
  
  
  
  • 保证遍历时访问的数据连续存放并且只包含需要访问的数据
    
  • SOA---数组的结构
    
  • SOAOS--结构的数组的结构
    
  • Unity3d ECS的Component Data Chunk
    
  
  
• SIMD（0~4倍提升）
  
• multithread（0~8倍提升）
  
  
  
  • Job System
    
  
  
• 分支预测，避免if/else（感觉提升不明显，同时很难避免）
  
• 异构编程（严格说与ECS无关，但ECS好像通常就是在实现异构编程的cpu部分）
  
  
  
  • cpu--延迟消除架构，利用cache与缓存来消除延迟
    
  • gpu--延迟隐藏架构，利用大量并发与快速切换来隐藏延迟（SIMT）
    
  
  

5、unity ECS 0.17

• system可以使用托管对象，job不可以，猜测原因是引用类型互相关联无法进行编译时分析，而job要运行在多线程必须保证没有数据访问冲突，因此不开启burst编译不使用多线程的job是可以使用托管数据的
  
• component里不能使用数组，nativearray也不可以（官方说这个是暂时的限制，后续会努力消除）
  
• shared component+archtype确定了chunk，目前看chunk的组织可以认为是固定的，或者说数据目前组织为2个层级：thunk与component data
  
• 应优先用systembase和Entities.ForEach，除IJobEntityBatch外，其它IJob开头的接口已经不推荐使用
  
• generic component应该是最多使用的component类型，后续应该会一直存在
  
• buffer component用来记录动态变化的数据，这应该是为了弥补component里不能使用数组的限制
  
• chunk component加IJobEntityBatch可以用来给每组同步数据或汇总每组数据
  
  
  
  • 因为chunk与component只有2级，所以只能用于2个层级的概念，比如一个部分作为一个整体可以接受指令，这些指令可以在部队逻辑里暂存到chunk component上，然后在IJobEntityBatch job里同步到部队里的各个单位。
    
  • 但是如果部队分为多个小队，每个小队再由单位构成这样的三层结构就没有类似的机制了
    
  
  
• Blob Asset用来保存只读的信息，可以用于配置数据，能在component里使用
  
  
  
  • 这看来是在ECS里访问配置数据的官方途径
    
  • 否则可能就只能将配置数据复制多份放到component data上了
    
  
  
• 在system里使用元素是struct的托管队列可以在system间传递信息，通过局部变量闭包，job里也能访问
  
• system的惯用法其实是fork and join的多线程风格
  

6、一些问题

• Unity3d ECS的版本目前还是早期实验性的，据说0.50版本2022年Q1推出，之后是1.0版本，但1.0版本只考虑支持unity 2022及以上版本
  
• Unity3d ECS可能存在不必要的内存拷贝，在移动设备上对内存带宽有一定影响，基于struct的开发方式非常不自然，开发效率较低
  
• chunk的组织方式只能是2级结构，对数据组织与遍历方式的设计有很大的约束
  
• 各System间传递信息有时候还是需要借助非ECS的方式，很难仅仅借助component data来传递信息（不是共享信息）
  
• 对功能逻辑，往往数据互相关联，component与system的拆分并不容易
  
• system拆分的依据很模糊（感觉仍然得是功能导向的），性能的提升仍然需要借助profiler来确定，很难在开发过程中进行大致判断
  
• 性能提升的技术原理来源于硬件底层，与问题域是割裂的，并且是实现细节相关的，在设计早期很难兼顾（因为此时如何实现还很模糊）
  

7、从面向对象到面向数据

• 感觉面向数据方法依赖实现细节，所以不太适合在分析与设计层面使用，一种可能的方式是设计时仍然采用适合问题域的方法，然后性能要求高的部分与面向数据开发方法结合
  
• 在实现上，可采用传统开发方法来为ECS准备数据与进行调度
  
• 这种调度可能是单向的，也就是从传统方法过渡到面向数据方法后，不宜再返回到传统方法（过程而非函数）
  

8、native实现

• 采用c++来实现ECS，感觉可能会更纯粹，比如内存拷贝或许更少，有机会应该试一试，不过缺少burst编译器，simd指令就需要自己来写了
  
• rust是否可以用来实现ECS？rust语言的所有权概念似乎能有效的减少内存拷贝。