《Good Middleware》:如何選擇遊戲開發的中介軟體

cryengine-sandbox
(圖片來源:brianlawler.smugmug.com)

原文出處:Good Middleware

之前在「遊戲引擎的層級架構」以及「商業或自製,引擎大不同!」兩篇文章裡,曾經討論過遊戲引擎的基本概念以及商業引擎與自製引擎的不同之處;而在這篇文章裡,第三人稱射擊遊戲《Fracture》的開發者 Kyle Wilson,對於遊戲開發領域的 Middleware(中介軟體)提出了幾項有力的觀點,非常值得做為使用與選擇遊戲開發中介軟體的參考指南。

身為遊戲軟體的設計者與創造者,為什麼我們需要仰賴別人製作出來的某些東西?為什麼我們要花錢購買所謂的中介軟體?主要來說,中介軟體能夠提供兩大益處,同時也具有相對應的代價。

首先,相較於自己撰寫的程式碼,中介軟體能夠以更少的花費提供給使用者更多的程式碼。因為中介軟體的開發商能夠將研發費用平均分攤在大量的授權客戶上,所以比一般的遊戲開發公司,更能夠維持龐大且具深厚經驗的團隊,專注在特定領域的功能項目之中。然而此項利益的相對代價,在於沒有任何中介軟體的功能,能夠百分百符合遊戲專案的所有需求;中介軟體是寫來支援最常見的使用案例,因此如果開發者擁有不同於一般標準的特別需求,最好還是自行實作這些特殊的功能。

另一項使用中介軟體的益處,是能夠為「你應該擔心的事」與「你無須擔心的事」畫出一條清楚的界線。只要中介軟體具備良好的文件以及穩定的系統,你就不需要浪費心思憂慮那些隱藏在公開介面之下的東西。當遊戲的複雜度增長到了某種程度以上時,如果中介軟體能夠協助開發者劃清各項功能系統的責任界線,將是一項相當具有價值的恩惠。而相對的代價,則是你不能夠去改變界線另一端的東西;如果決定要使用中介軟體,就必須願意接受某種程度上的缺乏靈活性,也必須願意將原本所使用的技術調適到合於中介軟體的程度,否則花錢購買中介軟體將會演變成為一場災難。

每個遊戲都會具有某些獨特的賣點,以與市面上的其他遊戲做出區別;對於這些獨家功能,遊戲開發者應該在團隊內部自行研發。同樣地,每個遊戲也會有許多與其他遊戲相同的特徵,對於這些尋常可見的功能,遊戲開發者應當購買架上現成的技術,然後接受技術的不彈性之處,並且修改遊戲的設計去適應它。總結以上論點,就是應該在遊戲獨特賣點以外的功能,盡可能地使用中介軟體;正如同 Joel Spolsky 所說的:「不要外包你的核心競爭能力!」(Don’t outsource your core competency.)

所以,當你搞清楚哪些遊戲功能應該藉由中介軟體實現,同時也心悅誠服地領略了使用中介軟體的益處之後,在琳瑯滿目而且五花八門的 Middleware 領域裡,要如何挑選出最合適於遊戲專案的中介軟體?以下有幾項必須謹記於心的內容:

好的中介軟體讓你掛勾自己的記憶體配置器
在日益複雜的遊戲系統中,天真無邪的 malloc() 函式或者 operator new 記憶體配置程序,已經難以滿足遊戲程式設計者的需索無度:我們必須自行管理記憶體的配置行為。自行管理記憶體有許多優點存在,例如能夠準確追蹤遊戲記憶體的使用量、可以輕易地找出記憶體漏洞的臭蟲,以及平衡物件資源系統的負載量等等,因此對於中介軟體來說,必須要能夠讓使用者掛勾 (hook) 自訂的記憶體配置器。

好的中介軟體讓你掛勾自己的輸入輸出函式
現在多數的遊戲,都會將原來數量龐大且分散在各檔案目錄中的遊戲素材,壓縮打包成幾個大型的檔案。如果中介軟體不能讓使用者掛勾自訂的 I/O 操作程序,程式設計者就難以使用檔案打包的方式將遊戲素材包裝起來。另外對於以光碟為儲存媒介的遊樂器平台來說,如果不能夠控制中介軟體的 I/O 操作,就無法對檔案的讀取進行排序以減少光碟搜尋時間。

好的中介軟體擁有可擴充的功能性
如前文所述,沒有一個中介軟體能夠達成遊戲開發者所要求的每一項功能。所以好的中介軟體應該要提供可實現的抽象介面,以及可掛勾的 Callback 函式,讓使用者能夠在有需求之處進行特製化的行為,例如在一個動畫套件中實作自訂的動畫控制器,或者是在一個物理套件中撰寫自訂的碰撞基底物件。

好的中介軟體會避免符號衝突
為了避免程式碼中的符號衝突狀況,每個中介軟體內的類別名稱都應該以自訂的字首起始,或者是包含在函式庫的命名空間範圍之內。另外,需要特別留意那些使用 STL 函式庫的中介軟體;當轉換到 STLPort 或是新的開發環境中時,開發者可能會突然發現程式碼裡冒出許多定義的衝突。另外,程式設計者也應該盡量減少對於 #define 語法的依賴與濫用,才不會發生符號定義相互遮蔽的狀況。

好的中介軟體對於執行緒安全具有明確定義
在越來越朝向「多核多緒多樂趣」發展的遊戲領域裡,中介軟體對於多執行緒的支援已經是刻不容緩的需求。為了使遊戲程式在多個執行緒上運行無誤,中介軟體必須充分地告知程式設計者,哪些操作可以同時並進地執行,而哪些操作又必須依序地執行。理想上來說,中介軟體應該要能夠讓程式設計者執行非同步化的資源創建程序,才能在其他執行緒中建立資源物件後再交由主執行緒處理。

好的中介軟體能夠適應於你的資料處理管線
對於中介軟體來說,遊戲資料的處理管線同樣是很重要的一環。中介軟體應該要能夠將遊戲資料匯出成與平台無關 (platform-independent) 的格式。在理想狀況下,這個格式仍應可以直接被遊戲系統讀取,然後在遊戲釋出版本的建置程序中,再使用命令列工具將這些遊戲資料轉換為高效能的特定平台 (platform-specific) 版本。

好的中介軟體是穩定的
中介軟體最主要的優勢之一,就是能夠釋放你的心思,讓你能夠專注在更關鍵的事物中。在這個層面上,中介軟體就像是程式編譯器一樣,使程式設計者免於擔心低階的實作細節,但前提是你必須要能夠信任編譯器!使用一個充滿臭蟲的中介軟體就像是身中「雙重詛咒」一樣,不僅無法減輕使用者的負擔,還會迫使我們不得不花費心思在某個陌生人所寫的程式碼之中。更糟的是,如果你自己修復了其中的臭蟲,就必須在每次中介軟體改版之後,自行處理相關的程式碼更新程序。請記得,中介軟體的益處只有在 API 不被使用者侵犯時,才能充分地展現出來。

好的中介軟體給予你源碼
儘管在前一則要點中,聲明了使用者不應該自行修改中介軟體,但是擁有存取源碼的權利,仍然是使用中介軟體時不可或缺的必須品。有時候,你會需要檢視程式碼的來龍去脈以追查遊戲中的臭蟲;而另外有些時候,則需要重新編譯源碼以連結相對應的建置設定值。在我使用過某款商業遊戲引擎的經驗裡,也曾經深入源碼追蹤一些可疑的問題,最後找出了潛藏在引擎程式碼中的臭蟲。如果沒有獲得存取源碼的權利,遊戲開發者就只能夠以不精確的試誤方式,猜測中介軟體裡可能存在的問題根源,因此將會使得遊戲開發流程更加地艱鉅困難。

As game developers, we’re looking for capable partners who we can trust to support us as we use their products and who we can trust to keep improving their products so we don’t fall behind the curve. We’re looking for relationships.

unreal-level-editor
(圖片來源:gamesprite.wordpress.com)

或許有些讀者會認為給予使用者源碼,不就等同於放棄了軟體開發的心血結晶與智慧財產權?實際上,中介軟體真正的價值並不在於源碼,而是在於開發商的品牌以及研發人才。購買中介軟體的遊戲開發者,並不是期望能夠買來隨插即用,然後就可以不用再去理會,從此過著幸福美滿的日子;反之,遊戲開發者與中介軟體開發商之間,應該比較像是伙伴之間的合作關係,而不是銀貨兩訖後就不再往來的交易行為。不論是後續的支援服務或者升級更新,都是選擇中介軟體的環節裡非常重要的考量點之一,而這也是商業引擎與其他免費程式碼或者開源引擎最關鍵的不同之處。

如果在缺乏仔細評估並謹慎考慮的情形下,原本節省遊戲開發經費的美意,最後反而可能會變成悔不當初的決定。雖然在網路上或者書籍裡,可以找到許許多多各式各樣免費與開源的程式碼、函式庫或者遊戲引擎,但是在開發預算動輒上看數千萬甚至上億台幣的的遊戲開發領域裡,我們承擔不起使用沒有售後服務與保障的免費程式碼、函式庫以及遊戲引擎的風險。

除了上述幾項要點以外,對於中介軟體的選擇,還有許多其他的問題需要納入考量,例如:中介軟體花費了多少記憶體使用量?需要使用多少 CPU 資源?升級到新版本時會不會很麻煩困難?與其他中介軟體的互動狀況如何?開發商的支援如何?或許是最重要的一點:要花費多少錢?以上種種問題都是必須依據個別產品需求進行考量的關鍵要點,而不變的規則是:在不外包核心競爭能力的前提下,應該要盡可能購買現成的中介軟體以協助遊戲的研發流程。

最後,作者列出了在《Fracture》開發流程中所使用的中介軟體:

  • Bink:影像壓縮。
  • FaceFX:臉部動畫。
  • FMOD:音源功能。
  • Havok:物理與動畫。
  • RakNet:低階網路層。
  • SpeedTree:種樹。
  • 其他:Boost、Zlib、Flex++、Bison++、EDGE 與 dlmalloc 等。

延伸閱讀:

10 thoughts on “《Good Middleware》:如何選擇遊戲開發的中介軟體”

  1. FMOD真的越來越多人用了。他們的服務真的很棒,甚至可以依客戶需求加上新功能,但是他們的PS2似乎沒有其他平台那樣好用呀~ (應該說,PS2沒有其他平台那樣好開發…)

  2. 順便好奇的問一下,請問站長是在哪邊看到ps2 dev kit半價的新聞呢?我只有看到ps3的半價了,而且半價後也還是10250美金耶~

    我家老大說ps2的目前好像也還是要10000上下,真是又笨又重又貴又不好維修!(哈哈發洩一下,最近在收尾了,照例在ps2上遇到很多鳥事…)

    http://www.gamespot.com/news/6183089.html

  3. 我同意使用middleware的時候
    擁有源碼是很重要的

    有時候使用者文件說的不是太清楚
    或是沒有/忘了更新
    看源碼最能了解當中內容

    當然除錯的時候有源碼會事半功倍

  4. @lsk:
    看樣子 WordPress 的 Akismet (Anti-Spammer) 對你使用的 Maxthon 瀏覽器不太友善。另外如果在留言內容中貼上網址連結,也很容易被誤判為 spam,真是非常的抱歉。現在猴子靈藥每天都會抓到很多的 spam 留言,所以還是需要像 Akismet 這樣比較嚴格防堵機制。在刪除每一則 spam 之前,我都會先瀏覽過以確保不會誤刪正常的迴響內容,還請各位多多包涵。 <(_ _)>

    我也認為 FMOD 的確是跨平台音源系統的第一選擇~

    關於 PS2 套件降價的消息在此。按內文所述,是對於 Casual Title 的開發者提供 $1000 美元的 debug console 價格。我沒有開發 PS2 遊戲的經驗,不知道這裡所提的 debug console 是否與 dev kit 不相同?

    另外,我好奇的是 PS2 開發真的如傳聞般很難搞定嗎? XD

    @Percy:
    使用 Middleware 或第三方函式庫時,最怕的就是那種沒有詳細說明的密技暗招與 presumption。而對於這些 implicit usage 的情境,又很難只依賴文件閱讀就能夠完全弄清楚,通常總是需要經過無數 trial-and-error 的血淚經驗,才能夠正確避開那些 pitfall。

    所以如果能夠存取源碼,我相信一定能夠讓程式設計者少掉幾根頭髮、少泡幾杯咖啡吧! XD

  5. 看到這篇文章,讓我想起一篇很有趣的新聞”開發too human的SK狀告EPIC不公平競爭”,內容主要是
    1.UurealEngine3未能如期交貨,甚至是大幅延期(比合約規定晚了一年),導致SK需自行開發引擎應急
    2.技術支援不夠即時
    3.從06年的GOW出色的遊戲表現來看,SK認為EPIC賣給他們的引擎遜色一籌,感覺自己花了大錢卻買到次貨

    我的感想
    SK在規劃開發時程時,居然敢採用一款當時尚未完成的引擎,心臟實在是很強,後來果然踢到鐵板,too human的PM不曉得有沒有被公司罵到臭頭

    不知半路你有沒有用過UE3,對它的印象如何?

  6. @larz:
    這則新聞我知道,去年我也曾經關注過一陣子。不知道目前雙方是否已經私下和解,或者還在打官司當中?事件的主要爭議點在於 Silicon Knights 公司認為 Epic 將他們所付的授權費,拿去投注在《戰爭機器2》的開發項目中,而沒有提供給他們關於 Unreal Engine 3 的良好支援與服務。

    我並沒有使用過 UE3,不過我記得《失落的奧德賽》的開發者曾說過,為了馴服 UE3 這隻巨獸,可是花費了他們非常多的心力。就我個人所知,UE3 像是一個超大型的遊戲編輯器,很多複雜的功能都能夠以視覺化的方式去製作與編輯。但是如果要開發一些引擎本身沒有具備的新功能,可能就要向下挖掘到幾百呎或者幾千呎的地方,也就是需要非常瞭解引擎的整體架構才行。

    結論就是:不是花大錢把引擎買回來就保證可以做出好遊戲,真正困難的事情還在後頭哩! XD

  7. 用過UE2.5,那時就已經是個大家伙了。
    但同時遊戲開發時其實並不靈活。比如當時的引擎中的網絡模型並不適合MMOPRG的開發,腳本系統也是有爭議的部分……

  8. @MrShooter:
    你好,

    我認為再怎麼優秀的遊戲引擎,也難以符合所有開發者的需求,所以自己動手增修部分功能,幾乎都是在所難免的事情。但如果開發者投入時間製作 Middleware 的插件或附加功能之後,最好能夠繼續沿用到往後的專案中,才可以使花費的開發成本得到最大效益。

    目前市面上,已有許多使用 UE 2.5 製作 MMORPG 的成功例子囉。

  9. @半路:
    你说的对,改是必须的。
    但同时要抛弃一些东西,比如UE的脚本系统,是一件非常痛苦的事情。

Leave a Reply