Butter Up! Devlog #1: Building a Game Inside Our Own Game-Dev Platform

This is Part 7 of the “Agentic Game Dev” series. Part 1: The Manifesto → Part 2: The Framework → Part 3: Asset Validation → Part 4: Build Failure Investigation → Part 5: Pipeline Insights → Part 6: Dogfooding Our Perforce Agent → Part 7: Butter Up! Devlog #1 → Part 8: Butter Up! Devlog #2.

We make software for game studios. So we asked ourselves an uncomfortable question: do we actually use it the way our customers do? Not a seeded demo full of fake data: a real game, with a real Perforce depot, real builds, real “wait, why did that change break the package?” moments.

So we started making one. Meet Butter Up!

Butter Up! is a tiny precision platformer. You play Pat O’Butter, a walking stick of butter trying to cross a blazing-hot kitchen and reach the fridge before you melt into a puddle. A single melt meter is both your health and your timer: every second in the heat costs you, and your score is how much butter you have left when you slam the fridge door. It’s deliberately small. That’s the whole point.

This is Day 1. Here’s what we built, why, and what it has to do with ButterStack.

Day 1 walkthrough video to be added: Pat O’Butter’s first run across the kitchen, melt meter ticking, heat, a cool pickup, and the dive for the fridge.

Why build our own game?

When you sell tools to game developers, the most convincing demo isn’t a slide deck. It’s your own commit history. A real backlog. A build you can click into and trace all the way back to the changelist that caused it.

For a long time our demo was a coherent fiction: seeded data that looked like a studio. It was fine for showing the UI, but it couldn’t answer the questions a technical buyer actually asks. “What’s in Perforce right now?” “Show me the build for that task.” “Where did this asset come from?” If the honest answer is “those are database rows we made up,” you’ve lost the room.

So we decided to build a game we own: a real, never-reset Perforce project that grows one authentic changelist at a time. We call the result a game studio in a box: Butter Up! lives on the exact infrastructure ButterStack runs for studios: Perforce for version control, Jenkins for builds, Jira for the backlog, Unreal Engine 5 for the game itself. The demo isn’t a mockup of a studio. It is a studio, and a real game is growing inside it.

What we built on Day 1

Two halves came together: the studio, and the game running in it.

The studio stack:

• A Perforce-native depot (//sample-game) as the single source of truth: permanent changelists, never rebuilt, never reset, exactly the way a real studio runs.
• A real backlog in Jira: every epic and task, fully written up, so work flows the way it does on a shipping project.
• A UE 5.8 project that compiles and packages to a real Windows build.

The game:

• Pat moves and jumps, with the little feel niceties that make a platformer feel good (coyote time, jump buffering, a variable-height jump).
• The melt meter drains. Stand in the heat and it drains faster. Hit zero and Pat slumps into a puddle and respawns.
• Heat zones melt you quicker; cool pickups buy back some butter.
• Reach the fridge and you win, scored on the butter you managed to save.

It’s already a complete little loop: move, manage your melt, make it to the fridge. The art is placeholder (think grey boxes and an on-screen readout), but the game is real, and it’s winnable.

Every beat maps to ButterStack

Here’s the part we actually care about. Every thing we did to build the game is the exact thing ButterStack exists to observe for a studio:

• A developer submits a changelist → a build kicks off (Perforce → Jenkins). ButterStack watches that handoff.
• A task links to the change that implements it, which links to the build that ships it (Jira ↔ Perforce ↔ Jenkins). ButterStack stitches that timeline back together.
• Binary assets (Unreal’s .uasset and .umap files) move through Perforce with exclusive locks, carrying their lineage. ButterStack surfaces where they came from and who touched them.

So when a buyer asks “what does ButterStack actually show me?”, the answer is no longer a tour of fake data. It’s: here’s our game, here’s the real pipeline behind it, click any build and trace it back to the task and the changelist. The game is the demo.

AI-accelerated, but real

We’ll be honest about how fast this came together: a lot of it was built with AI assistance, working directly against the live Unreal + Perforce setup, writing the gameplay code, packaging the build, and committing the changelists.

But “fast” did not mean “fake.” Every change is a real, version-controlled changelist in a real depot: authentic history, not a replay and not a seeded fixture. That distinction matters to us because it’s the same distinction that matters to the studios we serve: a pipeline is only trustworthy if what flows through it is real.

It also previews something we think is coming for every studio: AI agents committing alongside humans, and the growing need to observe, attribute, and audit that work. We figured we should live that on our own project before we ask anyone else to.

What’s next

Right now it’s one level and a melt meter. The plan is a lot more: three levels, a proper 3D Pat O’Butter with a melt material that visibly droops as he softens, compound-butter “flavors” that change how he moves, and a Van Gogh-impasto diorama that fills in as you stack up wins. We’ll keep posting devlogs as the kitchen heats up.

Building a game and tired of duct-taping Perforce, Jenkins, and Jira together by hand? See what ButterStack can do for your studio. Free to start.