Prototype #1 Post-Mortem

Composed by Chris Crone, Programmer

After Prototype 0, we decided that Prototype 1 would be about an ethical dilemma about deleting an android’s memories, and that I would champion the effort. Prototype 1 would feature puzzle games representing the player hacking into the android’s brain. During puzzle games, the player would hear emotive sounds from the android, and these sounds would convey information necessary for solving the puzzles. Ostensibly, the goal of Prototype 1 was to show that players will become more aware of emotive sounds if those sounds also carry information relevant to the players’ game goals.


What Went Right

From the beginning of work on Prototype 1, we shaped a design that would incorporate a sizeable amount of work from each of our respective disciplines: art, programming, and writing. This allowed each of us to focus on doing the best work possible with our individual disciplines, without worrying too much about pipeline dependency issues. By the end of work on prototype 1, each of us had produced good quality work as individuals, and we had a coherent game that incorporated that work.

About half way through work on Prototype 1, we got some very useful ideas and feedback from Jesse Schell about the direction of the prototype, and we subsequently refined the goal of the project. From that point, we started focusing our efforts more specifically on making players feel conflicted over whether they should delete the android’s memories, or whether they should continue to investigate the memories. If we could craft the game such that half of players would want to investigate all the android’s memories, while the other half of players would stop investigating the memories because they felt bad about causing pain to the android, then we could conclude that players were emotionally involved in the game’s decisions. Targeting the development of the prototype towards this goal lent some clarity of focus to our work.

When we stopped work on Prototype 1, it was complete in that it had all of the features we had planned for, and we were able to conduct instructive external tests with the finished prototype. Although the prototype wasn’t successful in making players feel conflicted over whether or not to continue investigating the android’s memories, we were able to gather useful information about why players weren’t conflicted, and what we could have done differently to amend that situation.

Experimental Findings and Analysis

We had more than a dozen external players test the game, and all of them wanted to investigate the android’s memories to completion. Some of them didn’t actually investigate the memories to completion, instead getting stuck at some point in the puzzle and deleting the android’s memories out of sheer frustration. However, no one deleted the memories out of pity for the android.

After collating feedback from the test players, we could identify a number of reasons why people would want to investigate all of the memories:

1) The memory movies tell a story of increasing interest. People want to see the memories’ story through to conclusion, and they want to understand the game’s back story.

2) There is an authoritative character who clearly instructs players to continue investigating the android’s memories. This is an especially relevant factor for players who may be confused with the interface, or generally players taking some time to understand what the game wants from them.

3) Investigating the android’s memories is done by solving the game’s puzzles, and there were some players who were simply compelled to complete the puzzles for their own sake.

Most players said that they did feel empathy toward the android, but that those empathetic feelings didn’t factor into their choice to investigate the android’s memories. In other words, players were aware of both the consequences affecting the android, and of their choice to affect the android; however they did not feel a significant connection between their choices and the consequences for the android.

When asked why they didn’t feel this connection between choice and consequence, some players suggested that they would have felt more responsible for the android if she had provided more feedback to their actions. For example, when the player makes an action that brings the puzzle closer to solution, the android could say something like “Stop, you’ll make me remember Janey dying!” This type of feedback would make it clearer to players the relationship between their choices and the consequences affecting the android. In other words, players would have been more emotionally involved in the decision about the android’s memories if the android had been a more reactive character. Prototype 1 exemplifies that reactivity in virtual characters not only makes those characters more plausible and immersive in general, it is especially important for emotionally investing players in their choices regarding those characters.

As for what we can conclude about the supposed experimental goal of the Prototype 1, whether players gain heightened awareness of emotive sounds when those sounds carry information useful for the game, conclusions are harder to draw. Towards the end of developing Prototype 1, we had to settle for a puzzle design where sounds are extraneous information to the player, because puzzles that required information from the sounds in order to be solved were too difficult for players. Because the emotive sounds were redundant with other, visually presented information, players did not pay much attention to them or comment on them.

What Went Wrong

That we couldn’t draw conclusions about sound as a game feedback device was but one symptom of some underlying, deep-rooted problems plaguing our project. What happened in the case of sound was that there was some ambiguity over who was responsible for handling sound design tasks, and those tasks were delayed while we focused more on our respective individual disciplines (art, writing, and programming).

The underlying problem on this prototype was an absence of clearly stated goals that we could all agree to. I said in the background of this document that the goal of this prototype was “ostensibly” to experiment with emotive sound as a game feedback device, but in fact we did not share the understanding that that was our goal throughout the development cycle. As a result, the prototype suffered feature creep (some features were added that were not strictly necessary for the purpose of our experiment), and some work that would have made the experiment more successful was neglected.

While in retrospect it may seem like a painfully obvious mistake to proceed in development without clearly stating and agreeing to our goal, it is important to examine the reasons why we didn’t do so:

1) Although we did not have a clear, shared goal, we did have a shared plan for the design of Prototype 1 from day one of development. We thought this meant we were in agreement about what we were doing, and we were wrong. Without a goal, nothing will guide the inevitable changes that happen to a design, and nothing specifies which parts of the design are critical, and which parts can be put off until later. Having a shared design without a shared goal gave us a false sense of security about the team’s communication process.

2) Personally, I was reluctant to impose my ideas and objectives on my teammates more than necessary, and hence I failed to be more pro-active with clarifying our goals (and I think the rest of the team might share variations on this sentiment). I erroneously thought that this would allow each of us to have more creative input and be more invested in our work. This thinking was a critical mistake: While it is important for each team member to have creative input and control over his/her own work, the desire for these things absolutely cannot come before the need to have a single, shared goal that everyone agrees is the top priority. Otherwise, it’s not the work of a team.

Conclusions

Analysis of feedback from our test session suggests that making virtual characters reactive to player actions is especially important for making the player cognitive of the connection between the player’s choices and consequences that affect the virtual character.

For our team moving forward with later prototypes, it is essential that we are pro-active about clarifying exactly what goals we’re trying to achieve with each prototype. In each case, we need to reach a consensus about these goals. Furthermore, we need to be willing to have critical discussions about our prototype designs, where we consider which parts of the design are most important for reaching our agreed goals and take subsequent action.

Background

Project Context is a student-pitched project at the Entertainment Technology Center, initially with the goal of creating a gameplay system based on character interaction. Early in the semester, we the team members were not reaching consensus as to how to create such a gameplay system, and a change of plans became necessary. Our faculty advisors identified that, while we had different opinions about how a character-based gameplay system could be created, we all shared a desire to make games more emotionally immersive. We agreed to a new project goal: “To create prototypes that find new ways of emotionally investing video game players.” To pursue this goal, we would create a series of prototypes, each in two weeks, and each with a different team member serving as the champion / director of the prototype. Before creating experimental prototypes in earnest, we quickly created Prototype 0 to establish our work pipeline.