各位开发者朋友大家好最近我们团队正在推进一个比较有意思的项目——派对游戏《黏土战争》。趁着 B 站 AI 创造公开赛的节点我们做了一期开放式的社区共创把“波兰球”视觉风格和 AI 伙伴玩法结合在一起尝试探索一个强社交属性的派对游戏能不能靠 AI 让 NPC 变得更有“活人感”。这篇文章是我们“猫娘计划社区共创”系列的第三篇技术笔记内容会更偏向工程实操。我会把整个项目的选型思路、派对游戏的核心系统设计、AI 伙伴的接入方式、波兰球风格的角色动画管线以及社区共创模式下的协作流程都拆开来讲。无论你是做 Unity 客户端、Python 后端还是对 AI Agent 在游戏里的落地感兴趣这篇文章都会给你一些能直接用的思路。1. 背景与核心概念1.1 什么是“波兰球风格”的派对游戏先说视觉。波兰球Polandball原本是网络上的一种漫画风格特点是角色是圆形球体表情简练不画手脚或只画简笔的小短手。用色块表现角色性格整体风格轻松、搞怪适合做喜剧化表达。制作门槛低不需要精细骨骼动画非常适合独立团队快速出原型。《黏土战争》想要的效果就是把这种无厘头的球形角色放进一个派对对战场景里玩家控制各自的黏土球体角色利用场景机关、道具和队友配合来分出胜负。它本质上是一款“易上手、难精通、重互动”的多人派对游戏。从开发角度看波兰球风格给客户端美术和动画带来了很多简化空间但同时也给角色识别的“辨识度”提出了要求——因为大家都是球怎么让玩家一眼认出自己控制的角色这是一个需要单独设计的问题。我们后续会在 3.3 节详细说明。1.2 AI 伙伴在游戏中的定位游戏里我们加入了“AI 伙伴”系统我们内部习惯叫它AI Buddy。它不完全等同于传统游戏里的 Bot 或 NPC。传统 Bot 是开发者写死行为树只会巡逻、攻击、回应固定指令而 AI 伙伴的设计目标是能听懂玩家的自然语言指令。能根据当前战局状态做出动态决策。能在情绪表达上与玩家互动比如“队友被击飞时它嘲讽一声”。能承担游戏主持人的部分功能比如播报战况、介绍道具。也就是说我们希望 AI 伙伴不只是一个“陪玩机器人”而是派对里真正的气氛担当。这个定位决定了我们在技术选型上不能只做一套有限状态机还需要引入大语言模型LLM的能力。为了控制风险和成本AI 伙伴不会完全由模型自由发挥而是走“规则框架 AI 决策”的混合架构。关于这一块我会在第三章重点拆解。1.3 为什么做“社区共创”“猫娘计划”是我们团队发起的社区共创项目玩家的角色设计、道具创意、甚至部分任务剧情都可以通过社区提交再由开发团队筛选后合入游戏。这个模式不是简单的“投稿”而是让社区成员参与实际的版本迭代美术社区提供角色立绘和球体配色方案。文案社区提供角色对白、AI 人设上下文。程序社区可以通过 GitHub 提交工具脚本或小玩法模块。这样做一方面降低了团队的内容产能压力另一方面也让玩家对游戏有更强的归属感。对于开发者来说社区共创最大的挑战不是“收集创意”而是如何把零散的社区内容变成可控的游戏资源。所以我们在开发流程里专门设计了资源命名、数据格式校验、自动化导入等环节这部分会在第五章详细展开。2. 环境准备与版本说明在开始搭项目之前先明确我们的开发环境。因为《黏土战争》是多人派对游戏客户端使用 Unity服务端部分使用 Python 搭建轻量级的房间与 AI 网关。下面是当前使用的核心环境清单版本需要根据你的项目实际情况调整本文示例以我们现有的内部环境为准重点演示开发思路。作用技术选型版本说明游戏客户端Unity以 Unity 2021.3 LTS 为基准环境部分新版本 API 可按需调整客户端脚本C#.NET Standard 2.1适配 Unity房间/介入服务PythonPython 3.10Web 框架Flask用于搭建轻量 HTTP 服务方便 AI 网关调试AI 大模型接入OpenAI 兼容接口我们使用兼容接口具体服务商可自行选择版本管理Git Git LFS大文件资源走 LFS代码仓库和美术资产分离协作工具GitHub / Gitee社区共创分支使用 Pull Request 审核动画方案Unity Animator 程序化形变结合球体挤压拉伸实现情绪表达这里要特别说明很多开发者喜欢把 AI 服务直接写进客户端这样原型跑得快但后续很难维护。我们的项目把 AI 调用独立成一个服务客户端只发战局状态和玩家消息AI 网关负责拼 Prompt、调用模型、解析返回结果。这个设计在后面会反复出现。3. 核心语法、配置与原理拆解这一节是整篇文章的核心我会按照项目中的实际模块进行拆解派对房间系统、AI 伙伴服务、角色形象系统、社区共创流程。3.1 派对房间系统的网络架构派对游戏的第一件事是让几个玩家进入同一个房间。很多初学者一开始就写“点对点直连”但从工程角度看派对游戏更建议采用“主机托管 状态广播”模式。我们的做法是房间内的某一台客户端作为“主机”负责游戏逻辑计算服务器只做信令转发与状态同步。这样减少了服务端的计算压力同时也能保证派对游戏的低延迟。房间模块的核心数据结构大致如下// 文件路径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结算 }这段代码定义了房间状态的基础模型。roomCode是玩家进入对局时需要输入的房间码一般 4 到 6 位hostPlayerId用于标识当前房间主机的玩家 IDgamePhase是整个房间的状态流转。需要注意的是玩家加入和退出房间时必须有一个“变更房间状态”的统一入口不要把状态散落在各个脚本里。我们定义了一个RoomManager单例来统一处理这些变更// 文件路径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; } // 这里应该继续调用网络同步方法 // SyncRoomState(currentRoom); } public void SetGamePhase(int newPhase) { currentRoom.gamePhase newPhase; // 通知所有客户端进入对应场景 // EventBus.Publish(new GamePhaseChangedEvent(newPhase)); } }这里可以看到我们采用DontDestroyOnLoad来保证房间管理对象在场景切换时不被销毁。关于同步方法生产环境一般会用 Mirror、Photon 或自研 Socket具体网络库可以根据团队熟悉程度选择但状态数据模型可以保持相似。3.2 AI 伙伴混合架构设计AI 伙伴是《黏土战争》的特色模块。我们不想做成“玩家说一句话模型随便回一句话”的聊天机器人而是希望 AI 伙伴能理解游戏状态并且按规则行动。因此我们设计了三层结构战局状态层客户端把玩家位置、血量、得分、当前道具、最近事件等结构化数据打包发送给 AI 网关。决策上下文层AI 网关收到状态后将其转成一段 LLM 可读的上下文文本同时拼接角色人设。行为输出层LLM 返回的行为指令可能是自然语言将经过一个解析器转换为游戏内可执行的指令比如move_to、use_item、play_emote。下面是一段简化的 Python 网关代码用来演示怎么把游戏状态拼成模型输入# 文件路径ai_gateway/game_prompt.py from typing import Dict, Any # AI 伙伴的人设模板社区文案可以自定义这一段 BUDDY_PERSONA_TEMPLATE 你是一个性格{personality}的派对游戏伙伴名字叫{buddy_name}。 你擅长活跃气氛说话简短幽默。你不能代替玩家操作但可以给出建议。 当战局里有玩家被击飞时你会发出夸张的感叹。 .strip() def build_buddy_prompt(buddy_config: Dict[str, Any], game_snapshot: Dict[str, Any]) - str: 拼接 AI 伙伴的人设与战局快照生成发送给大模型的 Prompt。 persona BUDDY_PERSONA_TEMPLATE.format( personalitybuddy_config.get(personality, 开朗), buddy_namebuddy_config.get(name, 泥泥) ) snapshot_text f 当前对局阶段{game_snapshot.get(phase, 进行中)} 玩家队伍分数 - 红队{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:]])这段代码的核心是把游戏状态文本化。很多团队在接入大模型时会直接把原始 JSON 丢给模型这样虽然也能工作但模型的输出质量没有保障。把战局转换成更具可读性的“文字播报”相当于给模型一个更好的思考底座输出质量会更稳定。模型返回结果后我们需要解析它的输出。为了避免模型输出无法解析的问题我们规定模型输出必须包含一个 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 伙伴是陪伴型角色如果模型偶发故障不能让 AI 彻底沉默更不能让游戏崩溃。所以我们在解析层兜底保证 AI 伙伴至少有话可说。3.3 波兰球风格角色形象系统波兰球角色的制作有两个常见路线一是纯骨骼动画把球体模型蒙皮用骨骼控制变形二是程序化形变通过脚本控制球体缩放、旋转、表情贴图切换。我们选择了第二种因为《黏土战争》里的角色交互动作很多被击飞、被压扁、情绪兴奋膨胀、被冰冻后僵硬。程序化形变的核心思路是用 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 伙伴播放嘲讽动画时不应该让角色模型长时间变形否则玩家会分不清自己的角色状态。所以动画控制方法一般会在 0.2 到 0.5 秒内快速完成。3.4 社区共创的数据结构设计社区共创流程中玩家会提交角色创意、道具设计、AI 人设文案。这些内容如果以“图片 文字描述”的形式直接丢进微信群开发团队很难高效整理。所以我们在仓库里设计了一套标准化的资源提交格式。每一个社区创意都对应一个 JSON 描述文件{ id: community_001, type: character, author: 社区玩家昵称, displayName: 小土豆, color: #C49A6C, personality: 憨厚但嘴硬, catchphrase: 这波稳了, skinTexture: textures/community_001.png, animations: { knockback: 预设枚举值, happy: 预设枚举值 } }这个 JSON 会被一个校验脚本检查通过后进入游戏资源池。这样做的好处是美术资源与数据配置分离社区成员不需要懂 Unity 编辑器也能通过修改 JSON 新增角色。4. 完整实战案例从零搭建一个 AI 伙伴小原型这一节我们完成一个最小可运行的完整案例。目标很简单玩家在 Unity 客户端点击按钮向 Python 网关发送一条消息。Python 网关调用大模型返回一段角色说话内容。Unity 客户端接收内容并显示在文本框里。这个原型虽然简单但覆盖了“客户端发送状态 → 服务端拼接上下文 → 调用大模型 → 解析结果 → 回显”的完整链路。4.1 创建项目结构为了方便对照先列出最小项目的目录结构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 网关需要安装 Flask 和 requests。requirements.txt内容如下flask3.0.0 requests2.31.0安装命令cd ai-gateway pip install -r requirements.txtUnity 客户端不需要额外第三方包使用自带的UnityWebRequest发送 HTTP 请求即可。4.3 编写核心代码先写 Python 网关入口app.py它接收客户端 POST 过来的玩家消息和战局快照返回 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: 调用大模型接口 注意不同服务商的参数格式略有不同请根据实际情况调整。 import requests headers { Authorization: fBearer {MODEL_API_KEY}, Content-Type: application/json } payload { model: MODEL_NAME, messages: [ {role: system, content: 你是游戏《黏土战争》里的 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(): 接收客户端数据返回 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: 系统好像有点卡不过我觉得我们能赢, 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负责把战局信息放入上下文让模型的回复贴合当前游戏局势。模型调用失败时有兜底文案不会让 AI 伙伴完全失声。接下来写 Unity 客户端脚本。AIClient.cs负责发 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(网关地址)] 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) { // 构建战局快照实际项目应从 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 网关cd ai-gateway python app.py如果看到 Flask 启动日志说明网关启动成功。然后在 Unity 编辑器中运行 Main.unity 场景在输入框里输入“我们这局能赢吗”点击发送按钮对应的 Text 组件会显示 AI 伙伴的回复。预期输出类似“红队分数已经领先啦稳住就能赢”由于不同大模型的回复内容有随机性这里没有固定输出。只要不会报错、会在 1 到 3 秒内返回结果整个链路就是通的。4.5 结果说明这个最小原型证明了三个事情客户端可以通过 HTTP 与 AI 网关通信。AI 网关可以把战局快照转换成模型上下文输出的回复与当前对战状态有关联。模型调用失败时系统会回退到安全文案不会让功能白屏。后续接入完整游戏时替换掉预设的GameSnapshotData从RoomManager和PlayerManager读取真实战局即可。5. 常见问题与排查思路AI 游戏开发中最容易踩坑的不是游戏逻辑本身而是“AI 网关与游戏客户端之间的数据对接”。下面整理了我们在开发过程中遇到的高频问题以及对应的排查思路。问题现象常见原因解决思路Unity 发送请求后无响应网关没有启动或防火墙拦截了端口先确认 Python 网关进程是否正常再在浏览器直接访问网关地址测试模型返回内容与游戏无关Prompt 里的战局状态不够详细模型只知道“玩家在说话”检查build_buddy_prompt是否把分数、事件、当前领先队伍等信息传入了模型输出不是标准 JSON不同模型对输出格式的遵循程度不同在 Prompt 中强调“只输出 JSON不要解释”同时在解析层做容错模型调用时间过长玩家体验差大模型推理耗时无法避免在网关做超时控制超过 3 秒则直接返回预设文案多个房间同时请求 AI 网关网关没有做并发控制或限流使用消息队列或限制单个模型服务的并发数社区提交的资源图片命名不规范缺少统一命名校验在资源导入前增加自动检查脚本强制重命名波兰球角色在不同分辨率下变形异常角色的 Transform 缩放与 Canvas 坐标不一致将角色动画和 UI 动画分层处理避免互相影响这里补充一个更具体的排查案例。有同学反馈“AI 伙伴的回复总是和当前战局没有关系比如红队已经落后了AI 还在说我们要赢了。”这个问题的根本原因通常是Prompt 里虽然写了分数但措辞不够明确模型没有把“落后”这个信息当成决策要素。我们的修复方式是在game_prompt.py中增加一个“战局分析”字段显式告诉模型当前哪一队领先、哪一队落后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 双方分数持平然后在build_buddy_prompt里直接使用这个结果snapshot_text f 当前对局阶段{game_snapshot.get(phase, 进行中)} 当前战况{format_advantage(game_snapshot)} 玩家队伍分数 - 红队{game_snapshot.get(red_score, 0)} - 蓝队{game_snapshot.get(blue_score, 0)} 实践证明这种“先让模型读懂局势再让模型发言”的方式比单纯堆分数数字要有效得多。6. 最佳实践与工程建议这一节把项目中的工程经验整理成几条可执行的规范方便大家直接用到自己的项目里。6.1 AI 网关要独立于游戏进程AI 调用应该独立成一个网关服务不要直接嵌入 Unity 主线程。原因有三大模型接口耗时不可控独立进程可以异步处理不阻塞主线程。多人派对游戏中AI 伙伴的请求频率高独立服务方便做限流、缓存和降级。后续更换大模型厂商时只需要改网关不需要重新打包客户端。我们当前使用 Flask 搭建网关生产环境可以替换为 FastAPI 或 Go 服务性能更好。6.2 Prompt 与代码解耦很多团队把 Prompt 直接写在 Python 代码里这种做法在原型阶段没问题但在社区共创场景下会变成灾难——因为文案同学也要参与修改 AI 人设。建议的做法是把 Prompt 模板抽成独立文件或配置项一条角色人设对应一个配置文件。我们目前用 JSON 管理社区角色每条角色数据里包含personality、catchphrase、prompt_template修改文案不需要动代码。6.3 角色状态与 AI 状态分开存储在派对游戏里AI 伙伴是否需要知道自己队伍的战绩当然需要但它的“记忆”不应该长期存在服务端否则会产生大量 token 消耗。我们的做法是AI 伙伴只接收最近 10 秒内的战局事件不保存完整对局历史。这样一来模型输入的 token 数量可控同时 AI 伙伴也能表现出“对当前局势有感知”。如果你的游戏需要 AI 伙伴记住玩家的偏好建议用短期记忆窗口而不是每次请求都传完整战报。6.4 为社区共创内容建立审核机制社区共创虽然开放但游戏内容一旦发布影响范围会很大。我们在资源合入前会做两层检查自动检查JSON 字段是否完整、图片尺寸是否达标、命名是否符合规范。人工检查社区运营和开发同学对白内容、角色形象进行审核。具体到技术层面可以写一个简单的 Python 脚本在 GitHub PR 触发时自动校验所有新增 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里配置好触发条件后社区成员每次提交 PR系统都会自动检查资源格式是否合格大大减少开发团队的人工核对成本。6.5 控制 AI 伙伴的输出频率派对游戏里如果 AI 伙伴每 0.5 秒就说一句话玩家很快就会觉得聒噪。我们给 AI 伙伴设计了一个简单的“冷却机制”被动触发玩家主动AI不受冷却限制。自动播报战局事件时每次触发间隔不得小于 5 秒。AI 只能在对方小队发生重大事件击飞、抢夺道具、得分时才自动开口。这个逻辑可以写在客户端由 AIClient 控制调用频率也可以写在网关里对同一房间的请求做限流。建议后者因为网关可以感知全局请求量方便统一管理。6.6 安全边界与内容合规AI 生成内容在派对游戏里存在不可控性我们要在网关层做内容过滤对模型输入进行敏感词检测涉及违规词汇直接拒绝生成。对模型输出进行关键词过滤发现风险内容时使用预设文案替代。记录每次模型调用的输入与输出日志方便事后回溯。严格来说这不仅是技术问题更是产品上线的基本要求。尤其是面向社区共创的项目AI 伙伴的内容安全需要比普通聊天机器人更严格因为游戏玩家中有很多未成年人。7. 总结与学习路线写到这里《黏土战争》的核心开发思路已经比较完整了。我们主要做的事情可以概括成四句话用波兰球风格降低角色动画门槛让美术产能集中在表情与物理交互上而不是复杂的骨骼绑定。用房间状态模型统一派对游戏网络逻辑主机托管模式在中小规模派对局里性价比很高。用“战局快照 Prompt 模板 输出解析”三层结构接入 AI 伙伴既保留了 LLM 的泛化能力又保证了游戏行为的可控性。用资源校验脚本支撑社区共创让玩家提交的内容能快速进入开发管线。如果你也想做一个类似的派对游戏 AI 伙伴项目可以按照下面的路线逐步推进先做局域网房间系统解决 2 到 4 个玩家进入同一局的问题。再做 AI 伙伴最小原型用文本对话验证“AI 能理解战局”这个假设。然后把 AI 伙伴与游戏事件绑定实现“AI 在队友被击飞时自动说话”这类被动触发功能。最后再考虑社区共创的资源提交与自动化校验流程。在开发过程中优先关注风险点也重要AI 调用延迟、模型输出不可控、网络同步冲突这三件事任何一个爆炸都会直接影响玩家体验。建议每一步都先做最小验证再逐渐扩展功能不要一上来就铺大面。我们的“猫娘计划”社区共创还在持续推进中后续会继续分享 AI 伙伴的人设制作流程、派对游戏关卡设计思路以及社区共创模式的工程化实践。如果你也在做独立游戏、派对游戏或 AI 玩法原型欢迎在评论区交流。如果这篇文章对你有帮助也可以收藏备用后面迭代时会用到不少细节。