January 31, 2009

The power of fiction

(Or, the new Prince of Persia has everyone fooled)

It's very common for a game's fiction to provide context to a game's mechanics, or to guide the design of those mechanics to be more intuitive. Recently, I've seen that i can also affect people's perception of what those mechanics acutally are.

Since Prince of Persia came out, people have been raving, complaining, and generally fixating on the fact that the prince "can't die."

The thing is, there is a death mechanic in this game, and it works almost exactly in the same way it always has: the prince fails at a challenge, dies, and is transported back to his most recent checkpoint.

There is one important mechanical  difference in the new version, which is that the checkpoints are much closer together than they used to be, occurring more or less any time the prince isn't platforming. The distance between checkpoints gets much longer toward the end of the game, but at their worst they're orders of magnitude more frequent than they've been in previous games.

There is also one important fictional difference: when the prince dies, there is a short death cutscene that shows Elika's hand grabbing his hand, providing the fiction that she's saved him from death:



If that cutscene showed the prince's head exploding, and big red text saying YOU HAVE DIED, the game's new checkpoint mechanic would still be making the game much easier, but would people still be making such a big deal out of it?

That 2 second cutscene is probably the most powerful usage of fiction I've ever seen.

What's this game about, anyway?

I've been playing some Tabula Rasa because I want to make sure I see what there is to see before it shuts down next month.

When I'm trying out a new game, I try to let the game teach me what the gameplay is meant to be through its mechanics, rather than looking it up on a website or strategy guide. After playing awhile in TR, I've decided the gameplay the game is encouraging me to adopt is collecting many weapons of different damage types, and switching among them often depending on which enemy I'm fighting or the stage of the fight.

The reason I've come to this tentative conclusion is that the game introduces enemies that are immune to certain damage types at very early levels, and robots seem to die much faster if you hit them with EMP weapons. There also seem to be a different weapons that are advantageous at different times in a fight, such as when an enemy's shields are down. This makes sense to me from a game design standpoint, but the truth is I can't tell if I'm imagining it.

I've also had problems like this in other games, especially games that are in genres that are full of conventions, like shooters. In some games, accuracy is affected dramatically by crouching or firing in bursts. Some have dramatically different hitbox effects, such as headshots that kill instantly, or leg shots that slow people down. Whenever I play a new shooter, it takes me days to figure out which common shooter mechanics are included, and which aren't.

It's ok to just give players advice directly

It's important to constantly and subtly reinforce the player behavior that you want, but it really is ok to just come out and say it too. If my weapons in Tabula Rasa had notes on them mentioning that they were good at taking out a shield, or a plant-based lifeform, or if it was part of the tutorial, I could be sure that swapping weapons often during the fight is gameplay the designers intended me to pursue. Likewise, a special UI element or scrolling combat text notification for "correct" damage that hits an enemy would help players learn these things through trial and error.

Every designer designs their game with an ideal gameplay in mind that will be the most fun or effective, but if the player doesn't find out them quickly, it's likely they'll end up quitting in frustration. Don't make your players close the game to search for information on what they're supposed to be doing, because there's a chance they'll never open it back up again.

January 28, 2009

Glossary: Fiction

Defining terms is an important step in the design process. There are some concepts for which I find it useful to create new or more specific definitions when discussing game design. See a collection of all glossary posts, here.

Fiction
Game designers often wrap a game's mechanics in familiar trappings to help the player understand and remember them. In a Tag-variant game such as Sharks and Minnows or Cops and Robbers, those roles are shortcuts to help players understand and remember who's meant to run from whom.
Fiction: The usage of metaphors to present mechanics and gameplay as a cohesive and logical whole.
Fiction encompasses all the characters in a game, it's geometry and animations, music and sound effects, the names of its powers and enemies, and the general traits of the world and setting.

To imagine a game with no fiction at all, try to picture the game stripped down into the form of a gameplay prototype, with no names of powers or statistics or characters. Dwarf fortress has a fiction that players have to learn, but at first glance it has no obvious fiction at all:


Imagine trying to learn to play the game without someone explaining to you what each character represented. Once people started making custom character sets for the game, things started being a lot more understandable:


Try picturing some other games with their fiction stripped away:
  • The Sims becomes a game about little squares moving around and interacting with other squares to get some numbers from them. Some numbers can't be gotten from other squares, so the squares must spend resources on circles, and spend time near those circles until they receive enough of the numbers they want. Your square is doing well if it has a lot of the right kind of numbers, and very little of some other kinds of numbers.
  • Dungeons and Dragons becomes a game about moving around some rocks on a piece of graph paper and the rocks collect some numbers from other rocks which another player arbitrarily puts down on the grid sometimes. Your rock has some numbers, but if you spend some of those numbers to take some other numbers from the other rocks, you'll eventually get some other numbers which you can convert into special permanent numbers which improves all of your rock's number-giving and number-taking.
Yikes. Sounds fun, right?

It's almost impossible to remove all fiction from a game. Even the concept of movement, time, and dimensions are metaphors to some degree. Even Tetris has the fiction of building and gravity. The only game I can think of with no fiction at all is Sudoku, and most people would probably refer to that as a puzzle rather than a game.


Fiction informing mechanics

Imagine World of Warcraft remade as a scifi game, but only visually. Every creature and castle would be replaced by a spaceship or starbase. Every power would receive a new icon, display name, and animation, but the game would have exactly the same mechanics and gameplay.

The game would be exactly as fun to play in theory, but it would be a lot harder to understand. A lot of WoW's mechanics don't make sense in the context of a space game's metaphors: Why can my warrior class spaceship only attack things in melee range? (And what would the animation for a spaceship melee attack even look like?)

The same problems would arise if CCP tried to reskin EVE as a fantasy game. How would they explain the metaphor of a quasi-permanent avatar piloting a pod inside a destroyable, upgradabe ship in the context of a game about being a huge warrior with an axe?

The fiction of these two games provide valuable context for all of their mechanics, as well as influencing which mechanics are included at all. Every player and designer innately knows from a century of pop-culture that shields in a space combat game should function very differently from shields in a fantasy game.


Fiction informing gameplay

While fiction helps players and designers understand mechanics, it can also work with fiction to help point players toward gameplay. Splinter Cell contains many mechanics that encourage the player to play stealthily or punish them for not doing so, but it also has a fiction and art style that encourage the player to roleplay a sneaky and careful spy, patiently waiting in the inviting shadows of the game's environment.

If you showed a non-gamer a photos of Sam Fisher and Kratos, they'd be able to easily recognize that one game is about a sneaky spy and one is about a rampaging badass. If you showed them a video of both characters' walk animations on a nondescript character, they'd be able to tell from that too. Every element that we present players with gives them subtle information of how to have fun in our game. This information must always be purposeful and consistent.

Glossary: Gameplay

Defining terms is an important step in the design process. There are some concepts for which I find it useful to create new or more specific definitions when discussing game design. See a collection of all glossary posts, here.

Gameplay

At its most basic level, game design is presenting a player with carefully selected stimuli, with the intention of encouraging a response behavior that the player enjoys.

Gameplay: Anything that a player does or thinks as a direct or indirect result of a game's mechanics.
Gameplay includes any thinking about strategy or tactics. Any of the advice you'd read in a game guide or on a webpage tutorial are generally also gameplay.
A quick rule for identifying gameplay is that it's anything the player would proudly or angrily describe to a friend later:
  • "So after distracting everybody with an explosion inside the base, I flanked the whole squad, knocked out their leader, and dragged him off before anybody else even noticed me."
  • "Then, on the river card, I finally made my flush, which surprised the hell out of him because I knew he could tell I was bluffing."
  • "And then that asshole camped my corpse for like 2 hours! I bet he regretted it though when I logged in on my main and killed him 12 times in a row."

In the basic game of Tag, the typical gameplay consists of the player who is "It" chasing players who aren't "It." It's important to realize that running around isn't a game mechanic. There's no mechanic that can ever force the player who is It to chase anybody else, but all the mechanics do encourage it.

Because basic Tag has so few mechanics, it can support a huge array of gameplay besides the "right" gameplay. Here are some examples I remember from my neighborhood as a kid:
  • "John hadn't seen me get tagged, so I just walked up to him really calmly like I was on his team, high-fived him, and yelled 'You're it!' as I ran away. He was so mad."
  • "Man, Billy's such a baby. After he was it he just sat there on the grass for 20 minutes until somebody finally came up and let them tag him."
  • "Brad's big brothers are so mean. They grabbed him by the arms and held him down until Joe got over there and tagged him."
  • "I got Janie's brother to yell out that she had a phone call, and I hid by her back porch so I could tag her when she tried to go inside."
New game mechanics are often added in response to undesirable gameplay. For example, most kids probably play Tag with a rule of "no tag-backs," and there are many variations of the basic game with slightly different gameplay.

Glossary: Game Mechanics

Defining terms is an important step in the design process. There are some concepts for which I find it useful to create new or more specific definitions when discussing game design. See a collection of all glossary posts, here.

Game Mechanics
At its most basic level, game design is presenting a player with carefully selected stimuli, with the intention of encouraging a response behavior that the player enjoys.
Game Mechanics: Any stimuli the game presents a player with, in the hopes of encouraging or discouraging certain gameplay.
All games are made up of at least one mechanic; it's impossible to have a game without them.
A game mechanic that doesn't modify or reinforce player behavior is a bad mechanic, by this definition. A mechanic that intends to reinforce a particular behavior but ends up encouraging a different behavior is also a bad mechanic.
The standard game of Tag only has 2 mechanics:
  1. One player is "It"
  2. If the player who is It tags another player, that player is now "It"


Mechanics vs. Rules

Aren't these just the same thing? What's the point of using the fancier word?

All game rules are game mechanics, it's true. However, the reason I think the term mechanics is more useful here is because there are many other types of stimuli that I count as game mechanics, even though they'd never be considered rules.

For example, level design, audio, and UI can encourage certain player behavior, so they are important to utilize as game mechanics. When we only think in terms of rules, it's easy to forget the subtler game mechanics such as these. For that reason, I find it more useful to ignore the concept of rules entirely and only refer to mechanics.

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.

January 24, 2009

Design Lessons from Visual Arts Jobs

I've learned several important design lessons from my work in various non-design jobs. See the full introduction, here.

Job: Graphic Designer

I did some freelance design work to pick up some extra cash in college, for department newsletters and things like that.
1 - Your job is to give people what they don't know they need
"I'll know it when I see it" is the worst thing to ever hear from a client, whether the job is in graphic design, art, writing, or game design.

A large part of this problem is that the customer doesn't speak your language like another designer or an art director would. Teasing out what they want can take months of iterations, and involves time-consuming tactics like making many mockups each time for them to choose between.

Spend more time up front getting a list of goals and requirements before working on a rough draft. Refine that draft before you waste time on a polished version that may be rejected, and constantly reiterate your goals. Don't ask a client if they like what you've done, ask them how well you think the deliverable achieves the goals you've laid out together. You'll get much more useful feedback.
2 - Don't give clients details to focus on too early
Clients with no vocabulary to discuss design details will often latch onto the first thing they can articulate about the design that they dislike. This often takes the form of an inane detail that becomes a huge distraction for them.

Clients will fixate on the font choice, a word selection, or a paper color, when really there's something about the design as a whole they dislike but can't articulate.

If you have a really difficult client, don't put in any details at all until you get them to agree on the rough layout. Then go away for awhile and insert all the details at once, making sure all the details are in service of the goals you've agreed upon.
3 - The client wants to feel in control
Talk difficult clients through what you're going to do, and make them think it was all their idea.

When you bring back the final perfect deliverable, insecure clients will always have one tiny piece of feedback that they want you to implement. This will always happen, no matter how much they like the design, and it's just because they want to put their mark on it, and assert themselves over you.

Usually these details will be so harmless that you can just put them in, and everyone will walk away happy.

Job: 3D Artist

I spent several years making 3D models and textures for game engines and virtual reality, as well as some 2D interface work.
4 - Your work must be usable by your customers
I use the word "customer" here to refer to any person who has to utilize the work you've made, which may be a player of your game, or another person working on the game who needs to use your assets.

A modeler who makes beautiful characters that don't deform well when animated isn't a good modeler. By the same token, an engineer who writes code that no other engineers can interact with or debug isn't a good engineer, and a designer who designs games that normal people can't understand isn't a good designer.
5 - Versatility is as important as skill
A mediocre artist may be able to draw a nice picture in one very specific style or medium. A master artist can represent the same subject with skill in any style or medium.

In game development, there are many ways to solve almost every problem, and we need to constantly evaluate which solution is the best for the goals we're trying to achieve.
6 - Never add details onto a rushed structure
Good artists aren't in a hurry to make their work look finished. They've learned the counterintuitive lesson that fine tuning a sketch for a few minutes is much more useful than trying to correct a problem once the details are already laid in:


Granted, if you have photoshop you can just select the eye and move it, so it's a bad analogy. But imagine if you had to copy and paste every pixel individually and by hand, and you'll be a bit closer to what fixing this sort of problem is like in game development.

Game designers need to make sure to iterate on a single map, character class, enemy group, or power set until it's right before making any more content that might be based on a flawed concept. Updating the entire game after the fact will take weeks for something that could have been corrected in the test content and designed into the rest of the game with little to no extra effort.

It's incredibly tempting for teams to start making tons of content when the first batch isn't even working right yet. It never saves time, and you'll always regret it. Be the voice of reason.
7 - Iterate on paper, when it's still free
All the great artists of history have created sketches or studies of some sort before a major work. Yes, even Picasso. For the cost of a pencil and some paper, Michelangelo made sure he wasn't going to waste a 15 ton block of marble.

By spending an extra month in the design phase, you can save yourself a year of production time. Think of all the extra content you could make in that year, if you spend more time getting your initial game design nailed down.