The Next Game Engine Won't Have a Manual — Arturo Nunez, Nereu
三句話摘要
下一代遊戲引擎應該摒棄複雜手冊，讓玩家用直觀的遊戲語言描述就能製作遊戲。 下一代遊戲引擎應將焦點從複雜技術細節移轉到創意表達本身，透過 AI 助手和直觀的標籤系統讓任何人都能享受遊戲製作的樂趣。 現有遊戲引擎要求開發者掌握程式設計、建模、渲染、動畫等多個領域，導致高學習曲線與冗長開發週期；Nereu 改用自然語言描述，讓使用者聚焦遊戲設計本身而非技術細節。
重點整理
重點- 1
現有遊戲引擎要求開發者掌握程式設計、建模、渲染、動畫等多個領域，導致高學習曲線與冗長開發週期；Nereu 改用自然語言描述，讓使用者聚焦遊戲設計本身而非技術細節。
- 2
系統採用實體-組件系統架構，每個遊戲物體只需加上描述用途的標籤（如「角色」「可動畫」「雙段跳」），引擎內的系統會自動查詢並執行相應邏輯，避免重複編寫樣板程式碼。
- 3
AI 助手 BB 透過場景上下文、使用者編輯位置和遊戲類型資訊，理解使用者意圖並自動新增或移除標籤；使用者隨時可提問如何實現特定功能，大幅降低認知負荷。
- 4
講者強調遊戲製作應是創意表達與樂趣的過程，而非商業產品開發，目標是讓更多人體驗製作遊戲的喜悅，重拾他 20 年前初入業界時的初心。
實用技巧與重點
乾貨- 工具名稱：Nereu
- AI 助手名稱：BB
- 架構設計：實體-組件系統（Entity Component System, ECS）+ 標籤系統
- 資產規模：約 6000~7000 個資產
- 場景資產數量示例：一個簡單場景約 100 個物件
- 開發技術：JavaScript，運行在瀏覽器
- 視覺模型應用：自動標記和描述資產
- 渲染效能目標：60 幀/秒
- 講者背景：Unity 工作近 10 年、後加入 MongoDB
- 場景優化策略：根據使用者距離渲染不同品質等級的資產
結論
結論“下一代遊戲引擎應將焦點從複雜技術細節移轉到創意表達本身，透過 AI 助手和直觀的標籤系統讓任何人都能享受遊戲製作的樂趣。”
完整解析
詳細遊戲開發長期存在的核心困境是技術門檻極高。製作一款遊戲需要掌握程式設計、3D 建模、渲染、動畫、音樂等多個專業領域。即便組建再龐大的團隊，成員間也難以互補——找到既精通遊戲設計、又擅長渲染、還懂實時攝影機操作的全才開發者幾乎不可能。結果是開發週期冗長，許多小型製作者花費 2~3 年才完成作品，最後卻難以銷售。講者 Arturo 在 Unity 工作近 10 年期間，親眼目睹成千上萬的開發者陷入同樣困境，不斷重複解決相同問題。
Nereu 的核心創新在於改變開發者與引擎的互動方式。傳統引擎要求開發者用引擎的語言思考——導入網格、理解渲染器、配置動畫師、新增剛體與碰撞體，再層層新增遊戲邏輯。這些元件配置在幾乎每款遊戲中都是重複的樣板，卻迫使開發者精通數百個參數。Nereu 反轉了思路：每個遊戲物體本質上都需被渲染和與他物互動，核心區別只在於使用者的意圖。系統讓開發者用遊戲的語言——玩家在教學中聽到的語言——來描述想要的東西。「按 A 鍵跳躍，再按一次做雙段跳」可直接轉化為標籤邏輯。
系統採用實體-組件系統（ECS）架構，遊戲業界已知的設計模式。每個物體是實體，透過標籤描述屬性和行為。引擎內建的系統自動查詢具有特定標籤的所有實體，然後執行相應邏輯——「移動系統」會尋找所有標有「玩家」和「可移動」標籤的物體並使其移動。標籤變成可組合的積木：同一座建築既可是固定障礙物，也能透過加上「可駕駛」標籤變成 Mario Kart 風格載具。
AI 助手 BB 理解使用者意圖並執行修改。當開發者說「加一個機器人」或「讓這角色用 WASD 移動並帶動畫」時，系統從場景上下文提取相關資訊，包括附近資產、遊戲類型、使用者編輯位置，據此生成提示詞。助手隨後新增或移除適當標籤。系統使用視覺模型自動標記 6000 多個資產，因為手動標記在規模上不可行。隨著使用者移動和修改內容，系統動態更新提供給助手的上下文，採用遊戲業界的細節層次（LOD）策略——離使用者近的物體獲得高優先級，遠處物體則被簡化。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
