引擎設計與商業模式

        這篇文章摘自“免費打工仔”在www.gameres.com上的發言，雖然字數不多，但對幾個引擎的評價卻一語中的。

引擎設計與商業模式

包括我在內的很多朋友都喜歡看國外引擎的代碼，並比較引擎之間的優劣。但是你會發現，每種引擎的設計都是於他開發人員和使用者及其相關，優秀的引擎不僅是設計上的優秀，更重要的是適應自身的商業（社區）模式。在這篇文章裡我們著重討論一下卡馬克的Quake 3引擎，Epic的Unreal 3，開源界的Ogre3D圖形引擎以及相應的Orz擴充架構。

一、Quake3=天才模式

在很早以前，我們只能接觸這款遊戲引擎的代碼。可以說卡馬克是中國遊戲圖形界的導師。我的很多前輩都是從這款引擎開始學起，並立志開發一款中國人自己的圖形引擎。後面介紹的虛幻引擎和Ogre3D引擎都或多或少的被這款引擎所影響。

提起Quake3引擎就不能不瞭解id公司和他的天才程式員卡馬克大神。約翰·卡馬克被稱為3D遊戲之父，因為其開創性的把3D渲染運用到了即時技術中來。他是圖形學界的牛頓，所有開發遊戲的人的偶像之一（另外一個是宮本茂）。有一本書《Doom啟示錄》就是講卡馬克和他的id公司的故事。在這本書中，你會發現卡馬克對於程式技術的癡迷勝過一起（甚至超過成 人錄影帶）。

所以Quake3以及其他id公司的圖形引擎產品，（曾經）唯一的目的是開發出最棒最新的圖形技術，把卡馬克的天才發揮到極致。id是卡馬克的公司，Quake3也是卡馬克的引擎。如同喬布斯和蘋果一樣，任何人也無法漠視卡馬克和Quake3之間的聯絡。

1 Quake3 極其重視效率，這樣可以便於在硬體支援前實現未來的圖形效果。

2 Quake3 代碼短小精湛，卡馬克對其不斷最佳化。

3 Quake3 不如其他引擎注重模組化，卡馬克一個人就能搞定。

4 Quake3 不需要重構，卡馬克擅長在最短的時間內重寫整個引擎。

5 Quake3 對使用者極其簡單，但擴充很難。如果需要擴充，卡馬克會重寫一個引擎。

Quake3以及同系列的引擎，在遊戲曆史上的價值是無可厚非的。但是你會發現，如果要修改這個引擎，基本上要瞭解所有的代碼。這些東西很緊密，如果你希望換一個圖形情境管理演算法，你會發現基本上要修改整個引擎。你可以很容易做出和《雷神之錘3》一樣的遊戲，但是很難把它修改成其他類型遊戲。（你會理解當年要卡馬克做RPG的時候甚至用辭職來威脅id管理層。）

國內有很多朋友企圖模仿Quake3的結構來實現一款圖形引擎或者遊戲引擎，但大部分都失敗了，另外的一部分也沒有獲得成功（掙紮中）。不是說Quake3引擎不好，是因為中國很難有類似的環境。Quake3的商業環境是，你需要一個靠技術來賺錢而不是靠產品的公司，另外還需要一個天才如卡馬克一樣的程式大師來驅動。基於這兩點，可以說Quake3的成功是無法複製的。

二、Epic的Unreal 3引擎 = 商業模式

很多朋友都有Unreal 3引擎的代碼，但我沒有讀過。我只是從一些看過Unreal 3的朋友的口中瞭解一些相關的資訊。這些資訊包括，

1 Unreal 3開發遊戲，如果不是極其複雜，只需要指令碼和編輯器就好了。它有極其強大的指令碼和編輯器系統。（上海育碧的一些朋友說的）。

2 Unreal 3代碼中有很多違反常規知識的地方，比如充斥著菱形繼承（C++虛擬繼承）。（一個看過代碼的朋友說的）

3 Unreal 3代碼寫的很難看（一個開發類似Quake國產引擎的朋友說的）。

4 Unreal支援大量平台，圖形效果非常好。

上面有很多條款我是沒辦法證實的，但是我們姑且就認為都是對的。

在《遊戲人》中有一段描寫Unreal誕生的故事，老闆並不看好為《虛幻競技場》重新開發一款引擎，因為已經有了一款卡馬克的了。要超越卡馬克的圖形技術太困難了。但是他們發現自己在編輯器的功能上可以領先id公司很多。基本上從那往後的10年裡，Unreal依靠這一點成為了最成功的商業引擎，在商業領域上擊敗了卡馬克。

1 Unreal 3 具有強大的指令碼和編輯器，這是為了給購買引擎的公司節約開發成本。

2 Unreal 3 有一些菱形繼承和緊湊的代碼。這是為了商業上的緊湊型，就算開放一部分原始碼，你也需要得到另外的授權，你無法單獨使用。（上面提及的朋友告訴我的）

3 Unreal 3目標是當前的，漂亮的圖形效果，更多的平台支援，是最重要的。

這些因素代表了Unreal 3的成功，一些其他的商業引擎，比如GameBro也很注重編輯器，而不是更優秀代碼品質。與其提供良好的結構，不如實現更多的效果。他們也都在各自的定位上獲得了相應的成功。

三、Ogre3D圖形引擎 = 開源模式

Ogre3D圖形引擎（http://ogre3d.cn）是開源界最出名的圖形引擎（沒有之一），包括國內的《天龍八區》、《成吉思汗》等，以及國外的《火炬之光》商業作品都是使用這款圖形引擎作為開發基礎。和Ogre3D同期的開源遊戲引擎，包括IrrLight等，都不如Ogre3D這般成功。

Ogre3D最重要的是從設計之初就目標開源社區，而不是商業或者技術。

Ogre3D 好的結構帶來更多的功能，而反之則不能。 開源社區需要好的結構讓更多的人來參與，而不需要商業引擎的工期，所以有充足的時間發展（十年甚至更多），而不爭朝夕。

Ogre3D 採用外掛程式化結構，這樣做的好處是讓一些社區開發人員，不用瞭解和改變整個引擎，就能擴充其功能，同樣開源的Quake3就很難達到這一點。

Ogre3D 只做圖形引擎，不做其他部分。

這樣做首先是利用了開源社區其他的成果，比如OIS或者CEGUI等良好的開源產品。更重要一點是因為不涉任何遊戲邏輯部分，核心模組只有5M左右大小，功能性引擎之間可以組合使用，這樣做可以讓Ogre3D適應不同領域，不僅是遊戲可以使用，在各種模擬領域都可以大展拳腳。同時期的IrrLight反而因為提供太多遊戲相關的東西，雖然學期曲線較緩，但是應用領域反而被閑置了。

Ogre3D在技術細節上 實現了情境圖中節點和內容分離，情境管理器因此可以作為外掛程式使用，這是Ogre3D設計的初衷。

Ogre3D 因為運用了大量軟體工程知識，導致在電腦運算比較差的環境下和其他引擎效率有一些差距。但因為開源引擎的持久性，隨著硬體效能的提高，十年後的今天，這些問題已經不再存在。

Ogre3D 和其他開源產品一樣，對開發人員要求較高（和一些商業領域的產品比較而言），不過Ogre3D也因此吸引了眾多開源開發人員（駭客）的參與。

基於以上幾點，Ogre3D在開源界得到了前所未有的成功，這種引擎開發模式，在商業領域反而不能成功。

四、Orz遊戲開發架構 = 分布模式

Orz遊戲開發架構(http://bbs.ogre3d.cn)是國內Ogre3D社區開發的遊戲架構，他利用了Ogre3D拒絕開發圖形之外代碼的基礎。提供了一系列開發工具以及對各種功能型引擎的粘合。不得不說Orz在遊戲引擎中採用了一種極端取巧的辦法。他把底層功能性引擎的開發交給了其他開源界的產品，專註於邏輯和介面的實現。相對於其他部分而言，這部分的代碼很少會受到硬體升級的影響。所以可以用較少的精力，不斷最佳化已有的代碼。但Ogre3D社區內也同時存在諸多開發架構，包括比較出名的yake和Goof等。Orz憑什麼能在這些架構中脫穎而出呢？

傳統上軟體開發的組織圖的基本問題是布洛克法則：“在延期的項目添加程式員只會延期更久”。普遍來講，布洛克法則認為，隨著開發人員數目的增加，項目的複雜程度和通訊成本按平方增加，而業績僅以直線增加。在上面圖中左面提供了一個傳統開發合作模式的，在這個結構中，因為每個程式員必須瞭解其他人員開發的模組介面，導致問題隨開發人員之間通訊路徑的數目增加，而後者與開發人員數目是平方關係（更準確地說，遵從公式N*(N – 1)/2，這裡N是開發人員的數目）。依照開源軟體的經驗，如果你有一個足夠大的項目，需要足夠多的人合作，你唯一的辦法是盡量降低程式員之間的依賴性。

Orz提出一個理想的分布式開發模型。在這個模型中，我們定義了一個公用的知識庫，裡面定義了互動的規則（訊息等資訊），所有的程式員按照這裡提供的約定完成自己的代碼，完全沒有和其他程式員的直接互動。在這種情況下，增加程式員的數量並不會導致過度增加開發人員之間通訊的成本。

在一些需要確定性結果的程式中，比如科學計算程式，很難達到理想的分布式開發模型，這是因為程式員之間要緊密的配合才能得到一個肯定的結果。然而對於遊戲程式而言，它的目的是帶來娛樂性和未知現實的類比，就如同生活一樣，你根本不需要（也不可能）知道別人想了什麼和做了什麼。只要大家遵守相同的規則，那麼就是一個不錯的體系，甚至越不可預測的結果給人帶來的驚喜和愉悅感越大。而這正是我們分布式開發所具有的，比如你寫了一隻狗，他寫了一隻貓，我們按照寵物的知識來通訊，你根本不用確定它們是成為朋友還是進行戰爭。就算加入一個寵物豬進來，我們也能正確的和它溝通——只要他遵守規矩。

Orz的目的就是基於這種分布式開發模型而設計，這和它的夢想相一致。頂尖的駭客定義遊戲規則，大家來遵守，成千上萬的程式員和他們的代碼來組成一個真正的虛擬世界。

Orz通過一系列工具和手段來接近這個目的，基於外掛程式來組合程式員們的代碼，提供訊息系統和ID管理器來確定公用知識庫。

Orz架構是一個可以完成商業產品的遊戲開發架構，但卻走的更遠。它在保證足夠運行效率的前提下，儘可能的增加結構的離散性質。所有的遊戲內容都可以被定義成不同種類的實體，這些實體可以通過外掛程式系統在運行期動態載入，它們通過“及其強大”的訊息系統相互溝通協作。任何一個開發遊戲實體的程式員，都不需要瞭解其他實體的邏輯。只要他們共同遵守一個訊息體系，就可以在這個基礎上進行協作。

但不得不說，這是一個沒有經過證實的理想而已。是否能達到這個目標還讓我們拭目以待。

綜上所述，所有遊戲引擎都需要放置在具體的商業環境中來評價其是否成功。你可以說Quake3寫得太僵化，Unreal代碼難看，Ogre3D運行速度不快，Orz只是一個東拼西湊的爛番茄。但是他們這些問題都是對他們所在領域的取捨。我認為，就如同人一樣，如果排除環境而言，世界上並不存在絕對的完美。引擎也是如此，他們都是希望在各自的環境和條件下盡量完美。如果我們對這些客觀的即時視而不見，那麼對引擎的評價也是不公正的。

虛幻引擎

雷神之錘III

Ogre3D圖形引擎

Orz遊戲開發架構