Rokid AIUI语音推箱子：AR眼镜上的语音交互游戏开发实战

1. 从童年记忆到语音交互这个推箱子项目到底在做什么推箱子这个游戏估计没几个人没玩过。规则简单到一句话就能说清把箱子推到目标点上不能拉只能推箱子进了死角就重来。小时候在文曲星、诺基亚或者网页Flash上玩得不亦乐乎现在回头看它其实是最经典的路径规划和状态空间搜索问题——每一步都要考虑“推完之后人还能不能绕过去”脑子稍微转慢一点就卡关。但这次我做的不是普通的推箱子。我用 Rokid AIUI 把它改成了一个能“听懂人话”的版本。什么意思就是玩家不用按键、不用触屏直接对着眼镜说“往上推”“左边那个箱子往右”“撤销一步”游戏就会执行对应操作。听起来好像只是加了个语音输入但实际做下来涉及的东西比想象中多得多语音指令的语义解析、游戏状态的实时同步、多步操作的意图理解、还有在AR眼镜这种算力和交互都受限的设备上怎么保证响应速度。这个项目适合谁看如果你对语音交互开发感兴趣或者手里正好有Rokid的AR眼镜想找点好玩的东西练手再或者你单纯想重温一下推箱子、顺便看看现在的AIUI能玩出什么花样那这篇内容应该能给你不少参考。我会把整个项目的设计思路、AIUI的接入方式、推箱子核心逻辑的实现、以及实际调试中踩过的坑全部摊开来讲。代码层面我会给出关键片段和配置参数你照着抄基本能跑起来。先说清楚一件事Rokid AIUI 是Rokid提供的一套语音交互开发框架它把语音唤醒、语音识别、自然语言理解、语音合成这些能力打包成了可调用的接口。你不需要自己去训练声学模型也不用搭一套NLU管线直接调用它的API就能让设备听懂指令。这对独立开发者来说省了大力气但前提是你得理解它的意图配置逻辑不然识别率会让你怀疑人生。推箱子这边核心其实就三块地图数据结构、移动合法性判断、胜利条件检测。听起来简单但加上语音交互之后每一块都要重新考虑。比如玩家说“把左边那个箱子推到右边”这句话里包含了目标箱子、推动方向、甚至可能隐含了多步操作你得把它拆成游戏能理解的原子指令。再比如玩家说“ undo”你得知道撤销的是哪一步还要保证撤销之后游戏状态完全回滚。我整个项目的开发周期大概两周其中一半时间花在AIUI的意图配置和调试上另一半花在推箱子逻辑和语音指令的映射上。硬件用的是Rokid Glass 2开发环境是Unity Rokid SDK。下面我按模块拆开讲尽量把每个决策背后的原因说清楚。2. 为什么选Rokid AIUI来做语音推箱子2.1 语音交互和推箱子的天然契合点推箱子这个游戏有个特点操作是离散的、方向性的、步骤明确的。玩家每做一个决策本质上就是在说“把某个箱子往某个方向推一格”。这跟语音指令的结构高度吻合。你不需要像动作游戏那样要求低延迟的连续输入也不需要像RPG那样处理复杂的对话树。推箱子的语音交互可以设计得非常干净指令短、意图明确、反馈直接。另一个契合点是推箱子天然适合“ hands-free”场景。你戴着AR眼镜双手可能在做别的事情或者单纯不想举着手机。语音操作让游戏体验更自然。我试过用触控板玩推箱子玩到后面手指酸得不行语音就完全没这个问题。但这里有个坑推箱子的操作频率其实不低。一关可能要走几十步如果每步都要说“往上推”嘴巴也会累。所以我在设计指令集的时候特意加入了一些“批量指令”比如“连续往上推三格”“把那个箱子推到最右边”让玩家可以用一句话完成多步操作。这就对AIUI的语义理解提出了更高要求。2.2 AIUI相比自建语音管线的优势我一开始考虑过自己搭一套语音识别NLU的方案。用开源的ASR引擎再写一套规则匹配或者接一个轻量级意图分类模型。但算了一下工作量发现不划算。自建方案的问题在于第一ASR的准确率在嘈杂环境下很难保证尤其是AR眼镜的麦克风阵列和手机不一样远场识别需要专门的降噪和波束成形处理第二NLU部分如果要支持灵活的指令表达规则会越写越多最后变成一座屎山第三语音合成还得单独接一个TTS引擎延迟和音质都是问题。Rokid AIUI把这些都封装好了。它的语音唤醒词可以自定义识别引擎针对Rokid设备做了优化NLU支持通过配置文件定义意图和槽位TTS也有多种音色可选。我只需要关注“玩家说了什么”和“游戏该怎么响应”这两件事中间的语音处理链路AIUI全包了。具体来说AIUI的意图配置是这样的你定义一个意图intent比如“move_box”然后给它配几个槽位slot比如“direction”方向和“steps”步数。再写一些训练语料比如“往上推”“向上移动一格”“把箱子往左推两格”。AIUI会根据这些语料自动学习之后玩家说类似的话就能匹配到这个意图。这个过程不需要写代码在配置文件里改就行。2.3 硬件选型和开发环境搭建我用的设备是Rokid Glass 2操作系统是基于Android的所以开发环境就是Unity Android SDK Rokid AIUI SDK。Unity版本用的是2021 LTS这个版本对AR眼镜的兼容性比较好社区里遇到的问题也少。环境搭建的步骤大致如下安装Unity Hub和Unity 2021 LTS勾选Android Build Support。从Rokid开发者官网下载AIUI SDK和Glass 2的Unity插件包。在Unity里新建3D项目导入Rokid SDK的unitypackage。配置Player Settings包名、最低API级别Android 8.0、目标架构ARM64。在场景里添加RokidAIUI预制体填入从开发者后台申请到的AppKey和AppSecret。连接Glass 2通过adb调试。这里有个细节Rokid AIUI的AppKey是和包名绑定的如果你改了包名需要去后台重新申请。我一开始没注意改了一次包名之后语音功能直接失效排查了半天才发现是这个问题。注意Rokid AIUI的免费版有调用次数限制个人开发够用但如果要做商业化项目需要提前评估调用量。3. 推箱子核心逻辑的实现细节3.1 地图数据结构的设计选择推箱子的地图可以用多种方式表示。最简单的是二维字符数组用不同的字符代表墙、地板、箱子、目标点、玩家。这种方式的优点是直观、易调试缺点是每次判断移动都要遍历数组效率不高。我最终用的是位图实体列表的混合结构。地图的静态部分墙和地板用一个二维布尔数组表示true是墙false是地板。动态部分箱子、目标点、玩家用单独的列表存储每个实体记录自己的坐标。这样判断移动的时候只需要检查目标坐标是不是墙、有没有箱子不需要遍历整个地图。具体的数据结构是这样的public class LevelData { public int width; public int height; public bool[,] walls; // true表示墙 public ListVector2Int targets; // 目标点坐标 public ListVector2Int boxes; // 箱子坐标 public Vector2Int playerPos; // 玩家坐标 }箱子和目标点都用List而不是数组是因为它们的数量会变化虽然推箱子里面箱子数量不变但撤销操作需要回滚状态。用List方便做快照和恢复。3.2 移动合法性判断的完整逻辑推箱子的移动判断比看起来要复杂。玩家往一个方向移动可能遇到以下几种情况目标位置是墙不能移动。目标位置是空地直接移动。目标位置是箱子箱子的下一格是空地或目标点推动箱子玩家移动。目标位置是箱子箱子的下一格是墙或另一个箱子不能移动。这四种情况要按顺序判断不能漏。我一开始写的时候漏了“箱子后面是另一个箱子”的情况导致两个箱子叠在一起游戏直接卡死。代码逻辑大概是这样bool TryMove(Vector2Int direction) { Vector2Int targetPos playerPos direction; // 检查边界和墙 if (IsWall(targetPos)) return false; // 检查是否有箱子 int boxIndex GetBoxIndexAt(targetPos); if (boxIndex 0) { Vector2Int boxTargetPos targetPos direction; // 箱子后面不能是墙或另一个箱子 if (IsWall(boxTargetPos) || GetBoxIndexAt(boxTargetPos) 0) { return false; } // 推动箱子 boxes[boxIndex] boxTargetPos; } // 移动玩家 playerPos targetPos; return true; }这段代码看起来简单但有几个容易出错的地方。第一IsWall函数要同时检查边界和墙边界外默认是墙。第二箱子的坐标更新要在玩家移动之前不然会覆盖。第三每次移动之后要记录历史状态用于撤销。3.3 胜利条件检测和关卡数据格式胜利条件很简单所有箱子都在目标点上。但实现的时候要注意箱子和目标点都是List判断的时候不能假设顺序一致。我的做法是遍历每个箱子检查它的坐标是否在目标点列表中。bool IsLevelComplete() { foreach (var box in boxes) { if (!targets.Contains(box)) return false; } return true; }关卡数据我用的是文本文件每行一个字符串用不同的字符表示不同的元素#表示墙表示地板$表示箱子.表示目标点*表示箱子在目标点上表示玩家表示玩家在目标点上这种格式是推箱子社区的标准格式网上有大量现成的关卡可以下载。我内置了20关难度从易到难最后一关是经典的“ Microban”系列里的一个中等难度关卡。解析的时候逐行逐字符读取根据字符类型往对应的数据结构里填。这里有个细节*和这两种字符需要同时更新箱子和目标点、玩家和目标点的状态。我一开始只处理了$和.导致带*的关卡加载出来箱子不在目标点上排查了好一会儿。4. 语音指令与游戏逻辑的映射实现4.1 AIUI意图配置的完整流程AIUI的意图配置是在Rokid开发者后台完成的。你需要创建一个技能skill然后在技能里定义意图和槽位。我定义了以下几个意图意图名称触发示例槽位说明move往上推、向下移动、往左走一格direction, steps移动玩家/推箱子undo撤销、退一步、回退无撤销上一步操作restart重来、重新开始、重置无重置当前关卡next_level下一关、继续无进入下一关query还有几个箱子、现在第几关无查询游戏状态每个意图都需要配置训练语料。语料要尽量覆盖不同的表达方式但也不能太多否则会影响识别准确率。我的经验是每个意图配15-20条语料比较合适太少识别率低太多容易混淆。槽位的定义也很关键。direction槽位我定义了四个值up、down、left、right。steps槽位是数字范围1-10。AIUI支持自定义槽位和系统预置槽位数字用系统预置的sys.number就行。配置完成之后AIUI会生成一个模型需要等待几分钟到十几分钟不等。模型训练好之后就可以在Unity里调用了。4.2 语音指令的解析和映射逻辑AIUI返回的结果是一个JSON包含意图名称和槽位值。比如玩家说“往上推两格”返回的结果大概是{ intent: move, slots: { direction: up, steps: 2 } }我需要把这个结果转换成游戏里的操作。转换逻辑分两步第一步是把方向字符串转成Vector2Int第二步是根据步数循环执行移动。void OnAIUIResult(AIUIResult result) { switch (result.intent) { case move: Vector2Int dir DirectionFromString(result.slots[direction]); int steps result.slots.ContainsKey(steps) ? result.slots[steps] : 1; for (int i 0; i steps; i) { if (!TryMove(dir)) break; } break; case undo: UndoLastMove(); break; case restart: RestartLevel(); break; // ...其他意图 } }这里有个细节如果玩家说“往上推三格”但推到第二格就推不动了应该怎么办我的处理是推到不能推为止然后给一个语音反馈“只能推到这里了”。这样比直接报错要友好。4.3 多步指令和模糊指令的处理策略多步指令是语音推箱子的一个亮点但也是最容易出问题的地方。玩家说“把左边那个箱子推到右边”这句话里包含了目标箱子、推动方向、以及隐含的“推到底”意图。AIUI的NLU不一定能准确解析这种复杂指令所以我做了两层处理。第一层是AIUI的意图匹配。如果匹配到了move意图就按上面的逻辑执行。第二层是自定义的模糊指令处理。如果AIUI返回的是“不理解”或者匹配到了错误的意图我会用一个简单的关键词匹配来兜底。比如检测到“左边”“箱子”“右边”这几个词就尝试找到最左边的箱子然后往右推。这个兜底逻辑当然不完美但实际测试下来能覆盖大部分常见表达。我试过说“把那个箱子往右推”“右边那个箱子往左”“最上面的箱子往下”基本都能正确响应。实操心得AIUI的NLU对语序比较敏感。“往上推”和“推往上”的识别结果可能不一样。配置语料的时候尽量把常见的语序都覆盖到。4.4 语音反馈和TTS的集成方式语音反馈是提升体验的关键。玩家每做一个操作如果没有任何反馈会不确定指令有没有被识别。我在以下几个时机触发TTS移动成功播报“已向上移动”或“推了一步”。移动失败播报“前面是墙”或“推不动了”。撤销播报“已撤销”。关卡完成播报“恭喜过关进入下一关”。查询播报当前关卡号和剩余箱子数。TTS的调用很简单AIUI SDK提供了Speak接口传入文本就行。但要注意TTS播报会占用音频通道如果玩家在播报过程中又说了一条指令可能会被截断。我的处理是在TTS播报期间暂停语音识别播报结束后再恢复。这样虽然会稍微增加响应延迟但避免了指令丢失。5. 实际调试中遇到的坑和解决方案5.1 语音识别率低的常见原因和优化方法调试初期语音识别率低得让人崩溃。我说“往上推”它识别成“晚上推”说“撤销”它识别成“车销”。排查之后发现几个原因第一环境噪音。AR眼镜的麦克风对低频噪音比较敏感空调声、风扇声都会影响识别。解决办法是在AIUI后台开启降噪模式同时尽量在安静环境下使用。第二语速和发音。AIUI对语速有一定的适应范围太快太慢都不行。我在语料里加入了一些不同语速的样本识别率有所提升。第三唤醒词和指令之间的间隔。如果唤醒之后马上说指令识别率会下降。我的做法是在唤醒词之后加一个短暂的提示音提醒玩家可以说话了这样识别率明显提高。第四意图混淆。“撤销”和“重来”这两个意图的语料有重叠导致经常识别错。我把它们的语料重新整理了一遍确保没有交叉问题就解决了。5.2 游戏状态同步和延迟问题的处理语音交互的延迟是不可避免的。从玩家说完到游戏响应中间要经过语音识别、NLU、网络传输、游戏逻辑处理这几个环节总延迟大概在300-500毫秒。这个延迟在推箱子里是可以接受的因为推箱子不是实时动作游戏。但有一个问题如果玩家连续说两条指令第二条可能会在第一条还没处理完的时候就到达。我的处理是加了一个指令队列所有指令按顺序执行执行完一条再执行下一条。同时给玩家一个视觉反馈比如屏幕上的指令列表让玩家知道哪些指令还在排队。另一个问题是状态同步。语音指令执行之后游戏状态变了但AIUI那边不知道。如果玩家紧接着说“撤销”AIUI需要知道当前是哪一步。我的做法是在每次操作之后把当前的操作历史同步给AIUI的会话上下文这样后续指令可以基于最新的状态来解析。5.3 常见问题速查表问题现象可能原因排查方法解决方案语音无响应AppKey错误或过期检查开发者后台的AppKey状态重新申请并更新配置识别结果乱码麦克风权限未开启检查AndroidManifest权限添加RECORD_AUDIO权限意图匹配错误语料配置不合理在后台查看识别日志调整语料增加区分度TTS无声音音频通道被占用检查是否有其他音频在播放释放音频通道或调整优先级游戏卡死移动逻辑死循环检查TryMove的边界条件增加边界检查和日志撤销失效历史状态未记录检查UndoLastMove的调用时机每次移动前保存快照5.4 性能优化和资源管理AR眼镜的算力有限推箱子虽然不复杂但如果不注意优化也会出现卡顿。我做了以下几件事第一地图渲染用对象池。箱子和目标点的预制体不要每次动态创建销毁而是预先创建好用的时候激活不用的时候隐藏。这样避免了频繁的GC。第二语音识别和游戏逻辑分线程处理。AIUI的回调是在主线程执行的如果游戏逻辑太重会阻塞语音响应。我把游戏逻辑放在一个单独的协程里AIUI回调只负责把指令放入队列不直接执行。第三减少TTS的调用频率。不是每次操作都需要语音反馈比如连续移动的时候可以只在最后一步播报。这样既减少了音频通道的占用也降低了延迟。6. 这个项目还能怎么扩展6.1 加入更多语音交互玩法现在的语音指令还比较基础可以扩展的方向很多。比如加入“提示”功能玩家说“提示一下”游戏就给出下一步的建议。这个需要实现一个推箱子的求解器用BFS或者A*算法找到解然后取第一步作为提示。还可以加入“教学模式”玩家说“教我玩”游戏就一步步引导玩家完成关卡。这个需要把求解器的完整解拆成步骤逐步播报。另一个方向是多人协作。两个人轮流用语音操作一个人说“往上推”另一个人说“往左推”游戏按顺序执行。这个在聚会场景下应该挺有意思。6.2 关卡编辑器和自定义关卡现在的关卡是硬编码在文本文件里的如果能让玩家自己设计关卡可玩性会高很多。可以做一个简单的关卡编辑器玩家用语音指令放置墙、箱子、目标点然后保存成文本格式。这个功能的技术难点在于语音指令的粒度要足够细比如“在第三行第四列放一个箱子”这种指令的NLU配置会比较复杂。6.3 适配更多Rokid设备Rokid的产品线不止Glass 2还有Air、Max等不同形态的设备。它们的麦克风阵列、算力、屏幕分辨率都不一样。如果要适配更多设备需要做一定的兼容性处理。比如Air没有屏幕那视觉反馈就要改成纯语音反馈Max的算力更强可以支持更复杂的求解器。6.4 接入大模型做更自然的对话现在的语音交互还是基于意图匹配的玩家必须说“往上推”这种结构化指令。如果接入大模型就可以支持更自然的对话。比如玩家说“我觉得这个箱子应该往右推”大模型可以理解这个意图然后转换成游戏操作。这个方向的技术挑战在于延迟和成本大模型的推理时间比意图匹配要长得多在AR眼镜上可能不太现实但可以把推理放在云端。我在实际开发中的体会是语音交互游戏的核心难点不在语音本身而在“如何把人类的模糊表达映射到精确的游戏操作”。AIUI解决了语音识别和意图理解的问题但意图到操作的映射逻辑还是需要开发者自己精心设计。这个项目我前后改了五版指令集才达到比较满意的识别率和操作流畅度。如果你也在做类似的东西建议先把指令集设计好再动手写代码不然返工的成本会很高。