Way Out

Way Out is a branching dialogue visual novel that was made over the course of 3 days as a submission to inkJam 2020, a narrative game jam that highlights the Ink narrative scripting tool. 

It explores a dystopian future in which working-class people are offered to participate in an unethical study for a chance to escape poverty (historians will surely look back and see that Way Out paved the way for modern contemporaries like Squid Game).

My Role:

I was the writer, narrative designer, and systems designer on Way Out. In a period of 3 days I worldbuilt and wrote over 3,000 lines of dialogue for the project. Keep in mind that due to the rushed development cycle, the game has a ragtag sense of unrefinement about it (Don't tell anyone, but I even found a typo).

Hard Lessons Learned:

Way Out was my first branching dialogue game, and during its short development period I learned a ton of useful lessons on narrative design:

  • You Don't Need to Write in a Straight Line: I spent half of my time writing the tutorial section, and half of my time writing the game that came after it. The lesson here could be "Be Better at Time Management," but there's more to it than that. 
    I came to the realization that I had been writing like a reader - I started at the beginning, and went in a straight line from there. There is no reason to confine myself in that way. In the future, I'm going to prioritize the most important content to make sure it gets the attention it needs - a game with a rushed tutorial but a fleshed-out main quest is probably going to be better than the inverse. 

  • Don't Bury the Treasure: Branching narrative is rife with temptation as a writer. I'd need more than 2 hands to count the number of times I thought, "Oh! Here's an opportunity for a unique interaction! If the player chose this specific combination of things..."
    This is due partly to the extremely short development time, but I spent a huge, valuable chunk of time writing stuff that only a tiny percentage of the playerbase would ever see. In my opinion, some of my best writing is hidden behind these obscure choice combinations, and that makes me a little sad. Don't get me wrong, these moments of specificity can make interactive narrative games feel truly special. If they're most of the writing, though, the meat of the story can feel empty. 

bepedantic.JPG

This "Be Pedantic" dialogue option is only available to players who make an obscure combination of 2 choices earlier in the game, and it leads to some of my favorite writing.

  • You're Using Too Many Variables: Intrinsically linked to my previous point, problems arise when there are too many unique variables that lead to different narrative branches. The core choice system of Way Out is based on the player choosing up to 4 from among 9 different tools to take with them on their adventure. Each of those tools is a different variable that leads to different world interactions. 
    I should not have written a story for a game jam that accounts for 9 different variables and their combinations, full stop. 

    Sure, it's possible to do the bare minimum here: <HasApple> You have an apple! (repeat for all your variables). Come on, though. I think often about how much cleaner, tighter, and more satisfying this story could have been had it been, say, a choice of 2 out of 3 variables instead. Hell, there's a choice at the beginning that determines whether a supporting character is your friend, lover, or family member. That could have fueled an entire game!

    Regrettably, there is absolutely a cluster of choices in Way Out that leads to a better story, because I just didn't have the time to flesh everything out. Some of the variables in the game are almost as egregiously bad as my apple example above (hello, bicycle). 
    Cutting content is a beautiful thing if done right, and like many a junior dev before me, I have fallen prey to overscoping. Maybe I wouldn't have made this mistake if I had internalized our lesson on combinations and permutations in statistics class...

var.JPG
  • UX Isn't a Stretch Goal: ​There's a moment in Way Out where the player makes most of the choices that will determine the outcome of the story, and it's about halfway through the game. As I was writing, I had the thought "we should probably include a way for players to skip instantly to this point so that they can replay the game with different choices more easily." I brought it up with the programmer, and we agreed that it would be a cool "stretch goal," but that it was not essential.
    Of the 6 comments on Way Out's inkJam page, 2 of them are suggesting this feature (I know, we're pulling some impressive numbers). 

comment1.JPG
comment2.JPG

This issue is somewhat specific to the nature of a game jam, as there isn't the room for testing and iteration that would normally exist as part of a game's development process. That being said, even if Way Out followed a traditional development cycle, there is no reason for this problem to exist. I identified a problem during development, and we pushed it to the backburner because it didn't meet our definitions of minimum viable product at the time. We pushed it back not because of how important it was, but because of what kind of problem it was. Specifically, quality-of-life. I can firmly say now that including this feature would have been way more worth the development hours than almost any other feature we implemented. User experience is absolutely as much of the core game experience as any other design discipline, and to push away a known issue just so it can be "re-discovered" in playtesting is a waste of everyone's time. 

Conclusion:

If I were to have a final lesson, it would be something painfully corny like "Keep Making Games!"
​From my experience, game development is like running a marathon, but you start out not knowing how to take a normal step - all you can do is repeatedly faceplant directly into the track. Each project you work on, you learn how to turn some of those faceplants into normal steps.

​Anyway, I'm off to try and make it over the finish line one more time.