Official Unity plan pricing and packaging updates

*pogoing away while headbanging*
You know, sex, drugs and rock & scroll!

 

I am guilty of this. Does this count as self-reporting?

 

I hope this is what you heard:

- One version of Unity only (with all Pro features) and it'll be 100% free. You can charge for Advanced Technical Support and other industry specific addons (industrial engineering, car-making, military...etc) for those who need it. Also remove the "always connected/3 days offline max" Editor bullshit.

- 2% to 4% royalties after $1m+ sales/income (not installs!). Sales/income should be self-reported by developers. We know that you're in a tricky financial situation (100% your management fault of course) and we're ready to help you on this.

- EULAs tied to specific versions (no retroactivity bullshit). If I release my game using Unity version xxx, I'm bound, forever, to the EULA for that version.

- Go back to your roots: Game dev. 100% focus on the Engine (porting to latest .NET) and the Editor (better reliability/perf). We don't need no AI, Ziva, 25 rendering pipelines, The Cloud™ (come on, did you really think you can beat AWS or Azure?) or other bullshit. Ah, also finish and release Gigaya (personally I don't need/care about Gigaya, but it'll show that you value game development again, and an internal end-to-end game can help improve the Engine/Editor, à la Fortnite/Unreal)

- Fire John.

 

The proposed 4% limit of revenue taken from installations is still a joke, it's not even the bare minumum of what needs to change.

• Guarantees to usage of previous TOS via the EULA of each LTS channel, as previously promised by the CEO himself.
• An announcement addressing the silent and shady removal of GitHub TOS tracking and immediate re-establishment of the repo.
• Unity Plus for smaller indies restored, this is just out of respect at this point, you shunned away every single smaller dev and hobbyist who felt their contributions mattered. You're not going to force anyone into the Pro tier by removing this, go find your notes from when you introduced this pricing tier in the first place, it just makes sense.
• Remove the "always online" requirement to the Unity Editor. Why does the editor need always-online DRM? Why shut out so many offline and privacy focused developers? This is a terrible change on so many levels, you gain very little from this change (besides whatever terrible developer tracking you probably have tucked away in your new EULA).

This is the bare minumum of what needs to change. Developer trust in your platform is at an all time low, your updates have been condescending (telling developer they have angst about the proposed changes is a special kind of tone deafness even coming from the current C suite) and any sort of goodwill you've accumulated over the last few years is dead.

Stop beating around the bush with these weak "clarifications". We understand exactly what the proposed changes mean, and you continue to tiptoe around the overarching actual issues with your proposed changes made last week.

I, like many, no longer have faith in Unity as a company, but I speak to developers regularly. It's time that you should too.

 

And what do you dream of at night?

 

Looking at that Bloomberg article, if this 4% cap and self reporting plan is real then that surely would mean it would be sales based and not install based. Even after all this I can't imagine they can be ignorant enough to maintain the "install" concept. They must know that developers/publishers have no way of knowing that number.

So if that's the plan then I assume it would be quarterly reporting (like Unreal) or monthly. Hopefully not monthly because I find it's hard to regularly have all platform sales analytics working at the same time. Microsoft's is regularly under maintenance whenever I want to check sales stats.

So essentially this would be very similar to Unreal's revenue share except being based on a common fixed price per game sale instead of a common fixed % of overall game revenue. For most non-mobile games that sell for a higher price than a few dollars, the % should be something lower than 4%.

Reporting sales figures will be a bit more of a headache than reporting revenue I suspect though because I generally find different stores expose revenue to you a lot more easily and cleanly than exact sales.

It also sounds like retrospective counting of installs (sales now?) won't happen, but it will still apply to existing games. So existing games would need to sell an additional 1 million copies (Pro/Enterprise) after Jan 1 2024 before any of this applies to them.

If they had gone with this approach out of the gate people would be far less angry. They didn't though, and I have a hard time believing many companies are going to trust them not to change the terms unfavourably going forward. It's also clear that most active Unity developers have started actively, to different degrees, evaluating alternative engines in an unprecedented way and are probably finding things outside don't look so bad.

Besides games that fit engines like GameMaker, I don't expect many serious companies that can't afford to speculate using engines outside of Unreal and Godot in the immediate future. Depending on what type of game you're making one of those is pretty valid and Godot will become increasingly more so very quickly I suspect.

 

That's gotta smart if you have lots and lots of unity stock...

 

Legal discussion about Unity's pricing scheme changes:

My main concern is Unity's attempt to apply new terms of service retroactively.

I think that's messed up.

Of particular interest to me is the discussion of the legal concept known as promissory estoppel at 11 minutes and 10 seconds:

QUESTION: Oh, there was an older copy of the TOS that was on GitHub that Unity took down. The older TOS had a provision in it that allowed you to use an older version of the contract that was current when you made your game and continue using that version. They've changed their contract now so that's no longer the case. Are they allowed to do that? Are they allowed to put a term that says the previous provision that allowed you to use the older version is no longer valid? They've also deleted the paper trail that ever indicated that provision was in there.

ANSWER: Because, as we've spoken about before, they do have the power to change the terms of service. They are allowed to change any part of it. Now, there might be a cause of action for a developer who chose Unity when that language was in the contract. They could make the argument to say, "Hey, I relied upon that language and they've now taken it out." The problem with that is, in California, that would be known as a promissory estoppel argument, which in contract law means if you make a promise to someone and they rely on that promise to make life choices, it seems unfair for you to just rip that promise away. However, the problem with making that argument is that it's not a contract argument; it's an equity argument. You are basically throwing yourself at the mercy of the court, saying, "What they've done is inequitable; please show me favor." I can't predict how that will go because judges react differently to different cases. It's just kind of the luck of the draw at that point.

promissory estoppel definition:

https://www.law.cornell.edu/wex/promissory_estoppel

Within contract law, promissory estoppel refers to the doctrine that a party may recover on the basis of a promise made when the party's reliance on that promise was reasonable, and the party attempting to recover detrimentally relied on the promise.

Recognition

In Cohen v. Cowles Media Co. 501 US 663 (1991), the Supreme Court recognized promissory estoppel as a "state law doctrine creating legal obligations never explicitly assumed by the parties that are enforceable."

Consequences

An agreement made by promissory estoppel will typically have the same binding effects on parties that a valid contract would. If a party breaches an obligation created by promissory estoppel, a court can choose to assign either reliance damages or expectation damages.

--

Here's what developers would need to prove:

1. Unity promised something they expected developers to rely on.
2. Developers believed Unity and acted based on that promise.
3. Unity broke their promise, and the developers lost money or something valuable because of it.

https://www.investopedia.com/terms/p/promissory_estoppel.asp

 

If you absolutely can't argue anything, but being personal, you might be better off if you sign off and just not participate. Seriously.

Trust me, no one will look down on you if you remain with Unity. I still think it is a great technology and an absolutely usable engine. I just like it. If you aren't bothered by the shenanigans the management presents and trying to F*** over everyone, then you don't need to be worried, you'll be fine.

 

Leadership desperately needs to make the unworkable work, because they see (correctly) that any other path means those of them unable to somehow absolve themselves of blame (almost impossible for the higher ups) will find their heads on spikes, if not immediately then eventually.

Here's my prediction: After enough attempts to placate customers predictably and inevitably fail, they will try to win us over by dangling the removal of the splash screen in front of us. Besides a reversion, this is the one concession that has any hope of gaining traction in the short term. In the long term, Unity is still doomed unless they can convince partners they have divested themselves of the responsible parties who now represent an unacceptable liability to the industry.

 

Even if they DID revert, so what? Now we know what they're after and what they're willing to do for an extra buck, including going back on their previous word.
They could easily revert these changes, go back to the drawing board, and surprise us again a year down the line with another stupid monetization scheme. Going back simply to how things were is now not enough. They need to put in new and irreversible guarantees in place.

 

No such thing. They already had those "guarantees". It's really almost impossible to trust them.

 

Reading what you all have to say about your engine and the love-hate-relationship with it is eerily similar to the C++ build ecosystem, including the fragmentation of tools.

 

ChatGPT made better Policy Apology then Unity

https://chat.openai.com/share/5cd11640-f480-4d7b-9208-c21fffa6ee2d

 

I hope there are more people that understand this than there are that don't.

 

I'm reading more about this and I wish unity would address US directly, the community that makes this engine POSSIBLE. Triangulating through Bloomberg is still a weak ass move

 

Now that would make perfect sense indeed and be much better than Unreal.

But is this report real ? Is there anything official on it ?

 

The only way if they state that they are doing that again, versioning all the EULAs and keep tracking them in a 3rd-party place, like github. And they prompt you EVERY time you install an editor with the ACTUAL EULA you will be bind by.

 

Regaining trust is very difficult. We need dialogue, guarantees, manifestations of good intentions and concrete actions in this direction.
But let there be the possibility of forgiveness. We should not go into harsh refusal.

 

including a diff view

 

Oh well you should go as harsh as you can without sticking your neck out if you have any self-worth.

 

If they seriously go with this 4% crap and then put the burden of proof even more on us, Unity can go F*** themselves. honestly I'd have some respect back if they say ok we are wrong, sorry, let's not do any of this

It's simple: NO. RUNTIME. FEE.

 

Looks perfectly normal. If you don't understand this you probably shouldn't touch physics components.

 

Whatever they do, they can still work to incrementally undo, over time, as the camel sneaks its nose under the tent. First they prompt you with minor changes that weaken things ever so slightly. Eventually, they stop prompting you altogether. Somewhere down the line, they stab you in the back again.

What are we expected to do here? Forever look over our backs and and comb through every TOS change with a lawyer? And when Unity does start inching towards betrayal again, when do we finally say "enough"? The first inch? The second?

No, it's far less of a liability to take the business elsewhere. The only way to begin to work towards reestablishing trust requires leadership that we can trust, and that will never be these people.

You don't do business with people who have irrevocably broken your trust, period.

 

4% after a million if to look at the Bloomberg article and shutdown Runtime Fee . This is a move in the right direction, in my opinion. Not enough, of course.

 

They should definitely do this! Paying thousands just to remove a splash screen is stupid at this point. Especially since they are pretty much forcing you into paid seats if you make any decent revenue.

 

Yeah, I'll take it, and then I'll stop using Unity anyway.

 

Is this a bit? I can't tell if you're doing a bit here but lol.

 

If you don't know what is the problem with that maybe you should stay silent and don't try to be personal with other people? You're now a happy member of my ignore list. Good day to you.

Yes, I'm a shill, read back my posts here... it's 8bit.

 

You can decompile C# code in seconds, reconstructing the source. Good luck doing that with C++. There's IL2CPP, but you lose some features of C#.

The speed difference is real as well. C# relies too much on GC, in situation where you need massive amount of dynamic allocations, you have no tools, because deterministic object life time is not a thing. C++ gives direct to metal ability to implement your own memory manager. There's a reason why physics engines are not normally written in C#.

 

yeah some dont have the option right now because of the dev circle.

but we are still on the "editor" tos legally - most of us. and there will be lawsuits because of it.
Its not that they changed their TOS, they could do that. Its that they pretended that people could stay on their TOS by adding a weird clause in kinda the wrong place, but using the same name "Terms of Service". Communicated it like that. Made everyone believe that we have that security. Snuck in one weird clause. And then stabbed everyone in the back. Its so F***ing gangster from them. Like literally gangster and absolutley shameless.

When their CEO speaks or when anyone defends him, people should remind them of that. Unity seems to be a company lead by gangsters.

...

yeah lol F*** i spend 5 years on that game. just want to finish it and then write a unity to godot code converter.

 

There is no confusion, we understand what you are trying to do.

 

In C++ when you need to optimize code that's reliant on dynamic alocation, you are still forced to redesign the software architecture to improve that. The bare metal functionality isn't an automatism. So is there really a difference to C#?
I mean yes, you do not have control over when an object is released, but you do have the same control over what and when something alocates, allowing you to design accordingly.

C# is slower, but not because of memory allocations, I'd say, but because it's not a fully compiled language and needs a runtime. It still provides you with Reflection which C++ by principle can't.

Interestingly enough, think in Unity much of physics are written in jobified and burstcompiled C#. Admittedly that is "cheating"

 

Even as an outsider I lost count how many times they told you a) and did b) over the last few years. If you think it's different this time, sure, I'd agree.

 

Modern game engines use a variety of memory allocators, some even use a form of mark-and-sweep garbage collection but that's mostly reserved for scene objects. You'd have to know which to use but that's not a very hard skill to learn, and lots of modern code bases are setup in a way where you don't have to explicitly free everything except for some limited use cases that often pop up in engine/systems level code.

Maybe in the DOTS stack? Absolutely not in the normal stack that's in production, though.

 

That security bit was about C++ developers insisting on shooting themselves in the foot with naked pointers instead of managed ones that give you garbage collection without noticable performance loss in most cases - for the better part of maybe 20 years.

 

If you put in the work you are at least talking 10x without cheating. Its just nonsense to do so in gaming because it's more than 10x effort. e: for the developer, not library maintainer - they probably have to do that

e2: cache locality is easily achievable and this brings most performance. I don't know how you would achieve that in the average engine or language if it does not do that for you.
e3: just in case someone does C++, please try: https://github.com/skypjack/entt
e4: https://en.cppreference.com/w/cpp/experimental/reflect C++ today is not c++98

 

This is only true for either ads-based F2P (Unity Ads Fee Waiver) or premium game model. (Less than 5%)
Games based on micro-transactions (Low ARPU) are charged way worse than 5%.

Duplicate this calculator and play around with the numbers yourself. (Sometimes it goes up to 9 - 17%)
Even if it doesn't bother your game, it limits and affects some business models greatly.
You can imagine F2P model like League of Legends or OW2 is no longer viable in this setup.

Either way, a lot of us don't mind supporting Unity for a lot we've owed them for the better good.
But charging fee per-install is just not the right metric to use.

They already require you to have revenue above 200k-1m as one of their requirements for the fee, what's preventing them from using it as a metric?

 

In terms of performance, that's a blessing and a curse. More overhead, but also more room for architecture specific optimization. I'm not up to date on the exact cost-benefit of modern .NET, though I believe the cost is still generally higher.

Memory is definitely the biggest issue for performance generally, but that depends a lot on how you write your C# code and how successful you can be in avoiding allocations, locality, etc. Extremely optimized, unsafe C# code can get really close to C++ a lot of the time.

 

And I’m not sure of anything too,
but, say, a clear plan for the development strategy (with an emphasis on the development of the game part of the engine) for several years ahead would be something new.
Management has ruined the plans for the future of many of us and a clear plan would at least be something reassuring.

Or something like that.

 

Technically 1/2 of physics was written in C#: Physics2D and Unity Physics was written in C#, Nvidia PhysX and Havok was written in C++.

 

I love how Unity wants to retroactively enforce a ToS with a missing clause that protected us,
silently removed the Github repo that tracked those changes,
and are blaming this situation on miscommunication and confusion, lol.

 

So, it seems everyone is fractioning off to different engines...its sad to see such a big community, all fall apart, so quickly! It is great however to see that we as developers CAN come together and fight the system.
At least no longer will there ever be a fight on Facebook/Twitter again about "which engine is better, UE or Unity".
I at least will be switching over to UE. See some of you guys there
R.I.P Unity and your "IDIOT" CEO.

 

Eh, it's very taxing hanging here in limbo.
- if I open Unity to work on stuff I feel bad because I should investigate where do I migrate
- if I investigate stuff where should I migrate I feel bad I do not progress and deadlines aren't staying away forever

 

"HPC#" isn't quite the same thing as normal C# though.

 

Amen. I tried to call them out on twitter last night for claiming they "talked to" the "community" when there have been nothing but crickets and us yappy dogs here, but it went nowhere.

 

Just the usable part of it.

 

Instead of just doing research investigation, I recommend trying to make a simple game in a couple days, game jam scale, to try and figure out what personal pain points are in the engine and do that while researching. It helps make it feel a lot less unproductive.

 

If you talk about vanilla C++ code yes. You won't see rear lights of optimized, unsafe C++