Gatekeeping Branching Narratives with a Voiceless Protagonist

This is the first time I've put this much work into interactive narrative design. I'm using a program called yWriter to organize and write the branching scenes, mainly because I was looking for an alternative to Scrivener, which I can't afford at the moment. Both applications function similarly, allowing you to structure your written content  they way you would in an IDE like Visual Studio. You can break the story into scenes, chapters, and resources, defining characters and information per section while editing the content on an instance basis. This modular approach is incredibly useful for organizing and iterating on narrative elements, which are central to this game.

In Godot, I've created several global and instanced objects to handle narrative data: a dialogue manager, a narration manager, and a clue manager for signs and ambient, repeatable information related to location or context-specific gameplay. These utilities manage all text-based information players can access. My goal is to integrate everything dietetically into the laptop function as development progresses, enhancing immersion. Right now, these managers and their dependencies work well together, but as I begin sequencing more complex narrative trees, managing the player's laptop entries may become more challenging.

Every narrative element is gated by specific strings of characters that the player must include in their laptop entries to progress the story and trigger global events. The managers use a Levenshtein distance function to check if the player has entered a key word or an approximation of one in their notebook. If a match is found, the corresponding interaction is triggered, affecting everything from progressing dialogue to opening doors or hacking vending machines. As the story expands, conflicts between entries and string combinations may arise. To address this, I might implement a daily log system that resets certain stored text information while marking some words as permanent, ensuring players only need to re-enter conflicting commands per story segment.

Early on, I tried to simplify the dialogue system out of concern that coordinating too many elements feeding into the laptop’s note-taking functionality would be difficult. However, this decision introduced unnecessary complexity and inefficiencies in other areas of the code. Moving forward, my priority will be refactoring the laptop UI to store multiple arrays across different pages—more like an actual desktop interface. This would allow players to better track and manage progression conditions rather than checking everything against a single notebook entry array.

On a side note, I've implemented a simple library of commands for the laptop that players can use to modify object variables, provided they know the specific object ID. I'm not sure how much I'll expand this system, but it could be an interesting avenue for puzzle mechanics. The available commands are:

• start
• change
• update
• log
• printvar
• coordinate
• generate
• stop

Players use start to queue the laptop for running a script, enter commands line by line, and finish with stop to execute the sequence. Currently, most in-game objects don’t have assigned IDs, so these commands only work with NPCs and a few other characters. However, printvar lets players see all available variables for modification on any given object.

Since text-based data is the sole form of progression in this game, visual, auditory, and interface design are crucial to retaining player engagement. This is one reason I chose Godot and a 2D art style. Working with pixel art allows me to rapidly prototype and iterate, helping refine the user experience and make confident design decisions before fully developing encounters. The faster I work, the more I can preserve the sense of exploration I want players to feel.

The story itself is highly fragmented. I want to maintain the power of a voiceless protagonist while subtly guiding players into a pre-established history. Players should feel inspired to define themselves through conversations and the unfolding world around them while still being encouraged to engage with and invest in the narrative. The laptop mechanic plays a huge role in this—it forces players to actively decide what information or responses to present, making choices feel impactful regardless of how much I define the protagonist. For now, I'm narrating the story in first-person, though that may change as I continue designing props and characters for each environment.

Ultimately, I hope this system of data-driven progression can sustain player interest across various narrative branches. I’m satisfied with the groundwork, but the next step is refining how player data is cataloged. Currently, most dialogue and narrative interactions are single-use, and players cannot modify or recall specific entries, leading to unintended ambiguity as they navigate the world. To address this, I plan to add a series of tabs to the laptop interface, allowing players to review past interactions. Additionally, indexing each notebook entry in the UI would enable players to modify individual lines, helping them fix strings or consolidate data when needed.

I plan to keep these entries here on Itch and Kofi predominantly as a record of conception for my self but also to share insight into crucial design decisions as the project evolves.