Roblox 如何評估「Build Game」的創作

Build 是我們全新的「行動優先」創作工具，讓 Roblox 使用者能透過文字提示來製作遊戲，並將其發佈給全球玩家。要生成一款完整的遊戲，需要一套端到端的自主生成系統：該系統須將程式碼、視覺資產、遊戲機制、使用者介面及操控方式協調整合，形成單一的複合式產出。此系統必須能穩健地處理因玩家輸入及多人互動所衍生的各種情境。 自紐西蘭推出 Alpha 版以來，已有超過 10 萬名玩家使用 Build 嘗試製作遊戲，並發布了約 9,000 款 Build 遊戲。^¹ 在數以千計使用 Build 製作遊戲的玩家中，有 71% 此前從未使用過 Roblox Studio，^¹ 這顯示他們正透過 Build 嘗試嶄新的創作方式。

然而，創作者只會在工具易於使用，且其生成的遊戲品質足夠高、能作為後續開發基礎時，才會採用這項新工具。為了了解透過 Build 製作的遊戲品質，我們會評估端到端的創作歷程，並利用這些評估結果以及創作者的回饋來改進產品。 我們的評估（eval）框架協助我們將「意圖理解」、「3D 可玩性」及「精緻度」列為優先改善項目。自 Build 在紐西蘭推出 Alpha 版以來，創作者滿意度提升了 10%，非預期輸出比例從 18% 降至 3%，且約有 14% 的提示式創作會話與 19% 的試玩測試最終成功發布。^² 這些是進展的描述性指標，而非單純針對評估影響所做的因果估算。

為何評估遊戲創作有所不同

遊戲與其他產生複合成果的系統（如應用程式、影片和世界模型）面臨著部分相同的評估挑戰。例如，品質取決於多個組件如何協同運作，且沒有任何單一組件的評分能完全描述最終結果。 

遊戲的獨特之處在於，其產出物是一個由玩家驅動的可執行、即時系統。反應速度、自主性、進度發展及遊戲手感等特性，皆透過互動而產生，僅憑檢視程式碼或資源無法完全評估。因此，遊戲必須跨越雙重門檻：既要達到低層級的正確性（無瑕疵且可遊玩），又要具備高層級的玩家體驗（感覺像是一款完成品，而非原型）。 

我們透過評估所尋求的答案，並非任何單一環節是否正確，而是整體作品是否符合創作者的意圖，以及玩家能否完整體驗整個遊戲流程。要回答這個問題，僅靠單一指標是遠遠不夠的。

四大指標，一個框架

我們的「Build」創作評估框架整合了四項指標。每項指標皆回答不同的問題、偵測不同類型的失敗，並產生具體的量化分數：

1. 遊戲規格品質（0 - 100 分）：Build 作為端到端的創作代理，會將創作者的提示轉換為規格，並據此生成遊戲。評分者將評估該規格是否明確做出重要決策、是否保留創作者的意圖、是否考量 Roblox 執行環境中的可行性，以及是否避免杜撰從未被明確提出的需求。

2. 靜態遊戲品質（0–100 分）：靜態評估器會在 Roblox Studio 編輯模式下檢查生成的遊戲。評估範圍包含遊戲結構、腳本、資源、屬性、連線，以及客戶端／伺服器邊界。 在此階段，我們旨在回答兩個問題。首先是遊戲是否建構正確：必備系統的實作、引擎 API 與網路連線的選擇、預期控制方式與 UI 元件是否齊備，以及遊戲架構的穩健性與一致性。 

其次是遊戲是否具備趣味性：核心迴圈的深度、內容的多樣性與難度遞增、進度系統、重玩價值，以及超越該類型遊戲常規的創新性。一款遊戲可能在架構上十分簡潔，卻缺乏內容深度；也可能充滿創意，但系統連結不佳。 

將這兩項檢視角度區分開來，並參照最佳實踐進行評估，能讓我們更精確地掌握遊戲在哪些環節存在不足。

3. 遊玩測試（0–100% 通過率）：遊玩測試評估員實際運行遊戲，並透過模擬真實玩家的輸入（包括點擊、按鍵及導航操作）執行測試計畫，而非透過程式碼觸發事件。 每項測試案例皆會驗證遊戲能否啟動、回應操作、順利推進、從失敗中恢復，以及是否能避免執行時錯誤。每項項目皆以二元「通過／未通過」判定，並以分級加權通過率搭配「可遊玩／不可遊玩」的明確結論進行報告。我們會重複執行測試以衡量結果的一致性。

4. 視覺與體驗品質（0–100 分）：遊戲的外觀與感受中，有些至關重要的要素無法從程式碼中讀取，因此視覺評審員會獨立根據在代表不同裝置的檢視窗中擷取的遊戲畫面，對呈現效果進行評分。此評分標準僅針對遊戲的視覺與音效表現，評估依據包含資產製作、介面完成度、動態效果、光影效果及音效。 核心問題在於：這款遊戲看起來像是一款可上市的產品，還是像一個原型？將視覺效果與遊戲機制分開評估，意味著「程式碼運作正常」與「遊戲看起來已完成」這兩項指標，不會被平均成一個具誤導性的綜合分數。

除了計分指標外，每次執行還會擷取僅供參考的指標，例如代幣使用量、工具呼叫次數、觸發的技能以及延遲。這些指標不會影響評估分數，但可能解釋結果產生的原因，並偵測到評分標準未能察覺的退化現象，例如同一款遊戲的建置成本卻增加了一倍。

這些指標與其所偵測到的失敗狀況相對應：

走過一個帶提示的 3D 障礙跑關

這些訊號在真實的提示中最容易辨識。例如：「一款真正的 3D 障礙跑酷遊戲，具備起跑平台、移動障礙物、檢查點及終點線。」障礙跑酷是 Roblox 上廣受歡迎的平台遊戲類型。即使提示並未規定每個實作細節，創作者的意圖仍十分明確。開發者需基於合理的假設來填補細節。

規劃與規格

開發團隊針對一款名為《Skyforge Ascent》的新遊戲編寫了一份規格書，詳細描述了一條包含檢查點及三種危險類型的五段式關卡。該規格書定義了核心循環、難度曲線、美術方向、畫面介面、疊加層以及操控方式。規格評估結果為 91/100 分，在完整性、準確遵循、可行性及內部一致性方面均獲得滿分。扣分原因來自兩個具體維度：實作細節與驗收標準涵蓋範圍。 

該規格書從未明確指定數值常數，例如旋轉速度、滑行距離、格子計時、平台尺寸或重置平面高度，因此工程師仍需自行設定這些數值。 此外，部分驗收標準（例如「約 24 個平台」或「天界熔爐色盤」）並無法嚴格驗證其真偽。高規格評分僅能證明該文件已具備開發準備就緒的條件。這些承諾能否經受實際遊戲開發的考驗，正是接下來三個階段將要衡量的重點。

靜態檢查：程式碼品質與內容品質

虛擬評審在未實際遊玩的情況下檢視了《Skyforge Ascent》的場所檔案，而兩組評估視角得出了不同的結論。

工程評鑑視角在讀取同一份場景檔案時，給予 98/100 的評分。它發現這是一個堪稱典範的建構，包含五個區段與三項移動式障礙物，並透過採用伺服器權威的順序檢查點、墜落重置系統，以及基於 StyleSheet 框架建構的介面，完全符合創作者的初衷。規格書中概述的一切皆已實現。唯一的問題是存在兩個未被使用的輔助函式導出。

設計視角則給予 31/100 的評分。雖然所有功能皆可正常運作，但在進度設計、重玩性、玩家自主性及原創吸引力這四項指標上，該遊戲均得零分。其核心循環過於簡單且線性——抵達每個檢查點，穿越終點線——不同遊玩過程幾乎毫無變化，也找不到讓人願意再次遊玩的理由。這只是障礙跑酷（obby）類型中的老套套路，而非具備獨特吸引力的遊戲。

這正是本次評測的發現。程式碼品質與內容品質是根本不同的維度，一個版本可能在其中一項近乎完美，卻在另一項上表現欠佳。若僅採用單一的綜合品質評分，便會將這兩者平均化，最終得出毫無意義的結果。

遊戲測試

遊戲測試代理以類真實玩家的輸入方式進行了跑關測試，並通過了測試計畫中的全部九項項目：在起跑平台生成角色、穿越3D幾何結構跨越間隙、承受危險衝擊、觸發檢查點與自動墜落恢復機制、完成跑關，以及重新開始——所有操作均未發生任何執行時錯誤。在此特定跑關中，《Skyforge Ascent》在遊戲測試中獲得了100/100的滿分。

完美的遊玩測試分數僅證明遊戲機制運作正常，且從頭到尾在技術上可遊玩。這並不能說明遊戲是否真正引人入勝或有趣——正是這項區別，使得「設計視角」評分僅為 31 分。

視覺品質

最後，評估系統針對手機大小的視口，對錄製的遊玩片段進行視覺呈現評分。《Skyforge Ascent》獲得 86/100 分：畫面簡潔、風格統一，且與典型障礙跑酷遊戲的視覺風格相符；平台幾何結構清晰可辨；危險元素標示明確；以及現代化且不礙眼的介面顯示。雖因些微的視覺限制而未能臻於完美，但並無任何瑕疵，亦無任何會讓玩家停止滑動的元素。

執行追蹤指標

同一輪遊玩過程也同步記錄了建置指標。遊戲建置耗時約八分鐘，未出現任何工具錯誤，且建置過程運用了 3D、UI、腳本編輯、資產插入及遊戲音效等技能。這些指標雖不會直接影響評分，但能揭示遊戲的製作方式，並能在未來建置速度變慢或成本增加卻未帶來相應效益時發出警示。

在五個評分階段中，《Skyforge Ascent》於遊戲規格、程式碼品質、內容品質、遊玩測試及視覺品質等面向獲得了不同的評分。其中四個面向顯示，「Build」能將單一提示轉化為完整、正確、可遊玩且具展示價值的 Roblox 體驗；而另一面向則指出，這並非一款玩家會願意重複遊玩兩次的遊戲。衡量這項差距——而非透過平均數加以掩蓋——正是「Build」評估的關鍵所在。

早期評估如何改善 Build 

評估結果不僅能產生分數，更能為產品改進提供可執行的方向。透過結合個別元件的除錯與整體系統層級的測試，針對標準化提示套件進行的離線批次評估，已直接形塑了 Build 的開發方向。 

1. 快速解決 Alpha 階段創作者的痛點：在紐西蘭的 Alpha 測試中，用戶反饋指出，當他們想製作 3D 遊戲時，Build 有時卻會生成 2D 遊戲。評估框架協助我們的團隊迅速提升 Build 的 3D 能力。短短兩週內，我們便改進了 Build 理解用戶製作 3D 遊戲意圖的能力——即使用戶並未明確表達此意圖。 我們還透過修正物件定位、光照等常見問題，進一步優化了 3D 遊戲的可玩性與精緻度。自此之後，「這不是我想要的」這類投訴在所有投訴中的占比從 18% 降至 3%；遊戲測試後的整體不滿反應也下降了 10 個百分點。在迭代框架本身的過程中，我們也累積了寶貴的經驗。 
2. 跨模型與架構的比較基準測試：我們運用評估框架，針對標準化的提示詞套件，對建構系統配置進行嚴格的基準測試。在將變更部署至生產環境之前，離線 A/B 評估報告會從以下四個維度，將候選版本與我們的生產基準進行比較： 

舉例來說，這些離線差異分析讓我們能夠釐清各種模型升級與代理路由決策如何影響個別品質指標：

• 基礎模型表現：升級基礎模型在每個指標上均帶來了穩定的提升——這使得首次嘗試的失敗建構次數減少、視覺精緻度更佳，且遊戲內容更為豐富。
• 代理路由架構：相反地，在雙代理架構中將特定子任務委派給輕量級模型，雖能維持內容深度與多樣性，卻導致可玩性與視覺完成度出現明顯退步。

1. 跨創作範式追蹤品質基準：我們亦運用此框架，透過最具代表性的評估資料集，來理解不同時間點的建構品質現況。這些資料集呈現了日益廣泛且複雜的創作任務的快照。
   最早期的資料集完全由機制相對簡單的 2D 遊戲組成。由於遊戲邏輯容易建構，因此遊玩測試分數往往較高；另一方面，正因相同原因，內容分數則維持在較低水準。
   當我們將焦點轉向 3D 遊戲時，評分分佈自然發生變化：實現無錯誤的遊玩體驗變得更具挑戰性，導致遊玩測試分數下降。由於資產未經細緻打磨，視覺分數維持平穩，使遊戲帶有原型般的質感。由於 3D 遊戲具有更深層次的潛力，內容分數相對較高——但由於單回合提示對內容擴展的空間有限，整體分數往往仍維持在較低水準。

1. 發掘各類型遊戲的特定瓶頸：評估數據亦凸顯出不同遊戲類型間存在顯著的效能差異。遊戲機制較為複雜的類型（例如角色扮演遊戲、射擊遊戲、競速遊戲）往往會遇到更多可玩性問題。 邏輯相對簡單的遊戲類型（例如生存遊戲和大亨模擬遊戲）在遊玩測試中表現往往更佳，這使得視覺精修與介面設計成為下一階段需解決的重點。了解不同遊戲類型的差異，促使我們擴充評估集，並在 Build 平台上的遊戲中進行更均衡的抽樣。
2. 在評估框架設計中汲取的教訓：針對框架本身進行迭代，讓我們學到了關於框架可靠性的關鍵教訓：

• 系統指標與元件指標：乾淨的程式碼結構或 API 使用並不能保證遊戲的可玩性。我們將正確性、設計與呈現分開考量，以避免掩蓋可處理的錯誤。
• 測試框架的弱點與人工校準：靜態檢查可能漏檢導致遊戲崩潰的執行時阻塞錯誤，而自動化遊玩測試則難以處理複雜的物理演算。我們會持續根據專業遊戲開發者與經驗豐富的社群評審，對虛擬評審系統進行校準。
• 擴展至多輪迭代與真實流量：由於真實創作者會持續迭代（新增系統、調整難度、修復錯誤），我們正擴展評估框架，以評估多輪編輯及真實世界的提示詞分佈。

下一步計畫

我們目前正致力於從五個方向擴展「Build」創作評估系統：

1. 涵蓋更廣泛的遊戲類型、2D/2.5D/3D 體驗、多人遊戲情境及複雜度層級
2. 對多回合編輯提供更強大的支援
3. 更可靠的遊玩測試、截圖、影片及音訊證據
4. 大規模校準至人類評分，並建立由創作者主導的基準案例
5. 更完善地整合離線評估、線上產品訊號與回歸測試

我們的長期目標是建立一個透明且持續改進的評估系統，該系統能從創作者最在意的層面來衡量 Build 的表現：即他們所能製作、測試、分享並持續開發的體驗品質。目前，這些指標被用於評估由 Build 生成的遊戲。隨著時間推移，當我們進一步精進這些指標並根據人類判斷進行校準後，它們將能推廣至其他創作工作流程，並協助在更廣泛的 Roblox 生態系統中，建立一套理解遊戲品質的共同語言。

關於 Roblox Assistant 代理系統評估的相關探討，請參閱《使用 OpenGameEval 對 Roblox Studio 的代理式 AI 助理進行基準測試》。