Behind the Work
How we build games from a question, a notebook, and a lot of iteration.
How a Game Starts
Every project begins the same way: a single image or question in a notebook, sketched or written before we touch code.
That's it. No design document, no feature list. Just something like "what if a radio tower could talk back?" or a thumbnail sketch of a place that doesn't exist yet. We sit with it for a few days, turn it over, ask why it stuck.
Then we prototype. Usually in Twine or on paper—a flowchart, a sequence of decisions, a set of cards on a table. We're testing whether the idea is actually fun or just interesting. Can we play it? Does it surprise us? At this stage we're looking for the skeleton, the thing underneath that might actually be worth building.
Only when we've found something we believe in do we open an engine and write the first real line of code.
Case Study: Marrow Keep
A roguelike about digging deeper. Early players hated dying.
In closed playtesting, we watched people make a single mistake twenty minutes in and just… quit. They'd lose their gear, their progress, everything. And they'd close the game. That's not tension—that's punishment. Permadeath only works if failure feels like it's your fault and you're ready to try again. Our testers weren't ready. They were frustrated.
So we invented the Bone Debt mechanic. When you die, you don't restart from zero. Instead, you can borrow resources—equipment, gold, passages—from your next run. You have to pay them back. You've gone deeper into debt.
This changed everything. Dying still stung, but now there was a conversation between runs. You'd limp back to the surface, plan around what you owed, and go back down smarter. We ran three closed playtests—each time tweaking the interest rates, the cooldown penalties, how much debt you could carry—until the mechanic felt like it belonged to the game, not fought against it.
It's the difference between a system that punishes you and a system that challenges you. We spent six weeks finding that difference, then another two shipping it.
Case Study: Hollow Signal
A puzzle game inspired by real radio towers on the Bristol Channel, built on actual radio science.
We spent a day walking the coast near Pill, photographing derelict transmission towers. Something about them—that sense of machinery listening to nothing, or maybe listening to everything and telling no one—felt like a story waiting to be told.
The core puzzle came from researching radio direction finding: the real technique used since the 1920s to locate signal sources. You need at least three receivers, each measuring signal strength. The source lives at the intersection of those measurements. It's elegant, it's geometric, it's a puzzle waiting to happen.
We tested the mechanic on paper first—a grid, three stones marking receiver positions, a hidden target. Players had to adjust receiver angles and strength thresholds until they narrowed down the target's location. Then we built a vertical slice in two weeks: just the core puzzle loop, no story yet, no polish. Could players understand it intuitively? Did it feel good to solve?
Yes and yes. From there we wrapped the puzzle in atmosphere—the abandoned tower, the radio chatter, the slow revelation of what you're actually listening for—and iterated through playtest feedback until release.
Pipeline: Prototype to Release
Paper & Prototype
Sketch, notebook, Twine, card tests. Does the idea work? Does it feel good? No code yet. One to two weeks.
Vertical Slice
One core loop in engine. Rough but functional. Two to four weeks. This is where we know if the idea survives contact with a real game.
Closed Playtesting
A small group of trusted players. Two to four rounds, depending on scope. We watch, we listen, we iterate on feel and clarity.
Public Demo
One to two weeks of wider feedback. Usually a 10–30 minute slice of the full game. This is our last chance to course-correct before content lock.
Full Development
Content, art, sound, systems. Polish and bug fixes. The actual grind. Usually four to eight weeks depending on scope.
Release & Support
Ship it. Listen to players. Patch what breaks. Ship what improves the game.
This is the same process we offer to commission clients.
If you're working on a game and you want us to prototype a feature, validate a mechanic, or build a full production from the ground up, this is how we do it. We start small, we test early, we iterate based on real player feedback, and we ship something that actually works. No surprises. No crunch at the end. Just craft.
Want to talk about a project? Get in touch.