Manual to The End

The aim of The Endwas to create a deeply personalized and empowering artwork that blended immersive theater techniques with the structured interaction of game design. Towards an open-source goal of sharing what we learned with other makers working in this form, on this page you will find an outline of and excerpts from our operating manual for the project used in both developmental rehearsals and performance of the game. This manual served a number of functions, everything from defining our macro-level goals, giving structure to how we communicated with players and tracked their journeys, to defining concrete guidelines for the day-to-day performance during its run. Preceding each document is a short paragraph explaining how it was generated and its use to the creative team. We share these documents for those interested in seeing the “script” that we used to define core mechanics/operations of the game along with some reflections on their usefulness for extrapolation towards future projects other creators might undertake.

This document was created by the core collaborative team as a way to define the goals of The End early on in its creation. This writing emerged from a collaborative prompt in which each core creator wrote a short response to the question: What is the mission of the game we are making? This exercise provided a useful opportunity to clarify what aesthetic qualities we envisioned the game would have and what philosophical perspective we were grounded in as a generative team. This exercise also provided a chance to solidify the core design choices that had emerged thus far, helping to create language to share with the players we would soon invite to apply to give a sense of how they would engage in play. We also used this document in early rehearsals with performance guides to align them to the game’s style.

Early on in development with the actors who would eventually guide players, it became obvious that we needed to define how the underlying principles created by the gamemakers would manifest through the character of The End. As the players’ main experience of live interaction with the game, The End needed to manifest the aesthetic experiences we articulated in that mission statement. In other words, we needed to create a set of rules, a script, for how The End would think and interact with those who talked to it.

This was no small feat. A vast majority of the conversations that occurred via text message were improvised, following each player’s response to a card’s quest. Unlike a traditional playwriting process, guides didn’t just need to find a compelling interpretive performance of a supernatural being – creating motivation and stakes for a non-human entity – but also be able to write that character’s thoughts and feelings on the spot in an improvised conversation. Towards this end, we created a mission statement in the voice of the character, something that would give a core sense of how the character thought and spoke. This document also draws from the language of acting objectives: defining what the character wants and some of the ways it goes about getting those desires met.

In this writing you’ll see nine core interaction modes we identified in rehearsals. After each is an emblematic statement in the voice of The End about how it articulates that dynamic. Following that emblem is further clarification language about how that manifests in the structure of the game the character offers to the player. Note that this character writing is framed as if it were speaking to the player directly so that these phrases could be transferred directly to the conversations in game, if needed.

In conjunction with the Mission Statement detailed above, we created a “diving chart” for performers to get more concrete details about each of the interaction modes. This document lists the same nine dynamics and then gives a series of action verbs that demonstrate ways the character of The End might attempt to enact this larger idea in practical application. Under each verb are examples of phrases in the stylistic voice of the character that guides could employ.

This language was crafted in rehearsals to define the overt rules that we expected players to observe. Many of these were dictated early on (things like play hours and the link for the website). Others, like the language around the three actions of DRAW, PLAY, and REFLECT, came into more specific focus as we experimented over the beta phase. While we knew there were internal expectations about what results might happen over the course of the game, we worked hard to keep the defined rules limited only to what a player needed to know so that we could stay open to emergent ways of playing that they might surprise us with. A few of these notes also gave a warning to specific problems around texting transmission that we did not have the capability of solving.

This document outlines the functional procedures of beginning and ending a day of performance. Because the tracking of a huge number of players was so multi-faceted, guides found it helpful to have a step by step checklist to refer to so they could ensure they had covered all their responsibilities at a given phase of the game. This was a functional manual (versus an archival one) that was often referred to during active play.

While rehearsing the beta run of the game, we learned just how tricky it was to have a character whose role was shared across eight different performers. For players of the game it was imperative that regardless of which actor they talked to during a day’s play, their sense of The End’s persona stayed consistent. Simple grammatical differences like a preference for an ellipsis to indicate a pause, if not used by all guides, quickly exposed an individual actor. It became clear that in addition to overarching objectives for The End as a character, it was necessary to create a much more detailed set of guidelines that standardized how The End wrote in the improvisational interactions.

This document outlines different aspects that emerged through the iterative testing of the game that could potentially disrupt the continuity of the character portrayal. It includes overarching style rules, specific grammar consistencies to observe, standardized language around daily mechanics of play, notes on where best to focus conversation, nitty gritty specifics about what this supernatural creature says about the physical world and its own being, and commonly used phrases.

The team created dossiers on each player to ensure that information from one day’s session guiding a player was logged and available for the next guide to interact with them. Dossiers were developed over the beta month and continually updated for most efficient use. These were logged both online and printed for easy access as a paper copy for perusal during active guiding. These dossiers also helped to act as a physical tracker – the binders they were housed in moved from one storage spot in the room to another when a player texted in, another while they were out on a quest, and a final spot after they completed a day. This gave an easy physical way to track where players had progressed at the end of the day.

This dossier shows an anonymized player to give examples of the kinds of data collected. The first page was displayed as a cover to the dossier binder for quick access to macro-level game notes (mission, major past experiences that were recurring themes, anything that the player commented about cards they wanted to draw, etc). Page 2 was placed on the back cover and includes important but less urgent info than page 1. Page three shows a card in the game where players defined activities that helped calm intense feelings, a useful thing to keep on hand. The following pages give a sense of the kinds of notes tracked in daily interactions for subsequent guides.

Note that players never saw these documents; they were only internal to the team for tracking purposes. Additionally, this dossier was a place that also developed internal protocols for recording in. We learned that the less “judgement” we made of the player and the more of their own words we could directly share with the next guide, the less we gave a distorted view of them.

Because the information in the dossiers was so extensive, it felt useful to have a secondary system that gave a quick snapshot of a player within a few seconds. Because of the volume of attention required once a player and guide start talking, this sticky note system gave “need to know” communications when the full read of a previous day’s dossier was not functionally possible. Here you’ll see the generic form we used to capture the absolute important data. Note these sticky notes were placed inside on the front page of the dossier binders.

The End’s script was constructed in two parts: scripts for a given day of play and scripts relating to a card quest undertaken by a player. This document shows a few excerpts of how we constructed “day scripts,” language that was required to communicate to a player because they were undertaking a required step in the overall progression. This happened more extensively in the beginning of the game as players learned the ropes and at several delineated points where they needed to undertake required quests. Generally, when required day scripts were used these were printed for guides to easily refer to, and also open in computer tabs so the content could be cut and pasted if needed.

In this particular day script – usually performed on the sixth day of the month – you will see how guides navigate three different card options (Cards 7, 8 and 9) that a player has to choose from. Two of these result in a phone prompt, one in a solo walking quest.

Some formatting notes to help navigate this text:

The title of the document indicates the day of the month first, the options for card draw, and finally the number of days left before the finish

Bold and underlined headings indicate which part of game the player is engaging

Text on the right side is system-wide communication (ie – texts sent to all players at the start or end of the day). These are useful for guides to see but aren’t sent by them.

Text on the far left side is language for guides to say to players in live time.

Black font indicates text to be texted to the player. When bolded text this language (or some version of it) is required to be communicated.

Non-bolded text is optional but potentially useful, always subject to following the player’s lead.

Blue font indicates language that is not script to be sent to player, such as improvisation suggestions/guidelines or texts sent as Announcements. When bracketed it indicates stage directions or what action must occur to engage this set of language.

Highlighted language indicates spots where a guide might need to look at a player’s dossier for information or time-sensitive responses for a card

This document shows a sample of a “card script.” Card scripts are the second half of the structured language in the game. While many responses were improvised, some cards required specific directions to the player via text, which is indicated in this section of the script catalogue. Additionally, card scripts detailed all the online portal text that a player would encounter. The performances guides all familiarized themselves with this text throughout the beta and rehearsal phases of the game. Additionally, we had large posters that included quick synopsis of each card for easy reference. Several quests required performances by guides or hired actors over the phone or in person. A sample of how these interactive performances were scripted is included here as well.

Over the course of the beta run and the full game we found that it was also helpful to have a document that aggregated many kinds of data about a given card in a single place. We came to call this the “cheat sheet” and in it included various aspects that would be useful at a glance: a card’s name and image, a brief summary of what the card does, notes about drawing it with a player, and/or useful hints in reflecting on it. We also included content tags and modes of interaction here in the aim that if we ever turned this into a searchable database, we could enter key words to identify cards. While we were iteratively testing cards, we also used this document to keep notes on potential changes to the writing.