Post Mortem

When I began working on Last Train Home, I knew I wanted to create a horror-based narrative game using Twine. My first step was the ideation stage, where I thought carefully about the kind of story I wanted to tell. I decided to look inward, reflecting on the media I had been consuming that summer, which was primarily Asian horror stories shared on YouTube. Having recently traveled to Japan, I became especially fascinated by Japanese urban legends, which often combine everyday spaces with unsettling supernatural twists. One story in particular stood out to me: the legend of Kisaragi Station.

The Kisaragi Station story describes a woman boarding a train, only for it to bypass her normal stop. As the train continues, the announcer begins calling out the names of stations she has never heard of. Eventually, she steps off at the mysterious “Kisaragi Station,” which appears abandoned and frozen in time. She meets a strange old man who warns her that she has slipped into another world and that her only chance of survival is to follow the tracks without looking back. She disappears into the night, and the legend claims she was never seen again. The idea of being trapped in a liminal space between the familiar and the unknown resonated with me because of my own experiences at train stations during my trip. I often found that once-busy stations became eerie and almost surreal when they were empty, particularly at night. This legend aligned perfectly with my own sense of unease and gave me a strong foundation for my game.

Once I had chosen my narrative direction, I moved into the writing stage. Since this was a branching narrative game, I needed to think about multiple possible outcomes rather than just a single linear story. I began brainstorming using mind maps, sketching out routes and possible endings. My first draft was simple: players could either make it home safely (a good ending) or become permanently lost (a bad ending). However, I quickly realized this was too shallow for a satisfying narrative game. I wanted more variety, so I added multiple “in-between” endings. For instance, players might find themselves trapped in a time loop, ride a train that never stops, or encounter sinister strangers who may or may not be ghosts. Expanding the story this way gave the game replayability and allowed players to feel that their choices mattered.

Translating these ideas into Twine required me to think structurally. I built my story top-down, beginning with a clear “Start” node and then branching outward. Twine’s map system allowed me to visualize paths easily, but my first version still had many branches that were too short. For example, some choices went from being lost at the station directly to either a good or bad ending without enough development in between. To fix this, I connected branches to one another and added twists and turns. For instance, a player might meet a guard and decide either to trust his directions or to press him for more information. Depending on their persistence, they could uncover additional clues about the mysterious station that shaped later choices. This process deepened the story and ensured that each playthrough felt different.

Of course, as the narrative became more complex, I ran into challenges with the flow of the game. Sometimes passages looped back incorrectly, or paths ended prematurely. Debugging was a large part of my process. I relied heavily on Twine’s “test from here” function to examine the story node by node, and I repeatedly played through the game from the beginning to catch mistakes. As the map became crowded with intersecting boxes, I had to inspect connections manually to make sure everything linked properly. While tedious, this testing process was essential for producing a coherent and functional story.

Alongside writing, I worked on adding visuals to the game. From the start, I wanted images to reinforce the horror atmosphere, but creating original artwork for every scene was unrealistic. Instead, I turned to MidJourney which is an image generation tool that I had never used before. My early attempts to generate images revealed an important limitation, that is,  AI image tools struggle with text. For example, I wanted a departure board that clearly displayed “Last Train: Departure Imminent,” but the tool consistently produced garbled or unreadable text. I quickly learned that focusing on mood-based prompts rather than specific words produced better results. By describing an atmosphere such as “a late-night deserted train station with flickering fluorescent lights, mist rolling across the platform, and a glitching digital board”, I was able to generate visuals that supported the tone of my story.

Once I had a library of suitable images, I faced the challenge of integrating them into Twine. Initially, I tried following Adam Hammond’s guide, which suggested embedding images using links. However, no matter how I formatted the links, the images would not display correctly. At first I thought there was an issue with the code but then, I realized it must be the image hosting site I was using. 

Frustrated, I searched for alternatives and eventually found a tutorial from Twine Adventure that had a similar code to the one Hammond supplied on his site, but I ended up using Postimg for link hosting. At first, I struggled with Postimg’s interface, mistakenly copying the wrong type of link. Eventually, I realized I needed to use the “direct link” provided after upload. Once I implemented this properly, my images finally appeared in the game. This breakthrough was incredibly rewarding, as it marked the point where my narrative text and atmospheric visuals came together.

After the core gameplay and visuals were in place, I moved on to finishing touches. I proofread all passages for grammar and clarity, ensuring consistency throughout the branching paths. I also created an introductory start screen with a short bio to give context before the story began. Previously, the game dropped players immediately into the opening scene, which felt abrupt. These adjustments helped polish the overall presentation.

Reflecting on the project, I believe the strongest elements of Last Train Home were its atmosphere and the way player curiosity was rewarded. Instead of overwhelming the player with long descriptive passages, I relied on small details: a guard’s outdated railway patch, a stranger’s 1957 ticket, or a timetable showing unfamiliar stations to create unease. These subtle touches proved more effective than explicit explanations. I also designed the story so that careful or inquisitive choices, like pressing the guard for information, often revealed deeper layers of the mystery. This gave players a sense of agency and made the game more engaging.

The most difficult aspects of the project were managing the branching flow and handling image integration. Debugging complex paths in Twine required patience, and even minor errors could throw off the narrative structure. Embedding images also took far longer than expected, and I only succeeded after experimenting with multiple hosting platforms. Another challenge was finding the right balance between ambiguity and closure in the endings. I wanted players to feel unsettled, but I also worried that leaving too much unresolved might frustrate them.

Overall, Last Train Home taught me that building an interactive narrative requires a combination of storytelling, structural design, and technical problem-solving. If I were to expand the project in the future, I would experiment with and integrate audio and different font styling to heighten the eerie mood.