Lua 与 AI/LLM:Agent 脚本、NPC 智能与动态内容
探索 Lua 在 AI 时代的角色:Lua 作为 Agent 脚本语言与 LLM 调用封装、基于协程的多步工作流编排、游戏 NPC 行为树与 LLM 驱动动态内容生成,以及成本、延迟与安全的工程实践。
tag
探索 Lua 在 AI 时代的角色:Lua 作为 Agent 脚本语言与 LLM 调用封装、基于协程的多步工作流编排、游戏 NPC 行为树与 LLM 驱动动态内容生成,以及成本、延迟与安全的工程实践。
对话系统不只是逐字显示文本。剧情游戏、RPG 和任务驱动游戏里,玩家经常需要回看刚才 NPC 说了什么,自己选了哪个选项,某个分支为什么进入当前任务状态。没有历史记录时,玩家一旦手滑跳过或被打断,就只能猜剧情。
城镇和营地需要热闹感。路人走动、商贩招呼、卫兵巡逻、同伴闲聊,都会让世界更可信。但如果每个 NPC 都每帧寻路、检测玩家、播放复杂动画、更新头顶 UI,低端设备很快顶不住。热闹不等于每个路人都用主角级成本运行。
开放地图最容易在原型期给人错觉:把整张地图放进一个主场景,编辑器里能跑,项目就算过关。真正进入内容生产后,问题会集中爆发。玩家站在城门口时,远处森林、城内 NPC、地下入口、天气特效、音频区和碰撞都在内存里;切到低端设备后,加载时间和内存峰值开始失控。Godot 的场景系统很灵活,但灵活不等于可以无限实例化。
编辑器里填的数据,不等于玩家存档 Godot 编辑器很适合让开发者在场景里填数据:怪物出生点、宝箱掉落、NPC 对话、触发区域、相机边界、背景音乐、任务 ID。导出变量和 Resource 让这些数据很容易被内容人员编辑。问题是,很多项目没有区分“编辑器创作数据”和“运行时玩家状态”。
写在前面:会说话,不等于有生命 邵宁想做一款小镇生活游戏。玩家经营一家旧杂货铺,每天和镇民聊天、进货、整理货架、处理邻里小事。项目最初很小,只有 8 个固定 NPC。后来他看到 AI 对话技术,觉得这正好能解决内容量问题。