QR-Anon is a prototype project developed for the HAW Games Master course.

Read on to learn more...

When	Games Master WiSe 24/25
Why	Sensoria
Platform	Mobile / ARG
Game-Engine	Web App
Genre	Parlour Game
Controls	Smartphone
Language	English
Current Version	0.0

The main inspiration for this project are Victorian-era style parlour games , similar to the ones exemplified in this SHUX video. This kind of game works by requiring participants to perform awkward and silly tasks in front of their peers, often within the (completely preposterous) frame of a "contest of skill". In truth, there is very little skill involved, and the contest itself is a sham, an excuse to put a bit of extra social pressure to a game experience that focuses on social elements to inspire engagement and playfulness .

Another important source of inspiration are "pervasive" games that run within and alongside other events, such as the classic Killer and the more recent Don't Get Got. These games provide a strong social element by making players feel part of a secret group performing hidden tasks. They demand a certain degree of buy-in and preparation, as the game activity can at times involve complex tasks.

QR-Anon is designed to be a party game blending together some core aspects of its main inspirations. Like parlour games, it is casual friendly and silliness focused. Like pervasive games, it runs in parallel with a broader event, like a party, fair or conference.

Players join the game by scanning a QR-code with their smartphones. This adds them to a chat-like web app where a mysterious task-master will broadcast a series of commands and interactive questions.

Successfully obeying to the task-master contributes to the achievement of a shared goal/score, but the real goal of the experience is to produce quirky happening-like situations among unsuspecting bystanders.

In order to test the concept, a no-code prototype was produced consisting of a series of Google Slides optimised to look and behave (within limits) like a mobile app.   Screen 01 This presents the game name and logo as a splash-screen. The logo itself works as a recruitment vector thanks to the QR-code included in its graphic design. Screen 02 This presents a short and flavourful text explaining what the game is and how it works. The game is meant to run for 1h, with an audio cue being activated externally by the game host to signal when it is time to perform one of the tasks. Screen 03 Players are offered the full list of tasks to be performed when an external signal (a stadium horn) is sounded. Screen 04 This final screen thanks the players for participating in the activity, and asks for one last task: to kindly answer to a short survey. (A separate Google Form)

Playtest Considerations

The prototype was tested in two separate occasions.

Once, with a small group of players invested in the testing activity. As expected, they had no trouble in understanding how to play the game, being alert for the horn-signal, and performing the tasks as instructed. Their feedback led to a few graphic/layout improvements and to the reduction of the tasks from 10 to 6, as they felt too frequent.

The second test, within an actual event with a crowd of strangers, held more problematic but highly educative results.

• Some players failed to understand how to interact with the prototype, being stuck at the initial splash screen. Visual cues (page counter, arrows, Next/Back) seemed insufficient.
• Some players failed to understand the game rules: how many tasks to perform at each signal, in which order, whether once or multiple times, etc.
• Some players understood everything, but chose to play by their own rules. For example, a group decided to only perform Task.3 over and over, creating a sort of "Schmetterling Gang".
• Some players joined in the game, but the effort of finding the slides again on their phone was too much of a bother. Of this group some simply dropped off the game, while others resorted to mimic what other players were doing.
• Using an external audio signal was effective, but very inconvenient, as it disrupts the main/official activity and can be immediately annoying for some guests (and players too!).
• As the "app" was not really interactive, even dedicated players ended up forgetting about the last page (the survey) as soon as the activity stopped. Thus, the only answers gathered were offered well after the event took place, thanks to people that could be individually reached with a fresh request to fill the survey.

Most of these results were expected, as the specific limitations of the no-code prototype were well known. Still, experiencing these shortcomings firsthand is a precious learning experience to evaluate possible solutions to such issues. A future iteration of the game in the form of a real interactive app should solve most if not all of these issues, if properly implemented. 

Ideal Implementation

The ideal form of this project is that of a mobile app.

A native app would allow for a more robust and feature rich implementation, but also require potential players to buy-in enough to get over the hurdle of downloading and installing the game. For such a casual activity with chance recruitment within an unrelated event, this might be a problem.

A web-app, while limited in its functionality, would have the advantage of immediacy: you scan the code, you are in the game. No download, no installation, no platform-specific versioning (Android/iOS).

Player Side

A chat-like interface delivers personalised messages to each new player.

This way the onboarding experience could be much more fluid and effective than in the prototype, delivering bite-sized sets of instructions with a small interactive prompt to keep the player engaged, attentive and make sure that every element is understood.

The delivery of individual tasks will also remove most problems caused by putting a whole list of instructions in the players' hands. Not to mention the ability to keep all participants synchronised on the same task (if so desired) or to send out different, maybe even coordinated, commands to specific individuals.

Relying on push-notifications would make the game less disruptive, intrusive and annoying for the broader hosting event, and increase the "weird factor" of seeing people randomly engage in strange actions. An obvious cue (like the stadium horn) acts as a "spoiler" that something is going on, reducing the desired effect.

Being an interactive app, the game could use tools like scores and teams to further engage players into its silly activities, offering an added sense of team-work. There would be no need of complex verification steps for such elements. The game is meant to be just an excuse to perform silly actions, causing some stupor and chaos within a larger event. Points and scores don't really matter, they are just a red herring devised to appease the taste of the more competition-oriented players.

Host Side

The game interface for the host could present a simple backend of options, allowing them to set the length of the game session, the frequency of the tasks, a predefined list of tasks, the ability to send personalised messages/tasks to individual or multiple players, etc.

The backend could also allow for the tracking of relevant information, optionally shared with players too: player IDs, player teams, scores, countdowns, etc.

Lessons Learned

• In the case of the paper prototype, the game experience works better with a higher ratio of players/bystanders.
• This means that "scale matters". Even a small gathering like the Lab's Christmas Party requires a lot of "active recruiting" to reach critical mass, when the game draws in people by itself.
• Even though the paper prototype worked in a radically different way than the intended final product, its testing was none the less surprisingly useful, producing valuable data for future development.