An Overview of the Design Process
So now that you understand that's it's important to have a good design process, you should first be sure you understand the entire game-development and design process. I want to take the development cycle we’ve been talking about and expand on it some more. This expansion fits well into the front-end development cycle I’ve been talking about, and helps refine it even further.
This elaboration of the development cycle may not be helpful for everyone on the team, but as a designer I think it is critical. As you read more of the article and begin to understand the big picture of game development, you will hopefully start to understand why this refined process is helpful.
I’ve talked a little bit about how scheduling is so important to game designers. This is actually a fairly controversial subject, since creative people hate to work on a schedule and would prefer to just do it the best that they can, no longer how long it takes. Publishers are often the ones to establish the Milestones and deliverables for a project. Most publishers don’t usually request design deliverables early on however, and leave this area very vague. It is very important that a designer stay on track and on time, since more often than not, any changes and slow downs the designer encounters will be amplified out to the entire team and project.
This more refined design and development process was the first step for me in trying to define what needs to be delivered and at what point in the project for the designers. Later on in the article we will get more heavily into how to more accurately and realistically schedule the design. For now just keep in mind that there are some reasons why this breakdown will be helpful to you.
I've identified 10 main stages of the game-design process for this article. These stages fit into the different phases of the overall game-development process. Because there can be different stages to a game design, and because stages are often repeated, it is important to separate the different stages and phases of the game design for this discussion. Keep in mind that there are key deliverables which will need to be created for each of these stages, which I’ll go over in a bit. Not every project will need to create every one of these documents or deliverables however.
I find it best that when you’re trying to establish a development process, that you create a set of standards so high that it’s almost impossible to reach them all. I’ve seen process documents from large companies that were meant to make everyone happy. In order for them to make a process document that outlined a process which was acceptable for every kind of game out there, they basically had to say “Do it however you want”. It’s impossible to create a process which will work on all games and at all companies. My goal is to always set a bar that is really high, define documents that may never need to be written, and to breakdown the process in as much detail as possible so that I have a goal to strive for. I would much rather have someone say that this document is unnecessary for their project for these reasons, than have someone never create the document because they never even realized that they should have created it. Some people will say that this approach is excessive, but if it gets you to think about the game development process and what really needs to go into it, then I have succeeded.
This breakdown is the best way for you to start thinking about the game development cycle as you’re getting into it, but this isn’t necessarily a formalized breakdown which the entire industry uses or goes by.
The Phases of Game Design
Phase 1: Concept
Stage 1: Concept
Phase 2: Preproduction
Stage 2: Vision
Stage 3: Definition
Stage 4: Creation
Phase 3: Prototype
Stage 5: Play
Stage 6: Refinement
Phase 4: Production
Stage 7: Expansion
Stage 8: Completion
Stage 9: Balance
Phase 5: Post-production
Stage 10: Conclusion
Of course, the Stage are similar to the Phases of the game-development process because they take place within the Phases. However, because they make up important substages of the overall design process, it's important to discuss them separately. Typically, each of the game-design phases is also a key milestone, with a specific design item that must be delivered.
This is an important point to understand. These phases aren't just random or arbitrary; they are designed so that you create your game in the right order and at the right time. Later in the article, I talk more about what it means to formalize your design and why you need to do it. These phases directly speak to this. You need to realize that each of these phases must be tied to a schedule and that you must hold to this schedule as much as possible. These phases also take into account that designing games is a creative process, so even if this seems rigid, you should hopefully understand at the end that this phase schedule is actually a very creative and flexible process.
Some phases include starting or finishing a major document, completing a series of smaller documents, and completing a proof of concept. I’ll briefly talk about all of the various documents you may need to create at these stages here, and then later on throughout the article I will talk in more depth about how to develop all of them. The design process is organized in layers, with each layer building on the one before it. As you'll see, creating a game is a bit like baking a cake.
The Proposal Phase of the project is the most informal phase of the project, when the initial ideas are coalescing into a game idea. Concepts are created, examined, and then thrown out. This is the stage in which all the seedlings of a game first take tentative root. At some point, the ideas become strong enough to write down and detail them. During this stage, a basic concept or "pitch" is created. Think of a pitch as a short summary of your game that you can use to get someone interested in your game idea.
Similar to the first stage of the game-development process, the initial phase of the design process is all about ideas. This phase doesn't have a great deal of formal process to it, but instead it requires a lot of brainstorming. The main point of the concept phase is to sift through a lot of ideas in search of a central "tentpole" concept that will become the basis of your game. To keep beating the cake analogy to death, this is equivalent to perusing the recipe article and picking your main ingredients. You might not know what kind of frosting or filling you want, but you had better figure out what kind of batter you're going to use.
The pitch doc is often one of the first documents you formally write. This doesn’t mean that it is the first thing you write, but once you have a good idea of what you want to make, you can start to create this document. This doc is more of a marketing or hype-doc as I call them. It’s meant to give people a high level view of your game idea, get them excited about it, and then ultimately fund or approve the next stage of the project. This document is often a short one or two pages. Keep it simple, and make it sound fantastic.
The concept doc is the first pass of the design document. It is where you start to write down your key concepts of the game. This document is for the design team to gain a better understanding of what the game is all about. It focuses on core gameplay, mechanics and what makes the game fun.
During this stage, the pitch is developed more thoroughly into a set of documents that describe the game in enough detail to create a prototype. This means that you are confident enough about your ideas that you can describe them in terms that enable programmers and artists to build a prototype and be fairly confident that it will work. The preproduction phase is often the shortest phase of the design process for many developers because there are always a million reasons why it is important to build the game now. This is usually the wrong approach to creating a good game, so I encourage you to fight for an adequate preproduction stage to allow you to properly design your game. The bulk of the game design should be done during this stage because good preproduction should lay a foundation that will make the rest of the project much, much smoother. By the end of the preproduction stage, you need to know exactly what you are going to build in your prototype.
In the vision phase, ideas are first put down on paper. You've picked out your main ingredient; now you have to create a recipe. Here's where your vision gets tested: Is there enough of a central concept to attract other great ideas, or is your idea of a role-playing game set in downtown Manhattan at rush hour just not cutting it? Throughout this phase, you will find yourself throwing out ideas and starting over many times. Eventually, concepts will start falling into place and you will actually write down a few recipes, asking people what they think of each one and what might make the cake taste better. I cover creating the vision for the game and the corresponding documents and steps involved in part 10, "Creating the Vision."
The vision statement is a tool that helps the entire team keep one central focus throughout the life of the project. A good vision statement will help the team clearly understand what it is that you are making, help focus the team members on a common problem, build cohesion among team members, and make it easier to make decisions about the project. A good vision statement helps clarify and prioritize the goals of the project.
A proper essence statement should tell anyone who is unfamiliar with your product exactly what it is in a very short period of time. This statement should include your vision and goals for the product.
During the second phase of the design process, most of the important details of the game are figured out, including the core concepts, game play, and general mechanics for the game. During this phase, you need to get your recipe down on paper and make it as complete as you canand that's not so easy when you can't actually taste-test anything yet. During the definition phase, you work on developing the creative vision of the game, which I cover in Article 10, "Creating the Vision."
The Creative Spec is the document where we start to get to the bare-bones of the game concept. This will be a working test model for the game. It may be redeveloped time and time again, but the Creative Spec. is the vision that will keep the game focused on its Essence Statement.
During the Proof stage of the project, it is time to show that your ideas will work. A lot of times this work is done by someone in marketing, but as a designer you need to help. This is the point where you need to thoroughly analyze the market and show why your game will succeed.
Competitive Analysis Doc
Doing research on your competition can take a lot of forms. You can analyze sales numbers, market trends, feature sets, reviews and a host of different information. Creating this document helps you thoroughly understand the competition.
Proof of Concept Phase
The proof of concept phase (POC) is the point where you’re ready to prove and show that your game idea is solid. This often includes building a partially working version. In the front end development model, this is the point where you iterate your game design several times if necessary, until you know if it is going to be fun and compelling to play. In the past, we’ve traditionally called this the prototype phase, but recently we have found that a “pre-prototype” phase is extremely helpful in refining ideas earlier on. A lot of projects get thrown from prototype into full production very quickly, so the more time you have to iterate early on the better.
The creation stage is the point where you’re ready to dive in and start writing the main design document for the game. So, now you’re ready to buy the ingredients for your project. This stage is where you take all the ideas you’ve created up until now and coalesce them into a nice cohesive design document which a game could be created with. This recipe has all the ingredients (characters, mechanics, storylines, and so on) described in detail. In Phase 2, you know the ingredients of your recipe, but you're not sure of the quantities of each one or how long they need to be cooked. In fact, to really make your cake, you're going to have to bake a few and adjust the recipe accordingly. During the creation phase, you must create the design for the game's prototype, which I cover in detail in Article 11, "Designing the Prototype."
Prototype Design Document
Any information that needs to be implemented in the prototype must be thoroughly defined now, so that the programmers and artists can actually start building the prototype.
Technical Design Document
There are two kinds of technical design documents. The first pass I like to do myself, working with the lead programmer on the project. Not every designer is technical enough to write this document. This document is meant to give the programmers an idea, often in non-technical terms, what the different systems of the game will function like.
The pre-production stage and the prototype stage are often combined. I like to separate them, though, because, without proper pre-production, it is very difficult to know what aspects of the game to actually implement. Skipping over pre-production is like building a house without plans. During the prototype stage, you build the first playable version of the game, including all the primary features and as many high-risk design elements that you can implement technically. The higher the risk is, the earlier features need to be tested. Because most of this work is being done by other people on the development team, a designer should spend his time during the prototype phase fleshing out the remainder of the design as much as possible.
At the end of the prototype stage, there needs to be time to test and iterate the prototype. I often add a short sixth stage (Stage 3b) between Stages 3 and 4. When you are happy with the design of the prototype, you need to bring the design documents into alignment with any changes that you had to make during the prototyping stage. Spending an extra month or so here can help a lot. The rest of the team can spend time bring any code that was hacked to make the prototype up to full production standards, and the rest of the team can begin hiring and ramping up for full production.
This is the point at which you bake your first little muffins, most of which will taste either under cooked or overcooked. Your carefully constructed design document has now been interpreted by engineers and artists to build a prototype. The game must be up and running to see how it plays. Now the ingredients get adjusted: Did you think that a drunken half-elf was a good idea? Whoops, controlling a drunkard is just not that much fun, scratch one gin-soaked main character. By continuing to bake muffin after muffin and adjusting the recipe, the batter improves quickly. This way, in case your terrific recipe produces shoe leather flavored muffins, you can fix it before ruining the whole cake.
Any features that are implemented in the game need to be evaluated. This short document is a way for me to basically analyze the game one last time before we move into full production. This is the last point where changes can be made in the design without some kind of potential impact on the project or loss of work. I like to identify all of the key features, make sure they are all necessary, and fun. This is also a good point to possibly run a focus group or usability test which will let you more formally analyze your features.
This is the phase during which you put all the final pieces together and flesh out the various design documents. It's time to butter the pan, make last-minute adjustments to the batter, set your timer, and preheat the oven. During this phase, you bring all your documentation into alignment with your final findings of the prototype design.
The design spec is the final design document. You take the prototype design document and begin to flush out all of the features. Every feature in the game should now be built into the document.
The design bible is the place I store everything in the game. This includes reference material, and anything not appropriate to put into the design spec. This can serve as a reference to other people as they work on different aspects of the product. Also, by putting stuff into the design bible, instead of the design document which only a few people will need, it can help keep the design document more focused and simpler.
The Story bible is where all the details of the story are kept. Many games often have a super complex story that includes many details which are unimportant to anyone but the lead designer and a few others. I often detail out parts of the universe or world which aren’t really necessary, but may play an important role to a sequel or for some consistency reason which I feel I need to understand. Don’t bore your whole team with all the details of the story in the main design document, but make sure they get enough of it so that they understand it.
The AI for the game needs to be designed. Similar to the technical design document, this is a task for a designer and a programmer. The programmers need to understand how the AI needs to work. AI in games is still rarely done well, and I think some of this has to do with the fact that designers rarely get heavily involved with defining the AI, and just end up using what the programmers create.
When you reach the production stage, you should know exactly what game you are going to build (although this rarely happens!). This is the longest part of the development process. The bulk of the actual work laying out and testing the game play is done during this phase, and this is the stage in which all the final aspects of the design are fleshed out. All of the final code and art is created during this stage.
In the expansion phase, a variety of other documents and secondary design tasks can be tackled, depending on the type of game you are creating. It's now time to start baking the cake. During this phase, you finish the last details of the design, finish creating the final design spec, and begin heavily testing the game for good game play. I cover most of these issues in Article 14, "Additional Issues and Elements"; Article 15, "Usability"; and Article 16, "The Design Spec."
Level Design Doc
The level design doc is the place where all of the levels are detailed out. This can include concept art, level layouts and other supporting material. It also isn’t necessary to put all of this information into the main design spec, since not everyone needs to know every detail about each level. This document should include information on how the levels are going to be built, the geography and architecture or layout of the level, the story and events of the level, locations of enemies, NPC’s and anything else that is in the world. There are a lot of details you usually need to know about a level before you run off and build it.
In this phase, you completely wrap up every aspect of the design and lock it down. It's now time to trim the edges of the cake and spread the frosting. Any remaining issues are now finalized. I cover the last few issues in Article 17, "Finishing the Design."
In this phase, your main goal is to make sure that the game is fun to play, while not being too hard or too easy. Now that the cake is fully baked, trimmed, and frosted, you need to put the candles on it to make sure that it's perfect. You shouldn't actually be creating any documents anymore, but you should be working to make the game fun and trying to get it out the door.
Post Production Phase
This is the final stage of the project that occurs when the game can be played end to end and is "content complete." During this stage, the game is tested for bugs and polished for release. By now, the designer's role is mostly over. Some projects might require a bit of play balancing or last-minute tweaking, but hopefully you have moved on to the next project by now.
This stage is the point of the project where you are usually code complete or finished with the game. What is important now is that you balance the game and find any bugs in it. Designers are usually involved with determining if design bugs should be fixed, making sure all the units in the game are properly balanced and that the game is playable from start to finish without ever stopping the player, stumping the player, or ruining the play experience. This is also where the pacing of the game can be adjusted.
In the final phase, an analysis and postmortem of the project should be completed so that you can move on to the next project, having learned some lessons. It's time to serve up the cake and see who comes back for seconds (or who gets sick to their stomach!). Do the people you work for ask for the recipe?
These 10 phases of the design process are important to understand. This is the concept about which most of this article is built around. Understanding the theory of how to create games is important, but understanding how to actually create the games is often more important. Designing games is an organic process, and understanding the different stages and phases of the design process and how they relate is very important. It's not good to just sit down and design a game without taking the idea on a journey to help define and refine it properly.
As you read through the rest of this article you will see how everything about game design will indirectly lead back to this process and you’ll learn that how you make games will become as important as what you design. You’ll then begin to see how everything fits together, and how the process of making games relates to all aspects of game design.
Determining When to Design a feature
Hopefully by now the shear immensity of what you have to accomplish as a designer has started to set in. Hopefully this article will help you better understand the entire process and allow you to go into game development with your eyes wide open to the realities it poses. If you’re already in the industry, there is still a good chance that you don’t fully understand the entire process, which this article I hope will help clarify.
One of the biggest things that separates a good designer from a bad designer, or an experienced designer from an inexperienced designer is their ability to do the right things at the right times. Determining when to design a key feature, how detailed to make the design and how much time to spend designing the feature is truly a difficult task. There is no right or wrong answer to this problem. Each game will need different things done at different times and in a different order.
Since making games is also a creative process, sometimes it is necessary to follow your heart, your inspirations and your gut instinct. Sometimes you also just need to put ideas down when they come. If ideas are flowing freely and quickly, sometimes it is good to capture them before you loose them. However, if you find yourself struggling for ideas and hitting a wall on things you know you really shouldn’t be, then it is definitely time to move on.