Designing a game can’t be easy, but there are some things that are simply unforgivable.
Back when Tom Clancy worked with MicroProse on Red Storm Rising in the late ’80s he made a passing comment that once they were finished, they’d never need to create another submarine game again. Because, after all, it was all just bits and rules – get it right once, and it’ll be perfect forever. The developers laughed at his naïveté (behind closed doors, I assume – you don’t laugh at a guy with NSA-level connections to his face), but in hindsight, he was probably right: Red Storm Rising, despite all its graphical limitations, is still one of the best submarine games ever created.
In my ongoing (if somewhat sporadic) attempt to explore a new genre, I’ve come to the conclusion that MLB 09: The Show is arguably the closest thing to a “perfect” baseball game out there. Pitchers change their stance based on the ball they’re throwing, there’s about twelve different ways you can steal bases (right down to being able to slide left or right on your personal approach), and statistics really do mean something throughout the game. Unfortunately, none of that was worth much to me when I couldn’t even reliably hit a ball, much less understand what the hell the game was telling me when it threw up pages of statistics on team, player, and season performance with no reference or assistance.
I get that it’s a simulation and I can get behind that – realism and complexity can be cool in their own right. I not only enjoyed X2 but back in day, I worked out how to play a second-hand copy of F15 Strike Fighter III without ever having the manual. The problem is that the world has moved on – this kind of forced opacity was fine when getting a computer up and running in the first place was practically a puzzle in its own right, but now that computers and console are commodities? Not so much.
Increasingly, there’s this tacit usage of closed language and interface throughout design processes, and not just in simulations. If you’re an RPG player of a certain age, you’re probably going to know exactly what THAC0 means. You’re going to know what HP, RTS, XP, and probably DM mean. Jargon is a way of life, but jargon inevitably narrows the accessibility and appeal of a given topic. The problem is that abbreviations and mental shortcuts aren’t the exception in game design, they’re the norm. More importantly, they’ve seemingly become transparent to most designers; the level of assumed knowledge required to play most games has become so high that they’re practically opaque to a non-gamer, even if that non-gamer is explicitly interested in trying something new. Not only do we often not know what we don’t know, we’re equally very good at unconsciously ignoring that which we do know. When you need three hands to play a big-budget, highly tested game, the world’s clearly gone insane.
Developers, please take note:
Every acronym and piece of assumed knowledge you put into the game is going to turn off at least one gamer, if not thousands.
People sometimes forget that economically speaking, jargon was primarily a tool to improve communicative efficiency and keep new entrants out, thereby keeping demand high for incumbents. That’s great if you’re a design engineer trying to keep your pay high but not so great if you’re a developer trying to sell a product. It’s absolutely unforgivable in games because it’s an outcome of sheer laziness – effective testing, observation, and re-design gets rid of these unnecessary opacities. Valve is almost the poster boy for this approach; if you haven’t already, have a listen to their “commentary” tracks on Portal. Directly observing testers and incorporating the testing cycle as a design input inevitably makes their games better.
In my mind, that’s not a hard pitch to make: “Hey Mr. Money Man, if we pull the testing cycle forward by a few months and use it to refine our gameplay, we’ll still hit our ship date, but we’ll have a product that’ll sell better. And, it’ll only add peanuts to the total cost, given the cost of test players!”
Every time the controls are made more obtuse, the the mechanics more ‘precise’, and the barrier to entry that much higher, the number of people who are interested in climbing up that cliff of a learning curve decreases. That’s not to say there isn’t a market for hyper-complex games – for those who have or are willing to invest the time mastering the mechanical depth of a game, that’s probably a selling point! For the majority of gamers and new entrants though, it’s a turn-off: when it takes six hours just to learn (not master) the rules, controls, and interface, something’s screamingly wrong.
It’s not like this problem is unique to the games industry either – car manufactures have been fighting against ingrained user-interface beliefs for decades. Look at the failure of the iDrive on launch! In the long run, history’s shown that optimising for an increasingly small niche and designing for oneself is the fastest path to obscurity and, eventually, irrelevance. Developers need to learn that they can’t just design games for their core audience; as with all other forms of great storytelling and architecture, it’s also about touching the uninvolved and uninvested.
There’s a multitude of reasons why many games under-perform against sales expectations, and it’d stun me if this wasn’t one of the more major ones. What’s even more stunning though is that despite being shown and told exactly how to do it by one of the most successful developers in the industry, so few can replicate it. Why is that?
Thumbnail courtesy of ilmungo.
Related posts:
Tags: Baseball, Jargon, Simulation, UI
