Runtime Fee - WebGL in a WebView inside a parent app

Hello! How does the runtime fee apply in this situation?

We sometimes develop apps for clients that are built using WebGL, and they end up in a parent app “container” that serves the Unity WebGL. The parent app container itself generates ad revenue and gets sponsorship funding. How does that work with this new runtime fee. If the specific WebGL we built doesn’t go over 1mil engagements within this parent app, does it not apply? If it does, and the game itself didn’t actually earn any revenue, but the parent app does, how is that calculated?

Thanks!

I was wondering the same thing.

The fact that we have to ask such questions is just ridiculous.

In general, it doesn’t matter that the revenue is coming from the ‘container’ rather than the game itself. If the revenue is only being made because the game is there - i.e. without the game, people wouldn’t be coming to the page, seeing the ads, you wouldn’t be getting the sponsorship deals, etc - then we consider that revenue attributable to the game. (In some situations, like if the sponsorship deal is across the whole site, how to attribute the revenue for that is a little more complicated; for those situations I’d advise to reach out to the sales team so that you can talk about the concrete details).

The Runtime Fee is charged on a per-game basis; if you are shipping to a web portal site with many hundreds of games, then we do not care about the total players or revenue raised by the site as a whole, we only care about the players (initial engagements) and revenue attributable to your game specifically. So the fee is only owed for your game once you’ve had 1 million players and your game has > $1mil of attributable revenue over the past 12 months.

1 Like

Yeah. What you are saying makes sense, but its still just extremely muddy waters and vague.
I think the issue here is not the runtime fee itself, but how vague the rules are when you get into situations like this, with money flying around everywhere. Its not so simple.

To be honest, if the runtime fee applies to WebGL then I would suggest moving away from Unity for any WebGL projects. Unity is already pretty poor at Web compared to almost every other web-first engine (such as Babylon.js, A-frame, etc) and you would get a lot of benefits from moving to those engines (as well as not having to deal with predatory pricing).

Babylon.js API is so similar to unity that you will find porting to it a breeze. The only thing you would lose is assetstore assets that are unity specific - but that’s the nature of relying on things like 3rd party add-ons, eventually they will either become unsupported or you will lose them.

1 Like

Max 2.5% of revenue from games that are making more than $1mil is “predatory pricing,” @MadeFromPolygons_1 ?

2 Likes
  • ~$2k per developer per year + 2.5% of revenue above 1 mil. For an engine where the developers openly admit that they can’t finish a simple right-click menu in a year time.
2 Likes

Honestly, the majority of the Unity 6 beta threads are great examples like the Inspector search that I was able to cobble together with GPT-4, or the keyboard layout in the shortcut remapping tool that isn’t showing up because they accidentally made the minimum size of the window 1 pixel too small in each direction.

https://discussions.unity.com/t/941857/20
https://discussions.unity.com/t/943703/9

The simple approach is to just pay the maximum of 2.5%.

I don’t know if it qualifies as “predatory pricing” but it’s definitely “double dipping” and in some industries (eg the financial industry as linked below) it’s considered an unethical practice and comes with fines.

https://www.investopedia.com/ask/answers/09/double-dipping.asp

4 Likes

The complicated aspect is more answering the question “2.5% of what?” though. This is not a problem specific to Unity, to be clear, and for many simple business models it’s pretty simple to answer, but in some other cases - when revenue is shared with other entities, etc - it’s more complicated. That’s why I suggest contacting the sales team, as they are the ones who are most familiar with the policies and how to apply them to the concrete details of your situation.

2 Likes

Applying a runtime fee to something that is deployed as WebGL is absolutely predatory pricing yes. It is absolutely ridiculous to apply this to web based deployments and I am sure deep down you understand that. An install is very different from accessing something on the web and should be treated as such.

And this is before we factor in the double dipping, which let’s be honest if you want to charge a share of revenue then that is the only price we should be paying, instead of paying for the right just to use the engine and then again when successful from it. Pick one or the other, until then yes its predatory regardless of how large or small the % you are taking is.

2 Likes

so is every webgl hit counted as an impression? I confess i havent followed the pricing debacle hugely closely, as i make £0 and unity gain money from me through asset store purchases to make up for lazyness or weakness, im not liable to pay costs, but, i thought webgl was dropped from the pricing scheme

The point is to count initial engagements, which in simple terms is “players you’ve reached with your Unity-powered game.” Raw hits on the page is kind of the worst-case estimate of that (you know it is not more than that) and in some deployment situations it might be the best you can do, but in other situations you may have more accurate data you can use, e.g. if an account signup is required in order to access your game then you can count the number of unique accounts that have accessed the game.

Surely you can see how this is ridiculously cumbersome on the developer end and poorly thought out on UT’s.

1 Like

In general I don’t think it is unreasonable to expect people with large, highly successful games to have some idea of “how many people are playing my game,” no. For situations where it really is difficult to figure that out, just treat it as a 2.5% revenue share and be done with it. Counting initial engagements only matters if you want to reduce the % further.

1 Like

In general I think it’s pretty unreasonable that this system is based not just on revenue but also impressions. “Average fee per initial engagement” is bizarre and cumbersome compared against a sliding scale based on revenue, something that no other company really seems to have trouble implementing and working with. This also adds on top of the fact that Unity is still expecting per-seat Pro licenses on top of everything.

This new licensing system is completely overwrought and the fact this thread exists at all shows that this is not nearly as clear as you’re presenting it as.

3 Likes

There was a large discussion thread about this when runtime fee was introduced for the first time. Even though there was backpedaling due to backlash, result was not exactly perfect. User has no reason to believe that magical install counting software is accurate. The scheme is convoluted and it is unclear why it exists when you could just use royalties.

Any system that counts installs or "impressions’ stinks. When user already paid once, adding extra mechanic to earn more if user earns “too much” also doesn’t smell right. Likewise people shouldn’t need to visit a page with a calculator to figure how much they’ll end up paying.

Also, overly complicated pricing gives impression that the seller is insincere and is trying to do something funny.

4 Likes

@superpig has good points about it not being cumbersome to track and not predatory. Devs making over $1m are already tracking this anyway.

@Ryiah has a good point about ethical double dipping. If the dev is already paying license fees for the engine, why are royalties also a thing? Unfortunately there’s lots of weird structures in software licensing that do things like this. Autodesk is notoriously unethical about forcing users into extremely uncomfortable situations that require them to pay or buy new things just to do what they are already doing.

Overall, there has been a lot of hype and everyone is generally unhappy about the idea of paying more money. Execution from Unity was undeniably terrible, so everyone is understandably upset. Does anyone here have first hand confirmation through actual data analysis that they will be severely handicapped due to this policy moving forward? I’m genuinely curious because the numbers do not seem that invasive.

2 Likes

My root-problem with this whole pricing-structure is this:

When Unity changed to subscription from sold units the saying was “this way we can provide frequent and predictable updates for everyone”.
When this new pricing came, simultaneously the “frequent and predictable upgrade” is also gone.

So Unity keeps subscription and backpedals on the yearly predictable release and double dipping when someone does something nice with the software they already paid for…

Not to mention introducing a new burden on the customers. Obviously everyone is looking forward to sell a million copy, but now it is a little bit sour if you made it with Unity, you just getting a new burden to deal with. Also it smells like the initial phase of a much worse price structure in the future, when the remaining userbase cooked enough with this, Unity will change it to a much worse regardless. I have no reason to think otherwise.

4 Likes

For me its either pay a license fee, or pay rev share. Paying both is just not how its done these days for game engines and that makes the entire thing unreasonable. I would be fine with paying either individually, but both is greedy. If unity want rev share they should migrate to doing revenue share exclusively.

I am also not happy with having to pay more when the engine has been in an absolutely appalling state for a long time now. I struggle to think of a year where it hasn’t been in shambles since pretty much the introduction of 2017 onwards. If things had been different up until now with packages not getting deprecated or abandoned all the time and users being unsure of what tech will still be available 6 months from now, lack of clear direction and focus, tons of poor acquisitions - this would not be a conversation that needed to be had. But this is not the case, instead we have had a decaying engine, a lack of focus and now increased pricing that double dips.

As for whether this affects anyone tangibly - have a conversation with publishers and see what they say. The change in pricing alongside the lack of trust that it brought on, has frayed things at all ends of the spectrum in regards to wanting to use unity and that goes for publishers too.

2 Likes

Specially when they can make most features to work 100% as intended :stuck_out_tongue: tbh that is my main concern with this system… I’m hoping they abandon this fee thing as they abandoned more important things like features in the past.

EDIT: i’m comparing unity’s pricing vs another game engine’s pricing and i’m just realizing that unity’s pro is like 2200$ USD / year O.O and i guess that is per seat (the other one is 1500/yr per seat, no runtime fee of course) that is imo kind of insane for this engine at this level + i’m not even taking into consideration the runtime fee. I’m bored of talking bad about unity but i’m really surprised right now