PR Nightmare Post-mortem
For our second Studio project, my cohort and I were divided into seven teams and briefed on a ‘Video(Board) game’. The VBG is a board game that integrates with a video component. The brief set us up with a common base:
- Game must have three players
- Incident Detail Cards:
- Cards flipped every round that introduce a theoretical ‘incident’ which occurs in the situations each game is set up with
- Five Incident Detail cards played in the setup phase, put face-down in the middle of the field.
- While all five cards will introduce separate incidents, they all must tie into a greater ‘episodic’ format to accommodate the video portion in a series of episodes in a series which involves the six other teams.
- Response Cards
- A variety of replies for the Incidents. These will have varying effects based on the incident Detail Cards – the result of which will be conveyed using the video portion
- As part of a television show, our cohort devised a storyline. The mayor of Muda Muda lives in a town where bad things happen, and the press comes to him for his thoughts. Each team creates a ‘season’ in the overall story, and as such each team must continue the story seamlessly between episodes.
Each team needed to tie a unique mechanic into the game, and my team devised a ‘pitching’ system. When responding to an Incident Detail Card – each player will place their Responses face-down, and altogether will flip their cards and convince the other players to pitch their vote for another player. A player cannot vote for themselves, and between three players, one response should head the team. The response card and Incident card are input into the companion software, and the players would receive video feedback of their gameplay. Behind the scenes, the game will accrue approval or disapproval which after 5 incidents, will determine whether or not the winning player “wins” or “loses”
Getting the game started was quick and straightforward. I made an effort to clarify all aspects of the brief as soon as possible, in addition to using the Friday session to lock down the game’s design. Getting started more quickly let us get a draft design down instantly and made us more prepared for the pitch. Hastily formulating the design in this way encouraged myself and my other designers to be critical and never let an idea sit around for too long without scrutiny. For this to be more efficient in future, gathering the team immediately after receiving a brief and completing a brainstorming “sprint” where the team encourages harsh scrutiny and quick feedback – which will result in a more robust design which has received input from all members of the team. In this way, the design belongs to everybody, and everybody is responsible for it.
When we received the briefing of this task, the skeleton game had no set story but was limited to being connected to the six other teams’ stories. With no set canon for the story, the only guidance we received from our facilitators at first was a story that was “funny”, and “cringey”, and the entire class did a brainstorming session where we suggested incidents for our episodic themes. For me, the output from this class was that we needed to write incidents that were absurd and unusual. With this guidance in mind, we created a story where a Florida Man – after an incident with his pet pony – sought legal restitution and the game’s various incidents related to the outcry from both sides. While we tried to focus our humour on the ‘Florida Man’ meme, our story simply was not good and relied on knowledge or insight that players might be missing. Instead, the team instead wrote a better story which made sense in the context of our cohort’s ‘episodes’ and was more appropriate for our mechanics. To ensure that the team writes more cohesive stories in future, the team should write a story inspired by our game’s mechanics. We need to ask ourselves “what does our gameplay mean?” before asking “How can we create a situation that is ‘funny/comedic/over the top’”. Further, seeking feedback from lecturers about our plots will ensure that we get feedback regarding our stories earlier and make changes sooner. Preferably, we can have a well-received story at the pitching phase, and receive feedback to make it better after that, instead of further down the line when changes are harder to make.
The workload of the task was unbalanced and unwieldy. Because the vast majority of the experience of the game is entirely physical, the designers were the ones writing, pitching, developing and iterating designs. Since their skill-sets are primarily digital, there few little tasks for the programmers to do. A pre-built Unity project featuring built-in functionality for video playback and Response/Incident card input served the base for out technical side, and our programmers could modify it to enable approval systems and work within our designs. While, in the end, everybody did have some work to do, I don’t believe the task distribution was balanced at all. Further, the team had not appointed a formal “project manager”, and as a result, I don’t think that the team prioritised deadline sensitivity.
To balance the project’s task backlog in future, the entire backlog needs to be input into software like Hack’n’Plan – a project management tool designed for Game Developers. The various tasks each team member should do can be clearly and evenly defined by the Lead Designer and Programmer, and all the tasks distributed to all team members. Setting up a project management tool will help to even the workload between all team members, and serves to allow the Project Manager to keep track of the work. The project manager themselves must push for the timely completion of tasks such that every team member is ready for each session
In the spirit of Tony Parmenter’s advice to probe playtesters with questions that do not prime them to discuss their feelings, our testing methodology was as follows:
- Begin playtesting session after a basic introduction to the game
- (as directed by the Studio Facilitators) Restrict developers from talking for 10 minutes
- When the session was complete, playtesters completed a 4 question questionnaire
This approach to playtesting resulted in several conflicts and violating interactions. Firstly, the temptation of creators to address concerns of playtesters was high, and in passing, I noticed that amendments were made to the Instruction manual in the middle of play to clarify the game’s instructions before testers had executed the design. Secondly, addressing playtesting concerns spoils the flow of the game, since playtesters are no longer primed to think “out loud” for the creators to make a note of. Thirdly, the testing methodology included no priming sentence or operation, which resulted in inconsistent playtesting data because some team members would give spoken context, and others would let the instructions give the primer. Fourthly, the playtesting questionnaire was effective, but I believe that the minuscule variety of questions did not gauge the breadth of the experience. The survey included questions such as:
- Describe a moment where you convinced another player to select your card
- Describe a moment where someone else convinced you to vote for their card
- Describe a moment where you wished you had a card that you had already used earlier
- Describe where your main focus was when you played
While these questions gauged the results of the game’s core aspects, I believe that it would be prudent to probe further into playtesters to assess their understanding of the game, such as:
- Describe how the Deliberation Phase/Incident Phase works
- Describe a time when you were confused by the instructions
- Describe the ease of which you were able to engage with PR Nightmare’s gameplay
- Describe a card which was difficult to understand how to play
- Describe a moment where you felt like your card should have been selected, but nobody voted for it
Fifthly, to improve the quality of results when testing, people who have experienced any version of the game previously should not be mixed with testers who have not. This results in the experienced player being the crutch when players misunderstand the instructions, and similar to if they asked developers gameplay questions, the testers do not get a wholly fresh experience with PR Nightmare, and may be less likely to think out loud when confused
As a measure to remove the temptation to communicate with players, I believe that developers should not be in the same space as the playtesters, and we should record their gameplay. Using a simple primer on a printed piece of paper, playtesters will enter the room and read it, and begin the game in front of a webcam/recorder. The aftermath results in a format which can be re-watched and analysed after the fact.
Overall, PR Nightmare released on-time, with all of its features implemented. While some issues with playtesting, story writing and project management hurt the efficiency of the team, the final product achieved all of its goals, and I consider it a success. As I said to my facilitator in class, I just wish that the things we had learned, and the playtesting results we acquired, had existed a week or so advance to polish and finalise the product to the standard I’d prefer.