>> Dancing With Players

A draw to being a puppetmaster and running an ARG is the level of mystery and uncertainty about what could happen next when interacting with players. Some players may simply enjoy testing the expanse of knowledge by asking questions, feeling out how natural and feasible the dialogue and the ambient storyworld feels. Some players may even make efforts to thwart plans, taking the story and characters in directions the actors or writers hadn’t even conceived. As puppetmasters weaving the story through player interaction, we need to strive to be prepared to deal with anything relevant, and often ready to decide on a whim how to respond to their actions, like an unscripted dance. This challenge can produce some very entertaining results.

When players let loose

As mentioned previously, forcing players to generate content to move forward isn’t necessarily conducive to a positive gameplay experience – there may be a reduced acceptance of the task or a more critical player sentiment. So it was of great encouragement to us when seeing that some had chosen to be creative without prompting, in efforts to help solve puzzles or depict elements of the story.

For one of our puzzles, a diagram of a separated wooden block puzzle was provided, but with a twist of course. It had to be reassembled in such a way to read its faces and produce the solution. We didn’t expect this challenge to be tackled by a player building the pieces from the puzzle diagram out of styrofoam blocks. That was awesome to see from Nyst.

Another inspiring and simple creation was submitted by Dreamerblue, who created a short video message, donning a pig nose and playing hide and seek in her living room.

To contrast that style of constructive creativity, however, some players take up a darker role, that of the hacker, or a kicker of the hornets’ nest. Always be prepared for the few players who will attempt to swim against the current and challenge a plan’s execution. Whether it be by trying to brute force or reverse engineer puzzles or programming, or dealing with sensitive information in unexpected ways (such as sharing top secret documents with villains, or revealing secrets held between characters, or even betraying protagonists and heroes).

How should a PM respond in situations like that? A character could pretend to ignore information they’re told that goes against the PM’s plans, but the players still believe that the character has been made known of the news, so the character’s resulting inaction might not make sense; ignoring player interaction dares to break the illusion of the 4th wall. The only feasible response is to deal with the communication in a manner consistent to the character. This is one of the most exciting, and hair-pulling aspects of executing an ARG, but which ends up creating memorable moments.

Surprise backstab!

At one point around the middle of our timeline, we had to deal with a twist where our “Eridanos” character was called out as a threat to Sys.

From the beginning of the project, we’d created but sidelined another character. He remained fairly quiet and unseen, someone we’d actually intended to depict as a Halo fan who was helping to track and blog all the events as they occurred with @intimation; a fallback strategy. Erik was an obsessed fan of the Intimation story, adopting the handle “Essyfan” to show his support for the AI Sacagawea in the Lewis & Clark story arc, her extension taking the form of the child AI here. He posted blog updates giving the appearance of an ARG player, but we made sure he would never break the 4th wall, nor would he post at the Unfiction forums and breach the forum’s terms of use. For this reason he went relatively unnoticed save a few twitter exchanges that he had with Sys. He was only noticed by others on the rare occasion that Sys mentioned @Essyfan in a public tweet.

Essyfan was not being used in the early story to his potential and quickly fell to the wayside, as did his blog. But when we let Eridanos (whose real name remained anonymous) become vilified by the players, we had Erik resurface and join in, following the community’s lead – but he took it to the extreme. He began threatening Eridanos, even publicly implying that he was stalking him. At first, he seemed like a very disturbed player to some of the community. But when Eridanos admitted to discovering that he was “actually” being stalked by Essyfan, it suddenly clicked! The community realized that Essyfan was another in-game character who’d been ‘playing’ along with the community the whole time.

This was one of our riskiest game mechanic decisions. Erik’s existence could potentially be interpreted as sock puppetry, a purposeful deception of players by pretending to be one of them. We were fortunate this worked in our favour, because from the very beginning we’d design the narrative itself to imply that the Halo video games (as video games) and previous ARG iterations (events in our era) actually existed narratively within the Halo storyworld, and so characters could know of the video games’ existence, and may even be fans of the games, while still remaining entirely in-character within the story. But this plot structure admittedly wasn’t very obvious or clear.

No ill deception was ever intended with Erik’s character, and his presence was always kept in a neutral state where nothing would imply a breaking of the 4th wall. We had him believe the science-fiction events of the prologue as if they were all real events – but blended in in such a way as to mingle with the ways a player might ‘pretend’ the ARG was not fictional. At points because of this context, in-game and out-of-game got muddled. Ultimately however, any concerns were overshadowed by sentiments such as this from Dreamerblue: “very clever! my brain is totally exploding from this revelation that we have been led along all this time.”

Erik eventually took the heat off of Eridanos and became an antagonist himself, his own arc growing more prominent and combative (being protective of Essy to an obsessive degree), and allowing room for Eridanos to try to redeem himself, to regain the trust of the community and work closer with them towards the end of the story.

None of this would have happened had Eridanos not been labeled by players as a threat to Sys.

Nonetheless, Erik’s own place in the prologue was shaky and another example of last-minute planning that, if prepared ahead of time and truly fleshed out, would have made more sense and been more cohesive in the story and game. For the long run, however, Erik’s story has evolved… and has not yet concluded.

Let’s get technical

Other memorable moments occur on a greater technical level, with some players trying to grasp the concept of how puzzles or the web interfaces work programmatically. This sort of player/puppetmaster relationship takes on an interesting hacker vs sysadmin dynamic when players begin trying to peek at functionality – from viewing a web-page’s source code, to decompiling shockwave flash elements, to reverse engineering deeper website functionality, or even attempting to straight-up brute force username logins and passwords. Contingencies should be considered for situations like this, since it can take players out of the experience – for example, finding out that a login prompt placeholder on a (fictional) corporate website actually does absolutely nothing; or discovering pre-developed story content before its intended revelation.

To what degree do you reward player curiosity and cunning without breaking the story or their experience, yet still provide an entertaining element that can make sense in-game?
The most significant plot element which we used as a gameplay asset of ours epitomized this dilemma.


Our little AI bot Sys was a busy little bee. Its mission was to contain and ‘stonewall’ the faulty AI within a virtual construct to the best of its ability, both to protect the AI, as well as the environment it was inhabiting. This became home to the “navpath” maze – a complex map of traversible nodes connected by navigational pathways, set up by Sys in a web reflective of its spider-like heritage. The intention here was for players to navigate and explore this network depicted as being stretched over the stonewall surface, seeking out Sys’s hidden and archived story content.

It was designed with an ajax-based web interface on the front end, but as weeks progressed the maze grew more and more complex. It was absolutely amazing to watch the evolution of the players’ attempts to map and understand the confusing, interwoven environment.

A dance with hackers

The difficulty with a simple HTTP-based ajax request system is that without any form of unique and persistent user authorization process or encryption, HTTP requests can easily spoofed. And this interface had no login or authentication system. Our ‘dance’ began when the player Anaerin dove in to hack away at the browser code. He created an automated scripting system that would spoof navpath HTTP requests independently of the interface, and very quickly navigate and map every possible route from every accessible node – instead of mapping the node connections. He set it to traverse the entire node network in every possible way. Anaerin’s script as it stood ran unthrottled and would run hours upon hours each week constantly making requests to find all the hidden content.

In an effort to remedy this technical loophole, we regularly introduced new types of hidden content and different ways to retrieve them that would make it harder for such a script to provide useful information – but without actually disabling or immobilizing his handy work.

Our hope was that with these incremental adjustments he would notice that the script was doing a lot more work than necessary to explore the maze while producing few results. We hoped that setting out additional content and hinting at the actual structure of the maze would serve as a nudge in the proper direction.

The network itself was simply a collection of nodes and vectors, each identifying a starting point and a direction. Anaerin’s script was mapping every possible combination of nodes and vectors reaching out from the starting point, through each connecting node. With combinations of connecting vectors of theoretically any length, it even occasionally got caught in endless loops.

While he continued to improve his script, we also implemented certain elements that could only be ‘found’ by traversing specific paths and nodes in series. The user had to begin a route at a specific node and follow a precise sequence of vectors to unlock the content at the final node. Simply visiting that final node by any other route would reveal nothing. This posed a technical hurdle for Anaerin’s brute force script, since with each update of ours he’d have to restart the mapping from scratch. Each adjustment he made to compensate for our tweaks continued to make it more complex – not adjustments in the direction we’d hoped.

It was a constant programmatic exchange with Anaerin, and the network structure continued to evolve. Thankfully in time, the players began to see a pattern, and a simpler visualization of the network took shape; attempts to depict and map the chaotic interwoven nodes began appearing, and these were much closer to its actual structure.

The blueprint

The node network was, in a sense, a puzzle in itself. As a fan of exploration and discovery, my goal was to provide an environment in which a person could travel around and locate hidden items by a coordinate-style system, similar to geocaching, or a location-based scavenger hunt.

The node network concept was a very simplified collection of routes over a surface, containing nodes spread over a 26×26 grid with each path to another node given a unique identifier, a GPS-like coordinate. Each node was identified by its grid location (XY), with any number of exit vectors labeled by an arbitrary code (AB). This made adding nodes to the grid, labeling pathways, and creating and managing “navpath” strings extremely simple, while providing a relatively simplistic navigational front-end.

The interface was reminiscent of a classic text-based adventure game that asks: “You’re standing in an open field. Which direction do you want to go? [N/S/E/W]” or any number of other movement commands. If you were to map out the layout of a field of connected locations in this manner, you could locate a specific sequence of turns by simply looking at the map. Our ‘navpath’ strings were a sequence of vectors. Using a map of nodes and each of their labeled exit vectors, one could locate the start and end nodes by locating the vector letter pairs where the sequence fit, like a word search.

For example, instead of providing a node ID for a location (such as “XY”), a unique navpath could be provided that would indicate the node location (such as “ABEFHI”). One would need to locate the node with an AB vector that leads to a node with an EF vector leading finally to the node with an HI vector – these three steps would end at the only possible destination node intended. It also meant that hidden content could be tied to a specific navpath, rather than a node. Depending on how you ‘arrived’, you might unlock different content.

This was a game setup that was in itself complex in structure on the back end, but heavily obfuscated on the front end. The structure and programming wasn’t important to the goals of the game or story, but on a higher level it also serves to provide a more challenging attraction that could capture the attention of people who are more curious and prone to reverse engineering things, a common ARG player tactic. For us, rather than being unprepared for the onslaught of community hackers or decompilers trying to circumvent our plans, we were prepared to confront such players and attempted to provide a dynamic response in a mystery they would enjoy tackling, and one which itself wouldn’t be paramount to, or required for furthering the story. It was a strategy intended to give the more technical players a challenge without breaking them out of the story.

In the end, we provided as an easter egg a snapshot of the network’s state as it stood one week, showing the actual simplicity of the network grid.

Additionally, the entire network was a simple grid map managed and organized in Microsoft Excel.

The consistent work done by the community in an effort to understand and pick apart the network’s underlying structure was outstanding.

PHP: Learning by immersion

For myself, this project was a very unique and challenging web-based system to create. I had set up to be as lightweight as possible, running on Linux with PHP. Prior to Intimation, I’d only dabbled in PHP code briefly on occasion, primarily in making minor adjustments to packages such as WordPress and Mediawiki. As the project grew more complex and the interaction, puzzles, and content had to be delivered in ever-creative ways, I ended up having to learn some far more complex PHP coding methodologies and syntax – especially for the stonewall network.

The website and all its dynamic content was created without the use of a server database, no SQL – the data was managed entirely through obfuscated data files and text-based storage. This was primarily for ease of access, for viewing and on-the-fly editing, but there was also simply not time enough to implement and migrate its content to a database on another server and deal with connections. Everything from tracking traffic statistics to reference lists and puzzle data were all dynamically coded and maintained in as minimally and quickly coded PHP as possible. It was definitely not the prettiest to look at, but it got the job done.

The drawback to quick and simple access to all the data, obfuscated (and not restricted) within the hosting space,  is that it still leaves room for basic human error. There were a few moments where links or references to pages were visible that were not intended to be public. That sort of oversight is never fun. And when the system is based on heavily hard-coded material, it’s just as much of a pain to locate and fix the mistake and adapt.

Nevertheless, for ease and speed of coding and organization, PHP ended up being a close friend and companion for a very long time. It was a language sufficient for us to accomplish all for which it was used, and ultimately the project weighed in at over a hefty 17000 lines of code – which isn’t including all the additional data files and content.