Do Great Games Take A Decade?

Jamie Fristrom reminded me of an old Joel Spolsky article which claims that any major piece of software takes 10 years of development time to really get good.

The part of Joel's post that really intrigued me at first was the idea of purposely having a small launch, so that only the die-hard early adopters would be around to see the problems that you've shoved out the door.

I've mentioned this before, when discussing how EVE and WAR arrived at 300k subscribers by such different paths:

EVE had a very small playerbase to witness its early its mistakes. It actually had a fairly troubled launch: It reviewed much more poorly (with a 69 Metacritic) than WAR did (with it's 86 Metacritic). But nobody remembers that, because nobody was playing it. EVE corrected many of its problems while it still had a very small userbase of devoted players, before trying to reach out to a larger market. WAR probably made fewer mistakes with its launch, but it made them in front of many many more people.

What's especially impressive, though, is that many of those early adopters have been remarkably loyal to the game to this day. I saw an interview recently where CCP's CEO stated that ~20% of EVE's subscribers from its launch month (May 2003) are STILL subbed to the game.

This makes me think that a small launch strategy might be the way to go (although I doubt many other companies would have the discipline to pull it off).

[Did anybody else see that video? I'm having no luck finding it again.]

The part of the article that is haunting me, though, is the idea that it takes ten years for a piece of software to really mature. It struck me as a bit ridiculous at first, as something that only makes sense for something huge like an operating system. However, the more I think of it, the more examples I notice of games that fit this profile.

Ten year juggernauts

At first it sounds a little crazy that it would take a game 10 years to really hit its stride, but our first instinct is to only think of the time that a game has been live, not the years of development before release.

CCP was founded in 1997, and developed a board game "in its first three years" to help finance EVE. I can't find anything specifically stating when EVE's development began, but it seems to have been sometime 1999 or 2000. EVE is now a ten year old piece of software.

As of this month, so is World of Warcraft, according to Rob Pardo:

But if you do want to try to be that No.1 MMO, it's hard, because not only are you going up against the five years of development we had, you're up against five more years of development that we've had since the game launched.

I find this interesting because from what I've seen so far of the Catyclysm expansion and its revamp of all the old content, I think this will be the year that WoW finally reaches its full potential.


Team Fortress 2 is also a ten-year game. What we now know as TF2 began development in either 1998 or 1999, depending on how you look at it. The timelines on this one are a bit confusing, since TFC was actually a spinoff of an even earlier TF2 incarnation(!), and development may have been suspended for some amount of time, but ten years of linear time have definitely passed.

I also think it took until this year for TF2 to really grow into itself. The class balancing, new gameplay modes, unlockable weapons, and achievements would be sorely missed if the game were reverted to its launch day state. Once the final classes receive their updates next year, I expect the game to feel really complete.

Everquest II is an interesting example, because its launch was a bit rough but its live team is often said to have drastically improved the game in the years since then. I know some people who have tried or returned to the game recently and who have been really blown away by how much they like it.

I can't find any exact info about when development began, but Everquest's success resulted in the formation of SOE in 2000, I'm guessing that game will soon reach its 10 year milestone as well.

So, what do you think of all this? Does it really take that 10 years for these huge software projects to become great? Would you invest that much time into a game if you knew it could be as great as EVE, WoW, or TF2?

I'm beginning to think I would.

Players (And Designers) Learn Faster With Tight Feedback Loops

I will never be good at Starcraft. Never ever ever. It's a great game, and fascinating to think about, but playing it against real people usually makes me quit in frustration pretty quickly. On the other hand, I'm great at learning new songs in Rock Band. My brain lights up like a Christmas tree every time I play that game.

This says a lot about my brain (great at music and sequential tasks, terrible at juggling multiple simultaneous tasks), but it also says something interesting about the nature of these two games.

When I make a mistake in Rock Band, the game makes sure I know about it that very instant: A piece of the UI shatters like broken glass, the audio for the note doesn't play properly, my performance meter goes down, and my note streak is broken. On top of that, notes show up hundreds of times per minute, patterns of notes show up many times per song, and each song is short enough that it can be replayed many times in an hour.

Because of this, Rock Band is one of the easiest games to learn. I don't necessarily mean that it's an easy game to be good at, but it is an easy game to get better at. If even the worst beginner sits down and plays the same song a few times in a row, their performance will immediately start improving.

Conversely, losing a game of Starcraft can take hours, and I can never really pinpoint where I went wrong. Something very early in the game, such as making the wrong number of harvesting units, or failing to expand at the right time, or deciding to progress down the wrong tech tree, can have adverse effects much later. This problem is also exacerbated by the fact that Starcraft, like most strategy games, is a slippery slope game.

Timely information feeds learning

Games like Starcraft and Chess, which can have long periods of time between between decisions and the consequences of those decisions, are very difficult for players to learn. This shouldn't be too surprising – any book on pet training, child rearing, or romantic relationships will tell us that a delayed reward or punishment for an action is confusing.

Your dog can't tell that the treat you just gave him is for the trick he performed 20 minutes ago, and your significant other will only be frustrated when you snap at them today because of something annoying they did last week. Gamers are the same way – the more immediate the feedback to their actions, the more quickly good and bad behaviors can become reinforced.

Strategy games obviously delay their consequences on purpose, and I'm not saying Starcraft should be redesigned to be more like Rock Band. However, I do think Blizzard could add in some sort of special learning mode that would notify the player in real time of mistakes that would not normally be apparent until much later.

If beginners could see status messages like “your economy is falling behind, try producing more gatherers” or “your factory has been sitting idle for x seconds” or “your opponent is producing tier 2 units already, time to upgrade,” it wouldn't help people become experts at the psychological aspects of the game, but it could help terrible players like me start to learn from their mistakes more effectively.

Feedback loops in game development

Just as players learn much faster by seeing the immediate results of their decisions, so to do game developers. If we don't see results for too long after making decisions, it's easy to forget what the other options were, which of our arguments and thought processes were flawed, or even who was responsible for a particular decision.

Worst of all, if a game takes too long to make, employee turnover becomes a problem. Bad people get fired, and good people leave for greener pastures. If the people who witness the results aren't the same people who made the decisions, only the most disciplined designers will manage to glean any useful lessons.


Show me a game designer who has shipped 2 games in 10 years, and I'll show you a mediocre designer who is learning much more slowly than they could be. Most of the best designers I know have shipped many games in a short period of time, started out on live games where changes are released almost immediately, or worked at studios that are constantly letting people playtest their work before the game ships.

Like all designers, these people started out with a lot of wrong thinking about how to make games, but they very quickly had their bad ideas shattered and their good ideas reinforced. Just like Starcraft, success in game design is a slippery slope. The first year of your career as a game designer sets the trajectory for everything you will ever do, and if a player never even plays one of your designs until your 3rd year in the industry, you've already fallen behind.

For those of you looking to start careers in the game industry, try cutting your teeth on a live team or expansion pack team. Experienced designers usually choose to move off of these teams for the exciting new project, and as a result they are more open to newbies. Likewise, starting out by working on games with very short production cycles is another good option.

The average game project is getting very small these days, so it's a perfect time to start out as a new designer on an iphone game, flash game, facebook game, or live MMO. Shipping a lot of games now will give you the accelerated learning you need before tackling that masterpiece later.

Designing Your Audience

Last week, I made a comment that I should have realized would need some explanation:

Learn to recognize which parts of your game and playerbase aren't important. Your favorite part of the game may be something the playerbase doesn't care about, and there are some players who care about things that it isn't in your best interests to focus on.

I probably shouldn't have mentioned this in passing before I had a chance to do a longer writeup on it. That's a fairly sinister-sounding quote, after all.

So what did I mean by this? Why wouldn't I want to just always make all of my players happy all the time? The short answer is that's exactly what I do want. The longer answer is that if you end up with too many different groups of players who want opposing things out of your game, you'll eventually arrive at a situation where any decision you make will anger one of the player camps.

Aside from bugs and generally shoddy development, the biggest cause of /ragequits is developers and players not agreeing on what the game is supposed to be:

Players thought it was an RPG with FPS elements, developers shipped an FPS with RPG elements. Players thought the game was supposed to be mostly grouping with some soloing, developers preferred mostly soloing with some grouping. Players expected open world territorial control PvP, developers implemented consensual sport PvP.

These are very small differences in opinion that don't matter at all, until they matter more than anything and all your players have quit.

Just like every other aspect of the game, your playerbase must be carefully designed and crafted. Here's how:

1 - Know what game you're making, and for whom

If your design team can't agree on what the game's about, how can your playerbase possibly be expected to agree with your design team?

Your gameplay will determine which players will enjoy your game, and which players you intend to enjoy your game should be the driving force in all your gameplay decisions. It's not important whether you start the game with an idea of the players or an idea of the gameplay, it's just important that they both support each other.


If you wait until you have real players to start trying to make them happy, it's already too late. The game has to be tailored to the audience before the audience even exists. This can be challenging, but there are lots of shortcuts.

You can do it by treating some designers as spokespeople for the player groups you expect to have, you can define a set of archetypes that you keep in mind while designing, you can write user stories, or you can just try make a game for another game's audience and steal them.

It doesn't matter how do you it, but you have to figure out who your players will be and what game they'll want in time to actually start making it.

2 - Keep your design focused

Feature creep is arguably the worst problem in the game industry, as well as the software industry as a whole. It causes financial problems and scheduling problems, and it also causes a fragmented playerbase.

Sprawling game designs such as RPGs are the most prone to feature creep, which in my opinion explains why so few MMO gamers are actually happy. It's incredibly difficult to support divergent gameplay styles in a way that doesn't result in each style's features harming the other's gameplay.

For example, Blizzard has enough resources to put huge amounts of effort into both PvE and PvP, but even they barely pull it off. WoW players are constantly arguing over which type of gameplay that game is supposed to be about, or angry that one is receiving more content, better itemization, relevant balance changes, etc.

The best way to avoid feature creep is to make a firm choice as to what game you're not making, and which audience you're not trying to appeal to.

By adding every feature under the sun to your game, you might attract more players, but I can guarantee you that those players will be less happy. Think about whether you want to have a huge audience of unhappy players, or a small audience of happy players. It's a trick question though, because unhappy players quit, while happy players multiply.

3 - Market your game honestly

Stop giving players false hope. If you know that your game isn't a PvP game, isn't a solo game, isn't a crafting game, etc, all you have to do is make that clear up front. Nobody wants to be the bad guy in the dev chat who tells all the nice crafters and all their nice money to take a hike, but it's much better than leading them on and then disappointing them.

If you feel ashamed to tell your players honestly what your game is about, that's a pretty great sign that you game isn't about the right things.

4 - Dance with the ones that brung ya

Once your game has players who aren't on your dev team, it's too late to change what game it is. You can only make it a better and better version of itself, even if you screwed up and made the wrong game.

Once players are playing your game, even for free, they've invested themselves in it. Players always talk about how they've paid money and deserve a service, but that's not actually what's making them mad. Once they've invested their time and attention in a game, they've given you something much more precious than their money and you've reached the point of no return.

Even when you've designed and marketed a game for a specific audience, you'll still have some players from outside your audience show up and try it out. These players will be mad that the game isn't a game for them, and demand that you change it. Sometimes you can accommodate them without alienating your existing players, but sometimes you just have to have the self-restraint to allow them to quit.

I'm hugely impressed by CCP's new game Dust 514. After being assaulted for years by complaints of EVE not being exciting enough, CCP didn't cave in and dilute their game to include those players who were outside of their intended audience. They made an entirely new game just for those players. This is a perfect way to make a new group of players happy, without that gain in happiness costing some happiness from another group.

Time to pick on poor SWG

Star Wars Galaxies is an example that's been beaten to death, but for good reason. That game suffered from all of the problems I've mentioned here. It tried to support every style of gameplay there is, from politics and city management to crafting to avatar combat to dogfighting in spaceships.

It was seemingly designed for fans of every part of the Star Wars universe but the movies, and then inevitably marketed to people who had only ever seen the movies. Once its audience was distilled to only people who really liked SWG's gameplay and everyone else had quit, the devs decided to try and fix their mistakes.

They rereleased the game with a new design that would appeal to all of the players who had quit (who wanted it to be more like the movies), except those players didn't really care anymore. The loyal players who had remained rightly felt this was a slap in the face and began quitting in droves.

The new Star Wars game seems to have much more in common with the failed SWG revamp than it does with the original SWG. The funny thing is that this time around everyone is incredibly excited about it. This is because we can all tell what that game is trying to be, and hopefuly because it's being marketed honestly.

Nobody wants their players to quit, and it's always a bad thing to make any of your players unhappy. However, if you let your design get too diluted and your playerbase get too fractured, you'll end up in a position where it's unavoidable.

If you decide which potential players are and aren't important long before the game ships and market the game honestly, then you'll never have such a divided playerbase that you have to make those kinds of tough calls. This hopefully also means you won't see so many players /ragequit.

How A Designer Thinks

Eric and Sandra over at Elder Game run what I consider to be the best blog on MMO game design, and one of the best game design blogs in general.

Sandra just posted a succinct piece of advice about another, possibly too-succinct, piece of advice: "think like a designer."

This is a very important piece of advice, and I've seen many aspiring and even experienced designers fail interviews for being "too playerish" or "not designerly enough." But what does that mean exactly? Here's Sandra's post:

“Learn to think like a designer, not a player.”

You’ll hear this a lot from game developers giving advice to would-be designers. And it’s not wrong … but taken at face value, it leads to being a sub-par designer. There’s no value in mimicing what you think a stereotypical designer would do.

Better advice: “Learn to understand how different types of players (including you!) experience your game, and analyze that like a designer.”

Not nearly as memorable, but way more accurate.

There's still something missing

Sandra has a great point; considering your whole playerbase is very important. I think there's one more detail that both versions only hint at: Think about your whole game. This is implied by "think about your whole playerbase," but it's so important that implication alone doesn't do it justice.


In my experience, taking a high-level view is especially difficult and important for designers of MMOs and other large, multifaceted games. We have so many competing features, playstyles, and subcommunities within our games that it's very easy to get hung up on just a small set.

Here's what "think like a designer" means to me:

Learn to think about your game and playerbase holistically. The classes, features, and gameplay style that you enjoy are only a small part of what is important to the playerbase as a whole.

We spend so much time as designers reminding ourselves to be detail-oriented that thinking of the game as a gestalt is sometimes easy to forget. Balancing between these two competing modes of thinking is what can really make a designer great.

Speaking of more advanced design thinking, I think this advice also comes with a counterintuitive but important corollary:

Learn to recognize which parts of your game and playerbase aren't important. Your favorite part of the game may be something the playerbase doesn't care about, and there are some players who care about things that it isn't in your best interests to focus on.

That may sound a bit mean or negligent, but there's no faster way to game design failure than trying to please everyone. If you can learn to tell what's not important, you'll be a better designer than just about everyone in this industry. Much more on that subject another time.

All this advice rolls off of the tongue less trippingly than "think like a designer," but it's a great point that we often give people important advice without bothering to clarify what our advice actually means.

The 3 Flavors Of Enemy Design

I hadn't really noticed it, but I seem to avoid writing about whatever sort of design I'm currently doing all day at work. The past few months are the first time in my career that I haven't been involved in designing AI or enemies, so I find myself wanting to write a few posts about that.

When deciding on a high-level design for the opponents in your game, it helps to decide first which of the 3 major groups you'd like your enemies to fall under:

1 - Enemies that follow the rules

There are many games with AI opponents that never do anything a player can't reasonably be expected to do. This type of enemy is often referred to as "bots" and used as a substitution for players in games that are multiplayer-focused.

With good enough AI scripting, it's possible to make enemies that mimic real players, with the same abilities, limitations, and even behaviors. Playing against AI is never exactly the same as playing against a player, but they can definitely feel similar enough to feel like good practice, to a point.

In this sort of game, players will feel cheated and angry if the AI does anything that they can't do themselves.

Examples:

Chess, Starcraft, Madden, Unreal Tournament, Street Fighter, Poker, Battlefield 2142

When to use them:

This sort of enemy works really well as a way of easing players into the game and preparing them for matches against real human opponents. For this reason, it generally make sense to tune these enemies to be clumsier and easier to defeat than a human would be. Despite that, these enemies are generally the kind that make the most sense to have a high level of awareness.

It's also possible to make very very challenging AI settings for people who can't find a human partner that can challenge them, but chess is the only example I can think of where this is very common.

2 - Enemies that break the rules

There is a similar class of enemies for whom breaking the rules is a possibility. They tend to have most of the same abilities as a player and generally seem like players, but they will occasionally break the rules in the service of modifying difficulty.

It's certainly possible to make AI cheat to be more difficult, but good designers also make them cheat downward, which is to see start losing a little bit on purpose if they get too far ahead. This is also known as rubberbanding, a form of negative reinforcement.

Examples:

Many racing games, many strategy games (most notably the Civilization series)

When to use them:

If you're thinking of your AI opponents as a replacement for other players, rather than a training tool, it might make sense to allow them to break some rules. This sort of AI design tends to focus a bit more on matching the player's ability and making sure that the game is challenging, but not too challenging. It can ensure that the player always feels they have a chance to win (or lose) right up to the end of the game.

3 - Enemies that ARE the rules

The most common type of enemy, by far, is that which operates in a completely different realm from the player. This type of enemy not only operates outside the set of game mechanics that the govern the player, but actually becomes a part of those mechanics.

Games that use this type of enemy design tend to have many different types of enemies, which vary from location to location. This enemy variation becomes a part of the game's content and level design palette.


It's also very common for games to use this sort of enemy design in boss battles, where there tends to be a puzzle to solve, a weakness to exploit, or a pattern to memorize. Unlike the previous two enemy types, this sort of opponent is not used to teach the player how to play against other players.

In the most extreme examples, the entire gameplay of a game can consist of learning how to defeat new and varied enemy types, in increasing numbers and more complex combinations.

Examples:

The God of War series, the Diablo series, the Halflife series, World of Warcraft, the Zelda series (especially their boss fights), the Super Mario series, the Ninja Gaiden series, the Metroid series, almost all shoot-'em-ups, and on and on.

When to use them:

My guideline for when to use this sort of enemy is when you'd like to present players with a more reactive form of gameplay, where they change their tactics based on which enemies they are fighting.

It also works well in games that are very content-heavy (shooters, RPGs). In games like this, enemies that try to fight like players are likely to become monotonous over time, or much easier as the player figures out all of the AI's tricks and shortcomings.

Should you combine enemy types?

Generally I'd say that it only makes sense to have one kind of enemy in your game. If you've got a really good reason, it can make sense to combine them, but there aren't very many examples I can think of.

Champions Online's enemies are almost entirely the third type (totally seperate rules), except for player Nemeses, which are the first type (same rules as players). Time will tell if this was a good idea, but the rationale of using Nemeses to prepare the player for PvP seemed like a sound one, and Nemeses were already very special and seperate from all the rest of the enemies in the game.

The Hierarchy Of Awareness

I've done a huge amount of work on AI scripting and tuning over the years, and in the last year especially I've been thinking a lot about the different characters of NPCs: What kind of AI makes an NPC seem more or less frightening? What kind of AI makes an NPC feel more or less human?

I think the following 6 levels of AI awareness describe the difference between a very stupid, inhuman AI and a deviously frightening opponent that seems to think like a human.

Lvl 0 - I thoughtlessly follow a routine

Before there was any such thing as AI in games, we generally just dealt with completely scripted enemies that followed set movement paths and attack rotations.

Some examples that spring to mind are the aliens in Galaga and Koopa Troopas from the first Super Mario Brothers game. In modern games, it's generally not likely to see this sort of opponent except for "inanimate" objects and environmental hazards: moving sawblades, laserbeams, etc.

Lvl 1 - I blindly pursue a single goal

The racecars in Pole Position and the ghosts in Pacman are enemies that want something. They want to chase you or get to the finish line, or escape from you. They don't do anything but try to complete that one goal. This is really the most basic form of AI scripting.

Lvl 2 - I think about only myself

NPCs that can change their behavior based on their own current state. If an enemy heals itself when its health is low, or tries to escape combat when outnumbered, they're thinking about themselves. Same goes for any enemy that realizes they have some sort of buff or invincibility and behaves more aggressively as a result.

There are lots of NPCs in games that heal themselves, self destruct at low health, or try to run away. I believe World of Warcraft has examples of all 3 of these things.

Lvl 3 - I think about other people

This is the level at which some NPCs can start to seem to have some personality or even deviousness. When a character in The Sims refuses a hug from a smelly person, or a group of enemies in Starcraft focuses fire on a damaged opponent, their AI is making decisions based on the state of another entity.

Another variety of this type of AI will change between offensive and defensive modes based on how much damage they take, or build "hate" or "aggro" toward enemies that damage it the most or in certain ways. This model is now extremely common in RPGs.

Depending on how you think of it, the ghosts in Pacman that switch between chasing you and being chased are either thinking about themselves or other people. They either realize they are vulnerable or that their enemy has become invulnerable, but in this case the effect is the same.

Lvl 4 - I think about what other people are thinking

Now, imagine if the ghosts in Pacman could calculate that you were trying to get to one of the power pills that would place them in danger, and start running early, or hug the center of the map. If they saw that a pill was already used up in an area, they would be much more bold. Suddenly the enemies in that game would feel much more intelligent, and be much more difficult to defeat.

AI that thinks of what a player's goals are and reacts to them are the approximation of a mediocre human opponent. Chess bots are the first thing that comes to mind when I think of this kind of AI.

Also, enemies in fighting games that try to predict the player's next move and preempt it are also on this level of awareness. If the fact that I've been playing more offensively causes an enemy to play more defensively, they're making decisions based on the fact that I will probably decide to keep attacking.

Lvl 5 - I think about what other people are thinking about me

This level of awareness in AI is pretty rare, mostly reserved for chess bots, RTS armies, and fighting game opponents. This is essentially AI that can trick you.

If a chess bot lures your bishop out of the way with a pawn so that it can capture your queen, or an enemy in an rpg feigns death until you let your guard down, these are all tactics based on making the player think something that isn't true.

Likewise any AI that has the ability to bluff and try to scare away a player that could actually attack them falls under this same umbrella. Generally I'd only expect to see this sort of thing in poker or strategy games.

Imagine in an RPG if enemies that have detected you in stealth didn't immediately go "HUH?" and look at you, but just subtly tried to walk toward you without indicating that they'd seen you. They'd use the fact that you thought they hadn't seen you to get in close before ambushing you at the last second. This sort of AI would be incredibly scary and make players very paranoid.

Human opponents and Yomi Layers

AI with an awareness level of 4 or 5 are generally the best way to prepare players to face off against human opponents, but they still aren't as dangerous as a real person. It's amazing how many more layers of deception human players are capable of, often without even realizing that we're doing it.

Check out this great article by Dave Sirlin about what happens when I start thinking about what you're thinking about what I'm thinking about what you're doing (and beyond). He refers to this as Yomi Layer 3, and apparently in competitive fighting games it's common for players to think about Yomi Layers 3, 4, and even 5.

The term "Yomi Layer" is probably new to you, but it describes a concept that should be very familiar if you've ever seen the The Princess Bride.

Don't Waste Your Fiction

Damn it. I was so excited.

I read today on Rock, Paper, Shotgun about an experiment that sounded like a brilliant idea. A group of researchers created the same game twice - once as a completely abstract set of game mechanics, and once with a fiction and narrative layered on top of those same mechanics.

I thought this would be a perfect illustration of how a game's fiction helps to contextualize a game's mechanics and to inform gameplay.

I tried playing Woosh (the abstract game) and was intrigued. I was a ball that had to roll around and get to a certain point in the map to pass each level. To do so, I had to grab onto little widgets, which started a laser shooting through a patch of red fog. Depending on which way I carried the widget, and (sometimes) how fast, the laser would move up and down. Then I could solidify the laser's path into a platform and roll up it.


I was pretty excited to see how Waker (the game with a fiction) would contextualize such a strange set of mechanics. But then it didn't, at all. It turns out that game is about grabbing onto little widgets to shoot a laser shooting through a patch of fog that changed direction etc etc. The only difference is that instead of a ball you are now a cat, and instead of a door, the exit of each level is a piece of a little girl's dream. The game mechanics are every bit as abstract as in the other game.


Waker presents an interesting story of having to rescue a girl from a dream she can't wake from, and some lovely audio and visual ambiance. But it doesn't try, even a little bit, to explain why the mechanics do what they do, or to clue me in on the kind of gameplay that will be successful. Why does that laser thing move the way it does? What makes it solidify? Why does running left sometimes make the beam lower, and sometimes make it raise? Why does "dying" to different hazards teleport me to different points on the map?

Let your gameplay drive your fiction

The more simple your game is, the more difficult and dangerous it is to try and fit mechanics to a fiction, instead of the other way around. What would have made sense for this sort of gameplay?

For the mechanic of moving up and down based on the player's left-right position, it might have been interesting to make the game about a very heavy character. If the entire level tilted right and left as the character moved across it, and the laser maintained its direction, it would immediately be clear how to manipulate the laser.

For the mechanic of moving faster increasing height, there are plenty of examples from actual physics. If the player were pulling a kite or a plane or a parachute, that mechanic would be instantly recognizable and intuitive.

Why does the path of the laser become a path? It could be exhaust from the plane that freezes, a sawblade that cuts off the tops of walls, an underground drill that makes a tunnel, almost anything.

None of these are million dollar ideas, but I think they illustrate how even the flimsiest justification of a game mechanic is better than none at all. We should never miss an opportunity to help our players feel more comfortable inside the logic of our games.

Glossary

I believe that defining terms is a very important step for game designers. So many of the concepts we deal with are so abstract and malleable that they can be interpreted in almost any way. The most basic description of our job is "making fun," and yet I've yet to see two designers agree on exactly what that word actually means.

Because of this, I think it's important to agree on definitions of terms in the context that you're discussing them, so that subjectivity doesn't become a problem. These glossary posts should help clarify some of the more specific terms I employ when discussing game design.

I'm not suggesting that these are neccessarily the "right" way to define these terms, but they are the ones that work best for me. I find it's much less important that a definition be correct than that everyone in a discussion have the same definition in mind.

Diminishing Returns

For any efficiency, the tendency of increasing costs to be less effective at increasing rewards. Diminishing returns may only apply above a certain cost level, or they may scale over the entire range of possible costs.

Efficiency

The ratio between the cost of an action and the perceived value of its reward.

Essentialism

1) Assuming something to be an absolute truth when it is only true in specific cases.
2) Mistaking correlation for causaulity as a result of such faulty logic

Fiction

The usage of metaphors to present game mechanics and gameplay as a cohesive and logical whole.

Game Mechanics

All stimuli the game presents a player with, in the hopes of encouraging or discouraging certain gameplay.

Gameplay

Anything that a player does or thinks as a direct or indirect result of a game's mechanics.

Narrative

A game's plot or story. This includes the conflict, specific characters and their arcs, the backstory of the world, and the happy ending.

Productivity

The amount of rewards generated in a particular span of time, regardless of how efficiently those rewards were generated or how much effort and resources they cost.
Productivity = (Effort x Efficiency)/Diminishing returns

Career Lessons This Recession Has Taught Me

The economy is terrible, unemployment is up, and all we hear is doom and gloom. Despite all that, a lot of game developers I know are suddenly thriving. In many cases, these are people who weren't doing particularly well before the bust.

The bad economy has turned into a great windfall for those people who have learned and applied the lessons it has to teach us. Here are some of the ones I've learned:

Nobody is looking out for you

It's so easy to be complacent when things are going well - an ok raise, a decent project, and a mostly-not-terrible boss are all it takes to keep most people sitting in the same job for years.

When companies cancel bonuses, skimp on raises, and generally freeze advancement, it suddenly becomes much easier for us to see that we need to look out for ourselves. Since the economy got rough, several of my friends (and myself included) have switched companies, gone solo, or started side projects. Every one of us wishes we'd have gotten the nerve to do it sooner.

Be generous when networking

While you're at it making opportunities for yourself, take the time to give some help to those around you. Helping out other people in their careers feels great, especially when things aren't going so well in your own career. Even the lowest person on the totem pole at a game company can kickstart someone's career by forwarding along a resume to the right person.

As I've mentioned before, I think people worry too much about networking with people who are in positions of power. If you surround yourself with people you respect and enjoy working with, and help them succeed, the results will be positive one way or another.

Don't assume people will be able to return the favor (again, you're the only one looking out for you), but often helping other people goes hand in hand with helping yourself. You never know where your next opportunity may come from.

Market your differences

If there's anybody whose career is legitimately doomed by all this mess, it's the unremarkable developer. That person who's got a little bit of experience, has adequate skills, is a nice enough guy, and worked on that kinda alright game always seems to be the one who falls through the cracks.

When it comes down to who will be promoted, who will be laid off, or who will be hired, companies always seem to give the short end of the stick to the average, forgettable guy. Don't be one of these people.

The industry right now is a great place for seasoned masters, mad geniuses, and eager neophytes. If you've been around awhile or are just really good, you can get that hefty salary even in a recession, because people don't want to take any chances. Sell yourself as the guy who can do the work of 3 mediocre designers for only 1.5 designers' worth of salary.

Likewise, if you've never had a game job before, there are companies eager to hire you too. You can learn the ropes, be molded to the kind of employee they want, and by corporate standards you're effectively free.

Just be honest; If you're a newbie, you'd better not try to represent yourself as something else, because people will see right through it anyway. By the same token, desperate veterans who try to pass themselves off as a bargain will also look very suspicious to a hiring manager.

Fear breeds mediocrity

Don't let this bad situation paralyze you with fear. There's a lot of "I'm just lucky to have a job at all" and "I'm sure if I worked somewhere else I'd be just as frustrated" going around these days, no to mention some "I'm just going to keep my head down and get through this."

All of these sentiments are completely rational, but nevertheless the kind of thinking that can turn you into that nice guy whats-his-name who's unemployed. Fear is always the enemy of a successful career, it's just harder to see in prosperous times when even the unsuccessful people are still doing ok. In times like these, the difference between successful and unsuccessful careers can mean the difference between having or not having a career at all.

If we can succeed in such a hostile job market, imagine how well we'll do when we take these lessons and apply them in a booming economy. Meanwhile, the best defense is a good offense. In short, it's hustle time.

My Interview with FanToPro.com

Steven Savage is one of those amazing bloggers who is constantly churning out good content, speaking at conventions, podcasting, the works. In short he makes me feel like a slacker. His site, Fan To Pro, is a career blog that focuses particularly on turning that hobby you love into a paying gig.

Steven asked me a few questions related to my own transition from game fan to professional designer. In the interview, we talk about breaking in, networking, mentoring, and how game design careers are evolving.