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

用AI把“頁游”轉(zhuǎn)換為虛幻大作。

整理/秋秋&電了個教

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

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

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

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

以下為經(jīng)過整理的演講實錄，內(nèi)容有所刪減調(diào)整：

01

游戲原型制作的瓶頸

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

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

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

讓我們先來談?wù)?strong>原型制作（Prototyping）。

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

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

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

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

因為大多數(shù)引擎工具都是GUI優(yōu)先（GUI-first）的。它們擁有對人類極其友好的圖形界面（如藍圖節(jié)點、連線），但這些界面并非為AI設(shè)計。AI更擅長處理API或?qū)oken友好的代碼結(jié)構(gòu)。

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

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

02

從Web到引擎的跨越

在我們的工作流管線（Pipeline）中，一切從設(shè)計師的創(chuàng)意開始。

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

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

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

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

第一個Prompt大約花了40分鐘來處理。但它一次性完成了最終版本里大約70%的功能。當然，還是存在一些Bug需要解決，比如還有4個功能需要我們?nèi)ナ謩诱{(diào)整和開發(fā)。

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

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

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

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

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

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

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

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

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

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

03

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

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

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

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

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

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

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

1. 渲染與空間理解

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

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

• 資產(chǎn)元數(shù)據(jù)（Asset Metadata）：將所有資產(chǎn)的邊界、包圍盒和碰撞體數(shù)據(jù)提供給AI。

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

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

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

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

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

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

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

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

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

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

1. 游戲核心邏輯與ECS架構(gòu)

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

我們將邏輯分為兩部分：

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

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

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

04

引擎內(nèi)直接生成

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

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

05

自動化分層測試

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

基于此，我們希望對游戲系統(tǒng)中可驗證的部分，譬如游戲規(guī)則等，構(gòu)建一套可以自動化迭代的系統(tǒng)。

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

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

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

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

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

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

06

總結(jié)與未來展望

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

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

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

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

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

最后，Agent反饋循環(huán)與提示詞技術(shù)仍有巨大的優(yōu)化空間。

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

游戲葡萄招聘商務(wù)經(jīng)理，

| |

| |

游戲行業(yè)書籍推薦

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