1.6.5 平臺無關層(Platform Independence Layer)
大多數遊戲引擎需要有能運行在超過一個硬件平臺上的能力。像EA及動視暴雪(Activision/Blizzard)這些公司，一直把它們的遊戲定位在一個非常廣泛的平臺，因爲這能使他們的遊戲拓展到儘可能大的市場。典型的，對每個遊戲，唯一不把目標定在至少兩個不同的硬件平臺上的公司是第一方工作室(first-party studio)，如Sony的Naughty Dog還有Insomniac Studio.因此，絕大多數遊戲引擎架構上都有一個平臺無關層，如圖1.16所示。這一層建立在硬件層、驅動層、操作系統，還有其它第三方軟件上之，把引擎的剩餘部分和大部分的底層平臺細節隔離開來。
圖1.16 Platform Independence Layer
通過封裝或者取代最常用的C標準庫中的方法，操作系統調用，以及其它的基礎的API，這個平臺無關層保證引擎在所有不同的硬件平臺上的行爲一致性。這個是必要的，因爲不同的平臺之間有很多差別，即使是C“標準”庫。
1.6.6 核心模塊(Core System)
每個遊戲引擎，還有每個真正的大的，繁雜的C++軟件程序，都需要一個有用的軟件功能集。我們將會把它們歸類在覈心模塊下面。一個典型的核心模塊層如圖1.17所示。這裏還有幾個核心層一般都提供的模塊的例子.
圖1.17 core system
* 斷言(Assertions). 斷言是進行錯誤檢查而插入的用來捕獲邏輯錯誤以及違反程序員本意的代碼。斷言一般在最終產品生成時被移走。
* 內存管理(Memory management). 目前所看到的所有遊戲引擎都實現了它自己一套內存的分配機制，來確保高速的內存分配及釋放以及減小內存碎片帶來的負面影響(見5.2.1.4節)。
* 數學庫(Math library). 遊戲是天生的對數學要求很高的。正因爲如此，每個遊戲引擎至少都有一個數學庫，如果沒有多個的話。這些數學庫爲向量及矩陣運算、四元數旋轉、三角運算、對線、射線、圓、截頭錐體(frusta)的幾何操作等提供工具。插值(spline manipulation)、數值積分(numerical intergration)、系統方程式求解，以及所有程序員要求的其它功能。
* 自定義數據結構及算法(Custom data structions and algorithms). 除非引擎設計人員決定完全的依賴第三方庫如STL，那麼一堆用來管理基本的數據結構(鏈表(linked lists)、動態數組(dynamic arrays), 二叉樹(binary trees), hash maps, etc)及算法(搜索、排序等)的工作一般來說是需要的。它們一般是手動編碼以求最小化或者消除掉動態分配，以及確保在目標平臺上最佳的運行性能。
關於最常見核心模塊的詳細的討論請看第二部分。
1.6.7 資源管理器(Resource Manager)
在每個引擎中以某種形式存在着，資源管理器提供一個統一的接口(或者幾個接口)來存取任何及所有的遊戲資源及其它引擎輸入數據。有的引擎採用一個高度集中並且穩固的管理(如Unreal的packages，OGRE 3D的Resourcemanager類).其它的引擎則採用一些特別的方式，一般讓遊戲程序員直接存取磁盤上的原始文件或者從一個壓縮結構中讀取像Quake的PAK文件一樣。一個典型的資源管理器如圖1.18描述。
圖1.18 Resource Manager
1.6.8 渲染引擎(Rendering Engine)
渲染引擎是任何一個遊戲引擎中最大和最複雜的組件之一。它可以有不同方式的架構，沒有一個絕對的標準去做。不過就如同我們看到的一樣，大多數現代的渲染引擎都採取了一些基本的設計哲學，並受到它們所依賴的3D顯卡的設計很大的影響。
其中一種比較常見和有效的設計一個渲染引擎的方法是採取如下的層次架構：
1.6.8.1 低級渲染器(Low-Level Renderer)
低級渲染器，如圖1.19所示，包括了所有的原始渲染引擎特性。在這個水平上，設計目標主要集中在如何快速且大量的渲染一堆幾何圖元，不考慮場景的哪個部分是可見的。這個組件可拆分爲幾個子組件，將在下面進行討論。
圖1.19 Low-Level rendering engine
* 圖形設備接口(Graphics Device Interface)
圖形SDK，例如DirectX和OpenGL，需要一大堆合理的代碼去查詢可用的圖形設備，初始化它們，設立渲染面(Render surface)(後臺緩層(back-buffer)，模板緩存(stencil buffer))等等。這些東西一般由我們稱之爲圖形設備接口的組件管理(儘管每個引擎有它自己的術語)。
對一個PC遊戲引擎，你還需要代碼把你的渲染器跟Windows的消息循環結合起來。你可能會寫一個"消息泵"(message pump)，當Windows消息沒有被處理的時候進行處理，否則就儘可能快的執行渲染循環。這個把遊戲的按鍵輸入與渲染器的屏幕輸出循環連接在一起了。這個連接是不大好的，不過好處是可以把對硬件的依賴性最小化。後面我們會對這一問題作更深入的探討。
* 其它渲染組件
低級渲染器中的其它組件通力協作，目標在於收集提交的幾何圖元(geometric primitives)(有時候也叫做渲染包(render packets))，如網格(meshes), 線段系列(line lists), 點系列(point lists)，粒子(particles), 地形塊(terrain patches)，文本字符串(text string)，以及其它所有你想畫的，然後儘可能的繪製它們。
低級渲染器一般提供一個視口(viewport)，它由camera-to-world矩陣及3D透視的參數如FOV(field of view)及近剪裁面及遠剪裁面得出。低級渲染器也根據它的材質系統(material system)以及動態光系統(dynamic lighting system)來管理圖形硬件的狀態及遊戲的着色程序(shaders). 每個提交的圖元都伴隨着一個材質，並且被n盞動態光影響。材質(material)描述了當這個圖元被渲染的時候，圖元(primitive)所用到的貼圖(texture)，硬件需要事先被設定的狀態，以及哪個頂點着色程序(vertex shader)/象素着色程序(pixel shader)被採用。光照和着色程序是一個非常繁雜的話題，在許多卓越的計算機圖形學書籍中都有深入的探討，包括[14]、[42]、[1]。
1.6.8.2 Scene Graph/Culling ptimizations
低級渲染器渲染所有的提交給它的幾何圖元，不管它是否可見(除了背面剔除(back-face culling)以及視錐剔除)。一般需要一個更高級的組件來闖蕩江湖提交的圖元數，根據某種方式的可見檢測。這一層如圖1.20所示。
對每個小的遊戲世界，一個簡單的視錐剔除(frustum cull)(去掉攝像機不可見的部分)是必要的。對於大的遊戲世界來說，一個更高級的空間劃分(spatial subdivision)數據結構可能用來提高渲染效果，它能對物體的潛在可見集(potentially visible set, PVS)進行快速的檢測。PVS有多種形式，包括二叉空間分割樹(binary space partitioning)，四叉樹(Quadtree)，八叉樹(octree), 多維檢索樹(kd-tree)，或者sphere hierarchy. 空間劃分有時候被稱作scene graph, 儘管技術上來說後者只是一種數據結構且並不包括前者。Portals/occlusion culling可能也會應用到渲染引擎的這個層級中。
理想的，低級渲染器應該完全不知道上面所使用的空間劃分或者scene graph。這個能讓遊戲團隊重用它們的圖元繪製系統，不過PSV系統則跟他們的遊戲的特定的需求有關。OGRE 3D開源渲染引擎的設計是體現這一原理的極好的例子。OGRE提供了一個即插即用(plug and play)的scene graph架構工。遊戲開發者可以從預定義實現的幾個scene graph設計中挑選一個，或者提供一個自定義的實現。
1.6.8.3 視覺特效(Visual Effects)
現在的遊戲引擎支持大量視覺特效，如圖1.21所示，包括:
* 粒子系統(particle system)，用於煙，火、濺起來的水花等
* 貼花(decal system)，用於彈孔，腳印等
* 光照貼圖light mapping and 環境貼圖environment mapping
* 動態陰影dynamic shadows
* 全屏後期特效full-screen post effect，作用在3D場景被渲染到離屏緩存上之後。
圖1.21 visual effects
一些full-screen post effects的例子:
* 高動態光照渲染(high dynamic range(HDR) lighting and bloom.)
* 全屏抗鋸齒(full-screen anti-aliasing(FSAA))
* 顏色糾正(color correction)以及各種濾鏡(color-shift)特效，包括跳躍漂白(bleach bypass)，過飽和(saturation)，去飽和(de-saturation).
對一個遊戲引擎來說，擁有一個特效系統來按理所有的粒子，貼花，還有其它特效的特殊渲染是常見的。粒子和貼花系統常常作爲渲染引擎中一個比較獨特的部件，並且作爲低級渲染器的輸入。另一個方面，光照貼圖、環境貼圖、陰影一般由渲染引擎內建管理。全屏後期特效則既可以作爲渲染引擎內建的模塊實現，也可以作爲一個獨立的模塊來操作渲染器輸出緩存。
1.6.8.4 前端(Front end)
大多數遊戲都採用了一些2D的圖形放在3D場景上面來實現各種目的，如:
* heads-up display(HUD)
* 遊戲內建菜單或者控制檯，或者其它開發工具，它們可能不會從最終產品中移除。
* 可能有一個遊戲內建的圖形用戶接口(GUI)，允許玩家來改變他的角色的道具，配置戰役中的戰鬥單位，或者完成其它複雜的任務。
這部分如圖1.22所示。這些2D的圖形一般是在一個正交投影下用繪製四邊形(quads)(兩個三角形)來實現的。或者是完全的3D製作的，採用四邊形的公告板(bill-boarded)技術來使它們一直朝向鏡頭。
在這一層中可能還包含全動視頻系統(full-motion video FMV system).這個系統負責播放預行錄製的全屏的電影(遊戲引擎渲染的或者其它渲染工具渲染的)
圖1.22 front end
一個相關的系統是in-game cinematics(IGC).這個組件允許電影跟遊戲本身結合起來。例如，當玩家走過一個城市，兩個關健角色的對話就可能是一段in-game cinematic. IGCs可以包含或者不包含玩家控制的角色。它們可能被設計成當玩家失去控制權時出現，或者可能是巧妙的整合進遊戲而玩家根本沒有意識到這兒有一段IGC.