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.
- “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.”
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.
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.
- 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.
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.
- 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
- 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.
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.
- 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.
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.
- 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.
- 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.
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.
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.
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