Brackeys Game Jam 2025.2 · Risk It for the Biscuit
A narrative dice roguelike where who you recruit, who you risk, and what you choose can change the rest of the 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.
Long-Term Development
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.
Jam → Demo
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.
Meaningful Decisions
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.
Crew Passives
Each crewmate has a unique rule that changes when they are worth sending.
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.
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.
The current demo includes 10 crew Passives.
Arena Modifiers
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.
The Arena framework currently supports eight modifiers.
JSON Narrative Architecture
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.
{
"id": "hungry_shore_choice",
"title": "The Hungry Shore",
"area": "sailing",
"tags": ["environment", "neutral"],
"intro": "The crew are already lowering a rope.
They want that biscuit badly.",
"choices": [
{
"text": "Convince everyone to leave it alone",
"stat": "charm",
"difficulty": 4,
"success": {
"unlock_voyage_outcome":
"Left the Biscuit Alone",
"nextScenario": ""
},
"failure": {
"nextScenario": "shore_close"
}
}
]
}One authored choice connects dialogue, a crew stat, difficulty, a persistent voyage outcome, and the next branch.
One file can drive
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.
Narrative Roguelike
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.
Run Composition
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.
As the project grew, replay progression, result timing, dialogue references, and save migration each created their own design and implementation problems.
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.
Players can chase a specific discovery or outcome in the Voyage Log, while encounters they have never seen are still more likely to appear.
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 result is already decided, but nothing visible gives it away before the spinner lands.
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.
The one-week version placed #28 overall. Players liked the presentation and writing, but the choices and replay structure were much weaker. I kept developing the game to bring those parts up to the same standard.
Play the original build ↗Biscuit Bandits began as a three-person jam game and has continued as a long-term small-team project. I handle the gameplay, systems, programming, and writing while George creates the art and Dirk creates the music.
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.
Keeping Biscuit Bandits going has let me revisit decisions I made in one week and find out which ones actually hold up. Some of the jam ideas did, 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.
The project also made me realize that I enjoy building narrative systems as much as writing scenes. I like deciding when an encounter appears, remembering which crewmates are present, and letting earlier choices return later. The demo is still in development, and I expect parts of it to keep changing as I test it.
