一個遊戲引擎一般是由工具集和一個運行時組件組成。下面部分我們將首先研究這個運行時組件，然後再看工具集。
圖片1.11展示了組成一個典型的3D遊戲引擎的主要的組成部件。沒錯，它非常宏大！而且這張圖片並沒有把所有的工具都包含進來。遊戲引擎絕對是一個大的軟件系統。
就像其它所有的軟件系統一樣，遊戲引擎是分層次結構的。一般來說上層依賴下層，但反過來不一定成立。當下層也依賴上層的時候，我們就說這是一個循環依賴。循環依賴在所有的軟件系統中都是需要儘量避免的，因爲它們導致系統聯接關係不明，讓軟件變得不可測試，阻止代碼重用。這個對大規模系統如遊戲引擎尤其正確。
圖片1.11 Runtime game engine architecture
現在是圖1.11中對話框中描述的組件的一個概覽。本書剩下的部分將對這些組件進行一個更加深入的探討，並學習這些組件如何被整合成一個功能齊全的完整的系統的。
1.6.1 目標硬件
目標硬件層，在圖1.12中單獨列出來的，是將運行遊戲的電腦系統或者主機。典型的平臺包括運行Windows或者Linux的PC，蘋果iPhone和蘋果電腦，微軟的Xbox和Xbox 360， 索尼的PlayStation，PS2, PSP, PS3，任天堂的DS, GameCube, 還有Wii.這本書中大部分主題都是平臺無關的，不過我們將會講到一些針對PC或者主機的不同設計上的考慮，在某些有比較大的差別的地方。
1.6.2 硬件驅動
如圖1.13描述的一樣，硬件驅動是比較底層的由操作系統或者硬件開發商提供的軟件組件。硬件驅動管理硬件資源，把操作系統與引擎上層跟無數不同的可用的硬件細節操作隔離開來。
1.6.3 操作系統
在PC上，操作系統是一直運行着的。它指揮着多個程序在一臺電腦上運行，其中就包括你的遊戲。操作系統如微軟的Windows採用時間片的方法來讓多個運行程序分享硬件資源，這個就是廣爲人知的搶佔式多任務(pre-emptive multitasking). 這個表示一個PC遊戲永遠不能假定它對硬件有着完全的控制 - 它必須跟系統中的其它程序“和平共處”.
在主機上，操作系統一般只是一個很小的直接鏈接到你的遊戲運行程序的庫。在主機上，遊戲一般完整的“擁有”整個硬件。不過，根據Xbox 360和PS3的介紹，並不是嚴格的這種情況了。例如，這些主機的操作系統可以打斷你的遊戲的運行，或者取得某些系統資源來顯示在線信息，或者允許玩家暫停遊戲，調出PS3的Xross Media Bar或者Xbox 360的dashboard。不管怎樣，所有主機和PC上面的開發的差別在慢慢的縮小。
1.6.4 第三方SDK和中間件
大多數遊戲引擎都使用了許多第三方的SDK和中間件，SDK提供的或者或者接口一般稱之爲應用程序接口(API).我們來看一些例子.
1.6.4.1 數據結構和算法
如同其它任何軟件系統一樣，遊戲也非常需要一堆數據結構和算法來幫助處理。這是一些第三方提供的這些功能的例子。
* STL. C++標準模板庫提供了大量的代碼和算法來處理數據，字符串和I/O流
* STLport. 這是一個輕量級的簡化過的STL的實現版本
* Boost. Boost是一個強大的處理數據結構和算法的庫，被設計成STL的風格。(在線的Boost文檔還是一個學習計算機科學的好地方。)
* Loki. Loki是一個強大到讓你頭痛的通用編程模板庫。
遊戲開發者在是否在引擎中使用模板庫如STL上產生了分歧。有些人覺得STL的內存分配模式並不高效並導致內存碎片(看5.2.1.4節)，這使得STL在遊戲中不適用。另外一些人覺得STL的強大和方便足以掩蓋它的缺點。而且事實上大部分問題都可以解決。我的個人意見是STL在PC上面使用是沒有問題的，因爲它的高級的虛擬內存機制對於小心的內存分配不是那麼嚴格(但仍然需要小心)。在主機上，由於受限的或者根本就沒有虛擬內存機制，還有昂貴的cache miss開銷，你最好自己寫一個具有可預測的或者極少內存分配的自定義數據結構(在PC項目上這樣做的話也不會錯到哪去).
1.6.4.2 圖形
大部分遊戲引擎是建立在這些硬件接口庫上面的：
* Glide. 這是一個給老式Voodoo顯卡的3D圖形SDK. 它在硬件座標轉換和光照加速(hardware T&L)也就是DX8出現的時代非常流行。
* OpenGL. 一個廣泛使用的輕便的3D圖形SDK.
* DirectX. 微軟的3D圖形SDK，OpenGL的主要競爭對手。
* libgcm是一個底層的直接面向PS3的RSX顯卡的接口，是索尼提供的一個比OpenGL更高效的選擇。
* Edge是一個由Naughty Dog還有索尼爲PS3提供的強大的渲染和動畫引擎，它被許多第一方及第三方遊戲工作室採用。(譯者按：第一方工作室，first-part studio，與某家遊戲機製作商簽約的專門爲他們製作遊戲的工作室)
1.6.4.3 碰撞和物理
碰撞檢測及剛體物理(在遊戲開發交流中簡稱爲“物理”)由下面這些有名的SDK提供支持：
* Havok. 一個非常流行的工業水準的物理及碰撞引擎
* Phy X. 另外一個具有工具水準的物理及碰撞引擎，可以從NVIDIA那免費下載。
* Open Dynamic Engine.(ODE) 是一個非常流行的開源物理/碰撞模塊。
1.6.4.4 角色動畫
這裏有許多商業的動畫包，包括但不限於：
* Granny. Rad Game Tool的非常遊戲的Granny toolkit包括了能支持所有主流3D製作軟件包括Maya和3DMax的性能優良的3D模型及動畫導出插件，一個能讀取和操作導出的模型及動畫數據的實時庫，還有一個強勁的運行時動畫系統。在我看來，所有商業的或者私有的庫中，Granny SDK有是最着最好的設計及最符合邏輯的動畫API，特別是它對時間的天才的處理。
* Havok Animation. 隨着角色變得越來越真實，物理及動畫之間的界線變得越來越模糊。那個開發了遊戲的Havok物理SDK的公司決定製作一個免費附送的動畫SDK，它使得物理及動畫之間的連接變得從未有的簡單。
* Edge. Edge庫是Naughty Dog的ICE team爲PS3開發的，他們是Sony Computer Entertainment America的工具及技術團隊，Sony在歐洲的高級技術團隊開發了一個強勁的高效的動畫引擎，還有一個爲了渲染的高效的幾何處理引擎。
1.6.4.5 人工智能(artificial interlligence, AI)
* Kynapse. 一直到最近，人工智能一直是由每個遊戲自定義的。不過，有家叫Kynogon的公司製作了一箇中間層的SDK叫作Kynapse.這個SDK提供低級的AI模塊，包括尋路，繞開靜態和動態的物體，發現某塊區域內的弱點(例如，某個開着的窗戶可能就是埋伏的好地方)，還有一個合理的關於AI及動畫的接口。
1.6.4.6 生物的角色模型(Biomechanical Character Models)
* Endorphin and Euphoria. 這些是用真實人類移動的高級生物模型製作的角色動畫包。
我們在前面提到過，角色動畫及物理之間的界線越來越模糊。Havok Animation這種工具包試圖把物理和動畫通過傳統方式結合起來，也即是通過Maya這類工具做出用真人動畫來提供主要的動畫，而通過給出物理參數進行實時的運算。不過最近一家叫做natural Motion Ltd的公司製作了一個產品試圖重新定義遊戲中或者其它數字媒體中如何處理角色動畫。
它的首款產品，Endorphin，是一個Maya插件，它允許動畫師對角色進行完全的生物模擬並導出就如同手動動畫製作一樣的結果。這個生物模型計算重心，角色重量分佈，以及一個真實的人在重力及其它作用力影響下如何保持平衡及移動的細節。
它的第二個產品，Euphoria，是一個Endorphin的實時版，它試圖產生在不可預測作用力影響下實時的精確的物理及生物動畫。
