Developing a Process for Design
This is a slightly older article I wrote, but it still has some relevance, especially for larger game productions, console/PC games and such. It might be too formal for some mobile game design projects, but the overall idea is still relevant, so hopefully it provides some useful insights for everyone.
"The person who knows 'how' will always have a job. The person who knows 'why' will always be his boss." - Diane Ravitch
Designing games is an extremely challenging job. It requires a vast array of skills, knowledge and experience in order to do it well, yet it is perceived by many as being easy to do. There are many kinds of designers and design jobs out there, and they all often do very different things each day.
People often think that designing games is just about coming up with ideas. Ideas are a dime a dozen. Taking an idea and making it work, making it fun and making it into a game is the hard part. Execution of the idea is everything. In the end, you have to trust that you and the people on your team will have plenty of great ideas along the way, so great ideas aren’t going to usually be a problem for most teams, but making the idea is another story.
Some people think that great games are all about good game play or storytelling, artwork, cool technology or some other aspect of the game. In fact, it’s about all of them and how they all fit and work together. Designing games is a constant compromise, since everything must fit together and work as a cohesive experience.
You often see a bad feature in a game and think that you could have done it so much better, and that the designer of the game must have been an idiot to have done it that way. While there are some bad designers out there, and a few people with bad ideas, the reality is that it is often out of our hands. If the technology doesn’t come through for you, if a feature isn’t possible to make, if the artists can’t make it look right and if a thousand other things that could happen do, you can get completely messed up and have all your plans evaporate instantly.
When I was helping design the first 3D RTS to come out called “Armor Command”, we knew very little about 3D. We were unable to figure out how to get the mouse to work in the 3D world and then also function on the 2D interface, so we were forced to make the 2D interface completely keyboard driven. While this was far from optimal, we made due and came up with an adequate solution. On Munch’s Oddysee for the Xbox, a large amount of the planned features never were completed, so we were forced to redesign most of the levels for the game at the last minute in order to take advantage of the features which actually made it into the game.
As a designer, it can be a hopeless feeling to have all your hard work thrown out because something else didn’t come together. While we can never remove risks like this, and it will always happen and be the thorn in our side, there are things you can do to prevent many of these problems from happening. Having a process that you follow when you make games will help you prevent many of these problems and others which you might encounter.
The Game Development Cycle
All games must go through a development process. This means that they usually follow the same order of events, or a similar order of events when they are developed. Most games follow a fairly similar development cycle. Each company makes games a little different, but the overall development cycle is very similar. So from a high concept level, the game development process is similar to the development of other software and entertainment products.
The basic development cycle goes like this:
Concept - Pre Production - Production – Post Production
Later on we will refine this cycle a bit more however, to show how this process of making games is slowly changing.
Like most everything else, all games must start with an idea. This idea must be thought about and refined a little bit, until it can begin to form into a cohesive concept. This concept is usually then developed into some kind of proposal. Occasionally this may just be you going to your boss with the idea in your head and telling it to him to get approval to make it, but usually it involves putting it down on paper in some kind of formal way which people can read, understand and get excited about. The goal of this first step is about getting permission to develop your idea further.
Once you are given permission to develop the idea further or decided for yourself to refine the idea more, you can then start what is called Pre-Production. Pre-Production is the time when you take your early concept and evolve it into something which can show why the game should be made. The goal of pre-production is to develop a game prototype which shows why the game is fun, how it looks and that the technology necessary to build the game is feasible. Pre-Production is therefore the planning and early building stage. For a designer, this is where a lot of your work is done. Surprisingly, Pre-production is one of the most important stages of the development cycle, and is often either overlooked or severely cut short by many developers and publishers. At the end of Pre-Production, you generally will need to show your game prototype to someone again to get approval to move into full production.
Once you have approval to start building the entire game, you move into Production. Production is when most of the assets of the game are made, and when the bulk of the features are flushed out. This is when the game is assembled. The goal of this phase is to create a version of the game which is basically all together, done and ready to test.
Once a game hits a key point, called Alpha or Content Complete by many people, it should have all of it’s features and programming code finished. The goal of this phase is to find all of the bugs with the game, make sure it is stable, compatible and well balanced. At the end of this phase the game should be finished and shipped to the public.
Keep in mind that every company has a different process and set of procedures when it comes to making games. This can serve as a guideline to what is widely accepted by many companies.
This general overall process is logical and generally works pretty well to develop games. As a game designer however, you will find that the overall game development cycle isn’t the same or in alignment with the game design process you will need to follow to make a great game.
The Game Design Process
A game design process is similar to the game development cycle for most people. Most game designers, yes even the working professionals, don’t have a formalized game design process. Whether they realize it or not however, most game designers do have a process which they follow.
So what is a game design process? A design process is a series of steps that must be completed to refine an idea for a game and bring it to completion. Whether the game is being designed by one person or a group, every concept within the game must be thought of, refined, questioned, verified, and solidified before it can be implemented.
As a designer, you control the content that goes into a project. You determine the number of features, mechanics, moves, protagonists, antagonists, special effects, and so on. Being realistic about what is going into your game is the first step in the design process. Making sure that everyone on the team understands as clearly as possible what is in the game from the start is the best thing you can do. Establishing a formal design process allows you to think about all aspects of the design and ensure that you cover all your bases up front.
You can have great art, great technology, and a great design, but unless you have unlimited funds, a proper schedule is the most important thing you can have on any project. Because games are often one-of-a-kind propositions full of unproven content and technical hurdles, they are notoriously difficult to schedule (which is one reason that so many games are late, late, late). Having a design process is one of the checks and balances with the reality of your schedule and the game design you are creating. With a good understanding of the process, you can not only schedule your own tasks, but help the Producer on the project begin to schedule the rest of the game realistically.
Every idea must get from the designers head and then somehow into the game. Every aspect of the game must be designed. Failing to design key aspects of the game could cause major problems late in the development cycle. Therefore developing a formalized game design process can be a huge advantage to you if you understand how to properly utilize it. Keep in mind that there is no right or wrong design process, but there are better processes which will work better for you.
Different Processes
While there is no right or wrong way to design a game, there are many different ways. This is both a blessing and a curse. It gives us lots of freedom, but makes finding the right process very confusing. This can also be made worse by the fact that many of the people who write articles and articles on game design, and speak about it at conventions have very strong opinions about what works and doesn’t work for them, but they tend to preach it as the only solution.
For some designers, the idea of a design process involves just sitting down and creating the game as they see fit, in a vacuum. Others try to create the design by brainstorming with other members of the team. Whichever way you generate your ideas, you need to agree upon the process by which new ideas can be implemented. Although some designers can conceive and control their projects by themselves, most need other people involved in the process to ensure that what they're doing is realistic.
So, if you don't have a process in place that helps make your ideas happen, it's time to think about it a little. You then want to make sure that the entire team understands the process and will adhere to it. It seems a little strict at first, but ultimately having a process ensures that you're making the best possible product.
It is a good exercise to read and hear about how other designers work and the processes that they use, but you have to be careful. I would encourage you to use a lot of common sense and restraint in throwing out your current process, if you have one, unless you’re sure that this new process that someone else is using is right for you, your team, the type of game you’re making and the environment you are trying to build.
Many different philosophies approach the best way to design a game. Every company, every team, and every project have different strengths and weaknesses that will also make one method more successful than another. This article shows you primarily one approach to game design, but it's not the only way and it's perhaps not even always the best way for you and your particular project.
Some designers hate the way large publishers work and the way big business works, so they will argue and rebel against my process until the bitter end. Some designers believe that game development has to be a totally organic process that you can't schedule because the game needs to evolve into its final form. Other designers believe that it's best to have a game designed by a single visionary, while still others believe in design by committee. There are a lot of different ways to skin the game design cat. Here's a glimpse at a few of the design processes which people use:
No Design
Some designers believe that it is impossible to design something and keep it creative. To put it bluntly, they are wrong. Jumping into a game and just making it won’t get you very far, unless you’ve done it before, the game is really simple, or it is some kind of a sequel. Even then, I still wouldn’t recommend attempting to not design your game ahead of time.
Little Design
A bit more than not having a design, some people like to design as little as possible in the beginning. They may write a paragraph to a few pages of details and then jump into making the game. This isn’t much better.
Complete Up Front Design
On the other extreme side of the spectrum are the people who try and completely design the entire game before they begin making it. They may write hundreds of pages of detailed documents and plan out every detail, before they begin making the game.
Technology Design
A technology design is one which is one where a key feature(s) of the game are programmed first and then a game is made out of the feature. While every game needs technology, and even it has to be designed, a technology driven design is one where a programmer sits down and develops a cool feature or set of technologies and then makes a game out of it. Bloodwake for the Xbox is an example of a game where some incredible water technology was created, and then they figured out how to make a game using really good water physics.
Another approach for technology driven design is taken by a game like Dungeon Siege. These games were designed by designers with a strong programming background, and they first developed what they call the “Sandbox” and then see what they can make with it. This is where the developer creates a whole series of features, which all fit together, but they aren’t sure exactly how, and then once the technology is finished they try and figure out exactly what kind of game to make with it.
Artistic Design
Visual design is the process used by many developers who work in what are primarily art houses. Many game developers whose upper management come from the art or film industry also use it. This process involves visually detailing the game for a very long time. In this process, there is a tendency to forget about game mechanics. I've seen projects designed with this method drag on for a very long time, only to produce impressive artwork without a real game underneath. One of the big problems with art-driven design is that the visuals raise expectations that, in many cases, are not supported by the underlying technology or game-play mechanics. In general, it is very easy to visualize a game in static storyboards or paintings (or even pre-rendered game-play visualizations) and very difficult to actually implement these visual ideas.
Munch’s Oddysee was highly driven by its need for a fantastic visual quality. These types of projects are usually designed or run by someone with an art background, or because the art is a very important aspect of the game. I have seen games which were close to a year into their Pre-Production phase, and all that had been done was concept art. No code had been written and no real game design had been done. While Art is a critical element to the game design, you need to make sure that it is kept in balance with the rest of the game.
Collaborative Design
A collaborative design process is one in which the entire team works together to develop the design of the game. Although in many cases every project is a team design, even if it has a lead designer, a collaborative design goes out of its way to include everyone in the process. Valve is a prime example of a company that uses a very collaborative design process called the Cabal. You can read all about it at www.gamasutra.com/features/19991210/birdwell_01.htm.
The Valve process involves including the entire team or members of the team in regular brainstorming and design meetings. The idea behind a collaborative design process is that everyone on the team is smart and has great ideas, so it's good to utilize this to get the best game possible. Unfortunately, everyone tends to have different ideas, so it can be hard to focus the project.
One of the biggest problems with a collaborative design process is that someone needs to be in charge and able to make the hard decisions. This process can quickly devolve to a design by committee, which doesn't work. Unfortunately, when you ask everyone's opinion, you're likely to get a variety of different answers, or else one person will dominate the group and keep others from talking. Whenever the entire group must decide specific issues, you can be in for trouble.
If the collaborative process isn't run well, you can run into a host of problems. In my opinion, even a collaborative process should have a leader who can act as a "tie breaker" to keep the team focused.
Iterative Design
An iterative design is one where a feature, or maybe a few features are designed, implemented, tried, tested and the refined, before you move on to the next set of features. This design process can be similar to that of a balanced design, but tends to look at just a few features at a time and then make them fun, before adding anything else. This process is often driven by programmers, and is often used in strategy games where every new feature could possibly unbalance the game.
Iterative design can also be called Trial and Error Design or T&E design, as I call it, and it is most often done by programmers. Although this isn't necessarily a bad idea for some games, it can mean death for others. In a T&E design, you start with a small concept and then begin to program the game. The goal is to get the game up and running and fully playable as soon as possible. When the core of the game is working, you begin to add features and remove features as it makes sense. In other words, add a feature and see if it is fun; if it isn't, take it out and add another. Keep this up until the game seems fun overall. Designers who use this process typically do minimal, if any, formal game design.
Most early games and many arcade games were designed this way because the games were simple and easy to create. This was also often done because no formal design standards existed and because the person programming the game was often also the person designing it and possibly even doing the art for it. This made designing games back then a lot different than the way most games are now designed.
This design philosophy was used by Chris Taylor when he created Total Annihilation. Because an RTS is so data-driven, game-play balance is everything. Although this approach worked really well in TA, it didn't work so well initially in Dungeon Siege, and Chris quickly learned that he needed to do more up-front design work to design a good RPG. This shows that just because one technique works well in one application doesn't mean that it can be applied to every game design you might do, unless you're always doing the same type of game in the same genre.
Balanced Design
A balanced design is one where everything is done together. It lies somewhere in between no design and a complete upfront design. It has components of artistic design, technology design and the other design processes, while finding the right balance between them.
Similar Issues in Software Design
It can also be helpful to study general software development. I strongly believe that there is a strong correlation between the game-design process and that of other software design. I believe you can learn a lot from other software projects, whether they are applications or even updates of an existing code base. The more I talk to people from other parts of the software industry, the more I realize that game developers' problems aren't unique. Therefore, I highly recommend reading articles on general software development, including Rapid Development, by Steve McConnel.
The process of game design is similar to normal software design in many ways. Many people think that making a software application is totally different than designing a game. Although it's true that games are creative and have their own set of difficult problems to overcome, a lot of similarities still exist between most software-development processes. All software projects require code to be written, involve deadlines, must create a product that is easy to use, includes a development and design process, must consider what users want, and includes an entire team of skilled people working on the project for years at a time. Designers can learn a lot from normal software development, which can help improve the process of developing games.
As you can see, there are a lot of different ways to design a game, and all of these different development processes will directly influence how you create your own design process. The entire process of creating games is very difficult. Without some kind of plan, you're never going to make it on time and on budget, unless you make severe compromises. It's important to adopt and understand some kind of design process if you hope to be successful.
Creating a good game design is a very difficult thing. It's not something that you can just jump into, but it's also something that is creative and that can't be overly analyzed. Having a process in place and developing a deep understanding of how you should design games will go a long way toward helping you design a better game.
What Does It Mean to Formalize a Document?
A formal design is one that follows a set of policies and procedures to help ensure that an adequate design is created for the project. If you don't follow a more formalized approach to design, you might waste a lot of time early in designing the wrong things or focusing so much on short-term issues that you put off the long-term problems facing your game.
This formalization is set in place as a way for you to think about every aspect of the game early, especially when it's time to set a budget and a schedule. People in the industry commonly do not work on critical components until late in the project, assuming that they will be easy. More often than not, this causes delays in the project. Never assume that anything is easy.
Formal design documentation is about planning your game. The better planned a game is up front, the smoother the project will usually go and the better chance it will have of actually being manufactured and distributed.
In an ideal situation, a designer should be able to work by himself for at least six months before anyone else even joins the project. During this time, the designer roughs out the design. When the designer has had time to solidify the basics of the game play, several other people should then come on board and help with pre-production. By the time the design reaches the end of pre-production, it should be fully formalized and fleshed out so that when the project moves into full production, a blueprint of the entire game will be available to the team. Of course, some aspects of the game won't be fleshed out yet, but the pre-production phase should answer as many questions as possible. Keep in mind that this is an ideal situation that doesn't always happen. Often you will have to work on projects that are already in full production and that have either no formal design or a really weak one that needs to be fixed.
The most challenging part of creating a formal design documentation procedure is that it needs to constantly change and adapt to every new project. It is impossible to create a set of rigid rules that are equally appropriate for every project.
By formalizing your design process into documents, you create a blueprint from which others can build the game. To communicate your intentions effectively, these documents must live up to certain standards of completion. The bigger the team with which you work is, the greater the chance you have of something going wrong with someone else's implementation of your design if it is not properly formalized.
By creating this document and saying that it is complete, you're endorsing the design. If your name and reputation are on the document, you're placing a lot on the line. You also want to make sure that the design you endorse is done right. The worst fear of a designer is to work on a project for an extended period of time with a large team and see the project cancelled because of bad game design. A lot of fingers can (and will) point in your direction because, as the lead designer, the fault is yours. I've been involved in helping a lot of projects that have come under fire late in the project's development for bad or unfinished game design. This problem is very common in the industry, and we must stop it by making sure that game designs are formalized and up to snuff.
So what separates a normal design document from a formalized one? A formalized design is one in which a set process is applied to the document to ensure that it is written to a satisfactory level of completeness. In some ways, every design is formalized, but if you're just writing down what comes to mind and are not thinking about the process and the implications, you're failing to formalize the document.
A formalized design is one that is planned out in advance. This requires that you have some prior knowledge in game design and hopefully some experience in designing the same kind of game because they are all slightly different. It also helps if you have a template of some kind. A formalized design doc doesn't exactly have precise characteristics that can be listed because it's always different. The process involved in the development of the document is more important than the specific information within the document. A formalized design is one done to a level that is satisfactory enough to allow you to easily and realistically develop a game based on the information.
The next two short examples show the difference between taking a loose approach and a more formal approach to writing a paragraph description.
Well, you see, in my game there are these guys, and they run around using guns and killing people. They have all kinds of cool weapons that shoot bullets, lasers, big flames, and missiles that explode. The player is a big guy who is in the Army, and he's fighting aliens who have all kinds of strange weapons.
Goal: This is a first-person shooter that has spectacular graphics and a bunch of great new features.
Game play: First-person shooter, similar to Quake.
Controls: Same as Quake. List here[el].
Weapons: Pistol, machine gun, laser pistol, laser rifle, bazooka, flame-thrower, grenades.
Story: Sci-fi story that pits the player against an alien invasion on a distant Earth colony on Mars.
The difference between these examples is that the formal example is often easier to read for the team, because they can find the information they need and get all of the details. The formal example also helps make sure that what you are writing is complete and precise. The informal example doesn’t sound as professional, which you need to try and be. Overall, I’ve found for my main design documents, it’s best to be quick and to the point, and as minimal as possible. You shouldn’t have to sell your team on the idea.
Sometimes it is necessary however to create multiple versions of your documents. You may find that people from marketing and management respond better to a more hyped up, cool sounding document, than one which is better suited for the team.
Using the Design Process
Every idea must go through some form of process to become a reality in a game. Understanding the path that an idea travels until it becomes a reality is important. You might start with an idea such as "The game should have four-player split-screen multiplayer." As a lead designer, you might be fairly sure that this is something you want to do, but you must also figure out all the specifics for it. You might then need to check with all the other designers to make sure that there is not some other ramification or pushback to doing it. When the entire design team thinks it's a good idea, you might need to check with the programmers to see if they can do it. After the programmers have signed off on the idea, you might need to check with the art department, to make sure that any changes required by that group can be done.
For some games and ideas, this might be all that is required. However, for more complicated or risky ideas, you might also need to have the marketing department, testers, and management signed off on the idea. Each one of these sign-offs is a necessary step in the design process. Either way, you need to understand that, as a designer, you can drive the vision of the game, but you can't control it: Other factors need to be taken into account before your idea can become a reality inside the game.
Most ideas are put into some form of a design document and looked at in bulk by whoever needs to sign off on them. Avoid trying to get buy-off on each and every individual idea from the entire team, unless it's a really big change in the vision of the game. No matter how you turn an idea into a feature, keep in mind that at some point you need to get others to buy off on the idea. Involving the entire team in the buy-off process regularly helps the entire design process greatly.
A design process can also help you identify several main needs in your game production. First of all, a process should help you keep track of all of your ideas. It can also help you track all of the features in the game, and help ensure that you don’t forget any key features of the game. As you can see, a design process is indirectly closely tied to scheduling. This is important to keep in mind since it’s difficult to make games without keeping the reality of the schedule in mind.
Making games is a team effort. A design process can help your team work much better. Every idea that must be made into a game has a process that it must go through in order to get made. This process includes getting the team to buy off on each and every idea you come up with. Programmers and artists must tell you that the idea is possible, while the Producer and others may need to tell you if it is feasible.
A design process also helps to ensure that nobody on the team is implementing ideas without your consent and buyoff. It also lets the other people on the team know that you're in charge of the design and that it's not okay for them to simply start changing things as needed. In addition to the project design process, each department should have its own development process, or "pipeline," for how things are implemented in the game. This helps keep proper communication channels open between team members and keeps time from leaking away from your schedule.
How you formalize your design process is up to you. Just knowing that you need to have a process may be good enough for some people and projects, while creating some kind of chart may be better for others. I like to create a spreadsheet that lists every feature in the game going down, with the across columns listing the steps of the design process.
Here are the different categories I track across the top of the spreadsheet: Feature, Feature Priority, Date Needed By, Stage feature is in: Idea, design buyoff, art Buyoff, Programmer Buyoff, Buyoff from Others, final feature approval.
Going down on the chart I track the features like: Interface Design, level design, units, weapons, etc. I then break down each of these features into as finite as detail as possible. Even if the features are unknown, you still should have a rough idea of what the total features for the game should be. This initial step can also help you try and help you figure out which features you should design first. This helps you make good decisions about what you are doing early on, which is one of the toughest challenges for a professional game designer.
I've found that creating a detailed design process spreadsheet serves several important functions. First, the spreadsheet acts as a place where I can put every important design feature. This helps me make sure that I don't forget an area. Second, by continually updating this spreadsheet, I can track the progress of every design feature in the game. This also allows me to globally track the game's progress against its ship date. In addition, the spreadsheet helps the rest of the team, which must buy off on a particular feature, know where the game is in the design process. Last, the design process marks the beginning of a schedule, which is really the most important part of the project.
How exactly you use the design process to improve your game is up to you. It may not be possible to capture all of the information you need to track in a single design process document. It may also not be necessary to even create these documents at all, but if you’re as anal and thorough as I am, it can’t hurt.
The Changing Development Cycle
Earlier we talked about the standard development cycle.
Concept - Pre Production - Production – Post Production
Over time, we have begun to realize that this development cycle doesn’t work extremely well. Some of this has to do with the way games need to be made, while other issues revolve around stickier problems having to do with the way contracts are written and the current political scene of the industry. What it boils down to however is that once we commit to fully developing a game, it can be very difficult for some publishers to cancel a project.
One of the problems we are facing which is forcing this change is that the quality bar of games is dramatically increasing every year. Many developers are still developing games using the processes and standards of what was acceptable in years past, which is impractical in today’s much more competitive environment and higher project costs.
There are two different schools of thought when it comes to creating features and showing quality in a game. The first school of thought is what is called a “back-end development cycle” (see figure 4a) and it says that developing games, programming features and making great quality art is extremely difficult. Therefore it will take the developer most of the production cycle of the game in order to get all of the features working in the game, which won’t allow them to show what the finished game will look like until very late in the development cycle.
The back end development model is the most common model used in the production of games today. Only a single prototype is built and then full production is started. Because the entire game is not running early on, many problems are often not discovered until late in the development cycle. This causes delays and lots of changes late in the project, when it is the most expensive to run. Also, if a project is then discovered to not be viable until the end of production, millions of dollars have already been spent and often years of time.
The second school of thought is called a “front end development cycle” (see figure 4b) and is where you need to show the final quality of the game as early as possible in the development cycle. This can be very difficult to impossible for a new developer with no existing technology to achieve. This approach is now considered lower risk for a publisher and the developer. Because of the quality problems we are having as an industry and because of the lower risk factor, there are more and more people making a change to the front end development cycle and demanding to see what the final game will look like as soon as possible.
The front end development cycle is safer for a publisher because it allows them to risk less money if there is a problem and they need to get out of the project. The front end development cycle is used by many successful companies like: Naughty Dog, Blizzard, Insomniac, Nintendo and Microsoft. It allows them to spend more time at the beginning, in Pre-Production, making sure that we know what we are going to make before we jump into making it. Under this model, several prototypes are built, which prove all major concepts in the game, before the entire project is staffed up and becomes expensive to run. If a prototype is found to need more work, it can be easily and more cheaply thrown out and repeated or just completely thrown out with a lot less money being spent. With this model, costs do not start going up until the risks are limited. Later in the article I will get into more detail about what goes into a prototype, and how this process directly effects pre-production.
Finding the Process That Works for You
As you can see, there are many different ways to make games. Every company you work for will have its own way of making games. You may not have a choice on the process you use to make games initially. You may however be able to control how your team or small group works, so it will help you a lot to see how different people design and the advantages and disadvantages of each technique. Then, in the end, you can hopefully gain enough insight, experience and influence to build your design process and development process which works best for you.
You should formalize your design for a lot of reasons, and you should avoid a few things along the way. The biggest mistake I see all game companies making is not properly documenting their design ideas. So, the first step of figuring out how to formalize your document is to think about what would be best for you and the project.
None of my advice here will do you any good if it completely changes your project and it spirals out of control. You might not be able to stop your game development for four months while you say, "I'd really like to just think about this for a while do you guys mind taking a short vacation?" The advice in this article is meant to help you improve your process in an idealized situation, so don't expect to completely adopt a formalized document overnight. Some of my ideas will be immediately applicable to you, while others are food for thought or something to implement in the next project.
Breaking Down Design
"Designing is not the abstract power exercised by genius. It is simply the arranging of how work shall be done." - R. Lethaby
The different parts of the development cycle which we’ve been talking about can logically be broken into phases. These Phases help identify key points in the game-development cycle. Within each Phase of the development process, certain design and development work is usually done. These Phases aren't always very well defined during some projects, however. The five Phases might also be too granular for some production cycles, so don't be afraid to break this down into some smaller steps and adjust your design process appropriately.
The main reason for separating the Phases of the design is that, at the end of each phases, there usually comes a time when you are waiting for other members of the team to finish some work and for some kind of approval from management to continue. This usually means that you are waiting for some aspect of the game to actually be created and made playable so that people can look at or test it. At the end of each of these Phases, there is a chance that the results won't be adequate and that you will have to repeat the stage or iterate the stage until it is good enough to proceed. When you understand the different stages a design goes through, you can begin to understand the phases for the work that you need to do during each stage.
What is a Design Document?
Everyone has a different idea about what design documentation should look like. I've seen designs for games as short as 3 pages and as long as 1000 pages. What matters is not how long your documents are, of course, but how clear and thorough they are. Every type of product and team requires a different level of documentation, so the best approach is to offer guidelines and let the game dictate the standards.
The most important thing to remember while creating your design documents is that they are what we call "living" documents. This can mean several things. First, the documents are always changing and are always being updated, refined, and polished. Second, many people tend to contribute to the document in some way, providing feedback and additional information through the life of the project. Finally, a living design document isn't just a collection of words and diagrams set in stone, but it is a flexible map representing every aspect of the design as it changes over time, acting as a warehouse of useful information for the entire team.
Creating a game is not a black-and-white process, so your design documents also cannot be rigid and inflexible. Game creation is an art applied to a science. When creating your documents, you might have to use your instinct, intuition, and gut feelings to come up with the initial answers to your problems. Sometimes you might come up with several ways that a problem can be solved. Because a design document is living, feel free to insert all of your ideas. In case one idea doesn't work, you'll immediately know what to try next. Also, by including your ideas and thoughts in your document, the rest of the team can read them early and might contribute to a healthy debate about the relative merits of your ideas, allowing you to solve problems on paper well before implementation. Letting your programming team see your ideas early also enables them to evaluate them from a technical perspective based on the way the core technology functions. Sometimes even the slightest game design change, that seems easy to do, can affect the entire core of the game. If the programmers know that there is a possibility for two different features to exist, they can make their technology flexible from the start, to implement your new idea later with less work.
For example, if you ask the question in your game: “Can the NPC’s in the game pickup and use different weapons?” Whether or not NPC’s use the weapon they are given or have the ability to change weapons is a huge architectural change. If a character just uses one weapon all the time, like a sword, then the actual model of the character can just have a sword as default. The game doesn’t really need to know the sword exists. Plus the animations can account for the character always having a sword. If you decide on this, and then later on decide that it would be cool if the character can pickup and use a gun, this will cause all kinds of problems. An in between solution may be that there are classes of weapons, stick (swords, clubs, etc), pistols, rifles, etc. Then, a character might be able to use a class of weapons, but not all weapons. Making this single choice will determine how the programmers design the architecture of the animation system and AI, how the models are built, how the characters are animated and how the game is balanced. Before you decide on any key feature, try and think about any possible changes you can foresee, what systems of the game will be affected and who it affects. Get the signoff of anyone who the design feature affects, so that you and they know it will work.
One of the biggest problems with trying to also keep track of all these other things arises in the way documents are formatted. Later I'll get into how to properly format game design documents that will make ideas in your document clear and easy to understand.
Another critical reason to properly design your game on paper is to allow you to create realistic schedules. We live in a time in which it seems to be acceptable to be late sometimes very late. Publishers and developers wonder why they can't make any money from a project that was a year late and doubled its expected production budget. There is no reason why projects should be late, and there is no reason for designers to live in perpetual crunch mode. If projects are properly designed and a set of good design documents is created, you should know exactly what you need to do up front and should be able to detail out a proper schedule. If you fail to design, you're failing to plan, and you know what can happen there.
You'll face many unknown questions when designing a game. Even with a formal design process, you might not be able to answer them. Get help early! Turn to other members of the team or outside resources to solve as many problems as you can.
There comes a point in every paper design in which the answers will just be unknown. If you design too much of the game before it is playable, you run the risk of designing so many features early on that aren't fun, and then you end up spending time implementing features and losing the soul of your game. It is very important to strike a balance between documentation and implementation. Some games beg for a completed design early. Adventure games and other very linear games are examples of games that have simple play mechanics but complex interactions between them.
One thing you will learn is that you usually can't just design a game from start to finish. This begs the question of whether you can over-design. I can say that it's important to design a game as much as possible, but a lot has to do with when you design.
Think of designing a game as a military operation. You don't want to just gather all your troops together, cram them in a plane, and tell them to attack. Although this does happen a lot and is sometimes necessary to win the war, it's not the safest thing to do. This is especially true if your troops are green. A good military operation requires proper training, practice, intelligence, and preparation before execution.
The military can do some practice before a battle, but until it knows exactly what the terrain and the opposition are like, it's impossible to plan the specifics of the battle. Game design is similar: You have to design a lot of general things early, which means making broad design strokes. Then when you learn what kind of war you're getting into, you will know more about how to refine your ideas and what tactics you will need to employee to crush your enemy. At this point, you might have the vision of the game pinned down and can start getting ready to go into battle. When you find out where exactly the battle will take place, you can practice it in other words, you can build the prototype before committing to battle. While drilling for the final battle, however, you might find out that a different plan is better than the initial one you created. This might require a totally different or even slightly different battle plan before attacking. Attacking the enemy or committing to the battle is the point at which you move into full production in the game.
Although this analogy might seem strange, it shows you that no matter how well you plan or how much you design, you still need to test things, try new things, look for problems, and evaluate the game design before committing to it. A bad game design will result in you losing the war or getting the project canceled. However, sometimes victory is bittersweet at the end of the war or project if there are too many casualties along the way. A poorly run or designed project might get out the door, but that doesn't mean that everyone will be happy at the end, when the game doesn't sell and everyone on the project is burned out and quits from frustration. You have to find a balance in your game designs. Designing too little or too much can both lead to problems.
Every game has some level of design documentation; the question is how much is right for you and this project. As a general rule of thumb, I expect that when laying out my design over the course of months, I will write a minimum of 100 pages. However, if you find your document hitting 500 pages, it's probably time to seriously re-evaluate what you're doing and the state your project is in. This doesn't mean that always writing 500 pages is bad, but if you've written 500 pages of design and still haven't started creating the game, you are probably in for trouble. If a lot of what you're writing is back story, character development, and other details that will help serve as a guideline for the game, maybe you're just working on a very grand and epic storyline within an RPG.
Because there is no hard-and-fast rule, it's just good to get into the habit of occasionally evaluating your design for the content that it holds. As soon as you find yourself writing text because you feel like you need to add more pages to the document, stop! It's time to figure out what information is relevant and what is just filler.
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.
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.
Proposal Phase
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.
Concept Stage
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.
Pitch Doc
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.
Concept Document
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.
Pre-Production Phase
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.
Vision Stage
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."
Vision Statement
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.
Essence Statement
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.
Definition Stage
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."
Creative Spec
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.
Proof Stage
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.
Creation Stage
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.
Prototype Phase
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.
Play Stage
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.
Feature Analysis
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.
Refinement Stage
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.
Design Spec
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.
Design Bible
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.
Story Bible
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.
AI Spec
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.
Production Phase
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.
Expansion 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.
Complete Stage
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."
Balance Stage
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.
Polish Stage
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.
Conclusion Stage
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.
When should you design a feature?
While there is no precise time to design a feature, there are some general rules and guidelines which you can use. If you follow the design process which I outline throughout this article, you will see that a lot of it is about designing certain sets of features. This can be important to follow, since it is an attempt to define which features need to be worked on first.
The biggest thing you need to realize is that you need to have a vision for what you want to make. This means that you need to understand what it is you want to make. You need to understand what it is you are making, what makes it special and different. You need to initial think in broad strokes, and the progressively refine your ideas and concepts into more exact specifics. Be careful to avoid defining exact specifications early on. If you find yourself figuring out exactly how fast a unit moves, how strong it is, and details like that in the beginning, this is unnecessary.
I have seen design documents from seasoned developers which were 50-100 pages in length. They outlined every unit in the game, every detail and number associated with the unit, every piece of equipment, weapon and such that was found. Every detail of the story was detailed out, the back-story and every important event was detailed. Yet, they didn’t know what kind of game they were making, why it was fun, or why people would play it. They didn’t understand or define the interface or controls for the game, which was a major problem in the kind of game they were trying to make. In short, they dove right in to the features, without knowing why they were doing what they were doing.
Overall, you need to figure out what is important to the project and focus on it first. A very story driven game like an RPG will typically need a lot more story work up front than your typical action game. Also, just because you are doing a game like a FPS or RTS which is very derivative (similar to another game) or a sequel doesn’t mean that you can ignore defining what the core of the game is and how it is going to play.
Spending Your Time Wisely
It’s very easy for a designer to do “research” for a very long time. Early on in the development of a game it is very easy for us to get wrapped up in checking out the competitors (hey, it’s a good excuse to play games for awhile, and is necessary). It’s also very easy to just get lost in thought for long periods of time. When you combine this with everything else which happens at the start of a project, it can be very easy to not get a lot done for a few months. While this can be nice, it doesn’t help your schedule.
It’s incredibly difficult to get started on a new project. Ideas have to come from somewhere. We often need to come up with ideas, which can be very difficult for all of us at certain times. It’s important to balance out this need, with the need to get the game designed on time or at least in a reasonable time frame.
You must also spend your time wisely during the day. Find ways to make your design process more efficient. It does nobody any good to be inefficient in what you do. Make sure you look at how you are designing, the tools you are using, how levels are being built and the steps that you must go through in order to get the job done properly. It is very easy to work very inefficiently and waste a lot of your precious time. It is good to always evaluate your methods and see if the time you are spending is well spent.
Wrapping It All Up
The game development cycle is an incredible complex thing. There are many different ways which you can make games. While the vast number of possibilities can be thoroughly confusing, there are really just a few viable paths with a few different variables in each.
An analogy I like to use is that the paths to game development are like a battlefield. There are actually two parallels here. Each possible path you choose can either lead to victory or defeat. If you’ve studied military tactics you will see that at first, when you look at the entire battlefield, it would seem like there is an infinite number of options ands paths. However, you only have a fixed number of highly specialized resources. So if you look at the battlefield, the resources you have and the dangers ahead, it becomes apparent that there are usually only one or two paths that will work. Some paths will work, while others will dead end or get you killed.
The point is, you must study, practice, train, plot and plan if you want to win the war. Once you understand the battlefield, the correct path to victory will become clear and obvious. The trick is in making sure you either don’t just jump into battle, and just run into an unknown situation guns blazing, loose the war by preparing too much or get so confused you never know what to do and you get killed without even realizing it.
The more you know about the various fields in game development the better off you will be. You are the General of the battle (well, hopefully at least a Major), and you must be able to know how to use your troops effectively. A general must understand his: army, airforce, armor, artillery, special forces, support and all different kinds of specialties. All of these must work together as a team to win. The better the General can see the big picture, the better he can truly understand exactly what his troops are capable of, the better he is. Also, If you only know the theory of battle, but never understood the current health of your troops, weather, enemy positions or morale, you also can’t be an effective commander. Likewise, a good designer must not just understand basically what the other members of his team do, but strive to constantly understand the condition in which they are in. This is mostly just common sense, and part of being a good manager or teammate, but it’s surprising how often it is really done well. SO, understand your team and the process, and you’ll be off to a running start when it comes to your next project.
Founder / Creative Director at circa.
9 年great article_