遊戲引擎、3D引擎、物理引擎以及其他引擎的由來

20多年前,大部分電腦遊戲都還是以文本為基礎的,少數則是以低分辨率的圖像及各種很聒噪的音效構成的.因此,在這一時期,為遊戲編寫代碼與著色可以說是一件非常簡單的工作,只需要將圖像填充到最初的位置上就行了.於是乎,用不了幾個程序員,便能在幾週,甚至幾天的時間內,在他們的車庫或是閣樓裡做出遊戲來.

但是隨著電腦技術的進步,玩家的胃口也越來越高.現在的遊戲已是非3D加速畫面不用,非數字式環繞音效不支持,為了使遊戲角色在充滿細節的三維世界中的移動更加真實,遊戲代碼的編寫成了一件需要耗費大量時間,耗費大量金錢的事情.可以說,這一進程(編寫代碼)的好壞,甚至在遊戲公司開始創作最終的內容之前,就已經決定了遊戲的最終品質

遊戲引擎

今天,很多遊戲公司都心裡明白,僅憑自身的財力,根本不足以平地起高樓——開發從頭到腳都完全嶄新的遊戲.於是他們決定從其它公司獲取那些在屏幕後面驅動遊戲運行的程序代碼,也就是俗稱的"遊戲引擎".

由Rogue Entertainment根據著名童話故事Alice in Wonderland(愛麗絲夢遊仙境)所改編的第三人稱射擊遊戲American McGee's Alice,是其中一個典型的代表.其設計師American McGee對此解釋說:"要想白手起家,創建一套功能強大的3D遊戲引擎,實在是超出我們力所能及範圍之內的不可完成之任務,因此我們唯一的選擇就是尋找一套市面上現存的,具備強大功能及適應性的引擎."

許多開發者都有著類似的處境,他們無力獨自開發一套全新的遊戲引擎,大部分是因為沒錢,沒時間,甚或只是因為他們沒有足夠的程序師,以完成這項日漸艱苦的工作——畢竟如今遊戲市場上可供選擇的遊戲引擎並不在少數,縱使你有幸得以開發出一套新的引擎,也不足以保證能從眾多同類者中脫穎而出!

對此,Legend Entertainment的Glen Dahlgren也是深有感觸,他評論說:"若僅僅只靠自己的技術力量開發遊戲引擎,你就要冒遠遠落後於技術潮流的巨大風險,因而很可能當你還在使用第一代引擎的時候,市面上第二代,第三代的引擎卻早已出現了,那麼你怎麼可能競爭得過他們呢?"

最常見的解決辦法便是去尋求某些公司為自己提供已有的引擎,當然這些引擎還要能夠根據自己的需要進行改良與延伸.


Unreal引擎


當前最主流的3D遊戲引擎之一便是Unreal的引擎,它是由Tim Sweeney及其開發小組Epic Games所提供的.該引擎不僅為Epic自己的遊戲,比如Unreal與Unreal Tournament提供了強勁的動力,它還被眾多其它開發者所選用.

Ion Storm奧斯汀部的Warren Spector便是其中之一,他的RPG大作Deus Ex(殺出重圍)正是採用的這部引擎.Spector在談到他之所以選擇這款引擎時說道:"當我們還處於前期製作階段時,便發現Unreal可以說是性價比最高的引擎."

"他為遊戲設計師們準備了極為強大的開發工具組件,並且似乎具有相當簡便的擴展性.當我們決定無論我們簽下哪一款引擎,我們都會加入許多新要素時(當然我們也不希望完全從頭開始),這款引擎注定必須擁有輕而易舉的修改性."

"最終,我們為其加入了一個交談系統,大量的二維界面畫面,新型的武器與物品,極度增強的AI,以及一個非常貼近真實效果的實時嘴型同步系統.當然,不管有多少新要素的加入,提供了一個穩定基礎的Unreal引擎是必不可少的前提."


Quake引擎


能與Unreal引擎比肩的主要競爭者毫無疑問是Quake 3.其擁有者id Software也許是這個世界上對引擎授權行當最不陌生的公司了.根據其前設計師John Romero的說法,id授權引擎的歷史最早可追溯到1991年的Commander Keen系列.

到90年代中期,以其大獲成功的共享遊戲軟件Wolfenstein 3D(德軍總部3D)為基礎,誕生了Apogee的Blake Stone與Raven的Shadow Caster.自那以後,他們不僅使用自己的引擎開發本部遊戲,還將其授權給其它一些公司.其中,Doom催生了Heretic與Hexen, Quake催生了Hexen II與Half-Life, Quake II引擎則被Kingpin,Heretic II(異教徒2), Soldier of Fortune(命運戰士) , Sin(原罪)以及Daikatana(大刀)等等一長串游戲所引用.

曾開發過Soldier of Fortune, Heretic II和Voyager:Elite Force的Jake Simpson(Raven)對於id的技術一點也不陌生,他形容他們的最新引擎(Quake III)"簡直是酷斃了!"

"Quake III中強大的功能節省了我們不少的時間,它實在是難以置信—尤其是其陰影系統就完全值得我們購買."

"當然,這部引擎也缺少我們過去所熟悉的某​​些要素,比如游戲存檔,以及Quake II中最基本的要素:單人遊戲模式.但是我們會花費一定資源對其進行擴展的,所以沒什麼問題."


並非完美


當然,使用任何現成的遊戲引擎都會遇到許多問題,Quake III自然也不例外.Jake對此評述說:"(Q III引擎)在描繪廣闊戶外場景上的不足,是我們不得不面對的一大難題.而Unreal Tournament與Tribes在這方面就做得很不錯.此外,Quake III引擎還存在一些並不容易被察覺的問題,直到你試圖嘗試一些特別設計的時候,這些問題才會顯現出來. "

"Carmack是一個十足的實用主義者.他只會使他的引擎能盡量滿足他自己的要求就行,而很少顧及別人的需求,這就使我們這些購買引擎的人不得不進行大量的鑽研與特性修改."

這種看法得到了3D Realms一位程序員的附應,他就是負責Duke Nukem Forever(永遠的毀滅公爵)開發的Scott Miller,雖然花大價錢購得了Quake II引擎,但經過一番努力後,他卻痛苦地發現:如果非要說Quake II適合某一款遊戲的開發的話,那麼這款遊戲就只有是Quake 2.

最後3D Realms不得不於1998年作出了一個令世人震驚的決定,放棄Quake II引擎而轉投Unreal引擎來重新開發DNF——哪怕他們的這部新作才在幾週前的E3展上給新聞界留下了深刻的印象,還是哪怕他們已經為Quake II引擎的使用權向id支付了不菲的代價.

也許,Quake II引擎的缺陷並非3D Realms作出如此決斷的最主要因素,但Scott Miller所給出的官方解釋就是如此:"理由很簡單,Quake引擎對於戶外場景的處理並非盡善盡美,而我們則必須要用到這一功效來製作​​DNF中的眾多關卡."

當然,也並不是每一位設計師都會被Quake引擎的缺陷所限制,主持開發<愛麗絲夢遊仙境>的前id老兵American McGee就是其中之一,他告訴我們說:"就Alice與Quake III引擎而言,我們還真的沒有發現它們有什麼重大設計缺陷."

"因此,我實在找不出我們選用Quake III引擎會有什麼錯,也許是因為我們對其研究得更加深入吧……!"


誘人的引擎授權


雖然引擎授權對id Software來說只是一個小小的副業,但正是這個副業卻為id帶來了不菲的利潤——每授權Quake III引擎開發一部遊戲,大概可收入50萬美元左右,這還不包括版稅!


如今,Quake III引擎已經為數部遊戲所採用,他們有:"American McGee's Alice"(愛麗絲夢遊仙境), "Heavy Metal:FAKK2"(重金屬2),"Return To Castle Wolfenstein"(重返德軍總部) ,"The World Is Not Enough"(末日危機)與"Voyager:Elite Force"(星際迷航記:精英力量).再考慮到id並沒有花費多少資源在推銷(或是支持)他們的引擎上面,那麼幾乎可以肯定:他們從引擎授權中獲得的利潤要比光靠販賣"Quake 3 Arena"所獲得的利潤還要多.

出於這樣的誘惑,Monolith也深信引擎授權是一項絕對有利可圖的生意,於是他們最近也成立了一個全新的公司,名稱就是以他們公司的代表引擎LithTech命名的,而這家公司的業務便是從事設計,開發,授權他們的LithTech引擎,並提供相應的技術支持.

LithTech引擎的買家還不少,他們之所以選擇它不光是因為它的強大性能,還因為Monolith完善的售後支持.對此,Third Law公司的David Namaksy(開發作品為KISS : Psycho Circus<變態馬戲團：噩夢男孩>)的話頗具代表性:"Monolith承諾將為購買者提供技術支持與不斷的升級服務,並一直持續到我們的遊戲發售後,這一點對於我們將決定購買哪款引擎是非常重要的.而Monolith的承諾就像是我們擁有一個自己的引擎專門小組一樣."

持這一觀點的還有大名鼎鼎的John Romero,他新成立的公司同時購買了Quake與Unreal引擎的授權,這便使他對這兩大引擎的售後支持力度有了一個直觀的比較,他首先指出"這主要還是得依靠引擎提供商".

"如果從id購買引擎,基本上得不到任何支持與幫助,也沒有任何相關資料.這並不是件好事.但如果你從Monolith,或是從Epic購買引擎,他們則會給予你相當相當大的支持."


問題


購買授權引擎還會引發其它一些問題.Raven就遭遇了受制於引擎更新進度的麻煩,本來其Voyager : Elite Force的開發工作早在Quake 3 Arena 上市前就已展開,但id這部作品的開發進程一拖再拖,給Raven造成了極大的不便.

"試圖去擊打一個移動目標一直都很非常困難,"Jake Simpson訴苦到."我們很久之前就已期盼著這部引擎能夠快點完成,不然這顯然會對我們自己的上市日程造成極大衝擊——尤其是在我們與id還有著特別協議的情況下,即我們作品的發售日期不能與id的QuakeIII挨得太近."

"我們遊戲的開發進度只能與Quake III引擎的開發進度大致相當,因此當我們有時獲得了更新源代碼後,只能將其中變化的部分進行簡單的剪切粘貼,而沒有時間進行深入細緻的改良."

不過,就算開發者能夠擁有一套現存的完善引擎,其大部分功效最後也不得不被扔棄——如果你不僅僅只是希望製作一部看得過眼的資料片的話.

對此,Scott Miller評述到:"理論上說,購買了現有引擎使用權的開發商確實能夠節約大把的開發時間."

"但事實上,如果他們真心希望開發一部3A級別的遊戲,他們就需要對所獲得的引擎進行根本上的升級與改進.Half-Life就是一個典型的例子,Duke Nukem Forever也是一樣.到最後,引擎大部分地方其實都是我們自己的成果."

"當然基本上,所有的Unreal Tournament基礎核心代碼還是會得以保留,"Scott進一步解釋到."我們自己新開發的代碼則主要用於增添引擎的其它特效."

或者用John Romero最近在達拉斯Razer-CPL大賽上所說的那樣:"有時我想,要是能只購買引擎的核心部分就好了,那樣我就能隨心所欲增加任何自己想要的東西."


自創


既然你打算將引擎的大部分代碼進行重寫,有人也許會想:"那何不干脆從頭乾起更好?"

英國開發商Rebellion的創始人之一Jason Kingsley便是持有這種想法的開發人之一,而它的兩部作品:Aliens vs Predator(異形vs掠奪者)及組隊型動作冒險遊戲Gunlok(鋼鐵戰場),也正是用自家的引擎開發的.

Jason告訴我們說:"用我們自己的引擎,使我們能夠自由盡情的發揮,這樣就不必妥協於他購的引擎——或準確的說是二手引擎."

Rebel Act工作室的Xavier Carrillo也同意Jason(作品Blade<黑暗之刃>)的看法,他告訴我們說從頭創建屬於自己的遊戲引擎比外購引擎"更具有靈活性",它將使你自己對整個遊戲的開發"擁有完全的掌控權,並能依據自己的開發需求對引擎進行設計規範."

Starbreeze公司一位正在忙於在線第一人稱射擊遊戲Enclave(困土)開發的關卡設計師:Jens Matthies也認為使用自己開發的引擎使開發者們有了"對遊戲設計過程中的所有方面全面施以影響的權力"

他還說:"如果我想到了一個新點子,我便會把它告訴Magnus[Starbreeze的主程序員],如果他贊成的話,他就會將其加入遊戲中.這對我這樣的關卡設計者來說實在太有利了,因為這種做法有可能使一切都能變得盡善盡美.這實在是太令人高興了."


自創的弊端


很顯然,開發全新引擎也有很大的弊端.Xavier就告訴我們從頭設計獨立引擎:"無疑需要更多的程序員,而所有其它部門的工作進程都得要視引擎的進化程度而定."

而Jens也直言不諱地認為這確實是一個大問題.他解釋到用一個尚在開發中的引擎製作遊戲,意味著"永遠都會存在著你很想加入,但事實上卻無法加入的特效," ,甚至"要到很晚才能進行關卡設計."

雖說若真的有必要從頭設計一部引擎,開發者還可以根據遊戲的需要對其進行量身定制的話.那麼如果遊戲引擎的設計實在變動得太過頻繁，那將意味著大量的早期工作將被浪擲、返工、或至少是在工程後期需要重新編譯.

這篇文章應該有 8 年左右的歷史了.

遊戲引擎，3D引擎，物理引擎以及其他

一，遊戲引擎

在遊戲的啟蒙時代，其實是沒有遊戲引擎的，那時候的遊戲足夠簡單，類似於pacman之類的遊戲用頭髮想想也明白它根本用不到引擎這種概念。

隨著遊戲的複雜，對遊戲項目的複雜性和開發週期提出了更高的要求。首先是代碼的重用，為每個遊戲完全重寫一套代碼實在是不划算，而且伴隨代碼的重寫，測試的壓力也很大。其次是開發週期的壓力，商業競爭要求遊戲廠商要足夠快地推出更複雜更好玩的遊戲，把遊戲的內容硬編碼進代碼很快成為了一種很愚蠢的做法，因為這樣的話，簡單的修改就會牽扯很多地方。

於是，遊戲引擎的概念被提出，從遊戲架構上來說，3d的fps和2d rpg/slg可能是最早引入引擎概念的。而隨著技術的進步，引擎也越來越成熟。

那麼，遊戲引擎究竟做了什麼？

1 封裝了硬件平台和操作系統的功能調用。
大多數的通用引擎封裝了硬件平台和操作系統的功能調用，用統一的接口暴露給程序員，這樣便做到了跨平台。舉個例子，絕大多數的pc遊戲引擎都同時支持DirectX和openGL，為Windows編譯好的遊戲可以用DirectX，為Linux編譯的版本則顯然會自動使用openGL，而這些在某種層次上可以做到對程序員透明（當然，3D部分是最麻煩的，稍後說明）。

2 提供基本的功能服務。
遊戲引擎會提供一些基本的功能服務。
比如：
A 對文件系統的抽象，研發的時候直接讀取硬盤上的遊戲資源，發行版本自動改為讀取打包文件中的資源。
B 提供統一的對像管理，大部分是樹裝的層次結構。
C 內存管理，異常處理
D 遊戲腳本支持，把遊戲引擎的功能以腳本函數的方式暴露給腳本，這樣可以在腳本中編寫遊戲邏輯，操作遊戲引擎，大大方便了修改遊戲，舉個例子，WOW的UI部分就暴露了腳本接口，玩家可以自己用LUA編寫UI插件。

3 提供一個易擴充的框架結構
很多遊戲引擎是易擴充的，比如更換渲染模塊，添加物理引擎等，這樣可方便的針對項目量體裁衣。比如我需要DirectX不需要物理引擎，都可以自由定制。

4 提供研髮用的編輯器
很難想像沒有編輯器如何做遊戲。玩家熟悉的編輯器舉幾個例子：星際爭霸，魔獸爭霸3。

二，3D引擎

隨著技術的進步，現在的遊戲基本都使用3D技術來渲染畫面了，很多玩家根本就想不到即便是那些看起來是2D的遊戲，其實也是用3D模式渲染的。舉個例子，PS2的GS硬件上對純2D其實基本可以說沒有支持，PS2的2D遊戲，基本上都是用正交投影的3D模式渲染的，不論是SSF3.3還是GGXX都是這樣，平面的人物也是用三角形構成的。用3D有很多優勢，比如3D硬件速度快，支持alpha十分簡單等等。

如果大家學過D3D或者openGL，就會發現往屏幕上畫一個三角形，貼圖然後讓它轉起來，其實很簡單，關鍵的代碼不超過50行，那為什麼還要搞出3D引擎這種聽起來很華麗的詞彙呢？

工程學上，蓋一個平房和造帝國大廈，其規模和復雜性完全不在一個數量級。同理，往屏幕上畫一個三角形，貼圖然後讓它轉起來和大家玩到的FF12也完全不是一個檔次。現實生活中的遊戲太複雜了，以至於必須要3D引擎來完成很多工作。

1 場景。
遊戲引擎需要管理場景，也就是玩家所在的某個區域，不管是戰場還是道具屋。根據需要剔除不需要顯示的部分（對於FPS來說玩家身後顯然是永遠也看不到的）。

2 對象
遊戲引擎需要管理場景中的對象，比如一個木桶，一棵樹，在需要的時候向硬件提交對它們的渲染。

3 動畫
這裡的動畫指的是3D物體的動作。遊戲中有很多需要動畫的地方，例如草的擺動，開門，乃至於玩家控制人物的走動。很難想像手工寫代碼去計算構成玩家角色的每一個三角形的坐標變換。常見的方法都是在3D創作軟件中設置好動作然後導出，動作用專用的腳本來描述，3D引擎會對它進行解釋。

4 渲染
我這裡只就現在的先進的渲染方法來說。現在的pc和console硬件都具備了可編程的顯示硬件（不論是pc還是ps3，xb,xb360），叫做shader，shader分為兩種：vertex shader和pixel shader，更先進的硬件還會提供一種叫做geometric shader 的可編程硬件。 shader是在顯卡上的，它需要對應的代碼來運行，可以用shader的彙編或者專用的c語言來編寫shader（我有個朋友就喜歡用彙編直接寫shader - -b）。 shader使用起來沒有想像的那麼難，買本nv的CG教程，至多三天就能大概知道怎麼用了。

渲染每一個模型的時候，乃至於渲染模型的不同部分，動作的不同階段，3D引擎會自動選用適當的shader來執行渲染，手工完成這件事情幾乎是不可能的。


三，物理引擎

越來越多的玩家對遊戲的感官真實性提出了要求，他們追求更真實，於是仿真現實世界的物理引擎被提出來，物理引擎把遊戲中的物體的行為進行修飾，讓他們表現得看起來更真實。舉個簡單的物理引擎的例子：直到CS 1.6，遊戲玩起來還是那個樣子，然而CS:Source則不同，儘管只用了簡單的物理效果，我們已經可以用槍擊倒油桶之類的物體了。

那麼物理引擎究竟是怎麼工作的呢？依我看來物理引擎其實有兩個任務：物體之間的物理交互，物體自身的物理交互。

1 物體之間的物理交互。
比如剛才說的子彈擊中油桶，油桶被擊倒。這個比較簡單，CS中子彈是沒有體積概念的，這種碰撞計算很簡單。而其他的類型就不那麼簡單了，比如有立方體的碰撞，球體碰撞，乃至於曲面的互碰撞計算。不要忘了，這可是3D坐標系中的碰撞計算，回想一下你的空間解析幾何知識吧，這種計算對資源的消耗有多麼大。

2 物體自身的物理交互
如果我擊中了一塊玻璃，玻璃碎掉或者掃射旗子，旗子上被打出很多彈孔，這也需要物理引擎來幫忙，當然並不是必須的。但是玻璃的碎裂如果要求很真實，用物理引擎計算碰撞的結果就很必要了，碰撞是僅導致玻璃裂開還是粉碎，取決於碰撞的強度。

題外話：遊戲中的矩形玻璃最簡單的實現就是倆三角形一層材質，但是，計算機很笨，玻璃碎掉它不會自動增加多變形來表達每一個碎片。即便是物理引擎也不會做這件事情。現在都是需要程序員做額外的工作，未來DX10會提供geometric shader，做這個工作就會大大簡化。

四，其他

剛才說了很多理論和原理上的東西，那麼遊戲引擎，3D引擎，物理引擎是怎麼攢到一起的呢？前面說了，遊戲引擎是個框架，3D引擎，物理引擎被裝在裡面。更進一步說，其實物理引擎是受制於3D部分的。物理引擎要計算的物體數據是3D引擎提供的。

下面是一個簡化的frame渲染流程：

調整3D場景狀態（CPU）
處理輸入（CPU）
處理音效（SPU）
處理物理效果（CPU/SPE/PPU/GPU）
渲染3D（GPU）
渲染2D（GPU）

這個流程可以說基本上所有的遊戲都會有，而且我也把主要負責的模塊寫在了後面。從目前的技術來看，程序中能充分發揮多核，也就是多處理器優勢的部分，必定是能夠多線程操作的部分，就遊戲而言，網絡通信和處理音效是最容易多線程化的，因為它們本質上就必定是多線程實現。渲染基本上是單向的，CPU向GPU提出需求，除非CPU需要GPU的運算結果，這種情況不是很多。

好，現在剩下處理物理效果（CPU/SPE/PPU/GPU），對於沒有專用物理硬件的環境來說，目前常見的就是用CPU來算這種對浮點要求極高的任務，當然，PS3可以藉助CPU中的SPE。未來可能會有用GPU來協助的實現。當然最好的就是用專用硬件，傳說中的xx物理加速卡。這裡有個關鍵的問題，這種運算很難多線程，換句話說，渲染之前，必須等待物理計算完成，如果我們採用的是CPU來計算，很可能計算速度不夠，速度不夠的結果我就不用再多描述了，玩過遊戲的人都知道這意味著什麼。

好，基本上我要說的技術上的也就這麼多，現在回頭來看看某xxx老師的言論：“havok是負責物理，和丟幀沒什麼關係。”，希望大家可以笑一笑了。

via 滴水藏海