About

The studio, the people, and the story behind Clean Game Architecture.

Who We Are

Crimson Pine Games (crimsonpine.com) is an independent studio focused on mobile games. Our flagship portfolio is Antistress Games (antistressgames.com) — a family of relaxation and creativity apps enjoyed by millions of players worldwide.

Despite their casual appearance, the Antistress titles are far more complex under the hood than it seems. Multiple game types — paint by numbers, jigsaw puzzles, diamond painting, and more — all ship from a single unified codebase, sharing a deep metagame with cross-title progression, synchronized player levels, multiple interlocking currency economies, and a portfolio-wide meta-progression layer that rewards players across every game they install. Behind the calm, relaxing exterior sits a serious production-grade architecture.

Our Story

Crimson Pine Games started the way many mobile studios do: a small team, a good idea, and a codebase that grew organically alongside success. Our Antistress titles found a large audience quickly, and we did what every growing studio does — we hired more developers, added more features, and kept shipping.

For a while, that worked.

Then it stopped working. Technical debt had been accumulating silently for years, and the symptoms became impossible to ignore. Every new feature took longer than the last. Bug fixes in one system cascaded into failures in systems that seemed unrelated. The codebase had become a web of hidden dependencies where nothing could be changed safely.

The instinctive response was to add more people. But more developers made it worse, not better. With no clear boundaries between systems, everyone was stepping on everyone else’s work. Merge conflicts became daily events. Onboarding a new hire meant months of tribal knowledge transfer before they could contribute without breaking things.

Then a few of the most senior people left the company to “start fresh” elsewhere. Technical leadership changed and an honest look at what we’d inherited made all the skeletons jump out of the closet — and there were plenty of them. We realized something had to change. Rather than patch the existing mess, we decided to do the radical thing: commit fully to restructuring around Clean Architecture principles — clear layers, strict dependency rules, interfaces at every boundary, and comprehensive test coverage. It wasn’t a gradual suggestion; it was a deliberate, studio-wide decision that the way we built software had to be different from that point forward.

The transition was painful. The first months were the hardest. Every feature carried migration weight on top of its own complexity. Velocity dropped even further before it improved. There were genuine moments of doubt — from developers who felt the new patterns were over-engineered, from management watching deadlines slip, and from ourselves when we wondered if the investment would ever pay off.

It took over two years.

But eventually the curve flipped. New features started landing faster than they ever had in the old codebase. Bugs that would have taken days to track down were caught in seconds by automated tests. Developers could work on different features simultaneously without colliding.

The outcome surprised even us. A smaller, more focused team now ships faster than the original, larger group ever did. The codebase doesn’t just work — it’s easier to make work, which compounds over time. That transformation was the single biggest reason the studio came out of that difficult period stronger than before.

For the technical strategy behind the migration — how we split the codebase into legacy and clean zones, wrapped boundaries, and migrated feature by feature — see Transition from Legacy.

Why We Wrote This

These principles changed our studio and helped the company overcome a near-extinction event. They turned a codebase that was drowning us into one that works for us. But the journey to get there was long, expensive, and full of mistakes we could have avoided if someone had written down what we know now.

That’s why this site exists. We want other game developers — especially those working in Unity, but the ideas apply to any engine — to benefit from what we learned without having to go through the same pain. Clean Architecture isn’t new, but applying it to games has unique challenges that the standard literature doesn’t address. This is our attempt to bridge that gap.

If you have any questions about this site you can contact us at cga@crimsonpine.com.