MiniGameDev | Simple systems for powerful games.
Building a Repeatable Production Pipeline

Building a Repeatable Production Pipeline

Fri Apr 03 2026

I recently hit a strange point in my game’s development: all the systems work, but it still doesn’t feel like a game yet.

Right now, the player can:

On paper, it sounds good. However, it still wasn’t enough to make the experience feel cohesive.

That realization has pushed me into the next phase of the project: Execution.

My goal now is to build one complete mission area with final-ish art, VFX, SFX, narrative, and gameplay. While doing that, I’m also building the production pipeline that will let me finish the rest of the game.

Defining the Real Problem

For a long time, I tried building games by investing in mechanics and systems.

That’s what I’m comfortable with. I’ve built inventory systems, stat systems, progression systems, dialogue systems, and all kinds of supporting tools across multiple projects. But even when those systems were solid, I still wasn’t ending up with a real, finishable game.

The reason was relatively simple: systems are only half the equation.

A game also needs a repeatable structure that the player can discover, learn, and eventually master. Without that, every part of the game becomes a unique production problem.

And that’s bad for a couple reasons:

  1. It explodes scope as a solo developer
  2. It weakens the player experience because there’s no consistent rhythm or expectation for how the game unfolds

Traditional software can get away with this. Most software is a collection of systems with some light connective tissue between them. But this doesn’t work for games.

Building a Repeatable Game Structure

So I’ve started designing Arden Cardfront around a repeatable campaign format.

Each level / area in the game is now treated as a self-contained mission. Since the game is set in an active warzone, I want each area to feel like a deliberate military operation dressed up in a fantasy setting.

Here’s the structure each area will follow:

That’s the full loop. It’s simple and that’s the point. This structure gives the player a rhythm they can understand, and it gives me a production model I can actually repeat four times without exploding scope.

Why I Changed the Structure

This shift happened because of my first Area 1 prototype. Over February and March, I built an early version of the first area. It had:

When I first blocked it out, I actually thought the area might be too small. Just walking across it only took 90 seconds. But once I layered in the encounters, pickups, traps, and interactions, the area became much denser than I expected.

I had my wife playtest it, and the results were surprising. It took her around an hour to fight and explore the level, and she only managed to explore about half of it.

That’s when I realized if I approached each area indpendently, I was going to over or under design them. So I standardized. Now, each area is built around:

It’s a better fit for the game I’m building. And it’s finishable because now there won’t be ambiguity when I design the next area.

Breaking Down the Area Structure

Narration

Each area begins with narration that sets the stage for what’s next. This is where I can establish context, atmosphere, and mission framing without needing expensive cinematics or large-scale in-engine storytelling.

The plan is to keep this simple: text on screen against a controlled backdrop. That keeps the production cost low while still giving the game a strong narrative identity.

Opening Cutscene / Dialogue

This is where each area gets its strongest visual setup. For Area 1, the opening is intentionally minimal:

  1. An airship drifts into frame
  2. It lands
  3. The player character steps out

That’s it.

The goal isn’t to make elaborate cinematic sequences. The goal is to create one strong, memorable image that introduces the area and puts the player into gameplay quickly. The dialogue that follows is there to establish the mission, introduce any key characters, and move things forward.

Mission Area

This is the core of the experience. Each mission area is where exploration, tactical decisions, enemy encounters, and environmental storytelling come together.

By reducing the number of encounters and reducing the layout, I can spend more time making each one feel deliberate instead of just filling space. Each area will still have its own enemy lineup and tactical identity.

Mission Boss

Each area ends with a boss encounter. The boss is meant to serve as the final test for that area by combining and escalating the ideas introduced by the normal enemy encounters.

That gives each area a clear endpoint and a stronger sense of progression.

Closing Cutscene / Dialogue

Just like the opening, the closing sequence is meant to be lightweight. A small amount of animation, a bit of dialogue, and a clean transition into the next mission area. The goal is to keep the player’s momentum.

Building a Repeatable Production Pipeline

The repeatable structure isn’t just for the player. It’s also for me.

To support that, I’ve been building tools and data-driven authoring workflows that let me configure each mission area without writing new code every time. For each level / area in the game, I’ve defined a data asset that allows me to configure the area automatically.

Area 1 Game Level Data Definition

That data allows each area to be associated with arbitrary sets of:

This keeps the level itself agnostic of the actual gameplay flow. Instead of hardcoding custom logic into every map, I can author the area’s structure through data and let the systems do the heavy lifting.

That has already paid off. I was able to move from my original prototype level into a brand new level with almost no rework. Encounters, hidden items, dialogue, and mission flow all transferred over.

That’s exactly the kind of leverage I need if I want to finish this game as a solo developer.

What’s Next?

The next phase of the project is all about execution. At this point, I have the:

What remains is the hard part: turning all of that into something that actually feels like a complete, cohesive game. That means:

That’s still a lot of work, but for the first time, it feels like I’m not just building isolated systems anymore. I’m building a pipeline I can actually use to finish the game.

Up Next: TBD