The iterative process is one that is heavily promoted as a crucial way of producing solid and dependable games. But what is the iterative process?
The iterative process is simple and works in 4 states that repeat in a cycle. These are; Generate Ideas, Formalize ideas, Test ideas and Evaluate the results. Should there be an issue at the final evaluation stage then the process repeats itself. By doing this, a designer is ensuring that at all stages of the project there will be no problems and that their product will perfectly tailor their target market.
As a process it is dependable and as a designer, I have used it subconsciously in both of my projects. In my board game design project when designing the Miscalculation cards, at the end of each design I would ask several people what they thought of the design, asking questions like; did it feel like the type of card they would see in a board game and (dependant on the stage of development) whether or not it fit the criteria I wanted. A clear example of this is when I was applying the writing to the cards. The writing needed to be clear – but at the same time be fitting of the design. Not including the iterative stages that the template had, it took 3 repetitions of the original cycle to create the final version
The first stage was seen as too futuristic, so in the next stage I looked at the colour of copper and made the writing look embossed – a industrial process fitting of the time. When I showed it to several people they each said that the design was hard to read and too dark. So the next stage, being happy with the overall design template, I simply increased the contrast of the writing and background so that the writing was clearer. My feedback was more positive, but still as a collective they felt that it needed to be lighter still. On the fourth stage I had lightened up almost all of the area around the writing and the response was that the writing was clearly visible and not out of place. This was exactly what I had wanted so the process stopped there. It can be seen that there is a clear improvement from the first three stages to the last and in the end, the result was far superior than had I just kept with the first stage.
Another example of the iterative process is in the film War Games – a film I had watched in Fridays afternoon viewing. In the film it features an advanced CPU that can learn from mistakes. At one stage, the CPU plays a game multiple times, each time taking different routes, calculating the results and trying again to alter the result. This internal iterative process is repeated untill the computer realises that there is no positive outcome.
This is something that often might happen should designers use the iterative process later in production rather than earlier. This is likely due to the face that constant feedback at each level will allow each idea to be refined into a complete working concept, rather than complete a concept, collect feedback on it as a whole and have to start from scratch. It is because of this that often it is obvious when games fail to achieve what they want that an iterative process has not been used.
Obviously there are a few downsides to the process, in that it takes longer and is more expensive to keep bringing in outside testers consistantly – which is why some games developers don’t follow the technique. However from a personal viewpoint and looking at the long term impact, the use of an iterative process has positives that far outweigh the negatives. If a game uses the process and is far greater due to it, then reputation grows, a fan base is gained and critics might rate it highly. If a game hasn’t used it and there are faults that appear after it has gone on sale, then the opposite will happen (damage to reputation, fan base gets angry and critics will write the game down as a failure).

No comments:
Post a Comment