Contents
Designing Games That Don't Suck
 
 
Printer-Friendly VersionPrinter-Friendly Version
 
Latest News
spacer View All spacer
 
November 22, 2009
 
Video Game Watchdog National Institute On Media And The Family Shutting Down [11]
 
Modern Warfare 2 Infinity Ward's 'Most Successful PC Version' Yet [12]
 
New Tech, Design Details Of Project Natal To Emerge At Gamefest In February
spacer
Latest Jobs
spacer View All     Post a Job     RSS spacer
 
November 22, 2009
 
Trion Redwood City
Sr. Evnironment Modeler
 
Trion Redwood City
Sr. Environment Artist
 
Sucker Punch Productions
3D Environment Artist
 
Sucker Punch Productions
Network Programmer
 
Sucker Punch Productions
Character Artist
 
Sucker Punch Productions
Texture Artist
 
Monolith Productions
Sr. Software Engineer, Engine - Monolith Productions - #113767
 
Sony Online Entertainment
Brand Manager
spacer
Latest Features
spacer View All spacer
 
November 22, 2009
 
arrow Upping The Craft: Susan O'Connor On Games Writing [6]
 
arrow Small Developers: Minimizing Risks in Large Productions - Part II [7]
 
arrow iPhone Piracy: The Inside Story [48]
 
arrow And Yet It Grows: Analyzing the Size and Growth of the European Game Market [5]
 
arrow NPD: Behind the Numbers, October 2009 [13]
 
arrow Reflecting On Uncharted 2: How They Did It [5]
 
arrow Sponsored Feature: Rasterization on Larrabee -- Adaptive Rasterization Helps Boost Efficiency
 
arrow Postmortem: Wadjet Eye's The Blackwell Convergence [2]
spacer
Latest Blogs
spacer View All     Post     RSS spacer
 
November 22, 2009
 
Time Fcuk [1]
 
Accepting the Inherent Value of Games
 
Planckogenesis, Part II: Song Structure & Gravy Train [1]
spacer
About
spacer News Director:
Leigh Alexander
Features Director:
Christian Nutt
Editor At Large:
Chris Remo
Advertising:
John 'Malik' Watson
Recruitment/Education:
Gina Gross
 
Features
  Designing Games That Don't Suck
by Jason Bay
11 comments
Share RSS
 
 
July 8, 2009 Article Start Previous Page 5 of 5
 

In the Head

"Knowledge in the head" implies that the game world doesn't actively or persistently give players the information necessary to perform an action. Instead they're expected to intuitively know, remember, or figure out how to do the task without help or reminders.

In a game's GUI, you might be able to leverage the player's preexisting knowledge by:

Advertisement
  • Following established standards that the player will recognize, such as drop-down lists and scroll bars
  • Giving it an appearance and behavior of something from the real world that a typical user would already be familiar with, like a button or a folder tab
  • Labeling controls with familiar pictures/icons to jog his memory

In the game world itself, it's dangerous to rely on your players' preexisting knowledge; if he doesn't know what you expect him to know then he'll have trouble executing core tasks.

Many games "pre-load" the player's head with necessary information during a tutorial phase, and that's a good start, but problems arise if the player forgets what you've told him or else skips through the tutorial without paying much attention, which unfortunately seems to be commonplace.

Many contemporary games are so complex that players can't memorize all the necessary information until they've logged many hours of play.

You can also frustrate players if you require them to frequently retain new pieces of critical knowledge that are difficult or impossible to re-learn it if they happen to forget:

  • "Yeah the scientist told me the combination to that blast door. But I haven't played since last June, and now I've forgotten what he'd said!"
  • "Do I really have to click-click-click into the Unit Stats screen just to get a reminder about this tank's attack rating?"
  • "That boss monster just killed me a dozen times in a row. This sucks -- what am I doing wrong?"

In order to cope with these problems, we should provide accessible, abundant knowledge in the game world to alleviate the need to memorize, or we should provide reminders at key points to spark the player's memory. Some ideas that could help with the above examples might be:

  • Provide a way to store important information that the NPCs have given to the player (a Notes screen, a Quests menu, etc.)
  • Provide a popup with a visual stats summary when the player hovers his cursor over a unit, or offer a sidebar to show a stat overview for all units currently on-screen
  • Detect when the player is repeatedly failing a task, and then offer a helpful hint or make existing hints even more obvious

Conclusion

For every development cycle, game teams spend a lot of time revising and re-revising in-game actions to make them easier for players to understand and execute; often, the problems have stemmed from users not having the knowledge necessary to successfully perform a desired action.

If the developers can make an effort to bake as much knowledge as possible into the game world -- especially knowledge that facilitates the completion of Norman's Seven Stages of Action -- you'll find that players navigate more easily and get confused and frustrated far less often.

With these simple design tools, we can build more intuitive interactions and help our games go from "this sucks" to "hell yeah," all the time, every time.

 
Article Start Previous Page 5 of 5
 
Comments

Luis Guimarães
profile image
When you're trying to make imersivity and comfort for the player to focus on the game, it's needed skills and the pure sense of joy, everything that is not a challenge shall not be one, it's just distraction, distraction of anything out of the game's world...

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.

Glenn Storm
profile image
Great article, Jason. Usability analysis is a good tool for bulletproofing interactive systems. This is a fine summary of how that analysis applies to game design and I think it gives some insight into how usability might even play a role in game play. (i.e., purposely omitting information to a particular stage of action) Thanks again!

Ian Fisch
profile image
Great article and great examples.

Ivan Kanev
profile image
Excellent reading, thanks for sharing your thoughts and experience. =]

Stefan Durmek
profile image
Yea, good article with many good points. Thanks!

André Martins
profile image
Very interesting article and nice examples!

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.

Bart Stewart
profile image
In a practical sense, what this very good article reminds me of most is a simple rule of thumb: never assign a programmer to create any element of a user interface if anyone else is available.

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.

Ichiro Lambe
profile image
I recognize the character and setup screen from our 12 title, The Wonderful End of the World. :) But I wasn't sure of the audio setup screenshot is meant to reflect good or bad practices?

Ichiro Lambe
profile image
That should read "12th title" and "...wasn't sure if the audio..."

So much for proofreading after a night of no sleep. ;)

Theo Tanaka
profile image
Great article, I really liked the last part where you discuss about giving hints to the player about what he has to do, like a notes screen, quest log. Those are things that when implemented poorly make me get stuck in games that I haven't touched in a while. That happened a lot in old RPGs, and I always had to look for some FAQ to find which part of the game I was in. Also, hints at boss battles should always be implemented, specially if the boss needs an uncommon strategy. I remember getting stuck at boss battles that didn't make very clear what I was supposed to hit or do.
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.

Christian Philippe Guay
profile image
It's clearly a great and useful article. However, I think it could be confusing, because it also talks about graphics, sounds, etc. It is very useful to understand how an action is performed, but games are also about any kind of interactivity and that goes so far beyond just "the action".

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



none
 
Comment:
 


Submit Comment