游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

从点击操作看基于单位的UI设计问题(下)

发布时间:2013-12-02 15:01:52 Tags:,,,,

作者:Phil Goetz

离线vs.在线控制

指挥官之所以能够命令7名下属的一部分原因是预先准备。他事先设定好了任何行动的情节,并通过在他的军队行动中命令不同情节间的转变而实现快速且巨大的改变。他的服务分支带有一个标准的战术库,即基于团队水平区别他可以在行动过程中用于向下属解释自己的目的。他的下属面对着交战规则去判断如何对各种类型的敌人以及非战斗式行动作出回应。他可以事先将这些规则带进战斗中。他带有许多野外演习,在每次演习后,他会告诉下属他们哪些做对了而哪些则做错了,而他的长官也将对他的表现做出分析。这便减少了战斗中所需要的直接监管的分量。(请点击此处阅读本文上篇

如果你使用统一的形式去设计游戏AI,如基于规则的系统或有限状态自动装置,你便可以将其作为指导玩家单位的另一种方式而面向他们开启。在真正的军事野战游戏模拟器(如JSAF或OneSAF)中,面向半自动单位创造交战规则是必要的。实际上,SAF可以代表“半自动化兵力,”这是能够提供非常复杂的任务和交战规则的单位,所以操作员便能够监管它们并且不会过多进行干涉,同时还能为真正控制每个对立单位提供现实的培训环境。

quake(from openpandora)

quake(from openpandora)

有些游戏,像《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。你有大小n n n的体素数组,每个体素是可以打开或关闭的。我们将考虑四个可能的用户界面。在第一个界面中,用户想要打开每个体素坐标轴中的用户类型。用于明确从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,即每秒钟的乐趣。做到这点的最简单方式便是将同样的行动整合到更少的时间中,而这么做的最简单方法便是经常完善用户界面。

本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

Too Many Clicks! Unit-Based Interfaces Considered Harmful

by Phil Goetz

Off-Line Vs. On-Line Control

Part of the reason that a commander can get by with commanding only seven subordinates is prior preparation. He has drawn up scenarios in advance of any action, and can cause a quick and dramatic change in his battalion’s actions by ordering a switch from one scenario to another. His service branch has a standard library of tactics, from the squad level on up, which he can use during an action to explain his intent to his subordinates. His subordinates have rules of engagement to help them decide how to respond to a wide variety of enemy and non-combatant actions without his intervention. He can add to these rules prior to entering combat. He has many field exercises, and after each one, he tells his subordinates what they did right and wrong, and his superior tells him what he did right and wrong. This reduces the amount of direct supervision needed in combat.

If you design your game AI using a uniform formalism, such as a rule-based system or finite-state automata, you can open it up to your players as another way of directing their units. Creating rules of engagement for semi-autonomous units is considered necessary in real military wargame simulators such as JSAF or OneSAF. SAF, in fact, stands for “semi-automated forces,” which are units that can be given fairly sophisticated missions and rules of engagement, so that an operator can supervise many of them and intervene as little as possible, while still providing a realistic training environment for the real humans controlling each of the opposing units.

Some games, like Quake, allow players access to the AI to program enemies; others, descended from Robotwar, give players units that must be completely programmed and that cannot be directed during gameplay. None provide an interface for semi-automated forces. Providing two user interfaces – one to be used off-line to provide rules of engagement, and another to be used on-line – could reduce the stress of handling individual units.

User Interface Profiling

To detect areas where your user interface is inefficient, you can play-test your game with a user-interface profiler. A UI profiler is like a code profiler, but instead of reporting CPU cycles, it reports user interface events. It should show you exactly how many clicks, keypresses, and mouse moves the player made within each part of your code. User interface profilers can present more sophisticated information, such as graphs showing the sequences of actions users took (Ivory & Hearst 2001).

You may be able to use your IDE’s profiler to count I/O events or function calls, but this won’t usually tell you what the player spends most of her time doing. You can get more information if you roll your own UI profiler by having your code call a routine to report UI events.

If the developers of Civ III had used a UI profiler, they would have found an inordinate number of clicks and keystrokes being used in the negotiation portion of the game. This would have revealed a bug in the game – a missing scrollbar in the city-selection menu – as well as the need for the game to recommend a minimally acceptable number of gold pieces to offer in trade, rather than making the user conduct a binary search to find it. These two tasks accounted for over a hundred of the UI events in my count.

To compare different potential UIs, you need a way of keeping score. Going back to my Civ III UI counts, I can come up with a total UI score by assigning a point value to each type of UI action. How you assign points depends on what you want to measure. For an arcade game, speed might be the primary criterion, and so you might count a mouse click as being nearly as fast as a keystroke – faster, if the user is already using the mouse anyway.

For a game such as Civ, which takes hours for a single game, you should weigh wear and tear on the player more heavily. Clicking a mouse button takes more than an order of magnitude more force than pressing a key, and uses the same finger each time, so that it causes a great deal more stress to ligaments in the wrist. (Pain that people blame on typing is usually caused by mouse use.) So I’ll count each mouse movement and keystroke as 1 UI point; each mouse click as 3 UI points; each wheel scroll as 6 UI points; and each mouse pan (scrolling the map) as 9 UI points. This gives a total of 2208 UI points for the turn. Different UIs can then be compared by score.

A UI profiler can be used to evaluate and refine a UI that’s already been built. With a little math, though, you can evaluate a UI before writing any code. I’ll touch briefly on that next.

Work calculations

You can compute the work W that a player must do to specify a move using your user interface. If you measure W in terms of game variables, such as the size of the gameplay area and the number of player units, you can then compare different possible user interfaces, even if you can only estimate W.

For an example, consider a UI for sculpting virtual clay. You have a voxel array of size n′n′n, and each voxel can be on or off. We’ll consider four possible user interfaces.
In the first interface, the user types in the coordinates of each voxel that she wants turned on. The number of keystrokes it takes to specify a number from 1 to n is proportional to log2(n), so this takes work proportional to 3log2(n) to specify each on-voxel. (From now on, I’ll drop the phrase “proportional to” and write W=f(x), with the understanding that it means W=O(f(x)).) If we suppose the artist will efficiently specify only a surface, and not fill in the entire inside of the sculpture, then the total work will be W=3n2log(n). (The size of the surface is proportional to n2.)

In the second user interface, the user chooses a point in three-space with a three-dimensional mouse (such as 3DConnexion’s Spaceball), and clicks the mouse to toggle its on/off state. The work needed to go to a particular point in 3-space is then the combination of 3 movements; each movement is on an axis ranging from 1 to n, with (let’s suppose) an average value of n/2. This seems as if it would then take work W=n5/8 to create a sculpture. However, let’s suppose that after turning on one voxel, the user moves to one of the 26 neighboring voxels. We will say that this takes work proportional to the information needed to specify one choice out of 26, which is log2(26). We’ll approximate it as log2(33=27), because the constant 3 in both this and in our previous value for W come from the three-dimensional nature of the sculpture. The total work is then W=3n2log2(3). This interface looks like an improvement over the first one.

In our third interface, we’ll start the user off with a sphere of clay of about the same volume as the desired sculpture, and the user will use an ordinary 2D mouse to move a cursor around on the surface of the clay, and click the left button to push the voxel under the cursor down (perpendicular to the surface), and the right button down to pull it up. We’ll use an accelerating push/pull interface which states that the number of voxels pushed or pulled doubles when the clay is moved in the same direction as the last click, and halves when moves in the opposite direction, so that the proper position can be found with a binary search taking time proportional to log2(n). Suppose again the user only needs to work each point on the surface once. The work needed to move to the next voxel is 2log2(3), because this movement is in 2 dimensions. The total work is then W = n2 ′ 2log2(3) ′ log2(n) = 2n2log2(n)log2(3). This is worse than the previous UI, even though we’re restricting movement to be on a surface, because of the number of clicks that it takes to push and pull the virtual clay.

In our fourth interface, the user will move around the surface with a 2D mouse, and push and pull points in and out as before. However, the surface of the clay will have tension, so that pushing a point in or out will drag all the neighboring voxels along. The result is that a surface can be sculpted in a way similar to the way you can define a curve using control points and a spline. Then W = 2c2log2(n)log2(3), where c, the number of control points, is now a function of the irregularity of the sculpture, not of the number of voxels. For very high-resolution modeling, n>>c, and W = O(log2(n)). This is a vastly superior user interface.

To incorporate cognitive ergonomics into W, you would also count the amount of memory the player needs to remember the meaning of each keyboard shortcut, clickable icon, etc., and incorporate a measure of the work done to convert displayed information into relevant usable information (this is the tricky part). You could also add a term for memory retrieval time. Retrieval time estimates for different types of memories are given in (Anderson 1974); for remembering one of a list of options (say, possible commands for a unit), the time is K+an, where n is the number of options and K and a are constants. Cognitive terms may be summed separately if you don’t how to scale them so as to be comparable with the non-cognitive terms.

Theoretical Interface Efficiency

It is possible, although usually difficult, to compute how efficient a user interface is relative to its theoretical optimum. Information theory shows how to compute how much information is present in a series of numbers or other symbols, given the current situation, the history, and knowledge of what symbols are likely. If you can estimate the probabilities of all of the possible player moves, you can estimate the information I that is present, according to information theory, in a move. The best your UI can possibly do is for W to be of the same order of computational complexity as I, meaning that O(W) = O(I).

I/W is a measure of the efficiency of your interface; it can be at most O(1). For every variable in the expression for I, it will have the same or a larger exponent in W, so it is easier to think in terms of W/I, which is a measure of how badly you abuse your players. Estimating I is much harder than estimating W; you can often obtain only an upper bound on I. In order for W/I to be meaningful, then, it should be a lower bound.

What you find, in a game with many units, is that for unit-based user interfaces, your lower bound on W grows much faster with the number of units than your upper bound on I does. This is because, most of the time, a lot of the units do pretty much the same thing, and knowing what a small fraction of a player’s units are doing would enable a skilled player to predict with good accuracy what the rest of their units are doing. This is exactly analogous to our user interface for sculpting clay: Most of the points on the surface of the sculpture have a surface tangent almost the same as do the points near them. An interface that requires you to move every unit individually is the equivalent of a sculpting interface that makes you move every voxel. The use of information theory allows you to calculate I, and learn the true dimensionality required of your UI, even when you don’t have a simple way to visualize the connection between the units in play.

To explain how to compute W and I in general would take another article. You can figure it out from a book on probability and information theory. A good primer is the book version of the 1949 paper that defined information theory, The Mathematical Theory of Communication, reprinted in 1998 by the University of Illinois Press. In difficult cases, I can be estimated by a combination of theory, and statistics gathered during playtesting.

Summary

Computers can now animate more units than any player could reasonably want to control, and the number will continue to increase exponentially. This leads to player frustration rather than fun. In a good user interface design, no player should control more than seven game entities. To enable this, the UI may let the player control something more abstract than an on-screen unit. This requires object-oriented developers to think of code objects as abstractions beyond the mere units on the screen. The UI may also give the player a chance to specify behaviors off-line in order to reduce the amount of on-line supervision needed.

Game developers can evaluate their user interfaces using a user-interface profiling tool, and by computing the work involved in different interfaces. They can even estimate their theoretical efficiencies, to know for sure whether there’s room for improvement. The ultimate goal of game design is to increase the game’s FPS – fun per second. The easiest way to do that is to pack the same action into fewer seconds, and the easiest way to do that is usually to improve the user interface.(source:gamasutra)


上一篇:

下一篇: