So here's what Unity says the new pricing policy is, today (assuming it doesn't change again next week, like it did last week, and the week before).
https://blog.unity.com/news/open-letter-on-runtime-fee
Critical thoughts:
1. The fact that the new fees *only apply to 2024.1 and later* is the critical change here, and probably(?) avoids a lawsuit. This *will* have interesting ecosystem effects since many people will now want to stick on 2023.4 indefinitely. Possibly, libraries will latch to 2023.4 and never update.
2. The new policy is a bit confusing, though easier to understand than last week's. They now claim [over $1m revenue] they will charge *the lower of* 2.5% revshare, OR a charge per "number of new people engaging with your game" that they "calculate" based on your "self-reported data".
This "new installs" number is still untrustworthy gibberish. But now you can ignore it. The new "price" is 2.5% of revenue, possibly reduced arbitrarily.
Now the question is: Is this better or worse than Unreal?
(2, continued) Unity's new 2.5% revshare is lower than Unreal's 5%. But *Unreal doesn't charge a per-seat fee*.
A per-seat fee *plus* a revshare is sour tasting. Per-seat fees are really inconvenient for small operations where some or all of your devs may only use Unity part time. And those per-seat fees are (by my math) 5x higher than they were in 2021.
Overall, New Unity *probably* costs less than Unreal, *usually*. But awkwardly, any cases Unity costs more will be at the lower revenue end.
3. My gut is that if *this open letter's policies" were what Unity had announced to begin with, people would have been *annoyed*, as they were with the 2021 changes, but you wouldn't have seen a community collapse or mass exodus. However, I do not think this open letter will halt the mass exodus. The core problem is that *Unity can no longer be trusted*. You can consider the new 2024 prices acceptable. But now what you really have to worry about is how they will change in 2026.
(This thread has been edited to correct confusion about Unity's version numbering scheme, as corrected by Jonbro; 2023 LTS will be released in 2024 and therefore the new fees will apply.
Possibly, I will post a version of this thread on Cohost later, just so that I can actually sit down and make a two-dimensional graph of at what combinations of developer count and revenue Unity now costs more than Unreal. I bet it's going to be a *fascinatingly* baffling graph.)
@mcc more than that I think they lose the advantage of being the “low cost, no fuss” engine. Until this month, you paid them $X and you used their tools to make your game. Just like Maya or Photoshop.
It was ideal for a ten-person team hoping to hit it big in the mobile market, and that’s why all those teams used Unity. If there’s a bookkeeping requirement and a charge on the backend now, why wouldn’t the next generation of those teams switch to Unreal?
I really don't get people switching to Unreal.
When there is a near monopoly in a market, and one of the main players do something uncool and survives, the other players tend to imitate. A recent example is the raising prices of streaming platforms. An timeless one is every time someone rises oil prices.
What makes they think Epic will not pull the same move or worse next year? Remember: they used to be very expensive, until they were forced to imitate Unity pricing schemes.
@jgg @charliet I trust Unreal will not do this next year for the same reason that last year I trusted Unity would not do it this year. Because the company has shown itself stable and attentive to market conditions.
Unreal's prices did used to be higher, but my interpretation is that they used to target a higher-end market segment and started making changes to move into Unity's. If they're trying to capture Unity's market, they probably won't mimic a Unity move that clearly damaged the company.
@jgg @charliet And if Unreal *DOES* do it next year? It will not affect me. Because I use https://lovr.org/ :P
Who knows. Long term, they can try to devore Unity undercutting it, and once they are dead return to their old ways, or imitate them knowing they are not going to lose clients to them.
They getting bad in a month, a year or 2 years is more or less the same if you need 3 years to develop your game, anyway.
Lovr seems nice. I'd love (pardon the pun) to know how it works for you.
Never touched Lua, but after years of suffering the JS/TS dilema, I find nice the speed and creativity that carefree JS gives, and feel very constrained by TS. On the other hand, I enjoy C# strong typing, reflection and restrictions, mainly because it has really great IDEs that make autocomplete, hints and heavy refactoring a real joy. Which TypeScript promises too, but never fully delivers.
I fully understand your point. When you are a lone coder, having a very flexible and forgiving language is really nice. When you are in a big team, with a big code base, you need the restrictions, and powerful and absolutely reliable tools for refactoring and diagnosing bugs. Even more if you are expected to maintain that code for decades.
I really love the reflection capabilities of .NET. Seems like magic sometimes.
@jgg I think gradual typing (in other words… TypeScript, or Python I guess) is the solution, because it lets me not think about it when I'm just messing around and then introduce strong typing when I'm building infrastructure. I have dim hopes that I can eventually introduce a scripting layer to my Rust code so that I can add a "messing around layer" that meshes with my Rust infrastructure.
Tried TypeScript and Python and, frankly, it seems the worse of the two worlds to me.
The main gripe I have with Python is it doesn't force you to declare your variables. It was a terrible idea in old Basic, and still a terrible idea in Python. You are always a typo away of creating a new variable when you really are trying to change a value.
I find much more cumbersome TS typing than Java or C#; a great part of it is compatibility with JS forces weird kind of types to exist, some of the worst are DOM related (!). Java and C# have very simple and straightforward typing.
Besides, typing in Java and C# guarantees autocomplete and refactoring always work like a charm; but in Python and TS it is pure hit and miss (obviusly, a part of it is because you didn't especify a type; but many times it is because it hasn't found types for a library, or it got lost in your code). Java and C# were designed with this in mind; Python clearly not, and TS tries hard, but being JS compatible makes it impossible. They get much more mistakes at compile time, too, which saves a lot of time.
I have just watched the talk. English is sort of an acquired taste for me, to the point sometimes I have trouble understanding this kind of talks, but got yours fine, congrats. Funny reading in the automatic subs about a strange language with a randomly changing name: love, loves, lover, liver...
A nice and very informative perspective, kudos to you.
@jgg thanks… the name is a pun, its based on LÖVE but it's VR so it's named LÖVR
@jgg I gave a talk on it. https://youtu.be/u9cYW6ffkPM?si=jKsMIK90GK3EoL6e
It's very small even compared to Godot but it has a very active Slack (now a Matrix). I may be moving to something else as the ambient quality of Godot and Rust tools improves by comparison and my focus moves away from VR.
I love Lua but didn't anticipate how big a problem the lack of types would become as I scaled up from my former "hobby project" level to a commercial game level.