从UI设定层面谈玩家的操控和界面效能
导读：本文将指出另一种思考UI的角度，讨论如何比较UI的优劣或将一种UI与理论上最有效的UI作比较，最后解释如何改进游戏。
前言
一般来说，电脑游戏要求玩家控制屏幕上的一个或以上的单位。在早期的游戏中，玩家通常控制只一个单位。随着CPU性能提升，玩家控制的单位越来越多。今天，玩家可能要控制上百个单位，每个都必须独立操作。这种基于单位的UI不再有效了。本文将指出另一种思考UI的角度，讨论如何比较UI的优劣或将一种UI与理论上最有效的UI作比较，最后解释如何改进游戏。我使用的例子主要是策略游戏的，但这些UI案例同样适用于其他类型的程序。
我一直很喜欢《文明》系列游戏。当我让朋友来玩这款游戏时，他们在前一两千年还很有热情——当然这指的是《文明》中的时间，也就是一百多个回合吧。但之后，游戏中城市、单位和等待时间变得太多了，新手就会觉得游戏变成一连串单调乏味的点击操作。
甚至对于资深《文明》粉丝，这款游戏的乐趣也不能超过1800年。点击太多了。我数了我玩到《文明3》的1848年时共经历了多少次点数、鼠标移动和按键盘。许多个小时之后，当那个回合结束，我得到的结果是：422次鼠标点击，352次鼠标移动，290次按键盘，23次鼠标滚轮和18次屏幕滚动。如果不是充分利用了《文明》的所有快捷操作、自动操作和集合移动，以上数字还要翻倍。
c3c_industrial
你可能会问，为什么我谈的是《文明3》，而不是已经出了好几次个月的《文明4》。我从来没有买过《文明4》。我一直在等着更好玩的《文明》游戏。而我最终等到的是需要同样多点击操作的《文明4》，只是换上了新的3DUI罢了。
不要误解我——《文明4》确实增加了重要的新玩法。在这方，Firaxis做得比那些只不过制作一些新单位、美术和过场动画就说是新版本的公司好多了。但我不玩《文明3》不是因为我厌烦了那款游戏，或因为它不够精致。我不玩了是因为它需要的时间太长了。《文明》不需要更漂亮的UI——它需要的是更有效的UI。
点击过多不是《文明》专有的问题。即时策略游戏会让你患上更严重的腕道症候群。那就是为什么我不玩《魔兽争霸》或它后来的在线版。对于今天的即时策略游戏，策略似乎变得不重要了，当与你对战的是一个按键比你快两倍的14岁少年时。
RTS的UI从《TotalAnnihilation》(1997)以后就没有什么突破。这款游戏的单位自动化比现在的许多游戏都更实用。同时，我们的电脑可以控制和动画的对象也增加了，并且还在以指数速度增加。老式UI模型没有达到突破点——更是破了。
本文是关于如何设计一种让玩家用更少的点击传达意图的UI。我不打算讨论UI的人体工学(物理上的易用性)或认知工效学(如视疲劳和人类记忆及处理要求)。在评估他们的UI时，设计者应该考虑到这些问题，但那些太复杂了，不是这么短的文章就能解释清楚的。
“7”原则
策略游戏通常让玩家扮演如军队指挥官这样的角色。但想一想现实世界的指挥官是怎么工作的。他不会一边观察地图，一边命令战场上的每一辆坦克。在真实的战争中，他手下有几个直接听从他的命令的人。在美军中，1个小队长和2名火力小队长一起带领约9名士兵。1个排长通常指挥4个小队长再加上3-4名参谋。1个连长通常对4个排长和参谋直接发号施令。1个中校可能指挥4个连的部队加参谋，等等，形成一个完整的指挥系统。
没有意外。这是使长官得以有效地管理有限数量的下级的军事组织的基本原则。由长官直接指挥的下级数量就是该长官的指挥范围。无论是排长还是战区司令，最有效的指挥范围都是一样的。19世纪欧洲军队确定的指挥范围的最大值是7，这个数字自那以后就没有变过。
在现在的美军中，指挥范围应该是5-7。在救灾工作中，联邦应急管理局的主管监督的下级通常不超过7人。根据美国众议院报告104-631，1997年整个美国政府机构的指挥范围就是7。这并非巧合，7也是一般人可以同时记忆的物品的最大数量。这就是为什么电话号码是7个数字(不含区号)。
这个原则也应该运用于策略游戏设计。控制数量超过7的玩家不可能有效地管理所有单位。(这是推论，如果一个回合历时一分钟，玩家每10秒钟执行移动约一次，那么玩家可能无法专心致志且没有机会进行深入、策略性的思考，而这本应该是策略游戏的乐趣来源。要求玩家每秒一点击的游戏是街机游戏，无论它的复杂度是多少。)
一个战区司令指挥的7个下级通常有一两个不直接参与战斗而是负责转达信息。这意味着不同的信息显示器(注：如《文明》中的城市显示和技术显示)计数达到7.
这个原则存在使情况复杂化的因素。以国际象棋为例—-各个玩家控制16个棋子，且同时必须注意16个敌方棋子。这就是为什么国际象棋对初学者来说这么困难。但国际象棋专家却能应付得了。国际象棋的玩法违背了“7”原则吗?
是的，但也不是。国际象棋的专业知识不包括学习用头脑跟进越来越多的棋子;而是学习把棋盘位置拆分成单独的、熟悉的结构——士兵、国王、三个士兵、骑士、一组对中心区域有影响的棋子——为了把概念的数量压缩成人类可控的数量7。
美军的指挥范围目的是，指挥官可以命令和监督第一层级(他的下属)，同时跟进第二层级的情况(他的下属的下属)。国际象棋的玩家掌握两个层级的控制：第一，选择这些结构体各自的子目标(比如，“控制中心”或“打破对方的防御结构”);第二，选择执行各个子目标的步法且选择其中一个步法。这样，玩家就不是跟进所有棋子，而是选择每一个步法，这就破坏了“7”原则。如果你希望你的游戏进展得比国际象棋快，且仍然保持策略性，那么你就必须遵守“7”原则。
鱼与熊掌不可兼得
游戏设计师可能会认为，如果允许玩家控制所有单位，但不是必须控制所有单位，那么游戏世界就完美了。不幸的是，事实并非如此。在经济学中有一条法则叫作“Gresham’sLawofMoney”，也叫作“劣币逐良币法则”。Gresham解释道，当一个国家使用两种货币，即具有固有价值的金属货币和不具有固有价值的纸币时，纸币会把金属货币驱逐出市场，直到所有人都只使用纸币。
在游戏中，恶劣的玩家驱逐优秀的玩家。在RPG中，糟糕的角色扮演(注重财富积累和控制权的玩法)升级更快，最终把优秀的角色扮演驱逐出游戏世界。在允许控制各个独立单位的游戏中，每秒可以执行3次点击的14岁男性玩家会打败依赖电脑执行其计划的思考型玩家，因为我们距离电脑可以比人类玩家更好地控制单位的时代还很遥远。
有些玩家喜欢快速点击和微观管理，他们也许就是游戏杂志、广告和推广渠道所针对的上述14岁男性玩家。越出这个熟悉的玩家类型的范围总是危险的。任何制作人都不愿意损失这个市场份额，所以游戏最好能够包含独立单位控制的选项。
然而，现在的游戏市场却没有充分考虑害怕患上腕道症候群的玩家(我想这个市场会比14岁少年玩家的市场更大)。如果游戏允许控制独立单位，那么它必定是一个独立的游戏选项，玩家应试能够设置不允许独立单位控制的多人游戏。
现在，你可能会质疑我的神智是否清楚，发布本文的编辑是否有脑子。我是说策略游戏应该只允许玩家控制7个单位?不是的。我是说，玩家不应该直接控制它们。我们必须概念化控制的中间层。这做起来并不困难，只是被常见的对象导向型程序的误解所阻碍。
对象不必是对象
Smalltalk(注：为XeroxPARC在1970年代所发展出来的一种使用功能表单驱动的高级程序语言;常与鼠标器合并使用)用户称对象为“objects”，称方法为“verbs”(动词)。自那以后，许多制作对象导向型程序的程序员都把“objects”解释为“noun”(名词)。我曾与其他程序员争论，因为他们认为游戏不是对象导向的，除非游戏中的物理对象在代码中是OO对象(面向对象)。当我表示，让游戏中的verbs成为代码中的objects，这样组织代码从而强制执行游戏的一致的物理学。他们回答道，“objects就是objects，verbs就是verbs。”至今，我们仍在根据游戏中的物理对象来组织游戏代码和UI。
不必如此。对象，在面向对象的情况下，可以是任何你所选择的抽象概念。在《文明3》中，对象可以是军事行为或工程项目。如图1所示。在这张图片中，我的文明已经在开发铁路技术了。我打算把国家的南北两端用铁路连接起来。
文明3
对于《文明3》的单位导向的界面，这需要点击各个工人单位，把他们分配到的铁路线路的各个路段。各个工人必须分配到线路的某个短的路段，因为如果你让一个单位从南端作业到北端，让另一个单位从北端作业到南端，那么完的路段就会从他们的任务的开头部分计算，而不会计算另一个单位同时作业的部分——导致大量非重叠的平等铁路线路，以及军队将无法越过你的边界来击退罗马军团的侵略。
为了在被侵略以前完成，我必须分配约一百个工人去建造铁路线。对于各个工人，选中必须点击一次;然后输入“g”开始移动，滚动到铁路线的起点，再点击。之后，当它到达那个点，我必须输入“ctrl-r”以开始建筑铁路和，滚动到那个单位的铁路部分的末端，再点击。每个单位都经过这三次移动，三次按键，和三次鼠标点击。我尝试过把工人组成三人小组，尽管这不是任何时候都可行的。所以我大约执行了600次点击、按鼠标和滚动才完成那条铁路、
想象一下，如果我只要点击铁路的开端和末端，电脑就会指挥工人却建筑他们各自的路段。这整个铁路就会在我指挥各个单位所需的同样的管理工作量下建造完成。
这条铁路的作用是把军队运到边界去抗击罗马军团。另外，每个新建造的单位都必须各自沿着线路运送到边界沿线的某些地点抗击敌人。想象一下，如果我只要简单地确认边界、城市或防御点，电脑就会操作剩下的军队移动，那么我的手腕该省下多少力。但为了清楚地执行，程序员必须把铁路和边界作为第一类对象。
离线vs.在线控制
指挥官之所以能够命令7名下属的一部分原因是预先准备。他事先设定好了任何行动的情节，并通过在他的军队行动中命令不同情节间的转变而实现快速且巨大的改变。他的服务分支带有一个标准的战术库，即基于团队水平区别他可以在行动过程中用于向下属解释自己的目的。他的下属面对着交战规则去判断如何对各种类型的敌人以及非战斗式行动作出回应。他可以事先将这些规则带进战斗中。他带有许多野外演习，在每次演习后，他会告诉下属他们哪些做对了而哪些则做错了，而他的长官也将对他的表现做出分析。这便减少了战斗中所需要的直接监管的分量。
如果你使用统一的形式去设计游戏AI，如基于规则的系统或有限状态自动装置，你便可以将其作为指导玩家单位的另一种方式而面向他们开启。在真正的军事野战游戏模拟器(如JSAF或OneSAF)中，面向半自动单位创造交战规则是必要的。实际上，SAF可以代表“半自动化兵力，”这是能够提供非常复杂的任务和交战规则的单位，所以操作员便能够监管它们并且不会过多进行干涉，同时还能为真正控制每个对立单位提供现实的培训环境。
有些游戏，像《Quake》便允许玩家访问AI去设计敌人;或者像在《Robotwar》中，玩家所获得的单位必须是经过完整规划的，而不是在游戏过程中进行引导。没有人会为半自动化兵力提供一个界面。提供两个用户界面(注：一个是提供交战规则的离线界面，另一个是用于在线过程中)将减少处理个体单位的压力。
用户界面性能分析
为了检测哪一部分用户界面是无效率的，你可以使用用户界面分析器进行测试。UI分析器就像代码分析器，但比起报告CPU循环，它报告的是用户界面事件。它将直接呈现出玩家在你的每部分代码中进行了多少次点击，按键以及鼠标移动。用户界面分析器可以呈现出更复杂的信息，如表示用户所落实的行动序列的图像。
你也许可以使用你的IDE分析器去计算I/0事件或函数调用，但这通常都不能告诉你玩家将最多时间花在哪些内容上。如果你让代码调用一个程序去报告UI事件而启动自己的UI分析器，你便可以因此获取更多信息。
就像如果《文明III》的开发者能够使用一个UI分析器，他们便能够发现在游戏的谈判部分中出现了过度点击与按键次数。这也揭示了游戏中存在漏洞(注：即城市选择菜单中缺少滚动条)，并需要游戏明确交易中的最低限度金币数量，而不是让用户使用二进位检索去找到它。根据我的估算，这两个任务占据了100个以上的UI事件。
为了比较不同的潜在UI，你需要保持分数的方法。回到我的《文明III》UI中，我可以通过将点值分配到每种UI行动类型中而获得整体的UI分数。你是如何基于想要策略的内容去分配点数。对于一款街机游戏，速度便是主要衡量标准，所以你可能会基于按键速度去计算鼠标的点击速度。
对于像《文明》这样需要花数个小时体验的游戏，你应该更加重视玩家的消耗。对于每次使用同一个手指，比起按压按键，鼠标点击需要花费更大的力量，所以这会对手腕造成更大的压力。(其实人们所归咎的按键造成的疼痛往往是鼠标点击所造成的。)所以我将计算每次鼠标移动和按键作为1个UI点;每次鼠标点击作为3个UI点;每次滚动滑轮作为6个UI点;每次鼠标平移作为9个UI点。如此每次移动总共会得出2208个UI点。不同的UI可以与分数进行比较。
UI分析器可以用于评估并完善已经存在的UI。基于一些数学元素，你可以在编写任何代码钱评估UI。
估算
你可以计算玩家必须做的W操作去明确使用你的用户界面的一次移动。如果你基于游戏的变量衡量W，如游戏区域的规模以及玩家单位的数量，你便可以比较不同的用户界面，即使你只能够估算W。
例如，为塑造一个虚拟粘土考虑一个UI。你有大小nnn的体素数组，每个体素是可以打开或关闭的。我们将考虑四个可能的用户界面。在第一个界面中，用户想要打开每个体素坐标轴中的用户类型。用于明确从1到n的按键次数是与log2(n)成比例的，所以这让操作与3log2(n)成正比去明确每个打开的体素。(从现在起，我将不再使用“成比例”这一短语并编写W=f(x)，即它意味着W=O(f(x))。)如果我们假设美术人员将明确一个界面，并且不填满整个雕塑，那么整体的操作将变成W=3n2log(n)。(界面的大小与n2成正比。)
在第二个用户界面中，用户在三维空间中使用三维鼠标(如3DConnexion的Spacebaoll)选择一个点，并点击鼠标去切换打开/关闭状态。操作需要前进到三维空间的一个特殊点上，然后结合三次移动;每次移动是基于1到n的坐标轴范围，并伴随着平均n/2值似乎它将利用操作W=n5/8去创造一个雕塑。然而，让我们假设在打开一个体素后，用户会移动到26个相邻体素中的一个。我们会说这与明确26个选择中的一个(即log2(26))所需要的信息成正比。我们将其粗略估算为log2(33=27)，因为在这里以及我们之前关于W的值中的常数3是源自雕塑的三维属性。之后整体的操作是W=3n2log2(3)。这一界面看起来就像是对于第一个界面的完善。
在第三个界面中，我们将让用户从一个与预期雕塑同样大小的球体粘土开始，用户将使用一个普通的2D鼠标绕着粘土的表面移动光标，并点击左键在光标下推动左键(垂直于界面)，并按压右键将其往上拉。我们将使用一个加速推/拉界面(声明体素的数量)粘土朝着同样方向移动时传达双倍推或拉的体素数量，并在朝相反方向移动时减半数量，所以我们可以通过二进位检索让时间与log2(n)成正比而发现适当的位置。再次假设用户只需要在界面上面向每个点进行一次操作。那么操作需要移动到下一个体素便是2log2(3)，因为这一移动是二维的。然后总体的操作便是W=n2′2log2(3)′log2(n)=2n2log2(n)log2(3)。尽管我们将移动限制在一个界面上，但这却比之前的UI还糟糕，这主要归咎于用于推并拉动虚拟粘土的点击数。
在第四个界面中，用户将基于2D鼠标绕着界面移动，并像之前那样推/拉进/出点数。然而，粘土的界面将会有张力，所以推进/出一个点数将同时拖曳所有邻近的体素。结果便是界面将基于与你使用控制点和齿条定义曲线的方式那样进行雕刻。然后在W=2c2log2(n)log2(3)中，控制点数c便成为了雕塑的不规则函数，而不是体素的数量。对于高分辨率建模，n>>c，并且W=O(log2(n))。这是非常优秀的用户界面。
为了将认知工效学整合到W中，你也要计算玩家用于记住每个键盘快捷键和可点击图标的含义，并整合操作的衡量将显示信息转换到相关可用信息所需要的内存量。你同样也可以为内存检索时间添加一个条件。面向不同内存类型的内存检索时间是明确的;为了记住一列选择汇总的一个，时间便是K+an，这里的n是选择的数量而K和a则是常数。如果你不知道如何按比例分配认知条件让它们能够与非认知条件成比例，你可能会对它们进行分开概括。
理论上的界面效能
我们有可能计算用户界面与其理论上最有效果成比例的效能。信息理论呈现的是如何计算一系列数字或其它符号中呈现了多少信息，这需要考虑到当前的情境，历史，可能的符号的相关知识。如果你可以估算所有玩家移动的可能性，你便可以根据信息理论估算移动中所呈现的信息I。你的UI能够做得最好的情况便是让W呈现出与I一样的计算复杂性次序，也就意味着O(W)=O(I)。
I/W是对于你的界面效能的衡量;它至多不会超过O(1)。对于I的表达中的每个变量，它都会在W中有一个相同或更大的指数，所以我们能够更轻松地基于W/I进行思考，这是关于衡量你是如何糟糕地对待玩家。衡量I比衡量W更复杂;基于I你可以获得一个最大值。为了让W/I具有意义，它应该是一个最小值。
在带有许多单位的游戏中，你会发现在W这种，面对基于单位的用户界面，比起最大值，你的最小值将伴随着单位数更快速地增长。这是因为大多数情况下，许多单位都是在做着同样的事，并知道少部分玩家的单位正做着那些能让有技能的玩家精确地预测到剩下的单位在做什么的事。这与我们雕塑粘土的用户界面类似：雕塑界面上的大多数点都带有界面切线，其周边的点也是如此。要求你各个移动每个单位的界面相当于雕塑一个让你能够移动每个体素的界面。信息理论的使用让你能够估算I并知道你的UI所需要的真正维度，甚至当你找不到一种简单的方法去显现单位间的连接时。
关于W和I的计算我们将在另外一篇文章进行详细说明。你可以在可能性和信息力量的相关书籍上进行更深刻的了解。
总结
如今，比起玩家真正想要控制的，计算机总是会触发更多单位，并且这一数值还将继续以指数的方式增长着。这将导致玩家逐渐失去乐趣，并最终受挫。在一个优秀的用户界面设计中，玩家不应该控制超过7个游戏实体。为了做到这点，UI可能会让玩家控制一些更抽象的内容而不是屏幕上的单位。这便要求对象导向型开发者将代码对象作为抽象对象，而不仅仅是屏幕上的单位。UI也会给予玩家一个机会去指定离线行为，从而减少所需要的在线监管数量。
游戏开发者可以使用用户界面分析工具并计算包含于不同界面中的操作去评估其用户界面。他们还可以通过估算理论效能而确切地了解是否存在完善空间。游戏设计的最终目标是提高游戏的FPS，即每秒钟的乐趣。做到这点的最简单方式便是将同样的行动整合到更少的时间中，而这么做的最简单方法便是经常完善用户界面。