Unity Runtime Fee: a look at some numbers

For the past few months I've been pretty busy with all sorts of development: I've been working on a video game of my own, in addition to some webdev and benchmarking of some technologies and most recently, I've even taken up a freelance project that might keep me busy for a few more months. Because of this I haven't really posted anything here in a while, though recently some news came out that caught my attention and therefore I'm breaking this little hiatus of mine to discuss current events.

What might news those be? It's none other than the newly announced Unity Runtime Fee, of course:

Recently the company behind the Unity game engine announced that they're changing how their product is priced. This change seemed abrupt to even some of the people that were working in the company at the time, some of whom have since resigned because of it:

Many employees also seem unhappy with management’s decision to change the pricing model. According to former Unity senior software engineer Jono Forbes, who prior to this week worked on the XR and PolySpatial teams (via LinkedIn), the company’s pricing update caused some employees to depart from the company.

“As a Unity employee until this morning, I assure you we fought like hell against this, brought up all the points everyone has, were told answers were coming, and then the announcement went out without warning,” Forbes wrote on X (Twitter). “Those of us who care are out — more resignations coming end of week.”

So what's the actual change, if it's enough to make some leave the company altogether?

The changes

Their announcement described it in detail.

In other words, now they'd expect the creators of games (and other software like visualizations) to pay them a fee each time the software is installed on an end user's device. In a sense, that's like you paying for an IDE and the company behind it suddenly asking you to pay for each time your application is installed or even launched. Ouch.

Up until now, most of the game engines in the industry either took a piece of your revenues (like Unreal Engine), or just charged you a flat fee for the tools. In the case of Unreal Engine in particular, their licensing page goes into more detail: if you opt for their plan with no upfront cost, then you can make 1 million USD and after that have to pay a 5% royalty fee for gross revenue on top of that. Many game developers will never actually make a million, so for them the engine is effectively free, though enterprises can also pay a bigger upfront fee based on the number of developers, after which royalty-free distribution can be negotiated.

Even Unity used to have a simple pricing structure, you could use their free version up until your revenues exceeded 100k USD in the last year, after which you could look at their Pro subscription (there have historically been some other plans, but the idea behind them was pretty much the same). Once you actually start making a decent amount of revenue, paying a few thousand USD per year does no longer seem like such a hard value proposition, so it's not like anyone was particularly upset with that pricing structure:

However, what would things look like under the new pricing structure? Well, the good news is that you'd pay pretty much nothing until you've made 200k USD instead of the former 100k USD and have a substantial install base for the actual game, so that's not all that bad. In essence, you're off the hook until you start earning double the previously relevant revenue, so this should give most developers more breathing room:

Unfortunately, that's where the positive aspects end. Past that, you'd be paying a certain amount of money for each time the game or software is installed on an end user's device, which effectively means that the expenses will scale up not with your revenue, not with your team size, but rather how many people are actually playing your game, provided that you're making money on it:

At first glance, that might not seem like the end of the world. Suppose that you release an affordable indie game that's priced at around 15 USD instead of the AAA pricing of around 60 USD. Perhaps you release the game on a platform like Steam, which might take around 30% of the sale, leaving you with 10.50 USD. Let's also assume that your game also has a publisher which will take some of your revenue as well, for a very simplistic model let's assume that it's 50%, leaving you with 5.25 USD. Even though you might have taxes to deal with, payment processing fees and other things like that, the Unity Platform Fee would still be only 0.20 USD at most, meaning that you'd be handing over about 5% of what you've made.

Not a big deal, right? Well, what you need to consider first and foremost, is that many games out there are essentially free and earn money from micro-transactions, or ads in the games themselves, which is the case for the majority of the mobile games market (in which Unity is perhaps the single most popular engine).

Furthermore, their definition of an install doesn't seem all that nice either:

It can all break down in environments where you don't get a persistent machine identifier, such as with web games (the "streaming" use case, when running in a browser with WebGL). For example, if you run a game that's made in Unity and it phones home, then after you clear your browser cookies, any subsequent attempts to play the game would probably register as new installs, incurring additional expenses:

Well, it's either that or invasive browser fingerprinting which some plugins or browsers might also attempt to work around, such as the Mullvad Browser, probably just breaking things in all sorts of ways. How do we know that this policy was badly made? Well, by looking at how much Unity have been changing the corresponding web pages after releasing them to the public, some archival sites suggest that they've been pretty busy editing them:

Maybe there is light at the end of the tunnel. If you look at the FAQ article, they've since stated that they won't count reinstalls of the same game on the same device towards these statistics, though unfortunately I'm not sure how exactly they will manage to do this, because without a centralized user ID system any attempts will be quite error prone:

Even if reinstalls won't cause issues, this still forced the developers to monetize their games a certain way, to attempt to maximize the profits from each user, such as putting more ads in their mobile games (since you'd need each user to watch at least 10 ads per install, assuming around 0.02 USD earnings per a single ad).

Even if the particular figures might shift around, the end result is clear: non-paying users, which previously wouldn't have been an issue, now actively become a liability to you.

The fallout

I will look at the numbers for what this all might look at later, but it seems like the rest of the Internet has already done their own research and aren't entirely happy with it. It's enough to just look up the game engine on YouTube and you'll see video upon video denouncing this change:

In part, I feel like this might be people chasing after recognition and their own profits: if something is popular online (some ongoing "drama"), you can be sure that most of the content creators will attempt to cover the topic, give their own takes on it and rake in some of the ad revenue, if possible.

There's nothing wrong with that, of course, but they obviously do have their own motivations and this can lead to the sentiment getting amplified and possibly things getting blown out of proportion.

Except for the fact that the changes are so severe, that even popular games are about to get deleted and won't be playable once this change will come into effect. For example, the developers behind the popular game Cult of the Lamb Tweeted one such message:

This is more notable, because it actually hurts their own bottom line: they've decided to stop selling the game altogether, instead of dealing with the fees, which means that they must really be feeling strongly about this! Not only that, but you know that things are indeed getting serious, when video game publishers themselves are putting out messages that suggest that Unity might not be accepted as a game engine in future deals:

They must feel pretty strongly about this, to the point of risking not being able to compete with those publishers that would just bite the bullet and pay the runtime fees. I'm actually not sure whether they have enough insider information to verify that the fees would indeed be a dealbreaker, or whether they're hoping that they've got enough leverage to get Unity to revert the changes, though it does seem that many are getting on the bandwagon with similar statements, some put more bluntly than others:

It's hard to say precisely where people doing the math ends and mob mentality takes over, but every single one of those developers are fully within their rights to choose whatever technology they desire to build their games in.

The problem, of course, is that this move on Unity's part might utterly destroy many of the projects out there. You can switch IDEs when doing regular software development, you cannot do the same with game engines. It's like you spending 3 years building a web application in Java just to be told that you no longer can use that technology and have to rebuild everything in .NET... without ever having used it before. With this in mind, the strong sentiments expressed become perfectly understandable.

However, does this outcry make sense on paper?

How bad is it, really?

I think a lot of this can probably be figured out with a simple spreadsheet. For each potential popularity that your game might reach, there is probably an amount of money that you need to make with a single sale for your business to be viable. So let's calculate just that, albeit with lots of approximations, to get a general picture.

First, let's start with the expenses that go to Unity (excluding regular license fees) based on the amount of installs, assuming you've exceeded the revenue threshold. With the Personal and Plus tiers, the expenses would rack up the most quickly, because you don't really get volume discounts like the Pro and Enterprise tiers. Here's the numbers:

Perhaps they're nicer to look at in the form of a graph:

With that in mind, it becomes immediately obvious that nobody is going broke if they're targeting the emerging markets, or are on the Unity Pro or Unity Enterprise plans, which have the most user friendly pricing out of the bunch - especially considering that you really only start paying the runtime fee after hitting 1 million USD in revenue in the past 12 months and 1 million lifetime installs. As for Unity Personal and Plus tiers, however, it gets pretty crazy.

Given the current pricing, it pretty much makes sense to switch over to the Unity Pro tier the very moment when you start having to pay the platform fee - because once you start going over 500'000 total installs, the platform fee gets more expensive than on any other tier. The difference is so staggering because of no volume discounts and it almost seems like a mechanism to upsell those other plans, unless the developers really want to waste their money.

But what about how much money you need to make off of a sale, to be able to cover the platform fee? Let's assume some sort of a split for the publisher and platform fees to get to such a figure in another spreadsheet:

Once again, it's possible to create a graph from the numbers, and the overall picture becomes more clear:

As always, I do reserve the right to be wrong with my numbers, but the general trend here is plainly visible - once more, the Unity Personal and Plus tiers have the greatest expenses to deal with. Not only that, but it also becomes apparent that if you have a publisher (that might take half of your revenue after platform fees) and platform fees (which are 30% in this case), then that increases the total amount of money that you need to make to overcome the platform fees per install.

Those 20 cents in Unity's blog post suddenly become closer to 50 and even though at lower volumes it wouldn't be such an issue (because you still have those 200'000 initial sales that amortize the cost), if you stick with Unity's Personal or Plus plans, the expenses quickly start mounting. In other words, with their current lack of volume discounts, it becomes rather apparent how this is just a sales funnel to their more expensive plans, for anyone who's game becomes successful.

So what can we do about it?

The alternatives

Suppose that this is too much to deal with, that Unity would decide to not roll back their changes and that people would indeed have no other choice than to throw away years of experience with Unity's tech and would have to look for another game engine to use for their games, visualizations and other software. Is there something out there that can replace Unity?

My short answer is this: no.

There are many technologies that get close, however they all have their own shortcomings. In some cases, that will simply cause the developers to spend more time re-implementing tools or features that were available out of the box in Unity, or were available in Unity's Asset Store. In other cases, that will be too much work (because nobody is going to write their own terrain functionality, in many cases people won't have neither the skills, nor time for that) and entire projects will be scrapped. It might be akin to Star Citizen's engine switch once they realized that all of their time was disappearing into a black hole, due to the engine tech not being compatible with what they were trying to do and that's one of the examples of people who have lots of money to throw around.

As for the engines that do feel like they might get most people close enough, these are probably worth a look or consideration:

• Godot - fully open source and is getting lots of attention, but still isn't very mature (see my previous post; though a new terrain plugin is in the works) and has basically no large games written in it yet; I'd say that in the next decade it will be on par with Unity 5, but until then all early adopters will struggle somewhat, with everything from 3D performance (which got better in version 4), to things like console support and bugs
• Unreal Engine - a very mature engine with lots of sophisticated graphics technology, but is complex to work with (C++ instead of C#), making you resort to visual scripting due to a lack of other supported languages (there are 3rd party language bindings, but those aren't very dependable), in addition to historically being meant for FPS games and other genres being harder to get working easily
• Stride (Xenko) - perhaps the closest open source engine to Unity (uses C#), but sadly this one never really got a big community around it and seems to be gradually trudging along without a lot of committers or new features being released
• O3DE - formerly known as Amazon Lumberyard, which was based on CryEngine, before eventually being made open source, this one is similarly complex to Unreal Engine, in addition to not being as popular and the earlier versions were just rough
• NeoAxis - similar to Stride (also uses C#) in that it's a nice project, but basically nobody uses it and it doesn't have much of a community around it, so no tutorials or assets, or anything of that variety, really
• jMonkeyEngine - for the fun of it, here's an engine that uses Java instead of C# and felt pretty decent when I used it, it still puzzles me that JDK doesn't get a lot of love amongst gamedevs, although I've donated money to them in the past, this is also a similarly niche one to Stride and NeoAxis in that few people use it

In short, you can't replace a game engine that has been around for almost 2 decades with others that either failed to attract an audience and build a community around themselves, or simply haven't had the time and the person-years of development that are necessary to add a bunch of important features and squash most of the bugs.

If you don't need something that's 1:1 to Unity's feature set (even ignoring things that were never really finished, like DOTS, their new networking solution, SRP or their many SaaS/PaaS solutions) then you're more than welcome to give those engines a look, maybe even work on some new features or fixing bugs yourself!

Summary

To put things in summary, this feels to me like another attempt by a large corporation to get access to additional income. This time, however, it doesn't seem like they gave enough thought to how their new approach would actually work without ending up quite unfair to their own customers (e.g. if someone who dislikes a game would decide to spoof and spam fake installs). Aside from the criticisms from the community, however, it appears that this is actually just an attempt to get more people to upgrade from the Unity Personal tier to Unity Pro or others once their games start getting popular, because that's the tier that is hit the hardest in non emerging markets.

Of course, as usual, the people on the Internet do take things pretty seriously and seem to be on the verge of boycotting the company which may or may not work for getting these changes reverted or reviewed in more detail, since there haven't been large scale protests to more conventional licensing structures, like what Unreal Engine offers instead. For many, this will actually be a reason to move off of Unity and look at other engines, though I can tell you with confidence that this will absolutely cause many projects out there to either be scrapped entirely, or will make them stick with Unity and just follow whatever terms are given.

The reason for this is simple - instead of the "sunk cost" fallacy, we're dealing with a situation where years of work would essentially be lost. Game development is a discipline of software engineering that has a lot of coupling between the engine tech and the actual game code. One without the other is essentially useless, so it's not like you can just take your code and move to another engine without having to spend a similarly large amount of time porting everything over and sometimes rewriting entire mechanisms because of the APIs and architectures being entirely different.

As for me, I'll probably keep my current personal project on Unity, because I have no illusions about my game ever getting big or successful, so none of the platform fees are an actual issue for me. But in the future? Who knows, maybe I'll spend a few months jumping around Godot, Stride and NeoAxis, in hopes of finding something that is boring enough and just let's me focus on development, instead of things like this whole ordeal.

Finally, in closing thoughts, to realize how big of a matter this actually is, have a look at the statistics for game engines used to release games on Steam, here's the top 10:

I doubt we'd have many games to actually play, if everyone decided to remove their Unity projects from the various stores that they're available on.