Thursday 24 August 2006

Too Many Clicks Unit-Based Interfaces Considered Harmful

By Philip Goetz

This article frm Gamasutra looks at the number of clicks, mouse movement etc in Civilization. While it is about user interface design, there are some lessons we can learn in terms of designing educational games. First, here are some extracts from the article:

Approaching a Thousand Clicks a Turn

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.

The Rule of Seven
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.

Hence, one of the problem identified by Goetz is the "unit control" available in Civilization. A player needs to set/control every aspect of the game play for each turn - explaining why there is a thousand clicks in a turn.

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. ... 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.

Here is the first lesson I have learnt. If we are to design educational games, we must understand what we are trying to achieve and avoid options which attract different game plays resulting not achieving learning objectives.

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.

Here is a second lesson I have learnt. If game playing needs offline mode to prepare alternate strategy, a good education game should be asynchronous to allow learners time and opportunities both to learn (research, reflect, discuss,...) the strategies and to implement the newly acquired strategy.

The rest of the article goes into some technical details of designing UI. Please read at your leisure.

No comments: