騰訊遊戲用一隻“貓”，直接AI生成3D遊戲原型？-遊戲-漫步新聞-陪你看看

今年的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修復。

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

遊戲原型製作的瓶頸

大家早上好，我是來自光子工作室羣的資深工程師 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的便捷性與引擎的強大表現力？

從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 - Adapter Design（適配器設計）： 當某些代碼不可避免地需要不同實現方式時，我們抽象出通用接口，讓AI來處理這兩種不同的底層實現。
T - Token-friendly（Token友好）： 這是最重要的一點，意味着要用代碼來驅動引擎，而不是用像素。這讓生成過程對AI來說變得更加容易。

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

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

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

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

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

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

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

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

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

知識（Knowledge）： 將遊戲規則（如檯球桌的尺寸、球的運動軌跡）作爲常識嵌入模型。
資產元數據（Asset Metadata）： 將所有資產的邊界、包圍盒和碰撞體數據提供給AI。
設計元數據（Design Metadata）： 設計師在關卡中使用標記工具（Markers）放置特定區域，這些標記帶有變換和層級關係，成爲AI理解空間的錨點。

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