Part of the final assignment for the ARTS 140 course I took was to write a postmortem of the game. I thought I would upload it as a bonus to anyone who was interested in the process.

My Intentions for the Game 

I came up with the form of the game before I knew what I wanted the content to be. I got into Twine when it was first introduced in the course and immediately saw in it the potential to make a diegetic user interface, as in games such as Emily is Away (Seeley, 2015) and Orwell: Keeping an Eye on You (Osmotic Studios, 2016). I didn’t know what kind of story I wanted to tell, but I knew how I wanted to tell it. 

My first idea for the story, which emerged from my experimentation with creating a diegetic UI, was that the player was accessing the old family computer of a missing friend in an attempt to find out what happened to them. Another person’s PC seemed like both a relatively realistic way to use the diegetic UI idea and something that would write its own story. The next major development to this story idea came when I was talking to a friend about the recent disappearance of a mutual friend of ours, who had gotten a messenger to tell us that our virtual D&D session was called off and went no-contact with us without explanation for a few weeks. Scared for my real-life friend, I ended up thinking about how we had used a remote desktop access application during the height of the pandemic to play couch co-op video games on their computer. I then had an idea: what if I made the player’s own computer diegetic as well, under the premise that they were accessing their friend’s computer through a remote access application? 

The final premise for the story of this game studies project ended up coming from a French project that was in itself based on a sociology project. Back at the beginning of the term, the Waterloo Region Police Service Human Trafficking Unit delivered a special presentation in my sociology class. I’d already learned a lot about local human trafficking from an online short play that my mum had me watch early this year, but I still learned a lot from the presentation. When I was thinking about the game shortly after writing a French paper on sex trafficking, it occurred to me that the premise I had created so far perfectly aligned with one of the most common patterns of how a victim is manipulated into a trafficking situation. I quickly came to the conclusion that this was what I wanted to do with this game: use a diegetic UI to tell the story of someone who is trapped into this common pattern that draws victims into sex trafficking. 

Issues and Roadblocks in Technical Development 

The first big technical challenge I encountered was creating a realistic chat function. I had originally pictured that, like most actual online chat services, all of your previous messages in one conversation would be visible on the same page. I quickly realized, though, that this meant that I would have to create an entirely different path for every possible combination of messages, which was unsustainable. I refused, however, to completely eliminate chat history, as that made me feel in my playtests like my decisions as a player didn’t matter since they had no visible impact on the game. The compromise upon which I ended up settling was to show only the very last message the player had sent, as that provided proof of visible impact for the player without being a nightmare for me as the developer. No longer needing to copy over the last passage to every new passage, I made a template passage off to the side to copy and paste, which sped up the process significantly and reduced the amount of proofreading I had to do. 

One notable choice I made in the technical development of the game involved the collapsing of whitespace. Once I had written a large portion of the game already, I discovered the simple way to collapse multiple invisible lines of code into a single line of whitespace for the player. Initially, my vision was for the input boxes on the chat screens to only be large enough to fit the available options, but before I knew how to collapse whitespace, the chat boxes ended up with large empty spaces where yet-inaccessible options should be. When I learned this skill, however, I decided to leave the empty space as part of my efforts to subtly push the player to dig for more information. The empty lines ended up serving as an indicator to the player that there was more information to find, and all filled lines meant that the player had experienced all the game had to offer up to that point. I ended up being pleased with this mechanism. 

As the project drew to a close, my biggest challenge was that throughout playtesting, the game simply sometimes refused to acknowledge that I’d already accessed a certain passage. I pored through online forums and guides and got a lot of advice, none of which seemed to help. The most significant issue was that I couldn’t identify a consistent pattern of errors, as code that worked fine in some places failed to work in others and I couldn’t figure out what was causing it to behave differently. After I’d finished writing the game and was in the final debugging phase, I eventually studied the variable tracker very closely in playtesting and realized what I definitely should have figured out sooner: when you click Twine’s built-in back button, it reversed whatever you had just done, including setting the variable associated with the information you had just obtained to true. This would likely have been obvious and difficult to forget if I had been writing a story that progressed forward through linear time as was intended, but normalizing its use as a way to navigate a standard computer interface caused me to lose track of what, exactly, it did. At this point, I didn’t have the time or willpower to completely reconfigure the game around built-in navigation buttons, so I added them exclusively where they were needed and added a disclaimer to the introduction: “In order to help the game track your progress, make sure to use the displayed button to navigate the game when available and only use the built-in back button when the page doesn’t have a displayed button”. I recognized that this was not the best way to communicate my point, but I hoped that it would make sense to the player once they encountered a displayed navigation button in the game. If I had had more time and willpower, I would have reconfigured the game to rely exclusively on built-in navigation buttons, as players aren’t supposed to be able to go back on their choices in this game anyway. 

On Length (for context, the project guidelines said the full experience of the game should be about five minutes long)

I struggled with the length of this game across most of the process of its development, but the variety of struggle changed over time. I knew right away that I was going to struggle with communicating a message that didn’t seem forced in a game that was strictly five minutes long. Early on, I had a crisis about how quickly one could progress through my game, but when I got a classmate to play only the introductory conversation with the character Lionel, it took them a solid three minutes. Note that at that point, the player hadn’t even started finding out information about Char’s disappearance. When I got a writer friend outside the class to playtest my finished game, they reported that it took them between ten and fifteen minutes to complete the game, which was more or less what I expected. 

I am including the length of my project as a flaw in the postmortem because explaining flaws to a sufficient degree in the postmortem means that we won’t be marked down for them, but truthfully, I’m unapologetic about the length of my game. I feel that this project is one of the frequent cases where content is more important than form, and I’ve accepted the length of my project as a necessity to create the target experience of critical play using the path I have chosen. 

Closing Thoughts 

I think my biggest regret surrounding the game is how limited it is in terms of player experience. I tried to account for everything a player could think of doing while simultaneously ensure that the shortest possible route would still provide a meaningful experience, which I found difficult because I’m only one person with one perspective. Asking writer friends to come to conclusions based on limited information definitely helped me build for different perspectives, but when I did adjust the game to accommodate for different playstyles, there was always a sense of loss that came with knowing that giving the player freedom to choose how they progressed meant that it was unlikely that they would experience all the game had to offer. 

Despite that, I’m very proud of how the game turned out after all. It’s neither a perfect video game nor a perfect representation of a human trafficking situation, but I think it accomplishes both objectives to a significant extent. I’m proud of myself for being adventurous and going beyond the basics with Twine’s functions, even when it meant sitting at my desk for five hours straight in a fruit juice-fueled coding haze trying to figure out why on earth something simple wasn’t working.

[Edited to fix formatting errors resulting from pasting the text in from Word.]