Monday, October 23, 2006

What are game mechanics?

The phrase “game mechanics” sends a pleasant shiver down my spine. At the heart of every game are these mysterious whirring clicking mechanisms that deliver to the player pleasure and thrills.

We use them, we build them, but I’ve never seen a good unified definition of game mechanics that gives us a practical base upon which to build great games. Here is one. It is clobbered together from a variety of influences though many of you will recognize some central tenets from ‘A Theory of Fun’ by Raph Koster.

Game mechanics are rule based systems / simulations that facilitate and encourage a user to explore and learn the properties of their possibility space through the use of feedback mechanisms.

It is a simple definition, but it offers a good amount of insight into why games work and how we can make them better.

Feedback loops
Central to the model is the concept of feedback loops that encourage learning. Here is a diagram that should explain the concept in a more visual format:

(click to expand the diagram)
  • Player performs an action.
  • The action causes an effect within the simulated game world. The simulation contains public and private tokens and the causal rules that affect the states of the tokens. The player rarely knows all the rules and is highly unlikely to be able to instantly describe the complete possibility space described by the rules. The unknown portion of the simulation is a “black box” that the player must attempt to decipher.
  • The player receives feedback.
  • With new tools and information in hand, the player performs another action. Using what we’ve learned, we pursue additional pleasure.
Linking game mechanics to create a system of systems
Interconnected networks of game mechanics make up the game as a whole. You can think of the game as a set of interlinked of puzzles where solutions to one puzzle lead to clues that help on additional puzzles.

The info treats that a game provides to the user need not be used to solve the immediate black box at hand. Humans horde potentially useful information like squirrels horde nuts for the winter time. We’ll store hints in our copious long term memory in the hope that there will be another black box down the line that will yield to our improved tool chest of knowledge.

The traditional metagame that sits on top of a game’s core mechanics is a good example of how one black box feeds into another. In this situation, the game mechanics are arrange in a temporal hierarchy where rapid feedback loops (often part of the basic control scheme) provide tools that enable the mastery of longer term feedback loops. The potential patterns of linking game mechanics together are nearly endless. This is a wonderful area of future study.

Humans are infovores
Humans are wired to solve black boxes. It is a fundamental aspect of our neurological learning wetware. We get real chemical rewards when we grok a problem or gain information that we suspect will help in grokking a black box. Evolution has selected for this behavior over thousands of generations since it is the biological reward system that encourages tool use and technological adoption. Without this built in addiction to problem solving, we would lack agriculture, medicine, architecture and other fundamental survival techniques that make the human species such a remarkably successful animal.

A key aspect of our model is that games actively encourage learning. I can put a black box on the table with a hidden button. Unbeknownst to a potential user, pressing the button enough times and the black box will spew out a thousand shiny silver coins. This is not a game. This is a bizarre gizmo.

To turn it into a game, a game designer would need to do several things.
  • Encourage Discovery: First, make it obvious that the button in meant to be pushed. Humans are naturally curious creatures, but as game designers, we need to explicitly direct them to take certain actions.
  • Encourage Exploration: Second, the designer would put a counter on the front of the machines that lets the user know that their actions are having some impact on the system. The counter provides delightful drips of feedback and it is up to the user to interpret that feedback
  • Provide Tool Mastery: Third, the designer would post a note “Payout: 1,000, coins!” Not all games need explicit winning conditions, but hinting at future utility is a highly useful technique for encourage the player to begin interacting with a particular game mechanic.
We’ve turned a gizmo into a simple game of chance. The difference between the two is that our primitive 1-armed bandit is explicitly designed to encourage player learning.

Existing games are richly laden with techniques that encourage learning. A few that come immediately to mind:
  • Levels take complex systems and encourage players to explore and master one aspect of the possibility space at a time
  • The use of scores, coin collecting and experience points are all simple feedback mechanisms that let the user know they are making progress towards some future state.
  • The classic “See the treasure chest you can’t reach” in Zelda acts as a promise of future utility.
A system alone is not a game. A dump of information is not a game. A system that encourages learning through strong feedback mechanisms is a game.

Secondary effects
I’ve just described the foundation of a game mechanic. Now lets dig into several of the secondary effects that immediate appear when you attempt to put this system into practice:
  • Burnout
  • Milking
  • Red herrings
  • Human factors
Burnout: A definition
After merrily harvesting tidbits of information by plunking coins into the virtual pachinko machine, the player will eventually grok the system. The game mechanisms may still serve up information, but the tidbits are not longer as tempting. The info we receive has no resonance with problems that we are solving or problems we have solved. It activates no curious networks in the brain. We begin subconsciously filtering out the feedback from these mechanisms. Burnout is a state of completed learning where the player finally figures out that a particular action no longer yields meaningful results.

In Monkeyball, researchers were astounded to find the the biggest jolt of pleasured occurred when you fell off a cliff and died. People loved it! If you look at falling off the cliff as a huge learning experience, this makes perfect sense. However, when they replayed the animation, people hated it. Same stimulus, radically different response. The animation of falling off cliff lost its ability to teach the second time around. Ultimately, users are subconsciously constantly asking the question “Is this activity worth my time? Does it gain me anything useful?”

Premature burnout
There are multiple paths that learning can take and not all are ones that game designers desire. We would like to imagine that groking a system results in complete and utter mastery of that system. In reality, ‘grokking’ means that that the user has stabilized on a mental model of the system they no longer feel like improving further. This model can be simple or complex, depending on the inclinations of the user.
  • A complex model of Black Jack might take into account probabilities of cards appearing based off what has already been played.
  • A simple model of Black Jack might conclude that cards appear pretty much randomly. There is more depth for the user to explore, but if they are a casual player, saying it is random is ‘good enough’ to judge the game.
A big frustration to game designers is that many users settle on a very simplistic model of how a particular game mechanic works. Players will claim that a game is unfair or too difficult and immediately toss it in a rubbish bin because the designer misjudged their reaction to a game mechanic.

Some mechanisms have highly predictable burnout rates. Most players immediately figure out that watching a cutscene again isn’t going to provide much additional information. Other mechanisms demonstrate a large variation in burnout rates depending on the person who is playing the game and their personal preferences and disposition towards addiction. Some players try a slot machine once and then never again. Others will ruin their lives in pursuit of the next reward, never grokking the simple truth that such machines exist to take money, not give.

The factors that influence burnout are numerous.
  • Personality.
  • Personal history.
  • Practical importance of imagined future rewards that stem from mastery.
  • The ability for the mechanism to signal that there is additional depth of mastery possible.
The first two factors are not possible to derive by simply exercising your superior intellect. A deep understanding of your target audience’s psychology is most helpful here. The second two factors are very much under the designer’s control and can be refined through heavy prototyping and player observation.

Milking: The transition from learning to tool use
The flip side of burnout is grinding. If burnout is when a player discards a game mechanism because it is no longer useful, milking is when a player continues to exercise a game mechanic long after they’ve reached the state of mastery because the game mechanics continues to provide value.

When a player has learned one system, they will often keep interacting with it. On first blush, this seems mildly demented. The activity no longer provides burst of juicy learning. It is a bit like jawing on a piece of gum that long ago lost its flavor.

However, remember that games are networks of linked game mechanics. Player will continue to interact with a mastered game system in order to create a useful game state for exploring another black box. Mastery gives the player predictable pragmatic tools that helps them advance in other aspects of the game. The learning and mastery that occurs in other portions of the game provide the necessary reward that goads the player into revisiting old game mechanics.

You can extend the time that a player spends with a set of a game mechanics by ensuring that a mastered system still provides utility to the player. Designs techniques that build tools result in more gameplay for less development work.

Red Herrings: Black boxes external the game
The network of blackboxes that the player considers valid can extend far beyond the systems in the game itself. Often, the player will collect strange bits of info that have no real impact on the game mechanics that the game designer built into the game. These pieces rattle around in our heads like a collection of oddball keys for a set of locks that we may never find.

Game designers can tease the player with hints to systems that do not exist in order to suggest depth to their games. A sly arched eyebrow in a cutscene triggers as massive cascade of meaning alerts. Our brains love people and faces and relationships and the breeding opportunities and politics! Surely, that eyebrow is important? The player greedily stores the memory away.

What impact will the collected information have on their gameplay? None. What impact will it have on their lives? Very little. This virtual person in a cut scene is no one they will ever meet. But our brains were not evolved to deal with such things. As apes, the tale of an arched eyebrow by a potential mate from our little tribe always meant something very, very important. So our brain rewards us with a little jolt of pleasure for noticing such an “obviously” beneficial tidbit.

The designer managed to suggest a system and get some of the benefits of that system without actually building it. It is not going too far to suggest that paintings, sculpture, movies and television all thrive on this simple quirk of our brain’s learning systems.

The downside is that such red herrings burnout quickly. Our brains becomes quite good at recognizing false, useless information. Almost no one watches a cut scene more than once. What would be the point?

My personal bias is to use red herring game mechanics sparingly. As game designers, we have deeper skills at our disposal. We can tailor potent electronic cascades of feedback loops that spin out a complex duet between computer and the player. Such system are highly effective at causing visceral pleasure and encouraging deep long term learning. As game designers, we conduct a majestic symphony of explicit learning and entrancing interactivity, something no static media will ever manage.

Sometimes though, it is worthwhile to suggest great mysteries with broad brush strokes. Setting, character design and plot can be crucial hooks that help make a game meaningful to players before they even press a single button.

Human factors: Emphasizing the humanity of games
Some folks read about models and immediately see them as reductionist mechanisms that strip the humanity out of the soul out of creating artistic games. The game mechanics I’ve described in this article attempts to avoid this trap. They explicitly include social, narrative and emotional elements in addition to purely analytical problems. All aspects of the human experience, that have an impact on our ability to process and learn from stimuli, fall within the domain of potential game play.

This definition of game design is much broader than the current range of games available on the market. Though it works quite well with hit points, button mashing and high scores, the breadth of the definition is intended to encourage exploration of a much wider range of human learning. Some open questions that I find immediately suggested by the model include:
  • What are the feedback mechanisms that impact learning about relationships, love, hate or spirituality?
  • How do we build games around such topics that leverage these feedback mechanisms?
Existing games give us the foundation of practical knowledge that lets us make the same thing in a reliable fashion. A good theoretical framework helps game designers create future titles that are inclusive of a wider range of human experience.

The goal of any model of game design worth its salt is that it both explains existing behavior and predicts future behavior of medium. In my experience so far, this model seem rather robust at explaining almost any existing game on the market ranging from board games to slot machines to social games. There is certainly room for improvement, but it is a good enough for my main goal.

I want a practical model that lets the good folks in this grand industry describe game designs in more exacting terms. The model should give insight into why their prototypes suck. It should allow them to discuss potential issues and solutions with shorthand language that cuts to the meat of the matter. A good predictive model allows for more intelligent design decisions with less waste and unnecessary rework.

So some of aspects of the model that I find useful:
  • It treats game mechanics as well defined, comprehensive atomic units. These units can be discussed individually and they can also be linked together in interesting ways.
  • Explicit identification of user value. Fun is not a nigh spiritual activity that spontaneously bursts forth from the ether. It has a testable neurological basis.
  • There exist clearly inputs and outputs that easily identified. You can easily tell when a specific game mechanic has all component elements such as actions, rules, tokens and feedback systems. Through observation, you can identify the player’s reaction to each mechanism and then adjust its impact.
All and all, the hope is that this model of game mechanics is a good foundation for future discussion. It is one that I’ll be leaning on heavily as I continue to meander through this lovely little series of essays on game design.

Take care

The pleasure of killing monkeys
See research lesson #1. I don’t agree with their conclusion about what causes the reported result, but I find the data fascinating.

A theory of fun for game design: Raph Koster
Many of the basic concepts in this essay build upon the ideas in this book. I find it helps my thinking to rework what I’ve read in essay form. Call it a form of active listening if you must. (

Feedback loops
A slightly different definition of feedback loops that comes from control theory.

Games are designer foods for infovores

Other loose ends
This essay became too long and started budding little essays. Some have been planted in new documents that may one day emerge in full blossom. The rest are here for your reading pleasure.

Is a book a game? With this big emphasis on learning, there is bound to be a wiseass who asks “Is a text book a game? It too encourages learning.” The problem here is that there are few strong feedback mechanisms evident. The user reads the book and without a doubt they get a burst of pleasure from ingesting the info. However, the act of turning the pages, and interpreting language are skills mastered through other activities ages early. At best, reading the book is an example of milking, where a player uses a mastered technique to advance the grokking of some larger blackbox.

The primary role of content. In this model of game mechanics, content in the game is meaningful only through it’s association with a feedback mechanism. Plot points become reward and hints, Damage becomes a punishment that clues that player into the fact they shouldn’t be doing something. There is no such thing as an inherently pretty picture that exists ‘just because.’ The image is pretty because it activates the brain’s learning systems which in turn feed back into actions.

In order to answer the question “what content does my game need?” you need to first answer the question “What feedback should my game mechanics provide to the user based on their actions?”

Sunday, October 15, 2006

Persistent myths about Game Design

The straw man concept of game design involves the sole genius game designer who writes his thoughts on a golden tablet and passes it down to the production minions to build.

There are several beliefs about the process of game design and development evident in this stereotype.
  • Heavy upfront design and preproduction are critical to the creation of a great game.
  • When these activities are not done early in the process, there will be mistakes made later in the development that are almost impossible to correct.
  • A single individual must drives the creative design process. Otherwise there will be a lack of vision that cripples the project.
To this day I still come across designers who enthralled by such philosophies. How often have you heard comments like:
  • “If only we had more preproduction time, we wouldn’t have run into this problem.”
  • Or “If only I had been given more creative control, the product would have turned out better.”
These statements sound quite reasonable and many of us can bring up examples where such practices appear to have worked. However, as the industry becomes more experienced, many have come to understand that traditional upfront design presents a myriad of problems including delayed schedules, conservative design choices and years of our lives spent producing game designs that customers simply don’t want.

Our development beliefs have deep roots in the creative processes that have been historically promoted as the right thing to do. Let’s look back at why they are so prevalent and why they fail when applied to modern game design and development.

Historical Roots: Software development as an engineering discipline
Back at the turn of the century, manufacturing believed that heavy upfront planning was the key to efficiency. The mantra was “Do it right the first time”. There is a rich history of ‘time and motion’ process development where learned men with stop watches would plan out manufacturing steps performed by their laborers to the second. Software development, in an attempt to add rigor to their fledgling discipline adopted the manufacturing philosophies whole heartedly.

The following are wisdom gleaned from this ancient era. In small doses, they are quite beneficial. When they are followed dogmatically, time and experience has proven that they destroy projects.

Myth: “Upfront design reduces risk”
We all are familiar with waterfall style preproduction, production, post production cycle. The idea is that by planning upfront you think through problems early and avoid stupid mistakes. In this line of reasoning, the longer you think about a problem, the more edge cases you’ll discover.

When teams are given plenty of time for upfront design, they will typically design elaborate systems for problems that do not really exist. The interaction of software with users is notoriously difficult to predict. Problems emerge from the most unlikely areas and other issues that take of dozens of hours of planning end up not being all that important. When a team plans in isolation from feedback, the result is bloated software that either poorly solves the actual problem or does not connect with the users needs.

A better technique is to test your ideas early and often.
  • Build working systems that you can show to users as early as possible. This allows you to gain real world knowledge at the earliest possible point.
  • Try multiple paths early in development. This results in the cross fertilization of expert knowledge necessary to create truly innovative solutions.
  • Do the simplest thing possible. Instead of worrying about every contingency, do the simplest thing that will solve the problem at hand. If you get feedback that it needs to be improved, go for it. This dramatically reduces feature creep.
  • Defer decisions as long as possible. The longer you can gather information, the more likely you’ll make the right decision. This may smack of being wishy-washy, but it is an attitude that encourages building flexibility into the system and allows you to adjust to feedback more easily.
  • Iterate: By building rapid feedback cycles into your development process, you’ll converge on an optimal solution far faster than you would if you spent time in planning.
  • Include customer feedback. Play that game constantly. Watch others play the game. Collect real world data and share it with everyone on the team. Act on the problems you witness.
There are two forms of risk, execution risk and design risk. Execution risk is the risk that the project will not be completed as planned. Historically, it is what our fledging industry has been overwhelmingly concerned with. “Can we even make a game?” Design risk is the risk that you will complete the wrong product. This is where mature developers should be focusing their effort “Am I making the right game?” Upfront planning focuses on reducing execution risk. In reality, long preproduction delays the production effort and results in a product that is disconnected from the needs of the market.

Rapid iterative development reduces both production risk and design risk. Design risk is reduced by constantly reconnecting with the customers. Production risk is reduced because you find that you often need to do a lot fewer features in order to satisfy the core customer’s needs. It is amazing how you can cut production schedules by simply doing half as many features. Just make them the right customer focused features instead of the flights of fancy of a planner locked in a dark room.

Myth “The cost of change increases exponentially as time goes on”
Many conservative design decisions are motivated by fear of change. We are told that a change late in the process will cost 1000 times as much as a change early in the process. The argument is that it takes five minutes to write a spec, two days to program the feature, two weeks to test it before deployment and a month to write a patch that fixes a problem after deployment.

This belief encourages logical people to optimize their behavior in peculiar ways. The first inclination is to create highly detailed plans of action that are presented to the production teams as the Bible for the game. Some common problems include:
  • Locking into design details before real experience based information is available
  • Locking the development team into a design that is guaranteed to be wrong.
  • Discouraging ‘Aha’ moments that occur later in development as the team learns about new and exciting attributes of your emerging gameplay. If it isn’t in the plan, it doesn’t get developed.
Second, you want to choose the lowest risk designs as possible. Changes are expensive and low risk designs are less likely to change. The result is a glut of surprisingly narrow minded design decisions made early in product development.
  • Choosing well known designs that are already implemented in other projects over new designs that have multiple unknowns.
  • Discouraging experimentation after preproduction in the belief that it will lead to difficult to plan for innovation and feature creep.
It turns out that the act of attempting to control the cost of change through waterfall techniques bloats the cost of even simple activities. The team puts on spec blinders, focuses on low risk designs and fails to consider the surprising solutions that appear when smart people slowly attain mastery of a complex system. The process itself of excess upfront planning causes the exponential cost of change, not the inherent nature of the work.

When you take the same activities in put them in a software development environment that emphasizes rapid feedback cycles and modern coding techniques, you see a much flatter cost of change. This requires systematic changes throughout the team, not just in the area of game design.

Introduce flexibility into programming activities:
  • Refactor religiously. Use a language that lets you refactor and make refactoring part of your daily coding habits.
  • Use modern source control and coding standards.
  • Reduce rigid code ownership. This ensure that the right person is available when the time comes to make a change across multiple areas of the program.
  • Encourage unit test suites. This builds a safety net that allows programmers to experiment without worrying about irreversibly breaking existing code.
Introduce flexibility into artistic activities:
  • Create highly reusable artwork that follows a standardized format. Procedural content is a must. One shot disposable artwork such as cinematics or in-game cut scenes should be avoided.
  • Reuse artwork from previous projects. Prepare to ship with some of it.
  • Use easily replaceable dummy artwork to prevent bottlenecks during rapid design iterations
Introduce flexibility into design activities:
  • Keep design documents simple. Try post-it notes stuck on a wall in a team area.
  • Use prototypes instead of design documents. If you can’t play a game mechanic, you are just waving your hands. This is often worse than useless since it can hide really bad mistakes for surprisingly long periods of time.
  • Rely on reusable game mechanics instead of one shot level design. Think football, not Disney rides.
  • Be very willing to cut scope. 80% of the designs that you suggest should not ship. Reevaluate your design after everything iteration.
There will always be major features that are difficult to change, but these should be the exception, not the rule.

Myth: “A specialized workforce organized into functional silos is the key to productivity”
The heart of the concept of mass production is that complex system can be decomposed into a series of easily manufactured pieces. The production of these pieces can then be streamlined and created by a specialized workforce that sequentially processes each step of production. An underlying assumption is that if each one of those pieces is built in a high quality fashion, the assumption is that the system as a whole will be of high quality.

Many game developers embrace this strong division of labor. The game designers sit in one area of the office and plan the game. The programmers sit on another floor and implement tools and game systems. The artists are outsourced. Each group is managed based on meeting individual goals associated with their specialized task. The work then flows through each team in a regimented fashion with very narrow bandwidth communication between each group. The design documents and Gant charts describe who should pass off what materials when. And the whole system hums along like a giant clockwork machine.

This does not work. Developing each aspect of a game in a vacuum leads to the following:
  • A rigid inability to change. When an artist realizes that they can improve their process by changing up a few steps, there are often few channels of communication or incentives for communicating these changes to other groups. Often each silos will actively attempt to kill change in other silos in an attempt to “stick to the plan.”
  • A lack of an overall vision for the product. When change does occur (and it inevitably will), each silo begins to drift out of sync with one another. If the drift goes far enough, each group will end up with distinctly different visions of what the end product should be.
  • Isolated silos of workers protecting their own turf. With separate goals and visions comes conflict. Dominance games, unhealthy compromises and apathy are common.
  • Massive integration costs. Often games are integrated together at the very end of the production cycle. Many projects that are not playable in whole until only 20% of the schedule is left. The cost of shoehorning divergent systems and teams together after months of primarily independent development tends to bring up substantial technical and personnel challenges that no one predicted.
Having a team filled with skilled experts is a good thing. It ensures that you don’t end with jack of all trades, but master of none. But once you get those experts, you should seat them together and encourage cross training between disciplines. This ensures a shared vision and helps reduce sub-optimization.
  • Sit cross functional teams together. Being within shouting distance of your artist or your programmer increases the bandwidth that you have for communication by a factor of 1000. This means that the vision for the project is constantly reinforced. It also means that experts from each discipline can come together to solve very tricky problems in a relatively straightforward manner. You’ll come to decisions in 1/10th the time and your decisions will be more well rounded and better informed.
  • Make each team no larger than 10 people. When you get more than 10 people, communication suffers. Maintaining group cohesion requires more management and ape-like ‘social grooming’ time. Teams of around 5 to 10 typically have the highest per person productivity. String multiple teams together with a system like Scrum if need be.
  • Build working games, not isolated systems: Integrate early and often. This goes hand in hand with iterating rapidly and prototype driven design. Each cross functional team has everyone they need to make a complete working game from the start of development. By integrating early, you’ll exercise your development pipeline and you’ll encourage each discipline to being working together early in the project.
Myth: “There is one game designer who holds the vision for the project”
The artist of the previous century has been lionized as a lone creator who imagines a visual in their head and single handedly copies it onto paper, film or clay. On the traditional art project, single artiste owns the creative process from concept to execution.

Shakespeare, Picasso, Rodin dominate our art history. As tribal apes, our innate bias is to assign ownership and dominance to a few individuals at the top of the social pyramid. If the vast majority of publicly celebrated creative works of the past have been attributed to a single artist, then surely game design must follow the same model?

The only problem here is that most games are not created by a single person with genius level skills in a mature craft. They are team activities that involve the creation of complex, new-to-the-world interactive systems.
  • Games represent a class of problems that benefit greatly from collaborative problem solving and use of specialized skills. It is difficult (though not impossible) for a single person to make a modern game. Teams typically produce more enjoyable, more fully realized experiences.
  • Communications issues dominate the creative process, not individual creativity. It is more likely that 10 moderately creative people who can communicate will create a great game. A massively creative person who cannot communicate is outside the game design sweet spot.
  • The ability to solve new problems is more important than the mastery of craftsman-like skills. Game design involves exploring and manipulating complex system that have highly unpredictable results. Every day presents a new set of problems that no one in the entire history of the world has ever witnessed. This is very different than a person getting to spend ten years working in a stable medium such as oils or clay that haven’t changed in the last century.
These are big beefy differences between game design and traditional art that have a deep impact on the process of creating a game. When your team insists on following the model of a single grand designer, expect the following:
  • Communication issues come to a boil: Team conflict increases as people feel they are not being heard. Talented team members may leave the team.
  • Artistic quality is low: When one person makes all the decisions, they tend to ignore the expertise that is inherent in all the other team members. A thousand little decision that could have been made with expert knowledge are left up to a single person who cannot possible understand all the nuances. The result is Star Wars Episode One.
So when you get down to the practical matter of making games, the historical metaphor of the lone creator offers few if any practical lessons. Certainly, the tale of the lone creator is appealing and perhaps inspiring, but by no means does it represent the pragmatic sweet spot of modern game development. Instead consider the following:
  • Train everyone on the team in design. There can still be someone who champions design concepts, but everyone on the team should know the techniques, practices and philosophies of game design. If the lead designer is hit by a bus, the rest of the team should be able to quite merrily finish up the project.
  • Use a coaching model to lead the team. Instead of saying that there is a king figure from which all design flows, push out responsibility to the team members and use leadership positions to encourage learning and transfer of wisdom. The best game design ideas will come from the devs in the trenches. It is the leader’s job to unblock the flow of ideas from bottom, not push ideas onto the team from the top.
  • Reward the team, not just the leadership: Everyone on the team makes the game, not just a few leaders. It is easily to fall into the trap of ascribing success to the inspired leadership and failure to the team. Act against the biases inherent in our damned monkey genes to prevent stratification within the team.
What happened in the rest of the world
Much of this advice may seem counter intuitive or impractical. The majority comes from hard won experience trying to fix systems that were broken.

Just as software development was discovering the tenets of “Do it right the first time,” manufacturing was abandoning intensive upfront planning and design. About three decades ago, Japanese firms introduced the concept of lean manufacturing with an emphasis on strong team work, continuous innovation and just in time delivery. Decisions are made as late as possible when the most information is available. The workers at the lowest levels of the organization drive innovation, not planners detached from actual work conditions.

Lean manufacturing brought about a revolution in manufacturing efficiency. Quality and innovation increased while development times plummeted. The massive planning phases and risk avoidance of previous generations turned out to be more of a burden than a benefit. Those who did not adopt the new agile methods of production where driven out of business.

I expect a similar transition to occur in the game industry over the next decade or two. The market abhors waste and our industry is currently very wasteful of its development talent.

Lessons from the straw man
There are many game developers who no longer build their games using massive upfront design with regimented silos of specialized workers. Throughout the industry there are bright spots of individual developers doing great things to make the process of game design more agile and responsive to customer needs.
  • Valve is known for its cross functional Cabal system.
  • Spore is known for its strong prototype driven development and procedural content
  • High Moon is known for its agile software development techniques.
We are all trying to design a great game. It is worthwhile to note what does not work. More preproduction is not the answer. Bigger teams are not the answer. Finding the one right game designer is definitely not the answer. Game developers need it burned into their skulls that project that follow the “Get it right the first time” philosophy tends to be devoid of innovation, over budget and lacking creative cohesion.

The process of game design is undergoing a fundamental shift. As an industry, we moving beyond our primal fears of failing to complete a game and are beginning to ask “How do we build the right game?” In order to do so, we must throw away many of our borrowed practices.

So if game design is not the act of a creative genius passing down tablets to the team from on high, what is it?
  • Game design is about listening to customers and getting rapid feedback on working software, not writing fantastical design novelettes.
  • Game design happens throughout the development process, not just in the pre-production phase.
  • Game design is a collaborative team activity, not a solo activity.
Take care

Lean software development: An Agile Toolkit for Software Development Managers
This book is a good overview of how lean manufacturing concepts can be applied to software development. Of particular interest is the concept of ‘waste’. Highmoon claims that some of the exercises suggest a 50% reduction in cycle time is possible in their current development techniques. That is awesome.

Valve’s development process
Valve is a fascinating example of applying many of the principles mentioned in this article to a linear “Disney ride” FPS.

An illustrated explanation of reality of game design planning
I love these pictures. They are so spot on.

Agile development blogs