Game Development Post-Unity

What are the options for game developers looking to migrate away from Unity?

My tenure in the game industry was working on game engine code, not with game engine code. As a result, I do not have any first-hand experience choosing an off-the-shelf game engine. It’s not a decision I’ve ever had to make, and I don’t keep up with the latest developments across the myriad of engine options.

But I do follow game business trends to a certain extent, and for well over a year now, I’ve been warning that Unity’s relationship with game developers would inexorably change for the worse.

This was not based on any inside knowledge. It was based solely on the financials they report, and the kinds of statements they make to investors in their earnings calls. If you read these regularly, you get a very good sense for what a company’s priorities are in two ways: one, because you hear how they are pitching their future to investors; and two, because you can see how far in the hole they are financially, so you know whether they are likely to make major business model changes.

A Predictable Disaster

In Unity’s case, paying attention to their quarterly investor materials tells you many things that aren’t as common knowledge as they should be. As a small example, most developers think Unity is primarily in the business of selling game engines. They’re not! Less than half their revenue comes from game engines. Over half comes from advertising. Their bottom line is more affected by the advertising market than it is by how many developers buy their engine.

There are many things like this you learn when you dig into their investor materials. In my opinion, none of their fundamentals boded well for Unity’s future as a game engine on which to base a game company — hence my tweets (“X’es”?) on the subject.

A few months after I posted that Unity seemed likely to be absorbed, Unity merged with IronSource, a controversial company that has been accused of developing malware. This was the first indication that things might (unfortunately) be going the way I had anticipated.

Now, less than a year later, Unity has announced that they will be retroactively(!!) changing their license terms in order to charge game developers a substantial per-unit fee, despite explicitly disavowing “royalty-like” structures in the past. This move has sent shockwaves through the developer community, as one of Unity’s differentiating factors was that they only charged an up-front cost for their platform.

Developers are understandably upset by this move. Unity already charges high per-seat monthly rates to professional developers. At $185/mo, Unity Pro is twenty-six times as expensive as a subscription to Office365, and three times as expensive as Adobe’s “all apps” Creative Cloud subscription. At $250/mo, Unity Enterprise is among the most expensive end-user SaaS offerings a game developer might see — more expensive even than Autodesk’s Maya and 3DS MAX.

Yet despite these SaaS offerings being less expensive than Unity, to the best of my knowledge they have never tried to demand anything like a royalty from their paying customers. If they did, it didn’t last, because they do not charge any today.

Even if Unity ends up backpedaling due to backlash from this decision, it seems unlikely that developers will trust Unity going forward. Many are wondering if they should switch engines now to avoid relying on an untrustworthy partner for their core technology.

But switch engines to what?

Alternatives to Unity

Switching engines from Unity requires knowing what engine you might switch to. To that end, I was recently asked on X what I recommend as an engine for people who want to switch away from Unity. Since I have no opinions on this, I went ahead and asked developers to weigh in:

To make it easier for people to explore the responses, I tallied how many times each alternative engine was mentioned, and I’ve prepared a list from most-mentioned to least-mentioned.

I’ve also tried to summarize a little bit about what the engine seems to be “about”, but, take that with a huge grain of salt. As I’ve said multiple times now, I don’t use off-the-shelf-engines, so I have no first-hand knowledge here. If I’ve summarized anything inaccurately, please let me know in the comments, so I can correct it!

I’ve also tried to include the “scripting language” supported by each platform where applicable, so that people can quickly see if the engine directly supports a particular scripting language they know. Because they often don’t have official names, I’ve used “visual” if the platform has a built-in flowchart-like visual scripting language.

Godot (C#, GDScript, visual). By far the most-mentioned alternative to Unity, Godot seems in many ways to be an open-source response to Unity: less focused on high-end engine features than something like Unreal, and more focused on being quick and easy to spin up for beginners. Common complaints seem to be that it is “not quite there yet” — perhaps because of bugs and missing features compared to Unity — and that it lacks first-class support for consoles, a feature most professional game developers now need. But it has been used in some recent notable games (Brotato and Dome Keeper), and it seems to have decent momentum behind it.

Unreal (visual). The Unreal Engine needs no introduction. A hefty percentage of the AAA releases in any given year run on one version or another of Epic’s flagship engine. Although it offers a host of AAA features like Nanite, Lumen, and Metahuman, common complaints are that its complex nature makes it more difficult to get started, and requires more technical expertise to work with. However, as Ethan Lee — who does have a ton of experience working with off-the-shelf-engines — wrote a few months back, apparently shipping a game on Unreal is actually easier these days in many ways than shipping one on Unity if you’re aiming for a quality release.

Defold (Lua). Mentioned almost as many times at Godot and Unreal was an engine I’d never heard of, Defold. Apparently this is a good engine to check out if you’re developing 2D or mobile games, and it appears that tons of mobile-style games have been shipped on it. If you’re looking for more of a 3D engine, it is probably not what you’re looking for.

RayLib. RayLib is not an engine per se, but rather a library suite that allows you to quickly build games (and apps) in a native language like C++. It was mentioned multiple times, so it seems like DIY devs enjoy using this library — but, people looking for a turnkey solution with a full editor like Unity probably won’t be interested.

Open 3D (Lua, visual). This is actually CryEngine, which was licensed by Amazon and made into LumberYard, which was then abandoned by Amazon and made into Open 3D, which is now maintained as open-source. So, if you like CryTek, you might be very interested in Open3D! However, being a descendant of a highly-specialized AAA-focused engine does suggest it might have a harder learning curve, so it’s unclear how much of an option this is for less technical developers.

GameMaker (GML, visual). For 2D games, GameMaker is an evergreen favorite, and very beginner-friendly. Many famous 2D games were made with GameMaker — Undertale, Forager, Hyper Light Drifter, Gunpoint, Hotline Miami, and Spelunky, just to name a few. If you don’t need 3D or fancy lighting, it seems like a solid choice. But for anything more technically demanding, GameMaker unfortunately seems to top out quickly.

Unigine (C#). Though not primarily targeted at games, Unigine was mentioned multiple times as an option, and they do list games as a first-class application of their SDK. How useful a simulation-oriented SDK would be to someone coming from Unity, however, is an open question.

Bevy. For Rust aficionados, the most commonly mentioned engine was Bevy. Presumably, if you’d like to program games in Rust, this would be an interesting one to check out, despite not yet establishing much of a pedigree. That said, it also doesn’t seem to ship with a complete editing environment, but rather some embeddable tools for putting editing in the game itself. This might be more of a hard sell for people coming from Unity’s integrated editing environment.

Flax (visual). Like Defold, I’d never heard of Flax, but it touts a surprisingly large feature set, and provides integrated editing capabilities out of the box. However, it doesn’t seem like there are many (or any?) notable games shipping on this engine yet, which leaves a bit of a question mark as to its viability.

Cocos (JavaScript/TypeScript). Another full-featured engine with an integrated development environment, the modern-day Cocos suite is apparently the same tool lineage that was used fifteen years ago to make FarmVille. Although I wasn’t able to find out much about this engine, it does appear to still be mobile-focused.

Stride (C#). Although it was mentioned multiple times, I had a hard time finding out much about this engine. Apparently, this is Silicon Studio’s Paradox engine, which was renamed Xenko, and then later renamed Stride. I’m not sure if any notable games have shipped on it, but like Unity, it is a C#-focused engine, and comes with a full editing environment.

Monogame (C#). Microsoft’s XNA was one of the most successful game-development-targeted SDKs ever made, spawning Bastion, Owlboy, Timespinner, Magicka, Axiom Verge, Serious Sam Double D, and of course, Stardew Valley. Being Microsoft, they responded to this overwhelming success by canceling the project. Thankfully, community developers picked up the slack, and Monogame is the result. A reimplementation of the XNA 4 API, it continues to be a popular base SDK for C# developers.

And that’s not all. In addition to the platforms listed above — which were mentioned multiple times — there were several others mentioned only once, so I did not include them in the list. But that doesn’t mean they aren’t worth checking out! If you’re looking for more platforms to evaluate, the other ones people mentioned were: Construct, Ogre3D, Solar2D, HARFANG 3D, CryEngine, FNA, libGDX, LÖVE, Fyrox, C4Engine, Hazel, Wicked, TelluSim, and heaps.io.

Please Share Your Experience!

The biggest thing I realized when compiling this list was that most developers probably don’t know what all their options actually are. I bet a lot of people use Unity by default, not because they actually looked at all these other engines and determined that Unity in particular was best for their game or studio.

I think a huge help to everyone right now would be if developers could share their experiences with alternative engines. What kind of project did you use it for? How did development go? Are there any particular links to tutorials or educational materials that might help people get started? Do you know of any good overviews?

I am leaving this comment section open to everyone, so anyone who has experience to share can leave it in the comments below. Please try to be polite and helpful! And most of all, please try to give honest guidance to people about the engines you’ve used. That way people looking to make the switch can make a well-educated decision about which platform is best for them.