January 25, 2009

Kill subjectivity - Define terms, problems, and goals

Entropy is evil

Entropy might mean many different things in different contexts, but it's a universal force, and the form it takes in game design is subjectivity. When a development team lets its guard down, subjectivity starts rolling in like a toxic fog.

Game design is a very squishy business at the best of times, but once it becomes infected by subjectivity, every design discussion simply becomes a competition to see whose opinions are the most stubbornly-held or loudly-voiced.

If designers on your team waste time arguing about vague concepts such as how single player/multiplayer is the only worthwhile form of gaming, or how games should always/never have a jump button, you probably have a subjectivity problem.

The way to prevent subjectivity (or at least to limit it as much as possible) is to set some ground rules, publicly and in stone.

A team that doesn't agree on what goals their game has, what those goals mean, and what's stopping them from achieving those goals will never get anywhere.

Define Terms/Define Goals
Compelling! User-Friendly! Casual! Hardcore! Skill-based! FUN! These words don't actually mean anything specific enough to make decisions based on them. If you could just say to any person, "please make that game more fun," someone would just write some software to generate games, making game designers obselete.

Many designers have tried to create a game design lexicon of some sort, but the truth is that every company, designer, school, professor, and genre disagree to some degree of what any game design term means. Every time two designers work together for the first time, they'll each have to spend some time learning and negotiating terms.

There will likely never be a universal definition of what fun is, and that's ok, but I do believe that it can and should be defined on a per-game basis.

This is where strong creative leadership comes in. At the beginning of preproduction, it's important for every lead to agree on what fun means and doesn't mean in the game they're all about to embark on making. For a shooter, fun may be overcoming impossible odds by sheer coolheadedness and skill. In a fighting game, fun might mean learning an elaborate system of attacks and counters. In an open-world game, fun could be learning all the routes through a vast world, and the locations of important or rare resources.

Defined terms overrule subjectivity, even when people disagree with those definitions personally. A given designer may have strong personal ideas of what makes for immersive or compelling gameplay, but once their leads have established rules for what those words mean in this game, those buzzwords can no longer be used to defend subjective arguments.

Define Problems

As I mentioned in my very first post, one of the biggest pitfalls for otherwise good design teams is talking past each other when trying to solve problems. It's alarmingly easy for 10 people to walk into a meeting with 10 different ideas about what problem they're trying to solve there, and this leads to a lot of needless frustration.

People can't solve problems if they don't know what the problem is, and can't recognize problems clearly unless the game has a clear set of goals, which can't be defined without a common understanding and definition of terms.

When a team has a strong common definition of terms, problems and goals, the lowliest member of any discipline will be able to make sound decisions in much less time, and the game will inevitably be a much more cohesive whole.

2 comments:

Anonymous said...

This is a problem across computer science. The language of various communities takes on it's own empty life, where there are only big egos.

Anonymous said...

Have you read Philosophical Investigations by Wittgenstein?