今年初，The Game Kitchen工作室推出戰(zhàn)術(shù)RPG《瘋狂之石》（The Stone of Madness），玩家需帶領(lǐng)五名囚犯逃離宗教裁判所監(jiān)獄。本文由團隊三位核心開發(fā)者親自解析開發(fā)過程中解決的渲染、UI及測試難題。

我們是Game Kitchen工作室，最近剛剛在PC和主機平臺發(fā)布了《瘋狂之石》。在此，我們想從技術(shù)角度分享開發(fā)這款最新作品時遇到的一些最緊迫的挑戰(zhàn)，并通過實際案例加以說明。在這篇合作撰寫的文章中，我們的編程團隊將詳細解析在Unity中實現(xiàn)的關(guān)鍵解決方案，這些方案不僅優(yōu)化了游戲性能，還提升了開發(fā)效率。

首先，圖形程序員Adrián de la Torre將介紹我們如何設(shè)計和渲染游戲的美術(shù)管線，以實現(xiàn)其獨特的視覺風格。

接下來，UI程序員Alberto Martín將詳細說明我們如何利用Noesis（即NoesisGUI，專為游戲和實時應(yīng)用程序設(shè)計的高級UI開發(fā)框架）來簡化UI開發(fā)流程，并根據(jù)用戶反饋進行UX改進以優(yōu)化工作流。

最后，玩法程序員Raúl Martón將展示我們如何在服務(wù)器上外部化和自動化復(fù)雜游戲行為的測試，確保在不影響系統(tǒng)集成的情況下處理多個邊界案例（corner cases）。

視覺效果挑戰(zhàn)：通過定制渲染管線解決

Adriándela Torre，The Game Kitchen 圖形程序員

《瘋狂之石》將2D視覺效果與3D玩法機制相結(jié)合，這帶來了獨特的技術(shù)挑戰(zhàn)。玩家看到的是2D世界，而游戲的底層系統(tǒng)卻在三維空間中運行，形成了獨特的設(shè)計二元性。

為解決這一挑戰(zhàn)，我們開發(fā)團隊創(chuàng)建了一個定制渲染管線，有效彌合了3D玩法信息與2D視覺表現(xiàn)之間的鴻溝。該方案通過多重渲染通道和專門技術(shù)，在保持視覺一致性的同時保留了預(yù)期的游戲深度，實現(xiàn)了3D元素到游戲獨特2D美術(shù)風格的無縫轉(zhuǎn)換。

在《瘋狂之石》中，幀渲染主要由兩個場景構(gòu)成：

第一種場景我們稱之為代理場景（Proxy Scenario），由計算最終幀光照的幾何圖元組成。

底層3D場景視圖（代理場景）

第二種是畫布場景（Canvas Scenario），由與代理幾何體形狀和位置相匹配的精靈圖組成。畫布通過分層排列來模擬3D空間，并為移動游戲元素實現(xiàn)正確的Z軸排序。

2D場景視圖（畫布場景）

以下將詳細介紹我們圖形管線中幀渲染的每個步驟：

游戲渲染流程概述

1.視覺錐（Cone of vision）

當視覺錐或游戲技能被激活時，將啟動管線的第一步。我們會在NPC的視點（PoV）位置放置一個攝像機，用于渲染其視野范圍（FoV）內(nèi)代理模型的深度信息。

由NPC視點攝像機生成的深度紋理

然后，在另一張渲染紋理中，攝像機會在B通道輸出玩家原點距離的漸變，該漸變用于技能特效的范圍效果。

由玩家視點攝像機生成的漸變紋理

利用NPC視點（PoV）的渲染紋理，視覺錐攝像機會在R和G通道上疊加一層錐形區(qū)域，并存儲障礙物和距離信息。

視域錐（cone of view）覆蓋在漸變紋理上

最終渲染通道將聲波數(shù)據(jù)寫入Alpha通道。

聲波信息疊加在漸變紋理的Alpha通道上

這是本步驟生成的最終紋理，將被用于畫布攝像機（Canvas Camera）階段來渲染場景中的精靈。

用于渲染技能范圍和視錐的最終紋理

2.畫布Render ID攝像機

在我們的項目中，每個代理模型都有一個對應(yīng)的Render ID（浮點數(shù)值）。代理模型與其關(guān)聯(lián)的精靈共享相同的Render ID。在這一步驟中，我們將這些Render ID的浮點數(shù)值渲染到一個紋理中。

Render ID紋理。每種色度代表代理模型與其對應(yīng)精靈共享的唯一Render ID。

在后續(xù)步驟中，我們將使用此紋理將代理場景中計算的光照信息與畫布場景中的精靈進行匹配。

3.光照系統(tǒng)

游戲中的光照由以下類型組成：

• 烘焙光照：持續(xù)生效的固定光源（如室外光照）

• 混合光照：可開關(guān)的靜態(tài)場景光源（如蠟燭）

• 實時光照：可在場景中移動并開關(guān)的動態(tài)光源（我們僅在一處實現(xiàn)此效果

  ——Alfredo的油燈）

  
  

《瘋狂之石》中不同類型的光照效果概覽

利用RenderID紋理，我們創(chuàng)建了一個包含代理場景光照信息的渲染紋理。

基于Render ID紋理和光照計算生成的陰影紋理

4.畫布攝像機

在創(chuàng)建完所有渲染紋理后，攝像機開始渲染包含光照信息、技能作用范圍、視覺錐和噪聲波紋的精靈

精靈渲染流程概覽

5. 后處理

在后處理階段，會應(yīng)用色彩分級（Color Grading）、暗角效果（Vignetting）以及其他特效。

后處理效果應(yīng)用概覽

6. UI

最后疊加UI。

UI疊加流程概覽

UI開發(fā)中的挑戰(zhàn)：加速UI開發(fā)流程

Alberto Martín，UI程序員，The Game Kitchen

《瘋狂之石》最終版包含50多個用戶界面。這是因為游戲需要向玩家展示大量信息。由于團隊初期規(guī)模較小，UI工作耗時巨大，因此我們持續(xù)優(yōu)化流程以確保在最短時間內(nèi)獲得最佳效果。

UI工作貫穿整個項目周期，因此確保UI/UX設(shè)計師清楚理解所有需要實現(xiàn)的功能至關(guān)重要。為了保證良好的用戶體驗和游戲樂趣，我們特別注意保持編程團隊與設(shè)計團隊之間的暢通溝通。

為了打造最佳的UI組件，我們打破了技術(shù)團隊與創(chuàng)意設(shè)計/用戶體驗研究團隊之間的隔閡，讓所有人都能積極參與游戲開發(fā)。以下是我們的雙軌工作流程。

┃UI設(shè)計中的創(chuàng)意設(shè)計與用戶體驗研究

我們的UI/UX設(shè)計師負責定義游戲最終界面元素的視覺呈現(xiàn)，并確保為用戶提供令人滿意的體驗。基于這一目標，他們從設(shè)計之初就遵循兩個核心原則：一是保持每個元素的技術(shù)負載最小化，二是通過潛在用戶驗證設(shè)計效果。具體實施流程如下：

1. 需求分析：理解玩家需求，列出游戲需求和用戶目標

2. 調(diào)研：研究其他游戲如何處理類似問題

3. 線框圖：設(shè)計結(jié)構(gòu)和布局（此時不包含最終美術(shù)）

4. 高保真原型：使用既有元素（按鈕、滾動條、框架等）搭建近乎完整的設(shè)計界面，便于快速迭代

5. 交互原型：在Figma中構(gòu)建原型，模擬手柄和鍵鼠操作，展示實際環(huán)境中的工作方式

6. 用戶測試：使用原型進行測試，驗證第一步確定的需求和目標

7. 迭代階段：根據(jù)測試結(jié)果進行技術(shù)實現(xiàn)、繼續(xù)迭代或進一步測試

《瘋狂之石》物品欄標簽頁導(dǎo)航設(shè)計原型展示

┃技術(shù)UI的實現(xiàn)

如前所述，《瘋狂之石》的UI元素數(shù)量極為龐大。開發(fā)專屬UI引擎成本過高，因此我們需要采用一個易于學(xué)習(xí)、且具備完善工具鏈和工作流的框架。經(jīng)過對多種中間件的評估，我們最終選擇了遵循MVVM（Model-View-ViewModel）設(shè)計模式的Noesis GUI。

選擇Noesis的原因在于其基于WPF（Windows Presentation Framework）架構(gòu)，并完整遵循MVVM模式。這使得我們可以復(fù)用絕大多數(shù)WPF技術(shù)文檔、參考文獻和論壇資源來解決常見問題。該框架已有18年歷史（自首次發(fā)布至今），被大量UI開發(fā)人員所熟知，這讓我們能夠從更廣泛的人才庫中招募專業(yè)人員來開發(fā)項目所需的界面和工具。Noesis的另一大優(yōu)勢是我們可以直接使用WPF的原生工具鏈。

通過XAML標記語言，我們的UI創(chuàng)意團隊能夠以最低限度的技術(shù)介入?yún)⑴c布局設(shè)計和元素優(yōu)化。得益于MVVM架構(gòu)，技術(shù)UI團隊可以專注于功能實現(xiàn)，僅在必要時為創(chuàng)意團隊提供特定領(lǐng)域的支持。

測試（如何在系統(tǒng)性設(shè)計中保持理智）

Raul Martón，玩法程序員，Teku Studios

《瘋狂之石》的核心玩法建立在三大基礎(chǔ)支柱之上：玩家技能系統(tǒng)、NPC人工智能和場景交互機制。這三個系統(tǒng)深度耦合，使得玩家需要應(yīng)對的復(fù)合情境數(shù)量呈指數(shù)級增長，這也意味著我們需要測試的潛在場景數(shù)量激增。

項目啟動初期，我們就意識到傳統(tǒng)QA測試體系將難以滿足需求。當多個系統(tǒng)以特定方式交互時，會產(chǎn)生海量不可控的復(fù)合情境。更關(guān)鍵的是，這些情境可能發(fā)生在極短的時間窗口內(nèi)，遠超人工QA團隊的測試響應(yīng)極限。

為此我們開發(fā)了自動化測試套件。該方案的核心理念是：將所有開發(fā)團隊能夠預(yù)見的系統(tǒng)關(guān)聯(lián)情境，通過模擬游戲環(huán)境進行高效自動化驗證。

例如在實現(xiàn)女主角Amelia Exposito的扒竊技能時，我們通過自動化測試確保：

• 基礎(chǔ)功能驗證：當對NPC實施偷竊時，正確觸發(fā)扒竊小游戲并暫停主游戲流程

• 邊緣場景覆蓋：當存在目擊者（如警衛(wèi)）或目標NPC處于移動狀態(tài)時，禁止偷竊行為

扒竊技能的自動化玩法測試，驗證該技能在不同游戲場景中是否按預(yù)期運作

┃創(chuàng)建集成測試

每個集成測試需基于以下要求進行配置：

1. 專門設(shè)計的測試場景

為測試扒竊技能，我們創(chuàng)建包含兩名警衛(wèi)和一名玩家的場景。精確調(diào)整角色朝向以確保測試條件成立（注：玩家在警衛(wèi)視野范圍內(nèi)無法使用扒竊技能）。

此外，場景中應(yīng)僅包含測試該場景所需的最簡組件，因為多余元素會給測量結(jié)果帶來干擾。這就是為什么我們的示例場景沒有HUD（平視顯示器）、手動輸入系統(tǒng)、音效等元素。

• 這一步驟要求游戲結(jié)構(gòu)具有高度模塊化特性，雖然需要一定前期投入，但一旦實現(xiàn)將物超所值！

2. 能夠強制觸發(fā)待測試場景的測試代碼

我們需要測試的許多場景往往難以手動創(chuàng)建且耗時，甚至需要通過代碼推送才能觸發(fā)。

例如，若想測試“NPC僅在移動時才會觸發(fā)捕鼠夾”的場景，就需要按以下步驟操作：

1. 加載場景

2. 等待1秒

3. 在NPC腳下生成捕鼠夾

4. 再等待1秒

5. 命令NPC開始向任意方向移動

由于該測試環(huán)節(jié)對開發(fā)中的變動極其敏感（可能受游戲規(guī)格變更或各種意外場景影響），因此必須確保測試代碼和反饋信息絕對清晰。

最糟糕的情況莫過于測試失敗時，卻無法獲取任何明確的錯誤信息。

3. 一套能夠可靠判斷場景是否按預(yù)期運行、或檢測出邏輯錯誤的機制

自動化測試仍需要人工監(jiān)督。隨著測試數(shù)量增加、測試項日益細化，監(jiān)控難度會大幅上升，甚至可能出現(xiàn)測試時長不足、測試不充分導(dǎo)致結(jié)果可能不準。為解決這些問題，我們開發(fā)了定制化工具。

例如，部分測試涉及場景中多個NPC的復(fù)合交互行為。為有效監(jiān)控這類情況，我們專門構(gòu)建了一套系統(tǒng)，用于記錄測試過程中NPC經(jīng)歷的不同AI狀態(tài)循環(huán)。

自動化測試中守衛(wèi)NPC未能按預(yù)期執(zhí)行追擊序列

我們還需要一個完善的API來獲取當前游戲狀態(tài)的可視化數(shù)據(jù)（例如：NPC是否已被擊暈？NPC是否進入逃跑狀態(tài)？觸發(fā)次數(shù)？哪個玩家角色被捕獲？等等）。

4. 快速啟動測試的系統(tǒng)架構(gòu)

與單元測試不同，自動化測試需在游戲?qū)崟r運行時進行，這可能導(dǎo)致測試效率低下。

在這種情況下，我們充分利用了游戲沒有采用Unity標準更新系統(tǒng)的特性。我們所有組件都使用了Tick()函數(shù)，這個函數(shù)通過游戲引擎以可控方式調(diào)用，從而模擬Unity的更新機制。

該設(shè)計幫助我們實現(xiàn)了兩大測試目標：

? 首先，我們通過強制函數(shù)加速測試執(zhí)行，使單游戲幀內(nèi)可處理多幀代碼邏輯

? 其次，由于測試需實時運行，其結(jié)果易受測試設(shè)備幀率波動影響。通過轉(zhuǎn)換為固定幀率控制，我們消除了這種差異：確保測試通過率在所有設(shè)備上保持一致（反之亦然）

下方就是測試結(jié)果。

通過控制游戲更新加速自動化測試：The Game Kitchen的自定義Tick()系統(tǒng)可實現(xiàn)單游戲幀內(nèi)運行多測試幀，既提升執(zhí)行速度，又確保不同設(shè)備間的結(jié)果一致性。

┃安全測試是幫助我們避免損壞構(gòu)建版本的

隨著測試套件的創(chuàng)建，我們還需要實現(xiàn)一種保護機制：當分支代碼存在缺陷時，自動中斷其合并流程。為確保這一點，我們創(chuàng)建了一個自動合并腳本，該腳本會在每次更改提交到項目主分支時觸發(fā)。

這個腳本會啟動所有測試并監(jiān)控結(jié)果。如果任何測試失敗，它將返回錯誤檢測并中斷合并。

通過這個系統(tǒng)，我們可以避免這種情況：看似獨立的系統(tǒng)更改破壞了與其交互的其他功能模塊。

感謝The Game Kitchen分享《瘋狂之石》開發(fā)的幕后細節(jié)。

Unity 官方微信

第一時間了解Unity引擎動向，學(xué)習(xí)進階開發(fā)技能

每一個“點贊”、“在看”，都是我們前進的動力