騰訊游戲用一只“貓”，直接AI生成3D游戲原型？

用AI把“頁游”轉換為虛幻大作。

整理/秋秋&電了個教

今年的GDC（游戲開發者大會）上，騰訊游戲帶來了20多場涵蓋游戲開發、AI工具、工程技術等領域的精彩分享。

其中，光子工作室群資深工程師（principal engineer） Yang Hao 帶來了一場題為“AI驅動的3D游戲原型開發：引擎集成實踐（AI-Driven 3D Game Prototyping with Engine Integration）”的技術演講。

傳統游戲原型制作往往面臨較高的技術壁壘，而目前市面上的AI生成工具多局限于Web端，難以與虛幻（Unreal）等專業3D引擎整合。

本次演講分享了騰訊游戲如何通過一套“C.A.T.原則”，讓AI理解3D空間數據，實現從Web端2D原型到引擎內3D高保真原型的無縫轉換，以及如何在生產管線中利用Agent（智能體）進行自動化測試與Bug修復。

以下為經過整理的演講實錄，內容有所刪減調整：

01

游戲原型制作的瓶頸

大家早上好，我是來自光子工作室群的資深工程師 Yang Hao。在過去的十多年里，我曾負責過千萬級DAU休閑游戲的后端架構，也主導過無縫開放世界底層服務器系統的開發。

而在過去的三年里，我將研究重心轉向了AI、游戲引擎以及AIGC的工業化落地。

今天，我想和大家探討如何使用AI和虛幻引擎（Unreal Engine）來構建游戲原型（Prototypes）。雖然我以Unreal為例，但這套思路同樣適用于其他引擎。

讓我們先來談談原型制作（Prototyping）。

傳統上，原型制作是游戲開發早期必不可少的一環。一個可運行的原型不僅能測試核心玩法，也是我們用來跨國、跨語言團隊間溝通的工具。

然而，原型制作目前存在明顯的技術壁壘（Technical skill barrier）——設計師通常需要掌握編程語言才能構建原型，這導致迭代循環非常緩慢，嚴重限制了我們驗證創意的數量。

目前市面上已經有一些基于Web的AI工具，能快速生成簡單的2D概念原型。但它們最大的局限在于缺乏引擎整合。

Web對AI很友好，但AI對3D游戲引擎卻舉步維艱。

因為大多數引擎工具都是GUI優先（GUI-first）的。它們擁有對人類極其友好的圖形界面（如藍圖節點、連線），但這些界面并非為AI設計。AI更擅長處理API或對Token友好的代碼結構。

對于人類來說，連接節點能立刻看到結果；但對于AI來說，這些GUI界面基本上就是“一堵像素墻”。

那么，我們該如何打破這堵墻，結合Web的便捷性與引擎的強大表現力？

02

從Web到引擎的跨越

在我們的工作流管線（Pipeline）中，一切從設計師的創意開始。

AI首先會生成一個基于Web的2D原型，團隊可以立即游玩、測試并導入自定義資產。在Web端迭代完善后，系統會將其自動轉換為準備好的3D引擎項目，設計師可以在引擎內繼續進行高級迭代，最終得到一個可用于生產環境的項目起點。

對此，我們測試了三款游戲。

第一款是《8球（8-Ball Pool）》游戲。我們選擇它是因為它有著非常明確的物理規則和幾何規則。雖然它主要是由物理驅動的，并不非常考驗AI寫代碼的能力，但這非常適合用來測試我們的工具，去驗證它在沒有太多人工干預的情況下能否處理好基礎的幾何計算。

第二款游戲是一個俯視角自動射擊游戲（Top-down auto-shooter）。這款游戲里的大部分功能都是由單一的Prompt（提示詞）生成的。為了創建這款游戲，我們要求AI自己做研究，并在一次生成中盡可能多地完成游戲內容。

第一個Prompt大約花了40分鐘來處理。但它一次性完成了最終版本里大約70%的功能。當然，還是存在一些Bug需要解決，比如還有4個功能需要我們去手動調整和開發。

最后一款是一個第一人稱（FPS）Boss戰游戲。在這里，我們的目標是創建多種不同的游戲機制（Gameplay mechanics）。我們添加了不同層級的角色，每個角色都有自己的身份，并且我們還為Boss制作了多種攻擊模式（Patterns）和不同的武器。

現在，讓我們更深入地看看這個工具。它是如何從Web引擎進行原型制作的？

左邊看到的是在Web瀏覽器中運行的2D臺球游戲，里面有光標、物理反饋，這些都能毫不費力地構建出來。而在右邊，你會看到它的3D版本，運行在Unreal（虛幻引擎）中。

為了實現這種跨平臺的飛躍，我們要求AI遵循特定的約束，我們將其總結為“C.A.T.原則”：

它們非常容易記住，只要想一想CAT（貓）。這只貓是真實的，不是AI生成的，它是我的一個同事養的。

• C - Code Reuse（代碼復用）：在Web端和Engine端之間共享盡可能多的代碼，將整合過程中的一致性最大化。

• A -AdapterDesign（適配器設計）：當某些代碼不可避免地需要不同實現方式時，我們抽象出通用接口，讓AI來處理這兩種不同的底層實現。

• T - Token-friendly（Token友好）：這是最重要的一點，意味著要用代碼來驅動引擎，而不是用像素。這讓生成過程對AI來說變得更加容易。

為了徹底打破“像素墻”，我們基于騰訊在GitHub上的一個開源引擎插件，允許在Unreal和Unity引擎中直接運行JavaScript或TypeScript代碼。

你不需要寫圖形化的藍圖代碼，只需用對AI極度友好的TypeScript去調用引擎函數即可。

03

UI、渲染與核心邏輯的映射

基于Token友好的基礎，我們構建了獨立于特定引擎的純邏輯代碼架構。通過“適配器層”，我們將項目拆分為獨立模塊，確保核心邏輯獨立且復用率最大化。

接下來，我們逐一拆解幾個核心模塊：

1. UI（用戶界面）的映射

將Web UI轉化為游戲內UI，主要有兩種方式。第一種是直接在引擎中嵌入網頁（Unreal內置了Web Browser Widget），通過進程間通信同步數據，這種方式能實現像素級的完美還原。

但在實際操作中，對于像“血條”這樣需要跟隨角色動態移動的UI，瀏覽器的性能開銷是不可接受的。

因此，我們采用了第二種方式：讓AI動態解析DOM（文檔對象模型）以抓取樣式和布局，再參照解析結果在UMG（Unreal Motion Graphics）中組建對應的UI控件樹——雖然犧牲了一點設計上的絕對一致性，但換來了極佳的性能。

1. 渲染與空間理解

渲染的核心難題是：如何讓大語言模型（LLM）理解3D空間？這對人類很直觀，對AI卻很難。我們通過三種方式來解碼空間數據：

• 知識（Knowledge）：將游戲規則（如臺球桌的尺寸、球的運動軌跡）作為常識嵌入模型。

• 資產元數據（Asset Metadata）：將所有資產的邊界、包圍盒和碰撞體數據提供給AI。

• 設計元數據（Design Metadata）：設計師在關卡中使用標記工具（Markers）放置特定區域，這些標記帶有變換和層級關系，成為AI理解空間的錨點。

結合這三者，AI就能計算出所有坐標并完成正確的3D放置。

這是一個從2D Web游戲轉換到3D引擎的例子：《8球（8 ball pooling）》。

規則被嚴格定義為牌桌尺寸以及每個球應該去哪里，同時我們有球的尺寸資產。

雖然我們沒有太多的設計元數據可以用，但有了這些數據輸入，AI可以計算出所有的坐標并完成正確的放置。這意味著2D原型現在變成了一個具有高保真物理反饋的3D游戲。

讓我們看另一個例子，這次有設計元數據的參與。這是一個21點（Blackjack）游戲。

在原型制作期間，我們不在乎卡牌或籌碼在桌子上是怎么移動的，我們只需要確保游戲邏輯是對的。

但是當它進入Unreal時，我們需要讓它感覺像真正的發牌。發牌員在哪里？卡牌的發牌區域在哪里？

為此，我們的設計師使用標記工具（Marker tools）來標記特定區域，AI會識別這些標記，提供更加生動的體驗。

在將2D游戲映射到3D空間時，除了空間理解，AI還需要知道如何映射資產、材質。雖然還有很多領域我們沒有涵蓋，但這已經證明了其可行性。

1. 游戲核心邏輯與ECS架構

我們需要給AI一個框架來遵循，我們選擇了ECS（實體組件系統）。ECS是數據驅動、高度解耦和模塊化的，天然契合AI生成代碼的模式。

我們將邏輯分為兩部分：

一部分是與平臺無關的核心邏輯（如游戲規則、AI決策），這部分直接復用；

另一部分是引擎內置的系統（如物理系統）。在Web端，我們使用簡單的2D物理引擎；在Unreal端，我們通過適配器模式接入Unreal的原生3D物理引擎。

系統邏輯不知道底層運行的是什么，因此狀態是完全可移植且易于擴展的。

04

引擎內直接生成

除了“從Web到引擎”的路徑，如果我們跳過Web原型，直接在引擎中構建（Engine-Only）會怎樣？

我們直接使用Agent（智能體）與引擎對話，生成TypeScript（用于替代藍圖可視化編程的腳本語言，對AI Token更友好，可直接調用引擎API驅動游戲邏輯）來驅動游戲，并結合多模態AI（結合視覺與語言理解能力）進行場景和語義生成。

05

自動化分層測試

我們注意到，為了構建完整的游戲，人類依舊需要很重的參與到開發流程中，這其中有很多瑣碎、不必要的情形；我們想進一步提升開發流程的自動化程度，減少這些內容對人的精力分散，更關注游戲設計等核心內容。

基于此，我們希望對游戲系統中可驗證的部分，譬如游戲規則等，構建一套可以自動化迭代的系統。

著名的Ralph Loop告訴我們，不斷迭代以完成需求；但并沒有明確認定什么叫“完成”。我們則引入分層測試作為終止條件，構建了一個自動化的Bug修復循環（Autonomous bug fix loop）。

這里的要點很簡單：測試不是可選項。它是控制因代碼復雜性帶來的Bug泛濫的防線，主要分為三層：

1. 單一系統測試（單元測試）：比如單元測試，一次驗證一個系統的功能。

2. 集成測試：將多個系統連接，運行多幀以驗證較長的游戲序列。

3. 自動游玩測試：模擬真實玩家的行為和輸入，捕捉邊緣情況。

數據表明，消耗更多的Token確實能捕獲并修復更多的Bug，隨著模型能力的增強，這種自動化推理的上限也會不斷提升。

06

總結與未來展望

我們展示了兩條AI制作原型的路徑。

如果你的重點是快速驗證核心循環、方便在瀏覽器中分享，且不需要原生引擎資產，那么基于Web的方法迭代速度極快；如果你需要立即評估特定引擎的特性（如3D物理、高級渲染），直接在引擎中構建（Engine-Only）會是更好的選擇。

展望未來，我們看到了幾個明顯的趨勢：

首先，游戲引擎將逐漸把它們的特性變得對Token更加友好，以便更容易地接入AI管線；

其次，目前的3D空間理解仍依賴大量文本元數據，未來極有可能需要基礎技術突破，引入更強大的多模態能力；

最后，Agent反饋循環與提示詞技術仍有巨大的優化空間。

但無論技術如何發展，人類依然是整個過程的主導者，AI只是幫助我們走得更快的工具。希望大家能從今天的分享中獲得啟發，如果只記住一件事，請記住那只“貓”——C.A.T.原則。

游戲葡萄招聘商務經理，

| |

| |

游戲行業書籍推薦

（星標可第一時間收到推送和完整封面）