從零開始手敲次世代遊戲引擎（四）

上一篇我們在Linux上建立了Clang的編譯環境。現在我們可以開始著手引擎的開發了。

軟體開發有幾種模式。傳統的是瀑布式，就是先完成頂層的設計，然後進行細節設計和實現。這種方式有一個隱含的假設，那就是"成竹在胸"。好比一個造船廠，已經有著豐富的造船經驗，對於新用戶的新訂單，雖然有著很多定製化要求，但是整體的技術已經十分穩定，就可以採用這種模式。另外一種常用的則是迭代開發，將每次迭代控制在一個較小可控的範圍之內，每次迭代都產生一個比上一個版本進化了的，功能受限但是可執行的版本，日積月累，是一個不斷試錯的過程。這種方式就好比"摸著石子過河"，是一種探索式的開發方式，適用於開發經驗不足的領域或者需求不定的領域。

-- 脫線開始 --

本系列的目的主要是展示一個挑戰的過程，就好比直播一個《血源》的遊戲過程。展示也有兩種方法，一種是先在線下將《血源》玩成割草遊戲，然後上線展示；另外一種則是展示一個普通玩家的挑戰學習過程。本系列的立意是後者。

這是因為很多事情，說是一回兒事情，做起來就是另外一回兒事情了。很多事情都是道理很簡單但是操作起來就有無數的細節。就好比開發一個引擎是很難，但並不是難到裡面寫的都是外星文。事實上，知識都在那裡，概念很多人也都知道，當代先進的商用引擎也都開源放在那裡。建造一個引擎，甚至是打造一個主機平台，這裡面主要是工程的問題。而這些問題，即使是開源，沒有實際動手參與其中的，也很難知道。

所謂"工欲善其事，必先利其器"。在筆者的日常工作當中，遇到了很多不讀平台文檔，不做準備工作就開始匆匆上馬開發的人員。最終他們都卡在了操作細節上，而不是所謂的大局觀。有明明沒有連上所有配線卻在問為啥無法訪問開發機的，有沒有安裝sdk卻問編譯為啥不通過的，有到了遊戲快發布卻不知道在哪裡看控制台輸出的log的，有不知道調試程序並不是一定要打包安裝之後才可以進行的，有到了出補丁的時候卻忘記了原始版本放在哪裡的。這樣的例子並不是少數。

-- 脫線結束 --

雖然我們選用第二種方式，但是我們仍然需要有一個目標和基本方向。現實社會是複雜非線性的，任何模型只能是某種程度上的近似，迭代也只能發生在這個方向上。

下面就是關於這個引擎的一些基本考慮:

1。該引擎的設計意圖是用於教學演示目的

2。因此代碼應該簡單易讀

3。模塊清晰，且容易替代，方便做各種改進和嘗試

4。不依賴任何特定硬體，盡量使用標準技術

5。隨時追加新校則(?)

指導本開發總體的主要書籍是

http://gameenginebook.com/

在具體的設計實現方面，盡量吸收當時能夠獲取到的最新信息。

同時當然十分歡迎感興趣的朋友的加入。無論是通過評論的方式，投稿的方式，還是github的pull request的方式。

(-- 題外話開始 --)

知乎的手機app寫作功能還是十分受限，所以這兩期格式上會比較單調。日後上pc修正。

(-- 題外話結束 --)

一個遊戲引擎的主體架構，可能隨著遊戲類型的豐富和遊戲複雜度的提升，在最近的10-20年里有了很多的變化。比如2D到3D的進化，線性流程到開放世界的進化，確定性AI到不確定性AI的進化，卡通風格畫面到電影品質畫面的進化，單機到網路的變化，小團隊製作到動則數百人大製作的變化，等等。

然而，如果從計算機硬體的角度來看，無論是哪種類型的遊戲，其基本的流程又是十分類似的。獲取外部的輸入，執行某種策略，更新場景物體狀態，繪製畫面，輸出畫面。

從軟體系統分類角度來看，遊戲系統屬於軟實時系統。所謂軟實時系統，就是它首先要求特定的任務在特定的時間片段內完成（保持一定的幀率）。但如果沒有完成，也不會造成傷及人身的重大事故的系統。

在工業界，對於用於生產的實時系統，一般是採用實時操作系統。這種系統所執行的每個任務的執行時間都是事先設計好的。到了時間沒有執行完，就會執行緊急措施。

在主機遊戲開發領域，早期的遊戲開發其實很類似這種情況。那時候的主機並沒有什麼遊戲引擎的概念，連一個像樣的操作系統也是沒有的。遊戲開發工程師們讀著硬體的各種參數資料，數著byte和cycle，用一張龐大的spreadsheet計算著各種資源的存放位置和調用周期。這種風格的開發至少延續到PS2世代。在那個世代里，最強的是日本的開發商。因為他們有秋葉原，有極強的計劃性。這些老頭們現在仍然是日本大廠的中堅力量，然而他們顯然已經被時代甩在了後面。

隨著硬體的摩爾定律式的發展，遊戲內容容量也出現雪崩式增長，這樣的開發手法已經變得沒有實際操作性了。人們已經不可能去一一指定所有的細節，取而代之的則是制定一些規則，讓計算機按照這些規則自己去調度安排資源分配，這就是操作系統和引擎runtime開始導入到主機的一個重要原因。而這些是歐美的強項，遊戲圈因此也出現了往歐美一邊倒的局面。

另外一個方面，如此龐大的內容資源製作和管理也日漸成為遊戲開發的核心問題。增加人力自然是一個辦法，也是業界最先採用的方法。然而人是典型的非線性資源，每增加一個人帶來的不僅僅是一個人的工資，更是增加了（n*（n-1））/2-（（n-1）*（n-2））/2=n-1條溝通路徑，和無數的不確定性，勞動生產率快速下降。

因此，隊伍規模不能無限地擴張。於是下一個目標就是提高生產單位的生產率。加班加點從原來的忘我工作成為了現在的強制要求。

然而即使是這樣也是不夠的。疲勞在累積，到了一定程度人會作自由落體運動。新人補進來又是長長的適應周期。

所以剩下的辦法就是改革生產工具，計算機不僅僅是用來跑遊戲，還要用來寫遊戲。這就萌生了所謂遊戲製作pipeline的概念，也是遊戲製作走向工業化的標誌。

知乎里有很多諸如「中國為什麼沒有AAA大作?」這樣的問題，有很多大牛從很多方向做了解答。我覺得答得都很棒。但是我想加一條，那就是中國的遊戲開發，甚至是更為廣泛的軟體開發，其生產工業化水平較低，這也是一個很重要的原因。

又跑遠了。國內能寫這種總結式批評文章的人太多，知乎上就一大把，我還是回到實際操作上。

當代引擎除了runtime，還有一個重要的組成部分就是editor。這個editor就是用來提高生產率的。在以前，遊戲的各種資源必須由程序一個一個放進去。而有了editor，遊戲本身的製作就可以交給程序以外的人員了。《古墓麗影4》開放了一個關卡編輯器，那個就是當代引擎editor部分的祖先之一。editor在計算機軟體屬於應用程序，和runtime的性質很不一樣。但是，editor的性質和遊戲卻是很相近的。比如南夢宮的《坦克大戰》，裡面就是自帶關卡編輯器的，而且這個編輯器小孩都能玩得很溜。

前面提到我們的引擎設計的一個要求是要跨平台。然而editor所要求的GUI部分是最難跨平台的部分之一，因為不同平台這部分的API實在是差得太遠。但是我們既然要寫一個跨平台遊戲引擎，那麼為什麼不就用這個引擎來跑editor呢？這其實也是目前主流商用引擎比較廣泛採用的一個辦法。當然遊戲的渲染引擎與GUI的繪製方式上有很多本質的差別，一些著名的商用引擎至今沒有很好用的GUI控制項，這個我們後面相關章節再討論。

綜合以上，我們可以確定開發順序是先進行runtime的開發，然後是editor的開發。

根據上面寫了的一般遊戲的通用處理流程，我們可以很自然地想到我們將會需要下面這些模塊:

1。輸入管理模塊，用來獲取用戶輸入

2。策略模塊，用來執行策略

3。場景管理模塊，用來管理場景和更新場景

4。渲染模塊，用來執行渲染和畫面輸出

5。音頻音效模塊，用來管理聲音，混音和播放

6。網路通信模塊，用來管理網路通信

7。文件I/O模塊，用來管理資源的載入和參數的保存回復

8。內存管理模塊，用來調度管理內存上的資源

9。驅動模塊，用來根據時間，事件等驅動其它模塊

10。輔助模塊，用來執行調試，log輸出等輔助功能

11。應用程序模塊，用來抽象處理配置文件，特定平台的通知，創建窗口等需要與特定平台對接的部分

(-- EOF --)

本作品採用知識共享署名 4.0 國際許可協議進行許可。