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