Documentation: Vicky

I still think of the ideas phase of the game as one of the most interesting. Although the idea was originally to have two games at different scales, we eventually narrowed it down to one. Half of the reason for this was practical- we saw how much work we had for all our classes during the relatively short summer, and no one wanted to invite extra work upon themselves if they did not have to. The other half of the reason was sentimental. We wanted to do a group project together as the first class of MSAUD so that we use this as an excuse of a bonding experience for the cohort as well as leaving something together that later cohorts could look back on us for.

Due to the amount of people on the project, the challenge came down to narrowing down a concept that would please everyone and not prioritize the views of any one member over others. I think it is the part that, for me, was the most difficult, as I feel like I am naturally more outspoken but at the same time had a fear of talking over the ideas of others. I think the creation of an opt-in agreement system, rather than silence-as-agreement, is very helpful for us. It was a good temperature gauge of how much others agree with the idea vs who is just going along because they don’t want to rock the boat – an immediate chorus of knocking might indicate everyone likes the idea, one of two tepid knocks after a three second pause, perhaps less so. It gives a good indication of which ideas needs more workshopping.

I kind of hope that we could have had a similar process during the game itself, but I think it would also detract from the urgent pacing of the game. Still, I feel like in-game, sometimes it ends up being a certain few people making up strategies and maneuvering others to follow, which might be more realistic to how life works, but is still kind of a hard pill to swallow after the game is over.

It was interesting to see how the process of developing the game mirrored how the game played eventually. One of the most obvious components is the collaboration between the players / members of the class that is required to complete the project. Another could be how the introduction of the time limit forced urgency and therefore forced the members of the class/ players to examine their own strengths in order the best complete the mission of the collective while managing their resources of tokens/ energy.

An example of how this played out in class is the assignment of tasks due to the strengths of the members of the team, such as putting our best graphic designer on designing the visual language for the class. It also plays out as how in some rounds, some players might be able to do less than others, whereas the same players accomplish more in other rounds, but nonetheless in the long run everyone contributes to the win state equally. This calls into question if we designed the ‘ideal’ for collaboration within the game based on the how we naturally collaborate with each other as a class, and if we were a different group of people with different dynamics – or even if we designed the game nine months ago where we knew each other much less – the game would still promote the same dynamics it does now.

We ultimately won the game by setting expectations relatively low and then meeting it, upon which, hypothetically, we would set a more ambitious objective once the base requirements have been met. This also resulted in an interesting perception of urgency, where time went slowly at the beginning, sped up significantly after certain key moments, and then slowed down again once the wall/ project is about 80% done and there was no longer fear that the plan would not come to fruition. This is especially interesting in the game itself, where the constant timer creates a sense of time dilation. Even though it is not as evident, I think we sensed it as well during the creation of the game, where the pressure of the weeks leading up to the final was very intense, and then on the last two days, once the major components were done, we felt much freer to experiment or hypothesize on later additions to the game.

The format of game making, just like urban design, forces the designer to consider all possibilities of interaction, yet at the same time accept that the unpredictable. Although in designing both there are elements that we can put in to hypothesize a certain future interaction – whether that be in the inclusion of curvilinear benches or certain metrics that the player must reach, the designer must, at some point, relinquish the control of the design’s future to the users. Methods of prediction, such as playtesting or prototype builds, are often down under controlled environments where the designers are oftentimes close to the testers if not the testers themselves, therefore making the test susceptible to bias due to preexisting knowledge of the work or the creator.

So as disquieting as it sometimes may be to watch, it is ultimately the role of the designer to let of of their work, and let it take a life of its own.