|
By Philip Goetz
Gamasutra
August 23, 2006
|
|
 Features
Too Many Clicks! Unit-Based Interfaces Considered Harmful
 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.
|
|
|
|
|
Previous