Brackeys Game Jam 2025.2 · Long-Term Development
A narrative dice roguelike where hand-authored encounters, crew state, faction relationships, and persistent consequences shape each voyage.
I designed the voyage structure, probability model, crew passives, injury and death, Arena modifiers, recruitment, Voyage Log and Focus systems, and the Treasure system currently being added for run-to-run crew customization.
I am the sole writer of the game. I reworked the full encounter library, expanded the three factions into connected arcs, strengthened parallels between recurring characters, and built the story toward a finale that reacts to the voyage that reached it.
I built the GML runtime and JSON-driven content architecture that connect scenario selection, crew state, roll resolution, Arenas, flags, save data, presentation, replay progression, and conditional narrative routing.
Biscuit Bandits began as my first serious attempt at game writing. Jam players praised the story and humor, but the gameplay and moment to moment feel did not give those ideas enough support.
The rankings showed the same split: #8 Audio and #11 Visuals , but #291 Gameplay . I continued development to make the choices more engaging and the results more satisfying without losing what worked in the writing.
The first thing I changed after the jam was the spinner. Giving the roll a stronger animation immediately made the old presentation feel flat, and that small improvement grew into a wider revamp of the interface, feedback, audio, and consequences surrounding every choice.
The development build still uses the original jam art assets. The visual changes visible right now are mostly procedural UI, spinner motion, Arena presentation, and effects that I implemented in code. We are creating new art assets for the public demo, and Dirk is also making expanded versions of the existing music tracks.
In the jam build, the best choice was usually whichever crewmate had the highest number. I wanted the player to think about who they were sending, what that character might change, and how the encounter itself could reshape an otherwise familiar roll.
I approached that from two directions: Crew Passives give each crewmate their own rule, while Arena Modifiers change the rules around the roll. I am also adding Treasure so crew stats can change during a voyage, giving each run more of a build identity instead of locking every crewmate into their starting numbers.
Each crewmate has a unique rule that changes when they are worth sending.
Each success adds one point to every stat, up to three. One failure wipes out the streak and leaves every stat weakened until the Gambler wins again, creating pressure to keep gambling while the streak is alive.
When someone else fails, the Bookworm remembers that stat. The next time she uses it, she gains three points and then forgets only that lesson, turning another character's failure into a resource the player can save.
When another crewmate dies, the Priest enters God Mode. Every stat becomes ten for his next roll, so a death immediately changes the next decision instead of ending as an isolated punishment.
If the injured Drunkard fails a dangerous roll that would kill him, he gets one last reroll. It reinforces his character while making a reckless assignment tempting even when the stakes are highest.
Four of the 10 Passives are shown here.
Arena Modifiers change the information, restrictions, or consequences around a roll without replacing the core system.
The normal stat and odds readout disappear, forcing the player to rely on what they remember about the crew and evaluate the same roster differently.
One representative handles the encounter instead of letting the player swap to the best specialist on every roll, so one assignment affects several decisions.
Failed rolls resolve as successes, while successful rolls resolve as failures, forcing the player to rethink which crewmate gives them the outcome they actually want.
A crewmate rests after being used, so taking the obvious best option now can leave the player weaker on the next check and turn isolated rolls into short-term planning.
Four of the eight supported Arena modifiers are shown here.
External JSON keeps authored content out of gameplay code. One encounter file can carry dialogue, choices, rolls, requirements, outcomes, persistent flags, crew references, Arena state, presentation, and routing.
The GML runtime evaluates that data against the current voyage. Encounter starters also carry tags describing their faction or vibe, such as Turkey, Brigade, Goon, Creepy, Environment, or Neutral. The voyage planner can then balance the story rather than stack similar scenes together.
Use a tightly cropped real encounter file and highlight only the fields that connect writing, gameplay, and presentation.
BBJSONAnnotated.png
Faction relationships survive the run, crew identities stay stable across multi-page scenes, and later encounters can respond to what the player actually did instead of treating every event as isolated. The finale uses that history but is omitted here to avoid spoilers.
I am the sole writer of Biscuit Bandits. After the jam, I rewrote all 45 standard encounters, strengthened recurring faction arcs, and rebuilt the story around a clearer climax.
Because each voyage uses only part of each encounter pool, those authored scenes must work in procedural order. The run planner surfaces unseen content, prevents obvious repetition, and preserves authored payoffs.
Use one encounter you substantially rewrote.
BBNarrativeRewrite.gif / .png
Show the same characters returning later in the voyage.
BBFactionArc.gif / .png
Every encounter carries faction and vibe tags, and the run planner uses them to keep the voyage varied while still serving the story.
Medium and Hard use the planner below. Easy is more authored: its layout is less random and guarantees the player meets the factions the rest of the story expects them to understand.
Encounter weights decide which scenes are most likely to be considered, including unseen-content and Focus weighting.
The planner assembles 64 complete layouts from those candidates, with each plan ordered randomly.
It checks the plans from the top and rewards variety across faction and vibe tags. Any plan scoring above 80 is strong enough to be considered.
From the qualifying plans, the highest-scoring layout becomes the voyage section.
Smaller problems that became important once the project grew.
These are supporting systems rather than separate case studies, but each exists because the expanded game created a specific design or implementation problem.
As the encounter library grew, pure randomness could make replay feel aimless and could hide authored content the player had never seen.
The Voyage Log tracks discovery, outcomes, and Crew Records. Focus lets the player influence future weighting toward something they still want to find without turning the roguelike into a level select.
A new voyage can now have a player-defined goal, while unseen-content weighting still helps the larger library surface naturally.
BBVoyageLogMenu.png
BBVoyageLogEasy.png
Injury or passive state could update as soon as the runtime knew the result, revealing a failure before the spinner finished.
I separated mechanical resolution from visible presentation and queue the state changes that would spoil the landing beat.
The code stays deterministic while the player experiences the intended suspense and result timing.
I wanted encounters to talk about the crew the player actually brought with them instead of using generic stand-ins. But a long scene can span several pages, and crew arrays can change after deaths, recruitment, or a Continue load.
I built conversation tags such as {crew1}, {crew2}, {crew3}, and {random_crew}. When an encounter begins, those tags resolve to stable crew IDs and that mapping is saved with the active voyage, so the same character keeps their role for the whole conversation.
The writing can be more specific without becoming fragile. A scene can call out a real member of this run, carry them through several pages, and still survive party changes or save / resume.
The jam-era schema used fake success/failure wrappers and redundant fields even for simple deterministic dialogue choices.
Current authoring infers rolls from the presence of a stat, lets narrative pages route directly, and supports skip-result question hubs while the parser still understands legacy structures.
I can migrate a large narrative project gradually instead of freezing development for one enormous content rewrite.
out of 2,272 entries
The one-week version placed #28 overall. I kept developing it because the project had more room to grow than the jam allowed: the presentation and writing had landed, but I wanted the gameplay, replay structure, and final narrative payoff to carry the same weight.
Play the original build ↗Biscuit Bandits began as a three-person jam game and has continued as a long-term small-team project. I own the gameplay, systems, implementation, and writing while working with George and Dirk on the visual and audio identity.
Art + Assets
George created the original character and environment art that established the jam version's visual identity. We are now creating additional visual assets for the public demo.
Music + Soundscapes
Dirk created the original music and soundscapes. For the expanded demo he is developing longer, expanded versions of the existing tracks while I handle the in-game audio and presentation implementation.
Lead Design + Programming + Writing
I lead the game design and programming, built the JSON/GML narrative architecture, and am the sole writer of the encounter library, faction arcs, dialogue, and finale. I also integrate the team's art and audio into the game.
The useful part of keeping Biscuit Bandits going has been getting to revisit decisions I made under a one-week deadline. Some of the jam ideas held up, and others did not. I have rewritten scenes, changed the voyage structure, and rebuilt parts of the crew and roll systems when they stopped supporting the game I wanted.
It has also made me realize how much I enjoy the technical side of narrative design: not only writing a scene, but building the rules that let it appear at the right time, remember who is present, and pay off choices later. The demo is still in development, and I expect parts of it to keep changing as I test it.
BBReflection.gif