1. 程式人生 > >遊戲設計模式——面向數據編程思想

遊戲設計模式——面向數據編程思想

color 模式 發現 內存 每次 date() 分割 cti 加載

前言:隨著軟件需求的日益復雜發展,遠古時期面的向過程編程思想才漸漸萌生了面向對象編程思想。

當人們發現面向對象在應對高層軟件的種種好處時,越來越沈醉於面向對象,熱衷於研究如何更加優雅地抽象出對象。

然而現代開發中漸漸發現面向對象編程層層抽象造成臃腫,導致運行效率降低,而這是性能要求高的遊戲編程領域不想看到的。

於是現代遊戲編程中,面向數據編程的思想越來越被接受(例如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種組件的指針)

class GameObject {
    //....GameObject的屬性
    Component1* m_component1;
    Component2* m_component2;
};

下面一幅圖顯示了這種傳統模式的結構:

技術分享圖片

一般的,遊戲對象/組件往往是批處理操作較多(每幀更新/渲染/其它操作)的對象。

而在圖中可以看到,這種指來指去的結構對CPU緩存極其不友好。

所以一個可行的辦法是將他們都以連續數組形式存在。

註意是對象數組,而不是指針數組。如果是指針數組的話,這對CPU緩存命中沒有意義(因為要通過指針跳轉到不相鄰的內存)。

GameObject g[MAX_GAMEOBJECT_NUM];
Component1 a[MAX_COMPONENT_NUM];
Component2 b[MAX_COMPONENT_NUM];

(連續數組存儲能讓下面的批處理中CPU緩存命中率較高)

for (int i = 0; i < GameObjectsNum; ++i) {
    g[i].update();
    g[i].draw();
}
for (int i = 0; i < Componet1Num; ++i) {
    a[i].update();
    a[i].draw();
}
for (int i = 0; i < Componet2Num; ++i) {
    b[i].update();
    b[i].draw();
}

2,這是一個簡單的粒子系統:

const int MAX_PARTICLE_NUM = 3000;
//粒子類
class Particle {
private:
    bool active;
    Vec3 position;
    Vec3 velocity;
    //....其它粒子所需方法
};

Particle particles[MAX_PARTICLE_NUM];
int particleNum;

它使用了典型的lazy策略,當要刪除一個粒子時,只需改變active標記,無需移動內存。

然後利用標記判斷,每幀更新的時候可以略過刪除掉的粒子。

當需要創建新粒子時,只需要找到第一個被刪除掉的粒子,更改其屬性即可。

for (int i = 0; i < particleNum; ++i) {
    if (particles[i].isActive()) {
        particles[i].update();
    }
}

表面上看這很科學,實際上這樣做CPU緩存命中率不高:每次批處理CPU緩存都加載過很多不會用到的粒子數據(標記被刪除的粒子)。

一個可行的方法是:當要刪除粒子時,將隊列尾的粒子內存復制到該粒子的位置,並記錄減少後的粒子數量。

(移動內存(復制內存)操作是程序員最不想看到的,但是實際運行批處理帶來的速度提升相比刪除的開銷多的非常多,這也是面向數據編程的奇妙之處。)

particles[i] = particles[particleNum];
particleNum--;

這樣我們就可以保證在這個粒子批量更新操作中,CPU緩存總是能以高命中率擊中。

for (int i = 0; i < particleNum; ++i) {
    particles[i].update();
}

冷數據/熱數據分割

有人可能認為這樣能最大程度利用CPU緩存:把一個對象所有要用的數據(包括組件數據)都塞進一個類裏,而沒有任何用指針或引用的形式間接存儲數據。

實際上這個想法是錯誤的,我們不能忽視一個問題:CPU緩存的存儲空間是有限的

於是我們希望CPU緩存存儲的是經常使用的數據,而不是那些少用的數據。這就引入了冷數據/熱數據分割的概念了。

熱數據:經常要操作使用的數據,我們一般可以直接作為可直接訪問的成員變量。

冷數據:比較少用的數據,我們一般以引用/指針來間接訪問(即存儲的是指針或者引用)。


一個栗子:對於人類來說,生命值位置速度都是經常需要操作的變量,是熱數據;

而掉落物對象只有人類死亡的時候才需要用到,所以是冷數據;

class Human {
private:
    float health;
    float power;
    Vec3 position;
    Vec3 velocity;
    LootDrop* drop;
    //....
};

class LootDrop{
    Item[2] itemsToDrop;
    float chance;
    //....
};


額外

面向數據編程可以說是對CPU優化的一個重要思想。

但是在實際開發中,一定要註意不能忘記這個原則:

不要過早優化!

面向數據編程說到底不是針對軟件需求的,而是針對CPU優化的。

在遊戲的叠代開發的後期,要是CPU性能出現瓶頸,才應去考慮使用面向數據編程技巧。

遊戲設計模式——面向數據編程思想