Biscuit Bandits - Narrative Systems and Data-Driven Design
- harrisonalonso9
- May 26
- 7 min read
Updated: 21 hours ago
Branching Narrative Roguelike | GameMaker Studio 2 | One Week Game Jam Project
Programming, Narrative Systems Design, and Writing: Harrison Alonso
Art and Assets: George Boutwell
Music and Soundscapes: Dirk Dammit
Project Snapshot
Role: Main programmer, narrative systems designer, writer
Team: 3 people
Engine: GameMaker Studio 2 / GML
Data: JSON-based scenario structure
Timeline: 1 week
Result: 28th overall out of 2,272 Brackeys Game Jam entries
Focus: Branching narrative, stat-based probability, crew management, replayable encountersOverview and Results
Biscuit Bandits is a choice-driven narrative roguelike created in one week for Brackeys Game Jam 2025.2, based on the theme “Risk It for a Biscuit.” The game takes place in a world swallowed by an endless ocean of gravy, where the player assembles a crew and sails toward the last remaining landmass: the Great Biscuit Island.
As the main programmer and narrative systems designer on a three-person team, I built the systems connecting branching encounters, crew management, stat-based probability, recruitment, progression, and presentation. I also wrote the game’s scenarios, characters, factions, and ending, with the narrative content organized through external JSON data.
The game was published on September 2, 2025, and placed 28th overall out of 2,272 entries.
My Role and Contributions
Designed and implemented the branching encounter system
Built the crew management, recruitment, and stat-based probability systems
Structured narrative scenarios through JSON for flexible branching and progression
Wrote the encounters, factions, characters, dialogue, and ending
Connected scenarios to portraits, environmental visuals, music, and ambiance
Resolved a major exported build issue affecting access to the ending sequence
Provided voice acting for the game’s crew members
Core Design Idea
From the beginning, I wanted Biscuit Bandits to feel like more than a sequence of funny choices. Its world is intentionally ridiculous—filled with gravy storms, pirate factions, hostile creatures, and characters obsessed with reaching the Great Biscuit Island—but the player’s decisions can still permanently affect the crew.
The central mechanic asks the player to choose both how to approach an encounter and which crew member must attempt it. Each character has different strengths across five statistics, allowing the player to fight, negotiate, steal, plan, or endure depending on the situation.
This made strategy personal. Even the statistically strongest choice could place a specific character in danger, connecting the probability system to the player’s attachment to the crew.
Systems Design
The crew system was built around five readable stats:
Strength: physical action and combat
Intelligence: planning and problem-solving
Grit: bravery and endurance
Charm: persuasion and social situations
Thievery: deception, sabotage, and opportunistic solutions
Each stat served both a gameplay and a narrative purpose. When writing an encounter, the available stat options helped define different ways the player could respond to the same situation.
I created a probability system in which stronger crew members improve the chance of success, but no choice is completely safe:
Success Chance = clamp(50% + 10% × (Crew Stat − Difficulty), 5%, 95%)
When a crew stat matches an action’s difficulty, the chance of success is 50%. Every point above or below that difficulty changes the chance by 10%, while the 5% to 95% limit ensures that even a strong option can fail, and even a desperate choice has a small chance to succeed.
I wanted players to understand why a decision was strategically strong without making risk disappear. Because crew members can be permanently lost, failure affects both the player’s emotional investment and the player's available strategies later in the run.
The game also uses controlled replayability. Runs draw from a collection of encounters, allowing different voyages to produce different recruits, losses, and situations. However, major story moments retain their authored pacing, so each run still builds toward a deliberate ending.
Technical Implementation
I built the narrative framework in GameMaker Studio 2 using GML, with scenario content stored externally in JSON. Rather than hardcoding each branch directly into individual objects, I designed a data-driven structure where scenarios could define their own text, choices, stat requirements, difficulty values, visual settings, and success or failure routes.
This allowed narrative content to be written and revised separately from the central game logic. New encounters could be added through structured scenario data, while reusable systems handled presentation, crew selection, probability checks, consequences, recruitment, and progression.
The scenario controller handled:
Loading and displaying encounter data
Tracking the active crew and current run
Presenting branching choices through the journal interface
Allowing the player to assign a crew member to an action
Resolving success and failure through stat-based checks
Applying consequences such as crew loss or recruitment
Routing the player into authored or randomized scenarios
The game’s primary interface was built around a journal where the player reads and responds to encounters while the boat and crew remain visible in the world behind it. Connecting the interface to character portraits, environments, music, and ambiance helped each event feel like part of an unfolding voyage rather than an isolated text prompt.
Narrative Design
The tone of Biscuit Bandits balances comedy with consequences. The Gravy Ocean is intentionally absurd, but its characters and factions treat the world seriously. Encounters introduce groups such as the royalist Biscuit Brigade, the treasure-obsessed Gravy Goons, and a turkey-bone cult whose beliefs gradually foreshadow the game’s ending.
I wrote scenarios as branching encounters rather than isolated jokes. Each encounter presents a problem, offers several approaches, and produces different outcomes based on the chosen action, the assigned crew member, and their chance of success. Some encounters focus on survival, while others develop the world, introduce factions, or allow the player to recruit new crew members.
A major design goal was making failure feel personal and understandable. Earlier ideas involved more general or randomized crew loss, but those consequences felt arbitrary. In the final system, the crew member selected for an action is the person placed at risk. This made failure harsher, but also fairer: the player knows exactly whom they are trusting when they make a dangerous decision.
Iteration, Limitations, and Lessons Learned
Developing Biscuit Bandits taught me that procedural narrative still requires authored structure. Random encounters helped different runs produce varied recruits, losses, and situations, but introductions, major reveals, recruitment moments, and the ending needed deliberate pacing. The scenario system allowed me to combine replayability with a controlled emotional arc.
The one-week timeline also forced tradeoffs between technical reliability and final balancing. Resolving the scenario-routing issue required time that I had intended to spend refining the starting crew.
With additional development time, my highest priority would be adding a third starting crewmate. With only two initial options, certain early encounters could depend too heavily on the available stat coverage. A third character would create stronger early decisions and allow the probability system to reward planning and crew composition more consistently.
Technical Challenge: Scenario Data Validation and Build Reliability
One of the largest technical challenges in Biscuit Bandits came from managing the game’s growing scenario data. JSON files defined branching encounters, dialogue, stat checks, outcomes, routing, recruitment, and the ending. Because the project was built in one week, I developed a rapid workflow for converting rough scene notes into the required data structure. I revised the writing, mechanics, identifiers, transitions, and final implementation before integrating each scenario.
As the scenario collection expanded, small formatting and routing errors became increasingly difficult to track. Dialogue sometimes contained unescaped quotation marks, identifiers could become inconsistent, and references could appear correct while leaving scenes unreachable. Near the end of development, these problems prevented the exported build from reliably locating the final ending sequence.
I responded by breaking scenario implementation into smaller tasks, manually validating JSON syntax, checking identifiers and transitions, and testing route accessibility before integration. I also moved toward indexing scenarios by ID during initialization, reducing the chance that an invalid reference would make important content unreachable.
The experience taught me that rapid content production must be supported by clear structural constraints, validation, and systematic testing. Fast iteration only remained valuable when every scenario was treated as production data and verified before integration.
The Ending
Throughout the game, the player receives hints that Biscuit Island may not simply be a safe destination. The turkey-bone cult and other pieces of worldbuilding initially appear to extend the game’s absurd humor, but gradually point toward something larger beneath the setting. The final concept was partly inspired by Andy Weir’s The Egg and its idea that seemingly separate lives may belong to one connected existence.
For most of the voyage, the player is taught to treat crew members as distinct individuals. Each character has different abilities, each recruit changes the available strategies, and every dangerous assignment asks the player to decide whose life should be placed at risk. When someone dies, the loss feels specific because the player knowingly made that decision.
Reaching Biscuit Island reveals that the crew members, the people encountered across the ocean, and the repeated voyages are connected within a larger cycle. What begins as a ridiculous adventure about risking lives for a giant biscuit becomes a story about how the player values individual lives and what it means to discover that those lives were never as separate as they appeared.
The reveal is supported by the game’s systems rather than only its final dialogue. Recruitment creates attachment, statistics encourage the player to evaluate each person individually, permanent loss creates responsibility, and repeated voyages make the cycle part of the player’s own experience.
Reflection
Biscuit Bandits confirmed that narrative design is strongest when story and mechanics are constructed around the same central idea. Its branching writing gained tension from crew statistics and probability, while recruitment and permanent loss made each decision feel connected to a specific character rather than an abstract resource.
This project represents the kind of work I want to continue pursuing: building narrative systems in which mechanics do not simply deliver a story, but actively shape how the player understands and feels it.
