The Long Way Around

By 1DigitalC. The Rift Wars Papers, Part IV: The Execution

I didn't set out to build a game alone. I set out to build something good and went looking for the people, the funding, and the structures that are supposed to make that possible. What I found instead was a pipeline that doesn't work for new projects in 2026, and a long list of reasons why the games most of us grew up loving are getting harder to make every year.

Rift Wars exists because I kept building while I was looking. This is the story of how that happened, what the search taught me about the state of the industry, and what I think it would take to actually fix it.

I'm not writing this to celebrate working alone. I'd happily work with a team tomorrow if the right one walked through the door. I'm writing it because the conditions that pushed me to do every layer of this myself are the same conditions strangling a generation of small studios, and that's worth talking about honestly.

The Pipeline Is Broken

Start with the funding side. Five years ago, an indie team with a working prototype could find a publisher willing to put up six or seven figures for finishing funds. That market has retrenched hard. Mid-size publishers have either folded, been acquired, or pulled inward to first-party slates. Venture capital, which briefly flooded into "web3 gaming," largely left when the token model collapsed and didn't come back for traditional games. Platform grants exist but are oversubscribed by orders of magnitude.

The hiring side is worse. Studios laid off tens of thousands of developers across 2023, 2024, and into 2025. The people I'd want to work with, engineers, designers, artists who shipped real things, are mostly looking for stable salaries at companies that aren't hiring, not equity stakes in a prototype. I don't blame them. I'd want the same in their position.

So the path that's supposed to exist (find a publisher, get an advance, hire a small team, ship a game) is, for most new projects, simply not available. You can spend six months chasing it, or you can build.

I chose to build while I kept looking. That's the actual origin story.

The Bureaucracy Tax

Here's the part that surprised me most. When I did get into rooms with established teams, what I saw wasn't velocity I lacked. It was velocity I'd lose by joining.

This isn't a knock on the people. Most game developers I've talked to are sharp and care about the work. The problem is structural. Process compounds with team size. A decision that takes one focused person five minutes can take a ten-person team three days: schedule the meeting, prep the docs, present the options, defer to the next sync, write the follow-up, get sign-off from the lead, get sign-off from the lead's lead, then implement.

Brooks's Law named this in 1975. It still applies. Adding people to a project doesn't add proportional output, and past a certain inflection point it actively slows things down. Not because anyone is bad at their job. It is because coordination is expensive, and bureaucracy is what coordination calcifies into when nobody is empowered to cut through it.

I'm not anti-process. The right process is the difference between a team that ships and a team that doesn't. But I've watched smart people lose months to approval chains that produced nothing a single empowered designer couldn't have decided in an afternoon. That's the bureaucracy tax, and it's part of why mid-size game projects keep dying.

What Necessity Teaches

When the pipeline doesn't open, you have two options: wait, or learn.

I learned. Not because I wanted to be a one-person studio, but because every gap in the project was a gap nobody else was going to fill. So I filled them, one at a time, in the order they became blockers.

I needed a server, so I learned server architecture. I needed cards, so I built a card generation system. I needed opponents at any hour, so I built a six-tier AI curriculum. I needed deployment, so I learned the deployment stack. I needed marketing, so I learned that too. Badly at first, then less badly. None of these were skills I picked up because solo dev is romantic. They were skills I picked up because the work was sitting there waiting.

That's the part the "I built this alone" posts on social media never capture. It's not a flex. It's a sequence of necessities. Every time I look at the codebase I see a record of what the industry didn't have available for a project at this scale, and a record of how far you can actually go by just refusing to stop.

The Coherence Side Effect

I want to flag one thing I noticed along the way, not as advocacy but as observation: the systems in Rift Wars are unusually coherent, and I think it's because they were forced through one head before they hit production.

The card generation system feeds the AI evaluation system, which feeds the matchmaking system, which feeds the economy. They weren't designed by separate teams negotiating their boundaries. They were designed in the same week, often in the same afternoon. When I add a new ability, I'm thinking about how the AI evaluates it, how it interacts with persistent effects, how it renders, and how it changes scoring all at once. Not because that's the right way to build games. It happens because there isn't anyone else to think about those layers.

That single-mind effect is real. ConcernedApe talked about it with Stardew Valley. The trade-off is obvious: scope. You pay for coherence with everything you can't build, and that bill comes due fast.

Scope Is the Real Enemy

The biggest killer of small projects isn't burnout. It's scope.

You start with a card game. Then it needs ranked matchmaking. Then it needs an economy. Then six tiers of AI. Then schools with skill trees. Then maps with modifiers. Then prediction markets. Each addition is reasonable on its own. Stacked, they bury you.

The discipline of building under constraints, whether solo, small team, or anything without a deep bench, is knowing what to cut. I've cut features from Rift Wars that I loved. Mechanics that were interesting but not essential. Effects that looked great but tanked performance. Subsystems that worked beautifully in isolation but made everything else harder to maintain.

Every feature you ship is a feature you maintain. That math hits differently when you're the one maintaining it.

The Part Nobody Sees

Here's a typical Tuesday.

7am: Check server logs from overnight. Two matches threw errors because of a card interaction edge case I didn't account for. Fix it.

9am: Card generation. Run the probability audit on the new batch. Three cards have ability grids that extend off the board from certain positions. Fix those.

11am: AI tuning. The Apex tier is over-weighting destroy cards. It's winning too consistently by killing everything. Adjust the heuristic to value board presence more.

1pm: Client work. The death animation isn't triggering VFX correctly when a persistent card is killed. The persistent removal and the death animation are racing. Fix the timing.

3pm: Marketing. Write a tutorial post. Generate the graphic. Schedule it. Check yesterday's engagement. Respond to the one comment.

5pm: Economy balancing. Run the M-Cred distribution simulation for 10,000 matches. Make sure the reward curve doesn't break the market in six months.

7pm: Still coding. Still fixing. Still building.

Nobody posts about the Tuesday. The version of indie dev the internet sees is launch screenshots and milestone tweets. The version that's real is 300 Tuesdays in a row, alone or otherwise.

What I'd Bring to a Team

This is where I'd want to land the article honestly: I'm not arguing that solo development is the answer. It isn't. It's an answer to a specific problem: a broken funding and hiring pipeline that left a generation of projects without obvious paths forward.

If anything, building this way has clarified what I'd want in a team. People empowered to make decisions without three layers of sign-off. Processes that exist to remove friction, not perform thoroughness. Generalists who understand more than their lane and specialists who go deep where it counts. Leadership that protects velocity instead of taxing it.

Knowing every layer of a game stack (server, client, AI, economy, deployment, marketing) isn't a substitute for working with great people. It's preparation for working with them well. You know what to ask for. You know which problems compound. You know where the pipeline tends to break and why.

That's the part I'd carry into any team that wants to ship something real.

Why I'm Still Building

Because waiting wasn't an option that produced anything.

I could spend six more months pitching, networking, and applying. I could keep writing the same proposal in different voices for funds that aren't deploying. Or I could keep the project moving and let the work itself be the proof.

So that's what I do. Every week the game gets better. Every week the AI gets sharper. Every week the card pool gets deeper. And every week I learn something else about why this industry is harder than it should be, and what it would take to make it less so.

The pipeline didn't open. So I built around it. That's not a manifesto. It's just what was available.

The work shipped because somebody had to ship it. That's the only lesson worth keeping.

This is how I think. This is what I'm building. If that resonates, you'll understand the game, and probably the work I'd do next.