• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            實時陰影繪制技術研究

            C++博客 首頁 新隨筆 聯系 聚合 管理
              48 Posts :: 20 Stories :: 57 Comments :: 0 Trackbacks

            原文作者:Jake Simpson
            譯者: 向海
            Email:
            GameWorldChina@myway.com
            ------------------------------------------------------------
            第1部分: 游戲引擎介紹, 渲染和構造3D世界


            介紹
              自Doom游戲時代以來我們已經走了很遠。 DOOM不只是一款偉大的游戲,它同時也開創了一種新的游戲編程模式: 游戲 "引擎"。 這種模塊化,可伸縮和擴展的設計觀念可以讓游戲玩家和程序設計者深入到游戲核心,用新的模型,場景和聲音創造新的游戲, 或向已有的游戲素材中添加新的東西。大量的新游戲根據已經存在的游戲引擎開發出來,而大多數都以ID公司的Quake引擎為基礎, 這些游戲包括Counter  Strike, Team Fortress, Tac Ops, Strike Force, 以及Quake Soccer。

            Aliens vs. Predator 2


            Tac Ops 和Strike Force 都使用了Unreal Tournament 引擎。事實上, "游戲引擎" 已經成為游戲玩家之間交流的標準用語,但是究竟引擎止于何處,而游戲又從哪里開始呢?像素的渲染,聲音的播放,怪物的思考以及游戲事件的觸發,游戲中所有這一切的幕后又是什么呢? 如果你曾經思考過這些問題, 而且想要知道更多驅動游戲進行的東西,那么這篇文章正好可以告訴你這些。 本文分多個部分深入剖析了游戲引擎的內核, 特別是Quake引擎,因為我最近工作的公司Raven Software已經在Quake引擎的基礎上開發出了多款游戲,其中包括著名的Soldier of Fortune 。


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

              對于曾經看過 Quake 游戲結構的人來說, 游戲引擎就是 Quake。exe ,而游戲部分則是 QAGame。dll 和 CGame。dll 。 如果你不知道這是什么意思, 也沒有什么關系;在有人向我解釋它以前, 我也不知道是什么意思。 但是你將會完全明白它的意思。 這篇游戲引擎指導分為十一個部份。 是的, 從數量上來說,總共是十一個部份! 每個部分大概3000字左右。現在就從第一部分開始我們的探索吧,深入我們所玩游戲的內核,在這里我們將了解一些基本的東西, 為后面的章節作鋪墊。。。


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

            Let it Snow



              什么是渲染器,為什么它又這么重要呢?好吧,如果沒有它,你將什么也看不到。它讓游戲場景可視化,讓玩家/觀眾可以看見場景,從而讓玩家能夠根據屏幕上所看到的東西作出適當的決斷。 盡管我們下面的探討可能讓新手感到有些恐懼,先別去理會它。 渲染器做些什么?為什么它是必須的?我們將會解釋這些重要問題。

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

              如今,在屏幕上生成像素,涉及到 3D 加速卡, API ,三維空間數學, 對 3D 硬件如何工作的理解等等。對於主機(游戲機)游戲來說,也需要相同類型的知識,但是至少對于主機, 你不必去嘗試擊中一個移動中的目標。 因為一臺主機的硬件配置是固定的 "時間快照", 和PC(個人計算機)不同, 在一臺主機的生命期中,它的硬件配置不會改變。

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


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

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

            3D computer image


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

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

              在一個好的引擎中,渲染器應該是可以完全被一個新的渲染器替換掉, 并且不需要去改動游戲的一行代碼。許多跨平臺引擎, 而且許多自行開發的游戲機引擎就是這樣的,如 Unreal 引擎, --舉例來說, 這個游戲 GameCube 版本的渲染器就可以被你任意的替換掉。

              讓我們再看看內部的表示方法—除了使用坐標系統,還有其他方法可以在計算機內存里表示空間的點。在數學上,你可以使用一個方程式來描述直線或曲線, 并得到多邊形, 而幾乎所有的 3D 顯示卡都使用多邊形來作為它們的最終渲染圖元。 一個圖元就是你在任何顯示卡上面所能使用的最低級的繪制(渲染)單位,幾乎所有的硬件都是使用三個頂點的多邊形(三角形)。 新一代的 nVidia 和 ATI 顯卡可以允許你以數學方式渲染(被稱為高次表面), 但因為這不是所有圖形卡的標準, 你還不能靠它作為渲染策略。

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


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

            Culling
            If you don't see it, it isn't there. By culling the non-visible parts of a 3D world, a game engine can reduce its workload considerably. Look at this scene and imagine that there's a room behind the one under construction, but if it's not visible from this vantage point, the other room's geometry and other 3D data can be discarded.
            如果你沒有看到物體,那么物體就不在那里。通過剔除3D世界鐘不可見的部分,游戲引擎可以減少可觀的工作負載。來看上面的場景和圖像,在建筑下面在一個屋子后面有另外一個屋子,但是如果從有優勢的點看過去它并不可見,那么另外一個屋子的幾何和其他三維數據就可以被忽略。


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

              如果全部多邊形都在屏幕上, 相同的紋理,相同的尺寸大小, 正在往顯示卡上傳送多邊形的應用程序除了傳送多邊形以外什么也不做, 這時顯卡能處理多少多邊形數量, 就是圖形芯片廠商呈現給你的數字。

              然而,在真實的游戲情形中,應用程序時常在后臺做著許多其他的事情 -- 多邊形的 3D 變換, 光照計算, 拷貝較多的紋理到顯卡內存, 等等。 不僅紋理要送到顯示卡, 而且還有每個多邊形的細節。一些比較新的顯卡允許你實際上在顯卡內存本身里面儲存模型/世界幾何細節, 但這可能是昂貴的,將會耗光紋理正常可以使用的空間,所以你最好能確定每一幀都在使用這些模型的頂點, 否則你只是在浪費顯示卡上的存儲空間。 我們就說到這里了。 重要的是,在實際使用顯卡時,并不必然就能達到你在顯卡包裝盒上所看到的那些指標,如果你有一個比較慢速的CPU , 或沒有足夠的內存時,這種差異就尤為真實。


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

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

              BSP 是一種將世界分成小區域的的方法,通過組織世界的多邊形,容易確定哪些區域是可見的而哪些是不可見的 – 從而方便了那些不想做太多繪制工作的基于軟件的渲染器。它同時也以一種非常有效的方式讓你知道你位于世界中的什么地方。

            Binary Space Partitioning


              在基于窺孔(Portal)的引擎 ( 最早由 3D Realms 已經取消的 Prey 項目引入游戲世界 )里,每個區域 ( 或房間) 都建造有自己的模型, 通過每個區域的門 ( 或窺孔 )能夠看見另外的區段。 渲染器把每個區域作為獨立的場景單獨繪制。 這就是它的大致原理。 足以說這是任何一個渲染器的必需部份,而且非常重要。

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


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

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

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

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

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

              3D 管線
              - 高層的概觀
               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 就使用了這個方法的一種變體來建立它的地表系統。

            TruForm


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

              這就是第一部份 -- 我們將會在第二部分繼續介紹光照和紋理,下面的章節會更加深入。
            ------------------------------------------------------------------------------------
            第2部份: 3D環境的光照和紋理


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

            Light Hurts


              在頂點光照中,你要決定一個頂點被多少個多邊形共享,并計算出共享該頂點的所有多邊形法向量的均值(稱為法向量),并將該法向量賦頂點。一個給定多邊形的每個頂點會有不同的法向量,所以你需要漸變或插值多邊形頂點的光照顏色以便得到平滑的光照效果。 你沒有必要用這種光照方式查看每個單獨的多邊形。 這種方式的優點是時常可以使用硬件轉換與光照(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-Mapping


              使用 MIP 映射,你可以在顯示卡應用紋理之前,自己縮放圖像,因為可以預先處理紋理,你做得更好一些,讓泥漿不被縮掉。當 3D 顯卡用紋理繪制多邊形時,它檢測到縮放因子,說,"你知道,我要使用小一些的紋理,而不是縮小最大的紋理,這樣看起來會更好一些。" 在這里, MIP 映射為了一切,一切也為了 MIP 映射。


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

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

            Bump Mapping


              凹凸貼圖產生相當明顯的表面細節,盡管是很高明的戲法,但嚴格意義上講,凹凸貼圖并不隨著你的觀察角度而變化。比較新的 ATI 和 nVidia 顯卡片能執行每像素運算,這種缺省觀察角度的不足就真的不再是有力而快速的法則了。 無論是哪一種方法, 到目前為止,沒有游戲開發者太多的使用; 更多的游戲能夠且應該使用凹凸貼圖。


            高速緩存抖動 = 糟糕的事物
              紋理高速緩存的管理對游戲引擎的速度至關重要。 和任何高速緩存一樣,緩存命中很好,而不命中將很糟糕。如果遇到紋理在圖形顯示卡內存被頻繁地換入換出的情況,這就是紋理高速緩存抖動。發生這種情況時,通常API將會廢棄每個紋理,結果是所有的紋理在下一幀將被重新加載,這非常耗時和浪費。對游戲玩家來說,當API重新加載紋理高速緩存時,會導致幀速率遲鈍。

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

            Frame Buffer


              另外一種紋理高速緩存管理技術是我們早先討論的紋理壓縮。很象聲音波形文件被壓縮成 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 版本。其中有一些是我曾經見過的最好的云--大約與你能看見的一樣真實。

            Fogging


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

              你可以用不同類型的混合,這些不同的效果被稱為混合模式。直接Alpha混合只是把背景像素的一些百分比值加到新像素的相反百分比值上面。還有加法混合,將舊像素的一些百分比,和特定數量(而不是百分比)的新像素相加。 這樣效果會更加鮮明。 (Kyle's Lightsaber在 Jedi Knight II 中的效果)。
             
              每當廠商提供新的顯卡時,我們可以得到硬件支持的更新更復雜的混合模式,從而制作出更多更眩目的效果。GF3+4和最近的Radeon顯卡提供的像素操作,已經到了極限。


            模板陰影與深度測試
              用模板產生陰影效果,事情就變得復雜而昂貴了。這里不討論太多細節(可以寫成一篇單獨的文章了),其思想是,從光源視角繪制模型視圖,然后用這個把多邊形紋理形狀產生或投射到受影響的物體表面。

              實際上你是在視野中投射將會“落”在其他多邊形上面的光體。最后你得到看似真實的光照,甚至帶有視角在里面。因為要動態創建紋理,并對同一場景進行多遍繪制,所以這很昂貴。

              你能用眾多不同方法產生陰影,情形時常是這樣一來,渲染質量與產生效果所需要的渲染工作成比例。有所謂的硬陰影或軟陰影之分,而后者較好,因為它們更加準確地模仿陰影通常在真實世界的行為。 通常有一些被游戲開發者偏愛的“足夠好”的方法。如要更多的了解陰影,請參考 Dave Salvator的 3D 流水線一文。

            Stencil Shadowing



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

            Depth testing
            Look at this scene and think about what you can't see. In other words, what's in front of, or occluding other scene objects? Depth testing makes that determination.
            看看這個場景并想一想哪些東西看不到,哪些東西在前邊,或者遮擋了其他的場景對象。深度測試就是來做這個決定的。


              看著場景并想想你所看不見的。 換句話說,是什么在其他場景對象前面,或者隱藏了其他場景對象? 是深度測試作出的這個決定。

              我將進一步解釋深度深度如何幫助提高幀速率。想像一個很瑣細的場景,大量的多邊形 (或像素)位于彼此的后面,在渲染器獲得他們之間沒有一個快速的方法丟棄他們。對非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 新的高級shader語言將會幫助促進這一目標), 我一點不驚訝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顯卡行業的事情發生了變化。

            API Wars


              如今在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),和單個骨架限制,以及相片真實感的紋理。這個清單還能夠繼續列下去。但是真的,在用專業行話說了所有這些以后,我們在這里真正談論的是什么呢?讓我們看看。

            Skeletal Animation System


              讓我們定義一個基于網格的系統和一個骨骼動畫系統作為開始。在基于網格的系統,對于每一個動畫幀,你要定義模型網格的每個點在世界中的位置。舉例來說,你有一個包含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
              先前描述的效果可以通過具有層次的骨骼系統來完成。這是什么意思呢?意思是每塊骨架實際上的位置相對于它的父親,而不是每個骨架直接位于空間中的地方。這意謂著如果你移動父親骨架,那么它所有的子孫骨架也跟著移動,在代碼上不需要任何額外的努力。這是讓你能夠在任何骨架層次改變動畫,而且通過骨骼其余部分向下傳遞的東西。

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

            Skeletal Animation System


              許多今天的動畫系統中正開始出現一些比較新的特征,如動畫混合,從一個正在播放的動畫轉變到另外一個動畫需要經過一小段時間,而不是立即從一個動畫突然轉變到另外一個。舉例來說,你有個角色在行走,然后他停了下來。你不是僅僅突然地轉變動畫,讓他的腿和腳停在無效位置,而是一秒鐘混合一半,這樣腳似乎自然地移到了新的動畫。不能夠過高的評價這種效果 -- 混合是一個微妙的事情,但如果正確的運用,它真的有些差別。


            反向運動學
              反向運動學 (IK) 是被許多人們丟棄的一個專業術語,對它的真實含義沒有多少概念。IK 是如今游戲里面一個相對比較新的系統。使用 IK ,程序員能夠移動一只手,或一條腿, 模型的其余關節自動重新定位,因此模型被正確定向。而且有模型的關節新位置的其馀者他們自己,因此模型正確的被定向。比如,你將會說,"好,手 , 去拾起桌子上的那個杯子"并指出杯子在世界中的位置。手就會移動到那里,且它后面的身體會調節其自身以便雙臂移動,身體適當彎曲,等等。

            Forward Kinematics Demo


              也有和IK相反的事情,叫做前向運動學,本質上與 IK 工作的次序相反。想像一只手,手附著在手臂上,手臂附著在身體上。現在想像你重重地擊中了身體。通常手臂像連迦般抽動,且手臂末梢的手隨之振動。 IK 能夠移動身體,并讓其余的四肢自己以真實的方式移動。基本上它需要動畫師設定每種工作的大量信息 -- 像關節所能通過的運動范圍,如果一塊骨架前面的骨架移動,那么這塊骨架將移動多少百分比,等等。

              和它現在一樣,盡管很好,它是一個很大的處理問題,不用它你可以有不同的動畫組合而脫身。值得注意的是,真正的 IK 解決辦法需要一個層次骨骼系統而不是一個模型空間系統 -- 否則它們都耗時太多以致無法恰當地計算每個骨架。


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

            Messiah


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

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

              我希望這些帶給你對模型和動畫問題的洞察力。在第五部份中,我們將會更加深入3D世界的建造,討論一些物理,運動和效果系統的東西。
            -------------------------------------------------------------------------------------------
            第5部分: 物理,運動,效果


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

            3D Studio Max


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

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

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

            QERadient



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

            BSP Tree Hierarchy


              大體而言,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幀的幀速率,如果速度開始減慢,它就自動地縮減任何給定效果繪制的三角形數量。這樣使主要工作完成了,幀速率保持住了,但一些效果看上去很丑陋。

            LithTech


              無論如何,因為如今絕大多數效果傾向使用大量很小的粒子模擬火和煙等等,結果你在效果代碼里面每幀要處理許多的三角形。你必須把它們從一幀移動到下一幀,決定它們是否完成了,甚至還要在它們身上運用一些物理學以便讓它們在地板上面適當的反彈。這在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


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

              "這里借用我們的 " OpenAL 規格和叁考" 的一個定義:

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

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

              如同Jedi Knight II: Outcast 一樣,連同Eagle 世界/聲音特征編輯器,Soldier of Fortune II 以這個新系統為特征。什么是Eagle? 在介紹這個以前,讓我們討論一些其他的系統,并定義一些聲音術語。

            Miles Sound System



              另外的一個系統是Miles聲音系統。Miles是一家公司,它為你的代碼生產插件,在充分利用每塊聲卡時處理所有必須的到特定聲音卡的說話(比如Sound Blaster Live!系列,或者老的A3D聲卡)。它非常像一個API前端,捆綁了一些額外的特征在里面。 在其他事物當中Miles讓你存取一些事物像MP3解壓縮。 它是很好的解決方案,但像任何事一樣,它花費金錢并是你的代碼和硬件之間的額外一層。雖然對於快速的聲音系統制造,它非常有用,而且他們有段時間了,因此他們的確精通自己的業務。


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

            NOLF 2


              比如說,在NOLF2的一個屏幕鏡頭上你聽到房子里面壞蛋的聲音。你能聽到他們,但是他們的聲音相當低沉而沙啞。障礙是相似的,但是你和聲音之間的障礙物并不是閉合的。一個好的例子就是在你和聲源之間有一根柱子。由于房間中的回聲你仍然聽得到這個聲音,但是它和聲音直接傳遞到你的耳朵里是不同的。當然這確實依賴于知道在你的耳朵和聲源之間的直線上是什么。而且根據房間的大小,聲源到你的距離等等,需要的處理能變得相當耗時。后面我們將會談到跟蹤--足可以說它時常是比較慢的幀速率的原因。Quake III 里面的A3D 代碼做了這些事情,關閉這些選項通常能夠提高幀速率。Tribe 2 是這種弊病的另外一個受害者。關閉3D聲音選項則你的幀速率立即好轉,這在你考慮Tribes世界有多大和你能看見多遠時有意義。

              接著是聲音物質的特征。大部分聲卡可以讓你能夠用可定義的過濾器作用于聲音從而修正播放的聲音。例如,在水下,或者在一個布料遮蓋的房間中,或者在一個長的走廊中,或者在歌劇院,聽到的聲音有著很大的不同。能夠根據你所處的環境改變你聽到聲音的方式是相當不錯的。

            Eagle


              我們回到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沒有發生太大變化。而且在游戲行業中,如果不是迫不得已,別理會它。

            Miles Sound System


              通常你會僅僅使用DirectSound為你做聲音混合,因為它會可以使用的聲音硬件,或者轉而依靠軟件,很多地方就像DirectX為3D顯示卡所做的一樣。在 90% 的聲音情形中,依靠軟件混合對你的幀速率沒有真正發生太多不同。當DirectSound在一些狂熱的編碼者眼中甚至還不是一絲光線時,Doom引擎就已經產生了。它從來沒有得到更新過,因為它從來就沒有真的需要更新。

              當然,你可以使用 SoundBlaster Live!聲卡的一些聰明特征,例如房間的回聲特性: 一塊石窟,或一個禮堂,一個巨穴, 一個足球體育館等。而且你真的應該使用由硬件提供的混合器,畢竟,那是它存在的目的。這種方法的一個不足之處是程序本身時常無法獲得混合結果,因為混合是在聲卡內部完成而不是在主存。如果由于某種原因你需要看到產生的音量,你是運氣不好。


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

              動態音樂就是根據在游戲中目睹的行動改變你的音樂的能力,比如探險用慢節奏的音樂,戰斗用快節奏的音樂。預先制作的音樂的一個困難之處是要合拍,因此你可以從一段音樂漸弱到另一段音樂,這對于MIDI音軌比較容易。盡管時常你足夠快速地淡出,或者一段音樂在播放另一段音樂之前已經消失了,你能僥幸不被察覺。

            Cakewalk's Sonar XL


              在我們離開這個主題之前,順便說一下,值得一提的是存在一些公司專門為你的游戲創作特定意義的音樂。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中不應該做太多的倒敘,因為通常會需要載入新的環境或者關卡,以及新的紋理和/或模型。所有這些額外的處理和渲染能影響到主要的游戲序列的性能。你可以重用已經存儲在內存里面的場景元素來倒敘,但那樣會看上去明顯比較粗陋。

            Star Trek Voyager


              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關于腳本系統的論述
              去年底我訪談了Jim Dose--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部份的腳本引擎來到這一章節中的許多主題,我們認為那些鐵桿游戲玩家和有志成為游戲開發者的那些人將會發現它們相當有趣。我們將開始討論現成產品與定制的設計工具。

              你的工具的選擇是你引擎設計的一個非常重要的部份,因為這是你將用來給你的游戲產生內容的東西,是最耗時的部份。在這個過程中有助于節省時間和資源的任何東西都是好的。那些不能的東西就是糟糕的。在那里,那是容易的。

              當然沒有那么容易。有比這更多的事情可能會立刻被注意到。你的工具集的選擇,和從工具到游戲的資產路徑比它聽起來更有技巧得多,并受到很多因素的影響,比如,是否適宜手邊的工作,費用,內容生產者的熟悉,市場滲透,工具支持等等。當考慮選擇現貨成品工具,或者即使當開發你自己的工具時,記得開發者實際在做工作,最好能夠做需要借助工具做的。一些現貨成品工具能在價格上達到那里,當你陷入多個拷貝許可時,費用猛漲。

              然后就有誘人的可能性從頭制造你自己的工具,為你游戲和引擎的需要而設計。這當然需要時間,和程序員大量的努力來產生在開發者友好方式中所需要的東西。快速打造基于窗口的文件轉換器是一回事情,從頭建造一個完整的關卡設計工具又是另外一回事情。另一方面,如果你確實選擇這條道路,最后你會有游戲開發者地帶其他人沒有的工具,因此你的東西將會看起來是獨特的。如今與眾不同是一件非常值得想望的事情,而且從群眾這些天起突出是一件非常令人想要的事物,產生所有的競爭。

            QERADIANT


              當然由于內部的工具開發,你需要某人來做所有那些不可避免的小的改變和修正。但這里真正的意義是這是可能的。使用現成的工具,工具開發者會很少因為你需要的一些特征而改變他們的輸出文件格式。這樣你的東西最后看起來更加通用一些,否則你必須采用額外的步驟使用另外的工具來得到想要的結果,當然會花費開發者更多的時間。

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

            MAYA


              如果你選擇建造你自己的工具,多半你是,a) 重新創造車輪到某種程度 b) 陷入那些建造現成工具的人們已經遇到過的相同的問題之中,只是他們已經解決了這些問題。時常人們建造一個單一特定的工具花費了相當的時間和努力,并產生了一個遠遠超出你自己的個人需求的工具。還有,他們有代表性地收編了一些你或者認為是沒有用的,或者沒有時間自己實現的特征。加上他們典型地有吸收特征你或會沒有想有用,或沒有時間實現你自己. 這是第三方軟件無法爭辯的。


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

              如果你或你的公司打算建造某種類型游戲的工具,那么這些工具一般是從一個項目到一個項目地演變發展,而不是每次都從頭重新建造。如果你變換游戲類型,很好,那些產生具有每個多邊形命中能力的高分辨率模型的工具明顯地不是一款RTS(即時戰略)風格游戲所必須的。

              Gil Gribb,Rave Software的技術帶頭人,對‘現成的工具’和‘自己動手建造’的問題是這么說的:

              "自己開發的工具有能夠根據自己產品的需要進行定制的優勢,你擁有代碼,可以修正任何錯誤或者增加任何的改進。

              自制工具的缺點是建造和維護它們是非常昂貴的,通常成本要比現成工具高很多。在許多情況下,由于應用程序范圍的緣故,建立自己的工具是完全不可能的,比如說3D建模和動畫軟件包或者位圖編輯軟件。"

              當然,如果你想要游戲玩家能夠修改你的游戲,而且你自己建立了所有的工具,那么你就必須要向世界發布這些工具。這可能會引起一點點疑惑,記住建立你自己的工具的部分原因是你可以領先你的競爭者。有時侯發布這些工具的源代碼甚至可能讓你獲益匪淺,這確實提供了一種創造內容的方法。再次,Gil Gribb闡述這個主題:

              "我是支持發布幾乎所有的源代碼。我認為我們沒有任何來自我們的競爭者的害怕的事情,合法的業務不會想到竊取知識產權。游戲迷,業余游戲制作者,以及游戲的普及都能夠從發布的源代碼獲益。"

              好,我們的游戲引擎剖析系列到這里,當然我們已經特別討論了許多和引擎相關的主題,下面讓我們繼續討論一些與游戲特定相關的部分。


            游戲控制機制
              控制機制能夠對開發中的游戲帶來巨大的差別,有時甚至表明你正在建立的游戲的種類或者風格。

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

              假定他們的目標對象是FPS游戲人群,Raven需要找到一個對FPS游戲玩家來說直觀的控制烏鴉座(Corvus)的方式。他們這樣做了,但確實花費了一些時間,和一些不同的方式—他們應當讓照相機固定在一個方向嗎,或者讓它是浮動的嗎?大多數游戲開發努力—除非一個確定類型游戲的一個沒有虛飾的實現—傾向于花費一些研發找出物理控制裝置和游戲需要的內部控制機制的最直接的合并。這里是一個暗示—一旦你發現一個方式很起作用,就堅持下去。用這種方式控制游戲內在的東西能把視野,直覺,甚至游戲的焦點完全改變成你從未想要過的東西。發現起作用的東西,證明它起作用,然后就別管它。過分設計控制會導致特征偏離和可察覺的游戲概念問題。

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

            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一年時間才讓他的胃安定下來。啊哈,我們所作出的犧牲。


            武器系統
              游戲模塊的另外一個部份是武器系統。大多數的游戲有武器系統或類似的東西。 這是在世界中影響其他的物體,而且使他們對給定情形產生反應的東西,--比如說被射擊。通常武器系統由許多不同的類型組成;攻擊掃描,基于飛彈的,以及范圍形式。

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

            Dungeon Siege


              基于飛彈的武器有一個占用有限時間穿越世界的真實射彈,從而帶給對方一些可以躲避的時間。

            COMMANCHE 4


              基于范圍的武器像手榴彈和炸彈一樣的東西,不必擊中就可以傷害到你;你只是必須處于爆炸范圍內。處在那種爆炸范圍內的玩家受到飛濺損害。熔巖是另外一種形式的基于范圍的武器。

              那么你如何決定什么被擊中而什么沒有被擊中呢?很好,這個問題把我們帶到了追蹤,我們將在接下來的物理學和人工智能章節更多的接觸追蹤。這是一組函數例程,當給定世界中一條從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,并且如果你對游戲代碼做了改動,它將立即自動地應用到所有的角色,這在大多數情況下是一件好事情。

              其他的世界意識問題會冒出來,比如這樣的情形,兩個守衛彼此緊挨著站立,你用狙擊武器干掉了一個,而另外一個站在哪兒完全不知已經發生的事情。再者,遵守真實世界行為的細節是一款好游戲和一款偉大游戲的之間的區別。

            Half-Life


              讓我們說你已經把所有的刺激-響應部分準備好了—你已經掃描了世界,決定NPC應當對正在進行的一些事情作出反應—他聽到了玩家角色發出了聲響—并且你(游戲開發者)決定了他應當對這個做些什么—他將去調查。現在更加復雜的事情來了。他如何離開現在的位置,到達他認為發出聲音的地方,而不會想通常的數字傻瓜一樣跑到墻壁里面,碰到家具呢?繼續往下看…


            有關正確的路徑 --- 世界導航
              快速,準確的世界導航( 也叫做路徑-發現) 近來已經成為游戲開發者的圣杯。 讓它看起來非常信服是一件非常困難的事情。你需要有局部世界的地理知識—墻壁的位置,臺階,懸崖和建筑物等的邊緣。你也需要世界中的對象的知識—比如家具,汽車,尤其是其他人的位置。真正最后的因素是問題所在,一會兒我們將回到這一點上。

            Path-Finding


              世界導航通常被分為兩個領域,世界導航和局部導航。二者實際上只是范圍上的區別,但大多數的程序員分別對待它們,因為這樣處理起來容易一些。世界導航例程處理理解房間,門和一般的地理學,并計算出讓玩家或者角色從世界中的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點,他自己穿越世界,在途中避免障礙物,正確播放動畫,現在到達了這里。他看見了你。接下來做什么呢?很明顯更多的是作出決策。他將向你射擊。太棒了。你回應射擊。現在干什么?當他試著逃走的時候,現在你再次經歷全部同樣的事情。

            Soldier of Fortune


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

              想知道隱藏的難點嗎?看看我前面所有的描述,然后試著將它應用到一組NPC上,這些NPC彼此必須說話,設定目標,彼此溝通,但不妨礙彼此的方式。一旦你這么做了,試試那些代碼,作為玩家的隊友做上面所描述的這些,然而不要在槍戰中妨礙他。現在這是復雜的。然后這成為樂趣。這是最困難的部分。Raven的 Chris Reed關于AI‘感覺’的一些評論:

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

              并且Jess Crable 贊同:

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


            游戲規則與自然發生的游戲
              在我們關于AI的所有描述中,我們采用的是FPS的方式。有不止一種的AI。我們已經描述的是處理3D世界一組規則。AI遠遠不止這些。時常最好的AI實際上非常的簡單。它就是一組規則,玩家必須響應和處理的響應(或開始)動作的規則。

              這里應當處理一個被稱為“自然發生的游戲”的專業術語。 自然發生的游戲本質上創造游戲將遵守的規則,那將會造成游戲程序員不能預見的情形。

            Chessmaster 6000


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

            The Sims


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


              好吧,下面還有一個章節,僅僅還剩下一個章節了。在最后的章節里,我們將討論頭頂顯示,菜單系統,游戲定制和配置,游戲引擎版權與建造,最后是游戲“mods”。
            ---------------------------------------------------------------------------------
            第11部份: 最后的章節


            前端
              你已經看到了菜單系統,你可能理解游戲內的頭頂顯示(HUDs)時常是游戲經歷中被忽視和誹謗的部分。最近,這個領域開始被給人印象非常深刻的Black and White所關注,這款游戲實際上沒有HUD。在Peter Molyneux經歷了Dungeon Keeper以后,它在屏幕上大量的圖標,他決定游戲的大部分被這些圖標占用了,主要的屏幕沒有被足夠利用。因此他決定廢除所有這些東西。Peter邁了大膽的一步,我們為你喝彩。很不幸,這種方式適用于B&W這類風格的游戲,但它并不總是對其他種類的游戲有用。

            Quake III


              大體而言HUDs應該是不引人注意的,只提供你需要的關鍵信息;這本身會在設計團隊中引發爭議。Soldier of Fortune的最初設計在屏幕上有一個圖標,當被擊中時向你準確顯示身體的哪個部位被擊中。當他們決定他們不準備為不同身體部位的傷害而處罰玩家時,最后這個被丟棄了。在一些早期的Soldier of Fortune的屏幕截圖上,依然能夠在屏幕的右上角看見這個圖標。

              在一個完美的世界中HUD是可配置的,因此你能決定顯示什么,在哪里顯示,顯示多久。如果你覺得不需要局部雷達,那么它應當可以被移除掉。任何顯示的HUD信息應當有一定程度的alpha(透明度),因此如果需要你能透過它們看見后面的事物。

            Quake III (with transparency)


              說到配置,我是一個游戲個人設定的十足的狂熱者。因為沒有即時存儲設備存儲配置文件,在游戲機游戲上不是廣泛地可以獲得配置,這足夠公平。但是隨著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加入讀取/存儲和腳本:Elite Force不是野餐,但是必須的。然而,使用Quake3引擎依然是領先的開端。

              Unreal有名的Tim Sweeney 對于今天一些流行的預先打包的游戲引擎解決方案有一些評論。

              "我認為我能公平地比較游戲引擎 (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的混合模式上花了四天時間。

              值得考慮的其他引擎有Garage Games的Tribes 2引擎---被稱為The Torque Game Engine。我的理解是它可以收取微小數量的許可費用,將來有一些版稅協議。這是的確值得考慮的事情。你可以在這里看到這個引擎的特征細節http://www.garagegames.com/index.php?sec=mg&mod=v12&page=features 。 然后就是Serious Sam 引擎。這也是需要許可證的,的確值得看一看。如果你對它有興趣的話,可以聯系God Games---他們應當可以給你指明正確的方向。

              在網絡上有一些你可以下載的自由引擎---首先想到的是Crystal Space引擎。你可以從這里下載http://sourceforge.net/projects/crystal ,并在你的游戲中隨意使用。這不是一個專業的引擎,但看看所有的部分如何結合在一起時常是一個好的學習經歷。

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

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


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

            Smile for the Camera


              游戲 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。

            Death Alley


              作為一個開發者,你需要在那里可以見得到,并為那些在家中想利用你的游戲和用它做點別的什么的人們提供經驗和幫助。這種支持可以有許多形式----一個親切友好的詞語,一段代碼,建議,宣傳或只是金錢。只要有這個它時常不介意采用何種形式。

              在這里你選擇哪個第三方工具用來建造內容可能是至關重要的。在Raven,過去我們已經做了一些開發決定,在這方面沒有什么幫助,由于我們為大多數的建模和所有的動畫需求使用了SoftImage。雖然它是制作我們需要的動畫的最好工具,對于家庭業余愛好者來說它太過昂貴了。這就給那些家庭業余愛好者在擴充我們制作的內容時帶來了問題,因此他們容易拋棄我們轉而尋求那些比較容易制作內容的游戲。在建造或者選擇一個引擎時這確實是值得留意的事情。為了響應制作游戲mods,Discreet在市場上發布了一個3D Studio Max的‘lite’版本,稱為gmax。最好的是,它是免費的。如果你想要試一試,你能從這里抓取它http://www.discreet.com/products/gmax/gmaxconsumer/index.html

            Discreet's g max 3D modeler/animator


              最后在線游戲的成功時常能追蹤到 mod 社區,因此我認為感謝他們做了件好的工作是公平的。我過去時常說,在行業中到達一個‘真正的’工作最快的方式是從一個mod開始,說明你有完成它的訓練并用它作為一個面試獲得者。不能說,"我能做這個" 就像已經完成了一樣。因此去到那里并開始吧。你損失什么了嗎?


            有關作者
              Jake Simpson 是一個游戲程序員,斷斷續續在這個行業已經有大約20 年了。他在英國本土從15歲開始,在C64的時代,Sinclair Spectrums和 BBC Micros,經歷了 Amiga 和ST,離開了一段時間,然后90年代中期至后期在Mideay Games寫街機游戲。他最近在Raven Software工作過,制作有Soldier of Fortune, Heretic, Hexen, Star Trek : Voyager : Elite force 和 Jedi Knight II : Outcast,在北加州的Maxis可以找到他,為Will Wright的游戲產品工作。業余時間他為GameBoy Color和Advance編寫代碼,因為“你能盡可能地遠離C++編碼,而且,如同John Carmack所說,底層編程對程序員的靈魂有好處”。

            (全文完)

            posted on 2006-01-07 00:05 苦行僧 閱讀(4290) 評論(3)  編輯 收藏 引用 所屬分類: 轉載

            Feedback

            # re: 游戲引擎剖析 2006-03-14 17:28 小銀子
            學習學習   回復  更多評論
              

            # re: 游戲引擎剖析 2006-05-10 19:41 dreamwaylai
            不錯,譯得不錯.謝謝  回復  更多評論
              

            # re: 游戲引擎剖析 2008-04-01 14:19 www
            翻譯的很好,不過-------是否能夠給出:
            1. 原文標題
            2. 原文地址

            OK?????????  回復  更多評論
              

            久久精品无码一区二区日韩AV| 久久久久99精品成人片试看| 无码人妻久久一区二区三区免费| 青春久久| 久久久久99这里有精品10 | 久久精品国产只有精品2020| 亚洲第一极品精品无码久久 | 亚洲国产精品无码久久青草 | 国产免费久久精品丫丫| 久久精品国产一区| 国产精品va久久久久久久| 国产亚洲美女精品久久久| 精品多毛少妇人妻AV免费久久| 精品久久久久中文字幕一区| 久久精品三级视频| 亚洲中文字幕伊人久久无码 | 亚洲一区精品伊人久久伊人| 久久亚洲精品无码VA大香大香| 久久久久久久久久久精品尤物| 99精品久久久久久久婷婷| 午夜精品久久久久久久| 潮喷大喷水系列无码久久精品| 久久精品国产一区| 伊人久久大香线蕉精品不卡| 欧美日韩精品久久久免费观看| 久久精品毛片免费观看| 久久精品国产福利国产琪琪| 狠狠色丁香婷婷久久综合| 91精品国产高清久久久久久io| 99久久免费只有精品国产| 久久精品中文字幕大胸| 国产91色综合久久免费分享| 国产精品永久久久久久久久久| 久久香综合精品久久伊人| 久久精品国产秦先生| 久久精品国产亚洲av麻豆图片 | 国产精品免费福利久久| 久久se这里只有精品| 久久综合狠狠综合久久| 开心久久婷婷综合中文字幕| 久久久久亚洲AV无码专区体验|