In October 2016 I wrote about the fall of cocos2d-xna — iOS 9 breaking everything, a Xamarin license I had to renew to fix it, and the realization that the engine I’d built my games on was running out of road. I ended that post by saying I was searching for a replacement, and that the next chapter was coming soon.

That was nine years ago. So, uh. Sorry about that.

Here’s the thing though: I didn’t stop working on the problem. I just stopped writing about it. And the answer to “what engine replaces cocos2d-xna?” turned out to be one I didn’t expect.

I’d maintain one.

The search didn’t end how I thought it would

I did the responsible thing first and looked hard at the big engines — Unity, Unreal, Godot. On paper, any of them could have worked. But going through them made me realize something about what I actually like in game development, and it’s the same thing cocos2d-xna and MonoGame had been giving me all along: being closer to the ground level. Writing code, not wrangling an editor. The big engines are built around the editor, and that’s just never been where I want to spend my time.

cocos2d-x held my attention for a while — it was the closest in spirit to what I’d come from. But it felt too rigid to work with, and it was all C++. After long enough in it, I really started to miss working with C#.

So I went back to look at cocos2d-xna again, half expecting I’d just pick it up where I left off. Instead I found it had been all but abandoned. That was a genuine disappointment — this was the framework that got me into game development in the first place.

That sent me to MonoGame, which cocos2d-xna had been built on anyway. And developing in MonoGame felt great — especially after slogging through a pile of other frameworks and engines to get there. I had a much greater appreciation for it the second time around.

Which left me looking at the whole picture: the .NET landscape was changing fast, the old cocos2d-xna was falling further and further behind, and it was still the thing that got me started. So I decided it was worth a shot to fork it myself and keep the project going.

It’s kind of a full-circle moment. I went out searching for a replacement, seriously considered coming back to the engine I’d started on — and when I found it abandoned, I took it upon myself to carry it forward.

Cocos2D-Mono

The first commit landed in February 2019. The pitch is in the tagline: MonoGame powered, built the cocos2d way. It’s the cocos2d API I already knew, sitting on MonoGame instead of the dead XNA stack — so the games I’d already written had somewhere to go, and the ones I hadn’t written yet had a future.

Since then it’s grown into something I genuinely didn’t plan on: 829 commits, 777 of them mine, and the most recent one two days ago. It ships on NuGet. It has real docs at cocos2d-mono.dev. CI runs green across DesktopGL (Windows, Linux, macOS), WindowsDX, Android, and iOS.

Every game I’ve shipped since runs on it.

Where it is right now

The last while has been less about new features and more about modernization — the unglamorous work that decides whether a project is still alive in five years.

2.5.11 (shipped a few days ago) collapsed the build from roughly 30 per-platform projects into three multi-targeted NuGet packages. Twelve packages became three:

Package	What it’s for
Cocos2D-Mono	The engine, with the MonoGame content pipeline (MGCB) build task
Cocos2D-Mono.Core	The same engine, without the MGCB dependency
Cocos2D-Mono.Box2D	The Box2D physics port

Each one multi-targets every platform and picks the right framework automatically. If you were referencing Cocos2D-Mono.Android or Cocos2D-Mono.DesktopGL, you now just reference Cocos2D-Mono and get on with your life.

Same release: the assembly is now Cocos2DMono.dll instead of Cocos2D.dll (the namespace is unchanged, so source doesn’t move), and I finally deleted the OpenTK dependency — which, it turns out, had been referenced but unused for years. Its only consumer was a long-dead GL-extensions probe. That’s the kind of thing you only find when you go looking.

And 2.6.0 is where the real refresh lands: .NET 10 and MonoGame 3.8.5.

Why I’m still doing this

It starts with the fact that I simply love this framework, and MonoGame underneath it. cocos2d-xna is what got me into making games, and MonoGame is what made me appreciate the craft all over again. That’s not a small thing to let quietly die.

The bigger reason is that I think other developers — new and experienced alike — deserve a viable option here: something up to date, still actively going, that pairs the power of MonoGame with the ease of Cocos2D. That combination is genuinely good, and when I looked around, nobody was keeping it alive. Cocos2D-Mono was born out of that gap.

Honestly, it comes down to three things. I liked it. No one else was clearly going to do it. And — maybe best of all — I get to build my own games on it.

The chapter I owed you

The story I was telling in 2016 was about an engine dying and taking my games with it. I framed it as a search — as if somewhere out there was the right engine, and I just had to find it.

That was the wrong frame. Nothing out there was going to be exactly the thing I wanted, because the thing I wanted was cocos2d, in C#, that didn’t depend on a stack that could evaporate. The only way to get that was to build and maintain it.

Nine years late, but the chapter’s written.

More posts coming. Faster than nine years, I promise.