Week 14: Readings

GDW Chapter 10: Functionality, Completeness and Balance (pages 305—338)

This chapter focuses on the next steps that follow the playtests, working with the feedbacks received from the playtesters in order to make sure that the final version can be functional, complete, and balanced. The chapter gives examples of various questions one can ask about their games, from the early prototype stage and after, with questions that follow from functionality, to completeness and balance respectively,

Upon the first prototype of the game, it should be functional, with a set of playable rules and system that works. Usually, functionality is something I test for with my first prototype, in order to find out whether or not the core system is working. If it is, then the next steps, like adding more elements, can be taken. However, if the core gameply isn't functioning, then testing the prototype early on will allow more room to fix the core system, or even make a new one if needed. Still, I realized that sometimes, even with a functional first prototype, me or my group would go back to work on the core systems again instead of moving on to the next steps. This is usually because, when observing the playtesters, the game doesn't seem to be fun, even though it is functioning. For example, if the functional game has to much down-time for some players, I think it is better to fix the core system right away rather than moving on to the next part, since the problem will show up in the later process of making the game as well, and it may be to late to find a solutions for it then.

After that, the game should be complete, with a beginning, middle, and end state. Although the winning state (or end state) is something I planned early on, I usually have to change it halfway through the making process due to time constraints or the ending being too ambitious. When this happen, I would take out all the additional features that would create the ending and leaving it with its most core element. The chapter also mentions how testing for completeness will allow you to see how malleable the game is. By playtesting with many players, you will realize that, even though the game is functional, there can be loopholes and unfair strategies that can reduce the fun of the game.  After that, it is the job of the designers to come up with solutions to fix those loopholes. I think that testing for completeness should be done with as many playtesters as possible, in order to increase the possibilities of finding any loopholes or deadends so that they can all be addressed before the final version of the game. There are many instances where the loopholes come from my code. However, if they are from the rules or the lack of it, then I usually go through the core system once again to see which rule is affecting or causing loophole.

Next, the game should be tested to check that its is balanced and fair for all players. In my opinion, the balance is something that's harder to plan for before actually playtesting the game. While the functionality and completess can be planned fairly detailed before play testing, planning the balance is a lot trickier since there's no way to predict how the players would play the game until actually testing it. Even when the variables seemed to be balanced and make sense mathematically, something unexpected always come up in the playtests. This is beacuse there are surrounding elements to the variables as well. For example, unclear feedbacks can result in a player not realized they are getting continuously damaged, and even with a balanced number of health and damage, the game will feel unbalanced to the players.