Usability in the Game World
Utilizing Norman's seven stages of action enables us as game
developers to make informed design decisions. Even in our simple Settings menu
example, we were able to use the stages to identify and regress several
interface issues.
Moreover, we've learned that failure to adequately address
all seven stages of action during the design process will ultimately hinder game
progress for the player.
But the applicability of
this system goes far beyond menu UI, and in fact can be used to evaluate most
or all of your game's in-world interactions.
By way of example, here's a brief
look at how addressing the seven stages can influence our design decisions in a
first-person action game:
In-world Action: Throw a Plasma Bomb
Stage 1:
Does
the player know he has plasma bombs, and that he can throw them? (Is it
displayed on the HUD? Is the HUD icon clear and understandable?)
Stage 2:
Does
the player understand whether this would be an opportune time to throw one? (Do
plasma bombs work well in close quarters? How about underwater? Does the targeting reticule change when it's hovering over a valid target?)
Stage 3:
Does
the player know which button to press to throw a bomb? (Was he told in a
tutorial but has since forgotten, and has his dog eaten the user's guide? If
so, does the game provide instructions on-demand?)
Stage 4:
Can
the player physically press the correct button while doing other important things
like moving and dodging? If it's a little kid on a big controller, can his tiny
fingers work the analog stick and hit the plasma bomb button at the same time?
Stage 5:
Is
there satisfactory feedback to indicate that a plasma bomb was indeed thrown? Can he see and/or
hear the bomb fly through the air? Even if it's dark, or in thick smoke? Did a HUD counter change?
If the
player is out of bombs then is there feedback to indicate why a bomb didn't
appear? An icon flashing on the HUD? His avatar groaning "damn,
out of plasma"?
Stage 6:
Did
the plasma bomb work? (Was there an explosion? Other effects? Do enemies visibly appear to have been injured? Did
it land in water and visibly fizzle out?)
Stage 7:
Was
the plasma bomb a successful
weapon to use under these circumstances? (Was it effective against this type of enemy? Did it bounce off a wall and end up injuring the
player? Was it a satisfying interaction?)
Piecing out each element in this game world
action further illustrates that Norman's psychology-based
approach has applicability far beyond the workings of his doors, ovens, and
clock radios.
It's a flexible and useful heuristic tool that can be applied to not
only UI and combat, but also to puzzles, boss fights, and nearly any other
interaction the player might have with your game.
|
I like to think in any game as I think in any software I use, the difference is that between those steps 2 or 4 there is something like "choosing the best tool and best way to accomplish your goal".
This is simple, I have an enemy, a weapon and a crosshair, and an input system such as a mouse, so I'm going to point the crosshair at the enemy while I'm carring the gun and then shoot. If the crosshair or the gun or my mouse doesn't respond well to my mind state that makes that action pure automatic as an extention of my own body actions, then I'll feel it, no matter the smalest jam that happens, I'll feel cheated. Same goes if I'm using and 6-axis and my enemy moves fast or takes good cover, then a simple action of aiming, that as a player I know I can do, just seems that I can't, so of course I'm gonna blame the input system.
Same goes for movement, jump, an things that seems simple in real life or in what the player is used to... "do these developers play soccer?! why my superstart soccer player cannot do a simple task that me and all my friends, and even my granda can do?!", the result is simple: "it sucks!", or in other words, player is being challenged by something that is out of the game's world.
Dead Space is an amazing example of showing the player all the information they need - without even showing it all the time. I like the way they used the floating menu to gather all the data the player may need to understand the history and to remember the main points of the controls. However... the game itself failures on letting the player change the control scheme, which is something I thought very problematic and annoying.
It's a truism throughout software development that the skills that allow some programmer to be very good at specifying object behaviors don't always translate into an ability to communicate effectively with other people. Ignoring this reality (sometimes because there's just no one else to do the job) is, I suspect, why we see problems like incomplete feedback (the programmer already knows what the control does) and confusing communication (such as rampant misspelling of words).
In other words, someone who's good at solving Stage 4 challenges in game development may not be equally talented at addressing game development challenges from Stages 1, 2, 3, 5, or 6.
So much for proofreading after a night of no sleep. ;)
I think that everyone on the development team should pay attention to those problems, but specially the game designer should know these points, because they have a great influence on the fun factor.
In this article, many great things are specified, even the reward, but I didn't find a part that explains how to produce fun and that's the most important part of a game. For sure, the reward needs to be fun, but it should be the same case for the mechanic used to perform the action and unfortunately there isn't much about that. If there was, I didn't feel it was enough for me.
I would love to hear more about your thoughts on the subject or read new articles ^^.
- Khris