在2025年这个时间点上“AI游戏”已经不是一个蹭热度的概念而是真正能落地、能玩起来的东西。我这一篇不讲虚的直接把我从零开始、用开源引擎配合大模型接口做出一款可运行AI游戏的全过程拆开从选型、环境配置、核心代码、踩坑链路到体验优化全部过一遍。文章会很长但每一步都可以照着抄适合有基础编程概念、但没碰过AI游戏开发的人也适合已经在做传统游戏、想把手头项目接入AI能力的开发者。1. 先想清楚AI游戏到底玩的是什么1.1 我理解的“AI原生游戏”大家常说的AI游戏大概可以分两类。一类是把AI当作辅助工具比如用AI生成美术素材、写剧情文本、做程序代码游戏本身还是传统的玩法驱动。另一类是AI作为游戏的核心运行时机制NPC不是读预设脚本而是每次都用大模型的推理能力现场生成对话和行动剧情不是写死的分支树而是根据玩家输入实时演化甚至游戏里的系统规则都会由AI动态解释。我做的是后者因为后者才配叫“AI游戏开发”。一个角色能不能记住你半小时前的决定一个剧情能不能在你连续挑衅NPC之后真的改变世界走向这些靠传统脚本要写死几百个分支而用大模型只需要给它一个“人设”和“记忆池”剩下交给你和它之间的对话。这里要泼一盆冷水AI游戏开发的门槛不在于“调用AI接口”而在于“把AI输出变成稳定的游戏体验”。大模型返回的是文本但游戏需要的是状态变更、数值增减、场景切换、任务更新。你要设计一套机制把这些文本翻译成游戏世界里的“真实事件”同时还要处理它偶尔跑偏、回复超时、输出格式不合法这些破事。1.2 这条开发路线天然适配这三类人独立开发者一个人就是一支团队AI能帮你把文案、配音、部分美术、甚至玩法策划都包了你专注系统架构和游戏性。传统游戏开发者转型Unity、Godot、Cocos的功力都还在只是多学一个“跟大模型对话”的模块边际成本很低但产品想象力空间一下子打开了。想拿AI游戏做作品集的新人市面上大量AI玩法Demo都是套壳聊天你如果能做出“AI行为真正影响游戏世界状态”的成品在面试和社区里的辨识度完全不一样。如果你连编程基础都没有那这篇文章里的代码会让你吃力建议你先补一遍任意一门编程语言的语法再回来。2. 引擎选型Godot、Unity、Cocos我最后选了谁2.1 “免费商用”这一条先帮我排掉了一半选项做AI游戏大概率要走长线迭代引擎的授权模式直接决定你以后会不会被“收割”。所以我在对比之前先设了两条硬门槛必须免费商用必须能导出到主流平台。拿这三个引擎分别过一遍Unity个人版在收入低于10万美元时可以免费商用但超过之后要订阅Pro而且最近几年它的收费政策改来改去社区怨气不小。它的优点是生态成熟AI相关插件、资产商店资源最多缺点是引擎本体越来越重打开编辑器做小项目有种杀鸡用牛刀的感觉。Cocos国内中小团队和微信小游戏的首选免费商用政策清晰对Web和小程序的支持是三个里最顺的Creator编辑器上手也不难。但如果你要做的是3D PC游戏或者要上SteamCocos的社区和生态就要弱一些了。Godot完全开源MIT协议意思是你拿它做的游戏随便卖一分钱授权费都不用交。编辑器轻量GDScript语法像Python对从零学引擎的人来说非常友好。它的短板是3D能力不如Unreal商业化案例不如Unity多但这两年在社区推动下进步非常快。2.2 我实测下来的对比数据我自己用同一个“AI对话场景切换”的Demo在这三个引擎里各跑了一遍感受如下对比维度Godot 4.xUnity 2022Cocos Creator 3.x安装包体量约70MB启动快动辄几个GB中等Web构建小学习曲线低脚本像Python中高C# 复杂面板低TS/JS熟悉即可导出目标PC/移动/Web全平台PC/移动/Web/主机Web/微信小游戏最强HTTP请求支持内置HTTPClient需用UnityWebRequest内置XMLHttpRequest封装AI文本处理字符串/GDScript字典操作顺手C#处理Json麻烦但可控前端思维处理Json很舒服开源与免费完全开源协议最宽松有收入门槛免费商用政策清晰2.3 我的选择Godot以及为什么我最终选的Godot核心原因就一句话AI游戏的代码量集中在“逻辑和状态管理”上而GDScript写这类代码的流畅度是三个引擎里最高的。举个例子AI返回的JSON里有一项action: attack_guard游戏要根据这个字符串去改变NPC的对玩家的好感度、卫兵的警戒值、场景BGM。在GDScript里我可以直接写var action: String ai_response.action match action: attack_guard: player_state.add_reputation(-10) guard_state.alert_level hostile bgm_player.switch_track(battle) bribe_guard: player_state.add_gold(-50) guard_state.alert_level neutral bgm_player.switch_track(ambient)这段逻辑在Unity里当然也能写但要写一个匹配规则类、序列化类还得处理MonoBehaviour生命周期。Godot的节点体系和_process回调让我能更快把“AI返回值”和“游戏世界状态”粘在一起这就是选型上最大的效率优势。另一个让我确定的点是Godot 4.x的Web导出越来越靠谱。AI游戏天然适合放网页上给别人即点即玩Godot导出HTML5的兼容性已经够用给我省掉了大量平台适配工作。3. AI能力接入不要一上来就追Agent框架3.1 三种常见的接入方式我的一句话评价现在打开知乎B站满屏都是“AI Agent”“多智能体协作”的概念。但做游戏不是做企业级应用我不建议新人一上来就上框架先搞清楚三种接入方式的成本接入方式实现难度适用场景我的评价直接HTTP调用大模型API低原型验证、小游戏首选所有复杂功能都从这里长出来用现成Agent框架如LangChain中需要工具调用、多步推理先别碰框架会替你抽象掉很多细节但出了问题你根本不知道在哪层自建Agent壳子高游戏需要长期记忆、复杂规划等基础版跑通之后再用属于进阶玩法3.2 我在Godot里封装的大模型请求模块我的项目并没有在引擎里塞任何Agent框架而是自己写了一个AIClient单例负责三件事组装请求、发起HTTP、解析流式输出。Godot的HTTP请求是异步的不能和主线程的游戏循环同步等待。所以我用HTTPRequest节点发请求然后用信号把结果传回来# AIClient.gd extends Node signal ai_response_ready(response_text: String) signal ai_response_error(error_msg: String) var api_url : https://api.your-llm-provider.com/v1/chat/completions var api_key : your-api-key-here var model_name : your-model-name var temperature : 0.7 var max_tokens : 1024 var http_request: HTTPRequest func _ready(): http_request HTTPRequest.new() add_child(http_request) http_request.request_completed.connect(_on_request_completed) func send_prompt(system_prompt: String, user_prompt: String, history: Array []): var messages : [] messages.append({role: system, content: system_prompt}) for msg in history: messages.append(msg) messages.append({role: user, content: user_prompt}) var body : JSON.stringify({ model: model_name, messages: messages, temperature: temperature, max_tokens: max_tokens, stream: false # 第一版我关掉流式先保证稳定 }) var headers : [ Content-Type: application/json, Authorization: Bearer api_key ] var err : http_request.request(api_url, headers, HTTPClient.METHOD_POST, body) if err ! OK: ai_response_error.emit(HTTP request failed: error_string(err))这里有几个我调试了很久才明白的细节别把api_key硬编码在导出的游戏包里。如果你发布的是Web版任何人的浏览器开发者工具都能把你的密钥抓出来。我的做法是游戏里调用一个自己的后端转发接口由后端保存密钥游戏只发业务内容后端再拼装大模型请求。这部分代码不难但属于“上线前必须做”的安全动作。temperature参数很关键。做游戏剧情时我开到0.8这样角色回复比较有创造性但解析“玩家意图”的时候我会降到0.2避免AI发挥过头产生不可控的判定。第一版别开stream: true。流式响应体验更好但会显著增加游戏内处理的复杂度后面我会专门讲这个坑。3.3 游戏内的AI抽象层对外只暴露一个函数有了AIClient之后我又包了一层GameAI.gd让游戏逻辑根本不用管“HTTP”“JSON”“大模型”这些事。所有玩法代码只调它暴露的方法比如# GameAI.gd extends Node enum AI_TASK { TALK, ACT, NARRATE } func request_npc_reply(npc_name: String, npc_persona: String, player_input: String) - void: var sys_prompt 你是游戏里的角色%s性格设定%s。请用中文以角色口吻回复玩家。 % [npc_name, npc_persona] _client.send_prompt(sys_prompt, player_input, _get_recent_memory()) func request_player_action(player_input: String) - void: var sys_prompt 你是一个游戏判定的AI。请根据玩家输入推断玩家想做什么。 只输出JSON格式如下 { action: 移动|攻击|交谈|拾取|使用|等待, target: 目标对象, intent: 一句话说明你想做什么 } 不允许输出JSON之外的内容。 _client.send_prompt(sys_prompt, player_input)我把AI请求分成两种任务对话型任务让AI自由发挥判定型任务让AI必须输出结构化JSON。这两种模式用同一个AIClient但用不同的system prompt和temperature这个设计帮我避免了后面90%的解析问题。4. 从空项目到可玩原型我的一步步搭建过程4.1 新建Godot项目配置好目录我用的是Godot 4.2创建项目时选了“Blank”模板。目录结构提前规划好res:// ├── scenes/ # 场景文件 │ ├── main.tscn │ └── npc.tscn ├── scripts/ # 脚本 │ ├── AIClient.gd │ ├── GameAI.gd │ └── npc.gd ├── data/ # 角色人设、剧情设定 │ └── npc_personas.json └── ui/ # 界面相关 └── chat_panel.tscn这个规划很普通但有个好处AI相关逻辑、角色数据、界面三层分离。后期调参、换模型、换人物设定都不用动到玩法核心。4.2 把“角色”设计成数据驱动做AI游戏最大的思维转变是角色不是图片、不是动画状态机而是一段可被大模型理解的人设文本 一组游戏世界状态值。我的npc.gd大概长这样# npc.gd extends CharacterBody2D export var npc_id: String export var display_name: String 神秘老者 export var persona_prompt: String 你是一位隐居深山的睿智老者说话慢条斯理喜欢引用山野典故。你对玩家有着隐秘的好奇心但不会轻易信任陌生人。 export var trust_level: int 40 export var memory: Array []persona_prompt就是AI的人设trust_level是影响对话走向的数值memory是“这个角色记得的事”。每次AI请求时我都会把相关状态拼进system prompt里你是一位隐居深山的睿智老者……人设 当前你对玩家的信任度是40满分100。 你记得的最近几件事 1. 玩家在村口帮过你找回丢失的药草。 2. 玩家昨夜在酒馆打听过你的下落。这样AI的回复就不是瞎聊天而是真正嵌在游戏状态里的。4.3 核心玩法闭环输入 → 判定 → 执行 → 反馈我的Demo玩法很简单概括成一句话玩家在对话框里输入任意文字AI判断玩家想做什么游戏执行对应的状态变更然后AI根据新状态继续扮演NPC回应。这个闭环的代码逻辑是这样的func _on_send_button_pressed(): var player_input input_field.text input_field.clear() _game_ai.request_player_action(player_input) func _on_action_ready(action_data: Dictionary): match action_data.action: 移动: player.position _find_target_position(action_data.target) _game_ai.request_npc_reply(神秘老者, _persona_prompt, 玩家朝你走了过来他说道 action_data.intent) 攻击: npc.trust_level - 10 _game_ai.request_npc_reply(神秘老者, _persona_prompt, 玩家突然攻击你) 交谈: _game_ai.request_npc_reply(神秘老者, _persona_prompt, action_data.intent) _: _game_ai.request_npc_reply(神秘老者, _persona_prompt, 玩家做了一件你一时看不懂的事情 action_data.intent)关键点在于AI负责“理解意图”游戏逻辑负责“执行改变”AI再根据“变化后的世界”继续反馈。这个循环一旦转起来玩家会感觉到自己说的话真的在改变游戏世界而不是在跟一个聊天机器人对话。4.4 把AI输出的JSON安全地变成游戏状态这里有一个新手最容易爆的雷AI返回的JSON不能被信任。它多了逗号、少了大括号、自说自话加字段都会让你的JSON.parse直接垮掉。我写了一个_safe_parse_json函数做了三层防御func _safe_parse_json(raw_text: String) - Dictionary: # 第一层直接尝试解析 var result JSON.parse_string(raw_text) if result ! null and typeof(result) TYPE_DICTIONARY: return result # 第二层尝试抠出花括号里的部分 var regex RegEx.new() regex.compile(r\{.*\}, RegEx.MULTILINE) var match regex.search(raw_text) if match: result JSON.parse_string(match.get_string()) if result ! null and typeof(result) TYPE_DICTIONARY: return result # 第三层放弃解析返回一个安全的默认值 return { action: 等待, target: , intent: raw_text.left(50) }很多教程不会告诉你大模型经常会在JSON前面加一句“好的下面是我的回答”。你如果直接JSON.parse整个字符串必然报错。用正则把花括号内容抠出来是最稳的降级方案。5. 实测里最折磨人的踩坑链路跑通第一版只花了一个晚上但真正让它“像能玩的游戏”我调了整整两周。下面这几个坑按我踩的时间顺序写。5.1 流式响应一开游戏直接“假死”初期测试我为了省事关掉了流式接上stream: true的当晚我的游戏画面就卡住了。原因其实不复杂Godot的HTTPRequest虽然本身是异步的但如果你用_process或者同步等待去阻塞主线程循环整个游戏就会僵在那里。排查链路是这样的我先在请求发出前打了print确认AIClient发请求正常请求发出后游戏立刻卡死连UI的点击都失效我以为是await用错了翻查后确认HTTPRequest的request_completed信号会自动在空闲帧触发不需要手动await后来发现我为了“处理流式”把解析逻辑放在了信号回调里做字符串累积和正则清洗这个操作本身不阻塞但传给信号的数据量一大回调里连续做几十次字符串截取和拼接就拖垮了帧循环最终解法流式数据单独走一个后台线程每帧只取“当前已累积的内容”显示到UI解析JSON和清洗文本全在另一个线程做。说实话如果你做的是对话类AI游戏流式真的不是必需品。我到现在很多正式场景都关流式换来的是稳定性和更简洁的代码。流式只留给“长篇剧情演出”这种需要逐字效果的时刻。5.2 上下文膨胀聊到第20句AI开始“失忆”我的对话系统一开始把所有历史消息一股脑都塞给大模型结果就是第10句后响应速度肉眼可见变慢第20句后AI开始重复说“你说得对”第30句后它忘了最初的人设开始说自己是AI助手。根因在于大模型的上下文窗口有限你不控制历史长度它就会被无关信息淹没。而且游戏里一个NPC的记忆只需要保留“对当前决策有影响”的部分不需要逐字记住所有对话。我的方案是引入滑动窗口 关键记忆抽取const MAX_HISTORY : 12 # 最多保留最近6轮对话 func _trim_history(history: Array) - Array: if history.size() MAX_HISTORY: return history.slice(history.size() - MAX_HISTORY, history.size()) return history func _compress_memory(npc_memory: Array) - String: if npc_memory.size() 5: return \\n.join(npc_memory) # 超过5条时让AI把旧记忆压缩成摘要 _game_ai.request_memory_compression(npc_memory)再往后我加了一个“睡前总结”机制每10轮对话后让大模型把历史对话浓缩成几条摘要存进npc.memory旧消息直接丢。这样NPC既能长期记住你跟它的交集又不会让上下文无限变胖。5.3 AI胡说八道怎么办给“幻觉”建一个兜底层最让人崩溃的是AI在某次判定时明明玩家输入的是“小心地推开门”它给你判定成“大力踹门”让整个剧情往离谱的方向狂奔。面对这个我的策略分三层第一层对判定型任务把可选的action枚举写死在prompt里并且用few-shot示例约束它。比如请把玩家的行为归类到以下枚举值之一 - open_door开门 - lock_door锁门 - break_door破门 - leave离开 如果无法归类选择最接近的一项。第二层在游戏逻辑里给每个枚举值写“最小可处理结果”。哪怕AI判定错了游戏也要能正常继续。比如break_door就真的让门碎掉但奖励惩罚照常计算让玩家觉得这是“游戏设计如此”而不是AI出Bug。第三层加一个玩家侧的手动修正入口。如果AI判定得离谱玩家可以长按“重试”按钮重新生成一次判定。这个操作很反直觉但实际体验中玩家非常喜欢因为他们能感觉到自己在跟AI共同创作剧情而不是在忍受一个不靠谱的导演。6. 性能、成本、体验上线前必须补的功课6.1 请求缓存同样的对话别让玩家花两遍钱大模型API按token计费虽然单次不贵但游戏是长期运行的产品玩家每点击一次都调一遍接口成本会失控。我做的第一个优化是结果缓存把“system prompt的哈希 用户输入”作为key把AI回复存到本地File或者登录后的云存档同一玩家再次输入相同内容时直接读缓存不再请求API。这个优化对重复体验剧情的玩家尤其重要。我的Demo里有玩家会把同一句话发给三个不同的NPC其中两句命中缓存响应时间从3秒降到0.1秒体验提升非常明显。6.2 预生成与后台预热消灭“等待转圈”AI响应再快也有网络延迟纯同步等待会毁掉游戏节奏。我做了三件事NPC出场前预生成开场白玩家接近NPC的瞬间就先在后台请求一轮“初次见面台词”走完触发交互时直接展示实现“秒回”回合制思维设计上刻意让AI交互都发生在“玩家主动输入”之后然后进入短等待状态配合转圈UI避免“玩家干等但无事可做”低俗场景用规则AI混合高频的移动、捡物品、简单交互绝不走大模型只有“对话”“复杂行为判定”才走API这样大部分游戏时间完全无网络等待。6.3 提示词工程别写小作文要写测试用例很多开发者把system prompt写成了长篇世界观小说结果AI表现平平。我的经验是人设适量功能边界清晰范例比描述更重要。比如我重新设计“神秘老者”的system prompt后性能提升不是因为人设字数变多而是加了这样一段示例对话 玩家“我听说山里有宝藏。” 老者眼中精光一闪但没有直接答话“……你来的路上是不是踩断了一根结香树枝”这一小段示例让AI明显更懂“这个老者角色该有的节奏”比我在人设里写三十句“他是睿智的、沉稳的……”都管用。另外温度参数也值得定期调。我的项目里对话任务温度0.75判定任务温度0.2记忆摘要温度0.3。调参的过程很漫长但效果立竿见影。6.4 兜底方案AI服务挂了你不能跟着挂最后一个必须提的AI服务宕机或超时不等于游戏崩溃。我的游戏里有一条完整的降级链路请求超过15秒无响应UI提示“剧情服务暂时繁忙”自动切换到本地规则引擎按关键词匹配返回预设回应玩家可以继续探索场景、拾取物品、查看NPC资料游戏主体流程不受影响。这意味着即使我依赖的模型服务临时停机游戏也不会变成一块死屏。很多玩家会因此对你多一份信任因为“AI游戏卡住了”跟“游戏死机了”是两回事。最后再分享一个我这半个月最有成就感的小设计我的Demo里有位“酒馆老板娘”她会在玩家赢得小镇掷骰子比赛后主动提及玩家三天前在河边给流浪猫喂鱼这件事。玩家完全懵了——因为那是他三小时前在一个毫不相关的场景里做的事。实际上我的实现非常土每个NPC的memory共享到同一个全局事件池AI在抽记忆时按“相关性 全局且私密”的权重捞出来。但玩家不知道这层设计他们会觉得“这个游戏里的角色真的在互相信任地传递信息”。这种“虚假的深度”恰恰是AI游戏最迷人的地方。技术上它只是一个记忆池加一次向量检索但体验上它完成了很多3A大作想做而不敢做的事让玩家相信每个角色都有自己的生活。如果你也准备从0开始做AI游戏我的建议是别一上来就纠结“我的AI逻辑够不够智能”先把“输入 → 判定 → 执行 → 反馈”这个循环用最简单的方式跑通哪怕你的角色就只有一个酒馆老板娘。跑通之后你自然会知道下一步该往哪里加东西。这条路我已经替你踩过一遍了接下来该轮到你进场了。