|
The Interface Part II: Feeding the Player
As the previous article was about how the player should be able to interact with the game, this part covers how the game talks back to the player, feeding him with the necessary information. Differently to what one is used to thinking, the Output Interface (OI) is not just the special interface symbols like bars, numbers, and pictures of all kinds, but also the game graphics themselves, and the better one weaves his OI into the actual game, the less the player will be reminded that there is another layer of abstraction between him and the game world. But nevertheless, additional information, especially in more complex games like strategy titles, may be required to give the player a better overview of events and current stats. Now in what cases are which approaches preferred? This depends on how homogeneously the data can be incorporated into the game environment, as information needs to be attached to some object carrying it. It would rarely make sense to show something like a graph directly on a building, monitoring its production for example (it would seem artificial wouldn’t it? Who gves information to the enemy for free?). Instead, showing the damage directly on buildings (standard in RTS games now, though only roughly implemented most of the time) gives the player all the data he needs to make decisions, since usually people don’t look exactly at the hitpoints but at the colors, thirds or fourths of the bar to determine when to repair a building. What I would like to introduce now is the expression "observer" to describe the focus of the player, the type of data he is most interested in acquiring at the moment. An observer really is like glasses with a special kind of color through which he perceives the world, a theory of the world that describes certain aspects, filtering unnecessary information (like sunglasses filter UV-rays, or camera filters filter certain colors). A good example of observers is in SimCity, where you have different maps showing crime, pollution, population density, etc., or in SC2000 the waterpipe layer. Showing all the information at once would surely overwhelm practically every human being (who cares about exceptions here?). There is a feature in the game Settlers that is a kind of "automatic" observer that can be switched off though, that shows players the maximum size of a building on a particular spot of land. I found this really useful as it saves quite some time searching the land with the cursor looking for an appropriate place. This is only a weak kind of an automatic observer, as it doesn‘t make any real assumptions about the player, as he explicitly indicates that he wants to build something and the behaviour is hard-coded. Fuzzy observers reach into the "intelligent interface" field that should anticipate players' needs and preferences to a certain degree and make a proper choice for visualization and type of data. One way I imagine achieving this is through the use of specialised intelligent agents that learn what the player generally wants. Think of some little helpers (like a Zelda fairy for example) that the player tells what main type of information he wants, with the fairy then flying around and retrieving data from objects which make sense to be inspected in ways of its observer type. While this does not have to be really "intelligent" behaviour and can be hardcoded with intelligently chosen rules, an interesting approach would be the use of emergence (complex behaviour through interaction of simple rules) under the belt of one single agent, where individual particles (I call them ISONS for now) with certain interests compete with others to deliver information from a certain object to the main agent. If only one unit, for example, is visible, there is no struggle, but as soon as they split there is fierce competition. In the beginning all the types of particles with certain rules occur in the same amount, but as the player prefers a certain unit by selecting one, the "winner agents" could reproduce and generate new and maybe slightly modified child agents, with its kind now having a greater share in the ISON population. So genetic algorithms could be used to generate an adaptive system. No kind of agent should go extinct though since if the preference of the player changes, the system may need to readapt to a previously almost ignored type of ISON. Of course, more fairies can be used, all having different base-observers, for buildings, own units, enemy units or resources (and of course sub-observers like health/repair state, production, experience etc). If one lets the player choose the number of agents used, he himself determines how much help he wants for retrieving data, since this may vary greatly, as some people may get distracted too much or simply think they don’t need this. The agents don’t have to be visible (also an option for the player maybe?), but highly translucent, like ghosts from another world, so people should get used to them quickly. Actually Miyamoto san already used a similar approach in Zelda, although only in a very simple manner, with the fairy flying to objects and characters, indicating their presence. But now let's get back to a less futuristic subject, that is, back to interfaces we all are used to. As stated, incorporating the OI directly into the game is highly effective. If The Sims didn't have their gestures, they’d be a lot less interesting to watch. In Black&White (yes, that one again...) there is no balance bar showing how good or evil you are, but your creature’s look and behaviour directly reflect this in an interesting and directly comprehensible way. Whenever this is not easily achievable, one has to step back to good old UI elements, although simple bars should become less of a standard and be replaced by symbols reflecting the feeling of the game in a better way wherever this is possible. Of course there are occasions where bars make better sense to most people because they are used to them, or because creating another graphical representation is just not practical, especially when precision is needed or data is analogous. A good example for this occurs in a Settlers-style game, where you have to show a Storage/Capacity relationship. As every unit here counts (so the detail is needed), and pictorial representation is either not space efficient (when showing all details in graphical form), or not accurate enough (when only changing images for certain percentages for example) except when the maximum storage is small enough, a bar represents a useful way to show the relationship with a relatively fine granularity (except the relationship between size and maximum capacity is too large..). It is necessary to deliver at least absolute values for wares currently stored, since computation of the real value according to the current relation is a rather inaccurate and a probably seldomly executed task by the player! (what do you have computers for...) In Soul Reaver for example you see a special kind of bar, which is an energy spiral that gets filled and is made rounder and larger throughout the game, while in Zelda you have hearts, giving greater abstraction but also less granularity. This whole thing of course (as actually quite anything related to game design!) is a matter of deeper psychology. If you define some smallest packages, like the hearts, people expect you to operate on a rather whole basis on them, and not on too small parts of them (like 8ths or 16ths). Even 4ths of a heart is rather strange, as even the form of the heart- being split into two halves- has a (for the human brain) rather clear cut in the middle, and so one halve of a heart is rather acceptable (it’s bad to have a broken heart, isn’t it?). Imagine having 5 separate hearts that have pixel-accurate health values; now how do you feel about an enemy causing damage of 2 pixels of your heart? Very accurate isn’t it? Well not in the sense of proper I think, as no heart of ours is made of pixels (but halves I think are a good cut....). Nowadays, written language is mainly part of the output interface, rather than the input interface (except for most option-menus, where enough space is available and immediate clarity is rather preferred, because the player, especially when first entering from the real world, is not yet immersed into the game and would need to interpret the more abstractly given image data relatively to it, while written language here is rather clear). Sprite properties like names or events (at least the more detailed description, not just the event type) are best displayed in text, since names mainly cannot be easily (and clearly!) translated into other forms, without the player having to learn the new language, or more complicated happenings have to be described, with language being optimized and best known for this! We scratched the topic of the options-menu, so why not stick to it for a bit now! As this is the entry point for the player into your world, this needs to be easy to understand for everyone without any prior knowledge of the game universe on one hand, and give a good introduction to your world so the player can become comfortable with the new environment on the other. This can probably be achieved by using key elements of the game in the menu, like Mushrooms for a game where players have to guard them in a defender style game, or even use some important in-game feature (shooting maybe for the likes of Deer Hunter) to let the brain grasp what is going to await it out there (in the real virtual world, where life is hard and dangerous...) The principle to get as close to what the player will probably associate with the displayed information as possible is still in charge for the output interface. For example Heart->Health is surely a more direct chain than RedBar ->Blood -> Health, though the latter is still better than a blue bar for example, except maybe for the high nobility.... Also the position of the elements on the screen is crucial, and this also needs to take account of the Input Interface, as space is shared with input elements most of the time. And again here, the closer the logical link between two items, the closer together they should be placed in order to reduce the eye travel of the player (similar to the mouse travel of the last article). Care must be taken, though, not to overwhelm the player with information at a certain location. Many rules of the first article are still intact here and can be applied also to output elements. Data which is frequently needed should have the highest priority, of course. In Diablo it is Health and Mana (the weapon type is also seen in the game environment). In Zelda you also have the different items assigned to certain buttons (so people don't have to look the current setting up all the time, since is often changes) in addition to the ever-important health. What is seldom spoken about when talking about UIs is sound as a tool to inform the player. In some games a (sometimes a bit annoying) beeping informs the player of a risky health state, and it actually really motivates (at least me) to regain energy again, since I really want to relieve my ears of it!! Dungeon Keeper informs you of important events using a voice and you are able to hear the battle cries of fighting creatures. Dynamic music to reflect the current atmosphere is a more complicated field but could be valuable not just to inform but invoke a proper feeling or awareness in the player, like instincts creeping up inside your mind. Creating feelings was one of Doom's strengths. In a dark room, for example, where you only hear the groaning of some devilish creatures, this gives additional information, but in a way that (in some people...) invokes a fear of death. Now, sound is often more difficult to separate from the actual game than visuals, and is already better integrated into the environment as sounds usually are produced by in-game happenings rather than an artificial user interface (except for clicks when pressing a button). This would also be an addition to an Input UI to help discern the buttons and create a different feeling. One could even create a game with almost sound only output, and only the mouse cursor displayed. This could be used to increase the sensitivity to certain patterns or frequencies, when used in combination with a maze game, for example, where the whole screen is black and the player has to perform tasks. Maybe if you remember the child-game where one has to find something, and the other person only helps by telling temperature (hot, worm, mild, cold etc). Game system theoretically spoken, an interface is always needed to bridge the incompatibility of two systems. As we humans cannot directly interact with the electric impulses of computers (I guess I should skip this experiment..), we need additional peripherals that help us map our inputs into something the (asocial!) computer thing can grasp. Further, if we want to influence software, we have to make use of another interface, but this time on a software basis (ah, a higher layer!). So for every level we have to cross, we need some way to bridge the communication gap. In the other direction, the layers in the reverse order are the same, but with different rules (software) or peripherals (hardware like the monitor, sound device, etc.). If you wonder what the hell I’m really talking about, I have to point to a future article covering General Game System Theory, which may be some more time ahead, as this subject is quite a complicated one! Nevertheless I’ll try to write about some other things to bridge the gap (though this is not interface related..) until this paper arrives. Of course it would be funny to write about the use of interface-hardware, but for reasons of applicability I think I’ll cut that just for now... Well then, good luck again in the real world; how about trying some real human interfaces again? ( umm well, is this some kind of language and body? :) Martin Kremecek aka Kralizec Please send comments and suggestions to: krale@teleweb.at! Discuss this article in the forums
See Also: © 1999-2011 Gamedev.net. All rights reserved. Terms of Use Privacy Policy
|