March 29, 2009

Make Cheating Part of Your Game

There's nothing more dangerous to an online game than rampant cheating. Players' willingness to play the game is heavily predicated on having a fair chance to win, or at least the ability to learn the game well enough to start winning eventually. When cheaters take over a game, the designers had better fix the problem quickly, or it's likely that honest players will abandon the game, or become cheaters themselves.

Some cheats are much more stubborn than others. When a kind of cheat has become rampant in a game or genre, and stopping it doesn't seem to work, lesser designers may just give up and allow their game to become a haven for cheaters and nobody else.

There is also another way. There are several examples of great designers co-opting cheating behavior into their game's mechanics. This has the dual benefits of both putting honest players on an even keel with cheaters, as well as making cheating less beneficial and therefore less tempting to new players.

Natural Selection

Natural Selection was a mod for the original Half-life. It was first released in fall 2002, when wallhacking in the Half-Life engine was at an all-time high. The way NS's developers dealt with this problem was brilliant: They gave both of the factions in the game abilities that allowed them to see enemies through walls.

Aliens could shoot a special form of spit at the humans, which would highlight them as Parasited in the faction's hive sight. They could also purchase an upgrade called Scent of Fear, which caused all injured enemies to show up through walls. Likewise, the humans had a Motion Tracking upgrade, which allowed the humans to see moving aliens as indicators through walls.


These abilities didn't totally neutralize wallhackers. They did still have an advantage, especially in the early moments of the game before humans had managed to upgrade to motion tracking. However, the advantage that cheaters received was much smaller, and once the other gameplay systems had kicked in, it disappeared almost entirely.

EVE Online

While EVE was being developed, the main example of an MMORPG with progression based on character skills rather than level was Ultima Online. In UO, the practice of macroing, or automated skill building, had become rampant. Some players would use macros to train their characters 24 hours a day, becoming much more powerful than non-cheaters and forcing them to either start cheating as well, or to quit the game in frustration.

When EVE's developers designed their skill system, they made what had been cheating in UO officially part of EVE, so they could control it. In EVE, every player trains skills 24 hours a day, even when not playing the game. Being able to predict what skill level every character will have based on how long the character has existed must make balancing that game quite a bit easier.

World of Warcraft

A couple of years ago, WoW players were buying in-game currency from goldfarming sites in droves, as well as paying powerleveling services to get their characters up to max level quickly. Blizzard has made several changes to the game since then that have diminished these cheats significantly.


First of all, they introduced daily quests in WoW's first expansion, which are a very easy way for players to make lots of money every day. Players are now more likely to do lots of dailies and send the money to their alts, rather than buy gold online. It's simply too easy to get the money to be worth it in most cases.

WoW's designers also responded to the concerns of players who were unwilling to play the low level content over and over again every time they made a new character. In patch 2.3, leveling speed was greatly increased, making it much easier to get characters to the endgame.

Then, in WoW 3.0, Blizzard introduced the Death Knight hero class, which would allow players to make an alt that started at level 55, further shortening the amount of time spent replaying low level content.

Conclusion

In the first two examples, cheating was introduced by players who wanted a competitive edge. However, in the WoW example, it seems to me that players were really just cheating because the game wasn't giving them what they needed.

Just as pirates may be underservered customers, players may start cheating because they aren't having their needs met. If players in your game are cheating, the most important step is to figure out why they're cheating, which will allow you to implement a countermeasure that actually solves the problem.

March 25, 2009

Eulogy for Tabula Rasa (Part 3)

This is the third of three posts on successful design decisions in Tabula Rasa.
Read Part 1 here
Read Part 2 here

Tabula Rasa let players plan

While I spent an entire post yesterday talking about how TR let players remain in the action with very little downtime, the little downtime it had was very efficient, especially when it came to letting players decide what do do next.

Tabula Rasa's UI always provided players with lots of easily accessible information, which always left me with a feeling of purpose. It also made me happy that I didn't need to constantly tab out of the game to webpages with guides and databases.

Detailed class/power info - I've posted before about how TR let players specialize gradually over time, via several sub classes and sub-sub classes. Also, the preview UI showed examples of powers and gameplay for every class, allowing an educated decision. This was a great example of the kind of thing that most games would make you go to a webpage for, but TR included directly in its UI.


No fog of war - When players entered a new zone in TR, its full content was fully revealed, complete with landmarks and connections to other zones. In some games, the choice to explore would have been more enjoyable, but with TR's self-contained maps and goal-oriented gameplay, I think it was a much better choice to reveal everything immediately. Also, it fit very well with the fiction of the game, as an invading military would have extensive intelligence.

Instance maps and cutscenes - Similarly, expository cutscenes at the beginning of instances and the full instance maps felt like more military intelligence. The cutscenes in particular were sold as military briefings, and really made me feel like I was being sent on a mission, as opposed to a quest.

Great Icons - Tabula Rasa's map and minimap system was one of its strongest features. It was key to both keeping players on the move and helping them make a plan. In particular, the variety of icons it was possible to show and hide on the map were especially useful.

The map icons showed trainers, teleporters, control points and their status, map exits, hospitals, crafting stations, and just about everything else. The added functionality of showing and hiding each of these icons individually was also very useful. I just wish the map would have let me zoom in further.

Quest locations - Speaking of informative icons, nearly all quests in the game displayed special indicators on the map which revealed their general location. This was another good choice, given that the game's zones emphasized action rather than exploration, and the military fiction. It was also a way to keep players in the game, rather than reading quest database webpages.


Information about zones - In addition to its many icons and markers, TR's map also had a list of all the maps in the game, which players could examine whether they'd been to them yet or not. Each map and instance was marked clearly with its level range, and even instances were included. Again, this availability of information fit in with the fiction of military intelligence, and was yet another way to keep players from needing all sorts of extra webpages as a supplement to playing the game.

Built-in coordinates - If even the map icons weren't informative enough, the map's coordinate system easily indicated the location of the mouse cursor. This made meeting up with friends, finding a specific mob, etc much easier than it would have otherwise been.

Conclusion

Well, that's all I've got for now. I'm glad I didn't try to cram this all into one post. Post more comments! It's great to hear some other opinions, and people have pointed out more than one great feature that had totally slipped my mind.

I think it's very important for game designers to have some sense of history, and my own isn't quite as developed as I'd like it to be. I'll probably be posting more eulogies like this for games that have died or that die in the future. When games close down it's a horrible waste of work and love, but it's not a total waste if we manage to learn from them.

March 22, 2009

Eulogy for Tabula Rasa (Part 2)

This is the second of three posts on successful design decisions in Tabula Rasa.
Read Part 1 here

Tabula Rasa kept players moving

Compared to other MMORPGs I've played, TR gave me a feeling of always being on the move. I think this feeling came from a combination of low downtime, easy travel, clear goals, and a lack of grinding.

Required traveling - The Logos elements scattered around each map in shrines were important to character advancement. Even if a new player wanted to stay in one place and grind or be powerleveled, the required amount of movement discouraged such behavior.

Ease of walking - As I mentioned yesterday, the world was populated less densely than other games, but was supplemented by lots of patrols and ambushes. This meant that it was easier to walk from place to place, and move around the world quite a lot, even without sticking to roads or other safe areas. The fact that every character could sprint also helped quite a bit.

Teleporters - Like WoW, TR had a fast travel hubs that could be used once players had walked to the location once and activated the node. Unlike WoW, TR's travel between hubs was instant. This may have hampered the player's sense of wonder at the world's size and scenery, but it definitely helped to encourage player movement. It was easy (and free) to pop back and forth between any settlements, meaning downtime was always minimized.


Auto Loot - In TR, while you can choose to manually loot a corpse, just walking over its corpse will take everything it has. You'll still see the gear you've picked up in your chat log, but because the moment of looting an enemy was de-emphasized, there was much less reason for each mob to have lots of vendor trash and body parts. This helped storage space to be less of a premium (see below).

Plentiful Storage Space - In WoW, storage space is one of the main resources in the game. Extending backpacks is very expensive, but allows the player to stay away from town longer and longer. In WoW I constantly find myself wasting 20 minutes standing in the middle of the wilderness, trying to decide which item I need to throw away so I can pick up something else.

Between TR's large personal inventory and the footlocker in town, combined with a markedly low amount of junk drops, I never found myself worried about storage space or throwing away items.

Tabbed Inventory - Another feature which minimized downtime was TR's inventory sorting tabs in the backpack. When an item was looted, it was automatically placed into the proper page of the backpack: Equipment, Consumables, Mission Items, and Crafting Items. This made it very quick and easy to find whatever you needed in your backpack, both to use them or to sell them. This usability feature should be applied to every game with an inventory from now on.


Auto Quest Tracking - In a lot of games, it's easy to waste many small chunks of time managing which quests are currently displayed in your quest log. I liked TR's method of just automatically including every quest I had into my HUD's quest log, and giving it a scrollable window. This, combined with the fact that all quests locations where marked on my map made it very easy to decide what to do next

Integrated Achievements - In most games, achievements are an extra layer on top of missions, but they don't often do anything useful. In TR, the type of tasks which would normally be marked as achievements were tracked in the mission system, and called Targets of Opportunity.

Some of these missions seem as though they'd be likely to encourage grinding (eg. "kill 200 Thrax"), but they were tuned to align fairly closely with the number of kills that a player would end up doing in that zone anyway. The most efficient way to achieve them was to simply play normally, and then clean up any last requirements before leaving a zone.
Continue to Part 3

March 19, 2009

Eulogy for Tabula Rasa (Part 1)

This is the first of three posts on successful design decisions in Tabula Rasa.

Introduction

When a person dies, we give speeches that focus on their good qualities, even if they may not have had very many. When a videogame dies, we dance on its corpse.

We've all seen the landslide of commentary on why Tabula Rasa failed, how badly, when, whose fault it was, etc. Clearly there were a lot of things wrong with it, but that doesn't mean there weren't some good ideas in there too.

I didn't play it long enough to get to the endgame, but I did see some things that I don't think should be allowed to fade into obscurity. Feel free to add to the list, just keep it civil please.

Tabula Rasa loved alts

Of all the design decisions that the TR team made, the choice to include lots of support for player alts was one of their strongest and most apparent.

Footlockers - It's a given that people are always going to want to send items and cash between their characters. In TR, there were footlockers located in towns, which were very simple shared banks between any character on your account. If you wanted to send some loot and spending money to your alts, you could just drop it in the footlocker and any of your other characters on that server could take whatever they needed.

Shared character surnames - In TR, all your characters on a server had a unique first name and a shared last name. When you spoke in chat, your last name was displayed. This removed all confusion among friends as to which character was which player's alt. It also meant that players couldn't behave badly with no consequences just by logging onto an alt. Have other games before TR done this? It's a brilliant idea.


Cloning - If you ever read gamebooks as a kid, you can probably remember how tempting it was to keep a thumb marking your place just in case your choice led you to a bad ending. Cloning is the gameplay equivalent of that comforting bookmark.

Knowing that you could go back and take that spare character in a different direction later meant it was easy to try out all the classes and find the gameplay you liked best. You could always change your mind and take the other path, or just play both characters for more variety.

Tabula Rasa's world was exciting

Compared to the other MMOs I've played recently, TR's world felt really dynamic and active. They must have spent a lot time scripting each map, and I think it was worth it.

Dropship ambushes - In TR, Large fields full of static mobs waiting to be killed seemed to be the exception, rather than the rule. Instead, enemy aliens would often be deployed periodically by dropships.

The lack of static spawns made it much easier to walk around the world, and yet the possibility of a dropship attack made traveling something that you had to pay attention to a little more than most games.


Control points - The first time I was in an outpost and it was was attacked by an alien army, I was completely taken by surprise. The NPCs all started shouting and fighting, and I was happily distracted from my banking by a surprising in-game event. Seeing enemy-controlled outposts on my map and going to attack them was a lot of fun too, even when other players weren't around.

Friendly NPCs - The reason dropship attacks and outpost battles were fun even when I was soloing was that so much care was put into the friendly NPCs. Everywhere I went, it always seemed there was a squad of AFS soldiers there to help me fight a wandering boss or to help in attacking and defending outposts.

There were actually a few times I was fooled into thinking an NPC was a player who'd helped me out of a tight spot. I ran through several spawns with a friendly patrol and rushed an outpost before I realized friendly dropships were landing and the whole thing was scripted.

There were also lots of places where you'd come across small skirmishes and could decide to help out. All of this care taken with the friendly soldiers went a long way toward making the world feel like a warzone, as well as making it feel as though you were really part of an army.
Continue to Part 2

March 13, 2009

Glossary: Essentialism

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.

Humans love generalizing

Our senses are constantly bombarded with data. If we didn't have the ability to make generalizations about information, we'd be so overwhelmed that we'd have a hard time functioning. In fact, an inability to generalize concepts between different contexts is one of the symptoms of autism.

Evolving the ability to apply knowledge to different contexts helped us respond to new situations in ways that wouldn't get us killed. This "aha!" feeling of making connections is one of the primary pleasures of playing (and designing) games.

However, assuming only helps and saves time when we assume things that are actually true. It's important not to let out of context ideas start building momentum for their own sake.


Our love of generalizing can cause lots of trouble. It leads to our tendency to be prejudiced. We prefer to see things in black-and-white, all-or-nothing absolutes, when this is almost never the case:

The list goes on and on and on. I'm going to use the term essentialism to refer to this type of thinking:

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.

Essentialism in game design

Here are some essentialist ideas that gamers and game developers are often tempted by:
  • Company X only has good ideas
  • Company X only has bad ideas
  • All games must fit neatly into genres
  • All games in genre X must have features Y and Z
  • Game X was fun, and it had feature Y, so adding feature Y to our game will make it more fun
  • Game X wasn't fun, and it had feature Y, so adding feature Y to our game will make it less fun
  • Game X is representative of all games in genre Y
  • Game X's audience is representative of all gamers
  • Game X sold well, so it must be well-designed
  • Game X sold badly, so it must be badly-designed

Avoiding essentialism

It's difficult to resist this kind of thinking, or even to identify it in many cases. It's especially tricky because essentialist thinking isn't necessarily incorrect. It's just never right for the reasons you think it is.

Here's the best tactic I've found to prevent this problem: whenever you're making comparisons between your game and another game, make a quick list of all the similarities and differences between that game's goals and those of your game. Throw them up on the white board.

If a feature failed in that other game, did it fail because it didn't align with that game's goals/audience/gameplay? Is it more in tune with your own game's goals? Usually just taking a moment to compare and contrast will shed plenty of light on the problem.

March 12, 2009

The Winners Write the History Books

When people ten years from now talk about what MMO design was like in the 2000's, they'll be talking about World of Warcraft. One huge game, played by millions of people, will be more or less all people remember. Hell, it's all most people think about already.

Everquest was the same way in its time. The success of Everquest led to the success of WoW, and the success of WoW will lead to more games like it. This is fine, don't get me wrong. WoW's a great game. It's just not the only game worth noticing.

When a game sells really well, its features will be emulated by games that also want to sell well. When a game doesn't sell as well, its features fade into obscurity - even the great ones.

One quick example

Shadowbane was released in 2003, and it never got above 50,000 or so subscribers. A lot of people talk about what a shame it is that the territory control mechanics, player cities, and seige warfare from that game didn't become more popular, but those are all fairly controversial ideas that not every MMO player necessarily enjoys.

However, their incredible UI customization is not a controversial feature at all. Show any MMO player in the world the following video, and I'll bet you a dollar that they say they wish it was this easy in whatever game they're currently playing:



If more people had played Shadowbane, this degree of native UI customization would be considered a basic requirement of every game released. WoW set an impressively high standard of UI customization through mods, but it's not nearly as easy as Shadowbane's system. Despite that, games that come out next year will be held to WoW's standard, not Shadowbane's.

We need to keep track of good ideas from all games, not just from the games that sell the most copies. I'll be posting about more great-but-overlooked features here in the future.

March 8, 2009

White Space in Game Design

[Halfway through writing this post, I realized I had seen the idea of nongoals in design documents somewhere before. Thanks Joel.]

Less is more

Everyone who's ever taken a graphic design course, designed a webpage, or even spent much time reading understands the importance of white space on some level, even if only subconsciously.

In graphic design, the use of space without text allows what text there is to achieve a higher importance and draw the focus of the reader. It's also much less fatiguing to read text that's broken up in interesting ways, compared to giant paragraphs. It's the reason this blog is centered in the middle of the screen and uses small paragraphs, instead of spanning the whole screen and using large paragraphs with no space between them.

Using white space takes self-restraint, though. Think about your resume, for example. It's so tempting to convey the maximum possible amount of information, but doing so just makes it confusing and unreadable. Compared to my grad school resume, my current resume is much easier to read, but it's still probably too dense even after all that trimming.


Know what game you're not making

In game design, there's a very similar temptation to pack ten thousand features into every game. You want to keep players with every possible playstyle happy, sell your game to every imaginable demographic, and include ideas from every member of your team.

Sadly, though, it's not possible to do everything all the time. Even if by some miracle of scheduling and funding you do manage to include every feature every possible player could possibly want, you'll end up with a game that has no focus. And even though each player will have every feature they wanted, they'll also probably have a lot of features they didn't want, which might serve to drive them away anyway.

It's incredibly important to know who your audience is, what types of fun your game is focused on, what features are the most important to get done by launch. However, it's equally important to know which players you aren't shooting for, which kinds of fun belong in another game, and which features would be nice but just serve to water down your game. Likewise, it's important to define nongoals for individual features or fixes.

Teams that don't keep these nongoals in sight end up shipping the videogame equivalent of a huge wall of text. There may be some really interesting stuff in there, but just trying to take it all in and parse it is overwhelming:


If you can't easily describe your game to someone in a few seconds, or if different members of your team give vastly different descriptions of what your game is or isn't meant to do, chances are you've got a white space problem.

Define both goals and nongoals

It's important that each member of your team is easily able to find out what goals are and aren't important for your game. Features will often worm their way into your game because a prominent game has it, one team member really loves that idea, or over time people simply forgot what the team's goals were.

Here are some ideal times to state goals and nongoals for the game or a feature:
It also couldn't hurt to have a very prominent list of goals and nongoals on your internal webpage or pinned up in the conference room.



Save rejected ideas

Just because a certain idea isn't right for the particular game or feature you're currently working on doesn't mean you should toss it out entirely. Keep a section on your wiki, or in your bug database that lists all the things you've decided not to do and why.

Tracking all these nongoals and nonfeatures will allow you to go back later on and mine ideas for a new game, a subsequent expansion, etc. When I used to work on The Sims, we had a section at the bottom of our design documents called "Considered but Rejected," which is where we'd put all of the suggestions that were too low priority or against the goals of the feature, and why.

Leaving these items in the docs helped us avoid rehashing the same arguments over and over again when too much time had passed or a new person was assigned to work on that feature. By spending less time debating which features should or shouldn't be in your game, you'll be able to spend more time on making those features you do include much better.

March 3, 2009

21 Behaviors of Great Designers

Since the purpose of reading (and writing) this blog is to become a better designer, I decided to group the posts based on their goal, rather than tags such as "combat" or "MMOs."

In the process of generating a list of tags that were general enough to cover all the content of this blog, I ended up with a list of the behaviors I think are most important in a great designer.

I thought about referring to these as "skills great designers posess," or "traits great designers exhibit," but I like "behaviors," since it emphasizes the fact that these are all things that anyone can consciously do more often. It also serves as a reminder that even highly experienced designers have to remember to do them.

1 - Admit Mistakes
It's important to know when your design isn't working or one of your ideas wasn't well thought out. This also includes identifying problems in your game that need to be fixed.

2 - Aim For Gameplay
All the most innovative mechanics, compelling fiction, beautiful art, and heartbreaking narrative in the world can't make a good game if it's not in the service of gameplay. Start with the thought process and tactical response you want the player to have to an enemy or location or story, and work backward from there. If you only ever remember one thing I write on this blog, please make this it.

3 - Be Consistent
Players can't learn how to play your game if the game doesn't present them with consistent feedback. Games are also subconsciously much more enjoyable if they present game mechanics, fiction, gameplay, and narrative that are all unified.


4 - Be Efficient
Focusing on efficiency is a positive feedback loop, and the benefits can be huge. One investment of a week working on a usable development tool or a well-written design doc can pay off over months or even years of development.

5 - Be Methodical
Game design isn't a science, but approaching it in a systematic manner can prevent all sorts of difficulties. Clear categories and terminology for data help players learn the game much more easily, as well as making the development process much simpler. Approaching problems in a methodical manner helps to solve them more efficiently and to know that they're really solved, or that they were even valid problems to begin with.
6 - Challenge Assumptions
Challenging assumptions is the seed of innovation. Why is a popular feature so successful in other games? Do you really need it at all? Game design on autopilot is never a good thing. Context is incredibly important in good design, but it's also valuable to consider a feature or decision as though no designer had ever made it before, and weigh out the pros and cons for yourself. Then, even if you do end up mimicking another game, you'll know you're copying the right element, for the right reason.

7 - Collaborate
Aside from a few notable hermits, game designers these days have to be great at working in a large team of developers. Good collaborators communicate well, accept feedback, and know when to throw away their idea in favor of someone else's. Often, the collaborative process also includes your players, a game reviewer, or even your game's competitors. Bad designers are often bad collaborators, but bad collaborators are almost always bad designers.
8 - Define Terms
What are the elements of game design, or of fun, or of a game itself? Game designers come to the discipline from all sorts of backgrounds, and tend to bring lots of different terms and jargon to the process. We need to take the time to be informed as to what people are actually talking about. Even when designers use the same terms, they often use them to mean wildly different things. On top of that, these terms can change their meaning from team to team and game to game.


9 - Don't Panic
Haphazard, knee-jerk game design is always bad game design, even when you're lucky enough that it doesn't come back to bite you. Iterate on design docs, or on a whiteboard, when it's still free. If not, the days you saved by rushing decisions will cost you weeks or months down the road.
10 - Get Your Hands Dirty
The best way to become better at designing is to spend a lot of time actually implementing your designs. The devil really is in the details. You can write 1000 design docs without ever improving as a designer, because the only way to learn is to find out the hard way which parts of those designs worked and which didn't.
11 - Improve Usability
In a way, good usability is the lowest-hanging fruit of good game design. Because there are often obvious right answers when it comes to making a game more usable, it's much easier to get right than making a game fun, which is much more subjective and finnicky. While reworking mechanics and gameplay always involves an element of risk, improving your game's usability is an almost guaranteed gain in quality.
12 - Know The Industry
Thinking about business models, release dates, competition, marketing and the like aren't really part of game design proper, but they are important if you want your game to succeed and your paychecks to continue.
13 - Know Your Audience
You'll eventually need to make some hard decisions between the kind of game your players want to play and the kind of game you'd want to play. This takes a good designer. You'll also have to listen to what your players demand and parse out what will actually make them happy. This takes a great designer.


14 - Know Your Goals
Establishing a solid set of common goals and values for the game you're making is the first and most basic step to making a good game, so of course almost nobody ever does it. Without this foundation to provide context for all of your other decisions, you may as well make a Magic 8-Ball your lead designer. Knowing what game you're making is especially important for being consistent and knowing your audience.
15 - Learn From Everything
Game design is a natural career for polymaths. People whose only interest is games are ironically not very good at making them. Everything from architecture to philosophy to zoology can come in handy when making games.
16 - Stay Objective
Contrary to popular belief, good design isn't about arguing opinions and personal taste. It's about finding the best way to achieve a set of predefined and agreed-upon goals. It's impossible to make objective design decisions if you don't know what game you're making.
17 - Study Games
Since almost anything you can think of has been attempted in some form already, playing games is the easiest, most detailed form of prototyping there is. This includes games someone else has made, as well as teams your own team has already made. There's nothing worse than repeating the same mistakes.
18 - Teach Players
Games need to teach players how to play them through consistent game mechanics that punish and reward, as well as clear UI and tutorials. Your learning curve has to account for the skill levels of all the players who comprise your audience. It's also very important to make sure your game is actually rewarding players for the behavior that you intended it to. When players are misbehaving, it's almost always because the game allowed or even encouraged them to.


19 - Think Ahead
Many designs that sound completely feasible in a game pitch or on the back of a box completely break down once someone actually tries to play them. Promising solutions to problems often cause a whole new set of problems elsewhere in the game. Take some time and work out the ramifications of each decision. This also includes designing extensible systems that won't break down the road when they need to be modified or expanded.
20 - Use Psychology
Game design, at its most basic level, is psychology. By typing on a keyboard, designers create an abstract set of data, which is compiled into an even more abstract set of stimuli, which creates a pleasant or unpleasant thought process inside the head of a person exposed and responding to those stimuli. It's very difficult to type a smile into someone else's brain if you don't understand a little something about people and how they think.
21 - Work Smarter
Imagine that by some incredible fluke, two teams at different companies produced the exact same game. Team A spent many years, way too much money, and whatever fraction of their team hasn't quit or died already is in a fairly grouchy mood. Team B made the same game in a shorter amount of time, for less money, and has a happy team ready to make the next game. How you make the game is almost as important as what you make, especially since so many games with bad process fail before they're even finished.