This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Unworkable Interface Elements (e.g. Invisible Crosshairs)
Santiago also proposed another TDC: crosshairs that you can’t even see. He said, “Most games allow you to decide if you want crosshairs or not, and some of them even offer you different crosshairs to choose. But some games paint them translucently or in a color that gets confused with the background. In the worst case you end up not knowing where you’re shooting. I’ve chosen to use crosshairs, so please make them clear!
“Half-Life Opposing Force uses translucent green crosshairs, one different for each weapon. Some of them are so dimmed that they are difficult to see, but then you turn on night vision (and some parts of the game can’t be completed without it) and it turns all your screen green... including your crosshair and all information, which get lost in the chaos.”
This sounds to me like a testing problem. Unfortunately, most game testers are not the right people to correct problems with a game’s usability. They know every detail of the game inside and out. They know exactly what’s going to happen next and where to shoot. They don’t need crosshairs… or mini-maps, or advisor characters, or easy modes, or, well, any of the features that make a game more playable to someone starting it up for the first time. The testers never even noticed that the crosshairs were useless… but somebody should have.
I heard a great lecture last year from Melissa Federoff, who wrote a seminal thesis on usability for games and, until recently, did game usability research at Microsoft Game Studios. She had some funny tales to tell of designers watching new players try to get through a level in some game or another. Half the time the players ended up going down a blind alley and falling into a pit. The level designers were baffled. “Why do they keep doing that?” they asked. Melissa had to suppress the urge to scream, “Because they weren’t the ones who built the level, you moron! They don’t already know what’s in it and unlike you they haven’t played it 10,000 times!”
OK, I exaggerate; Melissa is much too professional to call a level designer a moron. She probably reserves that for user interface designers who don’t provide any way to reconfigure the input devices. But when you’re testing a game, you have to get someone to look at it who’s never seen it before. Then you have to pay attention to what they say and act on it.
Speaking of reconfiguring input devices, Ben Ashley writes in to complain about…
I already mentioned bad configuration mechanisms back in No Twinkie V, but I hadn’t realized quite how many ways there were to screw up such an utterly trivial feature. Battlefield 2 doesn’t save your control profile with your game profile, so when you sit down at a new computer, you’ve suddenly got to reconfigure the keys again… and in a game like Battlefield 2, there are a lot of keys. And when you set up a new game profile, Ben says, the new profile goes back to the default control configuration again. Furthermore, according to the GameSpot review, you have to sort through multiple pages to unbind a key before you can bind it to something else.
Multiple pages? What a nuisance! You would think the scrolling list box had never been invented. Put a list of all the current bindings, all the unbound keys, and all the unbound functions on one screen. That way the player has all the information she needs right in front of her to do any mapping she likes. Then let her save as many different configurations as she wants on her own machine, and if it’s an online game, on the server as well, and reload them on demand.
Unavailable Configuration Menus
And I’m not even done yet. It seems that bad config designs hack players off far more than we realize, because Mihail Mercuryev adds:
“As a rule of thumb, most setup menus (controls, sound, small graphics adjustments) should be available everywhere in the game. Obviously, there are exceptions. You can’t change rules in the middle of the race, and resolution changes would freeze your computer, and those of other online players, for a couple of seconds. Some changes require recalculating large tables, or even reloading the entire level. But what is there to recalculate when you change your controls? Or when you turn off smoke effects?
“Grand Prix 3 doesn’t allow you to change anything (except sound) while in game. In Fallout, first you need to generate a character and view an introductory video, then you may change brightness or volume, or turn subtitles on. Driver is even worse: you need to complete the first mission (show how good you are at the wheel) with standard controls, then you may change them. Counter-Strike requires you to reconnect when you change brightness.”
|Interplay's Fallout. Too dark? Too bad!|
Uh… brightness? I have to disconnect from the game because I want to change the brightness? Whose idea was that?
You might be thinking, “Who cares? This config stuff is trivial compared to the importance of tuning the gameplay.” Yes, and that’s why there’s no excuse for doing it wrong! Building a good configuration mechanism is hardly the most exciting part of a game designer’s job, but it matters to the players, because if they can’t configure the game to their liking, you’re going to give them an inferior gaming experience no matter how well-tuned your gameplay is. I shouldn’t have to prove that I’m good with your stupid configuration before I’m allowed to set a sensible one, because in case you hadn’t noticed, I, not you, am the one playing the game.
Either do your job right—including the boring parts—or resign and give it to somebody who will. There are thousands of wanna-be designers out there who would be happy to take over from you.
Ignorance of the Law of Communicating Reservoirs
I’ll end with a sort of strange one, also contributed by Mihail Mercuryev. We’re pretty used to putting up with weird compromises in physics—cars that stop instantly when they hit indestructible park benches, and so on. Someday we’ll have enough computing power to get all that right. But this one is a level design mistake that doesn’t have anything to do with computing power. Mihail says,
“In some games (Quake 1, Duke Nukem 3D) you dive into the water, and get out a few meters below. If this has become a convention, forget it and start studying physics! When the reservoirs are communicating, the water level should be the same (unless there’s a closed chamber with some air trapped underwater, such as a diving bell).”
I have to admit that I never thought about that, but of course he’s right. If you dive underwater at point A and get out at point B, A and B must be at the same altitude because water seeks its own level. If you dive down to a lower level and get out into the air down there… why doesn’t that space just fill up with water?
Someday maybe we’ll simulate water as a real fluid rather than just a blue filter over the lens, and we’ll get this right. In the meantime, level designers, if you want to avoid Mihail’s wrath, remember the Law of Communicating Reservoirs. Or set your game inside a diving bell.
My thanks to Mahdi Jeddi, David Peterson, Santiago Hodalgo, Mihail Mercuryev, and Ben Ashley for this year’s batch of Twinkie Denial Conditions, and remember, only you can prevent stupid design errors. And if you spot one—even, or especially, in an otherwise great game—send it along to me.
Last item: After a real crunch to get it done, I’ve just finished writing a major update to Andrew Rollings’ and my book on game design, and it will be available in stores by August 21st. The book has a new name, Fundamentals of Game Design. I’ve heavily revamped it to make it more usable as a textbook, and added a lot of material, including four more chapters on subjects we didn’t get to last time. You can read more about it on my website.