一个有趣的交互BUG 兼谈游戏的引导系统.pdfVIP

一个有趣的交互 BUG 兼谈游戏的引导系统 文 / 顾露 授权 GameRes 游资网发布。 近日在 iPad 上玩一个叫《变形金刚》的游戏时，遇到了一个无响应的 bug 。想了想感 觉可以记一下，写在这儿，对自己也是个提醒。 当把游戏放下，过段时间后从解锁屏幕恢复时，这个游戏就无法响应任何的触摸输入了， 屏幕上的具体情况如下图： 有经验的开发者，光靠这个截图，应该就已经大致明白发生了什么问题了。我们简单分 析一下吧： 中间的消息框，是提示会话已过期需重新登录，这一类对话框很常见。为了防止玩家在 登录已经失效的情况下操作，这个对话框通常会被设计为模态的，也就是所有其它的界面响 应都会被它拦截，只有“确定”那个按钮能响应用户操作。 而在屏幕下方，呈现的是一个标准的新手引导提示——所有的界面元素全部被遮挡，只 有屏幕下方正中间的“剧情”按钮被高亮提示。 明白了各自的作用，理解这个“全屏无响应”的现象就很容易了——它们俩不约而同地觉 得自己是全屏唯一该被响应的元素，其他所有元素都得被拦截。结果就是它们互相把对方给 拦截了，谁也响应不了，整个游戏就死锁无响应了。 原理说明白，解决方案就很简单了。 • 首先，最简单的方案是，设计上显式指定响应的优先级。如让失效提示总是比新 手引导更“高”，也就是弹框能无视新手引导的屏蔽(或反过来)。对代码做最小 的修改，让他们彼此不冲突即可。（方案A ） • 其次，稍复杂的方案是，让模态对话框和新手引导使用同一种机制去做屏蔽全屏 触摸的操作，而通过那种机制去保证多个独占的界面元素同时发生时不会产生 冲突。比如在有的操作系统上，当屏幕上已有一个未处理的模态对话框而又弹 出一个时，原有那个会临时隐藏，待新的那个响应之后，原有那个会又弹出来， 也就是一个“栈(stack)”的串行机制。这个机制的好处是，再有新的独占元素加 入，也很容易纳入支持，代码里可以以统一且一致的方式处理。（方案 B） • 最后，针对新手引导的特点，还有一种做法可能会让代码逻辑更简单和清晰—— 当新手引导中高亮独占的元素时，总是按照那个元素的区域在屏幕上的一个特 定层生成一个隐形的新按钮。当玩家触摸时，总是把触摸事件由这个隐形按钮 转发给对应的元素。这么做看起来是把事情复杂化了，但实践中往往能简化问 题，因为跟那个被独占的目标按钮 (可能出现在 UI 场景树的任意层次上) 不 同，总是临时创建新按钮，可以保证新手引导的所有交互始终发生在指定的那 一层，极大地降低了新手引导与其他游戏机制冲突的可能性。（方案 C ） 大家知道，新手引导通常是纵贯整个游戏的所有功能模块的，一旦管理不善，琐碎的 bug 简直层出不穷。而且如果新手引导与被引导的具体功能交互按钮耦合过紧，模块内部的修改 很容易波及到新手引导。（这也是新手引导往往都是项目后期才加进来的原因，当结构还在 大改时，加新手引导就是作死啊） 通过一层间接性，把引导系统和每个模块的具体 UI 实现隔离开，就能降低引导系统被 无意中破坏的可能性，从而提高整个项目的工程质量。 这三种方案无所谓孰优孰劣，在不同的情境下，它们都有值得被考虑和实现的理由。进 度压力和图省事，往往会使得我们选择方案 A ，但是，只有清楚ABC 各自的利弊得失，并作 出符合当时情况的选择，才能在项目的不断演进中，对潜在风险的变化情况做到心中有数。 说完了这个交互的 bug ，我想把话题转换一下，谈一谈作为一个普通玩家，我自己喜欢 什么样的引导。这一部分非常主观，能坚持看下去的同学也挺不容易了，就随便看看吧。 相比那些全屏独占，一步一步强制引导玩家完成整个引导流程的游戏而言，我