[Top Secret] (James Long) and a play-by-email IF tool

James Long is Kickstarting an interactive story game called [Top Secret], played via email, which explores the Snowden story:

A fresh recruit to the National Security Agency (NSA), you have a new mission: find out who’s leaking TOP SECRET documents to the press. Stop them by whatever means necessary.

A single selector (phone number, email address, name) is all it takes for your team to surveil a target. It’s your job to decipher the intel, and follow the trail to its source.

But surveillance has a price…

In the paranoid world of the NSA, anyone can become a target, and soon your friends are in the firing line.

Part of his project is also to finish and release the play-by-email storytelling tool for general use, so I invited him to talk a little more about what that is and how it will work.

ES: Aside from (obviously) the Snowden concept, what sorts of stories do you think would lend themselves to this presentation?

JL: One of the great things is that it is truly “real time”. So with the Snowden story, I want to roughly match the 2 weeks in the run up to the leaks as they happened. It allows the author to pace the story and give time to the player to make choices and reflect on what’s happening. You can also inject meaning into the time between messages as well as content. e.g. if someone is excited, or angry about a conversation they may reply quickly, whereas disinterest, low spirits, or just being busy may result in delayed responses.

So I think there are rich mechanical opportunities to explore, but to be honest, I’m not sure what’s best for it – I’m discovering as I go!

I know there is a game called Lifeline on iOS which was app-based but also real-time. I haven’t played it (don’t own an iPhone), but I know that used time to give a sense of progression. e.g. the player would decide where the character should go, and several hours later, the character would ping to say they’ve arrived. (I’m sure they did more interesting stuff than this).

ES: How is your system deciding what to send back to players? Is it doing a simple keyword search on their email response, or is something more going on here?

JL: Yes, I can specifiy multiple keywords (or keyphrases) and trigger events when the keyword/keyphrase is detected. Such events include:

– sending a new message in the current email thread
– sending a new message in a new thread
– spawning concurrent email threads
– emails which are sent if none of the keywords are matched
– emails which match against any response

All the data is generated by a client-side web application I have created.

ES: Thinking about the structure of CYOA games here, I could easily imagine a situation where you want to bring several threads of story back together into a bottleneck. For instance, one might want to write the player an email where the first half of the email acknowledges/responds to what they’ve just done while the second half introduces a new chapter of the story that is the same for everyone who plays. Does your system allow for concatenating an email message out of pieces this way?

JL: No, my system does not allow for this yet – I also intend to do this post kickstarter. Each message body will be a concatenation of an array of paragraphs, each para will have an id so that it can be reused across multiple message bodies.

ES: How much state is the system tracking for each player? Is it remembering information about what they’ve done in the past?

Custom vars are stored for each player (firstName, lastName etc) and can be substituted into messages using a $ prefix, for example “Hi $firstName”.

However, there is no general way to extract vars from received messages right now – all of the vars are manually detected and stored. E.g. I haven’t yet implemented character disposition vars, and there is no delayed branching yet. The ability to store and query vars in a completely data-driven way will be added after the Kickstarter (assuming it is successful!).

ES: But in theory, then, the final version of the system would be able to respond differently to the same email input depending on what the player had done in the past. (“Differently” in the sense of leading to different narrative outcomes, not just swapping in a name variable.)

JL: Yes. In the simplest case there would be support for setting vars, and if/else/endif sections in text. I would like to support more expressions and logic than this (like twine) but it depends how quickly things progress. I don’t want to make any promises!

ES: Does an author need to be maintaining their own server in order to run a game with this?

JL: Yes, you do need a server to handle the email traffic. At the moment I use a single Amazon EC2 instance. Because the required latency for email is so low (I’m used to making games which run at 60Hz whereas emails activity is on the order of minutes), I’m currently operating completely within the free tier for Amazon Web Services (AWS) so my database and server cost nothing to run.

There is definitely some complexity with creating the server instance in the first place. (If you’re familiar with AWS then I have an Elastic Load Balancer and healthcheck setup). The database is easy to set up.

At the moment it’s definitely not something where say, a non-technical user could do everything. One of the stretch goals for the Kickstarter (unannounced yet) is to make the whole process completely non-technical – i.e. offer a web service ala twine/inklewriter which handled the setting up of the server (or even ran multiple games off the same server).

Here’s a commented message from the game which might help explain more. This whole data structure is a ‘thread message’. Basically a thread message sends a new email and controls what happens next. Multiple thread messages can be active for a player at any time.

{
  "name": "pgpIntro_0",
  "newConversation": true, // Starts a new email thread if true
  "endGame": false, // Does sending this message end the game?
  "message": { // This email is sent on creation of the threadMessage
    "from": "tom",
    "to": [],
    "subject": "PGP",
    "body": "Hey $firstName, welcome to the team!\n\nI hear you’re new 
      to the agency and might not be that familiar with our encryption 
      methods - do you know PGP? \n\n\nEd Mathis,\nCryptanalyst, TAO" 
      // Note the var substitution
  },
  "encrypted": true, // The game can send encrypted messages using PGP
  "receiver": null, // This allows sending and receiving of unsolicited 
      email messages but don't worry about that for now
  "replyOptions": {
    "type": "default", // There are a few reply types by default is 
      used in 90% of cases
    "custom": [
      {
        "name": "yes",
        "matches": [ // This reply option is triggered by the yes 
          keyword
          "yes"
        ],
        "threadDelay": { // The thread message to trigger if the above 
          matches are satisfied
          "name": "pgpIntro_1",
          "delayMins": 5 // Time delay until the next threadMessage
        }
      },
      {
        "name": "no",
        "matches": [
          "no"
        ],
        "threadDelay": {
          "name": "pgpIntro_0_no",
          "delayMins": 5
        }
      }
    ],
    "default": null, // Reply option which matches any reply (optional)
    "invalid": { // Reply option triggered if none of the above reply 
      options are matched
      "name": "pgpIntro_0_invalid",
      "delayMins": 5
    }
  },
  "children": [], // Concurrent email threads spawned on creation of 
    this thread message
  "fallback": { // Thread message created if non replied are received 
    after delayMins
    "name": "pgpIntro_0_fallback",
    "delayMins": 300
  }
}  

All the data is created and stored using a web app gui so authors don’t see the data structure above. The last big bit of tech which needs to be implemented is a way to view the flowchart of the data (similar to twine). This is the first thing I need to do if the Kickstarter is successful as it’s a real barrier to efficiently creating more complex content for me right now.

ES: It looks at first glance as though this system is only going to let you send text email, rather than images or HTML formatted stuff. Is that the case? (I myself am not a big fan of having garishly overdone email turn up in my inbox, but I can imagine cases, especially for ARG-likes, where the ability to enclose an image might be important.)

JL: It is the case and I don’t have plans to add support for HTML formatted emails for the final version. The code would support this now but the gui doesn’t provide a way to view and test html content (well, you’d see it as pure text which would be ok for more technical people). There are many open source html editors out there which could be integrated into the client side app so it’s definitely something someone else could do at a later date.

ES: What kinds of provisions do you have for testing? For instance, is there a way for authors to set up standard test scripts to verify that the system is continuing to behave properly? Or are you entirely relying on people to run their own tests by hand? And would they have to do so by sending email to their own system?

JL: There is no automated testing set up at the moment. There software does validate the json data (checks the properties, types, and that nothing points to non-existent messages) but nothing more. Most of my testing is done locally (with a node.js server) so you don’t need any email set up to create and test stories. I also have a debug flag which causes messages to be sent immediately so you can test without waiting in real-time for the story to progress!

ES: Have you played at all with Conducttr? How do its email features compare with what you’re doing, aside from the rather massive author price tag for using it?

JL: I haven’t seen that tool before but it looks like it uses fake email and fake social media apps rather than real email. I have heard of tools such as this being used in recruitment processes but I haven’t seen anything which uses real email. That’s not to say that such tools don’t exist of course.