各位開發(fā)者朋友大家好最近我們團隊正在推進一個比較有意思的項目——派對游戲《黏土戰(zhàn)爭》。趁著 B 站 AI 創(chuàng)造公開賽的節(jié)點我們做了一期開放式的社區(qū)共創(chuàng)把“波蘭球”視覺風格和 AI 伙伴玩法結合在一起嘗試探索一個強社交屬性的派對游戲能不能靠 AI 讓 NPC 變得更有“活人感”。這篇文章是我們“貓娘計劃社區(qū)共創(chuàng)”系列的第三篇技術筆記內容會更偏向工程實操。我會把整個項目的選型思路、派對游戲的核心系統(tǒng)設計、AI 伙伴的接入方式、波蘭球風格的角色動畫管線以及社區(qū)共創(chuàng)模式下的協(xié)作流程都拆開來講。無論你是做 Unity 客戶端、Python 后端還是對 AI Agent 在游戲里的落地感興趣這篇文章都會給你一些能直接用的思路。1. 背景與核心概念1.1 什么是“波蘭球風格”的派對游戲先說視覺。波蘭球Polandball原本是網(wǎng)絡上的一種漫畫風格特點是角色是圓形球體表情簡練不畫手腳或只畫簡筆的小短手。用色塊表現(xiàn)角色性格整體風格輕松、搞怪適合做喜劇化表達。制作門檻低不需要精細骨骼動畫非常適合獨立團隊快速出原型。《黏土戰(zhàn)爭》想要的效果就是把這種無厘頭的球形角色放進一個派對對戰(zhàn)場景里玩家控制各自的黏土球體角色利用場景機關、道具和隊友配合來分出勝負。它本質上是一款“易上手、難精通、重互動”的多人派對游戲。從開發(fā)角度看波蘭球風格給客戶端美術和動畫帶來了很多簡化空間但同時也給角色識別的“辨識度”提出了要求——因為大家都是球怎么讓玩家一眼認出自己控制的角色這是一個需要單獨設計的問題。我們后續(xù)會在 3.3 節(jié)詳細說明。1.2 AI 伙伴在游戲中的定位游戲里我們加入了“AI 伙伴”系統(tǒng)我們內部習慣叫它AI Buddy。它不完全等同于傳統(tǒng)游戲里的 Bot 或 NPC。傳統(tǒng) Bot 是開發(fā)者寫死行為樹只會巡邏、攻擊、回應固定指令而 AI 伙伴的設計目標是能聽懂玩家的自然語言指令。能根據(jù)當前戰(zhàn)局狀態(tài)做出動態(tài)決策。能在情緒表達上與玩家互動比如“隊友被擊飛時它嘲諷一聲”。能承擔游戲主持人的部分功能比如播報戰(zhàn)況、介紹道具。也就是說我們希望 AI 伙伴不只是一個“陪玩機器人”而是派對里真正的氣氛擔當。這個定位決定了我們在技術選型上不能只做一套有限狀態(tài)機還需要引入大語言模型LLM的能力。為了控制風險和成本AI 伙伴不會完全由模型自由發(fā)揮而是走“規(guī)則框架 AI 決策”的混合架構。關于這一塊我會在第三章重點拆解。1.3 為什么做“社區(qū)共創(chuàng)”“貓娘計劃”是我們團隊發(fā)起的社區(qū)共創(chuàng)項目玩家的角色設計、道具創(chuàng)意、甚至部分任務劇情都可以通過社區(qū)提交再由開發(fā)團隊篩選后合入游戲。這個模式不是簡單的“投稿”而是讓社區(qū)成員參與實際的版本迭代美術社區(qū)提供角色立繪和球體配色方案。文案社區(qū)提供角色對白、AI 人設上下文。程序社區(qū)可以通過 GitHub 提交工具腳本或小玩法模塊。這樣做一方面降低了團隊的內容產(chǎn)能壓力另一方面也讓玩家對游戲有更強的歸屬感。對于開發(fā)者來說社區(qū)共創(chuàng)最大的挑戰(zhàn)不是“收集創(chuàng)意”而是如何把零散的社區(qū)內容變成可控的游戲資源。所以我們在開發(fā)流程里專門設計了資源命名、數(shù)據(jù)格式校驗、自動化導入等環(huán)節(jié)這部分會在第五章詳細展開。2. 環(huán)境準備與版本說明在開始搭項目之前先明確我們的開發(fā)環(huán)境。因為《黏土戰(zhàn)爭》是多人派對游戲客戶端使用 Unity服務端部分使用 Python 搭建輕量級的房間與 AI 網(wǎng)關。下面是當前使用的核心環(huán)境清單版本需要根據(jù)你的項目實際情況調整本文示例以我們現(xiàn)有的內部環(huán)境為準重點演示開發(fā)思路。作用技術選型版本說明游戲客戶端Unity以 Unity 2021.3 LTS 為基準環(huán)境部分新版本 API 可按需調整客戶端腳本C#.NET Standard 2.1適配 Unity房間/介入服務PythonPython 3.10Web 框架Flask用于搭建輕量 HTTP 服務方便 AI 網(wǎng)關調試AI 大模型接入OpenAI 兼容接口我們使用兼容接口具體服務商可自行選擇版本管理Git Git LFS大文件資源走 LFS代碼倉庫和美術資產(chǎn)分離協(xié)作工具GitHub / Gitee社區(qū)共創(chuàng)分支使用 Pull Request 審核動畫方案Unity Animator 程序化形變結合球體擠壓拉伸實現(xiàn)情緒表達這里要特別說明很多開發(fā)者喜歡把 AI 服務直接寫進客戶端這樣原型跑得快但后續(xù)很難維護。我們的項目把 AI 調用獨立成一個服務客戶端只發(fā)戰(zhàn)局狀態(tài)和玩家消息AI 網(wǎng)關負責拼 Prompt、調用模型、解析返回結果。這個設計在后面會反復出現(xiàn)。3. 核心語法、配置與原理拆解這一節(jié)是整篇文章的核心我會按照項目中的實際模塊進行拆解派對房間系統(tǒng)、AI 伙伴服務、角色形象系統(tǒng)、社區(qū)共創(chuàng)流程。3.1 派對房間系統(tǒng)的網(wǎng)絡架構派對游戲的第一件事是讓幾個玩家進入同一個房間。很多初學者一開始就寫“點對點直連”但從工程角度看派對游戲更建議采用“主機托管 狀態(tài)廣播”模式。我們的做法是房間內的某一臺客戶端作為“主機”負責游戲邏輯計算服務器只做信令轉發(fā)與狀態(tài)同步。這樣減少了服務端的計算壓力同時也能保證派對游戲的低延遲。房間模塊的核心數(shù)據(jù)結構大致如下// 文件路徑Assets/Scripts/Network/RoomState.cs using System; using System.Collections.Generic; [Serializable] public class PlayerInfo { public string playerId; public string displayName; public int characterId; public int teamId; public bool isReady; } [Serializable] public class RoomState { public string roomCode; public int maxPlayers; public int hostPlayerId; public ListPlayerInfo players new ListPlayerInfo(); public int gamePhase; // 0等待, 1準備, 2對局中, 3結算 }這段代碼定義了房間狀態(tài)的基礎模型。roomCode是玩家進入對局時需要輸入的房間碼一般 4 到 6 位hostPlayerId用于標識當前房間主機的玩家 IDgamePhase是整個房間的狀態(tài)流轉。需要注意的是玩家加入和退出房間時必須有一個“變更房間狀態(tài)”的統(tǒng)一入口不要把狀態(tài)散落在各個腳本里。我們定義了一個RoomManager單例來統(tǒng)一處理這些變更// 文件路徑Assets/Scripts/Network/RoomManager.cs using UnityEngine; public class RoomManager : MonoBehaviour { public static RoomManager Instance { get; private set; } private RoomState currentRoom new RoomState(); private void Awake() { if (Instance ! null Instance ! this) { Destroy(gameObject); return; } Instance this; DontDestroyOnLoad(gameObject); } public void UpdatePlayerReady(string playerId, bool ready) { var player currentRoom.players.Find(p p.playerId playerId); if (player ! null) { player.isReady ready; } // 這里應該繼續(xù)調用網(wǎng)絡同步方法 // SyncRoomState(currentRoom); } public void SetGamePhase(int newPhase) { currentRoom.gamePhase newPhase; // 通知所有客戶端進入對應場景 // EventBus.Publish(new GamePhaseChangedEvent(newPhase)); } }這里可以看到我們采用DontDestroyOnLoad來保證房間管理對象在場景切換時不被銷毀。關于同步方法生產(chǎn)環(huán)境一般會用 Mirror、Photon 或自研 Socket具體網(wǎng)絡庫可以根據(jù)團隊熟悉程度選擇但狀態(tài)數(shù)據(jù)模型可以保持相似。3.2 AI 伙伴混合架構設計AI 伙伴是《黏土戰(zhàn)爭》的特色模塊。我們不想做成“玩家說一句話模型隨便回一句話”的聊天機器人而是希望 AI 伙伴能理解游戲狀態(tài)并且按規(guī)則行動。因此我們設計了三層結構戰(zhàn)局狀態(tài)層客戶端把玩家位置、血量、得分、當前道具、最近事件等結構化數(shù)據(jù)打包發(fā)送給 AI 網(wǎng)關。決策上下文層AI 網(wǎng)關收到狀態(tài)后將其轉成一段 LLM 可讀的上下文文本同時拼接角色人設。行為輸出層LLM 返回的行為指令可能是自然語言將經(jīng)過一個解析器轉換為游戲內可執(zhí)行的指令比如move_to、use_item、play_emote。下面是一段簡化的 Python 網(wǎng)關代碼用來演示怎么把游戲狀態(tài)拼成模型輸入# 文件路徑ai_gateway/game_prompt.py from typing import Dict, Any # AI 伙伴的人設模板社區(qū)文案可以自定義這一段 BUDDY_PERSONA_TEMPLATE 你是一個性格{personality}的派對游戲伙伴名字叫{buddy_name}。 你擅長活躍氣氛說話簡短幽默。你不能代替玩家操作但可以給出建議。 當戰(zhàn)局里有玩家被擊飛時你會發(fā)出夸張的感嘆。 .strip() def build_buddy_prompt(buddy_config: Dict[str, Any], game_snapshot: Dict[str, Any]) - str: 拼接 AI 伙伴的人設與戰(zhàn)局快照生成發(fā)送給大模型的 Prompt。 persona BUDDY_PERSONA_TEMPLATE.format( personalitybuddy_config.get(personality, 開朗), buddy_namebuddy_config.get(name, 泥泥) ) snapshot_text f 當前對局階段{game_snapshot.get(phase, 進行中)} 玩家隊伍分數(shù) - 紅隊{game_snapshot.get(red_score, 0)} - 藍隊{game_snapshot.get(blue_score, 0)} 最近事件 {format_events(game_snapshot.get(recent_events, []))} 當前領先{game_snapshot.get(leader_team, 未知)} .strip() return persona \n\n snapshot_text def format_events(events: list) - str: 把事件列表格式化成可讀文本。 if not events: return 暫無特殊事件 return \n.join([f- {event} for event in events[-5:]])這段代碼的核心是把游戲狀態(tài)文本化。很多團隊在接入大模型時會直接把原始 JSON 丟給模型這樣雖然也能工作但模型的輸出質量沒有保障。把戰(zhàn)局轉換成更具可讀性的“文字播報”相當于給模型一個更好的思考底座輸出質量會更穩(wěn)定。模型返回結果后我們需要解析它的輸出。為了避免模型輸出無法解析的問題我們規(guī)定模型輸出必須包含一個 JSON 塊并在代碼里做容錯# 文件路徑ai_gateway/response_parser.py import json import re from typing import Dict, Any def parse_model_response(raw_text: str) - Dict[str, Any]: 從模型輸出中提取 JSON 動作指令。 模型輸出示例 {action: play_emote, emote_id: laugh, comment: 紅隊這下摔得真慘} # 嘗試直接提取 JSON 代碼塊 match re.search(rjson\s*(.*?)\s*, raw_text, re.S) if match: json_str match.group(1) else: # 嘗試匹配第一個 { 到最后 } start raw_text.find({) end raw_text.rfind(}) if start -1 or end -1: return {action: speak, comment: 哈哈這局好激烈} json_str raw_text[start:end1] try: return json.loads(json_str) except json.JSONDecodeError: # 解析失敗時給一個安全回退行為 return {action: speak, comment: 啊我剛才走神了你們打得好激烈}這個安全回退很重要。派對游戲里 AI 伙伴是陪伴型角色如果模型偶發(fā)故障不能讓 AI 徹底沉默更不能讓游戲崩潰。所以我們在解析層兜底保證 AI 伙伴至少有話可說。3.3 波蘭球風格角色形象系統(tǒng)波蘭球角色的制作有兩個常見路線一是純骨骼動畫把球體模型蒙皮用骨骼控制變形二是程序化形變通過腳本控制球體縮放、旋轉、表情貼圖切換。我們選擇了第二種因為《黏土戰(zhàn)爭》里的角色交互動作很多被擊飛、被壓扁、情緒興奮膨脹、被冰凍后僵硬。程序化形變的核心思路是用 Unity 的 Transform 控制球體的 Scale 模擬擠壓和拉伸。使用獨立的 Sprite 層管理表情比如眼睛、嘴巴直接切換貼圖。把每個角色封裝成一個ClayCharacter組件提供公共 API方便 AI 行為調用。下面是一個簡化版角色控制器// 文件路徑Assets/Scripts/Character/ClayCharacter.cs using UnityEngine; public class ClayCharacter : MonoBehaviour { [Header(角色外觀)] public Transform body; public SpriteRenderer eyeRenderer; public SpriteRenderer mouthRenderer; [Header(表情預設)] public Sprite normalEyes; public Sprite happyEyes; public Sprite dizzyEyes; private Vector3 originalScale; private void Awake() { originalScale body.localScale; } /// summary /// 播放被擊飛動畫拉長身體換成眩暈表情 /// /summary public void PlayKnockback() { StopAllCoroutines(); StartCoroutine(KnockbackAnim()); } private System.Collections.IEnumerator KnockbackAnim() { // 先拉長 body.localScale new Vector3(originalScale.x * 0.7f, originalScale.y * 1.5f, originalScale.z); eyeRenderer.sprite dizzyEyes; yield return new WaitForSeconds(0.2f); // 恢復 body.localScale originalScale; eyeRenderer.sprite normalEyes; } /// summary /// AI 伙伴調用此方法播放開心情緒 /// /summary public void PlayHappy() { StopAllCoroutines(); StartCoroutine(HappyAnim()); } private System.Collections.IEnumerator HappyAnim() { body.localScale originalScale * 1.2f; eyeRenderer.sprite happyEyes; yield return new WaitForSeconds(0.3f); body.localScale originalScale; eyeRenderer.sprite normalEyes; } }這段代碼演示了“程序化形變動畫”的基本寫法。需要注意的是在派對游戲里動畫不能搶走玩家操作的反饋。比如 AI 伙伴播放嘲諷動畫時不應該讓角色模型長時間變形否則玩家會分不清自己的角色狀態(tài)。所以動畫控制方法一般會在 0.2 到 0.5 秒內快速完成。3.4 社區(qū)共創(chuàng)的數(shù)據(jù)結構設計社區(qū)共創(chuàng)流程中玩家會提交角色創(chuàng)意、道具設計、AI 人設文案。這些內容如果以“圖片 文字描述”的形式直接丟進微信群開發(fā)團隊很難高效整理。所以我們在倉庫里設計了一套標準化的資源提交格式。每一個社區(qū)創(chuàng)意都對應一個 JSON 描述文件{ id: community_001, type: character, author: 社區(qū)玩家昵稱, displayName: 小土豆, color: #C49A6C, personality: 憨厚但嘴硬, catchphrase: 這波穩(wěn)了, skinTexture: textures/community_001.png, animations: { knockback: 預設枚舉值, happy: 預設枚舉值 } }這個 JSON 會被一個校驗腳本檢查通過后進入游戲資源池。這樣做的好處是美術資源與數(shù)據(jù)配置分離社區(qū)成員不需要懂 Unity 編輯器也能通過修改 JSON 新增角色。4. 完整實戰(zhàn)案例從零搭建一個 AI 伙伴小原型這一節(jié)我們完成一個最小可運行的完整案例。目標很簡單玩家在 Unity 客戶端點擊按鈕向 Python 網(wǎng)關發(fā)送一條消息。Python 網(wǎng)關調用大模型返回一段角色說話內容。Unity 客戶端接收內容并顯示在文本框里。這個原型雖然簡單但覆蓋了“客戶端發(fā)送狀態(tài) → 服務端拼接上下文 → 調用大模型 → 解析結果 → 回顯”的完整鏈路。4.1 創(chuàng)建項目結構為了方便對照先列出最小項目的目錄結構ClayWarAI_Demo/ ├── unity-client/ │ ├── Assets/ │ │ ├── Scripts/ │ │ │ ├── AIClient.cs │ │ │ └── UIBuddyPanel.cs │ │ └── Scenes/ │ │ └── Main.unity │ └── ProjectSettings/ └── ai-gateway/ ├── app.py ├── game_prompt.py ├── response_parser.py └── requirements.txtUnity 工程部分我們重點看腳本場景搭建部分大家可以自行完成只需要一個 InputField、一個 Button、一個 Text 用來顯示 AI 回復。4.2 添加依賴或配置Python 網(wǎng)關需要安裝 Flask 和 requests。requirements.txt內容如下flask3.0.0 requests2.31.0安裝命令cd ai-gateway pip install -r requirements.txtUnity 客戶端不需要額外第三方包使用自帶的UnityWebRequest發(fā)送 HTTP 請求即可。4.3 編寫核心代碼先寫 Python 網(wǎng)關入口app.py它接收客戶端 POST 過來的玩家消息和戰(zhàn)局快照返回 AI 回復。# 文件路徑ai-gateway/app.py import os from flask import Flask, request, jsonify from game_prompt import build_buddy_prompt from response_parser import parse_model_response app Flask(__name__) # 這里填入你的大模型服務配置 MODEL_API_URL os.getenv(MODEL_API_URL, https://your-llm-service.example/v1/chat/completions) MODEL_API_KEY os.getenv(MODEL_API_KEY, your-api-key) MODEL_NAME os.getenv(MODEL_NAME, your-model-name) # 默認的 AI 伙伴配置 BUDDY_CONFIG { name: 泥泥, personality: 樂觀、愛吐槽 } def call_llm(prompt: str) - str: 調用大模型接口 注意不同服務商的參數(shù)格式略有不同請根據(jù)實際情況調整。 import requests headers { Authorization: fBearer {MODEL_API_KEY}, Content-Type: application/json } payload { model: MODEL_NAME, messages: [ {role: system, content: 你是游戲《黏土戰(zhàn)爭》里的 AI 伙伴。}, {role: user, content: prompt} ], temperature: 0.8 } resp requests.post(MODEL_API_URL, headersheaders, jsonpayload, timeout15) resp.raise_for_status() data resp.json() return data[choices][0][message][content] app.route(/api/ai_buddy, methods[POST]) def ai_buddy(): 接收客戶端數(shù)據(jù)返回 AI 伙伴的回應。 請求體示例 { playerMessage: 我們這局能贏嗎, gameSnapshot: { phase: 進行中, red_score: 12, blue_score: 9, recent_events: [紅隊玩家擊飛藍隊玩家, 藍隊獲得加速道具] } } data request.get_json(forceTrue) player_message data.get(playerMessage, ) game_snapshot data.get(gameSnapshot, {}) # 1. 拼接 Prompt prompt build_buddy_prompt(BUDDY_CONFIG, game_snapshot) prompt f\n玩家說{player_message}\n請用游戲伙伴的身份回復一句話不要超過20字。 # 2. 調用模型 try: raw_reply call_llm(prompt) except Exception as e: # 模型調用失敗時兜底回復 return jsonify({ reply: 系統(tǒng)好像有點卡不過我覺得我們能贏, raw: str(e) }) # 3. 解析模型輸出 parsed parse_model_response(raw_reply) reply parsed.get(comment, raw_reply) return jsonify({ reply: reply, action: parsed.get(action, speak) }) if __name__ __main__: app.run(host0.0.0.0, port5000, debugTrue)這段代碼的關鍵點有兩個build_buddy_prompt負責把戰(zhàn)局信息放入上下文讓模型的回復貼合當前游戲局勢。模型調用失敗時有兜底文案不會讓 AI 伙伴完全失聲。接下來寫 Unity 客戶端腳本。AIClient.cs負責發(fā) HTTP 請求// 文件路徑unity-client/Assets/Scripts/AIClient.cs using System; using System.Collections; using System.Text; using UnityEngine; using UnityEngine.Networking; [Serializable] public class BuddyRequestData { public string playerMessage; public GameSnapshotData gameSnapshot; } [Serializable] public class GameSnapshotData { public string phase; public int red_score; public int blue_score; public string[] recent_events; } [Serializable] public class BuddyResponseData { public string reply; public string action; } public class AIClient : MonoBehaviour { [Header(網(wǎng)關地址)] public string gatewayUrl http://localhost:5000/api/ai_buddy; public void SendPlayerMessage(string message, Actionstring onReply) { StartCoroutine(SendRequest(message, onReply)); } private IEnumerator SendRequest(string message, Actionstring onReply) { // 構建戰(zhàn)局快照實際項目應從 RoomManager 讀取 var snapshot new GameSnapshotData { phase 進行中, red_score 12, blue_score 9, recent_events new string[] { 紅隊玩家擊飛藍隊玩家, 藍隊獲得加速道具 } }; var requestData new BuddyRequestData { playerMessage message, gameSnapshot snapshot }; string jsonData JsonUtility.ToJson(requestData); using (UnityWebRequest request new UnityWebRequest(gatewayUrl, POST)) { byte[] bodyRaw Encoding.UTF8.GetBytes(jsonData); request.uploadHandler new UploadHandlerRaw(bodyRaw); request.downloadHandler new DownloadHandlerBuffer(); request.SetRequestHeader(Content-Type, application/json); yield return request.SendWebRequest(); if (request.result UnityWebRequest.Result.Success) { var response JsonUtility.FromJsonBuddyResponseData(request.downloadHandler.text); onReply?.Invoke(response.reply); } else { Debug.LogError(AI Buddy 請求失敗: request.error); onReply?.Invoke(AI 伙伴暫時掉線了…); } } } }然后寫 UI 面板腳本UIBuddyPanel.cs把輸入框、按鈕、文本連接起來// 文件路徑unity-client/Assets/Scripts/UIBuddyPanel.cs using UnityEngine; using UnityEngine.UI; public class UIBuddyPanel : MonoBehaviour { public InputField messageInput; public Button sendButton; public Text replyText; public AIClient aiClient; private void Start() { sendButton.onClick.AddListener(OnSendButtonClicked); } private void OnSendButtonClicked() { string message messageInput.text; if (string.IsNullOrEmpty(message)) { return; } sendButton.interactable false; replyText.text AI 伙伴思考中…; aiClient.SendPlayerMessage(message, (reply) { replyText.text reply; sendButton.interactable true; }); } }4.4 運行與驗證先在本地啟動 Python 網(wǎng)關cd ai-gateway python app.py如果看到 Flask 啟動日志說明網(wǎng)關啟動成功。然后在 Unity 編輯器中運行 Main.unity 場景在輸入框里輸入“我們這局能贏嗎”點擊發(fā)送按鈕對應的 Text 組件會顯示 AI 伙伴的回復。預期輸出類似“紅隊分數(shù)已經(jīng)領先啦穩(wěn)住就能贏”由于不同大模型的回復內容有隨機性這里沒有固定輸出。只要不會報錯、會在 1 到 3 秒內返回結果整個鏈路就是通的。4.5 結果說明這個最小原型證明了三個事情客戶端可以通過 HTTP 與 AI 網(wǎng)關通信。AI 網(wǎng)關可以把戰(zhàn)局快照轉換成模型上下文輸出的回復與當前對戰(zhàn)狀態(tài)有關聯(lián)。模型調用失敗時系統(tǒng)會回退到安全文案不會讓功能白屏。后續(xù)接入完整游戲時替換掉預設的GameSnapshotData從RoomManager和PlayerManager讀取真實戰(zhàn)局即可。5. 常見問題與排查思路AI 游戲開發(fā)中最容易踩坑的不是游戲邏輯本身而是“AI 網(wǎng)關與游戲客戶端之間的數(shù)據(jù)對接”。下面整理了我們在開發(fā)過程中遇到的高頻問題以及對應的排查思路。問題現(xiàn)象常見原因解決思路Unity 發(fā)送請求后無響應網(wǎng)關沒有啟動或防火墻攔截了端口先確認 Python 網(wǎng)關進程是否正常再在瀏覽器直接訪問網(wǎng)關地址測試模型返回內容與游戲無關Prompt 里的戰(zhàn)局狀態(tài)不夠詳細模型只知道“玩家在說話”檢查build_buddy_prompt是否把分數(shù)、事件、當前領先隊伍等信息傳入了模型輸出不是標準 JSON不同模型對輸出格式的遵循程度不同在 Prompt 中強調“只輸出 JSON不要解釋”同時在解析層做容錯模型調用時間過長玩家體驗差大模型推理耗時無法避免在網(wǎng)關做超時控制超過 3 秒則直接返回預設文案多個房間同時請求 AI 網(wǎng)關網(wǎng)關沒有做并發(fā)控制或限流使用消息隊列或限制單個模型服務的并發(fā)數(shù)社區(qū)提交的資源圖片命名不規(guī)范缺少統(tǒng)一命名校驗在資源導入前增加自動檢查腳本強制重命名波蘭球角色在不同分辨率下變形異常角色的 Transform 縮放與 Canvas 坐標不一致將角色動畫和 UI 動畫分層處理避免互相影響這里補充一個更具體的排查案例。有同學反饋“AI 伙伴的回復總是和當前戰(zhàn)局沒有關系比如紅隊已經(jīng)落后了AI 還在說我們要贏了。”這個問題的根本原因通常是Prompt 里雖然寫了分數(shù)但措辭不夠明確模型沒有把“落后”這個信息當成決策要素。我們的修復方式是在game_prompt.py中增加一個“戰(zhàn)局分析”字段顯式告訴模型當前哪一隊領先、哪一隊落后def format_advantage(game_snapshot: Dict[str, Any]) - str: red game_snapshot.get(red_score, 0) blue game_snapshot.get(blue_score, 0) if red blue: return 紅隊領先 elif blue red: return 藍隊領先 else: return 雙方分數(shù)持平然后在build_buddy_prompt里直接使用這個結果snapshot_text f 當前對局階段{game_snapshot.get(phase, 進行中)} 當前戰(zhàn)況{format_advantage(game_snapshot)} 玩家隊伍分數(shù) - 紅隊{game_snapshot.get(red_score, 0)} - 藍隊{game_snapshot.get(blue_score, 0)} 實踐證明這種“先讓模型讀懂局勢再讓模型發(fā)言”的方式比單純堆分數(shù)數(shù)字要有效得多。6. 最佳實踐與工程建議這一節(jié)把項目中的工程經(jīng)驗整理成幾條可執(zhí)行的規(guī)范方便大家直接用到自己的項目里。6.1 AI 網(wǎng)關要獨立于游戲進程AI 調用應該獨立成一個網(wǎng)關服務不要直接嵌入 Unity 主線程。原因有三大模型接口耗時不可控獨立進程可以異步處理不阻塞主線程。多人派對游戲中AI 伙伴的請求頻率高獨立服務方便做限流、緩存和降級。后續(xù)更換大模型廠商時只需要改網(wǎng)關不需要重新打包客戶端。我們當前使用 Flask 搭建網(wǎng)關生產(chǎn)環(huán)境可以替換為 FastAPI 或 Go 服務性能更好。6.2 Prompt 與代碼解耦很多團隊把 Prompt 直接寫在 Python 代碼里這種做法在原型階段沒問題但在社區(qū)共創(chuàng)場景下會變成災難——因為文案同學也要參與修改 AI 人設。建議的做法是把 Prompt 模板抽成獨立文件或配置項一條角色人設對應一個配置文件。我們目前用 JSON 管理社區(qū)角色每條角色數(shù)據(jù)里包含personality、catchphrase、prompt_template修改文案不需要動代碼。6.3 角色狀態(tài)與 AI 狀態(tài)分開存儲在派對游戲里AI 伙伴是否需要知道自己隊伍的戰(zhàn)績當然需要但它的“記憶”不應該長期存在服務端否則會產(chǎn)生大量 token 消耗。我們的做法是AI 伙伴只接收最近 10 秒內的戰(zhàn)局事件不保存完整對局歷史。這樣一來模型輸入的 token 數(shù)量可控同時 AI 伙伴也能表現(xiàn)出“對當前局勢有感知”。如果你的游戲需要 AI 伙伴記住玩家的偏好建議用短期記憶窗口而不是每次請求都傳完整戰(zhàn)報。6.4 為社區(qū)共創(chuàng)內容建立審核機制社區(qū)共創(chuàng)雖然開放但游戲內容一旦發(fā)布影響范圍會很大。我們在資源合入前會做兩層檢查自動檢查JSON 字段是否完整、圖片尺寸是否達標、命名是否符合規(guī)范。人工檢查社區(qū)運營和開發(fā)同學對白內容、角色形象進行審核。具體到技術層面可以寫一個簡單的 Python 腳本在 GitHub PR 觸發(fā)時自動校驗所有新增 JSON# 文件路徑tools/validate_community_assets.py import json import sys from pathlib import Path REQUIRED_FIELDS [id, type, displayName, color, personality, catchphrase] def validate_file(file_path: Path) - bool: try: data json.loads(file_path.read_text(encodingutf-8)) except json.JSONDecodeError as e: print(fJSON 解析失敗: {file_path} - {e}) return False missing [field for field in REQUIRED_FIELDS if field not in data] if missing: print(f缺少字段: {file_path} - {missing}) return False if not data[displayName].strip(): print(fdisplayName 不能為空: {file_path}) return False return True def main(): if len(sys.argv) 2: print(用法: python validate_community_assets.py 文件夾路徑) return target_dir Path(sys.argv[1]) success True for json_file in target_dir.rglob(*.json): if not validate_file(json_file): success False if not success: sys.exit(1) print(所有資源文件校驗通過) if __name__ __main__: main()在.github/workflows里配置好觸發(fā)條件后社區(qū)成員每次提交 PR系統(tǒng)都會自動檢查資源格式是否合格大大減少開發(fā)團隊的人工核對成本。6.5 控制 AI 伙伴的輸出頻率派對游戲里如果 AI 伙伴每 0.5 秒就說一句話玩家很快就會覺得聒噪。我們給 AI 伙伴設計了一個簡單的“冷卻機制”被動觸發(fā)玩家主動AI不受冷卻限制。自動播報戰(zhàn)局事件時每次觸發(fā)間隔不得小于 5 秒。AI 只能在對方小隊發(fā)生重大事件擊飛、搶奪道具、得分時才自動開口。這個邏輯可以寫在客戶端由 AIClient 控制調用頻率也可以寫在網(wǎng)關里對同一房間的請求做限流。建議后者因為網(wǎng)關可以感知全局請求量方便統(tǒng)一管理。6.6 安全邊界與內容合規(guī)AI 生成內容在派對游戲里存在不可控性我們要在網(wǎng)關層做內容過濾對模型輸入進行敏感詞檢測涉及違規(guī)詞匯直接拒絕生成。對模型輸出進行關鍵詞過濾發(fā)現(xiàn)風險內容時使用預設文案替代。記錄每次模型調用的輸入與輸出日志方便事后回溯。嚴格來說這不僅是技術問題更是產(chǎn)品上線的基本要求。尤其是面向社區(qū)共創(chuàng)的項目AI 伙伴的內容安全需要比普通聊天機器人更嚴格因為游戲玩家中有很多未成年人。7. 總結與學習路線寫到這里《黏土戰(zhàn)爭》的核心開發(fā)思路已經(jīng)比較完整了。我們主要做的事情可以概括成四句話用波蘭球風格降低角色動畫門檻讓美術產(chǎn)能集中在表情與物理交互上而不是復雜的骨骼綁定。用房間狀態(tài)模型統(tǒng)一派對游戲網(wǎng)絡邏輯主機托管模式在中小規(guī)模派對局里性價比很高。用“戰(zhàn)局快照 Prompt 模板 輸出解析”三層結構接入 AI 伙伴既保留了 LLM 的泛化能力又保證了游戲行為的可控性。用資源校驗腳本支撐社區(qū)共創(chuàng)讓玩家提交的內容能快速進入開發(fā)管線。如果你也想做一個類似的派對游戲 AI 伙伴項目可以按照下面的路線逐步推進先做局域網(wǎng)房間系統(tǒng)解決 2 到 4 個玩家進入同一局的問題。再做 AI 伙伴最小原型用文本對話驗證“AI 能理解戰(zhàn)局”這個假設。然后把 AI 伙伴與游戲事件綁定實現(xiàn)“AI 在隊友被擊飛時自動說話”這類被動觸發(fā)功能。最后再考慮社區(qū)共創(chuàng)的資源提交與自動化校驗流程。在開發(fā)過程中優(yōu)先關注風險點也重要AI 調用延遲、模型輸出不可控、網(wǎng)絡同步?jīng)_突這三件事任何一個爆炸都會直接影響玩家體驗。建議每一步都先做最小驗證再逐漸擴展功能不要一上來就鋪大面。我們的“貓娘計劃”社區(qū)共創(chuàng)還在持續(xù)推進中后續(xù)會繼續(xù)分享 AI 伙伴的人設制作流程、派對游戲關卡設計思路以及社區(qū)共創(chuàng)模式的工程化實踐。如果你也在做獨立游戲、派對游戲或 AI 玩法原型歡迎在評論區(qū)交流。如果這篇文章對你有幫助也可以收藏備用后面迭代時會用到不少細節(jié)。