Postmortem

As a narrative designer, this project was a blast. Was it as long as I wanted? Hell no. I probably need to change the title from “Eighteen Hours” to “Roughly Thirty Minutes”. But being able to refine my process and work on all aspects of a game made for a really fulfilling time. My main goal is design with intention, and I think I did a good job with that. 

My process more or less is like making spaghetti– throw it at the wall and see what sticks– except you’re throwing the whole pot instead of a noodle or two. Iterate quickly, come up with as many concepts as you can, and Frankenstein things together until they start working. You can definitely see that in every WIP document I made for this project. My music program has random sounds, chord progressions, and melodies that I thought were interesting. The character design sheets not only have one billion different versions of character outfits or palettes, but also have a bunch of hidden layers where I made dozens of tiny tweaks. And finally, my Google Doc for this project is 90% bullet points written in cave-man speak, where every wayward thought I had that was even slightly related to the project was housed. It’s a mess, but a fun mess. 

While the end quantity of the game is definitely the biggest “failure” of my end product, I really am proud of the “slice” I made for Eighteen Hours, slim as it may be. There were so many things I had never done before this project, and I learned how to do them! Writing music was awful and painful but I think my final tracks are interesting. Art was awful and painful, but I made some cool backgrounds, animation, and character designs. Coding was awful and— you see where I’m going with this. 

I focused on a single aspect of the project at a time, which I definitely will not do in the future. It was all too easy to spend too much time on one thing, like music, leaving less time for the other things that needed to be implemented (art, writing, coding). But this “mistake” in my workflow still offered learning experience in how game development works and let me hone in on these different skills, which allowed me to develop them a little more. Yes, the process was flawed, but I’m still happy to have the experience. 

To speak on specific questions–

When I mentioned how “writing takes time”, I more-or-less am referencing my own writing process which can be… inconsistent, especially when it comes to game writing. I’m a creative writing minor and have been writing more or less for my entire life, but to me there’s a difference between typical prose and writing a narrative based game. Specifically, when the expectation is for prototypes to be playtested consistently and my game hinges on its writing for gameplay, I want that prose to be as good as possible for whatever piece of the game I am testing. When I am writing short stories and essays, I tend to try to write as much as possible, then refine it. However, my process for Eighteen Hours had me laboring on short sections for long periods of time, to have cohesive, testable fragments of the game. This was where I was getting “stalled”. I would be interested in learning how people who write for narrative heavy games alter their writing workflow to accommodate playtesting and the like, since that was a definite hitch for me. 

Twine was overall the best engine for my project, but yes, at times it felt like I was working against the program, rather than with it. Audio was something I had a lot of trouble with. In my final game, I ended up having only one “switch” in music, but I had another location (and another track) that wasn’t finished for the end of this class (and thus was cut). However, I dedicated a lot of time trying to get audio to smoothly transition between my various tracks, which was made more difficult because the player was supposed to be able to move between them fairly freely. It was just… awkward. I’m not sure what engine I would use in the future, especially for a text based game. Maybe I just needed to set my sights lower when working in Twine. A disappointing conclusion to come to, but the audio engine in Twine simply is not it. 

As for tips to keep storytelling and tone consistent / cohesive… Similar to how we were told to come up with verbs for our gameplay loop, I would suggest writers come up with adjectives for their tone. Dark, bubbly, dry, whimsical. Understanding the core tone you want to maintain is really important, and boiling it down to a word or two can be helpful in discovering that. I also want to make sure my writing sounds good, so I will always recommend people read their writing aloud. Hell, I’ve been muttering every word of this reflection to myself as I write it. Reading your writing out loud not only can help you see if you are maintaining a consistent voice, but also forces you to read things back, thus allowing you to notice if there are inconsistencies in your story. At the cost of looking a little silly (if you do it in public), reading things out loud consistently is a very helpful tool. 

What is it that Truman says? In case this page is never updated again, good morning, good afternoon, and good night, dear dev log readers.