> <i>How does Unity estimate the Runtime Fee when I have not supplied data?</i><p>> While we always recommend you supply your own data, in the absence of that, we will use our own data from Unity services that you have agreed to integrate into your project, and readily available external data.<p>> <i>Does the Unity Runtime phone home by default?</i><p>> It does not, unless you have hardware stats enabled.<p>----<p>I'm not a gamedev nor have ever used Unity to develop something, but those two sections seem conflicting. Can anyone kindly explain how they have their "own data from Unity services" while the runtime does not phone home by default? Thanks!
So they rolled back the most abusive aspects of the new fees but are still going forward with some fees...<p>Seems like they win on the end.<p>Looks to me like the good old strategy of we'll start with a very high proposal then come back with a more watered down version thst people will accept as being more reasonnable than the initial terms. But they still get to charge more and seem reasonnable doing so.
I think the damage is already done. Going with a game engine is a long term commitment - investment in learning and assets etc.<p>Given clean slate would you really pick these guys for your new game? Knowing they’re keen to pull a fast one on you for profit and may well have a 2nd go at it.
I think if they had initially released this page there would have been very minimal outage. Not just the change in plans, but the language itself seems more thought out.<p>The question is whether or not they have damaged their user's trust to an irreparable degree.
> Are games distributed through subscription services, streaming services, or as WebGL applications, required to pay the Runtime Fee?<p>> Yes.<p>I guess that ends Pro or Enterprise users publishing web games or interactive content. It's also going to hurt GamePass publishers.
This and the apology post [1] are probably industry's (any industry's) first in how concise, to the point and with no bullshit they are.<p>Goes to show how deeply Unity screwed up that they couldn't even corporate speak their way out of this.<p>[1] <a href="https://blog.unity.com/news/open-letter-on-runtime-fee" rel="nofollow noreferrer">https://blog.unity.com/news/open-letter-on-runtime-fee</a>
I'm glad to see Unity finally choosing to play to its strengths here from an economic standpoint by offering rev share. It's an insurance business model, which a game engine is uniquely able to offer due to its horizontal reach.<p>There's big financial risk inherent in game development for which studios naturally would "pay" some sum to hedge against, in the format of trading away some upside in the success case for a lower cost in the failure case. In fact, risk aversion, which at least in aggregate often models much real world behavior, dictates that studios would be willing to pay generously, entering into a deal that yields negative EV in exchange for flattening the risk curve. On the other hand, underwriting the risk on Unity's part is basically risk-free because of its horizontal reach across studios. Because of the asymmetrical risk, there's considerable economic surplus to be captured in a way that leaves both parties better off.<p>Of course all of this only works out if Unity only sufficiently benefits from the big successes. To that end, while generous, the choice to let developers pay the lower of rev share vs. per-install fee seems perplexing to me. When customers can pick after they already know whether their game is successful, Unity fails to set up an effective insurance business and ultimately will lose out on the surplus. The winners will no longer automatically subsidize the losers, Unity may have to raise the costs of both deals to cover its operations, and this all just becomes a more convoluted price increase.