遊戲引擎的層級架構

遊戲程式的領域中,最常聽到的專有名詞,可以說是非 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》 書中的設計思維所述:應該著力於將「變動」與「不變動」的部分抽離分開,分別封裝「變動」與「不變動」的概念,才能夠將進行變動時所需耗費的心力降至最低。

37 thoughts on “遊戲引擎的層級架構”

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

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

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

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

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

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

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

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

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

    半路:
    你的問題很,不是三言兩語可以解釋完。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  7. 我想學習寫一個遊戲

    應該由那一方面學起,我學過用flash,不過中四以後就沒有學電腦了,所以不會寫program

    我上維基打遊戲引擎,有一大堆程式,英文…

    隨便下載1個 囧 game

    雖然我不知道要學甚麼先,就當我是1個新手,會打機的中學生
    想寫1個遊戲的話 應該要學甚麼先,再去寫

    我的夢想是寫出另一個fez

  8. @獨狐:
    你好,

    建議你可以由 Flash 或者 Virtools 入門,學習遊戲設計與遊戲程式的基本概念,然後試著去製作一些打磚塊之類的簡單小遊戲。寫出第一個遊戲之後,你就會獲得許多遊戲製作的知識與經驗。如果有興趣往遊戲程式方面發展,可以再繼續往 Java 或者 C++ 程式語言的方向學習。

    最重要的是,用心學、動手做!

  9. 看你的文章都覺得很有意思,不知道版主對NeoAxis game engine有什麼看法?

  10. @人類:
    我很久沒關注 NeoAxis 的發展了,上次看到它時還是零點零幾版而已。

    之前對它的印象還不錯,但看你想要做的是哪一類的應用。如果想要做一個跨平台的遊戲,可能要多花點時間研究,並測試看看它的執行效能如何。

    目前 NeoAxis 比較大的疑慮是,還沒有一個較大型或較成功的遊戲專案是用它開發建立完成的。所以在風險評估方面,得多花點心思才行。

  11. 聽說台灣很多遊戲公司都會開發他們自己的繪圖引擎(或是遊戲引擎?)
    請問這是真的嗎

  12. @路人:
    據我所知,通常是比較老牌的遊戲公司,比較有在做自行開發繪圖引擎或遊戲引擎這件事。

    現在有許多的遊戲公司,都是直接使用開源引擎或商業引擎來開發遊戲了。

  13. 基本上,一堆遊戲引擎原始碼跟網遊原始碼,都已經被駭客群 leak 掉了
    駭客都已經擁有比台灣產業量還大的資源了 ….不知道為什麼台灣還在一直吵這塊
    感覺就像 ue3 的第一個英文字一樣,unreal
    技術是技術,風險極高,市場也不大,就股票一直吵,好像在變相吸金
    支那那裡,已經爆掉了,去年裁了上千人,上市大公司虧損破千萬美金,都不敢說一堆公司
    做遊戲跟玩遊戲不一樣的 … 想進這領域的人,別再做小朋友的夢了

  14. @駭客群大老:
    我認為光是擁有遊戲引擎或遊戲的原始碼,並沒有多少價值可言。想要從別人的原始碼去搞款遊戲出來,這套作法在中國以外的地方大概都行不通。

    如果要純搞引擎技術,其實是大有可為的,但至少也得做出像 Unity 這樣品質的東西才行。

  15. 我以前用過python, java applet 寫過遊戲,現在想學c++
    不知道c++有什麼GUI library,用什麼ide比較方便
    我用的是Mac

    謝謝

  16. @Y:
    我對 Mac 的程式開發環境沒有這麼熟悉哩。

    如果你是單純要學 C++ 語言,我想應該大部分的程式 IDE 都可以使用,建議試試看 XCode 或 Eclipse。

  17. 半路大,想請問一下,如內文所提,遊戲引擎提供了「一組完整的解決方案」。
    我自己有接觸過Unity3D這套遊戲引擎,我覺得它降低了開發遊戲的門檻,如物理碰撞、3D模型處理等等。
    我的問題是,如果遊戲引擎是一個不錯的解答,那是不是以後會越來越走向使用遊戲引擎的方向呢?
    和使用遊戲引擎相比,像使用C++搭配繪圖API/繪圖引擎來開發遊戲是否具有某些優勢?

  18. @Blake:
    確實目前隨著各種遊戲引擎與遊戲工具的普及化,也使得製作遊戲的門檻越來越低。

    使用遊戲引擎,可以幫開發者節省很多時間,但相對來說,開發者也必須花費很多心力學習如何使用。而在好不容易熟悉該引擎的使用後,若要再轉換到其他引擎工具,不免又得花上一段學習時間。

    相較之下,學習 C++ 以及 DirectX/OpenGL 這條路雖然又硬又辛苦,但就像是武俠小說裡的內功心法一樣,當你有了深厚的「九陽神功」後,不管是要學「乾坤大挪移」或什麼其他的武功招式,都會來得容易許多。

  19. 我還是有1點搞不懂
    所謂的遊戲引擎 是不須要豐富的C++知識 光靠遊戲編輯器 也能做處低or中階品質的遊戲嗎?

  20. 每個遊戲引擎所使用的語言也不一定相同啊,
    Unity使用C#和js, Unreal使用自己寫的script, Gamebryo使用C++,
    其他還有很多小型的引擎,像Stencyl、Construct 2、Game Maker…等等,也不盡相同,
    要說關於程式的共通點,就是”邏輯”的部份吧。

    理論上一個完善的引擎,就是要可以在他的環境底下,做出一個遊戲,
    但是低、中階品質的定義…這似乎有點個人心證吧!

    如果是指遊戲類型的話,也是有人會用RPG Maker做出動作遊戲的啊,
    相性夠高,理解程度夠了,加上有心想做,就會生出方案吧。

  21. 另外推C++,以前感覺不出來,
    後來因緣際會需要學習AS3的時候,大概花了一兩個星期就可以上手了,
    真的是九陽神功,學其他武功(OOP語言)都會比較快!(´∀`)b

  22. 對不起 小弟是最近踏入這神聖領域
    那我在小問一下 JS 是寫在HTML的
    那可以拿來做IOS 或安卓之類的APP遊戲嗎?

  23. @安安:
    有些遊戲引擎未必會有功能完整的編輯器,需要的功能還是得自己寫程式才行。而即使像 Unity 這樣強大的引擎,要做遊戲也還是免不了要寫程式碼。

    如果你是指 Javascript 的話,可以試著學 HTML5 來寫以網頁為基礎的遊戲。

    @哈士奇:
    感謝幫忙回覆~ =w=b

  24. hello 板主~

    想詢問您Unity3D開發相關問題,因為它號稱跨平台,所以平常習慣用webplayer的環境開發(部屬時間短),但最近把專案包成xcode後輸出的版本落差有點大(記憶體過度使用,部分c# api相容性問題等等),不知道有沒有辦法縮短兩種環境的落差?

  25. 開源的id Tech系列引擎如何?像是戰慄時空、決勝使命等成功的第一人遊戲都是以此修改的~

  26. @路人:
    id Tech 的引擎的技術很強大,但相較之下很少人在使用。據我所知,它比較像是「工程師導向」的遊戲引擎,我想應該會比較適合擁有高強技術工程師的團隊來考慮使用。

  27. 半路你好,兩年前我曾經問過你一個問題,就是使用C++搭配DirectX/OpenGL開發與使用引擎之間的差異,最近因為工作的關係又從學習C++與DirectX的環境轉換到使用Unity3D(以下簡稱U3D)來開發遊戲,這兩年來U3D變得十分火熱,我聽到的各個學校如果有多媒體之類的科系必定都會開關於U3D的課程,最近我對這個問題又反覆在思考,就是如果今天如果開發一款手遊,它可能不像開發MMORPG一樣架構龐大,或許也不需要很難的3D技術,以您的作品勾玉忍者為例好了,要在Android上發行可能又需要學會寫Java,那如果今天開發者可能只會Objective-C的話只能在IOS平台上發佈,假設若有某個團隊他們採用U3D來開發一款玩法類似的作品,卻能夠快速在IOS/Android兩種平台上發佈,那是否擁有一個更大的優勢呢?

  28. @Blake:
    相對於各平台的 Native 原生程式碼來說,確實 Unity 的優勢就是在於跨平台發行的便利性上沒錯。如果公司或工作上有這樣的需求,那麼轉換到 Unity 應該是還不錯的選項,但我覺得對於學生(特別是資訊科系)來說,如果可以先學好基礎程式設計與電腦圖學的概念,我想才能夠在遊戲開發這條路上走得更長遠。

  29. 我想提個問:首先我練了幾年的C了(是C),最近在學習如何使用C++和directx寫遊戲
    但是網路上搜尋,幾乎可以說開發遊戲仰賴了遊戲引擎以及高階的程式語言(C#)
    爾且,中間都沒有甚麼C++/directx插足的餘地。
    我應該去學習C#和例如Unity的使用嗎?還是說,繼續學習C++/directx呢?

    提問二,這個有點題外話,C++的語法蠻容易我就看懂了,可是,我卻覺得寫出來的程式,完全沒有比較好維護,我似乎沒有發揮這C++的特性。儘管,我嘗試著建立了各種物件跟類別,但我還是大量的運用C的技巧(一堆指標啦,函數等等)。物件導向概念非常模糊,可以給我一點建議嗎?

  30. @蘇意喬:
    目前有許多單機遊戲和網路遊戲,都還是使用 C++ 與 DirectX/OpenGL 開發的,所以學習 C++ 絕對不會沒有用處。如果你是資訊科系出身的,我會建議不要太倚賴便利的引擎工具,因為這些東西都會有過時的一天,而自己紮實累積下來的程式語言功力,才是能長長久久的專業技能。

    關於撰寫程式的正確觀念培養,推薦你讀《Code Complete》這本書。另外記得要持續不斷地撰寫各種程式,用程式來解決問題,一面撰寫一面思考,長久累積下來,你一定會進步的。

  31. 上面看到幾年前的留言,有提到Torque,現在這引擎用MIT授權開源了!
    之前如果要用自由軟體搭建遊戲(比較完整的引擎效果都不是很滿意XD),
    都要抓繪圖庫拼一拼、物理庫湊一湊、為了方便使用還要自己搞個編輯器,
    Torque算是使用相當簡易的引擎,效果也不錯,MIT授權真的佛心來著,
    而且之後能任意擴充,不必擔心法律授權的問題。
    不知半路大有何看法?

Leave a Reply