The Interface Part I : Mapping the Player
by Martin Kremecek

Introduction

A game without a UI is like a car without a steering wheel, very unlikely to get much attention. UI design is one of the fundamentals, and luckily developers especially in recent times really try to innovate in this direction, with Black & White as one of the best examples. In this article I'll try to give some new views about what a UI is basically about, and give a few hints on how to achieve one that really incorporates the player into the worlds we create.

For the first Part of this series, I'll only talk about the Player to Game Interface, which defines how the player interacts with the game, not the information feedback provided by the game using the Game to Player Interface. The PGI has to map the thought input of the player to the game language, which is comprised of the game's manipulation rules, in a way that gives the player a feeling of familiarity and has a small conversion overhead. With this overhead I mean how a single action by the player gets converted to a single game action using the interface. It makes a difference if the player has to click his way through 3 menues or by using a single direct Click!But not only quantity plays a role. Basically clicking using the mouse pointer is a rather abstract action, and other forms of manipulation should be explored, with which I don't want to stress on joysticks or other devices, but rather remain with the standard PC setting of keyboard and mouse. The best example for manipulation diversity is now Black&White, where Peter Molyneux actually meets the above rules very elegantly. He uses a hand as a cursor ( aren't we used to manipulate things with that?). So the player moves by grabbing the landscape, slaps or carresses his creature and casts spells by drawing symbols. This really merges with what we as humans are used to. Image that instead of drawing the spell, you just would have to click on a GUI button co choose a spell, with the target location following right after, like in standard RPGs. But where would the fun remain? Basically the latter approach isn't too bad, an as long as the other ways of the interface would stay the same, B&W would be less creative, but still very playable. A problem would arise, if everything worked that way, so you would have to select your creature, then press on a "good" or "bad" button. If things get too similar in using the UI, they'll all be blurred together, and the special associations get lost, although the effects they create may be different ones.

Actions

Ultima Online appears to me as the best example for this. There are dozens of skills, but players don't really do different things, they just see different outcomes although the only difference is the location of the skill buttons, and maybe the type of object it gets applied to. Clicking on a button to chop wood, compared to clicking on a button to domesticate an animal would be comparable to name the first one allarch, and the second one allurch (whatever..). Now this is acceptable with two skills, but imagine all 20 actions were modifications of all rch (allorch, allirch, allmrch etc ). Pretty weird and difficult to remember which skill belongs to which word, isn't it? Imagine there was no text next to the skill buttons, and probably you'll soon stop playing the game. The button locations are different, but is location on the screen really comparable to the difference between chopping wood and petting an animal? I hope not, and I also hope that you agree that his way surely cannot be the most efficient.

But how could it be improved then? Let's try again to base the UI on the real world. Swinging an axe is the basic action that comes to my mind most immediately if I think about chopping wood, so why not let the player do some of the work? This is stupid you think? In my opinion this is less stupid in the long term than double clicking on trees, and it would also feel different from the other actions and my action actually really is more like doing the real work! But hold! I don't want to say that you should make things as real as possible, bundle an extra axe device with your game and let the player hit a piece of plastic wood (though this really is the trend in arcades, if we look at Bass-Fishing, Harley Davidson. Who knows, maybe TreeChopper would do well as a fitness machine, maybe a bit like Dance Dance Revolution..). I want to show that things can be abstracted in many different ways. A certain degree of realism is enough, depending also on the complexity of the game. Imagine UO players sitting in their rooms scrammed with dozens of different devices!

Language

But let's return to the language term. As many of us will probably know, some programming languages simply are better suited for certain applications than others, because they are shorter, faster, easier or whatever. The same things applies here. "Shortness" can be measured as the time needed for a player in average to do an action, and/or the spatial distance on the screen, but in any way it should be tried to minimize these functions, especially for those actions that are most frequently used by the player. Simplicity is often corellated with speed, because more UI actions simply need more time! So placing shortcuts, for letting the player redefine the UI at least a bit, to optimize it for his own purpose is recommendable (a positive point in UO!). Creating one that automatically adapts to the player's style still is a vision for the future, but still there would be a basic language needed for the computer to act on. So as tough as it seems, it will stay the designer's job for probably quite some more time!

The first step for your design is to really understand your game. This is the only absolute language you'll have, so you'd better be familiar with it. Anticipating what players are going to think is a classical problem. But as we tried before, using the real world is a good guarantee that many people might actually understand what you mean, since this is also usually used when two people meet, having foreign languages but a quite similar body and their shared environment. This way they then are able to gradually draw parallels between the two systems, although there may be things that cannot be directly translated, but only in a rather long and clumsy way. For example one language might not have a word for "huge", and it would need to be translated as "very very large". The first one surely is shorter, but it does not exist.. So what? Lets say your interface is the foreign language and the player speaks English. So in order to say huge he has to express this in longer ways. And since real world language is usually more elaborate than than the UI one, we should try to minimize the effect by guessing what word or sentence the player is most likely to use. If all people were used to say "very very huge", it would be strange if you used "huge" for this and actually invented a new word. This would create confusion at the beginning at least.

In order to reduce clumsyness for the player, using images instead of written language can be extremely helpful as long as aimages are easy and clear to understand. This is because if a player reads "tree", he first has to convert it to some sort of image to use it in comparison to your game. The probability that your game tree looks different to what the player expects is quite large, forcing him to remap his mind-tree to the actual game-tree, introducing unnecessary resistance, especially for beginner players. But again, don't just think that by using images always this job is done. Great care has to be taken of actions ( since they actually are not static! ), and they offer a high risk, since the used symbols are often ambiguous.Warhammer 40K ( an XCOM like strategy game) uses graphical buttons for quite everything and guess, many of them indeed are actions and I often really didn't guess the right way! So would animations be better? Well maybe if they wouldn't draw as much attention to themselves. But! What if the animation was only shown with the cursor over the button? This definitely would better things, but still I prefer a word like approach, because actions often manipulate many kinds of different objects, and using just one as example would be rather irritating. But a good example for use of symbols for actions is C&C with its small and fast interface. Sell and Repair both are actions, but both can be very well described using the symbols for money and a screwdriver, since selliing is practically allways associated with money, so: moneyl <-> trade <-> sell(buy), (offering just a small conflict at the beginning, which is very quickly resolved because of the description appearing above the mouse cursor!), while repair is something like this: screwdriver<->mechanic<->repair. But using symbols is allways a vulnerable way, with words being more absolute in ist meaning. A combination of both might serve the purpose well.

Resistance

Above I wrote about "resistance", and this basically is too a good way to express how a UI interacts with a player. It expresses the problems or conflicts the player meets when converting his thoughts to the game actions. If the thinks "left" for example and the player atually has to click right/press right, this is a conflict for the player to which he first needs to adapt. Some games use this consciously to add another twist to the game (eg. When collecting a special "bad" item), but generally a UI will be designed to have a harmonious relationship with the player. But conflicts can basically cannot be avoided in a game that is complex to a certain degree and interacts with a complexity of a human being! IT is always best to take yourself as model at the start, since you are much more human than any created image could possibly be in your head.

A way to optimize a given UI is to actually take a look at how the player has to perform the different actions of the game, by using a programming language for example. This way you are also able to see how mechanically/thinking intensive the game is, and where the biggest problems arise. If you have a working version of the game though, it is always best to just play it of course, and this phase might be skipped, except you want to take a very detailed look at what is really going on ( or should be going on ) inside the player.

Summary

All I can do now is offer a short summary and some hints to aid you on your quest:

As Einstein said: make it as simple as possible, but not simpler.
Meaning to create the language as close to the game but also as comfortable to the player as you can, while not generalizing things too much ( eg by putting buildings and units into the same build-list ).
Use real life as a basic model to give players familiarity.
Allow players to express their individuality by allowing UI refinements using shortcuts ( to spells in Baldur's Gate) and/or basic UI elements that can be freely used ( UO).
Differentiate the controls. This gives the players a "feeling" of your world.
Place things belonging together closer to each other.
Reduce the time/distance to frequently used objects and give them proper sizes ( this also decreases time and does not distract the player too much with fine tuning his mouse movements)
Do not tear the player completely away from the game with fullscreen interfaces ( especially in real time games!), since he loses complete control over the actions and will always be hectic to leave the menu again.

Conclusion

Well, these are at least some rules, but this merely scratches the surface into which it is best to dive on your own!

I hope you enjoyed this article a bit and are interested in reading Part II, in which I'll cover the Game to Player mapping of game outputs. Defining what data is needed and how it should best be converted. Hope you'll be with me then!

Discuss this article in the forums

Date this article was posted to GameDev.net: 5/26/2000
(Note that this date does not necessarily correspond to the date the article was written)

See Also:
Game Design