游戏设计师可能会认为，如果允许玩家控制所有单位，但不是必须控制所有单位，那么游戏世界就完美了。不幸的是，事实并非如此。在经济学中有一条法则叫作“Gresham’s Law of Money”，也叫作“劣币逐良币法则”。Gresham解释道，当一个国家使用两种货币，即具有固有价值的金属货币和不具有固有价值的纸币时，纸币会把金属货币驱逐出市场，直到所有人都只使用纸币。
Smalltalk（游戏邦注：为 Xerox PARC在1970年代所发展出来的一种使用功能表单驱动的高级程序语言；常与鼠标器合并使用）用户称对象为“objects”，称方法为“verbs”（动词）。自那以后，许多制作对象导向型程序的程序员都把“objects”解释为“noun”（名词）。我曾与其他程序员争论，因为他们认为游戏不是对象导向的，除非游戏中的物理对象在代码中是OO对象（面向对象）。当我表示，让游戏中的verbs成为代码中的objects，这样组织代码从而强制执行游戏的一致的物理学。他们回答道，“objects就是objects，verbs就是verbs。”至今，我们仍在根据游戏中的物理对象来组织游戏代码和UI。
Too Many Clicks! Unit-Based Interfaces Considered Harmful
by Phil Goetz
Computer games traditionally have a player control one or more units on the screen. In early games, each player controlled one unit. As CPU power grew, players controlled more and more units. Today, a player might have hundreds of units, each one of which they must control individually. The unit-based user interface (UI) is no longer sufficient. This article will suggest a different way of thinking about UIs, and will discuss how to compare one UI to another, or one UI to the theoretical maximally efficient UI, to tell if your game can be improved. I’ll use examples primarily from strategy games, but it applies to UIs for programs of all kinds.
Approaching a Thousand Clicks a Turn
My favorite game of all time is Civilization, in all its incarnations. When I introduce friends to the game, they’re enthusiastic for one or two thousand years – which, in Civ, means about a hundred turns. By then the cities, the units, and the waiting have multiplied so much that it becomes, for the novice, a chore more than a game.
Even for a Civ addict like me, the game isn’t much fun after about 1800. Too many clicks. I counted the clicks, mouse movements, and keystrokes that it took me to get through one move of Civilization III in the year 1848. Many hours later, when that turn was done, I’d counted 422 mouse clicks, 352 mouse movements, 290 key presses, 23 wheel scrolls, and 18 screen pans to scroll the screen. This was making full use of all the Civ shortcuts, automation, and group movements. I probably would have made twice as many movements if I hadn’t been counting.
You may wonder why I’m talking about Civ III, when Civ IV has been out for months. I never bought Civ IV. I’d been waiting and hoping for a more playable Civ. What finally arrived was a Civ that takes just as many clicks, but with a new animated 3D UI.
Don’t get me wrong – Civ IV has important new gameplay aspects. Firaxis did far better than companies who create some new units, artwork, and cut scenes, and call it a new version. But I didn’t stop playing Civ III because I was tired of the game, or because it wasn’t pretty enough. I stopped because it takes too long to play a game. Civ didn’t need a prettier interface – it needed a more efficient one.
Overclick isn’t limited to Civilization. Real-time strategy games will leave you with even worse carpal tunnel. That’s why I don’t play Warcraft or its descendants online. In terms of clicking skills, I’m over the hill. Strategy is irrelevant in today’s real-time strategy games when you’re playing against a fourteen-year-old who can click twice as fast as you.
The RTS user interface hasn’t improved since Total Annihilation (1997), which had more useful unit automation than many current games. Meanwhile, the number of objects our computers can control and animate has increased, and continues to increase, exponentially. The old UI model isn’t at the breaking point – it’s broken.
This article is about how to design a UI that lets players communicate their intent with fewer clicks. I’m not going to address UI ergonomics (physical ease of use) or cognitive ergonomics (issues such as eyestrain and human memory and processing requirements). The energetic reader should incorporate those as well into their UI evaluation, but it’s too complex for this short article.
The Rule of Seven
Strategy games typically place the user in the role of something like a battalion commander. But think about the job of a real battalion commander. He doesn’t sit watching a map and barking orders to each tank on the battlefield. In combat, he has a small number of people he gives direct orders to. A squad leader in the US Army leads about nine soldiers, with the help of two fire team leaders. A platoon leader typically commands 4 squad leaders plus 3-4 other staff. A company commander typically gives orders to four platoon leaders plus staff; a lieutenant colonel might command a battalion of four companies plus staff. And so on, up the chain of command.
This is no accident. It is a fundamental principle of military organization doctrine that a commander can effectively manage only a limited number of subordinates. The number of directly-reporting subordinates that a commander has is known as his span of control. The most efficient span of control is believed to be the same for a platoon leader as for a theatre commander. 19th-century European armies settled on seven as the maximum span of control, and that number hasn’t changed much since.
The rule of thumb in the US military today is that span of control should be from 5 to 7. A supervisor in FEMA is supposed to oversee no more than seven subordinates during a disaster-relief effort. According to US House Report 104-631, the average span of control across the entire US government bureaucracy in 1997 was seven. Not coincidentally, seven is also the number of items that the average person can keep in memory at the same time (Miller 1956). This is why phone numbers within an area code are seven digits.
This rule should apply to strategy game design as well. A player who is controlling more than seven entities can’t effectively supervise any one of them. (A corollary is that, if a turn takes a minute, and a player makes a move more than about once every 10 seconds, that player probably isn’t focused and isn’t getting an opportunity for the kind of deep, strategic thought that is supposed to be the source of enjoyment in a strategy game. Games that require a click per second are arcade games, regardless of their complexity.)
The seven subordinates that a field commander controls often include one or two who don’t actually act in combat, but who merely relay information to the commander. This means that different information displays (such as the city screen and the technology screen in Civ) count towards the seven.
There are complications to this rule. Take chess – each player controls 16 pieces, and must be aware of 16 enemy pieces. That’s why chess is so frustrating to a beginner. But chess experts can do it. Are they breaking the rule of seven?
Well, yes and no. Gaining expertise in chess doesn’t consist of learning to keep track of more and more pieces in your head. It involves learning to break board positions down into separate, familiar structures – a pawn structure, a castled king behind three pawns and a knight, a set of pieces exerting influence on the center squares – in order to bring the number of concepts down to a manageable number (say, oh, seven).
The span of control in the US military is intended to be such that a commander can command and supervise one level down (his subordinates), and keep track of everything happing two levels down (his subordinates’ subordinates). The chess player is responsible for two levels of control: first, choosing the subgoal for each of these structures (e.g., “control the center” or “break up his defensive pawn structure”); second, choosing a move to implement each subgoal, and choosing just one of those moves. Thus, it isn’t keeping track of all the chess pieces, but having to choose every move, that violates the rule of seven. If you want your game to play faster than chess, and still involve strategy, you must observe the rule of seven.
You Can’t Have Your Cake and Eat It Too
A game designer might think she can have the best of both worlds by making a game in which the player can control every unit, but doesn’t have to. This, unfortunately, is not so. There’s a rule in economics called Gresham’s Law of Money: Bad money drives out good money. Gresham explained why, when a country tries to use both metal coins that have real inherent value, and paper bills that don’t, the paper money drives the coins out of the marketplace, until everyone is using only paper money.
In gaming, bad players drive out good players. In roleplaying games, the bad roleplayers, who emphasize accumulating wealth and power over playing a role well, advance faster and eventually drive out the good roleplayers. In a game which allows control of individual units, adrenaline-filled 14-year-olds who can make three clicks a second will beat more thoughtful players who rely on the computer to implement their plans, because we’re still a long way from the day when a computer can control units better than a player.
There is a player demographic that enjoys click-fests and micromanagement, and it may be the same 14-year-old males that the game industry’s magazines, advertisements, and distribution channels are aimed at. Trying to step outside that familiar demographic is always hazardous. (I believe games won’t be mainstream until they’re sold at Borders; however, that’s a separate rant.) No producer would want to lose this market share, so it might be good to have individual unit control available as an option.
However, the market of players who do not enjoy carpal tunnel, which I suspect is much larger than the market of 14-year-old males, is not just underserved by today’s games; it is completely unserved. If the game is to also allow control of individual units, it must be a separate game option, and players should be able to set up multi-player games that disallow individual unit control.
By now, you’re probably questioning my sanity and the wisdom of the Gamasutra editors. Am I saying that strategy games should only allow a player to build seven units? Not at all. I am saying that the player shouldn’t control them all directly. We need to conceptualize an intervening level of control. It isn’t hard to do, but is hindered by a common misconception about object-oriented programming.
Objects Don’t Have To Be Objects
Smalltalk users called objects “objects”, and, what’s worse, they called methods “verbs”. Ever since, many object-oriented programmers have interpreted the word “object” as something like “noun”. I had arguments with other adventure programmers in the 1980s who insisted that a game wasn’t object-oriented unless the physical objects in the game were OO objects in the code. When I suggested organizing the code so that verbs in the game were objects in the code, thus enforcing a consistent physics on the game, they said, “Objects are objects; verbs are verbs.” To this day, we organize our game code, and the user interface, around the physical objects in the game.
There’s no need to do so. Objects, in the OO sense, can be any abstraction you choose. In the case of Civ III, an object could be a military action or an engineering project. Consider Figure 1. In this figure, my civilization had recently developed the technology for railroads. I was attempting to construct a railway line connecting the north end to the south end of my civilization.
With the unit-centered interface of Civ III, this requires clicking on individual worker units and assigning them to individual sections of the railway line. Each worker must be assigned to a short section of the line, because if you start one unit from up north toward the south, and another unit from the south toward the north, they compute the path they will follow at the beginning of their assignment, and don’t adjust it to account for the work done in the meantime by other units – leading to a multitude of non-overlapping parallel railway lines, and armies that can’t get to your borders before you’re overrun by Roman legions.
I needed to assign about a hundred workers to building the railway line in order to get it built before being overrun. For each worker, I had to click on it once to bring it into focus; then type ‘g’ to begin a movement, scroll to its starting point on the railway line, and click again. Later, when it reached that point, I would have to type “ctrl-r” to build a railroad, scroll to the end of that unit’s portion of the railway, and click again. That’s three mouse movements, three keystrokes, and three mouse clicks per unit. I tried to keep the workers in groups of three, although this was possible only about half the time. So it probably took me 600 clicks, keystrokes, and scrolls to build that railway.
Imagine if I’d been able to say that I wanted to build a railroad, click on its start, and click on its end. The computer would then have directed workers, as they became available, to work on sections of the railway. The entire railroad could have been constructed with the same amount of supervision that it took me to direct one worker.
The railway was needed to move troops to my borders to defend against the Romans. Again, each new unit built had to be individually routed to some point along the border to defend. Imagine how much less pain my wrists would be in if I could simply define the border, cities, or points to defend, to which the computer would direct surplus troops as they were built. But to implement this cleanly, the programmers would have to have conceived of railroads and borders as first-class objects.(source:gamasutra)