Audience Participation Games Project
From July 2016 to May 2017, I worked as a game designer and researcher for Carnegie Mellon University's Human Computer Interaction Institute on the Audience Participation Game (APG) Project. I designed and developed Pitcrew, an experimental racing APG, with game designer Nathan McKenzie. I also contributed the ludo-research for the paper: "Analytic Frameworks for Audience Participation Games and Tools" which was presented at the Spectating Play Conference in Tampere, Finland on April 24-25, 2017. I documented the project on a weekly blog: here.
Pitcrew
Download the build here. Link to audience interface: http://bit.ly/2pzDIdD
Pitcrew was intended to be an experimental exploration of the design space of Audience Participation Games (APGs) made in tandem with research into a framework for understanding the mechanics of existing, intentionally designed APGs. (This excludes games that are APG-ified through external tools or streamer intervention, such as naming your XCOM soldiers after viewers, though we did take note of those occurrences during research.) We wanted to learn the sequence of design choices that lead to the audience experiences, streamer experiences, timing mechanisms, and audience aggregation we see in the space. We wanted to make an APG that pushed the boundaries of how audiences interacted with the game through an interface; we wanted to expand upon the common voting mechanic as audience aggregation. We wanted to gain insight into the motivations of each level of the APG hierarchy, from viewers to participants to subscribers to streamers.
Pitcrew was designed and developed by Rachel Moeller (me) and Nathan McKenzie, lead designer on the APG project. Nathan created the Ludolab APG networking tools, developed the HTML interface for the audience, and advised the project, while I developed, created the assets, and designed it. I created five APG prototypes in the Fall of 2016, and the full Ludolab team chose the Pitcrew prototype for development. From January to May, Nathan and I met weekly for coworking (Nathan was also designing and developing his own APG, Gods of Spoons and Socks, as well as iterating the networking tools) and design discussion. The Ludolab designers and stakeholders met biweekly for extended design discussions. The research team (Jessica Hammer, Safinah Ali, Judeth Oden Choi, and I) met biweekly to discuss progress and emerging trends. The research team produced Analytic Frameworks for Audience Participation Games and Tools which went to the Spectating Play conference in Tampere, Finland on April 24-25, 2017. I wrote the ludographic portion of the paper. While not in coworking, I worked on Pitcrew alone or at CMU Playtest Night for about 7 hours each week. Expanding on the first Pitcrew prototype, I first created the main racing experience. I playtested this basic racing functionality with racing game players and non-genre players at CMU Playtest Night. Nathan and I then implemented the networking, adjusting the design around technical hurdles. As the networking tools became more robust, we used Pitcrew to iterate them.
Pitcrew was my first racing game and my first networked game. Pitcrew’s intended tone was absurd and while that is mirrored in how the car handles, I learned that racing games are a cavalcade of fine tuning. I learned the basics of networking and IRC events, how to package and receive messages, and the effects of information travel time on player/streamer experience.
Quickly we learned that streamer and audience relationship is affected by APG mechanics and streamers, as the financial gatekeepers of APGs, will only repeatedly play what they perceive as fun (regardless of the audience.) This led to safeguards for the streamer so that the audience could not remove their agency through their choice of car build. This included revealing the car builds of the pitstops to the streamer so they can choose which build to receive (though obfuscating the streamer’s information about the current state of their car by not giving them concrete numbers but a dial on a spectrum from low to high), allowing the streamer enough gas/time to choose between pitstops (though this is limited to force the streamer to interact with the pitstops on some level), and extra handling controls like the emergency brake. I was also careful to make all the choices the audience can make situational, meaning that there are never choices that affect the streamer in purely negative (ex: automatically killing off the streamer) or positive ways (ex: restoring the streamer’s health.) All of the audience effects on the streamer depend on context. In looking at other APGs we found that streamers quickly get tired of consistent negative behaviors against them, and audiences generally feel very strongly about their streamers (though how this adoration is expressed varies wildly depending on the stream’s culture.) Context driven effects lead to more complex opportunities for stream generated meta narrative and I felt it provided more options for forming and expressing stream culture.
Audiences are often aggregated into a mass of input in APGs. For example, voting turns an audience of 15 into a god force or a player 2 force. We learned that expressability and individuality diversified the experiences audience members had when participating, even if those mechanics did not directly affect gameplay. This led to the visual representation of chatting viewers and their individual usernames as fans in the stands of the in-game track. This was also an attempt to include viewers who have no desire to participate in the game, as pure spectatorship is a strong motivation for users of livestreaming platforms.
Scaling became a big question for the game, including the question of “is this game playable without an audience? /is this game fun without an audience?” I opted to answer yes by including some basic AI that changes the pitstop builds every 30 seconds if there are no audience members playing. We also needed to address how audience members were allocated across the pitstops and capping the number of total audience participants. The cap was necessary to appropriately route and make agent the choices of each participant. Few existing APGs do this, an aggregation technique we called “Dedicated Participation.” Originally, I designed each pitstop to scale from 5 to 15 players. Car builds would have five areas to change: interior, paneling, peripherals, engine, and tires and up to 3 audience participants could change car parts in those areas. For example, the engine block contained pistons, sparkplugs, and a casing and an audience participant would be assigned to each part, with three choices per part. Each choice affected two areas of the car’s score attributes: Weight (rotation angle), Speed (acceleration rate), or Suave (how far the camera was zoomed out over the car). The combination of all of these part values would result in the total car build. If there were less than 15 players, only one audience participant would get assigned to each block and would only change one part (one audience participant affecting the engine’s pistons). If there were a number between 5 and 15, audience participants would get distributed evenly over the blocks. If there were less than 5, players would get spread over different pitstops with their single choice affecting the build at that location. This choice ended up being much more compelling, especially since most streamers have very small audiences. In the current iteration of the build, the number of audience participants is capped at 3, with each audience participant getting control over a set of parts in the engine. There are three pitstops in the game, and all carry the same build constructed from the audience input. If there are 1 or 2 audience members, their choices are the only changes to the build (we do not add a dummy player.) We made this decision due to scope and hope that future iterations of the game can better address the issue of scaling.
Time and delay were also significant factors in the design of the game. Messages between client and server are sent within seconds, but the effects of those messages won’t show up in the stream for at least 15 seconds. To mitigate the feeling of waiting, I chose to display the full car build in the participant’s interface. They see the specific effects of their part choice, the grand car build, the names of their teammates working in the same block, and their teammate’s choices (in the form of changing sprites; each part has 3 options, each with a different corresponding image) changing in real time. Participant changes are collected and sent down at regular, but delayed intervals to prevent spamming. I chose not to display this collection interval to keep this visual activity going and to provide the illusion of immediate change/agency. The streamer sees this change in-game within a second, so their reactions can occur in somewhat real time as well. So even though the stream that audience participants watch will lag to show their changes, the participants are still getting immediate feedback from their choices.
Getting the networking working was a challenge and took the longest time to implement. Making sure to set aside lots of time for networking debugging is a must.
Check out all my posts on the APG project with CMU’s Ludolab (listed in chronological order):