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

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

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

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

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

視覺效果挑戰：通過定制渲染管線解決

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

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

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

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

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

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

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

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

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

游戲渲染流程概述

1.視覺錐（Cone of vision）

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

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

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

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

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

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

最終渲染通道將聲波數據寫入Alpha通道。

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

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

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

2.畫布Render ID攝像機

在我們的項目中，每個代理模型都有一個對應的Render ID（浮點數值）。代理模型與其關聯的精靈共享相同的Render ID。在這一步驟中，我們將這些Render ID的浮點數值渲染到一個紋理中。

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

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

3.光照系統

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

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

• 混合光照：可開關的靜態場景光源（如蠟燭）

• 實時光照：可在場景中移動并開關的動態光源（我們僅在一處實現此效果

  ——Alfredo的油燈）

  
  

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

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

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

4.畫布攝像機

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

精靈渲染流程概覽

5. 后處理

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

后處理效果應用概覽

6. UI

最后疊加UI。

UI疊加流程概覽

UI開發中的挑戰：加速UI開發流程

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

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

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

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

┃UI設計中的創意設計與用戶體驗研究

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

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

2. 調研：研究其他游戲如何處理類似問題

3. 線框圖：設計結構和布局（此時不包含最終美術）

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

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

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

7. 迭代階段：根據測試結果進行技術實現、繼續迭代或進一步測試

《瘋狂之石》物品欄標簽頁導航設計原型展示

┃技術UI的實現

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

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

通過XAML標記語言，我們的UI創意團隊能夠以最低限度的技術介入參與布局設計和元素優化。得益于MVVM架構，技術UI團隊可以專注于功能實現，僅在必要時為創意團隊提供特定領域的支持。

測試（如何在系統性設計中保持理智）

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

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

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

為此我們開發了自動化測試套件。該方案的核心理念是：將所有開發團隊能夠預見的系統關聯情境，通過模擬游戲環境進行高效自動化驗證。

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

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

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

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

┃創建集成測試

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

1. 專門設計的測試場景

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

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

• 這一步驟要求游戲結構具有高度模塊化特性，雖然需要一定前期投入，但一旦實現將物超所值！

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

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

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

1. 加載場景

2. 等待1秒

3. 在NPC腳下生成捕鼠夾

4. 再等待1秒

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

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

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

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

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

例如，部分測試涉及場景中多個NPC的復合交互行為。為有效監控這類情況，我們專門構建了一套系統，用于記錄測試過程中NPC經歷的不同AI狀態循環。

自動化測試中守衛NPC未能按預期執行追擊序列

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

4. 快速啟動測試的系統架構

與單元測試不同，自動化測試需在游戲實時運行時進行，這可能導致測試效率低下。

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

該設計幫助我們實現了兩大測試目標：

? 首先，我們通過強制函數加速測試執行，使單游戲幀內可處理多幀代碼邏輯

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

下方就是測試結果。

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

┃安全測試是幫助我們避免損壞構建版本的

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

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

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

感謝The Game Kitchen分享《瘋狂之石》開發的幕后細節。

Unity 官方微信

第一時間了解Unity引擎動向，學習進階開發技能

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