Iterative cycles are essential to game projects. Without iteration, projects miss critical feedback in early stages, are unable to be changed when flaws are found, spiral far beyond an achievable scope, and generally dissolve into a mess of disorganization. In Fullerton’s Game Design Workshop, the author presents an iterative loop for game designers to use to avoid these things and effectively design and develop games. However, I would argue that this loop, while helpful, has some flaws that in particular create difficulties with project scope and the adaptability of the project after the initial stages of design.
This is the iterative loop diagram from Fullerton’s Game Design Workshop (p. 15). It describes how designers should create ideas to achieve goals, document or prototype them, test them or ask for feedback, then evaluate the results to determine whether the goal is achieved or the iterative loop needs to be done again for this issue. This loop is effective in getting designers to test ideas and get feedback rather than spending many resources implementing ideas only to find flaws in them later; however, in my mind it also lacks analysis of the ideas themselves, asking the designer only to create ideas and then decide whether they could be improved based on feedback. I see this as an issue because I believe that deciding what parts of the game design need new ideas is a crucial step. Given the time, designers can create ideas for improvement for any part of a game no matter how good it already is, but often many aspects of the game are at a satisfactory point while others need a lot of improvement at the current stage of the development process. Designers’ time and ideas are resources like any other, and deploying them effectively is essential to keeping a game on track in design and development.
Barry Boehm created a software-development iterative loop model that Jesse Schoel discusses in the context of game design in The Art of Game Design (p. 96). While the model itself is very complex, one important feature that it introduces is the stage of risk analysis. Before entering the loop, Schoel describes how the designer must analyze the risks of the game – things like technological capability limits, risks of not meeting the required objectives of the project, and features that might detract from the player experience. The designer uses this analysis to choose what things should be improved and what things should be left for now, and then continues to apply this analysis throughout the process to decide what to improve next, whether to continue using resources on a given task, and whether the game objectives or design should be modified. Having this step helps to efficiently direct the designer’s time and efforts, and keeps the objectives of the game in mind so that the changes the designer chooses to implement don’t expand the scope of the project outside of what is feasible. Adding a risk analysis step to Fullerton’s iterative loop makes sure that designers can work more effectively within their goals.
With this small addition, I believe Fullerton’s loop becomes much more effective and helpful for designers. I still think that the larger Brainstorming-to-Production process that Fullerton outlines is limiting – it restricts design changes in later stages, and while making large changes is generally very bad to do anytime other than in the beginning of the design process, locking out all changes too early and before acquiring sufficient feedback can also lead to games that don’t reflect the play-centrism which Fullerton promotes. However, overall, Fullerton’s iterative process promotes making edits based on feedback, frequent prototyping and documentation, and extensive planning and assurance of design choices before beginning implementation.
As a disclaimer, this is my perspective on Fullerton’s loop and is thus very subjective to my experiences and style of game design. While I intended this to be a comparison of Fullerton’s and Schoel’s two proposed models, I recognize that it is now a suggestion of an improvement to the former’s model based on the latter, and I’d love to hear if other people disagree with my criticisms, as I have limited experience in game design.
