Fiasco Game Engine

Context: The Game Is the Workspace

Fiasco is a browser-based game editor built around a single conviction: the game is the workspace. Rather than forcing developers to toggle between separate tools for designing, building, testing, and debugging, Fiasco embeds all of those workflows inside the game itself: live, stateful, and continuous.

I joined Void Industries as Founding Head of Design and employee #1 on the product team. This is the story of Tapes, the feature that became Fiasco's key differentiator, and the discovery practice that made it possible.

The Problem: Skill Became a Penalty

Every bug fix in game development starts with the same silent tax: reproduce it first. Play to the point. Reset. Play again. If the bug depends on specific inventory state, a particular frame sequence, or a condition that only surfaces under the right inputs, reproduction could take longer than the fix itself.

What made this more than a friction problem was what we heard repeatedly in research: the better the developer, the more bugs they find, and therefore the more time they spend in this loop. Skill became a penalty. The most capable people on a team were paying the highest cost.

"If you see something and you forgot to record, you're like, oh my god, now I have to figure out how I can reproduce that."
— Developer interview, external beta studio

Unity and Unreal didn't address this. They were built on the assumption that developers would get things right. Existing tools treated debugging as a personal problem, not a workflow failure. We saw it differently.

Discovery: The Workarounds Said Everything

I established a continuous discovery practice from the start, running weekly research alongside our CPO and lead developer. The insight tree for bug reproduction grew across internal interviews and two external beta studios, and what emerged was consistent: developers had already invented their own workarounds.

One developer had built a custom debug menu with frame-freeze and physics overlays. Another recorded gameplay in QuickTime, then manually annotated the clip with system context before sending it to teammates. These were not edge cases. They were industry-standard coping mechanisms for a problem no tool had chosen to solve.

The workarounds told us exactly what shape the solution needed to take. When people invent their own tools, they're telling you what they wish existed.

‍

Iteration: A Tape Is Not a Recording

The core interaction was clear early: developers needed to scrub a gameplay timeline the way you'd scrub a video, moving forward and backward through recorded state without re-playing anything. The mental model we reached for was the browser inspector. Developers already knew how to hover an element and see what was underneath it. Tapes borrowed that instinct and applied it to time.

The design challenge wasn't the scrubber itself. It was everything around it. What gets recorded automatically vs. on demand? How does a developer mark a moment of interest without breaking flow? What does it mean to share a tape: is it a video, or something more?

That last question became the insight that shaped the whole feature. A tape isn't a recording. It's a copy of state. When a developer loads a tape and can no longer reproduce the bug, that's the confirmation the fix worked. Sharing is not playback. It's a handoff of state and control.

Tradeoffs: What We Chose Not to Build

The hardest design decision in Tapes wasn't what to build. It was what not to build. Early in the process we explored giving developers explicit control over what got recorded: toggle-based capture, manual bookmarking, opt-in discipline tracks. The argument for control was real. Developers are power users and generally distrust tools that make decisions for them.

But our research kept pointing the other way. The moments that mattered most were by definition the ones developers hadn't anticipated. An opt-in system would protect developer agency while guaranteeing they'd miss exactly the captures they needed most.

We made the call to record everything automatically, with a lightweight UI that stayed invisible until needed. The tradeoff was accepting some developer skepticism about always-on recording in exchange for capturing the unexpected. That bet proved out in testing. The first time a developer scrubbed back to a bug they hadn't thought to capture, the skepticism disappeared.

The second major tradeoff was scope. We could have built Tapes as a solo debugging tool and shipped faster. Instead we pushed for the collaborative layer: tagging teammates to specific moments, discipline-specific tracks. Because research showed that the most expensive bugs were the ones that required handoffs between disciplines. That added complexity and time, but it was the difference between a useful feature and a differentiating one.

The Feature: Invisible Until You Need It

Tapes ships inside Fiasco's Play mode. Every session is recorded automatically: no setup, no separate capture tool, nothing to remember to turn on. The playhead sits at the top of the viewport and stays invisible until you need it.

From any point in a session, a developer can scrub back to a moment of interest, inspect live data at that frame, make a fix, and verify it, all without leaving the editor. The timeline expanded to support multiple discipline tracks (Art, Sound, Animation), so the same recorded session could surface different context depending on who was looking at it.

The collaborative layer came directly from usability testing. Developers wanted to tag teammates to specific moments: pointing the animator to a frame, flagging the engineer to a physics event. The tape becomes a shared object that each discipline can enter and act on.

Outcome: A Different Relationship with Making

Iteration cycles dropped from one to two weeks down to two to three days. Prototype volume increased three to five times over, shifting engineering time from rework to forward progress. Beta studios evaluated gameplay changes in days rather than release cycles.

Tapes became Void's clearest differentiator, the feature that reframed what a game editor could be. Not a faster version of Unity, but a different relationship with the act of making.

"It was pretty cool that I was able to just scrub right through and find where the issues are, now that is extremely useful."

— Hasan, usability test participant