Jan 16 2008

遊戲引擎的層級架構

Tag: 入門概念

在遊戲程式的領域中，最常聽到的專有名詞，可以說是非 Game Engine（遊戲引擎）莫屬了。聽起來是個很炫很酷的名詞，但其實遊戲引擎一詞經常被過度泛稱與誤用。所謂的遊戲引擎架構，由低階 (Low-Level) 至高階 (High-Level) 可細分為以下三個層級 (Layer)：

繪圖 API，負責掌管程式與硬體間的溝通，將硬體層的功能與特徵抽象化，提供一組標準化的介面供程式設計者使用。目前 DirectX 與 OpenGL 已成為業界兩大標準。此層級屬於繪圖底層的規格化與標準化，有利於引擎與遊戲開發者以及整個業界的發展，使開發者可以專注在更具體與遊戲相關的引擎架構上，而不會受制於各家廠商不同硬體實做內容所產生的限制。

繪圖引擎，將底層的繪圖 API 包裝成與實做無關的介面，甚至能夠提供數種不同平台的繪圖 API 以供跨平台開發使用，更進一步的為程式設計者帶來許多的功能性以及便利性。使用繪圖引擎對於開發者來說最大的益處，就是可以使用以繪圖 API 建構起來的各種繪圖架構與技術，例如 Scene Graph 架構、空間分割、資源管理、光影處理等等。

遊戲引擎，則是一組完整的解決方案，能夠在保持一定彈性的原則下，提供最大程度的功能性與便利性。除了包含繪圖引擎的功能之外，可能也會包含播放音樂音效的音效引擎、判斷物理碰撞行為的物理引擎等其他功能面的元件。相較於單純的繪圖引擎，一個完整的遊戲引擎，更需要提供許多的編輯器與工具，例如地形編輯器、人物動作編輯器等等。而遊戲引擎與美術設計軟體（例如 3ds Max）的整合性也相當重要；如果引擎內含強大的編輯工具與外掛輸出程式，不僅能為程式開發者節省時間，為企畫與美術設計者帶來便利性，更能夠降低人為錯誤的發生率，進一步加速遊戲的開發流程。

除了上述的繪圖 API、繪圖引擎與遊戲引擎層級之外，還有一個稱為遊戲框架 (Game Framework) 的層級。在軟體開發的領域中，所謂的 Framework 是指一個在軟體系統中可重複利用的設計。與遊戲相關的著名框架系統有用來開發 Xbox360 遊戲的 XNA Framework 與微軟大力推行的 .NET Framework。框架系統需要能在提供現成實做版本的情況下，同時保留具有彈性且可擴充的介面，以期達到框架的可重複利用性。

此外，由於遊戲產業的蓬勃發展，專注於開發繪圖引擎與遊戲引擎的公司也越來越多，於是出現了一個新興的專有名詞稱之為 Middleware（中介軟體）。中介軟體是用來提供某特定層面的功能性元件，目的在於節省遊戲開發的時程與風險，包含像是繪圖引擎、物理引擎、人工智慧引擎、音效引擎等等都可以算是中介軟體的一種。目前也有中介軟體開發廠商，提供包含伺服器端與客戶端程式在內，開發 MMO 遊戲的完整解決方案。

在遊戲程式開發中，最困難的關鍵點往往在於各層級間的橋接與溝通部分。對於各個層級，開發者需要盡可能使它們達到彼此獨立不相依的情況，減少各層級之間的耦合性，在這樣的設計模式之下，才有利於達到元件化、層級化的高度可再利用遊戲引擎。簡而言之，也就是將介面與實做分離的設計概念。在最理想的情況下，希望能夠將引擎框架的泛用程式碼與和特定遊戲相關的程式碼兩部分完全分離而治，以期達到在引擎相關程式碼變動最少的情況之下，能夠提供給不同的遊戲程式碼來使用。

遊戲引擎所提供的功能，就像是玩樂高 (LEGO) 玩具一樣，我們可以使用積木箱裡各種不同形狀的基本積木，組合出夢想藍圖中的巨大模型。這些基本積木就像是遊戲引擎中的各種元件，可以根據不同遊戲專案的不同需求，取出合適的積木元件拼湊組合成為一個完整的遊戲。而這個從積木組成模型的步驟，則需要一個規格化、標準化的程序，使得「組裝」這個動作，變得很直覺易懂，無論未來積木的內容材料是否有改變，都不會對使用者造成太大的影響。積木的「組裝」動作就像是程式的「介面」一樣，任意變動積木的組合方法或是介面的使用方法，都會造成使用者的困擾與不便，並且大幅降低複製使用經驗的可能性。

然而在真正的開發過程中，我們可能會發現，要達成各層獨立、介面實做分開是非常不容易的任務。特別是在程式架構不良的情況下，會使得日漸龐大的遊戲程式碼層層交疊、錯綜盤根，就像是地基不穩卻又拼命往上加蓋的高樓一樣搖搖欲墜。因此正如 《Design Patterns》 書中的設計思維所述：應該著力於將「變動」與「不變動」的部分抽離分開，分別封裝「變動」與「不變動」的概念，才能夠將進行變動時所需耗費的心力降至最低。

再來一罐：

“遊戲引擎的層級架構” 目前有 6 則迴響

  1. 李科科 on January 16th, 2008 at 11:52 pm

    可惜現在垃圾引擎一堆.. 抄抄改改就自稱遊戲引擎 還想賣錢…真是不知道天高地厚…

    半路：
    遊戲引擎這個詞，的確是有被過度引伸使用的濫觴阿。 ( ′-`)y-～

  2. hitchhiker on January 17th, 2008 at 11:55 am

    那請問Torque這引擎好不好呢? 正在做個可用性調查. 請指教.

    半路：
    Torque 以它的價位來說算是很不錯的遊戲引擎囉～ 它的使用者社群也算是滿熱絡的，能夠從中得到不少資訊，如果要用來開發中小型商業遊戲沒有問題，目前也有成功的案例。至於大型商業遊戲，因為我本身沒有使用過 Torque 的經驗所以就不予置評囉。

  3. 不錯哦 on January 21st, 2008 at 1:16 pm

    版主內容寫得很好.
    很好奇引擎這種工程,要如何去學習製作?
    用抄的可以抄出來嗎?

    半路：
    用抄的多半只能學到皮毛而已，重要的是要去瞭解引擎的設計理念與實做應用層面。要朝這方面學習的話，我會建議先去使用並且鑽研幾個有名的 Open Source 引擎，例如內文提到的 Ogre 或 Irrlicht，都會是不錯的選擇。真的要能下苦心去研究學習，才能夠逐漸累積知識，進而增強自己的實力。

  4. 不錯哦 on January 22nd, 2008 at 10:14 am

    感謝板主的建議.
    板主的知識見解,令人想要再請教一下:
    學習Ogre會花多少時間嗎?
    它可以達到商業遊戲(國外)水平嗎?
    (為何台灣公司很少有公司願意採用?)
    有些資深技術人,提過國外的商業繪圖引擎
    (RenderWare/GameByro)未提供Game編輯器,
    在製作遊戲前,仍然需要花時間(好幾年)開發編輯器,
    因此使用Ogre(免費引擎)或購買商業繪圖引擎,
    2者都要花時間開發工具,
    為何還是會有很多公司會想購買商業繪圖引擎?
    最後一個問題:
    瞭解引擎的設計理念與實做應用層面這2點後,
    再進行抄習(學習?)引擎相關功能,是否也要花幾年,
    才有辦法製作到國外商業遊戲的水平呢?

    這些問題從以前一直想了解,
    只是台灣有在研究引擎技術人太少了,不知為何會這樣呢?

    再次請板主再回應一下,謝謝.

    半路：
    你的問題很大，不是三言兩語可以解釋完。

    學習 Ogre 或其他引擎要花費多少時間，這點有很大程度取決於你個人目前所學過的相關知識與經驗，每個人都會有自己的學習曲線，不能從一而論啊。

    Ogre 從前的版本有不少大大小小的問題，直到去年左右，才算是有比較穩固的版本釋出。現在的版本，用來開發具水準的中小型商業遊戲，是不成問題的。

    另外，使用遊戲引擎來製作遊戲與開發遊戲引擎來製作遊戲，兩者的難度完全是天差地遠的兩回事。以開發製作引擎的例子來說，就像星爺講的：「球，不是一個人踢地。」引擎，也不是一個人可做的。如果僅是使用引擎，就簡單多了。

    其實台灣研究 3D 引擎的人並不少（至少就遊戲界來講），不過大多直接往國外網站與討論區去了，所以中文的相關資訊才會這麼少。 =.=

    「未提供Game編輯器,為何還是會有很多公司會想購買商業繪圖引擎?」這個問題很好，有問到一個關鍵重點，我想另闢一篇文來細講。關鍵其實在於 Robust 這個字。

  5. R2D2 on March 29th, 2008 at 5:02 am

    有些引擎是以runtime executable的形態存在, 遊戲部份的程式以dynamic linking方式執行; 有些引擎是則是將引擎和遊戲compile在同一個executable裡. 不知道板主對這兩種方式有何看法?

    半路：
    一般情況下，我認為在大型的系統或遊戲引擎中，才會比較需要使用 DLL 動態連結的方式。

    分開 DLL 檔的原意，應該是為了在不更換主執行檔的情況下易於替換部分模組的程式，但是如果引擎架構中的功能模組，沒辦法妥善地封裝成獨立不相依的組件，而在每次更新程式的時候，還是需要更換主執行檔與許多的 DLL 檔的話，其實使用 DLL 的作用就不大了。

    使用 DLL 有好處也有壞處，如果在某部分的組件能夠維持穩定且獨立運作的狀態下，使用 DLL 的確可以提供一些益處。而我自己比較不喜歡引擎中需要一大堆 DLL 檔的情況，要花費額外的心力維護許多不同 DLL 版本的發佈，也要小心版本衝突的問題。但如果是商業引擎的話，我認為 Static Linking 或 Dynamic Linking 兩個選項都要提供給開發者自由選擇會比較合適。

    不知道有沒有人有其他看法？歡迎提出討論喔～

  6. R2D2 on April 4th, 2008 at 9:34 am

    我自己原本蠻喜歡只有一個DLL(遊戲)和一個執行檔(引擎+一些有的沒的共用模組),
    但是這樣似乎比較適合製作同類型的遊戲.
    而且遊戲完成前不一定能事先知道哪些library會被用到,
    最後常會變成每個遊戲有自己不同的engine runtime,
    不如乾脆一開始就通通作static linking.
    加上console game幾乎沒有在做patch的, dynamic linking似乎失去了它的意義.

    話說回來, 也有看到其它公司用DLL用得蠻成功的, 所以會很好奇…

    半路：
    要能夠把 DLL 的方式運用得當確實不容易啊。
    在我印象中，使用 DLL 比較著名的應該就屬 OGRE 引擎的 plugin 系統了。

    雖然就我個人來說，
    還是不太喜歡把一卡車的 DLL 檔跟著執行檔一起散佈就是。 = =+

留下迴響