The game development process involves a lot of work and sometimes it seems almost too much to take on. However, the key is to not take on an entire project at one time. You'll need to break it up into manageable chunks so that you can focus and work on those to a high polish and so you don't lose your mind. Iterative design, along with good organization, is one way of breaking a game project up into portions that can be designed, produced, tested, and implemented. I've described iterative design before as similar to the scientific method. Put simply it is:

1. Come up with an idea
2. Make a prototype that tests that idea
3. Test and record data by playing the prototype with other members of the team and, more importantly, people that have never heard of the game before
4. Review the collected data to see if it fits with the original idea and the game idea.
5. (Choose one)
   • If the collected data found that the prototype didn't fit with the original idea or the game idea then start over at step 1, but take the collected information into account
   • If the collected data found that the prototype did fit with the original idea and the game idea then simply move onto a new idea

In "Challenges for Game Designers" by Brenda Brathwaite and Ian Schreiber, "Practical Tips for Independent Game Development by" Jacob A. Stevens, and many other books or articles, iterative design is described in roughly the same way. Recently, I've discovered that what isn't discussed, when it comes to iterative design, is the dark side. The dark side of iterative design comes up when you don't have enough experience, don't have a solid core or aesthetic, and/or aren't using iterative design in the correct way. In this article I will discuss iterative design in a more detailed manner that will hopefully give you enough information on how to use iterative design properly. The iterative design process, like everything else, becomes more useful when you have more experience with it and game development as a whole. Some basic things that I have learned about iterative design are:

• There are two types of iterative design prototypes
  • The overall project - This should be the first prototype you make. Get your basic gameplay down here.
  • Individual mechanics - Every prototype you make after your basic one is to test individual mechanics and small changes. These mechanics and prototypes should ONLY be tested within the overall project to make sure that they not only work, but work within the game.
• If you constantly run into issues with specific design ideas, mechanics, or even your core. Don't be afraid to scrap it and start over. A smaller or shorter high quality game is always better than a long game that is of low quality. Note: The decision to start over should be done during pre-production, otherwise too much money and time will be wasted and you won't be able to start over.
• Never depend on iterative design to make your game for you. While iterative design is a powerful tool, you'll still need to pick the aesthetic, dynamics, and mechanics as the underlying foundation for it. If you try to find a game through rapidly producing prototypes than the game you end up with will just be a mishmash of enjoyable and unrelated mechanics.

If you're not very experienced with iterative design, the most important part that you can learn is to have an idea beforehand. Just as you would have a hypothesis when going through the scientific method, you need a main idea for the game in order to use the iterative design process properly. While you'll still be able to find out if the prototype is enjoyable and understandable, you won't have a good idea of how well it meshes with your other ideas. Obviously you could test it with every combination of ideas you have, but it's much better to just have a goal that you're headed towards and then come up with ideas that will suit that goal. Some game developers prefer to start a game with a mechanic, and then make their game based on that. Just as any other development method, you'll need to find which method works best for you. For people that prefer to start with a mechanic first, they will test their mechanic against various themes and play styles to see which one it suits best. An important element to remember is to not use iterative design in a vacuum. You'll need to constantly compare your prototype and the additions you make to it with your overall idea for what you want the game to be. If you don't have an overall idea of where you want the game to go, then you will ultimately have a game that is a confusing collection of unrelated elements that alone might be enjoyable, but together make little to no sense. Every time I have started a project with a main idea in mind such as an aesthetic or core idea, instead of just rapidly prototyping mechanics, I have ended up with a much higher quality game. The most overlooked part of iterative design is that it is a tool to be used among other tools in order to create a final game. The correct way to use iterative design is to not use it alone. For example, iterative design could be somewhat confused with testing, but one should never be used without the other. Iterative design is about constantly retrying new ideas to find the best combination of ideas. Testing is about looking at what you have in the light of how it works and how it is perceived by your target audience. Iterative design is mainly a pre-production tool, but can also be used when testing finds mechanics or aspects of the game to be unfit for release. Testing is used throughout the entire production of the game. It might seem like the entire pre-production process just involves a lot of iterative design, but while you are trying to find the best combination of mechanics you or other teams will be figuring out other aspects to the game. One aspect that will need to be worked on is the look of your game. During pre-production this will involve a lot of concept art. If your prototypes have been mainly paper ones, you will also need to find a game engine and start creating a digital prototype. While the pre-production process involves a lot of concept art, it might not always be obvious when to start developing and implementing final art. Most companies start a digital prototype with very rough art, sometimes to the point of just blocking things out with square shapes. This might seem strange but waiting to implement final art until the prototype is farther along will reduce the amount of art that ends up being thrown away. It's important to remember that a lot of work that goes into a game will ultimately go unused. Try to reduce the amount of unused work, not by forcing that work into the game, but by figuring out exactly what needs to be done and what will be used before you have your art team start creating. If you think there will be a level in the game that features a gigantic ship that the player might go into, have a level designer create a very rough level that features such a ship and use iterative design to test whether or not the ship portion of that level fits. While testing the ship, your concept artists should be coming up with different looks for the ship. If all goes well and the ship fits within the level, then your art team can work on final iterations of it. Notice that I say iterations, because just like with the game, your art and assets will also go through iterations. Most of the iterations of assets should be done with the concept art since concept art is much easier to create than full textured models. There is a lot of time and work that goes into making a game so be sure to make the most of every tool you use. Iterative design is yet another tool that can be used to improve the quality of your game and improve the efficiency to which you use your time.

Related articles

Four Steps to Detailed Quest Lines by Matt Christian http://www.gamasutra...Quest_Lines.php Practical Tips for Independent Game Development by Jacob A. Stevens http://www.gamedev.n...velopment-r2687