AI:從遊戲引擎--到AI

原文連接：http://blog.csdn.net/left_la/article/details/6358911#t9

　這是我在Gameres上看到的一篇文章，文章很長，全文分爲11個部分，看後感受寫的很是好，對我啓迪很大，特此推薦。做者是國外的一名老程序員，相信對於剛接觸或者想要接觸遊戲引擎的同窗，這篇文章可以帶領大家步入遊戲引擎的世界！下面就開始吧：

 

原文做者：Jake Simpson
譯者： 向海
Email：GameWorldChina@myway.com

第1部分:遊戲引擎介紹， 渲染和構造3D世界

介紹
　　自Doom遊戲時代以來咱們已經走了很遠。 DOOM不僅是一款偉大的遊戲，它同時也開創了一種新的遊戲編程模式:遊戲 "引擎"。這種模塊化，可伸縮和擴展的設計觀念可讓遊戲玩家和程序設計者深刻到遊戲核心，用新的模型，場景和聲音創造新的遊戲，或向已有的遊戲素材中添加新的東西。大量的新遊戲根據已經存在的遊戲引擎開發出來，而大多數都以ID公司的Quake引擎爲基礎，這些遊戲包括Counter  Strike， Team Fortress， Tac Ops， Strike Force，以及Quake Soccer。Tac Ops和Strike Force 都使用了Unreal Tournament引擎。事實上， "遊戲引擎"已經成爲遊戲玩家之間交流的標準用語，可是究竟引擎止於何處，而遊戲又從哪裏開始呢?像素的渲染，聲音的播放，怪物的思考以及遊戲事件的觸發，遊戲中全部這一切的幕後又是什麼呢？若是你曾經思考過這些問題， 並且想要知道更多驅動遊戲進行的東西，那麼這篇文章正好能夠告訴你這些。本文分多個部分深刻剖析了遊戲引擎的內核， 特別是Quake引擎，由於我最近工做的公司Raven Software已經在Quake引擎的基礎上開發出了多款遊戲，其中包括著名的Soldier of Fortune 。

開始
　　讓咱們首先來看看一個遊戲引擎和遊戲自己之間的主要區別。 許多人們會混淆遊戲引擎和整個遊戲。這有點像把一個汽車發動機和整個汽車混淆起來同樣 。 你可以從汽車裏面取出發動機， 建造另一個外殼，再使用發動機一次。 遊戲也像那。 遊戲引擎被定義爲全部的非遊戲特有的技術。 遊戲部份是被稱爲 '資產'的全部內容 (模型，動畫，聲音，人工智能和物理學)和爲了使遊戲運行或者控制如何運行而特別須要的程序代碼，好比說AI--人工智能。

　　對於曾經看過 Quake 遊戲結構的人來講， 遊戲引擎就是 Quake。exe，而遊戲部分則是 QAGame。dll和 CGame。dll。 若是你不知道這是什麼意思， 也沒有什麼關係；在有人向我解釋它之前，我也不知道是什麼意思。 可是你將會徹底明白它的意思。 這篇遊戲引擎指導分爲十一個部份。 是的， 從數量上來講，總共是十一個部份!每一個部分大概3000字左右。如今就從第一部分開始咱們的探索吧，深刻咱們所玩遊戲的內核，在這裏咱們將瞭解一些基本的東西，爲後面的章節做鋪墊。。。

渲染器
　　讓咱們從渲染器來開始遊戲引擎設計的探討吧， 咱們將從遊戲開發者(本文做者的背景)的角度來探討這些問題。事實上，在本文的各個段落，咱們將經常從遊戲開發者的角度探討，也讓您像咱們同樣思考問題!

　　什麼是渲染器，爲何它又這麼重要呢？好吧，若是沒有它，你將什麼也看不到。它讓遊戲場景可視化，讓玩家/觀衆能夠看見場景，從而讓玩家可以根據屏幕上所看到的東西做出適當的決斷。儘管咱們下面的探討可能讓新手感到有些恐懼，先別去理會它。 渲染器作些什麼？爲何它是必須的？咱們將會解釋這些重要問題。

　　當構造一個遊戲引擎的時候， 你一般想作的第一件事情就是建造渲染器。由於若是看不見任何東西 – 那麼你又如何知道你的程序代碼在工做呢?超過 50% 的 CPU處理時間花費在渲染器上面； 一般也是在這個部分，遊戲開發者將會受到最苛刻的評判。若是咱們在這個部分表現不好，事情將會變得很是糟糕， 咱們的程序技術，咱們的遊戲和咱們的公司將在 10天以內變成業界的笑話。 它也是咱們最依賴於外部廠商和力量的地方，在這裏他們將處理最大限度的潛在操做目標。如此說來， 建造一個渲染器確實不象聽起來那麼吸引人（事實如此），但若是沒有一個好的渲染器， 遊戲或許永遠不會躋身於排行榜前10名。

　　現在，在屏幕上生成像素，涉及到 3D加速卡， API ，三維空間數學，對 3D 硬件如何工做的理解等等。對於主機（遊戲機）遊戲來講，也須要相同類型的知識，可是至少對於主機，你沒必要去嘗試擊中一個移動中的目標。 由於一臺主機的硬件配置是固定的 "時間快照"，和PC（我的計算機）不一樣， 在一臺主機的生命期中，它的硬件配置不會改變。

　　在通常意義上，渲染器的工做就是要創造出遊戲的視覺閃光點，實際上達到這個目標須要大量的技巧。3D圖形本質上是用最少的努力創造出最大效果的一門藝術，由於額外的 3D 處理在處理器時間和和內存帶寬方面都是極爲昂貴的。它也是一種預算， 要弄清楚你想在什麼地方花費處理器時間，而你寧願在什麼地方節省一些從而達到最好的總體效果。接下來咱們將會介紹一些這方面的工具，以及怎樣更好的用它們讓遊戲引擎工做。

建造3D世界
　　最近，當我和一位從事計算機圖形方面工做長達數年之久的人會談時，她向我吐露道， 當她第一次看到實時操縱計算機 3D圖象時， 她不知道這是怎麼實現的， 也不知道計算機如何可以存儲 3D圖象。 今天這對於在大街上的普通人來講或許是真實的，即便他們時常玩 PC遊戲， 遊戲機遊戲， 或街機遊戲。

　　下面咱們將從遊戲設計者的角度討論創造 3D世界的一些細節，你也應該看一看 Dave Salvator 所寫的「3D管線導論「，以便對3D圖象生成的主要過程有一個總體的瞭解。

　　3D 物體（對象）被儲存成 3D世界中的一系列點(被稱爲頂點)，彼此之間有相互關係，因此計算機知道如何在世界中的這些點之間畫線或者是填充表面。 一個立方體由8個點組成，每一個角一個點。立方體有6個表面，分別表明它的每個面。 這就是 3D對象儲存的基礎。 對於一些比較複雜的 3D物體， 好比說一個 Quake 的關卡，將有數以千計(有時數以十萬計)的頂點，和數以千計的多邊形表面。

　　參見上圖的線框表示（注：原文在這裏有一幅圖）。 本質上與上面的立方體例子相似， 它僅僅是由許許多多的小多邊形組成的一些複雜場景。模型和世界如何儲存是渲染器的一部份功能，而不屬於應用程序/遊戲部份。 遊戲邏輯不須要知道對象在內存中如何表示， 也不須要知道渲染器將怎樣把他們顯示出來。遊戲只是須要知道渲染器將使用正確的視野去表示對象， 並將在正確的動畫幀中把正確的模型顯示出來。

　　在一個好的引擎中，渲染器應該是能夠徹底被一個新的渲染器替換掉，而且不須要去改動遊戲的一行代碼。許多跨平臺引擎， 並且許多自行開發的遊戲機引擎就是這樣的，如 Unreal引擎， --舉例來講， 這個遊戲 GameCube 版本的渲染器就能夠被你任意的替換掉。

　　讓咱們再看看內部的表示方法—除了使用座標系統，還有其餘方法能夠在計算機內存裏表示空間的點。在數學上，你能夠使用一個方程式來描述直線或曲線，並獲得多邊形， 而幾乎全部的 3D顯示卡都使用多邊形來做爲它們的最終渲染圖元。 一個圖元就是你在任何顯示卡上面所能使用的最低級的繪製（渲染）單位，幾乎全部的硬件都是使用三個頂點的多邊形(三角形)。新一代的 nVidia 和 ATI顯卡能夠容許你以數學方式渲染(被稱爲高次表面)，但由於這不是全部圖形卡的標準， 你還不能靠它做爲渲染策略。

　　從計算的角度來看，這一般有些昂貴，但它時常是新的實驗技術的基礎，例如，地表的渲染，或者對物件銳利的邊緣進行柔化。咱們將會在下面的曲面片小節中更進一步介紹這些高次表面。

剔除概觀
　　問題來了。 我如今有一個由幾十萬個頂點/多邊形描述的世界。我以第一人稱視角位於咱們這個 3D 世界的一邊。在視野中能夠看見世界的一些多邊形， 而另一些則不可見， 由於一些物體， 好比一面看得見的牆壁， 遮擋住了它們。即便是最好的遊戲編碼人員， 在目前的 3D顯卡上， 在一個視野中也不能處理 300，000個三角形且仍然維持 60fps (一個主要目標)。顯卡不能處理它， 所以咱們必須寫一些代碼，在把它們交給顯卡處理以前除去那些看不見的多邊形。這個過程被稱爲剔除。

　　有許多不一樣的剔除方法。 在深刻了解這些以前，讓咱們探討一下爲何圖形顯示卡不能處理超高數量的多邊形。我是說，最新的圖形卡每秒鐘不能處理幾百萬個多邊形嗎？它不該該可以處理嗎? 首先，你必須理解市場銷售宣稱的多邊形生成率和真實世界的多邊形生成率。 行銷上宣稱的多邊形生成率是圖形顯示卡理論上可以達到的多邊形生成率。

　　若是所有多邊形都在屏幕上， 相同的紋理，相同的尺寸大小，正在往顯示卡上傳送多邊形的應用程序除了傳送多邊形之外什麼也不作， 這時顯卡能處理多少多邊形數量，就是圖形芯片廠商呈現給你的數字。

　　然而，在真實的遊戲情形中，應用程序時常在後臺作着許多其餘的事情 --多邊形的 3D 變換， 光照計算， 拷貝較多的紋理到顯卡內存， 等等。不只紋理要送到顯示卡， 並且還有每一個多邊形的細節。一些比較新的顯卡容許你實際上在顯卡內存自己裏面儲存模型/世界幾何細節，但這多是昂貴的，將會耗光紋理正常能夠使用的空間，因此你最好能肯定每一幀都在使用這些模型的頂點， 不然你只是在浪費顯示卡上的存儲空間。 咱們就說到這裏了。 重要的是，在實際使用顯卡時，並沒必要然就能達到你在顯卡包裝盒上所看到的那些指標，若是你有一個比較慢速的CPU， 或沒有足夠的內存時，這種差別就尤其真實。

基本的剔除方法
　　最簡單的剔除方式就是把世界分紅區域， 每一個區域有一個其餘可見區域的列表。那樣， 你只須要顯示針對任何給定點的可見部分。 如何生成可見視野區域的列表是技巧所在。 再者， 有許多方法能夠用來生成可見區域列表，如 BSP 樹， 窺孔等等。

　　能夠確定，當談論 DOOM或 QUAKE 時，你已經聽到過使用 BSP這個術語了。 它表示二叉空間分割。

　　BSP 是一種將世界分紅小區域的的方法，經過組織世界的多邊形，容易肯定哪些區域是可見的而哪些是不可見的 –從而方便了那些不想作太多繪製工做的基於軟件的渲染器。它同時也以一種很是有效的方式讓你知道你位於世界中的什麼地方。

　　在基於窺孔的引擎 ( 最先由 3D Realms 已經取消的 Prey項目引入遊戲世界 )裏，每一個區域( 或房間) 都建造有本身的模型，經過每一個區域的門 ( 或窺孔 )可以看見另外的區段。渲染器把每一個區域做爲獨立的場景單獨繪製。 這就是它的大體原理。足以說這是任何一個渲染器的必需部份，並且很是重要。

　　儘管一些這樣的技術歸類在 "遮擋剔除"之下，可是他們所有都有一樣的目的:儘早消除沒必要要的工做。 對於一個FPS遊戲(第一人稱射擊遊戲)來講，視野中時常有許多三角形，並且遊戲玩家承擔視野的控制，丟棄或者剔除不可見的三角形就是絕對必要的了。 對空間模擬來講也是這樣的， 你能夠看見很遠很遠的地方 –剔除超過視覺範圍外面的東西就很是重要。 對於視野受到限制的遊戲來講 –好比 RTS (即時戰略類遊戲)--一般比較容易實現。一般渲染器的這個部份仍是由軟件來完成， 而不是由顯卡完成，由顯卡來作這部分工做只是一個時間問題。

基本的圖形管線流程
　　一個簡單的例子，從遊戲到多邊形繪製的圖形管線過程大體是這樣:
　　　　· 遊戲決定在遊戲中有哪些對象，它們的模型， 使用的紋理， 他們可能在什麼動畫幀，以及它們在遊戲世界裏的位置。遊戲也決定照相機的位置和方向。

　　　　· 遊戲把這些信息傳遞給渲染器。以模型爲例，渲染器首先要查看模型的大小 ，照相機的位置， 然後決定模型在屏幕上是否所有可見， 或者在觀察者 (照相機視野)的左邊，在觀察者的後面，或距離很遠而不可見。它甚至會使用一些世界測定方式來計算出模型是不是可見的。 (參見下面這條)

　　　　· 世界可視化系統決定照相機在世界中的位置，並根據照相機視野決定世界的哪些區域 /多邊形是可見的。有許多方法能夠完成這個任務， 包括把世界分割成許多區域的暴力方法，每一個區域直接爲"我能從區域 D看見區域 AB & C"， 到更精緻的 BSP(二叉空間分割)世界。全部經過這些剔除測試的多邊形被傳遞給多邊形渲染器進行繪製。

　　　　· 對於每個被傳遞給渲染器的多邊形，渲染器依照局部數學 ( 也就是模型動畫)和世界數學(相對於照相機的位置?)對多邊形進行變換，並檢查決定多邊形是否是背對相機 (也就是遠離照相機)。背面的多邊形被丟棄。非背面的多邊形由渲染器根據發現的附近燈光照亮。而後渲染器要看多邊形使用的紋理，而且肯定 API/圖形卡正在使用那種紋理做爲它的渲染基礎。 在這裏，多邊形被送到渲染 API，而後再送給顯卡。

　　很明顯這有些過度簡單化了，但你大概理解了。 下面的圖表摘自Dave Salvator's 3D 管線一文，能夠給你多一些具體細節:

　　3D 管線
　　- 高層的概觀
　　　[來源：GameRes.com]1.應用程序/ 場景
　　·場景/幾何數據庫遍歷
　　·對象的運動，觀察相機的運動和瞄準
　　·對象模型的動畫運動
　　·3D 世界內容的描述
　　·對象的可見性檢查，包括可能的遮擋剔除
　　·細節層次的選擇 (LOD)

　　2. 幾何
　　·變換 (旋轉，平移，縮放)
　　·從模型空間到世界空間的變換 (Direct3D)
　　·從世界空間到觀察空間變換
　　·觀察投影
　　·細節接受/拒絕 剔除
　　·背面剔除 (也能夠在後面的屏幕空間中作)
　　光照
　　·透視分割 -變換到裁剪空間
　　·裁剪
　　·變換到屏幕空間

　　3. 三角形生成
　　·背面剔除 (或者在光照計算以前的觀察空間中完成)
　　·斜率/角度計算
　　·掃瞄線變換

　　4. 渲染 /光柵化
　　·着色
　　·紋理
　　·霧
　　·Alpha 透明測試
　　·深度緩衝
　　·抗鋸齒 (可選擇的)
　　·顯示

　　一般你會把全部的多邊形放到一些列表內， 然後根據紋理對這個列表排序(這樣你只須要對顯卡傳送一次紋理，而不是每一個多邊形都傳送一次)， 等等。在過去，會把多邊形按照它們到相機的距離進行排序，首先繪製那些距離相機最遠的多邊形， 但如今因爲 Z緩衝的出現，這種方法就不是那麼重要了。 固然那些透明的多邊形要除外，它們要在全部的非半透明多邊形繪製以後纔可以繪製，這樣一來，全部在它們後面的多邊形就能正確地在場景中顯現出來。 固然，象那樣，實際上你必須得從後到前地繪製那些多邊形。但時常在任何給定的 FPS 遊戲場景中，一般沒有太多透明的多邊形。 它可能看起來像有，但實際上與那些不透明的多邊形相比，其比率是至關低的。

　　一旦應用程序將場景傳遞到 API， API就能利用硬件加速的變換和光照處理 (T&L)，這在現在的 3D 顯卡中是很日常的事情。這裏不討論涉及到的矩陣數學(參見Dave的 3D管線導論)，幾何變換容許 3D顯卡按照你的嘗試，根據相機在任什麼時候間的位置和方向，在世界的正確角度和位置繪製多邊形。

　　對於每一個點或頂點都有大量的計算， 包括裁剪運算，決定任何給定的多邊形其實是否可見，在屏幕上徹底不可見或部分可見。光照運算，計算紋理色彩明亮程度，這取決於世界的燈光從什麼角度如何投射到頂點上。 過去，處理器處理這些計算，但如今，當代圖形硬件就能爲你作這些事情，這意謂着你的處理器能夠去作其餘的事情了。很明顯這是件好事情 (tm) ，因爲不能期望市面上全部的 3D 顯卡板上都有T & L，因此不管如何你本身將必須寫全部的這些例程 (再一次從遊戲開發者角度來講)。你將在本文各處的不一樣段落看到 "好事情 ( tm)"這個詞彙。 我認爲，這些特徵爲使遊戲看起來更好做出了很是有用的貢獻。絕不使人吃驚，你也將會看見它的對立面；你猜到了，那就是「壞事情 (tm)」。我正在嘗試爭取這些詞彙的版權， 你要使用他們就得支付一筆小小的費用喲。

曲面片（高次表面）
　　除了三角形，曲面片的使用如今正變得更廣泛。 由於他們能用數學表達式來描述幾何 (一般涉及某種曲線的幾何形體) ，而不只僅只是列出大量的多邊形以及在遊戲世界中的位置，因此曲面片 ( 高次表面的另外一個名稱)很是好。 這樣，你實際上就可以動態地根據方程式來創建(和變形 )多邊形網格， 並決定你實際想要從曲面片上看到的多邊形數量。 所以，舉例來講，你能夠描述一個管道，而後在世界中就能夠有這種管道的許多樣例。 在一些房間中， 你已經顯示了 10，000個多邊形，你能夠說，"由於咱們已經顯示了大量的多邊形，並且任何更多的多邊形將會使幀速率降低，因此這個管道應該只有 100 個多邊形"。但在另一個房間中， 視野中只有 5，000個可見的多邊形，你能夠說，"由於咱們尚未達到預算能夠顯示的多邊形數量， 因此，如今這個管道能有 500個多邊形"。 很是美妙的東西 --但你必須首先知道全部這些，並創建網格，這不是無足輕重的。經過 AGP 傳送同一個對象的曲面方程確實要比傳送其大量頂點節省成本。 SOF2就使用了這個方法的一種變體來創建它的地表系統。

　　事實上如今的 ATI 顯卡具備 TruForm， 它能帶一個以三角形爲基礎的模型，並將該模型轉換爲基於高次表面的模型，使其平滑 —接着再用十倍三角形數量把模型轉換回基於大量三角形的模型 (被稱爲retesselation)。而後模型送往管線作進一步的處理。實際上 ATI 僅僅在 T & L引擎以前增長了一個階段來處理這個過程。這裏的缺點是，要控制哪些模型須要被平滑處理而哪些又不須要。你經常想要一些邊緣比較尖銳，好比鼻子，但它卻被不恰當的平滑過了。 這仍然是一種很好的技術，並且我能預見它在未來會被更多的應用。

　　這就是第一部份 -- 咱們將會在第二部分繼續介紹光照和紋理，下面的章節會更加深刻。

第2部份: 3D環境的光照和紋理

世界的燈光
　　在變換過程當中， 一般是在稱爲觀察空間的座標空間中， 咱們遇到了最重要的運算之一: 光照計算。 它是一種這樣的事情， 當它工做時，你不關注它，但當它不工做時， 你就很是關注它了。有不少不一樣的光照方法，從簡單的計算多邊形對於燈光的朝向，並根據燈光到多邊形的方向和距離加上燈光顏色的百分比值，一直到產生邊緣平滑的燈光貼圖疊加基本紋理。並且一些 API實際上提供預先建造的光照方法。舉例來講，OpenGL 提供了每多邊形，每頂點，和每像素的光照計算。

　　在頂點光照中，你要決定一個頂點被多少個多邊形共享，並計算出共享該頂點的全部多邊形法向量的均值（稱爲法向量），並將該法向量賦頂點。一個給定多邊形的每一個頂點會有不一樣的法向量，因此你須要漸變或插值多邊形頂點的光照顏色以便獲得平滑的光照效果。你沒有必要用這種光照方式查看每一個單獨的多邊形。 這種方式的優勢是時常能夠使用硬件轉換與光照（T & L）來幫助快速完成。不足之處是它不能產生陰影。 舉例來講，即便燈光是在模型的右側，左手臂應該在被身體投影的陰影中，而實際上模型的雙臂卻以一樣的方式被照明瞭。

　　這些簡單的方法使用着色來達到它們的目標。 當用平面光照繪製一個多邊形時， 你讓渲染（繪製）引擎把整個多邊形都着上一種指定的顏色。這叫作平面着色光照。 (該方法中，多邊形均對應一個光強度，表面上全部點都用相同的強度值顯示，渲染繪製時獲得一種平面效果，多邊形的邊緣不能精確的顯示出來)。

　　對於頂點着色 ( Gouraud着色) ，你讓渲染引擎給每一個頂點賦予特定的顏色。在繪製多邊形上各點投影所對應的像素時，根據它們與各頂點的距離，對這些頂點的顏色進行插值計算。 (實際上Quake III模型使用的就是這種方法， 效果好的使人驚奇)。

　　還有就是 Phong 着色。如同 Gouraud 着色，經過紋理工做，但不對每一個頂點顏色進行插值決定像素顏色值，它對每一個頂點的法向量進行插值，會爲每一個頂點投影的像素作相同的工做。對於 Gouraud着色，你須要知道哪些光投射在每一個頂點上。對於 Phong 着色，你對每一個像素也要知道這麼多。

　　一點也不使人驚訝， Phong着色能夠獲得更加平滑的效果，由於每一個像素都須要進行光照計算，其繪製很是耗費時間。平面光照處理方法很快速， 但比較粗糙。Phong 着色比 Gouraud着色計算更昂貴，但效果最好，能夠達到鏡面高光效果("高亮")。這些都須要你在遊戲開發中折衷權衡。

不一樣的燈光
　　接着是生成照明映射，你用第二個紋理映射（照明映射）與已有的紋理混合來產生照明效果。這樣工做得很好， 但這本質上是在渲染以前預先生成的一種罐裝效果。若是你使用動態照明 (即，燈光移動，或者沒有程序的干預而打開和關閉)，你得必須在每一幀從新生成照明映射，按照動態燈光的運動方式修改這些照明映射。燈光映射可以快速的渲染，但對存儲這些燈光紋理所需的內存消耗很是昂貴。你能夠使用一些壓縮技巧使它們佔用較少的的內存空間，或減小其尺寸大小，甚至使它們是單色的 (這樣作就不會有彩色燈光了)，等等。若是你確實在場景中有多個動態燈光， 從新生成照明映射將以昂貴的CPU週期而了結。

　　許多遊戲一般使用某種混合照明方式。 以Quake III爲例，場景使用照明映射，動畫模型使用頂點照明。 預先處理的燈光不會對動畫模型產生正確的效果 --整個多邊形模型獲得燈光的所有光照值 -- 而動態照明將被用來產生正確的效果。使用混合照明方式是多數的人們沒有注意到的一個折衷，它一般讓效果看起來"正確"。這就是遊戲的所有 – 作一切必要的工做讓效果看起來"正確"，但沒必要真的是正確的。

　　固然，全部這些在新的Doom引擎裏面都不復存在了，但要看到全部的效果，至少須要 1GHZ CPU和 GeForce 2 顯卡。是進步了，但一切都是有代價的。

　　一旦場景通過轉換和照明， 咱們就進行裁剪運算。不進入血淋淋的細節而，剪斷運算決定哪些三角形徹底在場景 (被稱爲觀察平截頭體)以內或部份地在場景以內。徹底在場景以內的三角形被稱爲細節接受，它們被處理。對於只是部分在場景以內的三角形， 位於平截頭體外面的部分將被裁剪掉，餘下位於平截頭體內部的多邊形部分將須要從新閉合，以便其徹底位於可見場景以內。 (更多的細節請參考咱們的 3D流水線指導一文)。

　　場景通過裁剪之後，流水線中的下一個階段就是三角形生成階段(也叫作掃描線轉換)，場景被映射到2D屏幕座標。到這裏，就是渲染（繪製）運算了。

紋理與MIP映射
　　紋理在使3D場景看起來真實方面異常重要，它們是你應用到場景區域或對象的一些分解成多邊形的小圖片。多重紋理耗費大量的內存，有不一樣的技術來幫助管理它們的尺寸大小。紋理壓縮是在保持圖片信息的狀況下，讓紋理數據更小的一種方法。紋理壓縮佔用較少的遊戲CD空間，更重要的是，佔用較少內存和3D顯卡存儲空間。另外，在你第一次要求顯卡顯示紋理的時候，壓縮的(較小的)版本通過 AGP 接口從 PC主存送到3D 顯卡， 會更快一些。紋理壓縮是件好事情。 在下面咱們將會更多的討論紋理壓縮。

MIP 映射（多紋理映射）
　　遊戲引擎用來減小紋理內存和帶寬需求的另一個技術就是 MIP 映射。 MIP映射技術經過預先處理紋理，產生它的多個拷貝紋理，每一個相繼的拷貝是上一個拷貝的一半大小。爲何要這樣作?要回答這個問題，你須要瞭解 3D顯卡是如何顯示紋理的。最壞狀況，你選擇一個紋理，貼到一個多邊形上，而後輸出到屏幕。咱們說這是一對一的關係，最初紋理映射圖的一個紋素 (紋理元素)對應到紋理映射對象多邊形的一個像素。若是你顯示的多邊形被縮小一半，紋理的紋素就每間隔一個被顯示。這樣一般沒有什麼問題 --但在某些狀況下會致使一些視覺上的怪異現象。讓咱們看看磚塊牆壁。 假設最初的紋理是一面磚牆，有許多磚塊，磚塊之間的泥漿寬度只有一個像素。若是你把多邊形縮小一半，紋素只是每間隔一個被應用，這時候，全部的泥漿會忽然消失，由於它們被縮掉了。你只會看到一些奇怪的圖像。

　　使用 MIP 映射，你能夠在顯示卡應用紋理以前，本身縮放圖像，由於能夠預先處理紋理，你作得更好一些，讓泥漿不被縮掉。當 3D顯卡用紋理繪製多邊形時，它檢測到縮放因子，說，"你知道，我要使用小一些的紋理，而不是縮小最大的紋理，這樣看起來會更好一些。"在這裏， MIP 映射爲了一切，一切也爲了 MIP映射。

多重紋理與凹凸映射
　　單一紋理映射給整個3D 真實感圖形帶來很大的不一樣，但使用多重紋理甚至能夠達到一些更加使人難忘的效果。過去這一直須要多遍渲染（繪製），嚴重影響了像素填充率。 但許多具備多流水線的3D 加速卡，如ATI's Radeon和 nVidia's GeForce 2及更高級的顯卡，多重紋理能夠在一遍渲染（繪製）過程當中完成。產生多重紋理效果時， 你先用一個紋理繪製多邊形，而後再用另一個紋理透明地繪製在多邊形上面。這讓你能夠使紋理看上去在移動，或脈動，甚至產生陰影效果 (咱們在照明一節中描述過)。繪製第一個紋理映射，而後在上面繪製帶透明的全黑紋理，引發一種是全部的織法黑色的可是有一個透明分層堆積過它的頂端， 這就是 -- 即時陰影。 該技術被稱爲照明映射 ( 有時也稱爲 暗映射)，直至新的Doom，一直是Id引擎裏關卡照明的傳統方法。

　　凹凸貼圖是最近涌現出來的一種古老技術。幾年之前 Matrox第一個在流行的 3D 遊戲中發起使用各類不一樣形式的凹凸貼圖。就是生成紋理來表現燈光在表面的投射，表現表面的凹凸或表面的裂縫。凹凸貼圖並不隨着燈光一塊兒移動 -- 它被設計用來表現一個表面上的細小瑕疵，而不是大的凹凸。好比說，在飛行模擬器中，你能夠使用凹凸貼圖來產生像是隨機的地表細節，而不是重複地使用相同的紋理，看上去一點趣味也沒有。

　　凹凸貼圖產生至關明顯的表面細節，儘管是很高明的戲法，但嚴格意義上講，凹凸貼圖並不隨着你的觀察角度而變化。比較新的 ATI和 nVidia 顯卡片能執行每像素運算，這種缺省觀察角度的不足就真的再也不是有力而快速的法則了。不管是哪種方法， 到目前爲止，沒有遊戲開發者太多的使用；更多的遊戲可以且應該使用凹凸貼圖。

高速緩存抖動 = 糟糕的事物
　　紋理高速緩存的管理遊戲引擎的速度相當重要。 和任何高速緩存同樣，緩存命中很好，而不命中將很糟糕。若是遇到紋理在圖形顯示卡內存被頻繁地換入換出的狀況，這就是紋理高速緩存抖動。發生這種狀況時，一般API將會廢棄每一個紋理，結果是全部的紋理在下一幀將被從新加載，這很是耗時和浪費。對遊戲玩家來講，當API從新加載紋理高速緩存時，會致使幀速率遲鈍。

　　在紋理高速緩存管理中，有各類不一樣的技術將紋理高速緩存抖動減到最少 –這是確保任何 3D 遊戲引擎速度的一個決定性因素。紋理管理是件好事情 – 這意味着只要求顯卡使用紋理一次，而不是重複使用。這聽起來有點自相矛盾，但效果是它意謂着對顯卡說，"看，全部這些多邊形所有使用這一個紋理，咱們可以僅僅加載這個紋理一次而不是許屢次嗎?" 這阻止API ( 或圖形驅動軟件)上傳屢次向顯卡加載紋理。象OpenGL這樣的API實際上一般處理紋理高速緩存管理，意謂着，根據一些規則，好比紋理存取的頻率，API決定哪些紋理儲存在顯卡上，哪些紋理存儲在主存。真正的問題來了：a) 你時常沒法知道API正在使用的準確規則。 b)你時常要求在一幀中繪製更多的紋理，以至超出了顯卡內存空間所能容納的紋理。

　　另一種紋理高速緩存管理技術是咱們早先討論的紋理壓縮。很象聲音波形文件被壓縮成 MP3文件，儘管沒法達到那樣的壓縮比率，但紋理能夠被壓縮。 從聲音波形文件到MP3的壓縮能夠達到 11:1的壓縮比率，而絕大多數硬件支持的紋理壓縮運算法則只有 4:1的壓縮比率，儘管如此，這樣能產生很大的差異。 除此以外，在渲染（繪製）過程當中，只有在須要時，硬件才動態地對紋理進行解壓縮。這一點很是棒，咱們僅僅擦除即將可能用到的表面。

　　如上所述，另一種技術確保渲染器要求顯卡對每一個紋理只繪製一次。肯定你想要渲染（繪製）的使用相同紋理的全部多邊形同時送到顯卡，而不是一個模型在這裏，另外一個模型在那裏，而後又回到最初的紋理論。僅僅繪製一次，你也就經過AGP接口傳送一次。Quake III在其陰影系統就是這麼作的。處理多邊形時，把它們加入到一個內部的陰影列表，一旦全部的多邊形處理完畢，渲染器遍歷紋理列表，就將紋理及全部使用這些紋理的多邊形同時傳送出去。

　　上述過程在使用顯卡的硬件 T & L（若是支持的話）時，並不怎麼有效。你面臨的結局是，滿屏幕都是使用相同紋理的大量的多邊形小羣組，全部多邊形都使用不一樣的變換矩陣。這意謂着更多的時間花在創建顯卡的硬件 T & L引擎 ，更多的時間被浪費了。 不管如何，由於他們有助於對整個模型使用統一的紋理，因此它對實際屏幕上的模型能夠有效地工做。可是由於許多多邊形傾向使用相同的牆壁紋理，因此對於世界場景的渲染，它經常就是地獄。一般它沒有這麼嚴重，由於大致而言，世界的紋理不會有那麼大，這樣一來API的紋理緩存系統將會替你處理這些，並把紋理保留在顯卡以備再次使用。

　　在遊戲機上，一般沒有紋理高速緩存系統(除非你寫一個)。在 PS2上面，你最好是遠離"一次紋理"的方法。在 Xbox 上面， 這是不重要的，由於它自己沒有圖形內存(它是 UMA體系結構)，且全部的紋理不管如何始終保留在主存之中。

　　事實上，在今天的現代PC FPS遊戲中，試圖經過AGP接口傳送大量紋理是第二個最一般的瓶頸。最大的瓶頸是實際幾何處理，它要使東西出如今它應該出現的地方。在現在的3D FPS遊戲中，最耗費時間的工做，顯然是那些計算模型中每一個頂點正確的世界位置的數學運算。若是你不把場景的紋理保持在預算以內，僅居其次的就是經過AGP接口傳送大量的紋理了。然而，你確實有能力影響這些。經過下降頂層的 MIP 級別(還記得系統在哪裏不斷地爲你細分紋理嗎?)，你就可以把系統正在嘗試送到顯卡的紋理大小減小一半。你的視覺質量會有所降低-- 尤爲是在引人注目的電影片段中--可是你的幀速率上升了。這種方式對網絡遊戲尤爲有幫助。實際上，Soldier of Fortune II和Jedi Knight II: Outcast這兩款遊戲在設計時針對的顯卡還不是市場上的大衆主流顯卡。爲了以最大大小觀看他們的紋理，你的3D顯卡至少須要有128MB的內存。這兩種產品在思想上都是給將來設計的。

　　上面就是第 2 部份。在下面章節中，咱們將介紹許多主題，包括內存管理，霧效果，深度測試， 抗鋸齒，頂點着色，API等。

第3部份:內存使用，特效和API

關於內存使用的思考
　　讓咱們想想，在今天其實是如何使用3D 顯卡內存的以及在未來又會如何使用。現在絕大多數3D顯卡處理32位像素顏色，8位紅色， 8位藍色，8位綠色，和 8 位透明度。這些組合的紅，藍和綠256個色度，能夠組成 16。7百萬種顏色-- 那是你我能夠在一個監視器上看見的全部顏色。

　　那麼，遊戲設計大師John Carmack爲何要求 64 位顏色分辨率呢?若是咱們看不出區別，又有什麼意義呢? 意義是:好比說， 有十幾個燈光照射模型上的點，顏色顏色各不相同。 咱們取模型的最初顏色，而後計算一個燈光的照射，模型顏色值將改變。 而後咱們計算另外的一個燈光，模型顏色值進一步改變。 這裏的問題是，由於顏色值只有8位，在計算了4個燈光以後，8位的顏色值將不足以給咱們最後的顏色較好的分辨率和表現。分辨率的不足是由量化偏差致使的，本質緣由是因爲位數不足引發的舍入偏差。

　　你能很快地用盡位數，並且一樣地，全部的顏色被清掉。每顏色16或 32 位，你有一個更高分辨率，所以你可以反覆着色以適當地表現最後的顏色。這樣的顏色深度很快就能消耗大量的存儲空間。咱們也應提到整個顯卡內存與紋理內存。這裏所要說的是，每一個3D顯卡實際只有有限的內存，而這些內存要存儲前端和後端緩衝區，Z 緩衝區，還有全部的使人驚奇的紋理。最初的 Voodoo1顯卡只有2MB顯存，後來 Riva TNT提升到16MB顯存。而後 GeForce和 ATI Rage有32MB顯存，如今一些 GeForce 2 到 4的顯卡和 Radeons帶有 64MB 到128MB的顯存。 這爲何重要? 好吧，讓咱們看一些數字…

　　好比你想讓你的遊戲看起來最好，因此你想要讓它以32位屏幕， 1280x1024分辨率和32位 Z-緩衝跑起來。 好，屏幕上每一個像素4個字節，外加每一個像素4字節的Z-緩衝，由於都是每像素32位。咱們有1280x1024個像素 – 也就是 1，310，720個像素。基於前端緩衝區和Z-緩衝區的字節數，這個數字乘以8，是 10，485，760字節。包括一個後端緩衝區，這樣是 1280x1024x12，也就是 15，728，640字節， 或 15MB。在一個 16MB 顯存的顯卡上，就只給咱們剩下1MB來存儲全部的紋理。 如今若是最初的紋理是真32位或 4字節寬，那麼咱們每幀能在顯卡上存儲 1MB/4字節每像素 = 262，144個像素。這大約是4個 256x256 的紋理頁面。

　　很清楚，上述例子代表，舊的16MB顯卡沒有現代遊戲表現其絢麗畫面所須要的足夠內存。很明顯，在它繪製畫面的時候，咱們每幀都必須從新把紋理裝載到顯卡。實際上，設計AGP總線的目的就是完成這個任務，不過， AGP仍是要比 3D 掀卡的幀緩衝區慢，因此你會受到性能上的一些損失。很明顯，若是紋理由32位下降到16位，你就可以經過AGP以較低的分辨率傳送兩倍數量的紋理。若是你的遊戲以每一個像素比較低的色彩分辨率跑，那麼就能夠有更多的顯示內存用來保存經常使用的紋理 (稱爲高速緩存紋理)。 但實際上你永遠不可能預知使用者將如何設置他們的系統。若是他們有一個在高分辨率和顏色深度跑的顯卡，那麼他們將會更可能那樣設定他們的顯卡。

霧
　　咱們如今開始講霧,它是某種視覺上的效果。現在絕大多數的引擎都能處理霧，由於霧很是方便地讓遠處的世界淡出視野，因此當模型和場景地理越過觀察體後平面進入視覺範圍內時，你就不會看見它們忽然從遠處跳出來了。也有一種稱爲體霧的技術。這種霧不是隨物體離照相機的距離而定,它其實是一個你能看見的真實對象，而且能夠穿越它，從另一側出去 --當你在穿越對象的時候，視覺上霧的可見程度隨着變化。想象一下穿過雲團 -- 這是體霧的一個完美例子。體霧的一些好的實現例子是Quake III一些關卡中的紅色霧，或新的Rogue Squadron II之 Lucas Arts的 GameCube版本。其中有一些是我曾經見過的最好的雲--大約與你能看見的同樣真實。

　　在咱們討論霧化的時候,多是簡短介紹一下 Alpha測試和紋理Alpha混合的好時機。當渲染器往屏幕上畫一個特定像素時，假定它已經經過 Z-緩衝測試 (在下面定義)，咱們可能最後作一些Alpha測試。咱們可能發現爲了顯示像素後面的某些東西，像素須要透明繪製。這意味着咱們必須取得像素的已有值，和咱們新的像素值進行混和，並把混合結果的像素值放回原處。這稱爲讀-修改-寫操做,遠比正常的像素寫操做費時。

　　你能夠用不一樣類型的混合，這些不一樣的效果被稱爲混合模式。直接Alpha混合只是把背景像素的一些百分比值加到新像素的相反百分比值上面。還有加法混合，將舊像素的一些百分比,和特定數量(而不是百分比)的新像素相加。這樣效果會更加鮮明。 (Kyle'sLightsaber在 Jedi Knight II中的效果)。

　　每當廠商提供新的顯卡時，咱們能夠獲得硬件支持的更新更復雜的混合模式，從而製做出更多更眩目的效果。GF3+4和最近的Radeon顯卡提供的像素操做，已經到了極限。

模板陰影與深度測試
　　用模板產生陰影效果，事情就變得複雜而昂貴了。這裏不討論太多細節（能夠寫成一篇單獨的文章了），其思想是，從光源視角繪製模型視圖，而後用這個把多邊形紋理形狀產生或投射到受影響的物體表面。

　　實際上你是在視野中投射將會「落」在其餘多邊形上面的光體。最後你獲得看似真實的光照，甚至帶有視角在裏面。由於要動態建立紋理，並對同一場景進行多遍繪製，因此這很昂貴。

　　你能用衆多不一樣方法產生陰影，情形時常是這樣一來，渲染質量與產生效果所須要的渲染工做成比例。有所謂的硬陰影或軟陰影之分，然後者較好，由於它們更加準確地模仿陰影一般在真實世界的行爲。一般有一些被遊戲開發者偏心的「足夠好」的方法。如要更多的瞭解陰影，請參考 Dave Salvator的 3D流水線一文。

深度測試
　　如今咱們開始討論深度測試， 深度測試丟棄隱藏的像素，過分繪製開始起做用。過分繪製很是簡單 –在一幀中，你數次繪製一個像素位置。它以3D場景中Z（深度）方向上存在的元素數量爲基礎，也被稱爲深度複雜度。若是你經常太多的過分繪製， --舉例來講, 符咒的眩目視覺特效，就象Heretic II，能讓你的幀速率變得很糟糕。當屏幕上的一些人們彼此施放符咒時，Heretic II設計的一些最初效果形成的情形是，他們在一幀中對屏幕上每一個相同的像素畫了40次!不用說，這必須調整，尤爲是軟件渲染器，除了將遊戲下降到象是滑雪表演外，它根本不能處理這樣的負荷。深度測試是一種用來決定在相同的像素位置上哪些對象在其它對象前面的技術，這樣咱們就可以避免繪製那些隱藏的對象。

　　看着場景並想一想你所看不見的。 換句話說，是什麼在其餘場景對象前面,或者隱藏了其餘場景對象?是深度測試做出的這個決定。

　　我將進一步解釋深度深度如何幫助提升幀速率。想像一個很瑣細的場景，大量的多邊形 (或像素)位於彼此的後面，在渲染器得到他們之間沒有一個快速的方法丟棄他們。對非Alpha混合的多邊形分類排序(在Z- 方向上)，首先渲染離你最近的那些多邊形，優先使用距離最近的像素填充屏幕。因此當你要渲染它們後面的像素（由Z或者深度測試決定）時，這些像素很快被丟棄，從而避免了混合步驟並節省了時間。若是你從後到前繪製，全部隱藏的對象將被徹底繪製，而後又被其餘對象徹底重寫覆蓋。場景越複雜，這種狀況就越糟糕，因此深度測試是個好東西。

抗鋸齒
　　讓咱們快速的看一下抗鋸齒。當渲染單個多邊形時，3D 顯卡仔細檢查已經渲染的，並對新的多邊形的邊緣進行柔化，這樣你就不會獲得明顯可見的鋸齒形的像素邊緣。兩種技術方法之一一般被用來處理。第一種方法是單個多邊形層次，須要你從視野後面到前面渲染多邊形，這樣每一個多邊形都能和它後面的進行適當的混合。若是不按序進行渲染，最後你會看見各類奇怪的效果。在第二種方法中，使用比實際顯示更大的分辯率來渲染整幅幀畫面，而後在你縮小圖像時，尖銳的鋸齒形邊緣就混合消失了。這第二種方法的結果不錯，但由於顯卡須要渲染比實際結果幀更多的像素，因此須要大量的內存資源和很高的內存帶寬。

　　多數新的顯卡能很好地處理這些，但仍然有多種抗鋸齒模式能夠供你選擇，所以你能夠在性能和質量之間做出折衷。對於當今流行的各類不一樣抗鋸齒技術的更詳細討論請參見Dave Salvator的3D 流水線一文。

頂點與像素着色
　　在結束討論渲染技術以前，咱們快速的說一下頂點和像素着色，最近它們正引發不少關注。頂點着色是一種直接使用顯卡硬件特徵的方式，不使用API。舉例來講，若是顯卡支持硬件 T & L，你能夠用DirectX或OpenGL編程，並但願你的頂點經過 T & L單元 (由於這徹底由驅動程序處理，因此沒有辦法確信)，或者你直接利用顯卡硬件使用頂點着色。它們容許你根據顯卡自身特徵進行特別編碼，你本身特殊的編碼使用T & L引擎，以及爲了發揮你的最大優點，顯卡必須提供的其餘別的特徵。 事實上，如今nVidia和ATI 在他們大量的顯卡上都提供了這個特徵。

　　不幸的是，顯卡之間表示頂點着色的方法並不一致。你不能象使用DirectX或者OpenGL那樣，爲頂點着色編寫一次代碼就能夠在任何顯卡上運行，這但是個壞消息。然而，由於你直接和顯卡硬件交流，它爲快速渲染頂點着色可能生成的效果提供最大的承諾。(如同創造很不錯的特效 -- 你可以使用頂點着色以API沒有提供的方式影響事物)。事實上，頂點着色正在真的將3D圖形顯示卡帶回到遊戲機的編碼方式，直接存取硬件，最大限度利用系統的必須知識，而不是依靠API來爲你作一切。對一些程序員來講，會對這種編碼方式感到吃驚，但這是進步代價。

　　進一步闡述，頂點着色是一些在頂點被送到顯卡渲染以前計算和運行頂點效果程序或者例程。你能夠在主CPU上面用軟件來作這些事情，或者使用顯卡上的頂點着色。爲動畫模型變換網格是頂點程序的主選。

　　像素着色是那些你寫的例程，當繪製紋理時，這些例程就逐個像素被執行。你有效地用這些新的例程推翻了顯卡硬件正常狀況作的混合模式運算。這容許你作一些很不錯的像素效果，好比，使遠處的紋理模糊，添加炮火煙霧, 產生水中的反射效果等。一旦 ATI和 nVidia 能實際上就像素着色版本達成一致( DX9's新的高級陰影語言將會幫助促進這一目標), 我一點不驚訝DirectX和OpenGL採用Glide的方式--有幫助開始, 但最終不是把任何顯卡發揮到極限的最好方法。我認爲我會有興趣觀望未來。

最後（In Closing...）
　　最終，渲染器是遊戲程序員最受評判的地方。在這個行業，視覺上的華麗很是重要，所以它爲知道你正在作的買單。對於渲染器程序員，最壞的因素之一就是3D顯卡工業界變化的速度。一天，你正在嘗試使透明圖像正確地工做；次日 nVidia 正在作頂點着色編程的展現。並且發展很是快，大體上，四年之前爲那個時代的 3D 顯卡寫的代碼如今已通過時了，須要所有重寫。甚至John Carmack 這樣描述過，他知道四年之前爲充分發揮那個時期顯卡的性能所寫的不錯的代碼，現在很平凡 --所以他產生了爲每一個新的id項目徹底重寫渲染器的慾望。Epic的Tim Sweeney贊同 --這裏是去年他給個人評論:

　　咱們已經足足花費了9個月時間來更換全部的渲染代碼。最初的 Unreal被設計爲軟件渲染和後來擴展爲硬件渲染。下一代引擎被設計爲 GeForce 及更好的圖形顯示卡，且多邊形吞吐量是Unreal Tournament的100倍。

　　這須要所有替換渲染器。很幸運，該引擎模塊化程度足夠好，咱們能夠保持引擎的其他部分—編輯器，物理學，人工智能，網絡--不改動，儘管咱們一直在以許多方式改進這些部分。

　　搭配長篇文章的短篇報導（Sidebar）：API --祝福和詛咒
　　那麼什麼是API? 它是應用程序編程接口,將不一致的後端用一致的前端呈現出來。舉例來講，很大程度上每種3D顯示卡的3D實現方式都有所差異。然而，他們所有都呈現一個一致的前端給最終使用者或者程序員，因此他們知道他們爲X 3D顯示卡寫的代碼將會在Y 3D顯示卡上面有相同的結果。好吧，無論怎樣理論上是那樣。大約在三年之前這多是至關真實的陳述，但自那之後，在nVidia 公司的引領下，3D顯卡行業的事情發生了變化。

　　現在在PC領域，除非你正計劃建造本身的軟件光柵引擎，使用CPU來繪製你全部的精靈，多邊形和粒子 --並且人們仍然在這樣作。跟Unreal同樣，Age of Empires II: Age of Kings有一個優秀的軟件渲染器 –不然你將使用兩種可能的圖形API，OpenGL或者 DirectX之一。OpenGL是一種真正的跨平臺API (使用這種API寫的軟件能夠在Linux，Windows和MacOS上運行。)，並且有多年的歷史了，爲人所熟知，但也開始慢慢地顯示出它的古老。 大約在四年之前，定義OpenGL驅動特徵集一直是全部顯示卡廠商工做的方向。

　　然而，一旦在目標達成之後，沒有預先制定特徵工做方向的路線圖，這時候，全部的顯卡開發商開始在特徵集上分道揚鑣，使用OpenGL擴展。

　　3dfx 創造了T-緩衝。 nVidia 努力尋求硬件變換和光照計算。Matrox努力獲取凹凸貼圖。等等。我之前說過的一句話，"過去幾年以來，3D顯示卡領域的事情發生了變化。"委婉地說明了這一切。

　　不管如何，另外一個能夠選擇的API是 DirectX。這受Microsoft公司控制，且在PC和 Xbox 上被完美地支持。因爲明顯的緣由，DirectX沒有Apple或者 Linux版本。由於Microsoft控制着 DirectX，大致上它容易更好地集成在Windows裏面。

　　OpenGL和DirectX之間的基本差異是前者由‘社區’擁有，然後者由Microsoft擁有。若是你想要 DirectX 爲你的 3D 顯示卡支持一個新的特徵，那麼你須要遊說微軟，但願採納你的願望，並等待新的 DirectX發行版本。對於OpenGL，因爲顯示卡製造商爲3D顯示卡提供驅動程序，你可以經過OpenGL擴展當即得到顯示卡的新特徵。這是好，但做爲遊戲開發者，當你爲遊戲編碼的時候，你不能期望它們很廣泛。它們可能讓你的遊戲速度提高50%，但你不能要求別人有一塊GeForce 3 來跑你的遊戲。好吧，你能夠這麼作，但若是你想來年還在這個行業的話，這是個至關愚蠢的主意。

　　這是對這個問題極大的簡單化，對我全部描述的也有各類例外狀況，但這裏通常的思想是很確實的。對於DirectX，在任何既定時間你容易確切地知道你能從顯示卡得到的特徵，若是一個特徵不能得到，DirectX將會用軟件模擬它(也不老是一件好事情，由於這樣有時侯很是的慢，但那是另一回事)。對於OpenGL，你能夠更加貼近顯示卡的特徵,但代價是不能肯定將會得到的準確特徵。

第4部份:模型與動畫，細節級別

角色建模與動畫
　　你的角色模型在屏幕上看起來怎麼樣,怎樣容易建立它們,紋理,以及動畫對於現代遊戲試圖完成的`消除不可信`因素來講相當重要。角色模型系統逐漸變得複雜起來,包括較高的多邊形數量模型, 和讓模型在屏幕上移動的更好方式。

　　現在你須要一個骨骼模型系統，有骨架和網格細節層次，單個頂點骨架的評估，骨架動畫忽略，以及比賽中停留的角度忽略。而這些甚至尚未開始涉及一些你能作的很好的事情，像動畫混合，骨架反向運動學（IK），和單個骨架限制，以及相片真實感的紋理。這個清單還可以繼續列下去。可是真的，在用專業行話說了全部這些之後，咱們在這裏真正談論的是什麼呢？讓咱們看看。

　　讓咱們定義一個基於網格的系統和一個骨骼動畫系統做爲開始。在基於網格的系統，對於每個動畫幀，你要定義模型網格的每一個點在世界中的位置。舉例來講，你有一個包含200個多邊形的手的模型，有 300 個頂點(注意，在頂點和多邊形之間一般並非3個對1個的關係，由於大量多邊形時常共享頂點 –使用條形和扇形，你能大幅減小頂點數量)。若是動畫有 10幀，那麼你就須要在內存中有300個頂點位置的數據。總共有300 x 10 = 3000 頂點，每一個頂點由x，y，z和顏色/alpha信息組成。你能看見這個增加起來是多麼的快。Quake I，II和 III都使用了這種系統，這種系統確實有動態變形網格的能力，好比使裙子擺動，或者讓頭髮飄動。

　　相比之下，在骨骼動畫系統，網格是由骨架組成的骨骼(骨架是你運動的對象)。 網格頂點和骨架自己相關，因此它們在模型中的位置都是相對於骨架，而不是網格表明每一個頂點在世界中的位置。所以，若是你移動骨架，組成多邊形的頂點的位置也相應改變。這意謂着你只必須使骨骼運動，典型狀況大約有 50個左右的骨架—很明顯極大地節省了內存。

骨骼動畫附加的好處
　　骨骼動畫的另外一個優勢是可以根據影響頂點的一些骨架來分別「估價」每一個頂點。例如，雙臂的骨架運動，肩，脖子並且甚至軀幹都能在肩中影響網格。當你移動軀幹的時候，網格就活像一個角色同樣移動。總的效果是3D角色可以實現的動畫更加流暢和可信，且須要更少的內存。每一個人都贏了。

　　固然這裏的缺點是，若是你想要使有機的東西運動且很好，好比說頭髮，或者披肩，爲了讓它看起來天然，你最後不得不在裏面放置數量驚人的骨架，這會擡高一些處理時間。

　　基於骨骼的系統能帶給你的一些其餘事情是‘忽略’特定層次骨架的能力-- 說,"我不關心動畫想要對這塊骨架所作的事情，我想要讓它指向世界中的一個特定點"。這很棒。你能讓模型着眼於世界中的事件，或者使他們的腳在他們站着的地面保持水平。這一切很是微妙，但它能夠幫助帶給場景附加的真實感。

　　在骨骼系統，你甚至能夠指定"我須要把這個特別的動畫用於模型的腿，而一個不一樣的攜槍或射擊動畫在模型軀幹上播放，且那傢伙（角色）叫喊的不一樣動畫效果在模型的頭部播放"。很是妙。Ghoul2 (在Soldier of Fortune II:Double Helix and Jedi Knight I: Outcast中使用了Raven的動畫系統 )擁有全部這些好東西，且特別被設計爲容許程序員使用全部這些忽略能力。這對動畫的節省像你同樣難以相信。像你同樣的動畫上的此次救援不相信. Raven有一個角色行走的動畫和一個站立開火的動畫，並在它同時行走和開火形下把這兩個動畫合併，而不是須要一個動畫表示角色行走並開火。

More Skeletons in the Closet
　　先前描述的效果能夠經過具備層次的骨骼系統來完成。這是什麼意思呢？意思是每塊骨架實際上的位置相對於它的父親，而不是每一個骨架直接位於空間中的地方。這意謂着若是你移動父親骨架，那麼它全部的子孫骨架也跟着移動，在代碼上不須要任何額外的努力。這是讓你可以在任何骨架層次改變更畫，並且經過骨骼其他部分向下傳遞的東西。

　　建立一個沒有層次的骨骼系統是可能的 --但那時你不能忽略一個骨架而且預期它工做。你所看到的只是身體上的一個骨架開始了新動畫，除非你實現了某種‘向下傳遞信息’的系統，不然在該骨架下面的其它骨架保持原來的動畫。首先由一個層次系統開始，你就自動地得到這些效果。

　　許多今天的動畫系統中正開始出現一些比較新的特徵，如動畫混合，從一個正在播放的動畫轉變到另一個動畫須要通過一小段時間，而不是當即從一個動畫忽然轉變到另一個。舉例來講，你有個角色在行走，而後他停了下來。你不是僅僅忽然地轉變更畫，讓他的腿和腳停在無效位置，而是一秒鐘混合一半，這樣腳彷佛天然地移到了新的動畫。不可以太高的評價這種效果 --混合是一個微妙的事情,但若是正確的運用，它真的有些差異。

反向運動學
　　反向運動學 (IK) 是被許多人們丟棄的一個專業術語，對它的真實含義沒有多少概念。IK是現在遊戲裏面一個相對比較新的系統。使用 IK ，程序員可以移動一隻手，或一條腿,模型的其他關節自動從新定位，所以模型被正肯定向。並且有模型的關節新位置的其餘者他們本身，所以模型正確的被定向。好比，你將會說,"好，手 ,去拾起桌子上的那個杯子"並指出杯子在世界中的位置。手就會移動到那裏，且它後面的身體會調節其自身以便雙臂移動，身體適當彎曲，等等。

　　也有和IK相反的事情，叫作前向運動學,本質上與 IK工做的次序相反。想像一隻手，手附着在手臂上，手臂附着在身體上。如今想像你重重地擊中了身體。一般手臂像連迦般抽動，且手臂末梢的手隨之振動。 IK可以移動身體，並讓其他的四肢本身以真實的方式移動。基本上它須要動畫師設定每種工做的大量信息 --像關節所能經過的運動範圍，若是一塊骨架前面的骨架移動，那麼這塊骨架將移動多少百分比，等等。

　　和它如今同樣，儘管很好，它是一個很大的處理問題，不用它你能夠有不一樣的動畫組合而脫身。值得注意的是，真正的 IK解決辦法須要一個層次骨骼系統而不是一個模型空間系統 -- 不然它們都耗時太多以至沒法恰當地計算每一個骨架。

LOD幾何系統
　　最後，咱們應當快速討論一下與縮放模型幾何複雜度相關的細節級別（LOD）系統(與討論MIP映射時使用的LOD相對照)。假定現在絕大多數PC遊戲支持的處理器速度的巨大範圍，以及你可能渲染的任何給定可視場景的動態性質(在屏幕上有一個角色仍是12個？)，你一般須要一些系統來處理這樣的狀況，好比，當系統接近極限試圖同時在屏幕上繪製出12個角色，每一個角色有3，000個多邊形,並維持現實的幀速率。 LOD 被設計來協助這樣的情景中。最基本的狀況，它是在任何給定時間動態地改變你在屏幕上繪製的角色的多邊形數量的能力。面對現實吧，當一個角色走遠，也許只有十個屏幕像素高度，你真的不須要3000個多邊形來渲染這個角色 --或許300個就夠了，並且你很難分辨出差異。

　　一些 LOD 系統將會須要你創建模型的多個版本，並且他們將會依靠模型離觀察者的接近程度來改變屏幕上的LOD級別，以及多少個多邊形正被同時顯示。更加複雜的系統實際上將會動態地減小屏幕上的多邊形數量，在任何給定時間，任何給定的角色，動態地 -- Messiah和Sacrifice包括了這種風格的技術，儘管在CPU方面並不便宜。你必須確信，與首先簡單地渲染整個事物相比，你的 LOD 系統沒有花較多的時間計算出要渲染那些多邊形（或不渲染）。 任一方式都將會工做，因爲現在咱們試圖要在屏幕上繪製的多邊形數量，這是件很是必要的事情。注意， DX9將會支持硬件執行的自適應幾何縮放(tessellation)。

　　歸結起來是，獲得一個運動流暢，其表現和移動在視覺上可信，屏幕上看起來逼真的模型。流暢的動畫時常是經過手工建造動畫和運動捕捉動畫的組合獲得。有時你僅僅手工創建了一個給定的動畫 --當你在爲一個模型作一些你在現實生活中不能作到的事情的動畫時， 你傾向於這樣作 --舉例來講，你確實不能向後彎腰，或像Mortal Kombat 4中的Lui Kang那樣在行進的腳踏車上踢腿，一般運動捕捉這時候就出局了!一般運動捕捉動畫 -- 實際上視頻捕捉活生生的演員貫穿於你想在屏幕上所看到的動畫 --是獲得逼真的東西的方式。真實感的東西能使一款普通遊戲看起來很棒，並且能掩飾許多事情。好比 NFL Blitz，屏幕上的模型大約有 200個多邊形。它們在靜止站立時看起來可怕的斑駁，一旦這些模型跑動起來它們就有快速流暢的動畫，模型自身的許多醜陋消失了。眼睛容易看見的是 '逼真的'動畫而不是模型自身的結構。 一個不錯的模型設計師可以掩飾大多數模型缺陷。

　　我但願這些帶給你對模型和動畫問題的洞察力。在第五部份中，咱們將會更加深刻3D世界的建造，討論一些物理，運動和效果系統的東西。

第5部分:物理，運動，效果

世界建造
　　經常在創建一個含有任何3D成分的遊戲時，你最終要試圖創建一個將會在裏面產生遊戲動做的3D環境。不知怎麼的遊戲開發者提供了一個創建這種環境的方，它容易修改，有效率，有較低的多邊形數量，對於遊戲既容易渲染又容易運用物理學。很簡單，對嗎？當作這個的時候我用左手在作什麼？當作這的時候 ,我對個人左手作什麼? 是的。不錯。

　　雖然那裏有許多3D結構程序，從CAD/CAM程序到3D Studio Max，建造遊戲世界是不一樣於建造內部或外部世界的模型的尷尬。你有三角形數量問題 -- 任何給定的渲染器一次只能渲染這麼多的多邊形，這對於天才的關卡設計師來講永遠都不夠。不知這些，你也只能每一個關卡存儲預約數量的多邊形，因此即便你的渲染器可以在視野中處理250，000個多邊形，即便你只能在合理數量的空間中存儲500，000個多邊形，那麼取決於你怎麼處理它，最後你的關卡價值像兩個房間那麼小。很差。

　　任何方法，開發者須要提出一個創做工具 --最好足夠靈活，容許遊戲引擎須要的各類事物 – 好比，在世界中放置對象，在進入遊戲之前對關卡的適當預覽，以及準確的光照預覽。在他們花三個小時預先處理關卡來產生一個 '引擎可消化的'格式以前 , 這些能力容許遊戲開發者看到關卡將在遊戲中看起來怎麼樣。開發者須要關於關卡，多邊形數量，網格數量等等的相應數據。 他們須要一個合宜而友好的方式可以讓世界有紋理背景圖，容易存取多邊形數量縮減工具，如此等等。這個清單能夠繼續列下去。

　　在先前已經存在的工具中找到這個功能是可能的。許多開發者使用Max或者Maya建造他們的關卡，但即便3D Max須要對它的功能有一些任務特定的擴展來有效率地完成關卡建造工做。甚至可能使用關卡建造工具，像QERadient（見下圖），並且把它的輸出從新處理成你的引擎可以解釋的格式。

不能看見它? 別煩擾…
　　回想一下咱們在第一部分討論的BSP (二叉空間分割)樹，你也可能據說過潛在可視集合（PVS）這個術語正被四處談論。二者都有相同的目標，不去探究涉及到的繁雜的數學，它是一種把世界分解爲你能從世界任何給定位置看見的牆壁的最小子集的方式。在實現時，它們僅僅返回你能看見的那些，而不是那些隱藏在可能被遮擋的牆壁後面的。你能想象出這給軟件渲染器帶來的好處，渲染的每一個像素(多是這樣的情形)極爲重要。它們也按從後到前的順序返回那些牆壁，在渲染時這是很方便的，由於你可以在渲染次序中肯定一個對象的實際位置。

　　大致而言，BSP 樹最近正不受歡迎，因爲它們的一些古怪，並且由於咱們從當今3D顯示卡得到的像素吞吐量，再加上Z緩衝像素測試，BSP經常成了一個多餘的過程。它們在計算出你在世界的確切位置和正在你周圍的幾何物體方面是便利的，但經常有比BSP樹更好並且更直觀的方式來存儲這些信息。

　　潛在可視集像它聽上去同樣很是好。它是這麼一個方法，在任何給定時間，給定你在世界的位置，它決定世界的哪些表面，哪些對象實際上能夠看得見。這時經常使用來在渲染以前剔除對象，也剔除它們來減小AI和動畫處理。畢竟，若是你實際上不能看見它們,爲何還要費腦筋處理呢。多半這真的是不重要的，若是一個非玩家角色（NPC）正在播放動畫，或者甚至在運行它的AI思考。

遊戲物理學
　　既然咱們已經在內存中獲得了世界的結構，咱們必須防止咱們的角色從裏面掉落出去，並處理地板，斜坡，牆壁，門，以及移動平臺。加之，咱們必須正確地處理地心引力，速度變化，慣性，和放置在世界裏面的其它對象的碰撞。這被看做是遊戲物理學。並且在咱們進一步深刻討論以前，我想如今就在這裏消除一個神話。任什麼時候候你在世界中看見物理，或者任何人在一個複雜的遊戲環境中宣稱「真實的物理」，很好，它是BS。超過80%的建造一個有效率遊戲物理系統的精力花在簡化用來處理世界中對象的真實方程式上面。甚至那時，你時常忽略什麼是‘真實的’，並創造一些‘有趣的’東西，畢竟，這是目標所在。

　　常常地遊戲者將會忽視真實世界的牛頓物理學，並扮演他們本身的，更有趣的真實版本。例如，在QuakeII裏面，你可以當即從0加速到35MPH，並快速停下來。沒有摩擦力，並且斜坡不提供真實斜坡提供的相同類型的重力問題。身體沒有它們應該的做用在全部關節上的地心引力 -- 你看不見身體像真實生活中那樣倒在桌子上面或者邊緣 -- 並且地心引力它自己甚至多是可變的。面對現實吧，在真正的世界中，空間中的飛船不像二戰飛行戰鬥員在它們的表面操做那樣實行。在空中，所有是力和副作用力，力在重量點周圍做用，等等。不像 X-Wing中的Luke Skywalker那樣嘯叫。儘管那樣作更加有趣！

　　做爲遊戲開發者來講，不管咱們作什麼，咱們須要可以檢測牆壁，檢測地板，在世界中處理和其餘對象的碰撞。這些是現代遊戲引擎的必備 –咱們決定對它們進一步要作的取決於咱們和咱們的遊戲須要。

效果系統
　　現在絕大多數的遊戲引擎建造有某種效果產生器，這容許咱們表現出有洞察力的遊戲者期盼的全部可愛的吸引眼球的東西。然而，效果系統幕後所進行的東西可以急劇影響幀速率，因此這是咱們須要特別關心的地方。現在咱們有很棒的3D顯示卡，咱們可以傳送大量的三角形給它們，並且他們仍然要求更多的三角形。並不老是那樣。在Heretic II，使用它的可愛的軟件渲染模式，因爲他們漂亮的符咒效果，Raven遇到了至關嚴重的過分繪製問題。回想當你在屏幕上繪製相同的像素超過一次時，過分繪製就發生了。當你有許多效果正在進行，按其性質你有許多三角形，多個三角形可能相互堆疊在彼此上面。結果是你有許多重複繪製的像素。加上Alpha，這意味着在從新繪製以前你必須讀取舊像素並和新的像素混合，這會消耗更多的CPU時間。

　　Heretic II的一些效果能說明這點，咱們在一幀裏對整個屏幕重複繪製了四十遍。很驚訝，是嗎？所以他們在效果系統裏面實現了一個系統採樣在過去30幀的幀速率，若是速度開始減慢，它就自動地縮減任何給定效果繪製的三角形數量。這樣使主要工做完成了，幀速率保持住了，但一些效果看上去很醜陋。

　　不管如何，由於現在絕大多數效果傾向使用大量很小的粒子模擬火和煙等等，結果你在效果代碼裏面每幀要處理許多的三角形。你必須把它們從一幀移動到下一幀，決定它們是否完成了，甚至還要在它們身上運用一些物理學以便讓它們在地板上面適當的反彈。這在PC上面都是至關昂貴的，所以甚至如今你必須對你所可以作的有一些實際限制。舉例來講，用一個像素粒子產生火的效果可能會很好，但當你這麼作的時候就別指望在屏幕上作更多別的事情。

　　粒子被定義爲擁有它們本身的世界位置和速度的很是小的可繪製的物體。它們不一樣於有方向的精靈，大的粒子使用這些精靈 --好比噴出的一團團煙霧。它們面向照相機自動而典型地旋轉，縮放，改變它們的透明級別，所以它們可以隨着時間淡出。咱們容易看到大量的粒子，但咱們卻限制精靈的數量—儘管二者之間的真正不一樣現在正在模糊。未來，特別是在 DX9和更加高級的圖形硬件表面之後，咱們可能看到更多的人們使用過程shader來產生跟粒子系統類似或者更好的效果，創造很是棒的動畫效果。

　　當談論效果系統時，你可能據說過‘圖原’這個詞。一個圖原是你的效果系統將處理的效果的最低級別的物理表現。更進一步解釋，一個三角形是一個圖原。那是絕大多數引擎最終在底層繪製的 --大量的三角形。當你沿着系統向上時，你對圖原的定義隨着變化。好比說，頂層的遊戲程序員不想考慮處理個別的三角形。他僅僅想說,"這個效果在這裏發生"並讓系統以一種黑盒方式處理它。所以對於他來講，一個效果圖原就是‘讓咱們在世界的這點持續這麼長時間用這樣的引力產生一束粒子’。在效果系統內部，它可能認爲一個效果圖原是它那時正在產生的每一個單獨的效果，像一組遵循一樣的物理學規則的三角形—而後它傳送全部這些單獨的三角形到渲染器進行渲染，所以在渲染器層次，圖原就是一個單獨的三角形。有一點困惑，但你知道總的思想了。

　　以上就是第五部分，下一個部分是關於聲音系統，和各類不一樣的音頻APIs，3D音頻效果，處理閉塞和障礙，各類不一樣材料對聲音的影響，音頻混合等等。

第6部分:聲音系統，音頻APIs

聲音系統
　　因爲人們玩的遊戲在種類和技術上的進步，聲音和音樂近幾年來在遊戲中正逐漸變得重要起來（聲音是一個實際遊戲的可玩特色，好比在Thief和其它同類遊戲中的聽覺提示）。如今四聲道環繞系統在遊戲玩家的寶庫中是負擔得起的和日常的事。給定空間的聲音，噪音的障礙和閉塞，和動態的音樂，現在許多遊戲使用這些提升玩家情緒上的反應，更多的關注投入到這個領域就不足爲奇了。

　　如今在PC競技場中，遊戲玩家實際上只有一種聲音卡能夠選擇 -- PC聲卡製造商創新公司（Creative Labs）的Sound Blaster Live！ 從舊的時間我的計算機聲音卡片製造業者有創造力的中心.多年來創新公司已經爲DirectX提供了他們的EAX聲音擴展，而且他們是發起新的OpenAL（開放音頻庫Open Audio Library）的創立者。就如同OpenGL是一個圖形API同樣，OpenAL，像它起來聽同樣，是一個聲音系統的API。OpenAL被設計爲支持大多數一般聲卡的許多特徵，並且在一個特定的硬件特徵不可得時提供一個軟件替代。

　　爲了更好的定義 OpenAL，我向創新公司的Garin Hiebert詢問了其定義:

　　"這裏借用咱們的 " OpenAL規格和叄考" 的一個定義:

　　OpenAL 是對音頻硬件的一個軟件接口,給程序員提供一個產生高質量多通道輸出的能力。OpenAL是在模擬的三維環境裏產生聲音的一種重要方法。它想要跨平臺並容易使用，在風格和規範上與OpenGL類似。任何已經熟悉OpenGL的程序員將發現OpenAL很是熟悉。

　　OpenAL API能容易地被擴展適應插件技術.創新公司已經把EAX支持加入到這套API了，程序員能夠用來給他們的聲音環境增長複雜的反響，比賽和障礙效果。

　　如同Jedi Knight II: Outcast同樣，連同Eagle 世界/聲音特徵編輯器,Soldier of Fortune II以這個新系統爲特徵。什麼是Eagle？在介紹這個之前，讓咱們討論一些其餘的系統，並定義一些聲音術語。

　　另外的一個系統是Miles聲音系統。Miles是一家公司，它爲你的代碼生產插件，在充分利用每塊聲卡時處理全部必須的到特定聲音卡的說話（好比Sound Blaster Live！系列，或者老的A3D聲卡）。它很是像一個API前端，捆綁了一些額外的特徵在裏面。在其餘事物當中Miles讓你存取一些事物像MP3解壓縮。它是很好的解決方案，但像任何事同樣，它花費金錢並是你的代碼和硬件之間的額外一層。雖然對於快速的聲音系統制造，它很是有用，並且他們有段時間了，所以他們的確精通本身的業務。

聲音術語
　　讓咱們開始障礙和閉塞。它們聽起來同樣，但不是這樣。閉塞基本上意謂着一個聲音在播放時聽者在他們之間有一些閉合的障礙物。

　　好比說，在NOLF2的一個屏幕鏡頭上你聽到房子裏面壞蛋的聲音。你能聽到他們，可是他們的聲音至關低沉而沙啞。障礙是類似的，可是你和聲音之間的障礙物並非閉合的。一個好的例子就是在你和聲源之間有一根柱子。因爲房間中的回聲你仍然聽獲得這個聲音，可是它和聲音直接傳遞到你的耳朵裏是不一樣的。固然這確實依賴於知道在你的耳朵和聲源之間的直線上是什麼。並且根據房間的大小，聲源到你的距離等等，須要的處理能變得至關耗時。後面咱們將會談到跟蹤--足能夠說它時常是比較慢的幀速率的緣由。Quake III 裏面的A3D 代碼作了這些事情，關閉這些選項一般可以提升幀速率。Tribe 2是這種弊病的另一個受害者。關閉3D聲音選項則你的幀速率當即好轉，這在你考慮Tribes世界有多大和你能看見多遠時有意義。

　　接着是聲音物質的特徵。大部分聲卡可讓你可以用可定義的過濾器做用於聲音從而修正播放的聲音。例如，在水下，或者在一個布料遮蓋的房間中，或者在一個長的走廊中，或者在歌劇院，聽到的聲音有着很大的不一樣。可以根據你所處的環境改變你聽到聲音的方式是至關不錯的。

　　咱們回到Eagle… 這是一個編輯器，容許多數第一人稱射擊遊戲地圖設計者將他們的地圖導入到這個工具，而後構造簡化的幾何形體來爲實際遊戲引擎中的EAX代碼產生一個聲音地圖。其思想是你不須要一個真實的圖形地圖的複雜幾何形體來模擬聲音環境。你也可以給產生的簡化地圖分配聲音物質，這樣聲音環境就可以動態地改變。我親眼目擊了這在Soldier of Fortune和Unreal Tournament上的示範，確實至關引人注目。 我這在財富和 Unreal巡迴賽和它的軍人上真的對示範是證人至關醒目. 當你跳入水中時，聽到全部的聲音改變，這是一個很是使人沉浸的經歷。

　　好，讓咱們繼續吧。

　　對於遊戲機，因爲靜態的硬件，你的各類可能性會更受限制 —儘管在PlayStation 2和Xbox上，硬件至關不錯。我說的限制，僅僅是指擴展，而不是它所可以作的。我一點也不會感到驚訝看到這些遊戲機上的遊戲很快支持杜比數字5.1（Dolby Digital 5.1）輸出。Xbox，因爲它的 MCP 音頻處理器，可以將任何遊戲音頻編碼爲5.1，而且遊戲不須要特別編碼就能利用這個特徵。杜比（Dolby）把ProLogic II帶到了 PS2 上，並與Factor 5合做爲GameCube遊戲實現了ProLogic II。在 Xbox之上，Halo, Madden 2002 和 Project Gotham Racing等遊戲都有5.1杜比數字音頻內容。DTS最近也爲 PS2 遊戲開發者發佈了SDK，爲這個平臺上的遊戲帶來了下降了比特率的DTS音頻版本。

位置的聲音--一個複雜的世界
　　如今有一些不多有處理的聲音空間化問題。我說的是把聲音放在一個真實的3D世界中。有四個揚聲器在你周圍是一個很棒的開始，但這仍然只是在二維方向。在你的上方和下方沒有揚聲器，你沒有真正得到3D聲音。有一些聲音調製過濾器試圖解決這個問題，但實際上沒有真實東西的代替物。固然真實地大多數遊戲多半隻是在二維方向上，所以這仍然不是太大的問題。

　　實際上任何聲音系統最重要的特徵之一是把聲音混合在一塊兒。根據你所處的位置，空間中聲音的位置，每一個聲音的音量大小，一旦你決定了實際上你可以聽到的聲音，而後你必須混合這些聲音。一般聲音卡本身處理這些，這首先是聲音卡存在的主要緣由。然而，外面有一些引擎決定首先用軟件作一次‘預混合’。直到你着眼於一點點歷史之前，這並無真正地帶來多大的意義。

　　當聲音卡最初問世的時候，有許多不一樣的混合方法。一些聲卡能夠混合8種聲音，一些單位16種，一些32種，等等。若是你總想聽到16種可能的聲音，但你不知道聲音卡是否可以處理，那麼你回到了嘗試和試驗的道路上 —就是你本身用軟件混合。這其實是Quake III聲音系統的工做方式，但提一個問題:"Quake III是爲A3D和Sound Blaster Live！聲卡世界發佈的，這比之前更加標準化，爲何還這樣作？"這是個好問題。實際上Quake III的聲音系統幾乎每行代碼都和Quake II中的聲音系統同樣。並且Quake I，甚至Doom也是這樣。你想想，向上直到 A3D 聲卡和 SB Live! 聲卡，許多年來聲音系統的需求沒有真正地改變過。兩個揚聲器，二維方向，音量簡單地隨着距離減少。從Doom一直到Quake III沒有發生太大變化。並且在遊戲行業中，若是不是無可奈何，別理會它。

　　一般你會僅僅使用DirectSound爲你作聲音混合，由於它會能夠使用的聲音硬件，或者轉而依靠軟件，不少地方就像DirectX爲3D顯示卡所作的同樣。在 90% 的聲音情形中，依靠軟件混合對你的幀速率沒有真正發生太多不一樣。當DirectSound在一些狂熱的編碼者眼中甚至還不是一絲光線時，Doom引擎就已經產生了。它歷來沒有獲得更新過，由於它歷來就沒有真的須要更新。

　　固然，你能夠使用 SoundBlaster Live！聲卡的一些聰明特徵，例如房間的回聲特性:一塊石窟，或一個禮堂，一個巨穴, 一個足球體育館等。並且你真的應該使用由硬件提供的混合器，畢竟，那是它存在的目的。這種方法的一個不足之處是程序自己時常沒法得到混合結果，由於混合是在聲卡內部完成而不是在主存。若是因爲某種緣由你須要看到產生的音量，你是運氣很差。

Music Tracks in Games（遊戲中的音軌）
　　咱們沒有過多的談到遊戲中的音樂生成。傳統的有兩種方法，一種是簡單的音樂 .wav文件(或同等物)。它被預先製做作好，準備運行，和最小忙亂。然而，這些在內存和回放時間方面很昂貴。第二種方式用預設的樣本編碼MIDI音軌。這時常比較節省內存，但缺點是必須同時把一些聲音混合在一塊兒，於是會把聲音通道用光。

　　動態音樂就是根據在遊戲中目擊的行動改變你的音樂的能力，好比探險用慢節奏的音樂，戰鬥用快節奏的音樂。預先製做的音樂的一個困難之處是要合拍，所以你能夠從一段音樂漸弱到另外一段音樂，這對於MIDI音軌比較容易。儘管時常你足夠快速地淡出，或者一段音樂在播放另外一段音樂以前已經消失了，你能僥倖不被察覺。

　　在咱們離開這個主題以前，順便說一下，值得一提的是存在一些公司專門爲你的遊戲創做特定意義的音樂。FatMan(www.fatman.com)就是一家這樣的公司。音樂可能比其餘別的東西更加容易外包，這是他們存在的方式。

　　最後，遊戲如今的事情天然是MP3格式，容許巨大的11：1的聲音樣本壓縮，然而在送到聲音卡以前只花費CPU不多的時間解壓縮。當我在Rave Software工做時，在Star Trek Voyager: Elite Force中，咱們設法用MP3在一張CD上面徹底支持三種語言，仍然爲較多的圖形留有空間。主要地，咱們 MP3只用於非玩家角色（NPC）的語音，因爲遊戲的所有音頻效果MP3流和動態解壓縮超出了硬件的處理能力，雖然在未來這是確定可能的。比較新的格式，如來自 Dolby的 AAC 和來自微軟的WMA，以將近兩倍MP3的壓縮率提供了相等或者更高的音頻質量（實際上一半的比特率），可能應用到未來的遊戲中。

　　以上是這一章節的內容，下面將是網絡和連線遊戲環境的開發。

第7部份:網絡和連線遊戲環境

網絡遊戲
　　我記得一些年前坐在GDC（遊戲開發者大會）聽負責開發X-Wing Vs TIE Fighter的傢伙們題爲「淹沒在Internet」的演講，全是關於讓網絡遊戲實時地在Internet上工做的東西。他們選擇那個題目是多麼的正確啊。當它開始處理數據包的丟失，亂序，潛伏（一個數據包發送到它的目的地所花的時間）等等時，它確實淹沒了。然而它是可能的。對於Internet須要一些聰明和經驗，但它是確定可能的。看看今天大量的連線遊戲，從Quake III，Unreal Tournament，Counter Strike一直到EverQuest和Ultima Online。

　　現在大多數真正有長久生命力的遊戲都至少有一些連線成分。最純粹的單人遊戲容易玩一次，也許兩次，或者甚至三次若是它是很是好的遊戲，但一旦遊戲結束，就被束之高閣了。若是你想要有任何長久生命力，那麼多人連線遊戲就是形勢的核心所在，而且那意味着和Internet打交道，爲編碼者打開了那個潘多拉的盒子。

　　那麼跟Internet打交道包括些什麼呢？首先是要理解Internet是怎麼工做的，和點對點與客戶機/服務器體系結構的快速討論。點對點就是你在兩臺機器上運行遊戲，並簡單地在它們之間共享輸入。每一個單獨的遊戲假定它是正確的，並僅僅在它一幀接一幀的刷新中合併來自另一臺機器的輸入。客戶機/服務器是一臺機器有效地運行遊戲，別的機器僅僅是一個終端，接受來自玩家的輸入，並渲染服務器讓它渲染的任何東西。

　　客戶機/服務器的優勢是每臺機器都將會展示相同的遊戲，由於全部的處理都在一個地方完成，沒有跨越多臺機器，你能夠不用考慮每臺機器相互之間的同步問題。不足之處是，服務器自己須要有一些重要的CPU可用時間來處理每個鏈接的客戶機，和一個合適的網絡鏈接來確保每個客戶機及時地接收到它的更新。

瞭解IP
　　咱們都已經據說過TCP/IP（傳輸控制協議/網間協議）和UDP（用戶數據包協議），在Web網絡上有大量關於這些協議的深奧的技術資訊。實際上，在Cisco網站上有一些極好的TCP/IP指導。咱們將在較高層面上介紹一些TCP/IP的基本知識，目的是讓你更好地瞭解使用這些標準協議的網絡遊戲設計者面臨的挑戰。

　　TCP/IP和UDP/IP是兩層的通訊協議系統。IP層負責網際數據包的傳輸。UDP或者TCP層將大的數據包傳給IP，IP將數據包分割爲小的子數據包，爲每一個數據包加上一個信封，計算出目的地的IP地址，應該如何到達那裏，而後將數據包發送到你的ISP，或者無論怎樣你鏈接到網絡。這實在象是在一張明信片上寫下你要發送的，貼上郵票，寫上地址，塞進一個郵箱，它就送走了。

　　UDP和TCP是從你編碼者或者遊戲接收數據包的高層協議，並決定該如何處理這些數據包。UDP和TCP的區別在於TCP保證數據包的傳送和有序，而UDP不保證。UDP是一條直接和IP對話的小路，而TCP是在你和IP之間的一個接口。它像是在你和你的郵件之間有一個管理員助手。使用UDP你會本身爲你的信打字，把它們放進一個信封等等。使用TCP你會僅僅向你的管理員口授信稿，管理員會作所有的工做並追蹤確認信件送到了。

　　然而，全部這些使人驚奇的爲你完成的工做伴隨着代價。爲了肯定數據包經過Internet無缺無損地送到了目的方，TCP期待從目的方爲它發送的每一個數據包發回一個應答包（網絡用語是ACK）。若是它在必定時間內沒有收到ACK，它就中止發送任何新的數據包，從新發送丟失的數據包，而且將繼續這樣作直到收到目的方的迴應。當你訪問一個網頁時，咱們都已經看到了這種情形，在半途中下載中止了一會而後又從新開始了。多是一個數據包在什麼地方丟失了（假定不時ISP的問題），在任何更多的數據包被髮送之前TCP要求從新發送它。

　　這一切的問題是，在認識到出了差錯的發送者和實際上正在送達的數據包之間出現了延遲。有時這能花上數秒鐘，若是你僅僅只是下載一個文件或一個網頁，這不是什麼大礙，但若是這是一個遊戲數據包並且每秒至少有十次，那麼你真的是遇到麻煩了，尤爲是由於它中止了其餘一切事情。實際上就是這個問題因此幾乎沒有遊戲選擇使用TCP做爲它們主要的Internet協議，除非它不是一個實時動做遊戲。大多數遊戲使用 UDP--他們不能保證有序或可靠送達，但它確實很快—或者結果是至少一般比TCP/IP更快。如今咱們瞭解這些了，接下來呢？

客戶端預測
　　由於 UDP 明顯的是快速響應遊戲的方式，咱們將必須本身處理數據包的丟失和亂序。邊並且這是技巧所在。不用說出太多的代碼祕密，我就能說有方法。做爲開始，有客戶端預言，一個被談論得至關多的詞語。當你做爲一個客戶端鏈接到一個大的服務器，可是不能連貫地看見來自服務器的更新，客戶端預言開始起做用了。正在你的電腦上運行的遊戲部分看着你正給它的輸入，並在缺少來自服務器的任何棄絕信息的狀況下，對它認爲將繼續進行的事情做出‘最好的猜想’。它將會顯示被猜想的數據，而後當它獲得來自服務器的世界的最新狀態時，改正它本身，若是須要。你可能會對這個方法的效力感到驚訝。大致而言，大部分時間數據包不容易丟失—大多數時候是一秒的幾十分之一，這種狀況下游戲沒有太多的時間偏離服務器實際上認爲正在發生的事情。偏離確實會隨着時間變的比較大，大多數遊戲裏面有一個超時功能，當出現很長時間沒有來自服務器的聯絡時就中止遊戲。

　　你正在創造的遊戲類型在這裏有關係 --第一人稱射擊遊戲不須要這樣有效的客戶端預言，由於它多數狀況下僅僅處理「我在哪兒，我是否要射擊？」。在第三人稱遊戲中，你必須更加精確，所以你可以正確地預測你的角色正在播放的動畫，而且動做流暢。在這種情形中流暢的動畫是徹底必要的。Heretic II在這方面有很大的問題，而且是當它開始網絡編碼時Raven一直不得不處理的最困難的事情之一。

　　固然若是你有一個很不錯的網絡鏈接，好比寬帶鏈接，那麼這個問題就遠沒有那麼重要。對比較大的數據包有一個更寬的管道，對你的網絡連通時間更快速。事實上，寬帶對於遊戲的主要優勢不比較胖的管道多，但大大減小了延遲，特別是你到ISP的第一跳上。對於56K調制解調器，第一跳典型的延遲是100ms，這已經嚴重地增長了你到網絡上任意一臺遊戲服務器的潛在連通時間。對於寬帶鏈接好比像DSL，第一跳的延遲時間多半是20ms。使用Windows中一個叫作TraceRoute（TRACERT.EXE）的命令行程序並指定一個目標IP地址或者域名，你可以找出你的第一跳的連通時間。仔細觀察第一跳，由於這幾乎老是你到你的ISP的網絡連通時間。而且觀察你在你的ISP的網絡內部用了多少跳直到你看見在一個給定跳上列出的一個不一樣的域名。

　　請注意，寬帶並不老是能解決延遲問題。你仍然受最慢的路由器/服務器和數據包從服務器穿越網絡到達你的跳數（反之亦然）的支配。有一個寬帶鏈接確實容易緩和這些，但不可能它們最後就消失了。固然，若是你打算要運行某種服務器，你將會須要一個具備足夠快速的向上遊的數據速率的帶寬，由於僅僅一個調制解調器不可以處理一個服務器產生的負荷。

　　值得一提的是，若是你想要在PS2或者Xbox上面玩網絡遊戲，你將須要一個寬帶鏈接，由於它們二者都不支持調制解調器。

包大小，智能數據傳輸，和反做弊
　　別的必須被處理的事情是數據包的大小。若是你在一個遊戲裏面64我的都在跑來跑去相互攻擊，從一臺機器發送到另一臺機器的數據包能變得至關大，達到了一些調制解調器沒有帶寬處理這些數據的程度。這正在變得特別和那些有着很大的地表系統的遊戲有關。這裏增長的問題是，由於你有這個很好的地表系統，你可以看得很遠，所以可以看見許多其餘遊戲玩家，使得你爲了精確渲染所須要的來自服務器的數據數量以很快的速率增加。咱們能作什麼呢？

　　好吧，首先必要的是隻發送絕對必須的東西給任何給定的客戶端，所以他僅僅獲得從他的角度觀察遊戲所須要的東西。發送在他視野之外的人們的數據沒有一點意義—他將看不見這些。同時，你最好確保只發送那些每幀之間實際上發生改變的數據。若是一個傢伙仍然在播放相同的動畫，從新發送數據沒有意義。固然，若是數據包丟失時這確實帶來一些問題，但這就是爲何好的網絡程序員被支付不少金錢，來處理相似這樣的東西。

　　還有一些其餘的事情也要處理。最近已經有大量的使人苦惱的連線做弊正在發生。這是某些人修改遊戲以給他們不正當利益的地方。儘管嚴格意義上這不是網絡的一部分，但它確實發生了。有時人們會創做一些模塊，容許他們當即瞄準進入視野的任何人，或者簡單地容許他們看穿牆壁，或者讓其餘遊戲玩家看不見他們本身。大部份時間這些事情能夠在網絡層內部或者在服務器上被處理。任何有100%命中率的人被簡單地踢出遊戲，由於在人力所及的範圍內那是不可能的。

　　遊戲開發者必須盡一切可能制止做弊行爲，但很不幸，人作的東西能夠被人突破。全部你能作的就是讓做弊變得困難，當確實發生時去嘗試發現它。

　　好吧，如今就到這裏了。在第8部分中，咱們將會看看遊戲腳本系統的趣味世界，根據遊戲過程當中出現的事件來渲染或使能預先定義的場景和行爲，協助故事敘述。

第8部份:腳本系統

腳本系統
　　咱們從第七部分的遊戲網絡問題來到了腳本系統，由於其呈現的故事敘述機會，最近已經造成一種很大的遊戲元素。在一個須要以受控制的方式解釋的情景，預先編制的電影腳本是解決問題的方法。在電影中，這一般用來處理或者由主角向一個夥伴解釋情形，或者敵人對英雄解釋。固然，有其它的方法來作這件事情 --敘事者，倒敘，等等 – 但一般是使用實時情景的人們和事件來完成。固然，遊戲是不一樣的，遊戲開發者在他們日常的FPS中不該該作太多的倒敘，由於一般會須要載入新的環境或者關卡，以及新的紋理和/或模型。全部這些額外的處理和渲染能影響到主要的遊戲序列的性能。你能夠重用已經存儲在內存裏面的場景元素來倒敘，但那樣會看上去明顯比較粗陋。

　　RavenSoft 的Star Trek Voyager: Elite Force普遍利用了腳本序列產生遊戲中的事件和使用遊戲引擎自己的剪輯場景。

　　在遊戲中設計腳本情節的一個有趣趨勢是使用當前極大改進了的3D遊戲引擎本身產生剪輯場景。如今這可能像是至關地明顯，可是數年之前，當 3D圖形卡還比較簡單的時候，剪輯場景一般使用高端3D工做站製做，獲得的3D動畫而後被記錄爲一個數字視頻文件，以流式文件存儲在CD-ROM。你從剪輯場景的漂亮圖形畫面回到真實遊戲的相對粗陋的3D畫面，這是至關使人不愉快的失望的事情。但像Half-Life和 Star Trek Voyager : Elite Force這樣的遊戲很好地利用了它們本身的引擎產生全部的剪輯場景，結果是剪輯場景和遊戲之間的過渡更加平滑。

　　把腳本和人工智能區分開來多是個很好的主意。腳本是你徹底控制着一個給定場景，創建玩家幾乎老是沒有控制的事件，遊戲者‘沿着軌道’移動到一個給定地點，或者創建一個遊戲玩家須要解決的情形。一個好的例子多是巨石掉在走廊上，須要遊戲玩家找到一個新的逃脫方法。

　　現在有一些不一樣類型的腳本系統可供程序員或者美術師使用，並且它用很是有條理和邏輯的思想恰當地作這些。第一種是簡單的基於文本的，單線索的風格，就像咱們程序員習慣的編碼。在許多狀況，它實際上基於 C，儘管以一種很是簡單的形式。大量這種相似「if this，then do that」的東西。大部分腳本傾向在範圍內是至關線性的—意味着它一般由許多在次序上彼此相接的命令組成。在世界中移動角色A指向B。當完成之後，讓他講話，完成之後，移動他指向C。至關簡單的事情。

　　而後有複雜的東西--容許多重線索，和實際上容許可變情形。可變情形是當腳本開始時你實際上不能確知誰會出如今附近，可是你必須按這樣的方式編寫腳本以便任何人出如今附近它都將會工做。舉例來講--一個正常的簡單腳本會有三個傢伙，所有被預先定義，所有有一組他們將會討論的情形。一個可變的腳本將會有三我的,你不能保證是某一個特定的人，並必須按相同的方式工做。或者在一個極端的情形中，也許只有二個，或者甚至一個傢伙將會在那裏，使得三方交談有一點困難。

　　Raven在Star Trek Voyager: Elite Force中面臨的一個很大的問題是這樣的情形，使用者可能會想要把一個角色從一條船的某個地方帶到另一個地方，可是從A點到B點的路徑可能會隨着每次遊戲根本地改變。舉例來講，他們須要讓Munro(你所扮演的遊戲主要角色)從發動機艙室到輸送艙。不幸的是因爲遊戲的非直線性，在事件到達這一點之前你可能已經破壞了渦輪升降機，或者也許 Jeffries管被損害不能經過。假定當腳本開始的時候咱們不知道世界的狀態，咱們不得不爲幾乎各類可能發生的事情編寫腳本以便適用於這些‘若是。。。怎麼辦’的情形。並且它僅僅從那裏變得更加糟糕。咱們能創建的一些情形提供瞭如此多可能的組合情形，以至於爲了一個滿意的結論而準確測試每個可能發生的事情幾乎是不可能的。請和在SiN, Star Trek Voyager : Elite Force or Deus Ex中工做的任何人談談。QA部門傳統地憎恨這些類型遊戲，由於這已經使他們的工做比之前更加困難了 50倍。

　　你可以想象爲這些情形編寫腳本是何等的困難。但那是今天的非線性遊戲路徑要求的事情，並且它爲什麼博得了較多的開發支持從而可以努力實現它。

Jim Dose關於腳本系統的論述
　　去年末我訪談了JimDose--Ritual的前任開發者，如今是Id Software的一個開發者，Doom3腳本系統（和其餘一些事情）的設計者。儘管此次訪談有些久了，但仍然是頗有洞察力。

　　Jim談了腳本系統和建立一個易用且健壯的系統(與包含設計者傳統想要使用的全部特徵相反):

　　設計一個腳本系統最難的部份是知道什麼時候該中止。一旦你完成了並開始運行，你發現有許多可以利用它的系統。對於Sin，最初的主意只是要有一個比較容易的方法讓關卡設計者描述對象怎樣動態的在環境中移動。在項目的後期，咱們也使用它來讓聲音和遊戲事件與動畫同步，在多個關卡跟蹤任務目標，控制HUD的佈局和遊戲內部電腦控制檯用戶接口，描述人工智能如何對不一樣的情形產生反應，以及粒子系統。

　　控制複雜度可能也是至關的困難。當你把腳本的力量放進有創造力的人們手中時，他們開始探究他們所能作的界限。時常，他們受啓發作一些恰好輕微超出系統能力範圍的事情。很容易陷入到這種增長‘僅僅再多一個特徵’就容許他們作他們想作的事情之中。隨着語言增加，一個可能對最初的規格有意義的語言結構變得嚴重過分擴充了。在一些時候，從新思考系統變得有意義，但在那時，你可能已經積累了數量巨大的必須從新編寫的腳本。和FAKK2同樣，Sin遭受了這樣的損失。我沒有獲得對腳本系統進行大規模完全檢查的機會直到我爲Rogue's 'Alice'.重寫了腳本系統。

　　阿們，吉姆。-- Raven已經看到這個剛好在他們的ICARUS系統中出現了。ICARUS其實是一種與Jim在上面描述的相同種類的腳本系統，並且負責在Star Trek: Voyager: Elite Force中的全部腳本事件。它在Soldier of Fortune II和Jedi Knight II : Outcast中被重複使用。爲了解決系統須要處理的新問題，這些問題在最初的實現中沒有被預見/不須要，腳本系統的不少部分已經被從新編寫了。

可視化腳本系統
　　第二種類型的腳本是可視化腳本系統。使用這種方法，而不是文本文件的編碼方式，實際上你可以在真實的遊戲環境中使用真實的角色創建你的腳本。你可以追蹤角色在世界中行走的路徑，定義使用的動畫，而且一般獲得關於你的腳本實際上將看起來如何的更好的主意。它對咱們已經討論的非線性問題沒有太大的真正的幫助，但它確實能夠很快速地生成最初的腳本。

　　其次，Jim談論了可視化腳本系統。

　　可視化腳本系統確實有它們的用處，但每每實現更加困難，若是設計得不好，當複雜度上升時就容易讓開發者感到困惑。舉例來講，人工智能能夠用一個流程圖似的結構來進行可視化的設計。你能很是容易地可視化地表現人的行爲舉止方式，用盒子表明狀態，箭頭表明轉化到其它狀態，指示角色可以從一個狀態轉換到另一個狀態的方式。

　　腳本的一種一般使用是在遊戲世界中控制物體，指示他們他們如何在世界中移動。在一個編輯器中可視化地移動物體到關鍵位置並播放整個運動的能力對一個設計者可能會更加直觀。然而，它確實有它的極限，由於將須要另一個接口來設計物體在它的移動中必須做出的任何決定。那種能力是把腳本動畫片段和相似3DS Max或者Maya這樣的程序產生的動畫區分開來。

　　在一些時候，使用者可能須要一些方法決定一個腳本爲什麼沒有作他們所指望的事情。一些形式的除錯工具能使這件工做很是容易。至少，決定哪些腳本正在運行和腳本當前位置的一些方法必需的。在腳本中檢查變量，開始，中止，和單步執行的能力也是有幫助的。一般，一個程序師可以在他們的調試器中進行除錯，但這個過程要好比果有一些內建的腳本調試器可用時花費的時間更長。

　　以上就是第8部份，在接下來的章節中咱們將討論使用現成產品和定製的遊戲引擎設計工具的功過得失，而後探究遊戲控制機制，開發遊戲對象，和一些刺激有趣的事情 (武器系統)。

第9部分:現成產品與定作的遊戲引擎設計工具，遊戲特定主題

現成產品與定作的設計工具
　　咱們從第8部份的腳本引擎來到這一章節中的許多主題，咱們認爲那些鐵桿遊戲玩家和有志成爲遊戲開發者的那些人將會發現它們至關有趣。咱們將開始討論現成產品與定製的設計工具。

　　你的工具的選擇是你引擎設計的一個很是重要的部份，由於這是你將用來給你的遊戲產生內容的東西，是最耗時的部份。在這個過程當中有助於節省時間和資源的任何東西都是好的。那些不能的東西就是糟糕的。在那裏，那是容易的。

　　固然沒有那麼容易。有比這更多的事情可能會馬上被注意到。你的工具集的選擇，和從工具到遊戲的資產路徑比它聽起來更有技巧得多，並受到不少因素的影響，好比，是否適宜手邊的工做，費用，內容生產者的熟悉，市場滲透，工具支持等等。當考慮選擇現貨成品工具，或者即便當開發你本身的工具時，記得開發者實際在作工做，最好可以作須要藉助工具作的。一些現貨成品工具能在價格上達到那裏，當你陷入多個拷貝許可時，費用猛漲。

　　而後就有誘人的可能性從頭製造你本身的工具，爲你遊戲和引擎的須要而設計。這固然須要時間，和程序員大量的努力來產生在開發者友好方式中所須要的東西。快速打造基於窗口的文件轉換器是一回事情，從頭建造一個完整的關卡設計工具又是另一回事情。另外一方面，若是你確實選擇這條道路，最後你會有遊戲開發者地帶其餘人沒有的工具，所以你的東西將會看起來是獨特的。現在不同凡響是一件很是值得想望的事情，並且從羣衆這些天起突出是一件很是使人想要的事物，產生全部的競爭。

　　固然因爲內部的工具開發，你須要某人來作全部那些不可避免的小的改變和修正。但這裏真正的意義是這是可能的。使用現成的工具，工具開發者會不多由於你須要的一些特徵而改變他們的輸出文件格式。這樣你的東西最後看起來更加通用一些，不然你必須採用額外的步驟使用另外的工具來獲得想要的結果，固然會花費開發者更多的時間。

　　值得記住的是現在許多有名的3D工具已經有一段時間的歷史了，而且正在產生簡直沒有錯誤的產品，更重要的是，對他們所作的已經有必定程度的經驗了。

　　若是你選擇建造你本身的工具，多半你是，a）從新創造車輪到某種程度 b） 陷入那些建造現成工具的人們已經遇到過的相同的問題之中，只是他們已經解決了這些問題。時常人們建造一個單一特定的工具花費了至關的時間和努力，併產生了一個遠遠超出你本身的我的需求的工具。還有，他們有表明性地收編了一些你或者認爲是沒有用的，或者沒有時間本身實現的特徵。加上他們典型地有吸取特徵你或會沒有想有用,或沒有時間實現你本身.這是第三方軟件沒法爭辯的。

插件和目的建造工具
　　一般大多數的遊戲開發過程最終都是這樣的混合，本身開發的文件轉換器工具，現成的內容創造工具，和一般那些要增長一些必須的特殊功能的工具的一些附加插件。現成工具在提供你不可避免會須要的功能方面有很長一段時間了，可是正如不可避免，總有一些頗有用的，有幫助的，或者徹底必須的東西你不能獲得。一個小的插件多是一個很好的替代品，並且時常那就是所走過的路。爲特定目的建造的預處理程序也是可用的，好比把TGA文件轉換爲一個對PS2友好的格式，或者那些相關的東西。

　　若是你或你的公司打算建造某種類型遊戲的工具，那麼這些工具通常是從一個項目到一個項目地演變發展，而不是每次都從頭從新建造。若是你變換遊戲類型，很好，那些產生具備每一個多邊形命中能力的高分辨率模型的工具明顯地不是一款RTS（即時戰略）風格遊戲所必須的。

　　Gil Gribb，Rave Software的技術帶頭人，對‘現成的工具’和‘本身動手建造’的問題是這麼說的：

　　"本身開發的工具備可以根據本身產品的須要進行定製的優點，你擁有代碼，能夠修正任何錯誤或者增長任何的改進。

　　自制工具的缺點是建造和維護它們是很是昂貴的，一般成本要比現成工具高不少。在許多狀況下，因爲應用程序範圍的緣故，創建本身的工具是徹底不可能的，好比說3D建模和動畫軟件包或者位圖編輯軟件。"

　　固然，若是你想要遊戲玩家可以修改你的遊戲，並且你本身創建了全部的工具，那麼你就必需要向世界發佈這些工具。這可能會引發一點點疑惑，記住創建你本身的工具的部分緣由是你能夠領先你的競爭者。有時侯發佈這些工具的源代碼甚至可能讓你獲益匪淺，這確實提供了一種創造內容的方法。再次，Gil Gribb闡述這個主題：

　　"我是支持發佈幾乎全部的源代碼。我認爲咱們沒有任何來自咱們的競爭者的懼怕的事情，合法的業務不會想到竊取知識產權。遊戲迷，業餘遊戲製做者，以及遊戲的普及都可以從發佈的源代碼獲益。"

　　好，咱們的遊戲引擎剖析系列到這裏，固然咱們已經特別討論了許多和引擎相關的主題，下面讓咱們繼續討論一些與遊戲特定相關的部分。

遊戲控制機制
　　控制機制可以對開發中的遊戲帶來巨大的差異，有時甚至代表你正在創建的遊戲的種類或者風格。

　　嘗試在某個時候用gamepad玩一個即時戰略類遊戲--它不僅沒有樂趣。有時當你被限制在一個特定的輸入裝置的時候，例如鼠標和鍵盤，爲你的遊戲發明新的控制方法會是一個使人筋疲力盡的過程。當Raven開始開發Heretic II時他們決定作的第一件事情之一就是爲用鼠標使用第三人稱照相機嘗試和找出一個直觀的方法。在這之前，大多數遊戲採用的是Tomb Raider風格的照相機（第三人稱預兆的追逐）他們發現這時常不能正確地工做，在不少情形下會給玩家帶來挫折。照相機時常會獲得任意的視角，若是可能的話移動相機，並且有時改變玩家的方向。

　　假定他們的目標對象是FPS遊戲人羣，Raven須要找到一個對FPS遊戲玩家來講直觀的控制烏鴉座（Corvus）的方式。他們這樣作了，但確實花費了一些時間，和一些不一樣的方式—他們應當讓照相機固定在一個方向嗎，或者讓它是浮動的嗎？大多數遊戲開發努力—除非一個肯定類型遊戲的一個沒有虛飾的實現—傾向於花費一些研發找出物理控制裝置和遊戲須要的內部控制機制的最直接的合併。這裏是一個暗示—一旦你發現一個方式很起做用，就堅持下去。用這種方式控制遊戲內在的東西能把視野，直覺，甚至遊戲的焦點徹底改變成你從未想要過的東西。發現起做用的東西，證實它起做用，而後就別管它。過度設計控制會致使特徵偏離和可察覺的遊戲概念問題。

　　像這類特徵偏離的一個很好的例子能夠在Independence War中看到。這款遊戲有着如此多的模式，按鍵，等等，僅僅熟悉和操縱遊戲都不可能。

　　很明確這裏的關鍵是簡單。一個好的經驗法則是，在正常的遊戲中，若是你的遊戲須要比在普通的gamepad的按鍵或者你手上的手指更多的按鍵，那麼一些事情須要被重作。注意,我不是說一款遊戲不該該有靈活性—Soldier of Fortune一定有許多可能的按鍵設定。但一般，當你認爲它們大多數實際上都是不須要的時候Quake引擎有一個很好的方式。是的，你能夠選擇你想要使用什麼武器，但你不是必須這樣。遊戲將會自動地爲你那樣作。這就是靈活性和過分設計之間的不一樣。若是遊戲須要你按下某個鍵來選擇一個武器，那將會有問題。你理解這個了嗎？

　　控制機制不能被太高估價 --一款遊戲時常將會根據玩家以爲他們對事件或者主要角色有多少控制而得到成功或失敗。若是控制被改變，從新定向，或僅僅簡單地從他們哪兒移除，它能致使遊戲自身缺少參與，不用說，那是一件很糟糕的事情。在這上面花費時間並讓它保持簡單，將會有巨大的幫助。

實體和照相機
　　如今咱們來到了引擎不太使人愉快的部份，也是定義得最少的部分。當遊戲運行的時候，遊戲在這個部分能變得極端地多出錯，耗時間，或僅完全的極限。

　　在這裏咱們所談論的是遊戲引擎的 "遊戲"部份。這個部分使用全部的其它技術讓一些事物顯示在屏幕上，處處移動，讓它對你產生反應而且讓你對一些事物產生反應。這個系統有許多方法，但如今我將緊扣Quake的方法由於那是我最熟悉的。

　　讓咱們從實體開始。這些能夠被定義爲‘遊戲對象’。如今那不只僅意謂你在屏幕上看見的模型，雖然實體肯定地控制這些 --實體也多是其餘的事物。基本上它是遊戲在任何給定時間須要知道的任何事物，例如讓事情繼續進行的定時器，模型的碰撞檢測盒，特效，模型，遊戲玩家，等等。

　　甚至照相機均可能是實體（在幾乎全部Raven的產品中都是這樣）。照相機在世界中被分配一個有角度的原點，它們每幀都被刷新並告知渲染器應該從哪裏獲得它的視野數據，and off we go。典型地實體是爲了返回到遊戲早先的狀態而被存儲和裝載的那些東西。一般在裝載過程當中使用的方法是把遊戲地圖裝載進來，好像你正在從新開始一個關卡同樣，而後裝載全部存儲的實體，這樣他們就返回到遊戲存儲時它們的狀態。Voila，即刻返回一個存儲的遊戲。當我理解Heretic II的方法時這並非那麼的容易—裝載/存儲幾乎比其餘任何事情帶給個人問題還多，特別是在協做模式。

照相機有許多形式：

　　自由形式：照相機能去任何地方
　　腳本：照相機能夠沿着一條設定的路徑前進
　　遊戲時間：照相機有必需要遵循的定義的行爲

　　僅僅說"嗯，我將僅僅跟隨主要的角色"是不夠的。這意謂你也可能須要讓照相機穿過牆壁，或讓它按一些方式移動以至甚至引發一些胃的噁心。讓它沿着一些定義的上下運動路徑前進也有益處，如同任何玩Descent遊戲超過一小時的人能夠告訴你的同樣。身體和頭部習慣於上下是一個靜態的變量，並當它不是時，他們不喜歡它。製做Quake 1的 Mike Abrash，曾經告訴我即便當它被定義，他仍然處理的麥可 Abrash 地震 1,曾經告訴我即便當它被定義,他仍然從他們正製做的遊戲感到運動噁心。他提到，對於他來講，離開製做Quake 1一年時間才讓他的胃安定下來。啊哈，咱們所做出的犧牲。

武器系統
　　遊戲模塊的另一個部份是武器系統。大多數的遊戲有武器系統或相似的東西。 這是在世界中影響其餘的物體，並且使他們對給定情形產生反應的東西，--好比說被射擊。一般武器系統由許多不一樣的類型組成；攻擊掃描，基於飛彈的，以及範圍形式。

　　攻擊掃描是直接攻擊武器。在屏幕上他們產生的效果只是那樣，一個效果。當使用它的時候，和武器的實際操做沒有任何關係。當你用手槍開火時，子彈被認爲當即穿過世界並直接擊中在它運動軌跡上的任何人/事物。

　　基於飛彈的武器有一個佔用有限時間穿越世界的真實射彈，從而帶給對方一些能夠躲避的時間。

　　基於範圍的武器像手榴彈和炸彈同樣的東西，沒必要擊中就能夠傷害到你；你只是必須處於爆炸範圍內。處在那種爆炸範圍內的玩家受到飛濺損害。熔岩是另一種形式的基於範圍的武器。

　　那麼你如何決定什麼被擊中而什麼沒有被擊中呢？很好，這個問題把咱們帶到了追蹤，咱們將在接下來的物理學和人工智能章節更多的接觸追蹤。這是一組函數例程，當給定世界中一條從A點到B點的直線時，好比從槍的末端到預先定義的距離，它告訴遊戲什麼被擊中。追蹤很棒，但很昂貴，由於他們必須對那條線上的全部多邊形進行‘碰撞檢測’來看是否有什麼地方被擊中，更不用說模型和其它對象了。這也是一些物理學的工做方式，從一個給定的角色作一個筆直向下的跟蹤能夠知道地板位於什麼地方。肆意的濫用追蹤 — 如，在遊戲的一幀中屢次使用它們 -- 對於今天許多遊戲的速度降低是有責任的。在Jedi Knight II：Outcast，他們的光刀戰鬥已經遇到了這個問題，由於他們不只須要知道光刀是否擊中了某處的什麼和它如今的位置，並且對於它們之間的全部點都得這樣，他們對光刀作了屢次追蹤。

　　好吧，又一個章節結束了，僅僅剩下兩個章節了。下面咱們介紹人工智能和搜索的更多細節。

第10部分:人工智能和導航（路徑發現）

人工智能（AI）（終於到了遊戲的重點部分......）

　　咱們上面已經用了其餘九個章節介紹了遊戲引擎，如今讓咱們深刻到很是有趣和重要的人工智能主題。人工智能現在正在變成被談論得最多的僅次於遊戲引擎渲染能力的遊戲開發領域之一，確實如此。直到大約兩年半之前，遊戲彷佛主要是在考慮你可以渲染多少個多邊形，眼睛是多麼的漂亮，和…好…勞拉的胸部是多麼的有彈性...既然咱們如今已經可以渲染出很是真實的乳房，中心就開始轉移到咱們實際上用那些多邊形作什麼了（即玩遊戲）。由於它給你提供實際玩遊戲的刺激做用和參與遊戲世界中正在進行的事情，因此人工智能在這個領域很是關鍵。

　　人工智能包括了所有的東西，從在Tetris中決定哪一塊新磚頭掉落（這很大程度上知識一個隨即數產生器），一直到創造基於小組的策略遊戲，這些遊戲和你交互，而且實際上在你玩的時候向你學習。人工智能包含了許多規則，若是你（做爲一個遊戲開發者）沒有花費足夠多的時間讓它正確地工做，它會反過來在你屁股上咬一口。因此讓咱們談論一些哪些規則？這樣你能更好地理解人工智能系統會確實是多麼的複雜。爲了不法律上的糾紛，咱們將使用一個假設的遊戲而不是一個真實的遊戲做爲例子。

　　假設咱們的遊戲中有壞份子生活在3D世界中，幹着他們的事情，並且若是你打攪了他們的正常次序他們就會反抗你（玩家）。你必須決定的第一件事情就是他們正在從事的究竟是什麼事情呢？他們正在守衛什麼東西嗎？在巡查？在計劃一個聚會？在購買食品雜貨？在整理牀鋪？創建行爲的基線是遊戲開發者的工做之一。一旦有了這個，你就總有NPC（非玩家角色）或計算機控制的‘人’可以恢復去作的事情，玩家與他們的交互就應當能被完成。

　　一旦咱們知道一個NPC角色須要作什麼 —好比它在守衛一扇門，而且在這個區域小巡邏，NPC也必須有‘世界意識’。遊戲設計者須要決定NPC的人工智能將如何看見世界，和它的知識範圍。你將會僅僅說「計算機知道正在進行的每件事情」嗎？這一般被認爲是一件糟糕的事情，由於很是明顯計算機可以看見和聽見你不能看見和聽見的事情，這被當成是在做弊。不是一種有趣的經歷。或者你將模擬他的視野，這樣他只可以對他能看見的事物做出反應嗎？當有牆壁出現時這裏就有問題了，由於你開始進入那些我在第九部分提到的‘追蹤’例程，看看NPC是否試圖對被牆壁擋住的人做出反應。這是一個很明顯的人工智能問題，可是當涉及到門和窗戶時，這個甚至變得更加複雜了。

　　當你開始爲AI刺激例程增長聽覺意識時，這依然變得更加複雜了。可是，這個意識是那些關鍵的「小事情」之一，這些使得假想的遊戲世界彷佛更加真實，或者可以去除懷疑的懸念。若是你碰到過這樣的事情，請舉手：你在槍戰中跟一個NPC交戰，免除了一個NPC，你繞着角落行走並遇到了另一個NPC依然保持他的缺省行爲模式，沒有意識到剛剛發生的事情。如今，槍是嘈雜的事物，槍戰可能已經明顯地提醒了一個「傾聽」的NPC有些事情正在進行。避免這種事情的技巧在於找到一個有效的方式來決定聲源（即你武器的發射）的距離是否足夠接近到NPC可以聽見。

　　接下來就是決策例程。當咱們的巡邏NPC角色可以聽到但不能看見某物時，你試圖實現什麼樣的行爲呢？他去尋找它嗎？不理睬它？你如何決定什麼是重要的聲音他應該去或者不去調查？如同你看見的同樣，這會很快變得很是的複雜。有不少方法來建造處理這些事情的代碼，但一般這樣是一個好主意，創建一個不是對特定的NPC而是對全部的NPC都起做用的系統，該系統基於你可以在遊戲引擎之外的文本文件中創建的屬性。這樣就不須要程序員爲一個給定的角色而改變AI，而且若是你對遊戲代碼作了改動，它將當即自動地應用到全部的角色，這在大多數狀況下是一件好事情。

　　其餘的世界意識問題會冒出來，好比這樣的情形，兩個守衛彼此緊挨着站立，你用狙擊武器幹掉了一個，而另一個站在哪兒徹底不知已經發生的事情。再者，遵照真實世界行爲的細節是一款好遊戲和一款偉大遊戲的之間的區別。

　　讓咱們說你已經把全部的刺激-響應部分準備好了—你已經掃描了世界，決定NPC應當對正在進行的一些事情做出反應—他聽到了玩家角色發出了聲響—而且你（遊戲開發者）決定了他應當對這個作些什麼—他將去調查。如今更加複雜的事情來了。他如何離開如今的位置，到達他認爲發出聲音的地方，而不會想一般的數字傻瓜同樣跑到牆壁裏面，碰到傢俱呢？繼續往下看…

有關正確的路徑 --- 世界導航
　　快速，準確的世界導航( 也叫作路徑-發現)近來已經成爲遊戲開發者的聖盃。 讓它看起來很是信服是一件很是困難的事情。你須要有局部世界的地理知識—牆壁的位置，臺階，懸崖和建築物等的邊緣。你也須要世界中的對象的知識—好比傢俱，汽車，尤爲是其餘人的位置。真正最後的因素是問題所在，一下子咱們將回到這一點上。

　　世界導航一般被分爲兩個領域，世界導航和局部導航。兩者實際上只是範圍上的區別，但大多數的程序員分別對待它們，由於這樣處理起來容易一些。世界導航例程處理理解房間，門和通常的地理學，並計算出讓玩家或者角色從世界中的A點到達B點的一條路徑。「它將讓你從A點到達B點」，這是一句很容易說的話，不是嗎？提及來容易，但作起來很困難。理解世界是一個很是複雜問題，我已經看到過許多嘗試過的解決辦法。QuakeIII的機器人遵守建造的預先處理過的地圖，通常的說法，使用原來地圖的地面。預處理器檢測地面元素，由地圖建造者做上標記，並本身建造一個只使用地面的世界簡化地圖。機器人並不關心牆壁，由於他們從不接近它們，就像他們遵守地面的地圖同樣，設計上已經把避免牆壁構造在裏面了。

　　其餘方法在地圖自己裏面建造一些小的結點，AI能夠追隨它們。這些結點一般被建造在彼此的視線裏面，有從一個結點到其餘全部結點的鏈接，角色AI可以直接‘看見’，因此你就確保了從一個結點移動到另一個結點時AI不會試圖穿越牆壁。若是有門或者降落物，你可以事先用這些結點對路徑的信息編碼，因而NPC可以採用適當的行爲—等候電梯，打開一扇門，或者從一點跳到另一點。這其實是HereticII使用的系統，也是Raven在他們其餘的大多數遊戲中使用的系統。

　　關於這個主題，3D Realms的Jess Crable，如今爲Duke Nukem Forever工做，如是說：

　　"導航在許多方面是個巨大的挑戰，主要是當遊戲中有大量正在發生的事情和一些非計劃性的東西，好比障礙。爲了不和（或）真實地對非計劃性的障礙物導航（例如像另外的AI），AI須要很好地知道正在它周圍發生的事情。比較而言另一個巨大的挑戰就是真實感。若是AI正在表現玩家在實際生活中看到的一些東西，好比說一我的，或者一條狗，那麼讓它看上去真實可信就更加困難。"

　　而後就是局部導航。咱們可能有一條路徑讓咱們的 NPC從他在世界中的位置，移動到他認爲聽到聲音的地方，但你不能盲目地按照這個執行並指望獲得看起來不錯的結果。這種性質的路徑傾向於很是特定於一個給定的目的。當你沿着走廊從一個房間跑到另一個房間時，它很好，但若是你試圖指導他穿越一個巨大的房間時，路徑結點方法容易最終獲得一些看起來很奇怪的發現路徑。這些路徑也不是動態的。由於他們被預先建造，他們不容易考慮到世界的任何動態變化。桌子可能有被移動過了，椅子被破壞了，牆壁被摧殘，固然，人們會移動。這就是局部導航不一樣於世界導航的地方。它必須考慮局部世界並導航NPC在裏面穿越。它必須知道周圍的環境，存在哪些能夠選擇的路徑，並決定選擇哪一條。

　　在局部導航中最大的問題是其餘的NPC。給定一個發現路徑的具體例程，若是你在相同的通常區域中有不止一個NPC，他們都試圖到達世界的同一地點，結果是他們都很是容易有相同的路徑。而後他們試圖沿着這個路徑行進，結果彼此遇到一塊兒，而後花費他們全部的時間試圖將彼此分開，而且一旦成功地分開了，他們再次試圖到達目標，而後咱們又再次看到一樣的事情發生。這一切看起來都是很是的愚蠢，這不是大多數人想要的效果。因此須要一些路徑發現中的變化來避免這種情形，須要一些妥善處理避免的代碼。有大量可以幫助解決這種情形的算法。

人工智能和角色動畫問題
　　固然，當角色本身在世界中行走時你必須徹底地決定你想要角色播放什麼動畫。聽起來無足輕重？不是的。關於這個主題，Raven的 Chris Reed—Soldier of FortuneII使用名爲LICH的AI系統的如今的負責人—如是說：

　　"此刻我能告訴你，咱們在平滑移動上正有着最大的困難。在一個多丘陵的長滿草的叢林中試圖讓五個角色在彼此附近行走是一個很是困難的問題。讓底層系統完美是重要的，由於除非角色在較低層次上（避免牆壁，適當的動畫）看起來真實，他們不可以有效地表達任何較高層次決定的智能。因爲這個單獨的緣由，動畫和底層的移動是最重要的和最難實現的。它確實須要完美。"

　　所以咱們已經讓咱們的角色從A點到達了B點，他本身穿越世界，在途中避免障礙物，正確播放動畫，如今到達了這裏。他看見了你。接下來作什麼呢？很明顯更多的是做出決策。他將向你射擊。太棒了。你迴應射擊。如今幹什麼？當他試着逃走的時候，如今你再次經歷所有一樣的事情。

　　爲了讓這些情形看起來使人信服，你看見了這裏必需要處理的大量問題。若是你創建你的AI使用沒有動畫的行爲讓NPC執行，這能被混合。一些Soldier of Fortune中的AI就是這樣的例子。他們受到了指責，由於壞傢伙沒有以適當的方式對刺激做出反應。當他們明顯應該這樣作的時候，敵方NPC不掃射，或者不逃跑。部分問題是他們沒有掃射敵人NPC的動畫，或者讓他們往回跑，由於空間的問題。所以世界上全部最偉大的AI代碼都不可以解決這個問題。這是全部要考慮的重要事情。

　　想知道隱藏的難點嗎？看看我前面全部的描述，而後試着將它應用到一組NPC上，這些NPC彼此必須說話，設定目標，彼此溝通，但不妨礙彼此的方式。一旦你這麼作了，試試那些代碼，做爲玩家的隊友作上面所描述的這些，然而不要在槍戰中妨礙他。如今這是複雜的。而後這成爲樂趣。這是最困難的部分。Raven的 Chris Reed關於AI‘感受’的一些評論：

　　"我認爲反饋是AI的一個極大的問題。若是角色對於他周圍環境的變化不產生反應，遊戲的真實感就被徹底打破了。這有許多明顯的例子(聽見槍炮聲，看見同伴被擊中...)，以及一些更加微妙的事情(當兩我的經過門廳時看着彼此並點頭致意)。玩家是樂意接受一些生硬和可預測性的，可是這些事物容易把遊戲帶到現實生活。"

　　而且Jess Crable贊同：

　　"平衡是很是重要的…對玩家將會有多大的樂趣相當重要，但還有其餘的問題要平衡。遊戲玩家時常說他們想在遊戲中看見更加真實的人工智能。然而，太多的真實感開始把樂趣帶走。在這二者之間必需要有一個好的平衡。變化和隨機一樣也很重要—行爲的變化，和保持在可信範圍內的必定程度的不可預測性。"

遊戲規則與天然發生的遊戲
　　在咱們關於AI的全部描述中，咱們採用的是FPS的方式。有不止一種的AI。咱們已經描述的是處理3D世界一組規則。AI遠遠不止這些。時常最好的AI實際上很是的簡單。它就是一組規則，玩家必須響應和處理的響應（或開始）動做的規則。

　　這裏應當處理一個被稱爲「天然發生的遊戲」的專業術語。天然發生的遊戲本質上創造遊戲將遵照的規則，那將會形成遊戲程序員不能預見的情形。

　　舉例來講，象棋能被認爲是天然發生的遊戲。有一組規則，但遊戲可以陷入各類程序員不可以以個別方式處理的情形。你不能爲每一種可能的棋局情形編碼規則。很清楚，遊戲玩家每次不會老是面臨相同的遊戲情景。必定程度上，進行中的遊戲情形會根據他的行動而發生變化。Black and White是這種情形的一個完美的例子，和The Sims同樣—遊戲有它本身的規則，但你如何運用和調和他們是你本身的事情。實際上，你在玩遊戲的過程當中創造着遊戲，而不是照着遊戲設計者/程序員已經爲你定義的路線進行。

　　有可能把基於規則的，天然發生的遊戲方式和FPS環境混合在一塊兒。Half Life中的一些海軍陸戰隊士兵的行爲就是這樣作的—壓制火力和側翼攻擊從設定的規則中動態完成。它看起來是動態的，並且必定程度上它是這樣。然而，在FPS世界中僅僅有一組規則時常是不夠的。幾何和其餘AI時常可以戰勝簡單的規則，這讓保持正確並依然有趣變得更加困難。因此對那些可憐的AI程序員有一些同情心吧。他們的工做不容易。

　　好吧，下面還有一個章節，僅僅還剩下一個章節了。在最後的章節裏，咱們將討論頭頂顯示，菜單系統，遊戲定製和配置，遊戲引擎版權與建造，最後是遊戲「mods」。

第11部份:最後的章節

前端
　　你已經看到了菜單系統，你可能理解遊戲內的頭頂顯示（HUDs）時常是遊戲經歷中被忽視和誹謗的部分。最近，這個領域開始被給人印象很是深入的Black and White所關注，這款遊戲實際上沒有HUD。在PeterMolyneux經歷了DungeonKeeper之後，它在屏幕上大量的圖標，他決定遊戲的大部分被這些圖標占用了，主要的屏幕沒有被足夠利用。所以他決定廢除全部這些東西。Peter邁了大膽的一步，咱們爲你喝彩。很不幸，這種方式適用於B&W這類風格的遊戲，但它並不老是對其餘種類的遊戲有用。

　　大致而言HUDs應該是不引人注意的，只提供你須要的關鍵信息；這自己會在設計團隊中引起爭議。Soldier of Fortune的最初設計在屏幕上有一個圖標，當被擊中時向你準確顯示身體的哪一個部位被擊中。當他們決定他們不許備爲不一樣身體部位的傷害而處罰玩家時，最後這個被丟棄了。在一些早期的Soldier of Fortune的屏幕截圖上，依然可以在屏幕的右上角看見這個圖標。

　　在一個完美的世界中HUD是可配置的，所以你能決定顯示什麼，在哪裏顯示，顯示多久。若是你以爲不須要局部雷達，那麼它應當能夠被移除掉。任何顯示的HUD信息應當有必定程度的alpha（透明度），所以若是須要你能透過它們看見後面的事物。

　　說到配置，我是一個遊戲我的設定的十足的狂熱者。由於沒有即時存儲設備存儲配置文件，在遊戲機遊戲上不是普遍地能夠得到配置，這足夠公平。可是隨着PS2和Xbox硬盤驅動器的來臨，我期待在未來看見配置被更多地使用。可以被定製的每件事物都應當這樣，如同我看見的同樣。很明顯，也應當爲每件事物提供合理的缺省配置，所以玩家沒必要一屏一屏地進行枯燥的選擇過程---一下子咱們將更多地討論這個---玩家應當可以根據我的的喜愛和可得到的計算能力定製遊戲經歷。

　　回到缺省事物，保持必需的修改最小化很是重要。做出最少的決定而快速進入遊戲老是一件好事情。Mortal Kombat，甚至QuakeIII都有一個很是快速的遊戲進入系統。少量選擇，而後你就進入遊戲了。這並不意味着你不能有一個接一個的菜單容許你改變每件事物，但它們不該當是必需的且應當已經有合理的缺省設置了。若是甚至在你進入遊戲之前你必須用14個屏幕設置一個角色，多是第一次你可能沒有關於你正在選擇的線索並且僅僅會作任何事情以經過屏幕，可能作了一些會極大影響初始遊戲體驗的事情。並且有可能它將會是不利的影響，做爲一個遊戲程序員/設計者，我在這裏告訴你不管你作任何事情，讓玩家第一次選擇一些愚蠢的事物，無需讓它更糟糕你就會有足夠的機會製造不好的第一印象。

　　藉由關於配置和HUDs（連同前面十個章節的大量信息）的簡要論述，咱們最終結束了關於現代遊戲引擎的主要建造元素的討論。固然，依賴於遊戲的類型和誰在製做它們，每一個特定的遊戲對這個清單有它本身的添加（或者減小）。然而，有一些對於遊戲引擎實際上不是引擎設計部分的其餘元素，可是它們卻須要一些關注。

遊戲引擎許可與組件
　　現在若是你要製做一款遊戲，時常最快的開始方式就是購買現有的遊戲引擎許可證並在此基礎上開發---這就是Raven所作的事情，最近使用Quake3引擎編寫了Star Trek Elite Force。Half Life基於Quake 1引擎，Deus Ex基於Unreal，這個清單還在繼續。現在有兩種許可證方式---一個徹底的遊戲引擎（或遊戲操做系統如Jason Hall授予LithTech），或者一組給定問題的部分解決方案。這方面一個好的例子會是RenderWare，這是一個渲染場景的部分解決方案並給你提供一些物理。你不能僅僅拍着一些模型並把它們稱爲完成了的遊戲---還須要有聲音系統，遊戲機制，等等。但它確實給了你一個創建遊戲的堅實基礎。還記得我在渲染和物理學章節提到的全部數學知識嗎？很好，這樣你就避免了全部那些東西。

　　藉由LithTech，Unreal和Quake，你確實獲得了徹底的解決方案--或至少是創始者爲他們的遊戲所須要的所有解決方案。記住QuakeIII是能夠多人玩的，不時創建在單人遊戲的基礎之上的好比說Unreal Tournament。使用QuakeIII，你失去了單人遊戲需用的某些系統，像讀取/存儲，腳本等等。你只是的到了Id公司製做一款遊戲須要的東西，而不必定就是你所須要的東西。有時侯若是系統的一個侷限剛好是你所須要的東西時，這多是一個真正的缺點。給Star Trek Voyager加入讀取/存儲和腳本：EliteForce不是野餐，可是必須的。然而，使用Quake3引擎依然是領先的開端。

　　Unreal有名的TimSweeney對於今天一些流行的預先打包的遊戲引擎解決方案有一些評論。

　　"我認爲我能公平地比較遊戲引擎(Quake，Unreal等)和遊戲組件如 RenderWare 和 Karma。遊戲引擎是包含遊戲開發的全部技術方面的組織嚴密的框架：渲染，編輯工具，物理學，人工智能，網絡，等等。

　　它們針對那些想要一個徹底的，現成的解決方案的開發者，以便他們可以把精力集中在遊戲可玩性和內容上。像RenderWare這樣的遊戲組件針對那些正在開發他們本身的技術但不想在一些已經很完善的技術領域作重複開發的開發者。

　　遊戲引擎有解決遊戲開發中所有技術問題的優勢，有容易把一些包括遊戲類型的假設創建在裏面的缺點。舉例來講，Unreal已經被用來製做第一人稱射擊遊戲，第三人稱動做遊戲，角色扮演遊戲，甚至彈球遊戲。可是沒有人用它製做飛行模擬類遊戲—它不是適合這種遊戲的技術。遊戲引擎帶着完整的源代碼而來，這是祝福 ( 你能徹底看見內部正在發生什麼，你能夠自由地根據你的須要擴充它)，也是詛咒 (若是你改變它，你將必須把變化合並進新的版本以內)。

　　遊戲組件有解決所關注領域的技術問題的優勢，如渲染或者物理學，不用花費大量的時間在這方面就能夠比典型的開發者作得更好。他們的缺點是把這些組件整合進你的引擎其他部分就是你本身的事情了，這有時候會至關複雜。遊戲組件通常沒有完整的源代碼伴隨，所以並不老是很清楚他們內部作了些什麼。"

　　謝謝Tim，很精妙的分析。

創建你本身的遊戲引擎?
　　你可能創建本身的引擎而不是購買許可證。這避免了誰擁有什麼，版稅等全部的法律糾紛，並且若是你產出了質量足夠好的東西，你甚至可以向別人出售許可證。然而，正如已經指出的那樣，這須要時間和金錢來完成，更不用說絕對優秀的程序員了。LithTech已經發展了不少年，與Unreal相似。頗有趣，主要是由於變化的硬件和API版本，實際上Unreal最初的版本花費了四年時間才完成。當他們剛開始的時候，軟件渲染是惟一的遊戲。當開發正在繼續的時候，3dfx帶來了Glide，而後是Nvidia的TNT顯卡（從那時起硬件和APIs確實有了更多的進步）。這就是它爲什麼支持這麼多不一樣的渲染途徑的緣由。固然在一個相同的引擎內支持全部這些是一場編碼惡夢，但那是另外的事。每一個引擎有模塊化的方式，而且當一個模塊---好比說，腳本---變得過期了或者需求變化了，你只須要把它抽出來並開始作一個新的模塊。

　　Quake引擎經歷時間有更加完整的進化發展。相應於Id公司下一個遊戲的一組需求，當John Carmack創造了在當時的硬件上運行最快的東西時，引擎的每一個版本都通過了徹底的重寫。QuakeII徹底重寫了很多於四次，我我的看到了QuakeIII的機器人代碼的三個不一樣的版本。其餘的開發者也沒有可以避免這種情形。John Scott，建造了Soldier of Fortune II的地表系統，曾對我提到，在動態地表生成上他曾嘗試了許多方法讓物理學正確地工做。

　　建造技術或者完整的引擎不是件容易的事情。當今的遊戲引擎須要許多，許多的系統，就如同許多人們嘗試創造‘下一個大的引擎’時所發現的那樣，從屏幕上文本的簡單顯示到高級人工智能。而且如我前面提到的，不斷髮展的新技術使得建造一個快速，高效的引擎是一個變化的目標。事實上，我見到有人僅僅爲了讓一個帶alpha的紋理正確地顯示而在PS2的混合模式上花了四天時間。

　　值得考慮的其餘引擎有GarageGames的Tribes2引擎---被稱爲TheTorque Game Engine。個人理解是它能夠收取微小數量的許可費用，未來有一些版稅協議。這是的確值得考慮的事情。你能夠在這裏看到這個引擎的特徵細節http://www.garagegames.com/index.php?sec=mg&;mod=v12&page=features。而後就是SeriousSam 引擎。這也是須要許可證的，的確值得看一看。若是你對它有興趣的話，能夠聯繫God Games---他們應當能夠給你指明正確的方向。

　　在網絡上有一些你能夠下載的自由引擎---首先想到的是Crystal Space引擎。你能夠從這裏下載http://sourceforge.net/projects/crystal，並在你的遊戲中隨意使用。這不是一個專業的引擎，但看看全部的部分如何結合在一塊兒時常是一個好的學習經歷。

　　還有就是最初的QuakeEngine，如今已經被Id公司開放源代碼。對於任何有抱負的遊戲程序員來講這是一個很好的開端----下載它，編譯，開始調整。值得記住的是，這個擎是許多年之前的了，與Quake III或者新的Doom沒有多少類似性。重複一遍，它確實是個好的開始。你能從這裏找到發現好的資源網頁http://www.inside3d.com/qip/home.shtml。

　　確實，這一切都是時間與金錢的事情。若是你沒有時間開發一個新的引擎，就不要介意花錢使用第三方的引擎，去購買一個吧。注意，對於要求使用他們引擎的團隊，現在大多數引擎許可團體有很合理的途徑。儘量地讓許多人們使用他們的技術，所以這種經驗變成了工業標準，這對他們有好處。

‘Mod’社區
　　看一眼任何在線遊戲服務器的統計數字，顯示出Counter Strike服務器比任何其餘遊戲服務器都要多。和它最近的競爭者（Quake III或者Unreal Tournament）相比，幾乎有兩倍的CS服務器。

　　遊戲mods 所有來自於一些編輯程序，這些程序讓遊戲者可以修改DOOM最初的.WAD文件，提供他們本身自家制造的關卡設計和紋理。人們開始玩這些(大體)自家建造的工具，而且也發現了他們能夠產生其餘人想玩的關卡。Id注意了這個趨勢，並且將Quake系列引擎帶到了一個新的階段，這樣設計遊戲，使得遊戲是用戶可修改的。他們甚至發佈他們本身的設計工具，指令，並且甚至---喘口氣---遊戲中的代碼，如此有抱負的遊戲程序員能夠在Quake Universe中玩。你可能從這個創造出本身版本的Quake連線經歷。許多今天的業內大師來自這種早期的修改經驗。如今有名的設計者如LevelLord和CliffyB在這個行業中就是這樣開始的。最高的榮譽來自一位名叫ZOID的紳士，他提出了3Wave CTF，第一個‘奪取旗幟’的遊戲，遊戲中須要人們組隊---連線遊戲從純粹的死亡競賽以來的第一次進化發展。

　　一些遊戲是如此的流行以至於他們每一年都有事件發生。好比說，Quake有一個QuakeCon，在Mesquite Texas，Id軟件公司所在地，舉行的一年一次的quake大會。人們帶着他們的PC來到這裏，或爲了看最新的mods或是展現的基於Quake引擎的遊戲。

　　現在你製做的任何遊戲須要或者有殺人者可多人玩的經驗，或者有能夠很是容易修改的內容這樣連線‘修改者’能利用你的遊戲並製做出其餘遊戲來。這一切延長了你遊戲的生命，有但願賣出更多，人們購買它，能夠下載mods來玩最新的Quake III修改版本：The Teachers Strike Back。但你不能僅僅生產一款遊戲，發佈你的工具，就袖手旁觀。實際上你最初必須把代碼設計成不須要程序員就能夠容易地擴充, …好吧, … John Carmack。

　　做爲一個開發者，你須要在那裏能夠見獲得，併爲那些在家中想利用你的遊戲和用它作點別的什麼的人們提供經驗和幫助。這種支持能夠有許多形式----一個親切友好的詞語，一段代碼，建議，宣傳或只是金錢。只要有這個它時常不介意採用何種形式。

　　在這裏你選擇哪一個第三方工具用來建造內容多是相當重要的。在Raven，過去咱們已經作了一些開發決定，在這方面沒有什麼幫助，因爲咱們爲大多數的建模和全部的動畫需求使用了SoftImage。雖然它是製做咱們須要的動畫的最好工具，對於家庭業餘愛好者來講它太過昂貴了。這就給那些家庭業餘愛好者在擴充咱們製做的內容時帶來了問題，所以他們容易拋棄咱們轉而尋求那些比較容易製做內容的遊戲。在建造或者選擇一個引擎時這確實是值得留意的事情。爲了響應制做遊戲mods，Discreet在市場上發佈了一個3D Studio Max的‘lite’版本，稱爲gmax。最好的是，它是免費的。若是你想要試一試，你能從這裏抓取它http://www.discreet.com/products/gmax/gmaxconsumer/index.html。

　　最後在線遊戲的成功時常能追蹤到 mod 社區，所以我認爲感謝他們作了件好的工做是公平的。我過去時常說，在行業中到達一個‘真正的’工做最快的方式是從一個mod開始，說明你有完成它的訓練並用它做爲一個面試得到者。不能說，"我能作這個"就像已經完成了同樣。所以去到那裏並開始吧。你損失什麼了嗎？

有關做者 　　JakeSimpson 是一個遊戲程序員，斷斷續續在這個行業已經有大約20年了。他在英國本土從15歲開始，在C64的時代，Sinclair Spectrums和 BBC Micros，經歷了 Amiga和ST，離開了一段時間，而後90年代中期至後期在MideayGames寫街機遊戲。他最近在RavenSoftware工做過，製做有Soldier of Fortune， Heretic， Hexen， Star Trek : Voyager : Elite force和 JediKnight II : Outcast，在北加州的Maxis能夠找到他，爲Will Wright的遊戲產品工做。業餘時間他爲GameBoy Color和Advance編寫代碼，由於「你能儘量地遠離C++編碼，並且，如同John Carmack所說，底層編程對程序員的靈魂有好處」。