上周末收拾旧电脑我从一个写着“不能删”的文件夹里翻出了高中写的推箱子Java小游戏。运行起来画面还是那个土黄色的二维地图小人依然能推箱子、能过关。我习惯性地喊了一句“上一步”结果屏幕纹丝不动——毕竟它是个没有耳朵的游戏。那天下午我干的事就是给这个童年游戏接上Rokid AIUI的语音能力让它能听懂人话用嘴指挥小人推箱子。这篇文章就写写这个“语音版推箱子”从想法到落地的完整过程涉及经典推箱子的地图与碰撞逻辑、AIUI的意图与语义槽设计、以及实测过程中踩到的几个语音交互的坑。想给老游戏加语音入口、或者刚接触AIUI做交互Demo的开发者可以拿这份记录当参考。1. 为什么好好一个推箱子非要加上语音指令1.1 触屏推箱子缺少的“指挥感”推箱子这个游戏从PC键盘时代走来四个方向键就是全部操作手段。到了触屏手机上玩法没变但交互本质变成了“用手指替小人走路”。问题也随之而来手指往左一划小人往左一格这个动作太琐碎了。尤其是躺在沙发上单手玩的时候另一个手拿着水杯想挪个箱子还得先腾出手。这时候如果是语音指令只需说“往左推”游戏自己就把这一步做了想象一下其实挺符合“指挥”的直觉。更直接的一次触动是给家里小孩演示关卡。小孩站在旁边看到小人被箱子挡住激动地喊“往上推往上推”结果我的手指正按在屏幕上遮住了关键位置。那一刻我突然觉得推箱子这种规则明确、步数有限、反馈直接的游戏天然适合语音指挥——它不是一个需要连续操作的动作游戏而是一步一步“下达命令”再“等待结果”的策略游戏中间天然留着语音交互的缝隙。1.2 为什么选AIUI而不是裸接ASR给游戏加语音最朴素的做法是把一段ASR语音识别文本拿回来然后写一堆关键词正则去匹配“上”、“往上”、“推上去”、“go up”。这种方案不是不能用但问题在于“说法一变就失效”。今天测试说“往上推”能识别明天玩家说“把箱子朝上面顶一下”正则又跪了。维护这种关键词列表本质上是在手工维护一套语义理解系统越写越痛苦。Rokid AIUI的价值在于它自带一套完整的语音交互链路不只是把声音转成文字还负责把文字转成“意图”和“槽位”。我在AIUI的语义配置里定义一个意图叫moveBox槽位叫direction然后给它配上几十条自然说法样本系统会自动把这些说法归一到同一个指令模板上来。也就是说玩家说“往上推”“上去一格”“把箱子往上面顶”时我收到的都是一份结构化的结果意图是移动箱子方向是上。我不需要关心原句到底是怎么说的。同时AIUI天然带TTS能力可以让游戏开口回应玩家。移动成功时播“咚”墙挡住时回一句“动不了”过关时说“干得漂亮”。这一套如果自己拿ASR加播放器拼也能做但维护成本明显更高。做这种小游戏Demo选AIUI这类带语义理解的平台能把更多精力放在游戏逻辑本身。1.3 这个项目到底适合谁上手如果你正在做Android端的语音交互应用或者手里有个想“翻新”的老游戏又或者只是想搞懂“意图、槽位、语义理解这些概念在真实项目里长什么样”这个项目都很适合拆开看。它复杂度适中游戏逻辑是纯单机的不碰网络同步语音链路是标准的“识别—理解—执行—反馈”闭环整体跑起来不需要复杂的服务端架构。这篇文章后面所有内容基本可以按“抄作业”的方式来读。2. 整条链路的骨架从声音到“咚”的一声落箱子2.1 一条语音到一格位移的四段路径语音控制推箱子核心链路比大多数人想的要短。我把它拆成四段录音采集。玩家按住屏幕说话抬手结束AIUI把这段音频送去做识别。我没有做持续唤醒因为推箱子需要精确地一步一下唤醒词会频繁打断思路。ASR识别。音频变成文字比如“把箱子往左推”。NLU语义理解。AIUI根据我预先配置的语义模板从文字里抽取出意图moveBox和槽位directionleft。游戏引擎执行。我把解析结果转换成具体的坐标向量交给推箱子的核心逻辑去判断“这一步能不能走”能走就更新地图、播放音效。这四段里面前三段都是AIUI一个SDK搞定的我重点关注的是第四段。最初我犯过一个理解上的错误以为收到AIUI回调后直接改地图坐标就行忽略了推箱子本身还有一层“合法性校验”。语音说“往左推”不代表就一定能推——左边可能是墙可能是另一个箱子可能玩家旁边根本没有箱子。所以语义解析成功只说明“玩家想这么做”不说明“游戏允许这么做”这两件事必须分开。2.2 单线程串行别让回调弄乱棋局推箱子的棋盘状态是全局的每一步移动都会改变玩家坐标和箱子位置。而AIUI的回调并不是和游戏逻辑同一个线程它可能在任意一个异步线程里把结果抛回来。如果我在回调里直接改地图就会出现一个很恶心的场景玩家连说两句“上”“上”第一次移动还没完全刷新第二次移动已经带着旧坐标算了一遍结果小人根本没走两步或者箱子瞬移到奇怪的位置。我的处理方式很土但很稳在GameActivity里初始化一个指令队列所有AIUI回调统一用runOnUiThread扔回主线程然后按顺序执行。主线程同一时间只处理一条指令每条指令执行前都重新读取当前的玩家坐标和箱子坐标而不是复用上一次回调时缓存的坐标。这样即使语音指令排队返回游戏状态也不会打架。这一步的原则值得单独说一下异步回调只负责“翻译用户意图”不负责“修改游戏世界”。一切修改都发生在主线程的游戏引擎里而且每一条指令都以执行那一刻的地图状态为准。2.3 指令与状态之间的“当下”原则做语音游戏和做视觉游戏的思维有个明显差别。视觉游戏里玩家看到什么画面再点对应按钮交互和画面是同步的。语音交互不同玩家说完“往右推”语音经过识别和理解可能延迟了三四百毫秒才回到游戏此刻场景里可能已经发生了别的事。这时候如果还用“玩家说话那一刻的画面”来判断就会错位。所以我定了规则指令到达时只认当前地图不认上下文。玩家说“下一步”就是“现在的下一步”他理解的是当下的棋局。推箱子每一步都是原子操作不做多步连推也不做“记忆上一次说话时的坐标”这避免了所有状态错位问题。实测下来单条指令的延迟体感在三百到五百毫秒之间对回合制益智游戏来说完全可以接受。3. 推箱子没改动的那三块地图模型、碰撞规则与Undo栈3.1 二维数组加字符串地图一眼能看懂推箱子核心逻辑我是从旧项目里原样搬过来的只做了极小改动。整个游戏的地图不搞复杂的对象系统就是一张二维数组。我用几个整数代表不同元素0空地1墙体2箱子3目标点4玩家一个最小的关卡长这样// 0空地 1墙体 2箱子 3目标点 4玩家 val level listOf( intArrayOf(1, 1, 1, 1, 1, 1), intArrayOf(1, 0, 0, 0, 0, 1), intArrayOf(1, 0, 4, 2, 3, 1), intArrayOf(1, 0, 0, 0, 0, 1), intArrayOf(1, 1, 1, 1, 1, 1) )为什么用数字数组而不是建一个Box、Player、Wall的类体系因为关卡调试太方便了。游戏跑起来以后直接println整个地图谁在哪儿、箱子到没到目标点一目了然。语音指令的调试本身就是个黑盒过程如果底层的棋局状态还要靠断点去翻对象属性排错效率会非常低。用数组之后出了问题我直接打一张地图出来看立刻知道是哪一步逻辑没走通。关卡切换也很简单每个关卡就是一张字符串。我自己做了一套关卡配置格式把地图的每一行用字符串存起来加载时解析成数组。做语音换关的时候只需要根据关卡序号找到对应的字符串重新解析一遍整个棋盘就重置了。3.2 一次移动要过三道判定推箱子看似简单移动规则其实有三层判定少了任何一层都会出现穿墙或者飞箱子的Bug。我每次尝试移动玩家都会按顺序走这三个检查val dirMap mapOf( up to intArrayOf(-1, 0), down to intArrayOf(1, 0), left to intArrayOf(0, -1), right to intArrayOf(0, 1) ) fun tryMove(direction: String): Boolean { val (dy, dx) dirMap.getValue(direction) val player findPlayer() val nextRow player.first dy val nextCol player.second dx // 第一道玩家前方不能是墙 if (grid[nextRow][nextCol] WALL) return false // 第二道如果玩家前方是箱子检查箱子前方 if (grid[nextRow][nextCol] BOX) { val boxNextRow nextRow dy val boxNextCol nextCol dx // 第三道箱子前方不能是墙也不能是另一个箱子 if (grid[boxNextRow][boxNextCol] WALL || grid[boxNextRow][boxNextCol] BOX) return false // 箱子可以动先挪箱子 moveBox(nextRow, nextCol, boxNextRow, boxNextCol) } // 玩家走到目标位置 movePlayer(player, nextRow, nextCol) checkWin() return true }看代码就能理解三层判断的意义。第一道管住了玩家不穿墙第二道管住玩家只能推箱子不能撞穿箱子第三道管住箱子不能穿墙也不能推动另一个箱子。这里容易漏的是第三道很多初学者只检查“箱子前方是不是墙”结果两个箱子并排的时候一推就重叠状态直接崩坏。我见过不止一个推箱子新手项目栽在这一行上。胜利判定也很朴素每次移动后遍历地图统计所有箱子是否都落在目标点格子上是则过关心。这里不做“箱子进了死角立刻提示”这种优化因为语音版本里玩家本来就会通过“动不了”的反馈感知到路径被封死过早弹出失败提示反而打断节奏。3.3 快照式撤销最省心的Undo方案推箱子玩到中盘经常要悔棋。我最初想的是记录玩家的每一步操作方向然后反向推导操作来还原棋盘。后来发现这个方案有很多边角问题如果玩家推了一个箱子又绕了一圈回到原位置用操作记录逆推就得处理很多“这个箱子后来被谁动过”的情况代码越写越复杂。换成了快照方案之后世界清净了。我在每次合法操作前把“玩家坐标 所有箱子坐标列表”打包成一份State压进撤销栈。撤销时直接弹栈恢复这份快照。因为推箱子的地图小、箱子数量少一个快照就是几十个整数内存开销完全可以忽略。data class Snapshot(val playerRow: Int, val playerCol: Int, val boxPositions: ListPairInt, Int) val undoStack ArrayDequeSnapshot() // 每次执行合法移动前 undoStack.addLast(Snapshot(player.row, player.col, boxes.map { it.row to it.col })) fun undo() { val snap undoStack.removeLastOrNull() ?: return player.row snap.playerRow player.col snap.playerCol boxes.forEachIndexed { index, box - box.row snap.boxPositions[index].first box.col snap.boxPositions[index].second } refreshView() }这个方案之所以好用是因为它把“恢复现场”这个复杂职责压缩成了一次数据还原任何一步出问题撤销栈都不会留下脏状态。对语音交互来说尤其重要AIUI可能把一句“回一步”解析成悔棋也可能把“退回去”解析成另外的动作底层如果扛得住随时回溯上层再乱也能兜住。4. AIUI语义槽设计让玩家一百种说法落到同一个指令4.1 意图和槽位怎么建模才不打架AIUI这种语义平台的核心抽象就是“意图 槽位”。意图表示玩家想干什么槽位表示干这个事情的必要参数。推箱子这个场景里我定义得很少moveBox意图表示玩家想推动箱子槽位是direction取值限定为up/down/left/right。undo意图表示悔棋不需要槽位。restart意图表示重新开始本关不需要槽位。nextLevel意图表示进入下一关不需要槽位。这里最需要注意的坑是方向槽位的取值一定要做枚举限定。AIUI的语义理解会把“往右边”解析出directionright但如果我不限制槽位取值范围它也完全可能把“往右侧那个空地方”解析成一串复杂描述。推箱子本身只接受离散的单步方向所以我在配置槽位时明确只允许四个值所有超出范围的解析结果都视为无效建议玩家再说一次。意图之间的边界也要划清楚。“回一步”“退回去”“撤销”我都归到undo“重来”“重新开始”“重置本关”归到restart。一开始我把“退回上一步”和“重新开始”放在同一个意图里结果玩家说“退回去”时游戏直接重开了这个问题直到实测阶段才发现所以意图划分宁可多建几个也不要塞在一起。4.2 四个核心指令的示例说法池我在AIUI的语义配置里给每个意图都放了一批“示例说法”。这一步很枯燥但直接决定识别效果。移动指令的示例我最初只写了七八条比如“往上推”“往左推”“向右推一下”结果发现玩家根本不会按我规定的句子说话。实际测试中听到的说法五花八门。我一边试一边补最后沉淀出一个说法池意图典型说法槽位取值moveBox往上推、上去一格、把箱子往左推、朝右边顶一下、推到上面那个空位directionundo回一步、撤销、退回去、倒回去一步无restart重来、重新开始、重置本关、这关重开无nextLevel下一关、换一关、继续下一关无通过这个表能看出一个通用原则示例说法不求多求覆盖说法模式。每种说法代表一种句式“把X往Y推”是一个句式“推Y方向”是另一个句式句式覆盖到了玩家换个名词也能被理解。如果你只是机械地堆大量同质说法识别效果不会有质变。这里也踩过一个真实的小坑中文里“上”和“上面”是同一个槽位值但在语义理解时可能被拆成不同表达。我把方向槽位的别名配置成“上/上方/上面/往上/朝上”等等让它们都归一成up这样后续处理代码只要处理四个值不用处理一堆同义词。4.3 识别完成后的小动作设计语义识别完成只是开始游戏还要给玩家明确反馈。我最初的设计是AIUI识别出moveBox后立即调用TTS播报“正在往左推”。结果实测下来非常累赘玩家已经连续说了好几步每步都被一句“正在”打断节奏全无。后来我把反馈改成静默执行加短音效只有过关和失败时才让TTS说话。移动成功时播放一个箱子拖动音效移动失败时播放一个沉闷的撞击声同时TTS用最短的话提示“动不了”。这比说“往左方向不可行请更换指令”友好得多。AIUI的语音交互能力在这时候更像一个“游戏旁白”而不是一个复读机。反馈的粒度应该是“一步一音”而不是“一步一段话”。5. 实测中的翻车现场与调优记录5.1 “往右”和“往右拐”傻傻分不清第一个正式测试就翻车了。测试者对着麦克风说“往右拐”AIUI解析出来的意图不是moveBox而是某个类似“转弯导航”的意图我压根没定义过这个意图。游戏没有任何反应测试者一脸疑惑地说“我说了往右啊。”这个坑的本质是语义模板里的示例说法如果不够宽ASR/NLU就不会把“往右拐”归到移动指令里。我当时的修复方案有两步。第一步把“往右拐”“往左边拐”“往上拐”这类说法补进moveBox的示例池让系统知道“拐”和“推”在这个语境下是一个动作。第二步加一个兜底逻辑如果AIUI返回的意图不在我的四类白名单里而且文本里能匹配出四个方向词之一就把这次请求当作moveBox处理。第二步本质上是一个“语义兜底的正则”它治标不治本但能大幅提升容错率。推箱子这个场景对意图的定义本来就非常窄玩家的目的几乎永远是移动、悔棋、重开、下一关这几个动作。兜底规则加进来之后即使语义模型没抽中意图游戏也不会愣住。5.2 “前”到底是谁的前另一个更有趣的问题是玩家说“往前推”。中文里“前”这个方向词在不同语境下指代不同方向可以指屏幕的上方、玩家小人的面朝方向也可以指当前视口的前进方向。推箱子的二维地图里小人面朝哪边取决于上一次移动方向如果语义解析把“前”固定为“上”而小人实际面向右边玩家就会觉得游戏在乱动。这个问题的真正解法不是去给AIUI增加“前”的复杂方位逻辑而是降低语义理解的自由度。我在示例说法池里直接不收录“前”“后”“左转”“右转”这类相对方向词只接受“上、下、左、右”四个绝对方向。游戏开始界面加了一行提示“语音指令请使用上下左右”。这看起来是退缩实际是设计取舍推箱子本来就是四方格操作绝对方向最不容易产生歧义。如果真的想支持“往前推”就得引入一个玩家朝向状态每次移动后更新朝向语义解析时还要把“前”翻译成朝向的向量。这套逻辑做完整不难但会给语义槽位和游戏引擎之间增加大量耦合。这个Demo阶段我选择不碰。5.3 反馈与节流TTS不是话痨喇叭还有一类翻车来自TTS。最初的版本里我几乎给所有状态变化都配了语音播报移动前说“好的”移动后说“已移动”撞墙说“前方有障碍物”过关说“恭喜过关你用了十五步完成”。结果十分钟测试跑下来所有人都被烦得不行。语音游戏最怕的不是“听不懂”而是“话太多”。正确做法是让TTS退居二线。移动成功不再播报只用音效反馈移动失败时说两个字的“动不了”过关时才说一句完整的“过关了”。同时加上节流逻辑如果玩家在短时间内连续说“上上上”排队指令每隔两百毫秒执行一条而不是三条指令同时冲进游戏。这个节流参数不是拍脑袋定的我试过零延迟指令会吞试过五百毫秒玩家觉得拖沓两百毫秒时体感最接近连续按键。6. 从Demo到玩具推箱子语音化的三种进化方向6.1 语义级连招说一整段做一连串动作现在的版本一次只处理一条指令玩家说一步走一步。AIUI本身是支持多轮和连续理解的如果扩展一下完全可以让玩家说“先往左推再往上推然后往右推”。语义解析结果会是多条指令列表我在游戏引擎里用一个队列把它们串起来逐条执行。这里的好处是推箱子的“步数”概念很清晰每个指令都是原子移动队列天然适配。而且玩家可以提前规划好三四步像小时候在纸上写攻略一样念给游戏听。我试过一版简易实现把语义结果里的动作序列转成指令队列效果出奇地好尤其是解稍难的关卡时指挥感会被拉到很满。后续如果要继续开发我会优先把这块做成正式功能。6.2 自然语言选关与自动求解结合推箱子到了后期关卡玩家很容易卡住。如果结合一个自动求解器比如BFS或A*再配合AIUI的语义理解就变成玩家说“这一关我过不去了帮我走两步”游戏就能自动推演几步并演示。这其实是把语音、搜索算法和动画播放三件事缝在了一起技术上不难但体验会非常惊艳。更朴素的扩展是自然语言选关。目前我只实现了nextLevel下一关如果玩家喊“第七关”AIUI会解析出一个数字槽位游戏直接跳关。这比在界面里翻页码更贴合“指挥感”。老玩家对特定关卡有记忆语音跳关省掉了界面导航也算这个方向的一个实用点。6.3 语音是更平等的游戏入口最后说点我做这个Demo过程中真正被触动的地方。推箱子这种纯逻辑游戏其实非常适合做无障碍适配。如果操作界面能完整隐藏玩家只需要用嘴说“上、下、左、右、撤销、重开”就能通关整个游戏那这个游戏对视障玩家就多了一扇门。普通玩家用触屏是轻松的但对特定人群来说语音不只是一个花哨功能而是他们使用一款游戏的主要途径。Rokid AIUI本身在语音交互上已经解决了识别和理解的问题留给开发者的是交互设计问题什么时候反馈、什么时候沉默、怎么容忍错误、怎么处理歧义。我在这篇文章里记录的很多“小坑”本质都是这些问题的具体体现。如果你也打算给游戏加语音希望这份记录能帮你少走几段弯路。