2023年7月3日发(作者：)

游戏设计模式——⾯向数据编程思想前⾔：随着软件需求的⽇益复杂发展，远古时期⾯的向过程编程思想才渐渐萌⽣了⾯向对象编程思想。当⼈们发现⾯向对象在应对⾼层软件的种种好处时，越来越沉醉于⾯向对象，热衷于研究如何更加优雅地抽象出对象。然⽽现代开发中渐渐发现⾯向对象编程层层抽象造成臃肿，导致运⾏效率降低，⽽这是性能要求⾼的游戏编程领域不想看到的。于是现代游戏编程中，⾯向数据编程的思想越来越被接受（例如Unity2018更新的ECS框架就是⼀种⾯向数据思想的框架）。⾯向数据编程是什么？先来⼀个简单的⽐较：

⾯向过程思想：考虑解决问题所需的各个步骤（函数）。⾯向对象思想：考虑解决问题所需的各个模型（类）。⾯向数据思想：考虑数据的存取及布局为核⼼思想（数据）。那么所谓的考虑数据存储/布局是什么意思呢？先引⼊⼀个有关CPU处理数据的概念：CPU多级缓存。CPU多级缓存（CPU cache）在组装电脑购买CPU的时候，不知道⼤家是否留意过CPU的⼀个参数：N级缓存（N⼀般有1/2/3）什么是CPU缓存：

更详细来说，结构应该是：CPU<---->寄存器<---->CPU缓存<---->内存可以看到CPU缓存是介于内存和寄存器之间的⼀个存储区域，此外它存储空间⽐内存⼩，⽐寄存器⼤。为什么需要CPU多级缓存:CPU的运⾏频率太快了，⽽CPU访问内存的速度很慢，这样在处理器时钟周期内，CPU常常需要等待寄存器读取内存，浪费时间。⽽CPU访问CPU缓存则速度快很多。为了缓解CPU和内存之间速度的不匹配问题，CPU缓存则预先存储好潜在可能会访问的内存数据。CPU多级缓存预先存的是什么：

时间局部性：如果某个数据被访问，那么在不久的将来它很可能再次被访问。空间局部性：如果某个数据被访问，那么与它相邻的数据很快也能被访问。CPU多级缓存根据这两个特点，⼀般存储的是访问过的数据+访问数据的相邻数据。CPU缓存命中/未命中：

CPU把待处理的数据或已处理的数据存⼊缓存指定的地址中，如果即将要处理的数据已经存在此地址了，就叫作CPU缓存命中。如果CPU缓存未命中，就转到内存地址访问。提⾼CPU缓存命中率要尽可能提⾼CPU缓存命中率，就是要尽量让使⽤的数据连续在⼀起。由于⾯向数据编程技巧很多，本⽂篇幅有限，只介绍部分。使⽤连续数组存储要批处理的对象1，传统的组件模式，往往让游戏对象持有⼀个或多个组件的引⽤数据（指针数据）。（⼀个典型的游戏对象类，包含了2种组件的指针）

1. class GameObject {2. //....GameObject的属性3. Component1* m_component1;4. Component2* m_component2;5. };复制代码下⾯⼀幅图显⽰了这种传统模式的结构：

游戏对象/组件往往是批处理操作较多（每帧更新/渲染/其它操作）的对象。这个传统结构相应的每帧更新渲染代码：

1. GameObject g[MAX_GAMEOBJECT_NUM];2.

3. for(int i = 0; i < GameObjectsNum; ++i) {4. g[i].update();5. g[i].draw();6. if(g[i].componet1 != nullptr)g[i].componet1->update();7. if(g[i].componet2 != nullptr)g[i].componet2->update();8. }复制代码⽽根据图中可以看到，这种指来指去的结构对CPU缓存极其不友好：为了访问组件总是跳转到不相邻的内存。倘若游戏对象和组件的更新顺序不影响游戏逻辑，则⼀个可⾏的办法是将他们都以连续数组形式存在。注意是对象数组，⽽不是指针数组。如果是指针数组的话，这对CPU缓存命中没有意义（因为要通过指针跳转到不相邻的内存）。

1. GameObject g[MAX_GAMEOBJECT_NUM];2. Component1 a[MAX_COMPONENT_NUM];3. Component2 b[MAX_COMPONENT_NUM];复制代码（连续数组存储能让下⾯的批处理中CPU缓存命中率较⾼） 1. for (int i = 0; i < GameObjectsNum; ++i) {2. g[i].update();3. g[i].draw();4. }5. for (int i = 0; i < Componet1Num; ++i) {6. a[i].update();7. }8. for (int i = 0; i < Componet2Num; ++i) {9. b[i].update();10. }复制代码2，这是⼀个简单的粒⼦系统：

1. const int MAX_PARTICLE_NUM = 3000;2. //粒⼦类3. class Particle {4. private:5. bool active;6. Vec3 position;7. Vec3 velocity;8. //....其它粒⼦所需⽅法9. };10.

11. Particle particles[MAX_PARTICLE_NUM];12. int particleNum;复制代码它使⽤了典型的lazy策略，当要删除⼀个粒⼦时，只需改变active标记，⽆需移动内存。然后利⽤标记判断，每帧更新的时候可以略过删除掉的粒⼦。当需要创建新粒⼦时，只需要找到第⼀个被删除掉的粒⼦，更改其属性即可。1. for (int i = 0; i < particleNum; ++i) {2. if (particles[i].isActive()) {3. particles[i].update();4. }5. }复制代码表⾯上看这很科学，实际上这样做CPU缓存命中率不⾼：每次批处理CPU缓存都加载过很多不会⽤到的粒⼦数据（标记被删除的粒⼦）。⼀个可⾏的⽅法是：当要删除粒⼦时，将队列尾的粒⼦内存复制到该粒⼦的位置，并记录减少后的粒⼦数量。（移动内存（复制内存）操作是程序员最不想看到的，但是实际运⾏批处理带来的速度提升相⽐删除的开销多的⾮常多，这也是⾯向数据编程的奇妙之处。）

1. particles[i] = particles[particleNum];2. particleNum--;复制代码这样我们就可以保证在这个粒⼦批量更新操作中，CPU缓存总是能以⾼命中率击中。

1. for (int i = 0; i < particleNum; ++i) {2. particles[i].update();3. }复制代码冷数据/热数据分割有⼈可能认为这样能最⼤程度利⽤CPU缓存：把⼀个对象所有要⽤的数据（包括组件数据）都塞进⼀个类⾥，⽽没有任何⽤指针或引⽤的形式间接存储数据。实际上这个想法是错误的，我们不能忽视⼀个问题：CPU缓存的存储空间是有限的于是我们希望CPU缓存存储的是经常使⽤的数据，⽽不是那些少⽤的数据。这就引⼊了冷数据/热数据分割的概念了。

热数据：经常要操作使⽤的数据，我们⼀般可以直接作为可直接访问的成员变量。冷数据：⽐较少⽤的数据，我们⼀般以引⽤/指针来间接访问（即存储的是指针或者引⽤）。⼀个栗⼦：对于⼈类来说，⽣命值位置速度都是经常需要操作的变量，是热数据；⽽掉落物对象只有⼈类死亡的时候才需要⽤到，所以是冷数据；

1. class Human {2. private:3. float health;4. float power;5. Vec3 position;6. Vec3 velocity;7. LootDrop* drop;8. //....9. };10.

11. class LootDrop{12. Item[2] itemsToDrop;13. float chance;14. //....15. };复制代码更多⼩细节（不常⽤）⾯向数据编程还有更多⼩细节，但是这些都不常⽤，就只作为⼀种思考⾯向数据编程的另类⾓度。对多维数组的遍历：int a[100][100];

1. for(int x=0;x<100;++x)2. for(int y=0;y<100;++y)3. a[x][y];4.

5. for(int y=0;y<100;++y)6. for(int x=0;x<100;++x)7. a[x][y];复制代码内循环应该是对x递增还是对y递增⽐较快？答案是：对y递增⽐较快。因为对y的递增，结果是⼀个int⼤⼩的跳转，也就是说容易访问到相邻的内存，即容易击中CPU缓存。⽽对x的递增，结果是100个int⼤⼩的跳转，不容易击中CPU。⽽内循环如果是y的话，那么就能内外循环总共递增100*100次y。但内循环如果是x的话，那么就内外循环总共只能递增100次y，相⽐上者，CPU击中⽐较少。额外⾯向数据编程可以说是对CPU优化的⼀个重要思想。但是在实际开发中，⼀定要注意不能忘记这个原则：不要过早优化！⾯向数据编程说到底不是针对软件需求的，⽽是针对CPU优化的。在游戏的迭代开发的后期，要是CPU性能出现瓶颈，才应去考虑使⽤⾯向数据编程技巧。