波希米亞互動 Enfusion 引擎開發的幕後
近期波希米亞互動宣布的 Enfusion 引擎之項目領導人 Pavel Šafář ，《武裝行動》與《Dayz》的開發人員在此與我們分享該引擎的開發幕後，聊聊該引擎擁有的特性、分享一些獨家螢幕截圖，並展示引擎的光照能力。
介紹
80.lv ：請你介紹一下你自己，以及你的團隊。你怎麼加入波希米亞團隊的？
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
Pavel Šafář：我的名字是 Pavel Šafář 而我是 Enfusion 項目中的領導人，也是波希米亞互動正在開發中的同名專利遊戲引擎。我在 2017 年時加入這個團隊，但我在 BI（波希米亞互動的簡稱）的職涯是開始於 2016 年在《Take On Mars》中擔任遊戲程式工程師。
當我加入 Enfusion 時，當時只有五個人在團隊裡，儘管因為開發《Dayz》中有涵蓋 Enfusion 的部分，因而他們不是全時投入開發。在那之前我不是項目領導而是個程式工程師。但在 2018 之後就不一樣了，而現今 2022，團隊內約有三十個人持續開發或維護 Enfusion 引擎的骨幹，而團隊也增長了不少。因為我們想以 Enfusion 來獻上我們次世代的多人遊戲與持續運行的線上遊戲。我們在 2020 時也有後端開發人員的加入。
我在加入 BI 之前並不是個專業的遊戲開發人員；我之前涉及的領域是在企業 IT。遊玩電子遊戲與寫程式是我日常愛好，所以我有著許多的原因來加入該產業。儘管換跑道的幅度有點大，但我想是我人生中最好的決定。
Enfusion 引擎
80.lv：Enfusion 如何誕生的？原始的計畫如何？你有什麼預定目標？
Pavel Šafář：一開始提及 Enfusion 是在 2014 年當我們 CEO 認定波希米亞需要開發一個更強大、更可拓性的遊戲引擎。但這也在實際開發之前花費了數年。我相信我們在 2018 年時從《Dayz》分支出原始碼。波希米亞也開始展現在 Enfusion 上全時投入可觀的注意與人力。
我們沒有什麼預定的目標。波希米亞互動在遊戲與遊戲引擎上的開發已經有著二十年的經驗，所以我們開發是基於與公司內經驗豐富的員工一同討論開始。我們與 Ivan Buchta ，那一位想要新引擎與遊戲續作中要加入什麼特性的創意總監聊了許久，且也依照他所要求的開發著所需的技術。
我們並非從零開始。我們從 Enforce 與 RV（《武裝行動》系列的引擎）引擎中重新採用不少的基礎。Enfusion 就類似於這兩個引擎的綜合體，儘管有許多元件已經重新編寫與更新。也刪除了數千行我們認為該重新編寫的程式碼，且要寫的更好或者不同。你沒辦法開發一個引擎一輩子；你在開發時也必須要有著遊戲項目為目標。而我們的第一個目標就是「移植」 《武裝行動 3》中美麗的 Tanoa 島至 Enfusion 中並運行在 PS4 上。我們選擇 Tanoa 島的原因就是因為夠大且有著許多實體在內，所以對於引擎來說一個很好的測試。在之前，我們在 Enfusion 之上有做一些其他小項目，包含著其中一個最終將會登陸 Steam 的原型作品－Project Lucie 。事實上－我負責著將 Oculus Rift 頭盔與控制器導 入 Enfusion 。
引擎的架構
80.lv：你能告訴我們關於引擎架構的部分嗎？新引擎的核心是？如何統整運作的？
Pavel Šafář：我們想透過 Enfusion 開發數款遊戲，但我們在這過程中要走好下一步。因此，我們需要好的引擎架構。也是被我們領銜引擎程式工程師持續專注的重要特點。簡單來說我們無法帶入特定遊戲的特性到引擎核心中；我們得將兩者分開，儘管也因此有些「間接成本」。但對長期發展來說是必要的。
引擎大致上由 C 與 CPP 編寫。我們在最新版本的程式語言中帶來的新特性有點保守使用，我們也對引擎中導入的函式庫也十分注意。因為引擎必須有著跨平台能力，我們在選擇函式庫與框架時要不斷注意這一點。目前來說，我們支援個人電腦上的 Windows系統、Xbox 與 PS 平台之外，我們也有支援 Linux，但僅在專屬伺服器上。我們盡可能減少平台專屬的代碼。能通用運行的就通用。我們的遊戲不論在大小、模擬、資料上的規模都很大，因此我們的引擎必須要高度最佳化才行。
其中一個我們想強化與改進的關鍵特性就是在 Enfusion 中的模組支援性，包含著對我們工具的支援。這也在重要層面上對架構的影響極大。而另一個我們考慮到的就是要讓 Enfusion 能夠驅動大且動態的多人遊戲，即使在中階硬體上也能運行。我們無法預先烘焙（電腦科學用語中意旨預先運算好的資料，如打光資料等...）許多資料，但大部分能在運行時重新整理與編譯。
我們想要 Enfusion 十分強大。不止對我們 CPP 開發者來說，但對技術設計、腳本編寫者，也就是我們社群中的內容開發者們也有感。在那之前，我們的腳本語言 Enforce 與我們特性豐富的腳本編輯器正在架構中最重要的一部份。它們快速且提供許多可能性，這也是為什麼一些重要的遊戲元件能夠做到且能夠用 Enforce 腳本開發。
我也提及過編輯器。我們稱其為「工作台」，也可以當作 IDE（整合開發環境，電腦科學擁有：編寫、除錯、運行的程式開發軟體的簡稱。）你可以在那找到你想開發遊戲或在 Enfusion 上開發遊戲內容時需要的一切。我們的座右銘：「不再需要文字編輯器。一切所需可能盡在工作台」。
80.lv：對於新加入團隊的藝術家上手難度有多難？當有人問你，如果與目前已有的方案有哪些差異來說，你該如何陳述？
Pavel Šafář：在我們遊戲團隊中有許多不同的藝術者。我們就舉例那些製作模型的舉例好了，像是（網狀、貼圖、材質）。令人驚訝的是，Enfusion 並不強制要求瞭解藝術家不知道的特定知識或流程。我們的模型導入流程是相容於其他遊戲引擎的，所以即使是「非 Enfusion 」的模型也能夠導入且你應該能看到結果。這大致上對於靜態物件就足夠了。對於動態物件來說，你需要在資料中添加許多資訊。這也是為什麼我們會釋出相關指南與文件，來讓大家都能瞭解如何在我們的遊戲中讓素材正常運作。而且，我們的技術性藝術家也正試圖讓這些素材能夠與 Blender（免費開放原始碼的 3D 建模、動畫、影片剪輯等美工軟體）相容。因此讓其能夠在導入 Enfusion 前能夠在 Blender 預覽成果。這會大幅增快建模流程。
再來就是關於我們音效藝術家。感謝我們強大且資料驅動的音效編輯器，他們能夠設計聲音在多個狀況下如何「混音」。沒錯，一樣沒有編輯配置－一切都在音效設計師手上。一個新的音效設計師應該不會在聲音與 Enfusion 中的聲音特效上不會太棘手。在特性層面上，我相信我們會釋出重要的音效工具，所以他們不用透過第三方的中介軟體解決問題。
接下來就是動畫師、視覺特效藝術家也要納入考量。兩者都會再製作他們所需特效時，能使用著強大且易用的編輯器。波希米亞互動有著自己的動作捕捉工作室來製作動畫，因此我們在導入 Enfusion 之前會用 Motion Builder。且那是第三方軟體，且非免費。而我們在建模上也是。因此在 Enfusion 中將支援 Blender 中的動畫製作，甚至可以使用 Rigify 等插件。基本上，你不需要任何付費軟體就能準備 Enfusion 的遊戲資料。
整體來說，我相信對其他遊戲引擎有開發經驗的人應該會發現我們的資料流程十分標準。
引擎的可能性
80.lv：你曾提及引擎能夠打造令人置信的環境。哪些元素令其讓人置信的？科技帶來了哪些新的可能性？
Pavel Šafář：其實不少，事實上。首先就是大小。我們想要我們的世界又大又廣，沒有人工的邊界。其次就是世界的模擬；主要專注於日、夜循環與天氣。為此，我們需要對大氣層有著非常精準的模擬，包含著雲層。然後以及物件的數量。我們的森林非常密集，且在每個世界中有著將近數百萬顆
樹。另一個元素就是養眼的雜草，可能 2D 或 3D。我們想要我們的玩家能看見非常遠的遠景。這也在我們大多渲染數百公尺內的陰影添上了一層調戰。我們想要下雨時有著潮濕的素材，出太陽時也會乾掉。還沒及提光線反射。當你設計一個新世界，因為我們模擬太陽的路徑，你必須矯正位置，包含星星在內。如果你在夜晚中望向天空，你可以物理性的看見它們。我們想要讓你能夠在我們的遊戲中透過星星來指路，或者至少在夜晚中有著月光指引你。我們想要室內與戶外有著不同的照明，我們想要有湖泊、溪流、大岩石、馬路、小路、電線及許多其他音效與視覺元素來讓你像是身處於遊戲中一樣。許多很美好的事物已經能夠達成，但我們依然有著一整張列表寫著我們想加入的特性。
80.lv：技術上如何應付大規模的開放世界？它如何處理著植被、複雜幾何物以及巨大的地形？
Pavel Šafář：我們在地形上使用動態 LOD（細節層次，電腦圖形上一種技術，使物件在不同狀況下有著不同的細節度），包含著海洋的模擬。細節層次是很常見的最佳化手法。在模型骨骼動畫上，我們不會去播放你看不見的地方。我們使其與物件的 LOD 融合。許多模型，特別對地形來說，有著遮檔過濾來告知渲染器在幾何之後是否要渲染或丟棄。我們也在多人中串流著許多東西來在可接受層度之下保持低流量與高效的伺服器效能。畢竟你無法把整個世界丟入到記憶體中，因此我們串流著它（像是：貼圖、音效、網狀等...）。
我們也用著在《武裝行動 3》上相近的植被手段，儘管我們改進了許多。樹木與草叢為普通物件且能套用細節層次系統。雜草雜物的渲染也是基於攝影機的附近至可設定的特定距離，我們讓其能夠與地形完美融合。
任何只能夠在 GPU（圖形處理器，顯示卡的核心）上能模擬，「只能夠」。可惜的是，我們通常需要透過 CPU（中央處理器）計算許多圖形效果之外還有其他像是音效方面的東西。除此之外它們影響著物理效果以及需要在多人中重疊。為了我們的遊戲創作這個技術並不容易。
光照
80.lv：你可以討論一下關於對於光照、天空盒、風以及其他天氣特效的引擎工具嗎？是否支持複雜的霧效果？
Pavel Šafář：天空盒（電腦圖形技術中，一種模擬天空與周圍用的密閉環境）在靜態環境中不錯，但在我們的情況下不適用。至少不能用於在天空中的動態物件。我們的天空與大氣層必須是動態的。我們投入相當大的努力至天空的物理模擬上，使其盡可能的逼近真實。我們移除了我們在《Dayz》中使用的雲層渲染技術並編寫一個新的。花了一些時間，但我們對於細節與渲染距離、陰影等很滿意。我們也從新編寫了整個渲染器；它在個人電腦上且在《Dayz》中也不在使用 DX 11。相反，我們渲染後端將以 DX12 為基礎編寫，因而我們能夠高度最佳化。我們也對 PBR（物理為基礎的渲染，電腦圖形上以物理層面模擬渲染的特性。光追、PBR 材質等皆有使用到其特性。）的光照模型有所變動。我們依然支持舊的 RV 材質，但它們在新的光照模型中可能看起來不太好。
這可能對《武裝行動 3》的內容創作者們來說是個壞消息因為他們沒辦法讓他們的材質在物件上好看又穩定。而也因此，我們也有對於轉換流程有製作相關文件說明。我們使用光照探測器來捕捉光照條件與反射。我們對於室內環境也有對應的解決方案。天氣特效也是由新的天氣編輯器驅動。將會有真的數百條的滑條與曲線來讓你達成你想要的效果，包括不同天氣的轉換。
渲染器與著色器在近年來也有大幅進步而我們對於整體結果來說十分驕傲，比起任何特性來說更高興。我們現在能在渲染特性集結一塊時能夠在截圖上看到不錯的結果。這讓我們由心而生出喜悅。
多人
80.lv：請告訴我們多人方面。你對此設計時需要什麼？
Pavel Šafář：世界的狀態需要同步或者確定性的模擬（像是雲）。這將會非常劣勢，舉例來說，玩家 A 待在陰影中且因為雲朵的陰影使其可見度降低，但其他玩家卻可以看到他被太陽照亮。但另一方面來說，在多人模式中的同步中並不是最嚴苛的，尤其考慮著在場景中有著數百、數千的其他重疊實體。
在很久之前我們就決定我們的多人架構基於一個十分強勢的伺服器。任何與遊戲狀態相關的是由伺服器驗證與模擬的。客戶端提供輸入且與伺服器同步，且在介入狀態中從伺服器獲得資料。舉例來說，客戶端不能更改遊戲內當天時間，因為是被伺服器控制的。在一些情況下，我們也能夠限制渲染距離，不讓擁有較強硬體配備的玩家在多人中占優勢。
我想在我們實做重疊層時，最重要的其中一方面就是如何對內容創作者的影響，我們不在乎客戶端與伺服器但卻是擁有權。這也讓我們，包含模組作者們能夠編寫著能夠在多人模式中運行的程式碼與腳本，包含單人情境在內。不再根據你是伺服器或者客戶端而該發生什麼事，這會給模組作者有著很大的權力因為他們能夠編寫整個多人模式系統。當然，他們也得先知道相關在多人運行環境下的腳本編寫。
模組化
80.lv：可以討論一下關於模組化的部分嗎？你如何更改他？而且，你製作了哪些工具來吸引使用者？
Pavel Šafář：不論是否要修改 Enfusion ，會有著數層介面的設計。幾年前，我們實做了 Prefabs（預製物件，在遊戲製作中，一個製作好共用的物件帶入不同程式環境中。減少重新製作與編寫物件的浪費。）在現在是一個很常見的東西了，但我們再預製物件中的實體能有著複雜的結構。預製物件也支援著層次結構與繼承特性。這給你在整理我們的資料上有很大的權力。我們甚至支援預製元件及其繼承特性，這在其他遊戲引擎並不常見。沒錯，既使使用預製物件，你依然能在特定情節下做出一些局部改變。
再來就是我們有配置，這對《武裝行動》社群來說十分熟悉。我們的配置也提供著上述所提及一模一樣的東西。你能夠繼承配置且你能在配置中又有個配置。資料類型（電腦程式中，物件的資料類型）能透過腳本自訂，所以引擎能夠檢查你的配置是否正確。你也能夠在編輯器中編輯配置時，有著可用的 UI 小工具。
再來就是模改能力。你可以繼承你模組中的一個配置與預製物件並從那繼續使用。或者你也可以覆蓋部分內容。我們不做覆蓋整個預製物件，我們是做整合。因此舉例來說，你可以有著多個模組變動著同一個配置。
以上所述都能在編輯器辦到，這也大概是我們給予創作者們最佳有用東西之一。他們能夠模改一個配置。當他們更改屬性時，我們會展示哪些遭到變動。變動能夠還原（像是你能還原原始檔案等...）。許多特性已經實做至編輯器中且我們的編輯器能夠支援。
額外的，整個模組的打包與推送過程將經由工作台經手。你在傳送模組至工作坊讓玩家下載時，你不必離開編輯器。
未來
80.lv：你目前的路程圖是什麼？什麼新的特性你想加入？是否在這過程中有遇到瓶頸？在接下來的這年有什麼計畫嗎？
Pavel Šafář：我們目前的計畫是釋出遊戲試玩來展示引擎的能力。我們也相信我們會全年支持。我們並不是指說人們會找到的問題。我們期待人們會開始玩弄著我們的引擎與編輯器，也相信接續的後果就是會出現許多我們要應對的，包含遇到的問題、想問的問題，以及該建文檔的新特性。
遊戲引擎的開發是無止盡故事而我們已經有著許多內部團隊請求的特性。我們知道目前的特性且我們想要去解決，有著幾個想法來讓 Enfusion 更向前一步。但我不期待我們會在今年增加跌破眼鏡等級的東西。但如果我們絕對會讓你知道。
Enfusion 項目領導人－Pavel Šafář
訪談人－Arti Sergeev
中文翻譯－DS
