剖析虛幻渲染體系（14）- 延展篇：現代渲染引擎演變史Part 1（萌芽期）

目錄

 

 

14.1 本篇概述

古人有語：以史為鑒，可以知興替。

歷史如此，技術亦然。通過研究現代引擎的演變歷史，可以更加系統、詳細地了解引擎的技術內幕，從而掌握底層原理，挖掘規律，預判技術或行業的未來。恰好這段時間筆者通讀了1000多篇各類論文和文獻，抽取了其中的數百篇文獻，總結歸納成此篇文章，以饗同行。

14.1.1 遊戲引擎簡介

本節將闡述遊戲引擎的定義、功能、模組以及基本框架。

遊戲往往有很多共同的功能，將這些功能創建抽象出通用功能的框架，即是遊戲引擎（Game Engine）。更準確地說，遊戲引擎是一系列模組和介面，使遊戲開發團隊可以專註於產品遊戲內容，而不必關注技術內容。

遊戲引擎按照完整性看分為一體式和模組化兩種類型。一體式是GameMaker、RPGMaker之類的引擎，模組化的引擎是指UE、Unity之類的引擎。本篇將著重闡述模組化類型的遊戲引擎。

遊戲引擎是通用遊戲所依賴的功能或模組。遊戲引擎是一個框架，由一組不同的工具、實用程式和介面構成遊戲的各種任務的詳細資訊。簡而言之，遊戲引擎可定義為：可擴展的軟體，無需重大修改即可用作許多不同遊戲的基礎。

現代遊戲引擎架構的常見模組。

有許多電腦遊戲類型，主要有第一人稱射擊遊戲 (FPS)、實時策略 (RTS) 和角色扮演遊戲 (RPG)。所有類型都包含單人遊戲（其中使用人工智慧模擬其他玩家）或多人遊戲（其中幾個玩家可以通過電腦網路在同一個虛擬世界中互動），或兩者兼而有之。而不同的遊戲引擎更擅長某些類型的遊戲創作。比如Unreal Engine更適合室外的FPS，Unity更適合輕量級的移動端遊戲，等等。

大多數現代電腦遊戲可以分為三個部分：遊戲引擎、遊戲邏輯和遊戲藝術。遊戲引擎是在電腦上運行的主要可執行文件。它提供了一個運行遊戲邏輯的環境，以及基本的數學、圖形、音頻、用戶輸入和網路功能。遊戲邏輯可以採用腳本、虛擬機位元組碼或庫（例如 DLL）的形式。遊戲邏輯的任務是控制遊戲玩法，並使用引擎適當地展示遊戲藝術。遊戲藝術包括圖片（遊戲用語中的紋理）、地圖（虛擬世界的布局）、模型（居住在世界上的事物的 3D 表示，例如玩家、武器或花盆）和聲音。

遊戲和遊戲引擎的關係。

遊戲、遊戲引擎、電腦的抽象分層。

遊戲引擎內的常見分層結構和模組。

現代遊戲引擎的模組詳情。

通過改變遊戲邏輯和藝術，可以使用遊戲引擎來創建許多不同的電腦遊戲。在某些情況下，如果源程式碼可用（如Quake 2），則可以修改遊戲引擎本身。

總之，遊戲引擎為遊戲創作團隊提供遊戲開發的方方面面，使得遊戲開發者需要更少的編程技能，可以快速、高效地創建出具有專業品質的虛擬內容。遊戲引擎的尺寸、模組化和可移植性的增加，以及與之相關的改進工具被認為是從第一款遊戲到今天發展的總體趨勢。

使用遊戲引擎的目的有幾個：

  • 靈活性。可以做任何原生 API 讓我們做的事情，沒有刪減功能。
  • 生產率。比原生 API 更易於使用，更少的程式碼，更少的精神負擔。
  • 性能。與手寫原生程式碼類似的CPU幀時間。
  • 簡單。保持介面儘可能少而精。


主流商業遊戲引擎的部分特性。

利用遊戲引擎創作遊戲等產品，擁有的好處是：

  • 更少的程式碼
  • 更高的生產力 = 更少的時間！
  • 可用性（易於使用）
  • 與設計程式的兼容性（集成）
  • 更多工具，更多選擇
  • 插件和庫
  • 跨平台

當然遊戲引擎並非萬能，也存在諸多限制，比如：製作與引擎預期不同的類型可能很困難，讓引擎做任何意想不到的事情可能很困難，遊戲開發者對引擎的弱點會限制遊戲的品質和效率。

14.1.2 遊戲引擎模組

遊戲引擎是遊戲或模擬遊戲的核心軟體，用於描述用於開發遊戲的一組程式碼。在螢幕上看到並在遊戲世界或模擬環境中與之交互的一切 均由遊戲引擎提供支援。它允許抽象並執行普通遊戲的細節或模擬相關的任務（例如渲染、物理、輸入），使開發者可以專註於製作他們的遊戲的各個方面模擬特性。

典型的遊戲引擎組件和類型圖。

遊戲引擎的設計側重於靈活性，允許對其功能進行簡單擴展，可以很容易地修改以適應受某些因素（如記憶體等）限制的平台。引擎分為兩個不同的部分，稱為框架和管理器。框架包含遊戲中重複的部分，意味著它們會有多個實例，還包含與主遊戲循環的執行有關的項目。管理者是遊戲邏輯所依賴的單例。下圖說明了組成引擎的不同部分：

遊戲引擎最基礎的模組必然包含時間更新、場景管理、渲染（圖形、繪製）、輸入事件等等。

擁有以上基礎模組之後，高級一些的遊戲引擎，還擁有更多複雜的模組，諸如攝像機、螢幕管理、網路、音頻、物理、動畫、模型等等。

應用程式維護的螢幕映射表，螢幕可以使用事件或將它們傳遞到不同的螢幕。

渲染模組是引擎的核心功能，一直以來是遊戲引擎的重中之重，也是行業從業人員重點攻克的陣地。一個遊戲引擎的成功與否，渲染模組佔據非常重要的地位。渲染模組最簡單的功能如設置相機、繪製形狀、設置形狀的材質屬性、繪圖文本，從而生成標準圖形API介面，通過作業系統或（和）驅動程式像GPU發送並執行繪製指令。

高級的遊戲引擎往往還有高層的遊戲通用模組，如玩家控制、插件體系、編輯器、自動化工具、資產管理等等。遊戲引擎還擔負著跨平台、圖形API、硬體差異等抽象和處理工作。現代遊戲引擎往往包含著更加複雜、多樣、全面的模組和工具鏈，可將它們分為低層級、中層級、高層級模組。具體如下：

  • 低層級模組

    • 數據結構
      • 數組、鏈表、樹、圖、哈希表
    • 演算法
      • 排序、動態規劃、並行循環
    • 數學
      • 向量、矩陣、四元數
      • 幾何計算
      • 隨機數
      • 其它數學模組
    • 記憶體管理
      • 遊戲引擎通常使用自定義記憶體管理
      • 必須避免碎片化
      • 分層記憶體管理
      • 定址
      • 垃圾回收
      • 顯示卡記憶體管理
    • 資源和文件IO
      • 快速載入
      • 定址
      • 解析
      • 文件格式
      • XML
      • 壓縮
      • 資源打包
    • 輸入設備
      • 控制板、操縱桿
      • 鍵盤、滑鼠
      • 特殊硬體（觸覺，6-DOF）
      • 力回饋
      • 麥克風
      • 相機
      • 配置
      • 按鈕映射
      • 校準
    • UI
      • 基礎控制項
      • 事件管理
      • UI動畫
    • 性能監測
      • 時間是關鍵資源
      • 各種硬體，每個都有自己的時序和性能特徵：CPU、圖形、音頻、IO
      • 存在許多複雜的分析器
      • 遊戲內預算和警告遊戲預算和警告
      • 遊戲內繪圖 遊戲繪圖
      • 用於全面分析的調試工具

  • 中層級模組

    • 渲染
      • 詳見圖形子系統
    • 音頻
      • 3D 空間化：平移、多普勒、杜比環繞、HRTF（與頭部相關的傳遞函數）
      • 管理聲音優先順序（聲音）
      • 混響，效果
      • MIDI
      • 音樂
      • 動態音樂
      • 流式傳輸 CD / DVD（多個流）
      • 語音
    • 文本
    • 碰撞檢測
    • 物理學
    • 腳本
    • 聯網
    • 角色動畫
    • 電影播放

  • 高層級系統

    • 場景管理
    • 用戶控制
    • 相機
    • AI（人工智慧）
    • 遊戲邏輯
    • 遊戲流程
    • 燈光、視覺效果
    • 平視顯示器
    • 前端（用戶介面）

  • 圖形子系統

    • 渲染
      • 在硬體之上分層
      • 常用 API：OpenGL、Direct3D、Vulkan、Metal
      • 渲染多邊形網格（顯示列表）
      • 照明
        • 漫反射、鏡面反射、AO、GI、IBL、PBR
      • 圖形狀態
      • 矩陣和視圖轉換
      • 著色器
      • 特殊材質
        • 皮膚、頭髮、眼球、二次元
    • 場景管理
      • 場景圖
      • 加速結構：KD樹、四叉樹、八叉樹、Portal、BVH等
      • 貼花
      • AI
      • 碰撞
    • 剔除
    • LOD
    • 地形渲染
    • 角色換膚
    • 粒子引擎
    • 效果（天空、水、植被、霧）

  • 工具

    • 程式碼開發工具

      • 編譯器（Visual C++、SN Systems、CodeWarrior、GNU）
      • 調試器
      • 探查器
      • 編輯
      • 修訂控制（CVS、SourceSafe、SVN）
      • 集成開發環境 (IDE)
      • C++、彙編、腳本語言
      • 圖形語言：像素和頂點著色器……
      • 設計分析工具
      • 文件、標準

    • 中間件

      • 渲染：RenderWare、NDL、Intrinsic、OGRE、OpenSceneGraph
      • 物理引擎：ODE、Havok、PhysX、牛頓
      • 數學引擎
      • XNA、Bink、FMOD、ScaleForm

    • 藝術製作工具

      • 3D 建模和動畫（Maya、3D Studio）
      • 導出導出模組模組
      • 資產管理（AlienBrain）
      • 繪畫（2D 和 3D）（Photoshop、Z-Brush、DeepPaint）
      • 掃描（2D、3D）
      • 動作捕捉
      • 遊戲內工具和編輯器

    • 音頻工具

      • 錄音
      • 作曲（ProTools）
      • 音效（原因）
      • 空間音頻配置工具
      • 遊戲內工具

    • 遊戲設計工具

      • 遊戲內工具
      • 關卡布局
      • 原型製作工具（Director、Flash）
      • 設計工具
      • 圖形用戶介面工具
        • CEGUI、NGUI、UMG

      開源渲染引擎OGRE集成的CEGUI編輯器一覽。

對於交互，遊戲或模擬中的交互遊戲或模擬中的交互非常重要，是整體用戶滿意度的最重要因素。每個遊戲/模擬都有自己的要求，具體取決於類型、支援的控制項、交互的響應時間、交互響應的真實程度等。每個應用程式的目標群體在很大程度上定義了交互選項。

只要有可能，用戶自定義和修改交互參數的能力是必不可少的、至關重要的，例如滑鼠移動速度、滑鼠移動速度反轉、上下軸反轉、多上下軸、多模態控制模態控制等。常見的一種遊戲執行流程包含處理窗口消息、調度器執行、分發更改、檢測執行狀態，如下圖所示：

通用的場景和物體的關係如下圖所示，每個系統包含一個或多個場景，每個場景包含一個或多個物體：

遊戲引擎通常由工具套件和運行時組件組成，下圖顯示了構成典型3D遊戲引擎的所有主要運行時組件。像所有軟體系統一樣，遊戲引擎是分層構建的，通常上層依賴於下層，反之則不然。當較低層依賴較高層時，會引發循環依賴。在任何軟體系統中都應避免依賴循環，因為它們會導致系統之間出現不良耦合，使軟體無法測試，並抑製程式碼重用，對於遊戲引擎這樣的大型系統尤其如此。

遊戲引擎中常見模組的細節和特性。通常採用了分層架構，上層依賴下層，反之不然，否則會引起不良的循環依賴。（圖摘自《Game Engine Architecture Third Edition》）

遊戲引擎的工具套件存在多種創作方式，部分工具可能是獨立的軟體，部分工具可能構建在運行時引擎使用的一些較低層之上，還有一些工具可能內置在電競筆電身中。例如，基於Quake和Unreal的遊戲都擁有一個遊戲內控制台，允許開發人員在運行遊戲時輸入調試和配置命令。


上：獨立的工具架構；下：共享於遊戲之間的框架式工具。

遊戲引擎分層示意圖。

平台相關的模組。

核心系統相關的模組。

遊戲邏輯相關的模組。

遊戲引擎中涉及的各類管理器如下圖所示：

如何識別遊戲引擎的通用部分？看待這個問題的一種方法是專註於將遊戲引擎定義為除內容之外的所有內容，每個遊戲引擎的通用部分將包括：

  • 主循環（或替代結構）
  • 處理遊戲數據文件或鏈接到用程式碼編寫的遊戲數據的模組
  • 處理遊戲邏輯的模組，可以但不是必須由數據文件指定
  • 從播放器獲取輸入的模組
  • 將輸出呈現給播放器的模組
  • 輔助模組，例如網路和菜單處理

14.1.3 遊戲引擎列表

目前市面上的遊戲引擎數量達到驚人的上百個，有些是當前風靡全球的商業引擎，有些是研製出很多3A級遊戲的遊戲公司內部引擎，有些是用於學習或研究的開源渲染器，有些則是曾經流行但現在已經淡出歷史舞台的引擎。下面將闡述部分常見的遊戲引擎。

14.1.3.1 Unreal Engine

虛幻引擎（Unreal Engine，UE）是一款集圖形渲染和開發套件的商業引擎，在歷經數十年的發展和沉澱，於百擎大戰中脫穎而出，成為引領實時渲染領域的全球性的通用商業引擎，廣泛應用於遊戲、設計、模擬、影視、教育、醫學等行業。它出自遊戲公司Epic Games，最初由Tim Sweeney負責，從上世紀90年代中期就開始，已經經歷了20多年，歷經數個大版本迭代。

Unreal Engine 2是一個完整的遊戲開發框架，針對當今主流PC、微軟的Xbox遊戲機和索尼的PlayStation 2。Unreal Engine 2X是Epic自製遊戲Unreal Championship 2: The Liandri Conflict中令人瞠目結舌的視覺效果背後的高度優化引擎。

Unreal Engine 3是一個完整的遊戲開發框架，適用於下一代遊戲機和配備DirectX9的PC，提供頂級遊戲開發者所需的大量核心技術、內容創建工具和支援基礎設施。雖然Unreal Engine 3對Mod製作者開放程度很高，但使用UE3發布和銷售遊戲的能力僅限於引擎許可。在2009年11月，Epic發布了一個免費版本的UE3 SDK，稱為Unreal Development Kit (UDK)，可供公眾使用。

Unreal Engine 4相比之前版本有了很大的改進，使之成為一款風靡全球的遊戲開發引擎。虛幻引擎是一套完整的構建遊戲、模擬和可視化的集成工具。其特性包含但不限於實時逼真渲染、可視化腳本、實時光線追蹤、完善的遊戲框架、專業動畫和過場、完善的工具鏈等等。

Unreal Engine 5於2020年5月13日發布預覽影片，支援所有現有系統，包括次時代遊戲主機PlayStation 5和Xbox Series X/S。該引擎的研發工作在發布前約兩年就已開始，且在2021年中期發布了Early Access版本的源碼，並計劃於2022年全面推出。Unreal Engine 5採用了兩大核心技術：

  • Nanite：允許將高細節攝影源材料導入遊戲的先進技術，可用於處理遊戲場景中複雜的幾何體；
  • Lumen：用於解決遊戲的全局光照細節，並且不依賴於硬體的光線追蹤。



從上到下依次是Unreal Engine 1、Unreal Engine 3、Unreal Engine 5的編輯器介面。

早期的Unreal的基於光照圖的光照效果。

Unreal Engine作為行業頂級的通用商業遊戲引擎，被遊戲行業廣泛使用，並研製出了許多知名、畫面精良的遊戲。



用Unreal Engine研發出的遊戲截圖。從上到下依次是UE3的Batman: Arkham City、UE4的最終幻想7重製版、UE5的黑神話悟空。

有了UE5的Nanite、Lumen等技術的加持，使得實時互動遊戲朝著影視級的畫質發展，Epic官方放出的黑客帝國演示demo便是最好的例證（下圖）。

Epic用UE5研製的黑客帝國互動Demo截圖，畫質直逼電影，讓人無法區分遊戲和電影的界限。

除了遊戲行業，虛幻引擎還被廣泛應用於影視、模擬、設計、廣電、科學可視化等領域，並逐漸完善了相配套的工具鏈和生態社區。

UE用於演習和模擬器中以進行培訓。

14.1.3.2 Unity

Unity由Unity Technologies公司研發維護，是一個具有功能強大的編輯器的跨平台遊戲引擎，也是最受歡迎的商業引擎之一。在項目中，開發人員可以控制向移動設備、Web瀏覽器、桌面和控制台的交付。它的功能非常豐富，使用Javascript或C#編寫腳本，存在大型社區支援，非常適合跨平台開發。

Unity的第一個版本 (1.0.0)於2005年6月發布，目標是為業餘遊戲開發者創建一個價格合理的遊戲引擎，並為業餘遊戲開發者提供專業工具，同時「使遊戲開發民主化」行業。這三者的靈感來自Apple的Final Cut Pro產品的簡單工作流程、簡單的資產管道和拖放介面。最初發布時，Unity僅適用於Mac OS X，開發人員只能將他們的作品部署到少數平台。當前版本可以支援Windows 和 Mac OS X等至少十幾個目標平台。

Unity早期版本（版本 0.2）的螢幕截圖。

早期Unity遊戲Gooball截圖（2005）。

14.1.3.3 CryEngine

CryEngine系列引擎由德國遊戲開發商Crytek設計的遊戲引擎，已被用在CryTek的所有遊戲中。初始版本在孤島驚魂中使用，並繼續更新以支援他們的遊戲的新控制台和硬體。

CryEngine自2004年發布了1代引擎，到目前的版本V，經歷了20多年的發展迭代了數個大版本。Ubisoft維護了一個內部的、經過大量修改的原始孤島驚魂的CryEngine版本，稱為Dunia引擎，用於他們後來的孤島驚魂系列迭代。

CryEngine和其孿生引擎的發展歷程。

CryEngine完整的家族樹及遊戲列表。

CryEngine 1最早於2004年和Far Cry的技術演示一同發布，支援Shader Model 3.0、HDR照明及其它圖形特性。遊戲代表作有孤島驚魂、永恆之塔等。

CryEngine的場景和地形編輯器（2004）。

CryEngine的動態光照效果（2004）。

CryEngine的水體、船、人物相互交互的渲染效果和編輯器（2004）。

Far Cry遊戲截圖。

CryEngine 2於2007年發布，支援HDR照明、實時環境貼圖、體積雲、動態水體（水面和水下）、景深、運動模糊、動態軟陰影、動捕臉部動畫、次表面散射、可互動和破壞的環境、可交互植被、繩索物理等特性。代表作有Crysis、Crysis Warhead等。


Crysis遊戲截圖。

CryEngine 3在2009年發布，相比上一代引擎，引擎支援 DirectX 9、10 和11的開發，新增了許多先進的圖形、物理和動畫技術以及許多遊戲增強功能，比如：實時間接照明的級聯光傳播體積、軟粒子、多核並發、延遲光照、自然光和動態軟陰影、霧效果（體積、分層和視距）、SSAO、全能著色器、人眼適應、HDR照明、運動模糊、DOF、次表面散射、高品質水體、動態體積光束和光軸效果、流環境、多核物理引擎、交互和破壞環境、高速紋理渲染等等。代表作有孤島危機 2等。

CryEngine3的渲染效果。

CryEngine3研製的射擊遊戲Nexuiz。

CryEngine (3.6–4)於2013年發布，Crytek將CryEngine（從版本 3.6.0 開始）更名為「CryEngine」，並宣布下一個CryEngine將不會以版本號進行宣傳，原因是聲稱這個新引擎與以前的CryEngine版本幾乎沒有相似之處。

CryEngine渲染出的大片森林。

CryEngine V（5）在2016年3月發布，CryEngine 5.4在2017年9月發布，添加Vulkan API渲染器作為測試版、物理集成和其它功能，包括新的C#模板、資產系統更新和新的抗鋸齒技術。在渲染方面，CryEngine V支援以下特性：

  • 區域光源
  • 基於物理的渲染（PBR）
  • 曲面細分
  • 高效的抗鋸齒
  • 實時局部反射
  • 基於體素的全局光照（SVOGI）
  • 螢幕空間方向遮擋（SSDO）
  • 基於圖形的光照（IBL）
  • 體積霧陰影
  • 支援DirectX 12
  • 實時動態水體焦散
  • 3D HDR鏡頭光暈
  • 運動模糊和景深
  • 實時植被
  • 逐物體陰影圖。
  • HDR膠片色調映射
  • 粒子特效系統
  • 平行視差映射

CryEngine 5.3編輯器。

CryEngine V沙盒編輯器。

CryEngine V的渲染效果圖。

14.1.3.4 Doom / Quake / ID Tech

Quake家族引擎用於創建許多遊戲，擁有延伸到榮譽勳章等現代遊戲的血統，並且Quake和Quake II引擎源程式碼免費提供。

在2004前後，Quake 3使用標準的FPS遊戲控制系統：滑鼠外觀和鍵盤，四處移動滑鼠會改變玩家的視線方向，滑鼠按鈕通常用於向前行走和射擊，鍵盤上的各種按鍵用於蹲伏、跳躍、後退、掃射和切換武器，可以通過稱為鍵綁定的過程將鍵重新映射到不同的遊戲內功能。Quake 3是一款面向網路的遊戲，使用客戶端-伺服器（CS）通訊模型。

Doom、Quake、Unreal等引擎有個共同特點，那就是擅長FPS類型的遊戲。下面是詳細的FPS遊戲及引擎的發展歷程圖：

其中ID Tech 3支援摒棄了軟光柵渲染，需要一個兼容OpenGL的圖形加速器運行。引擎的圖形概念緊密圍繞「著色器」（如今的材質）系統，其中許多表面的外觀在文本文件中定義，稱為「著色器腳本」。此外還支援基於樣條的曲面、曲線頂點動畫、基於子模型的動畫分離、體積霧、鏡像、入口、動態陰影和基於波形的頂點擾動。

14.1.3.5 OGRE

OGRE是一款開源的較為成熟的多平台3D圖形引擎，支援OpenGL和DirectX渲染，在LGPL許可下用C和C++編寫。 它具有基於OO的設計，並支援可載入的程式碼模組。它還提供了分層場景圖、基本物理函數，並內置了2D GUI系統，支援常用小部件和TrueType字體。在2000年時代，它擁有龐大而活躍的開發人員和用戶支援社區。 然而，它不是遊戲引擎，只處理圖形渲染，故而不支援網路或音頻，需要引入第三方庫。

用ORGE製作的遊戲代表作有Runic Games的火炬之光（Torchlight），Torchlight是角色扮演遊戲，類似暗黑破壞神的風格和玩法，於2010 年遊戲開發者選擇獎最佳處女作獎，可通過數字分發在Windows和Mac上使用。

用ORGE研發的單機暗黑類遊戲Torchlight的遊戲截圖。

Torchlight剛發布之時，筆者恰好入職中國某一線遊戲公司，被Torchlight炫酷的畫面、技能效果和別具一格的玩法深深吸引，那時還沒有996，每天一下班就有大把時光沉迷於探索它的暗黑魔法世界。

在2000年時代，中國湧現了很多遊戲公司和團隊基於ORGE做魔改和二次開發的自研引擎，其中最為成功的案例便是暢遊的天龍八部，它是一款改編自金庸古風武俠小說的網路遊戲，曾經風靡一時，至今尚在運營。基於OGRE二次開發的引擎或開源庫有很多，其中就包含Ogre Golf。後期的ORGE發展的功能有：可擴展框架、多平台、場景管理器、資源管理器、材質、網格、動畫、渲染器、特效、著色器、插件等。

14.1.3.6 Gamebryo

Gamebryo由Emergent Game Technologies研發維護，是一款跨平台的3D遊戲引擎，遊戲代表作有Fallout 3 (Bethesda)、Civilization Revolution (Firaxis)、Warhammer Online (EA Mythic)等。

Gamebryo引擎以前稱為NetImmerse。NetImmerse的開發以幾個設計目標為指導，其中最重要的是速度，導致研發者在整個引擎中使用了簡單的技術，並大量基於場景圖數據結構，允許多種性能增強技術，例如剔除對玩家來說是不可見的遊戲對象。

其它設計目標是提供與標準圖形和音頻介面的兼容性，並提供高級編程介面。引擎研發者聲稱目標已經實現，並分別指出創建引擎的一個發現是「高級編程介面不需要犧牲性能」。引擎提供高級介面很重要，允許開發人員降低開發成本，並且需要針對引擎進行優化不同類型的遊戲。

Gamebryo Lightspeed有著較廣泛的遊戲作品，提供快速的應用程式擴展框架，另外解耦的架構設計使得遊戲團隊可以方便地擴展。Gamebryo支援處理聲音、圖形、物理和多人遊戲的各種技術和遊戲玩法，它的視覺保真度高，曾被用於製作具有廣闊景觀的遊戲以及複雜的面部細節。此外，它還被用於開發美國政府和軍隊項目，以及消防和手術模擬。

14.1.3.7 BigWorld

BigWorld（也稱為 Wargaming Sydney）是一家澳大利亞公司，由John De Margheriti於2002年成立，該公司開發和許可用於創建大型多人在線遊戲 (MMO) 和虛擬世界的中間件開發工具套件。它是第一家為MMO市場開發此類中間件平台的公司。2007年，BigWorld被英國的Develop雜誌公認為行業領導者。2012年8月7日，Wargaming以4500萬美元收購了BigWorld中間件公司。

BigWorld Technology提供了遊戲開發者構建MMO和在線遊戲所需的底層軟體架構。3D客戶端技術專為Windows PC和瀏覽器構建，可通過網路API在 iOS、Xbox 360和PlayStation 3上使用。 後端伺服器解決方案在Linux下實現，具有Python API腳本環境。該工具套件包括內容創建工具、伺服器監控工具和支援。BigWorld Technology還集成了各種第三方插件，例如Umbra（遮擋剔除）、Scaleform（用戶介面創建）、Speedtree（樹葉）和 Vivox（VOIP）。

遊戲代表作主要有：World of Tanks系列、天下系列等。

14.1.3.8 Torque3D

早期的Torque3D引擎有幾個版本，具體描述如下：

  • Torque Game Engine 1.0：以及 TGE 1.5 的所有功能，它具有 atlas 地形生成編輯器、Torque GFX 圖形層、自定義紋理材料、現代場景圖和批處理渲染引擎。
  • Torque Game Engine 1.4：這箇舊版本的 Torque 仍然具有 3D 工具集、地形引擎、網路引擎和其它功能。基於用於部落 2（Tribes 2）的技術。
  • Torque Game Engine 1.5：1.4.2 的重大升級，具有集成的 Torque 照明套件、ShowTool Pro、附加藝術資產等等。

是2010年之前的一款較流行的遊戲引擎，後逐漸衰落，淡出人們的視野。

Torque引擎河流編輯器。

Torque地形編輯器。

Torque引擎的渲染效果。

14.1.3.9 Source Engine

Source Engine是由Valve Software開發的屢獲殊榮的3D遊戲引擎，最初在1994年被發行出來，被認為是市場上最先進的遊戲引擎之一，支援諸如使用Havok引擎的逼真模擬物理、DirectX 9.0支援（包括高動態範圍照明、骨骼動畫、聲音系統和許多其它功能）等功能。它是成功的知名遊戲《半條命 2》所依賴的引擎。

源引擎附帶可用於構建遊戲模組的Source SDK，該SDK對半條命2遊戲的所有者免費提供，並提供了對Valve自己用來創建半條命2系列遊戲、失敗之日源、反恐精英源和即將推出的遊戲（包括傳送門和軍團要塞 2）的工具的訪問許可權。它也被包括Ritual the creators在內的許多獨立開發者使用。

2010前後的Source引擎應用了快速、可靠和靈活的技術，使用以下許多功能呈現計算或渲染密集型遊戲：

  • Direct3D（在Windows 95及更高版本、Xbox 和 Xbox 360 上渲染）。
  • OpenGL（在Mac OS X和PS3上渲染）。
  • HDR（高動態範圍），HDR 僅在《半條命》的《失落海岸》中引入，而沒有在《半條命 2》單人遊戲中引入。
  • 具有自動生成唇形同步功能的面部動畫系統。
  • 想要修改遊戲的人的源程式碼。
  • 混合骨骼動畫系統。
  • 一個模型查看器，用於查看您的角色在不同著色器中的樣子。
  • 放置凹凸貼圖、紋理等的材質系統。

Source引擎的架構和特性。

使用 Source引擎的Vindictus遊戲截圖。

14.1.3.10 Frostbite

Frostbite是EA Digital Illusions CE（DICE）開發的一款內部遊戲引擎，專為在Windows、PS系列 、Xbox 系列上的跨平台使用而設計X/S系列。該遊戲引擎最初用於戰地遊戲系列，但後來擴展到其它第一人稱射擊影片遊戲和各種其它類型。Frostbite一直是由Electronic Arts發行的遊戲所獨有的，迄今為止已經發布了3個大版本，其代表作有戰地系列、FIFA系列、極品飛車系列、植物大戰殭屍系列、星際大戰系列等等遊戲。



用Frostbite研製的部分遊戲截圖。從上到下依次是：Need for Speed Heat、Battlefield 2042、Star Wars: Squadrons。

Frostbite雖然是DICE的內部引擎，不對外發行和授權，但因為Frostbite的研發成員活躍於Siggraph、GDC等國際技術峰會，常在峰會上分享最新的渲染技術和研究成果，而享譽盛名於遊戲行業。Frostbite公開分享的技術文章列表可參見：EA Tech Blog。

14.1.3.11 Anvil

Ubisoft Anvil（直到2009年稱為Scimitar，直到2020年稱為AnvilNext）是由Ubisoft Montreal創建並用於2007年遊戲刺客信條的遊戲引擎，包含Scimitar、Anvil、AnvilNext、AnvilNext2.0、Ubisoft Anvil等分支。引擎用於Microsoft Windows、Nintendo Switch、PlayStation 3、PlayStation 4、PlayStation 5、PlayStation Vita、Wii U、Xbox 360、Xbox One、Xbox Series X/S 和 Stadia等平台。專為主機遊戲刺客信條打造，後來被用於刺客信條系列、湯姆克蘭西的幽靈行動等遊戲中。

Ubisoft Anvil圖標。

Anvil引擎使用Autodesk的HumanIK中間件在運行時正確定位角色的手和腳以進行攀爬和推動動畫。添加的功能包括完整的晝夜循環、增強的繪製距離、與孤島驚魂 2 相同的植被技術、改進的照明、反射和特殊效果、新的布料系統以及新的AI和NPC導航系統。

AnvilNext增加了對新天氣系統的支援，該系統允許特定的天氣設置以及在刺客信條IV中看到的自動循環模式。其次，渲染器被重寫以提高效率並支援額外的後處理技術，最多可以實時渲染3000個不可播放的角色。最後，AnvilNext 添加了來自Far Cry 4的技術，以支援更加動態的沙盒環境和新的水技術，遊戲世界可能會隨著時間的推移而變化，具體取決於玩家的行動和進展。更重要的是，從刺客信條Unity 開始的AnvilNext能夠以靈活和自動的方式生成結構，同時遵循特定的設計規則和模板，從而減少藝術家和設計師創建錯綜複雜的城市環境所需的時間和人力。AnvilNext還為不可玩角色提供了改進的AI。

渲染方面，該引擎支援預烘焙的全局照明、反射映射、體積霧、動態天氣和動態樹葉等等，還有基於物理的渲染 (PBR) ，使材質、對象和表面能夠更逼真地查看和反應照明、陰影和陰影。此外，通過添加體積技術，全局照明系統現在更加逼真，以物理為導向的對象反應更加逼真，並且布料在主角、環境和其他角色上的表現更加逼真。世界現在支援更大的陸地、更多的物體、更大的建築物、無需載入螢幕即可訪問的建築物內部，以及許多其他增強視覺保真度、沉浸感和遊戲玩法的附加功能。

代表作有刺客信條系列、For Honor、Tom Clancy's Rainbow系列等等。

Assassin's Creed Valhalla的打鬥畫面截圖。

14.1.3.12 Destiny Engine

Destiny引擎是遊戲公司Bungie研發的遊戲引擎，用於開發自家的Destiny系列遊戲。

2013年，《命運》的大部分基礎工作已經完成，包括傳說、遊戲引擎以及許多環境和任務。

Destiny1代遊戲採用了一種新的遊戲引擎，稱為Tiger Engine，它基於大多數Halo遊戲所使用的引擎，允許全局光照和實時動態光照同時運行。此外，Bungie的目標是Destiny將在Xbox One和PlayStation 4上以1080p原生渲染圖形。Bungie的「漏斗」技術創新是Halo配對系統的支柱，允許更好的玩家配對，以便在合作或競爭的多人模式中創造更自然的體驗。但是，Bungie的開發人員批評新引擎不適合遊戲的在線性質，引擎的資源密集型特性使得即使是對地圖的微小更改也需要通宵渲染和編譯過程，新地圖和任務的開發是「艱苦的」。

此外，Destiny的多執行緒並行技術運用得爐火純青，並引入到場景渲染的各個階段。

Destiny引擎的場景渲染並行化圖例。

Destiny 2遊戲截圖。

14.1.3.13 RE Engine

RE引擎（全稱Reach for the Moon Engine）是由Capcom公司創建的影片遊戲引擎。最初是為《生化危機 7：生化危機》設計的，後來被用於該公司的各種遊戲，例如Devil May Cry 5和Monster Hunter Rise。該引擎是Capcom之前的引擎MT Framework的繼承者。

RE引擎對MT框架進行了各種改進，包括新的抗鋸齒和體積照明功能。該引擎還允許開發人員使用攝影測量來創建更高品質的資產，包括比其前身改進的VR支援，使其能夠達到避免眩暈所需的高幀率，支援使動畫更快的工具，例如模組化裝配、運動匹配、程式動畫和運動重定向，還具有各種新的物理模擬選項，允許更逼真的碎片。

代表作包含生化危機系列、怪物獵人、鬼與妖精的復活等。

Resident Evil Village遊戲場景截圖。

14.1.3.14 RedEngine

RedEngine由CD Projekt開發和維護，主要針對3A級主機遊戲的研發，雖然它的名字鮮有人知，但其研發的遊戲卻是鼎鼎有名，遊戲代表作有巫師系統、賽博朋克2077等。

賽博朋克2077遊戲截圖。

14.1.3.15 RAGE

RAGE全稱Rockstar Advanced Game Engine，是由RAGE Technology Group開發的專有遊戲引擎，RAGE Technology Group是 Rockstar Games的Rockstar San Diego工作室的一個部門。自2006年第一款遊戲Rockstar Games Presents Table Tennis面向Xbox 360和Wii發布以來，Rockstar Games的內部工作室一直在使用該引擎為遊戲機和電腦開發先進的開放世界遊戲。

早期的RAGE特性有角色動畫引擎、物理引擎、處理大型流媒體世界的能力、複雜的 AI 安排、天氣效果、快速的網路程式碼和多種遊戲風格，支援DirectX 11和個人電腦的立體3D渲染，以及更強大的繪製距離、紋理過濾以及改進的陰影映射和曲面細分品質。

隨著2018年Red Dead Redemption 2的發布，RAGE將進一步完善，支援基於物理的渲染、體積雲和霧值、預先計算的全局照明以及Windows版本中的Vulkan渲染器，還可以創建先進的 AI 以及增強的遊戲物理和動畫，HDR渲染以及深度學習超級取樣 (DLSS) 的支援。

遊戲代表作有荒野大鏢客（Red Dead Redemption）系列、俠盜獵車手（Grand Theft Auto）系列等。

Red Dead Redemption 2遊戲截圖。

14.1.3.16 PhyreEngine

PhyreEngine是Sony的一款僅許可免費使用的遊戲引擎，兼容PlayStation系列平台、 Windows（OpenGL、DirectX 11）、Android和iOS。

PhyreEngine以可安裝包的形式獨家分發給Sony被許可人，其中包括完整的源程式碼和Windows工具，根據其自己的靈活使用許可提供，允許任何PlayStation遊戲開發商、發行商或工具和中間件公司部分或完全基於創建軟體在任何平台上的PhyreEngine上。該引擎使用針對 PS3單元寬頻引擎的協同處理器單元 (SPU) 優化的複雜並行處理技術，但可以輕鬆移植到其它多核架構。

除了低級PS3 LibGCM庫之外，PhyreEngine還支援OpenGL和Direct3D，提供功能齊全的「遊戲模板」作為源程式碼，包括對Havok 、PhysX 、Bullet等物理引擎的支援。

PhyreEngine已被多家遊戲工作室採用，並已用 200多個已發布的遊戲中。遊戲代表作有最終幻想系列、英雄傳說系列等。

14.1.3.17 Irrlicht

Irrlicht引擎可以使用 OpenGL、DirectX 或軟體進行渲染，可以在在 Windows 和 Linux 上運行。技術上，Irrlicht使用了分層場景圖進行場景管理，並具有基本的 2D GUI功能。

Irrlicht比同期的其它引擎要小巧一些，只有一個主要開發人員，但是在當時有一個龐大的愛好者支援社區。 它還提供基本的物理常式，但缺少任何網路功能。並且，Irrlicht以圖形品質和渲染速度比其它軟體差而聞名，被更容易開發所抵消，通常被視為理想的初學者引擎。



Irrlicht引擎渲染畫面截圖。

14.1.3.18 XNA

Microsoft的XNA Game Studio是一個易於使用且高度可訪問的遊戲開發平台，旨在鼓勵玩家創建自己的遊戲並與在線遊戲社區分享。

XNA基於C#和公共語言運行時 (CLR)。主要的開發環境是Visual Studio或其免費對應物Visual Studio Express，其源程式碼和遊戲資產等所有內容都在Visual Studio中進行管理。藉助XNA，開發人員可以為PC、 Xbox 360控制台創建遊戲。通過以基本為零的成本提供出色的工具，微軟出色地為普通人打開了創造新遊戲的閘門。

XNA研發的遊戲Barotrauma遊戲截圖（2019）。

14.1.3.19 其它引擎

在2004前後，FPS 類型中，有三個主要的遊戲引擎系列，每個系列都由不同的開發者組成：id Software的Doom 3和Quake 3引擎、Valve Software的Half Life和Half Life 2引擎和Unreal Tournament (UT)和 Epic Games的 Unreal Tournament 2004 (UT2004) 引擎。

毀滅戰士3、半條命2和UT2004代表了每個開發者的最新一代，並且是當時可用的最佳遊戲引擎。Quake 3、UT和Half Life是上一代引擎。應該注意的是，Half Life引擎是基於Quake 和 Quake 2引擎的。

所有這些引擎都功能齊全，並且基於這些引擎中的每一個都存在一個或多個完整的遊戲，與上面的大多數開源引擎形成鮮明對比，後者提供了更多基本功能。開源引擎通常需要與其它庫和工具包結合才能創建可玩的遊戲，Quake 3值得特別提及，和其它引擎不同，可以被開發人員進行大量修改。 另一個應該提到的引擎是GarageGames的Torque。它是一種廉價的商用引擎。

此外，還有Cocos2d系列、Panda 3D、OpenSceneGraph、Delta3D、Blender Game Engine、GameMaker、Godot、bgfx、Unigine、Delta3D等等引擎或渲染器。

Blender Game Engine編輯器和渲染效果圖。

下面是另外一些引擎的特點描述：

下表是部分遊戲引擎的說明：

名稱 公司 許可 代表作 備註
4A Engine 4A Games 專用 Metro 2033, Metro: Last Light, Metro Exodus
A-Frame (VR) Google MIT - 開源Entity組件系統WebVR框架
Alamo Petroglyph Games 專用 星際大戰
Anvil Ubisoft 專用 刺客信條、湯姆·克蘭西的彩虹六號
BigWorld BigWorld Technology 專用 坦克世界、天下
Blender Game Engine Blender Studio GPL-2.0+ Yo Frankie!, Sintel The Game 2D/3D遊戲引擎封裝在3D模型中，集成子彈物理庫
Cocos2d 多個 MIT Geometry Dash 中國是Cocos2d-x/3d引擎
Creation Engine Bethesda Game Studios 專用 上古捲軸、輻射
CryEngine CryTek 專用 孤島危機、孤島驚魂
Dark Engine Glass Studio 專用 Thief: The Dark Project、System Shock 2、 Thief II: The Metal Age 高級 AI 和聲音功能（完全控制聲音傳播）
Decima Guerrilla Games 專用 死亡擱淺、地平線零黎明、殺戮地帶：暗影墜落、直到黎明、直到黎明：鮮血狂潮
Dunia Engine Ubisoft 專用 全境封鎖 基於CryEngine
EGO Codemasters 專用 F1系列 主要用於賽車遊戲
Essence Engine Relic Entertainment 專用 帝國時代4、戰錘、英雄連3
Fox Engine Konami 專用 實況足球
Frostbite Ubisoft DICE 專用 戰地、FIFA、星球大戰
Gamebryo Gamebase 專用 攻殼機動隊：獨立情結、冒險島2
GameMaker Studio YoYo Games 專用 警察故事、死亡詭計
Glacier IOI 專用 殺手系列、自由戰士、迷你忍者、凱恩與林奇系列
Godot Argentina MIT 殘酷小隊、硬編碼、轉儲王國、Keen in Keen Dreams 3.0+通過模組和GDNative添加了C#腳本和其它語言、PBR和全局照明。
HeroEngine Simutronics 專用 星球大戰：舊共和國
id Tech id Software 專用 Doom、Quake、憤怒、德軍總部：新秩序、德軍總部：舊血、內心的邪惡 從Doom和Quake發展而來，早期版本部分開源
Irrlicht Nikolaus Gebhardt zlib Minetest
IW Engine Infinity Ward 專用 使命召喚系列 最初基於id Tech 3構建
Jade Ubisoft 專用 Rayman Mini、Space Junkies、Tom Clancy's Ghost Recon Breakpoint
Kinetica Sony 專用 戰神
MonoGame / XNA Microsoft Microsoft Public 幕府將軍的骷髏、泰拉瑞亞、堡壘、塔樓墜落、電晶體、非斯、公理邊緣
Odyssey Engine BioWare 專用 星球大戰：舊共和國騎士團，星球大戰：舊共和國騎士團II：西斯領主
OGRE - MIT Torchlight, Kenshi
OGRE-Next - MIT - OGRE的下一代引擎
Panda3D - BSD 卡通城在線，加勒比海盜在線
PhyreEngine Sony 專用、免費 英雄傳說：步入遐想、天空：光之孩子
Real Virtuality Bohemia GPL-2.0+ ARMA 2、ARMA 3、DayZ
RedEngine CD Projekt 專用 巫師 2：刺客之王、巫師 3：狂獵、賽博朋克 2077
RAGE RAGE Tech 專用 荒野大鏢客1和2、俠盜獵車手
RPG Maker ASCII 專用 女巫之家、Escaped Chasm
SAGE Westwood Studios、 EA 專用 指環王系列、命令與征服系列
ShiVa ShiVa Technologies 專用 波斯王子2：陰影與火焰
Silent Storm engine Nival Interactive 專用 寂靜風暴、守夜人、鎚子和鐮刀、日間守夜人 用於回合制戰術遊戲
Source Valve 專用 半條命2、反恐精英：來源、Left 4 Dead、傳送門、軍團要塞2、Dota 2、實驗室、神器、半條命:Alyx 第一款使用Source 2的遊戲Dota 2是從原始 Source引擎移植過來的，The Lab的一個迷你遊戲Robot Repair使用Source 2引擎，而其餘七個使用Unity的引擎。
TOSHI Blue Tongue 專用 侏羅紀公園：創世紀行動、尼克卡通聯盟、·里維拉歷險記、漫威超級英雄小隊
Torque3D GarageGames MIT Marble Blast Gold、Tribes 2、Blockland 包括多人網路程式碼、無縫室內外渲染引擎、骨骼動畫、拖放 GUI 創建、內置世界編輯器、類 C 腳本語言
UbiArt Framework Ubisoft Montpellier 專用 雷曼起源、雷曼傳奇、光之子、勇敢的心：大戰
Unigine Unigine 專用 Dual Universe 專註於大型開放場景：64位精度坐標，支援地理坐標，圓形地球模型，主要用於企業和專業模擬器。
Unity Unity Technologies 專用 天刀、原神、最終幻想、王者榮耀、爐石傳說
Unreal Engine Epic Games 專用 和平精英、黑神話悟空、蝙蝠俠、最終幻想重製版 UE4刪除了UnrealScript

以上只是其中部分引擎，更詳細的參見：List of game engines。

14.1.4 遊戲引擎簡史

電腦遊戲已經走過了漫長的道路，從1962年的太空大戰到在21世紀最大的媒體中佔據一席之地，在總收入方面甚至超過了電影行業。從技術上講，電腦遊戲就像任何其它電腦程式一樣，由源程式碼模組組成。有人定義的遊戲引擎指的是與遊戲內容分離的模組部分：行為或環境。就像汽車的引擎一樣，遊戲引擎是遊戲的技術核心，遊戲的內容就建立在它之上。

關於遊戲引擎的確切含義存在一些混淆，遊戲引擎被定義為「不直接指定遊戲行為（遊戲邏輯）或遊戲環境（關卡數據）的模擬程式碼模組的集合」。在引擎的模組中，遊戲世界的輸入處理、輸出（3D、2D 和聲音）以及通用物理和動力學。遊戲引擎作為對遊戲實際內容沒有影響的模組，包括輸入、音頻、圖形、動態和事件循環。

設計和開發軟體組件是一個成本高昂且耗時的過程，因此遊戲開發人員通常在經濟上更好地投資於現成的引擎而不是開發自己的引擎，重複使用優質組件也提高了整個產品的整體品質。構建新軟體不可避免地會導致「重新發明輪子」，與以前創建的軟體相比，程式碼重複估計高達85%。

在實踐中，遊戲引擎通常會根據特定遊戲的內容風格進行調整，但會損害引擎在不同風格遊戲中的重用性。大多數引擎都是為在特定平台上運行特定遊戲而設計的，引擎越通用，在特定平台上運行特定遊戲的優化程度就越低。更一般地說，構建可重用的軟體組件所花費的精力是構建一次性組件的三倍。因此，雖然重用現有遊戲引擎具有相當的價值，但每個人都構建自己的可重用引擎或每個遊戲引擎都可重用（或者甚至與遊戲的其它部分分開）則沒有意義。

在上個世紀80年代之前，由於沒有遊戲引擎，每個遊戲都需要重複造輪子，必須針對所使用的特定硬體進行構建，多個發行平台意味著從頭開始重寫遊戲，對遊戲開發團隊而言，意味著多倍的又重複的工作。

到了80年代，遊戲引擎的前身概念出現，以Pinball Construction Set (Bill Budge)為例，售出超過300000份。

Pinball Construction Set遊戲畫面（1982）。

Pinball Construction Set定義了一種新型的產品：遊戲構建系統，包含IDE、命令行介面、精靈編輯器、模型編輯器、地圖/場景編輯器等。

到了1990年代，遊戲創建系統實際上就是遊戲引擎，遊戲引擎的術語正式開始出現，由id Software引入，在Wolfenstein 3D（德軍總部 3D）的FPS遊戲中展現，引擎名為Fast 3D Engine（實際是2.5D）。

早期遊戲引擎經歷的3個階段。

id Software隨後發布了正式版遊戲引擎Doom和Quake系列。Doom引擎的特性包含紋理映射、非正交牆、光源衰減/光源、可變高度的地板和天花板、環境動畫和變形、調色板轉換、多玩家等。Quake引擎則支援降低3D複雜性以提高速度、預先計算光照和陰影（光照貼圖）、分割地圖以提高速度、快速渲染、渲染順序、硬體3D加速、網路遊戲等。

初代Quake引擎的最低系統要求和渲染畫面。

在隨後的1999，Quake引擎在GPL下發布，由此衍生了龐大的Quake引擎家族。（下圖）

id Tech引擎家族樹。

Stardock遊戲引擎發展歷程。

從上世紀90年代到如今，遊戲引擎已經經歷了30多年的發展，勢頭迅猛，衍生出一代又一代的經典技術和架構，湧現許多通用的引擎和內部引擎，由此幫助了數量眾多的遊戲開發團隊和公司，創作出了許許多多耳熟能詳的遊戲作品。

上世紀90年代，遊戲引擎還處於混沌期和萌芽期，很多遊戲開發團隊尚沒有使用遊戲引擎，只對基礎和通用的模組進行部分抽象，在各個項目之間進行複製。這種模式是處於低級的復用，更別談擴展性、維護性和易用性了。

沒有遊戲引擎的助力，加之遊戲技術和硬體的限制，當時的遊戲畫面極其粗糙，顏色位深有限，像素嚴重不足，顆粒感十足。（下圖）



上：Saboteur II（1989）；中：Xenon 2（1990）；下：Prince of Persia 2（1995）。

到了上世紀90年代，以ID公司的Doom和Quake系列引擎和Epic公司的Unreal引擎開始面世，諸多通用的功能模組、亮眼的遊戲畫面和較為易用的編輯器，使得它們成為當時的主流遊戲引擎。（下圖）


上世紀90年代的Doom、Quake、Unreal引擎的遊戲畫面。

早期的遊戲引擎編輯器介面。

2000年前後，Quake和Unreal引擎發展到了第三代，部分遊戲引擎發展的描述和時間線如下圖所示：

關於Doom、Quake、Unreal引擎更詳細的時間線如下圖所示：

引擎核心模組愈來愈多，尤其引擎渲染、粒子等效果的完善，使得遊戲也愈發炫酷。

2008年發行的用UE3研製的音樂類遊戲Nurien Mstar Online。

在隨後的短短數年間，各類遊戲引擎如雨後春筍般湧現，除了老牌的Quake、Unreal、CryEngine外，還誕生了Torque、BigWorld、Gamebro、Irrlicht、OGRE等等引擎，觸發了百擎大戰的序幕。這股風潮也吹到了中國，幾乎每個遊戲公司都有引擎團隊，做自研引擎工作或對國外引擎進行二次改造。那時候的許多引擎程式設計師都有個夢想，那就是擁有個人的遊戲引擎。

隨著遊戲品質要求的提高，對引擎技術、工具鏈的要求越來越高，許多技術底子本就不深厚的團隊逐漸無法滿足需求，敗下陣來，從歷史的舞台褪去。逐漸形成了少數技術雄厚的老牌遊戲引擎鼎立的架勢，引擎的天下被他們分而治之。

其中後起之秀就有Unity引擎，它以小巧、跨平台、簡單易上手著稱，被廣泛用於移動遊戲和網頁遊戲。Unity以Entity-Component的場景對象結構為核心，簡化了場景節點管理，提升了可擴展性，避免以往的以繼承為主的類型爆髮式增長。後續在Entity-Component的基礎上，發展成了ECS（Entity-Component-System）。

Unity的GameObject-Component模式。

Unreal的繼承和Entity、Component相結合的模式。

遊戲對象以各種方式相互關聯，可以繪製描述這些關係的圖表，任何這樣的圖表都可以作為事件的分發渠道。

和ECS伴隨著的是從面向對象設計（OOD）向面向數據設計（DOD）的轉變，以便明確區分實例、組件、系統並各司其職，將適用於具有某些組件集的實體的程式碼形成系統，結合Structure-of-Arrays (SoA)的數據布局，利用線性遍歷提升記憶體訪問效率，提升快取命中率，從而提升效率。

OOD和DOD在記憶體布局上的區別。

SOA記憶體布局示意圖。

隨著功能的增加，技術的發展，現代引擎由工具套件和運行時組件組成，在引擎架構上，將硬體擴展到高級應用程式，基於的分層設計，避免循環依賴以最大化重用和可測試性。

遊戲引擎架構圖。採用了分層模式，包含了遊戲相關的子系統、核心系統、資源管理器、渲染引擎、前端、平台抽象、低級組件、第三方庫等分層。

以上跟渲染強相關的分層或跟模組是渲染引擎，它分為低級渲染器、場景圖管理、視覺效果、前端等層級。

低級渲染器專註於儘可能快速和豐富地渲染圖元，不考慮可見性，圖形設備相關介面（訪問和枚舉圖形設備、初始化 GD、設置緩衝等），還有、幾何圖元的表示、相機介面的抽象、材質系統、動態照明系統、文字和字體等。

低級渲染器的模組詳情。

場景圖限制提交渲染的圖元數量，使用截錐體剔除——移除可見螢幕之外的東西，採用空間細分結構（BSP、四叉樹、八叉樹、kd-tree）。

場景圖的模組詳情。

場景圖的一個案例。

視覺效果包含粒子系統、貼花系統、光照映射、動態陰影、全螢幕後期效果等模組。

前端包含HUD、菜單、用於字元操作的 GUI、用於過場動畫的全動態影片等。

另外，DCC工具和資產的數據流如下圖所示：

面對大型遊戲，涉及的資產非常龐大，需要一種方法來存儲和管理大量數據，一些公司使用關係資料庫（MySQL 或甲骨文），一些公司使用版本控制軟體（SVN、Perforce 或 GIT），還有一些人使用訂製軟體，例如頑皮狗使用一個名為Builder的自定義GUI。

獨立和集成兩種方式的工具架構圖。

另外，還涉及基於網頁的工具，用於各種用途（資產管理、調度、錯誤管理），更容易構建，通常比獨立應用程式更容易構建，無需強制重新安裝即可輕鬆更新，如果它只需要顯示錶格數據並有表格 - 使用網頁介面。

Integrating Architecture Soar Workshop探討了如何集成不同引擎、技術棧研究的架構設計。（下兩圖）


網路技術的發展給遊戲引擎的網路模組增強了動力，使得大型多人在線遊戲蓬勃發展並取得矚目的成績，最典型的例子便是暴雪的魔獸世界，開啟了日常跑團副本的先鋒。（下圖）

圖片顯示了魔獸世界遊戲中的一個大型活動現場，有成千上萬的玩家在同一個地方實時地交流和互動。

時間來到2010年前後，移動設備智慧化的趨勢明顯，以iOS的移動端系統和iPhone 4的硬體設備在全世界範圍內廣泛追捧，自此拉開了移動設備智慧化的歷史進程。遊戲作為智慧移動設備的首要功能，自然成為中國外遊戲廠商的目標，因而他們都在轉型到移動遊戲開發。

2008年到2012年的遊戲份額圖例，其中移動端的遊戲佔比逐年增加。

2017年移動端遊戲的佔比已達29%。

Unity作為小而精的代表，敏銳地察覺到移動端的商機，於是避開PC上的已然存在的眾多老牌遊戲引擎的競爭，集中精力轉向移動端的研發之路。

2012年的Unity已經支援移動端的開發。

與此同時，由於單核CPU摩爾定律逐漸接近天花板，CPU廠商往多核的方向發展，因此，遊戲引擎也在順應多核並行化發展。

CPU的核心、頻率、性能、電晶體從1970到2014年的趨勢圖。

並發引擎架構的層級。從上到下劃分為引擎系統層、內核層、框架層、作業系統層。

並發引擎的循環步驟示意圖。

另外，由於移動設備的特性，對性能異常敏感，並行化也是其趨勢之一。The Benefits of Multiple CPU Cores in Mobile Devices闡述了在移動端多核CPU的技術，如何在SMU、ARM架構的CPU上協同地和NV的Tegra 2的GPU完成並行化任務，以達到性能最大化並且省電。

雙核ARM Cortex A9 MPcore架構。

雙核CPU的電壓和頻率擴展優勢。

多核化的設備使得主流遊戲引擎能夠充分利用多執行緒的優勢，完成很多並行化的任務。下圖是其中部分遊戲引擎的執行緒數量：

下圖是遊戲Dungeon Defender使用了NVIDIA Tegra處理器的兩個內核：

同期的Frostbite是另一個使用基於作業的並行性的遊戲引擎示例，它能夠使用底層硬體平台提供的儘可能多的執行緒。引擎在GPU上執行主要的Game和Render任務，並將其它系統相關的工作劃分為作業。每個作業通常包含15K到200K行C++程式碼，平均作業大小約為25K行程式碼。 大多數這些工作是獨立的，而一些具有多執行緒遊戲使用兩個 CPU 內核相互依賴。遊戲的每一幀通常包含200到300個作業，並且引擎將作業分配給所有可用的硬體內核。

Frostbite引擎上的任務級並行性。

上圖中的每種顏色都代表Frostbite啟動的一個作業，該數據是使用Frostbite Timing View軟體在具有四核CPU和兩個處於AFR模式的GPU的PC系統上收集的，從圖中很容易看出，遊戲引擎有效地使用了所有可用的內核進行任務處理。因此，這些遊戲引擎將能夠有效利用 NVIDIA Tegra的兩個CPU內核和ULP GeForce GPU內核，並提供無與倫比的遊戲機風格遊戲體驗，這種並行技術成功地應用在了Battlefield: Bad Company等遊戲上。

啟用了多核之後，在Quake引擎上的幀率可以提升1.6倍以上，而遊戲Dungeon Defender的幀率提升2倍以上。（下圖）


在渲染技術方面，以暴雪的Naty Hoffman、迪斯尼的Brent Burly、Epic Games的Brian Karis等行業科研人員率先在實時渲染嘗試PBR技術的應用。

PBR涉及的部分演講如下：

Naty Hoffman：Physically Based Shading Models for Film and Game Production

Brent Burly：Physically Based Shading at Disney

Brian Karis：Real Shading in Unreal Engine 4

以下是主流引擎支援PBR的時間表：

  • Unreal Engine 4：《Real Shading in Unreal Engine 4》，SIGGRAPH 2013
  • Unity 5：《Physically Based Shading in Unity》，GDC 2014
  • Frostbite（寒霜）： 《Moving Frostbite to PBR》，SIGGRAPH 2014
  • Cry Engine 3.6：《Physically Based Shading in Cry Engine》，2015

隨後PBR技術逐漸在主流渲染引擎中普及開來，成為實時互動遊戲的標配技術和標準工作流。



從上到下：Naty Hoffman科普PBR技術、迪斯尼原則的PBR參數化預覽、UE4的PBR效果。

2015年前後，基於現代化的新生代圖形API橫空出世，典型的代表是Vulkan和DirectX 12。它們的共同特點是將諸多控制權由驅動程式轉移到了應用程式層。具體地說，新的圖形AP的特點有：

  • 允許多執行緒命令緩衝區記錄。

  • 減少運行時/驅動程式的工作量。

  • 減少運行時驗證。

  • 將工作移至初始化/載入時間（例如管道設置）。

  • 更明確地控制硬體。

  • 減少便利功能。

  • 精確地管理記憶體。

    DX12的資源管理圖例。

這樣的轉變使得遊戲引擎有了更多的控制圖形API的機會，以便做極致的渲染優化。並行化命令錄製、多執行緒渲染、記憶體精確管理和基於整幀優化的渲染圖（亦被稱為幀圖）等技術就此誕生。

Frostbite引擎採用幀圖方式實現的延遲渲染的順序和依賴圖。

UE作為老牌的追求渲染品質的遊戲引擎，在2018年改變了原來的市場格局，在Steam平台上顯示，25%左右的遊戲採用它來製作，一舉超過了Unity，穩坐榜首。（下圖）

在Steam上發布的遊戲中使用的遊戲引擎（數據來自2018-12-20）。

此外，現代圖形API以及GPU渲染管線的進步，使得某些以往受限的渲染技術得到蓬勃發展，例如GPU驅動的渲染管線、基於Cluster的渲染、光線追蹤及實時全局光照等等。

GPU驅動的渲染管線概覽。

光柵化、計算著色器和光線追蹤的混合渲染管線。

基於面元（surfel）全局光照的面元可視化。

有了以上技術的強力支撐，使得當前的遊戲達到了影視級的畫質，最突出的便是利用UE5的Nanite和Lumen等技術研製出的《黑客帝國》Demo以及遊戲科學的《黑神話：悟空》。

近些年，圖形API標準已經支援人工智慧，Nvidia率先在RTX系列GPU晶片上集成了Tensor Core，由此基於深度學習的人工智慧技術也大量地引入到圖形渲染和遊戲引擎當中，例如光線追蹤降噪、DLSS、智慧化NPC的AI、風格化渲染等等。

DLSS關閉（左）和開啟（右）的對比圖，幀率提升了71%。

DLSS在部分3A遊戲上的加速比例圖。

此外，除了傳統的PC、主機等實時渲染平台，移動端、XR、網頁端和雲端渲染等分支也得到了較大的發展。

2018年主流商業引擎支援VR、移動等平台的表格。

2020年的移動端市場份額，達到770億美元，在新冠的陰霾下依然逆勢同比增長13.3%。

其中由於XR設備比普通移動設備對頻寬、電量、性能更加敏感，於是誕生了注視點渲染、多視圖渲染、可變著色率、插值、預測、時間扭曲、多執行緒等等優化技術。

用於優化VR等渲染的MultiView對比圖。上：未採用MultiView模式的渲染，兩個眼睛各自提交繪製指令；中：基礎MultiView模式，復用提交指令，在GPU層複製多一份Command List；下：高級MultiView模式，可以復用DC、Command List、幾何資訊。

Arm在UE上使用4-視圖的多視圖進行注視點渲染，可以減少65%的渲染工作量。

14.1.5 內容概要

本篇將時間作為主線，劃分成幾個部分：

  • 萌芽期（1999之前）
  • 成長期（2000~2009）
  • 開花期（2010~2015）
  • 結果期（2016~2021）

內容主要圍繞著遊戲引擎的架構和渲染部分，但不僅僅限於此，還包含相關的模組或筆者認為值得關注的內容。

 

14.2 萌芽期（1999之前）

遊戲引擎始於1990年代中期，尤其是與第一人稱射擊遊戲 (FPS) 等3D遊戲相關，也就是Doom（下圖）和Quake遊戲的流行，其他開發人員不用從頭開始工作，而是授權軟體的核心部分並設計自己的圖形、角色、武器和關卡。

左：Doom遊戲截圖；右：Doom 3遊戲截圖。

儘管遊戲引擎的術語在1990年代才首次使用，但在1980年代也有一些較早的系統也被認為是遊戲引擎，例如Sierra的AGI和SCI系統、LucasArts的SCUMM系統和Incentive Software的Freescape引擎。然而，與大多數現代遊戲引擎不同，這些遊戲引擎從未用於任何第三方產品。後來的遊戲，例如Quake III Arena和Epic Games的1998 Unreal，在設計時就考慮到了這種方法，引擎和內容是分開開發的。至少，可重用引擎使開發遊戲續集變得更快、更容易，這在競爭激烈的電腦遊戲行業中是一個寶貴的優勢。

左：Unreal的Skaarj角色截圖；右：Unreal 3的Berserker角色截圖。

在早期的PC開發遊戲，最簡單的遊戲循環如下所示（想必學過windows開發的同學肯定接觸過）：

// 開始消息循環
MSG kMsg;
while ( TRUE )
{
    // 優先處理消息
    if ( PeekMessage(&kMsg,(HWND)0,0,0,PM_REMOVE) )
    {
        if ( kMsg.message == WM_QUIT )
            break;
        HACCEL hAccel = (HACCEL)0;
        if ( !TranslateAccelerator(hWnd,hAccel,&kMsg) )
        {
            TranslateMessage(&kMsg);
            DispatchMessage(&kMsg);
        }
    }
    else // 空閑循環
    {
        // 繪製調用
        Draw();
    }
}

上面的Draw函數繪製過程（OpenGL為例）的最簡單的實現如下：

void Draw()
{
    // 清理緩衝區顏色
    glClear(GL_COLOR_BUFFER_BIT);
    // 設置渲染狀態
    glDisable(GL_CULL_FACE);
    // 設置模型到世界的變換
    glMatrixMode(GL_MODELVIEW);
    glPushMatrix();
    glMultMatrixf(gs_afMatrix);
    // 繪製三角形
    glBegin(GL_POLYGON);
    glColor3f(gs_afColor0[0],gs_afColor0[1],gs_afColor0[2]);
    glVertex3f(gs_afVertex0[0],gs_afVertex0[1],gs_afVertex0[2]);
    glColor3f(gs_afColor1[0],gs_afColor1[1],gs_afColor1[2]);
    glVertex3f(gs_afVertex1[0],gs_afVertex1[1],gs_afVertex1[2]);
    glColor3f(gs_afColor2[0],gs_afColor2[1],gs_afColor2[2]);
    glVertex3f(gs_afVertex2[0],gs_afVertex2[1],gs_afVertex2[2]);
    glEnd();
    // 恢復之前的變換
    glMatrixMode(GL_MODELVIEW);
    glPopMatrix();
    // 交換緩衝區，將後台緩衝區複製到前台緩衝區
    SwapBuffers(gs_hWindowDC);
}

當然，以上只能對應簡單案例，例如繪製Hello World這樣的場景。對於複雜的場景，需要引入更多技術、加入更多調用，從而形成更複雜的遊戲主循環。下圖是3D Game Engine Architecture提及的一種場景節點的交互圖：

空間類、節點類、幾何類和渲染類之間的相互關係。

在當時，場景的節點組織結構以繼承為主（尚未出現Entity-Component和ECS），物體的數據結構以Entity為節點：

早期遊戲場景的Entity節點結構圖例。

早期遊戲場景的Entity節點結構圖例2。

隨著時間遷移，各種新興的渲染技術和硬體的進步（如紋理映射、抗鋸齒、像素和頂點著色、改進的陰影生成、增加的記憶體頻寬、增加的填充率……），使得遊戲的環境更加逼真，而且它們也愈加複雜、絢麗。（下圖）

id公司研發的遊戲隨時代演變的畫面。從左上到右下依次是Wolfenstein 3D（1991）、DOOM（1994）、Quake（1996）、Quake 3（1999）、DOOM 3（2004），肉眼可見的畫質進步。

隨著物體、光源的增加，渲染技術越來越複雜，使得渲染狀態需要執行複雜的管理，以便提升效率。下圖是3D Game Engine Architecture闡述的渲染狀態更新技術：

更新渲染狀態的情況。通過樹狀結構，遊戲引擎可以方便地收集依賴關係和渲染狀態。

在光照上，此時期的遊戲常以多紋理獲得光照效果。（下圖）

多重紋理以獲得暗圖和光圖。左上：木質的主要紋理，右上：與主要紋理結合的次要紋理，左下：一張暗圖，下中：使用硬疊加的光照圖，右下：使用軟疊加的光照圖。

CryEngine1為太陽陰影提供了陰影貼圖和每個對象的投影陰影。為了提升性能，預先計算了植被陰影，但記憶體限制為非常模糊的紋理。對於高端硬體配置，CryEngine1為植被添加了陰影貼圖，但將它們與預先計算的解決方案結合起來依然有不少問題。

CryEngine1將模板陰影用於點光源，以獲得更簡單、更有效的解決方案。CPU蒙皮允許在CPU上提取陰影輪廓，然後在GPU渲染模板陰影。很顯然，當想要渲染更詳細的對象時，這種技術會成為一個問題，因為它依賴於CPU蒙皮，需要額外的CPU計算、上傳到GPU、邊緣數據結構的額外記憶體，並且幾乎沒有可預測的性能特徵。由於缺少對alpha混合或經過測試的陰影投射器的支援，因此該技術甚至無法用於棕櫚樹（下圖）。

Far Cry遊戲截圖，使用了軟預計算陰影與實時陰影相結合的方案。

在此階段，已經誕生網格的LOD技術，下圖展示了同一個網格的兩個LOD的外觀和三角形數量：

地形渲染也初見雛形，擁有了較大的視野、LOD過渡、特殊的紋理過濾（如雙線性、各向異性）和霧效：

在此階段，也已經興起了Billboard（公告板）技術，用於粒子特效及部分遠景物體的模擬。

14.2.1 圖形API

14.2.1.1 DirectX

DirectX是微軟訂製的圖形API標準，是當今非常流行的主流圖形API標準之一，是一組應用程式編程介面 (API)，專用於Microsoft平台上處理與多媒體相關的任務，尤其是遊戲編程和影片。最初，這些API的名稱都以「Direct」開頭，如Direct3D、DirectDraw、DirectMusic、DirectPlay、DirectSound等。DirectX這個名稱是作為所有這些API的縮寫詞（X代表特定的API名稱）而創造的，並很快成為該集合的名稱。

隨版本變化的DirectX圖標。

微軟最早於1995年發布DirectX 1.0版本，隨後幾乎保持一年一發布的速度。截至1999年，已經發展到了DirectX 7.0。1996年微軟發布了DirectX 2和3兩個大版本。另外，因特殊原因，DirectX 4從未被公開發布。（下圖）

DirectX 3.0的圖形特性包含硬體級加速的點陣圖、表面、線條繪圖，支援高點陣圖的顏色深度，擁有一個支援MMX的光柵化器。

DirectX 3.0研製的遊戲截圖。

DirectX 5.0的圖形特性包含新增直接將多邊形資訊直接傳遞到硬體的DrawPrimitive介面、程式化網格和增強的動畫、與排序無關的抗鋸齒、基於範圍的霧、各向異性紋理過濾、無緩衝隱藏表面消除等。

graph TD A(Stipple Test) --> B(Z-Buffer) B --> C(Fetch Texels from single texture. Filter to final texture color.) C --> D(Texture Blend) D --> E(Add Specular) E --> F(Apply Fog) F --> G(Alpha Blend) G --> H(Write to Frame Buffer)

DirectX 5.0的固定渲染管線。

DirectX 5.0研製的遊戲截圖。

DirectX 6.0的圖形特性包含更快的性能、用於更好照明和轉換的更好的幾何引擎、為具有硬體3D加速器的用戶提供更快的軟體光柵化器，以及對多紋理、凹凸貼圖、紋理壓縮、模板緩衝區和W緩衝區等。

DirectX 6.0的立方體環境貼圖效果。

DirectX 6.0研製的遊戲截圖。

DirectX 7.0的圖形特性包含多紋理（組合兩個或多個紋理貼圖，如光照貼圖）、立方體環境貼圖、硬體變換和光照、頂點混合（GPU骨骼蒙皮）等。

DirectX 7的光照圖效果。

DirectX 7的立方體環境圖效果。

DirectX 7的頂點混合（GPU骨骼蒙皮）效果。圖左沒有頂點混合，圖右啟用了頂點混合。

14.2.1.2 OpenGL

OpenGL（開放圖形庫）是獨立於平台的2D和3D可視化規範標準，由Silicon Graphics Inc於1992年推出，ARB（架構審查委員會）聯盟負責其開發，會員為各大軟硬體廠商（ATI、NVIDIA、英特爾、微軟等），2006年由Khronos Group聯合接手其開發。OpenGL的一個特點是開發緩慢，因為規範化是一個緩慢的過程，極大地阻礙了圖形密集型應用程式的開發者。

在1999年及之前，OpenGL發布的版本和特性如下表所示：

版本 時間 特性
1.0 1992年6月 一組基準功能、支援擴展
1.1 1997年3月 紋理對象、頂點數組
1.2 1998年3月 3D紋理、BGRA和打包像素格式、成像子集
1.2.1 1998年10月 增加ARB擴展的概念

OpenGL存在開發擴展套件GLFW，是一個開源的多平台庫，用於桌面上的OpenGL、OpenGL ES和Vulkan開發，提供了一個簡單的API，用於創建窗口、上下文和表面，接收輸入和事件。它具有如下特點：

  • 支援 OpenGL、OpenGL ES、Vulkan 和相關選項、標誌和擴展。
  • 通過輪詢或回調支援鍵盤、滑鼠、遊戲手把、時間和窗口事件輸入。
  • 支援多窗口、多顯示器、高 DPI 和伽馬映射。
  • 易於集成到現有應用程式中。
    • 只需兩個函數調用即可為您提供窗口和 OpenGL 上下文。
    • 附帶教程、指南和參考文檔、示例和測試程式。
    • 許多不同語言的社區維護綁定。
  • 用 C 語言編寫。
    • 原生支援 Windows、OS X 和許多類 Unix 系統（Linux、FreeBSD）。
  • 具有 OSI 認證許可證的開放源程式碼，允許商業使用。
    • 訪問本機對象和平台特定功能的編譯時選項。

除了GLFW，還有GLEW、GLUT、gl3w、glad等等擴展庫，具體列表見：OpenGL Related toolkits and APIs。

14.2.2 硬體架構

1995年，Nvidia發布了NV1的顯示卡，電晶體達到100萬個，特性是16位色彩、最近點過濾，性能達到每秒處理5萬個三角形、100萬個像素和

1996年，3dfx公司發布了 Voodoo 1代GPU，是第一張3D加速卡（4MB RAM，50 Mhz），僅支援3D可視化，需要一個額外的2D影片卡，在市場上獲得巨大的成功。它的理念是將2D變換由快速的2D顯示卡執行，例如流行的Matrox影片卡，而3D變換由Voodoo卡執行，Voodoo的硬體能夠進行比軟體渲染更快的計算。

一個典型的Voodoo Graphics PCI擴展卡包括一個DAC、一個幀緩衝處理器和一個紋理映射單元，以及4 MB的EDO DRAM，DRAM和圖形處理器以50MHz運行。它只提供3D加速，因此電腦還需要傳統的影片控制器來處理傳統的2D軟體。

搭載Voodoo 1晶片的顯示卡外觀。

同年，NVIDIA和ATI（後被AMD收購）開始了自己的GPU系列，例如Nvidia的（NV1、RIVA 128、Geforce 256），ATI的3D Rage、Rage Pro、Rage 128等。顯示卡一經面世，立刻大受歡迎，主要原因是合理的價格、廣泛的銷售渠道和被遊戲和作業系統（主要是Windows）支援。

在隨後的短短兩年內，3dfx公司陸續推出了Voodoo Rush、Voodoo 2等晶片。Voodoo Rush將2D和3D統一在了一塊，無需額外的2D處理器。但由於2D和3D的頻寬爭用，Voodoo Rush性能並不佳。

此外，Rush晶片組並不直接存在於PCI匯流排上，而是必須通過2D晶片的鏈接暫存器進行編程。與Voodoo Graphics一樣，沒有中斷機制，因此驅動程式必須輪詢Rush以確定命令是否完成；通過2D組件的間接性在這裡增加了顯著的開銷，並傾向於備份PCI介面上的流量。與Voodoo Graphics相比，典型的性能損失約為10%，在窗口模式下甚至更糟。Voodoo Rush卡的銷售非常糟糕，並且這些卡在一年內就停產了。

1998年3月，Voodoo 2面世，架構上和1代類似，但硬體上增加了第二個紋理單元，支援一次繪製兩個紋理。Voodoo 2需要三個晶片和一個單獨的VGA顯示卡，性能上比同期其它產品都要好，但也存在一些限制。Voodoo2引入了掃描線交錯 (SLI)，其中兩塊Voodoo2板連接在一起，每塊畫出螢幕掃描線的一半，SLI將支援的最大解析度提高到 1024×768。由於使用三個獨立顯示卡（兩個 Voodoo 2 SLI加上通用2D圖形適配器）的高成本和不便，Voodoo2 SLI方案對總市場份額的影響很小，在財務上並不成功。

幾個月後，帶有集成2D/3D晶片組的Nvidia RIVA TNT（下圖）發布，對Voodoo2的霸主地位構成輕微挑戰。RIVA TNT添加了第二個像素管線，使得渲染速度翻倍，並且使用了更快的記憶體。與Voodoo2不同，它還增加了對32位（真彩色）像素格式、3D 模式下的24位深度緩衝區、8位模板緩衝區和對1024×1024像素紋理的支援。此外，改進的mipmapping和紋理過濾技術，包括新添加的對三線性過濾的支援，與TNT的前身相比顯著提高了品質，TNT還增加了對高達16MiB SDR SDRAM的支援。與RIVA 128一樣，RIVA TNT是單晶片解決方案。

Nvidia RIVA TNT晶片外觀。

1999年，Nvidia的GeForce 256（NV10）發布，特點是固定管線，支援DirectX7.0，硬體及坐標變換和光照，支援立方體環境圖、凹凸貼圖、2x各項異性過濾、三線性過濾、DXT紋理壓縮等功能。

在90年代，顯示卡的部件和布局尚顯簡單，最明顯的是散熱裝置，98年的顯示卡只需要少許散熱片，到了03年，便需要風扇來散熱（下圖）。

顯示卡除了物理部件的改進，處理速度和頻寬也在飆升，呈現或超越摩爾定律曲線。下圖是NVidia的從TNT（1998）到GeforceFX 6800（2004）每秒處理三角形數的曲線圖：

圖形API標準和GPU硬體的發展，使得遊戲引擎如虎添翼，在此時代有了較大的發揮空間。

14.2.3 引擎發展

人類歷史上第一款電腦遊戲通常認為是1962年的Spacewar，遊戲中有兩艘玩家控制的宇宙飛船在原始2D顯示器上呈現，儘管更簡單的遊戲甚至更早之前就存在。早期的電腦遊戲由低解析度螢幕上的簡單2D圖形組成，這種趨勢一直持續到1990年代。

1962年的電腦遊戲Spacewar，通常被認為是人類歷史上第一款電腦遊戲。

運行早期遊戲的硬體非常有限，迫使開發人員從系統中獲取所有處理能力，例如用彙編語言對遊戲進行編程，過去的遊戲工程主要是關於低級優化。由於硬體有限，早期電腦遊戲的架構非常少，僅由事件循環、狀態表和圖形常式組成。這些遊戲彼此之間幾乎沒有共享可重用元素，這意味著新遊戲通常是從頭開始編程的。

在早期的冒險遊戲中可以看到一絲早期類似引擎的架構，其中第一個是Colossal Cave Adventure，標誌著基於文本的互動小說類型的開始，其中遊戲玩法包括閱讀設置的文本表示並輸入簡單的命令與之互動。基於文本的冒險在早期遊戲中非常流行，後來，結合圖形催生了圖形冒險類型的架構，但結構非常簡單，僅有狀態表形式的遊戲邏輯、最小級別數據和一個幾乎難以識別的事件管理器。

儘管Adventure的架構很簡單，但可以清楚地看到數據驅動設計的元素，這就是典型的遊戲引擎：遊戲的內容與程式碼明顯分離。原則上甚至可以通過更改數據和不理會程式碼來創建遊戲的修改版本。

Adventure的一些繼任者都深受其影響，包括Adventureland（Adventure International，1978 年）、Zork（最初由 MIT 的幾個學生於 1977年編寫，後來Infocom在1980-1982年作為三款不同的遊戲發行）和Mystery House （1980年）。雖然Adventureland的機制與原始Adventure幾乎相同，但Zork和Mystery House在冒險遊戲的開發中產生了兩個分支。Zork和其他Infocom的遊戲仍然是純文本的，但具有極大改進的命令解析器，而Mystery House以基本圖形為特色（儘管玩家命令仍以文本形式輸入），開創了圖形冒險遊戲的類型。 儘管如此，Infocom的基於文本的遊戲在一段時間內更受歡迎，有行業人士後來評論說，當時有限硬體上的圖形處理剝奪了本來可以呈現的遊戲深度。

左：Mystery House（1980） 右：The Secret of Monkey Island（1990）。

1980年的太空恐慌（Space Panic）是一個單螢幕遊戲，其中一個角色在一個螢幕上移動，躲避外星人，爬上爬下梯子並在地上挖洞。像Donkey Kong（Nintendo，1981年）這樣的遊戲增加了額外的功能，比如跳躍的能力。更進一步的發展出現在像《超級馬里奧兄弟》（任天堂，1985年）這樣的遊戲中，它用橫向滾動機製取代了單螢幕機制，並添加了其它功能。

左: Space Panic (1980)；右: Super Mario Bros(1985)。

在1980年代中期，有一些小型獨立影片遊戲工作室，研製小型的平台遊戲，平台遊戲通常是遊戲玩家通過在靜態和移動平台和壁架上奔跑和跳躍來導航角色穿過充滿敵人的關卡（下圖）。此類遊戲取得了巨大的成功，讓全世界的遊戲玩家感到高興。

Darwin the Monkey遊戲截圖。

與早期遊戲架構的情況一樣（冒險類型的遊戲除外），關於早期平台架構的文獻很少。Blow（2004）提供了一些見解，命名了一個 1990年代的2D遊戲的一些模組（流式文件 I/O、聲音、主要/雜項、模擬、快速2D圖形），同時指出其它類型的遊戲可能包含不同的部分，例如獲得AI的一部分，可能會失去快速圖形節點。

上世紀90年代之前，由於沒有成熟的遊戲引擎，開發遊戲異常困難，並且會重複做很多類似的功能，生產力低下，畫面效果顆粒感十足。

在開發遊戲過程中，有些遊戲工作室對每個遊戲都是從新造輪子，這樣的後果就是開發一個遊戲的時間愈來愈長，並且發現競爭對手研發遊戲的時間卻在逐漸縮短。而縮短研製遊戲周期的工作室正是採用了復用的思維，所有遊戲和所有平台遊戲共有的許多屬性和功能都可以從他們的特定遊戲中提取出來，將上一個項目抽象出可重複使用或基礎的模組，以便快速用於下一個遊戲項目，從而不斷地縮短遊戲開發時間。

這些工作室不僅發現了最初的一些通用模組，而且幾乎認出了所有遊戲的可通用組件並將它們集成到單個系統中可以重複使用以製作許多不同的遊戲。他們知道遊戲內容（圖形和聲音）可能需要在逐個遊戲的基礎上創建，由於遊戲的外觀和聲音不同，但他們也意識到存在支援此內容的框架（或基礎架構），而這主要是可抽象的。這個框架或系統被稱為遊戲引擎。

1990年代，具備系統的遊戲引擎有兩個系列，一個是ID的Doom和Quake系列，另一個是Epic Games的Unreal系列。

許多人認為電腦遊戲（尤其是遊戲引擎）的轉折點是FPS類型的誕生，id Software發行了Wolfenstein 3D (1992) 和Doom (1993)，尤其是《毀滅戰士》，廣泛地流行遊戲愛好者中。

Doom的架構也值得關注，Doom的核心軟體組件（例如圖形渲染、碰撞檢測和音頻）與遊戲內容（例如藝術資產、遊戲世界和遊戲規則）分離，意味著用戶可以在遊戲中添加新的關卡、模型和其它資產，有效地創建自己的新遊戲。雖然Doom的可編程程度很小，並且從它衍生的遊戲繼續像原始遊戲一樣玩，但多家公司授權id Software的Doom引擎來製作他們自己的商業遊戲。因此，雖然不是第一個使用數據驅動架構的遊戲，但將其流行歸因於Doom或許並不牽強。

Doom渲染畫面（1993）。

Doom之後是Quake（id Software，1996 年），它繼承了Doom的功能，具有真正的3D圖形和客戶端/伺服器架構。Quake還提供了一個真正獨立於遊戲的遊戲引擎，包含一個關卡編輯器和QuakeC（一種可以改變遊戲行為的腳本語言）。這是對Doom將數據文件添加到遊戲可執行文件的方法的重大改進，並且可編程性極低。Quake的引擎由兩部分組成：客戶端和伺服器，所有輸入（鍵盤、滑鼠、操縱桿）和輸出（3D 渲染、2D 繪圖和聲音）都發生在客戶端，以及所有實際的遊戲玩法，例如玩家運動和物理模擬、AI和QuakeC腳本都在伺服器上進行。客戶端從玩家那裡獲取輸入並將其發送到伺服器，伺服器在固定的時間內處理遊戲，然後將遊戲的狀態發送回客戶端，客戶端為玩家提供視聽輸出。

Quake III Arena的渲染畫面(1999)。

Quake的單人遊戲和多人遊戲都建立在這種架構之上。在多人遊戲中，多個客戶端通過網路層與單個伺服器（通常在不同的機器上運行）進行通訊，而單人遊戲使用共享記憶體緩衝區進行通訊，並且每個處理幀都在從客戶端獲取輸入之間拆分，在伺服器上處理遊戲並在客戶端上輸出。

除了簡化多人遊戲中的同步問題（與Doom相比，所有玩家運行自己的遊戲模擬並且機器同步進行），客戶端-伺服器架構強制執行模組化設計，簡化調試並保持單人遊戲和多人遊戲程式碼相同。

緊隨Quake其後的是Quake II（id Software, 1997）和Quake III Arena（id Software, 1999）。隨著引擎從Quake 1引擎發展到第三次迭代（Quake 3），它的大小也在隨著源程式碼行數 (SLOC) 和源程式碼模組的數量增長。隨著時間的推移，引擎也變得更有條理，因為第一個版本中的源程式碼文件只存在於一個文件夾中，而後續版本將源文件組織成一個子文件夾樹。在這些版本的引擎中都發現了幾個模組：

  • 通用功能模組。
  • 遊戲邏輯模組。
  • 伺服器特定功能模組。
  • 客戶端功能模組。
  • 聲音和影片輸出模組（在以後的版本中分離）。

研究中分析的所有引擎都是用C程式語言編寫的，但是，引擎的第四個版本id Tech 4已經使用C++和面向對象的範式進行了完全重新設計。

聊完1990年代的Quake系列，回過頭來再聊聊同期的Unreal引擎。

1991年的ZZT，基本上是一個遊戲引擎，其中植入了遊戲。該引擎公開了一種小腳本語言，雖然它非常基礎，但它是一種完整的腳本語言，可以使用它來編寫小遊戲腳本。它有一個實時的所見即所得互動式編輯器，用於創建關卡，可以通過幾次擊鍵來回切換，添加一個關卡，進行遊戲測試並對其進行迭代， 這種互動式工作流程確實是其中的關鍵。

ZZT的遊戲模式和編輯模式。

Turbo Pascal是一個易於使用的編輯器，用於創建程式碼和編譯東西，輸入程式碼的幾秒鐘後它會被編譯，接著就可以運行它。這種編碼方式與之前使用的所有東西相比，創建東西的迭代過程體驗十分友好。

Turbo Pascal的編輯器。

隨後，Epic Games的Tim Sweeney受ZZT和Turbo Pascal的啟發，開啟了Unreal引擎的研發之旅，Unreal初代版本的很多核心功能和ZZT相似，編輯器則和Turbo Pascal相似。

1998年的Unreal Ed編輯器，使用了Visual Basic。

在隨後的若干年，隨著技術的演變，Unreal編輯器先後嘗試了Visual Base、wxWidget、Slate等UI框架，逐漸形成了如今的編輯器風格和交互方式。後續的Unreal Engine加入了Game Play框架，可以給開發人員快速提供一個可用和可擴展的基礎：

Unreal Engine的game play框架圖。

除了Quake和Unreal，此時期還存在其它遊戲引擎的發展。例如TerraForm3D Plasma Works 3D Engine & USGS Terrain Modeler提到了如何設計一款簡潔的引擎（Plasma Works Engine）。Plasma Works Engine的目標是滿足雙方需求的 3D 引擎設計、基於對象的渲染器、嘗試各種特殊效果，以及高品質的影像渲染器、用戶驅動的影像處理等。

Plasma Works Engine渲染效果圖。

在架構上，以前是單個引擎、相同的建築基礎、開源和專有的問題，現在是兩個分離的引擎、不同的架構、OpenGL獨有的擴展（GLUT）。

Plasma Works Engine架構圖。分為物體和渲染器，它們又引用了各種資源和對象。

Plasma Works Engine初始化和循環流程圖。

在數據流上，客戶端採用了命令驅動式機制，驅動物體和渲染器，最終渲染出畫面像素和光源資訊：

Plasma Works Engine的地形建模器涉及不少的包體介面，它們的交互關係如下：

在地形生成和處理上，採用了並行化的分散式架構：

下圖是地形編輯器介面：

下圖是地形並行化處理的介面：

雖然站在現在的角度，略顯初級，但在當時，能夠並行化處理是非不易，會遇到IO、紋理頻寬、同步、設計模型等諸多方面的問題。

1995年，Architectural Blueprints—The 「4+1」 View Model of Software Architecture提到了一種4+1視圖的軟體結構：

  • 邏輯視圖（Logical View），說明對象模型。
  • 流程視圖（Process View），處理並發的流程和同步問題。
  • 物理視圖（Physical View），描述「軟體的映射到硬體上並反映其分散式方面。
  • 開發視圖（Development View），代表軟體在其開發環境中的靜態組織，添加了組件、它們的介面和它們相互關聯的組合的概念。
  • 場景（Scenario），描述了對象之間和進程之間的交互序列，它們用於識別架構元素並說明和驗證架構設計，還可以作為架構原型測試的起點。此視圖也稱為用例視圖。

4+1視圖的軟體結構。

這種視圖的軟體架構也可以引入到遊戲引擎的架構設計中，比如揭示引擎核心類的UML圖便是邏輯視圖，引擎的工具鏈便是開發者視圖，資源文件的載入分層和部署方式便是物理視圖。

此階段的引擎已大致成形，架構的組件大致如下所示：

若是細化各個模組，則是如下圖所示：

時間來到新世紀，誕生了不少新的渲染引擎或組件，其中就有典型代表Ogre。作為Ogre的衍生引擎Ogre Golf，在Orge的基礎上做了不少擴展，引入了許多特性和第三方庫，並且研製了代表遊戲，例如包含了忍者、機器人、消防栓、城堡、術士等物體的大型迷你高爾夫球場，該遊戲支援多人聯網互動。

Ogre Golf渲染畫面。

在同期，還出現了Irrich、Delta3D、Panda、OSG等引擎，它們各具特色，在引擎的各項特性（渲染、功能、場景、地形、視覺、跨平台等）上的支援程度如下表所示：




此階段引擎的邏輯循環和渲染循環如下所示：


// 邏輯循環
while (true)
{
    for (each frameListener)
    {
        frameListener.frameStarted();
    }
    renderCurrentScene();
    for (each frameListener)
    {
        frameListener.frameEnded();
    }
    finalizeSceneAndSwapBuffers();
}

// 渲染循環
while (!quit)
{
    // 修改相機屬性。
    updateCamera();
    // 修改場景物體的屬性。
    updateSceneElements();
    // 渲染場景上的物體。
    renderScene();
    // 呈現交換鏈（啟用多緩衝的情況下）。
    swapBuffers();
}

至此，遊戲引擎的萌芽期總算順利完成，逐漸形成了基礎的模組、架構和渲染技術。

 

 

  • 本篇未完待續。

 

 

特別說明

  • 感謝所有參考文獻的作者，部分圖片來自參考文獻和網路，侵刪。
  • 本系列文章為筆者原創，只發表在部落格園上，歡迎分享本文鏈接，但未經同意，不允許轉載！
  • 系列文章，未完待續，完整目錄請戳內容綱目。
  • 系列文章，未完待續，完整目錄請戳內容綱目。
  • 系列文章，未完待續，完整目錄請戳內容綱目。

 

參考文獻

Tags:

VirMach 便宜 VPS