Case Study: Using Iterative Design
I spoke previously of following an iterative design pattern in Development Blog n°2, but never truly delved deeply into it. For this log, I will be looking deeper into this process, looking at two sources:
- “Making Games Better Through Iteration”, by Will Luton.
- “How I Teach Games Design, Lesson 1: The Game Design Process”, by Eric Zimmerman.
In layman’s terms, iterative process is trial and error. The designer has an idea in their head, tries to build it, makes it go through stress testing, playtesting and observation through an ‘uncorrupted’ (or open-minded) individual, who then gives feedback on the product’s features, design and enjoyability. The designer then goes to fix and improve their product according to this feedback, sorting the viable from the impossible, applying and presenting the product again. Rinse and repeat until completion.
Eric Zimmerman describes the iterative process as: “[…] a process focused on playtesting. You produce a playable prototype of a game as quickly as possible, then playtest the prototype, and you decide how to evolve the game based on the experience of the playtest.” (2013)
According to Will Luton, iterative design is best applied on small games as it allows to design fast, and fail faster, knocking impossible concepts out of the park and patching the project as it goes. The iterative process allows for a quick and reactive approach to design. (2021) Consequently, this was exactly what I needed.
Whilst Zimmerman explains the process of iteration as a 4-step plan (step 1: design a prototype -> step 2: playtest your prototype -> step 3: analyse what happened -> step 4: back to step 1), Luton presents a whole diagram which itself is just as comprehensive.
The speed at which this helps develop and hone the rough edges of the game was staggering. My first playable was well within a day, from which I had a stream of feedback that could be used to reiterate the features and gameplay.
I also noticed this applies to the feel and intention behind a product. For instance, I had planned on something more stressful and turbulent to reflect the turmoil that is planning, scheduling and time management for people diagnosed with ADD. Dragging and dropping objects, as I had both experienced and was shown, is not as nervous or quick as I had intended. One can only go as quick as one’s mouse, and without a time constraint the mechanic is closer to soothing. A “game feel” I adopted instead, as explained in my Development Blog n°1.
There are pitfalls to this design process of course, it is important to ensure your original vision does not become diluted in the flow of feedback given. Play testers may give their own vision, or propose solutions that can detract from the game, or offer additional features that cannot be achieved within the time constraints.
“It’s important to be critical of playtesting, and of the reactions your play testers might have to your game. Like any design concept or methodological tool, playtesting is not universally valid or true, and there are many ways to playtest well or poorly.” E. Zimmerman (2013)
Similarly, Luton agrees with his, claiming it must be done with thought and concern for the type of team and desired outcome. (2021).
Whilst I do not feel as if my project itself has been diluted, this process has helped me determine what was possible, and what would have to be left for further improvement/resubmission. There has also been a net evolution in how the project came out. From a basic game of stacking blocks into a bizarre twist in Tetris, A Day Well Spent has become an enjoyable experience that conveys the importance of a well-balanced schedule. Additional features would focus more on the experimental aspect, and add longer term goals, such as ongoing projects or getting through the week without overworking oneself.
Using PlayerPrefs (a function I had not heard of until now), I could keep track of the number of days gone past, as well as the metrics for each need, before amount the whole.