Oh boy. Anyone remember a decade ago when Adobe tried to charge a revshare for cross-compiled 3d engine code on Flash Player and it pushed everyone out of Flash development and to Unity?
Also, this continues my pet peeve of disguising bad news with neutral headlines. If they had made anything cheaper they would have put it in the headline. "Updates" means "price increases".
I don't understand, is this as absolutely insane as it seems? Am I reading this wrong? They're charging the game developer 20 cents every time a user installs the game? I must be missing something here.
You're telling me. I've been working on a Unity project for several years and now I'm on the verge of scrapping the whole thing and starting over in Godot because of these fucking MBA parasites. I should've known better than to trust a publicly traded company with anything ever.
Godot is reasonably better than Unity, especially with Godot 4 and onward. A bit of a learning curve, but that's the same with any engine. You can certainly prototype and ship more quickly with Godot than Unreal.
Then, a while later, a new plugin came out that's made by the community, which seems to address some of my concerns: https://www.youtube.com/watch?v=NwJEXOglBrQ (video by Gamefromscratch)
To me, it feels like Godot has a pretty nice future ahead of it. I'll probably stick with Unity for the time being, since I don't actually expect any of my small game projects to ever get big, so the change in pricing doesn't really affect me at the time. But in the future? Maybe I'll go back to Godot, even their C# support is getting much nicer now!
You need to meet minimums in terms of revenue and installs so for college students it’d be a success problem. It’s still going to put a load of people off because who needs the added worry and reporting involved!
College students don't have to, since they don't meet this criteria to be charged the monthly fee: "Those that have made $200,000 USD or more in the last 12 months AND have at least 200,000 lifetime game installs."
That said, wow. Charging a monthly fee on game installs is absolutely wild. The personal fee (for first world countries) is $0.20 / month. If you charged $10 for the game, you'd be losing money after only 50 months (around 4 years).
You’re reading it wrong the monthly bit refers to the reporting/billing period and volume discounts. So each month you pay for the installs past the thresholds that month.
They managed to create a price that inviabilizes both ads-for-playing (and the more devious variants, like pay-for-win and lottery) and upfront paid games. That's just amazing, and will probably become a case study somewhere after the company fails.
Surely that’s not right… it’s gotta be first install is 20 cents. 20 cents per install is egregious but a recurring license is financially unsustainable.
Maybe because it's paid monthly no matter what, as opposed to yearly plans?
> You will be invoiced monthly based on the month’s install data. Invoicing will be the same method as for your Unity plan subscriptions, though it will be monthly regardless of your Unity plan payment cycle.
I'm assuming that $0.20 is paid every time it's downloaded based on their wording, so that could introduce a new way to harm competitors. Buy their game and uninstall / reinstall on loop?
I can't believe that they're encouraging MORE Unity games to be riddled with ads. Isn't that the (admittedly unfair but true for the mobile market) stereotype?
Mobile users put up with even directly "pay to win" mechanics and blatant gacha bullshit. They seem unwilling or unable, for whatever reason, to even conceive of a different paradigm. "Mobile gaming", read mobile unregulated casinos where you can never withdraw, are the biggest and most profitable gaming sector.
Don't worry, companies like EA are looking at that market, licking their chops, and continue to try and push such concepts as gacha into what used to be perfectly fine video games, and plenty of consumers eat up any excuse just so they don't have to go a year without the exact same videogame as last year but worse.
Yes, but the developer has to have made $200k over the last 12 months and had 200k installs. So if you hit both minimums and have made $1/install, they'd like 20% of that. Unless you're in an emerging market, in which case it's 2%.
Is that insane? I'm not a game developer, but it seems like it's in the ballpark of what the app stores are charging, and with a structure that's actually enforceable at reasonable cost from Unity's perspective.
> it seems like it's in the ballpark of what the app stores are charging
But now that's on top of the app store fee. So, using your example and the "standard (aka 30%)" app store fee, after that 200k cliff, the game makes $0.50 for every $1 sale. That is going to drive people away from using Unity on mobile games imo. Who cares about a $0.20 fee for a $70 (rip $60) game, but for a $1 game where 30% of your rev is already gone... it changes the dynamics.
Maybe that's what they want though? Maybe they are trying to use this to angle as Unity is a "serious" engine now?
Yeah, the case that interest me is mobile games with a high install/revenue ratio. If I install a popular game, try it out for 3 minutes, and decide it's not for me, then am I costing some indie developer $0.20 even though there's no revenue?
My guess is that the answer there is in this bit: "Qualifying customers may be eligible for credits toward the Unity Runtime Fee based on the adoption of Unity services beyond the Editor, such as Unity Gaming Services or Unity LevelPlay mediation for mobile ad-supported games. This program enables deeper partnership with Unity to succeed across the entire game lifecycle. Please reach out to your account manager to learn more."
My guess is that as long as Unity is getting a slice of your ads, you don't have to worry about per-install fees. So this may be more about driving free-to-play mobile devs to use their ad services.
Depending on how the legalese is worded, we might also see the comeback of demo versions and paid versions. So the free version has lots of installs but zero revenue, and the $0.20 bite only comes out of things you're charging for.
> it seems like it's in the ballpark of what the app stores are charging
Are there any app stores that charge developers per install? It's only per-purchase/transaction, right? The principle behind that is you don't get charged except as part of a transaction where you're making money. If a user downloads your app for free or pirates it or doesn't make any transactions, you don't pay anything.
What Unity is saying that if I buy a new phone and re-download my apps, that should cost the developers money. That seems like a very different situation to me.
I get the concern, but app stores can do that because the money flows through them. Unity says they're shifting away from revenue shares, presumably because they can't track purchase revenue and are tired of having a bunch of small fights with people who have every incentive to hide revenue from them.
> presumably because they can't track purchase revenue
So tracking installs and distinguishing between pirated and legit copies, and fingerprinting consumer hardware, and dealing with malicious or troll installs is going to be something they're somehow better at?
I can't prove Unity's motivations, but I can quote directly from their article:
> Qualifying customers may be eligible for credits toward the Unity Runtime Fee based on the adoption of Unity services beyond the Editor, such as Unity Gaming Services or Unity LevelPlay mediation for mobile ad-supported games. This program enables deeper partnership with Unity to succeed across the entire game lifecycle. Please reach out to your account manager to learn more.
and I think it's reasonable to at least entertain that it's not enforcement trouble that's causing them to create this policy. Not for the least reason being that they still have a revenue requirement sitting in front of this policy, and they still need to engage in the exact same accounting and fights to figure out which companies have made $200,000 so they can start charging them per-install.
I have no inside knowledge and am not a game developer. So I'm just guessing here. But yes, I believe tracking installs, which have published app store numbers and are instrumentable by them, is much easier than tracking revenue.
Note that nobody here really cares about total precision. Especially not their major customers who have negotiating power and who end up paying $0.01 per install. They're going to miss x% of the installs and have y% of spurious extras, and whether or not this approach advantages one side or the other is going to depend on a lot of factors down in the noise. If there's a large enough error it's going to end up as one more factor in the conversation with the account rep I'm sure they'll be having anyway.
> they still need to engage in the exact same accounting and fights
No, I think these are very different fights. A rev share means that every month everybody has to have the fight about what the actual revenue numbers are. I expect the way this work is that Unity will be tracking every game and looking at their app store metrics. If in their opinion they think you're making enough money to be worth squeezing, they're going to have an account rep call you. And if you don't engage, eventually they bring in the lawyers. So it's a one-time pain versus a monthly pain. Then the fight's just about install numbers, which are published and which I'd guess they have the ability to check on via instrumentation.
I disagree, these requirements refresh regularly and are applied per-game (note, I'm not saying that Unity is charging per-month, I'm pointing out that if you make $200,000 one year and $180,000 the next year, you dip back under the threshold and don't have to pay.)
This is still going to be a continual fight. Sure, I buy that you save some effort for studios that are clearly over the threshold, but it sounds like you're primarily talking about smaller companies anyway, and (correct me if I'm wrong) I don't see how it would be harder for a company to say "last year our 5 games each only made $190,000, it was a slow year for us".
> They're going to miss x% of the installs and have y% of spurious extras, and whether or not this approach advantages one side or the other is going to depend on a lot of factors down in the noise. If there's a large enough error it's going to end up as one more factor in the conversation with the account rep I'm sure they'll be having anyway.
> Then the fight's just about install numbers, which are published and which I'd guess they have the ability to check on via instrumentation.
I don't think these statements agree with each other. In any situation where it's simple to check install numbers (ie, Steam) -- Steam will also be tracking revenue. Where sales numbers are hard to track would be across multiple storefronts where... I mean, installs are also going to be hard to track. Unless they're planning to require an Internet connection for installing GoG games and Itch games because those installs aren't otherwise tracked. But I feel like that's going to be an issue for users if they do. Tracking revenue on a platform like GoG should be significantly easier than tracking installs, GoG has very little infrastructure I'm aware of to track installs of DRM free games.
I'm not an accountant, I don't want to make a serious claim, I could be wrong about the complexity, but it sounds like there is still going to be fighting over what installs failed, what was and wasn't pirated, etc... is that fight easier to have than "how much revenue did you take in?" :shrug:
Also bear in mind that this is not "you cross the threshold and then pay us for all installs", it's "you cross the threshold and pay us for installs after that point." So it's not just enough to ask if a company is making $200,000. When did they hit $200,000 in the current calendar year? How many installs happened specifically after that point? You still have to have that conversation with the company's accountants and you still have to try and confirm dates. And you have to do that yearly, and if you're already going to companies yearly and working with their accountants per-game to figure out when exactly installs start costing money... I don't know, again I'm not an accountant. I see that as a similarly complicated problem. Maybe I'm wrong.
----
My take is that Unity isn't saying that this makes their accounting easier, they're saying that it's going to encourage more "deep collaboration" with developers who purchase additional services, and that it supports the "continued investment" of the runtime. I'm inclined to believe the motivations that they're saying publicly. I'm sure that if they're pressed they won't reject a framing of accounting/ease of use, but it strikes me that it's not the motivation they're leading with. But I can't read their mind.
their terms also not about game profits. Let's say in case if $300k spent on Ads to get 200k+ installs and as result you made only $200k back as in-apps payments Revenue from game (so your profit is loss of $100k+fees+taxes) then Unity will demand you to pay them $40k+ just to cover installs amount and you almost won't have control to stop new charges because even if you will shutdown a game then some installs continue to happen from various pirate sources or some small app stores.
It looks completely insane terms for lot of mobile games where monetization is huge challenge and difference between profitable game and company bankruptcy measured in cents per user.
The FAQ suggests that once you cross the install threshold, you keep paying. The thresholds are "lifetime"
>The Unity Runtime Fee will apply to this game, as it surpasses the $1M revenue and 1M lifetime install thresholds for Unity Pro. Let’s look at the game’s installs from the last month:
Prior month installs (Standard fee countries) - 200K
Prior month installs (Emerging market fee countries) - 100K
The fee for install activity is $23.5K USD, calculated as follows:
(100K x $0.15 (first tier for standard fee countries)) + (100K x $0.075 (second tier for standard fee countries)) + (100K x $0.01 (fee for emerging market countries)) = $23.5K USD
Wait, that can't be right, it would be ludicrous. Once a game passes the threshold it pays per-install permanently? That's so wildly horrible of a pricing model that I just have to assume that's not what they intend, even a completely out-of-touch exec should be able to see the problems with that.
Have a game that's profitable enough to pass the threshold and then interest drops off? You're suddenly incentivized to completely take it off of the market and remove the game from people's libraries since you'll keep racking up fees from installs even if no one ever buys another copy.
I'm not denying that the quote does seem to imply what you're saying, but I have to believe that's a misprint or bad writing on their part, the implications of the threshold being lifetime sales are so bad. The policy is bad, but there's no way Unity is that comically out of touch, is there?
> Wait, that can't be right, it would be ludicrous. Once a game passes the threshold it pays per-install permanently?
Yes and no. You need to meet _both_ thresholds, cumulative (lifetime) installs _and_ yearly(!) revenue. I (!)'d the yearly part there, because you still need to be pulling in a yearly $1M of revenue (I'm assuming Unity Pro here cause the math is simpler) after your 1M of installs.
So while there are some edge cases here that are legitimately ludicrous, it's not the case that you're on the hook for the game in perpetuity, because if your game falls off a cliff and you make $500k in revenue next year, you owe nothing in runtime fees. In other words, you're not incentivized to take it off the market after 1M installs unless the runtime fees made it so you started losing money on the game after your $1M of revenue-- there are some examples where this is possible but none of them are very realistic.
It's also not clear if its $1M in the previous 12 months, or in the past calendar year, or if they have any rights to audit us, or which financial entity is on the hook. Is in the entity that pays for Unity, or the Publisher, or the Distributor?
What about the contractors we pay to do a few months of work at the end and use their own licenses. What about the folks that do our PS5 and Xbox ports for us?
Unity attempted to clarify their position around Game Pass telling devs not to worry because Microsoft will pay, but that makes me more worried because MS will just pull those games. I think there are 25 million Game Pass subscribers, and that's a lot of 20c installs.
We were hoping for another stint in Game Pass as a follow up to Void Bastards.
> Unity says they're shifting away from revenue shares, presumably because they can't track purchase revenue and are tired of having a bunch of small fights with people who have every incentive to hide revenue from them.
So now they are charging developers for something users have an incentive to try to do without paying the developer.
I would not categorize an ad platform as an app store. Plenty of streaming services and content licensing models charge per-stream/impression as well, but I feel that's a pretty separate category.
I'd be open to more clarification if there's something I'm missing, but I still don't think this is comparable to app store fees.
Do stuff like DDoS attack services or botnets charge per-install instead of directly for usage or compute time? Honestly kinda predatory pricing if that's the case. Seems a little problematic.
are they only counting unique installs or do developers pay with any install? Like if i reimagined my machine and reinstall games does that mean they have to pay the install fee again?
EDIT: The more I read the FAQ, the more I think this is a bad deal
Ooh, good question. Does Unity phone home when a game is launched? If I were in Unity's shoes and trying to enforce this cheaply, I'd either have it phone home so I could keep track of how many active users a game has, or I'd just scrape data from the app stores to see who's worth having a salesperson call up.
I was looking at that table, which otherwise made great sense, but struggling to understand why Unity Pro and Unity Enterprise had cheaper per-install prices than Unity Personal. Part of the answer is that they charge up-front monthly fees to use it:
So I see $2040 per year per seat for Unity Pro. That doesn't quite explain why the per-install costs decline with volume for Pro/Enterprise licensees, but I suspect that's just that the Pro/Enterprise are more sophisticated and have better negotiating power.
Presumably the Pro/Enterprise subscribers are more likely to reach the thresholds as well so get charged for installs and it’s a carrot to get people to upgrade if you expect volume.
Unity is a tragedy. They have managed to fumble the technical aspects so much it drove people away, to the point they become more valuable as part of an ad business than an engine one. Their efforts outside the games industry don't appear to have as much traction as they deserve either.
The question has already been "Why aren't you using Unreal?" and that's just going to get harder.
Given the current VC taste for eliminating all things which count against gross margins now might be a good time to be an engine developer again.
C++. Sure, we can talk about Verse or even Skookum, but C# is much easier. Still, if any big game engine would have something like JS it would be even better for indie or small studios.
Unreal C++ is so heavily modded that it often doesn't really feel like C++. Like I feel kind of odd the rare times I use std:: anything. And Unreal C++ tends to be garbage controlled, support reflection, and so on. The only real big downsides are you have C++ compile times and generally poor intellisense - though IDEs that specialize in Unreal, like Rider, have seen exponential improvements on that front. And for teams that are genuinely averse to C++, going 100% Blueprint is also a completely viable option.
For people scared off by C++ and who want faster recompile times, check out the Nim bindings [0]. Check out his Twitter/X account [1] for plenty of cool things it brings to the table.
Probably not very good on a team, yeah. I actually have a bit of a toy game engine for the browser/ThreeJS targeted at making games similar to the Windows 95 screensaver. Learned some good things like GLSL and shaders but working in JS was definitely a bit of a slowdown when I'd hit classes of bugs that wouldn't be possible in C#, even with annotations helping me. But other times it was convenient being able to pass stuff around without writing up classes or structs for them as you alluded to.
It's a fun experiment in seeing what JS can do, it's cool having it run natively on the web, and annotations get you a lot of the way there, but in a context like Unity I'd never pick it over C#. Typescript might be alright but at that point why bother? C# has anonymous types, tuples, and such today too.
Because it was not JS, it was UnityScript which is what happens when someone read "JavaScript: The Good Parts", and thought the title was "... The Bad Parts" and threw all those away and kept only the actual bad parts.
It was just about fine if you were doing very small projects but quickly got very hairy, and their compiler was full of bugs.
And to contrast, Godot's GDScript has been great for me so far. I've been hacking at a personal project for a couple of days now and I feel right at home in the language, which feels right at home in the engine.
The name of the game is iteration speed. (I always think of Paul Grahams story about beating out the competition using Lisp.)
I've been working with UE since 2014, originally started in UE4 C++ and avoided blueprints and kept everything in C++. Was great 'for performance' and code diffs but now 10 years later I'm 99% blueprint and only go down to C++ if the performance requires it for the 1% of hot paths. My iteration time in UE using blueprints makes me shutter to think of all the time I spent waiting for C++ to compile.
Blueprints are fun to work with, but the amount of time it takes to drag and drop nodes around to make the equivalent of a for loop feels incredibly unproductive. The result does look visually pleasing though!
I just started using Unreal 5 to prototype a VR game (lots of quirks but this engine is amazing). I’ve been writing C++ for 5ish years now and am pretty comfortable with it. I’ve also been slowly converting all the blueprints in the VR template provided by Unreal to C++ for a few reasons and was curious if these effect you.
I tried using blueprints for awhile, but it just feels so cumbersome and time consuming. I can bang out 10 lines of code basically as fast as I can think, but converting those same 10 lines of code to blueprints often involves much more time. You have to click around a bunch, rearrange the routing wires, make it look readable, abstract a lot of stuff into functions that usually don’t need it just because it helps condense the blueprints. Then the blueprints end up sprawling a large area and are very difficult to keep in my head at once (whereas it would normally take less than a page of C++ code to write it out and you can easily hold that in your head).
Basically, I was wondering if these downsides to blueprints effect you much or if you’ve developed suitable workarounds? I want to like blueprints, but the time it takes to click around and make it readable is painful, in my opinion, more painful than compile times for the C++.
Yea its unfair to taught Blueprints as the answer when they have a serious learning curve.
It took me a while to build up enough experience where I could become more expressive with Blueprints than C++. The Lyra example has some good Blueprint hygiene worth reviewing where they organize all variables underneath a function call.. but until you have serious experience with Blueprints they are going to feel like a cumbersome mess.
My advice is to do what you feel most expressive with, doing the thing you enjoy more will lead to more hours of experience. Start with C++ and build up a good understanding/mental model of the engine and then eventually give Blueprints a try in a few more years and you will see them in a new light.
I’ll have to check out the Lyra example! But yea, C++ definitely feels more comfortable for me at the moment. I’ll try blueprints again in a few years :)
How big is your team? How do you code review? How do you unit test? How are you maintaining 3 year old blueprints?
This will work just fine for small indie games and teams where the code is thrown out after a year, but there's no scaling this. I've worked with enough 10 year old Max/MSP patches to know that you will have an unmaintainable mess of wires that is as good as garbage after a while.
Larger teams typically use Blueprints to prototype but then rewrite in C++. This is a perfectly fine use case, but ultimately you still need it "written down" for the maintainability.
tl;dr Blueprints are a tool in the process to writing C++, they aren't a replacement.
I really hate BP and wish we get something better. The thing is, technically you are supposed to do gameplay in BP and push the core ones to C++, but BP is so messy after a short while.
It really isn't the lack of mobile support, as Fortnite shows, it is the fact Unity devs are cheaper and iteration speed from code changes is faster, which in hypercasual type stuff proves to be essential.
I tend to think the dev iteration speed is the core Unreal weakness.
The problem Unity have created is if something can be made with Unity it will get crowded out with clones in five minutes.
I did an evaluation earlier this year between the two. We needed the 3d engine but also needed native phone features. Meaning some screens of the app would be Unreal/Unity and some would be native iOS.
We couldn't even get Unreal to build as an embeddable library for a mobile app nor could we get it to build into anything that would run in a web browser despite more than a week of effort.
We had Unity working for both use cases in under a day.
The idea that developer iteration speed is actually an indicator of project-completion-at-scale speed is really only true at a trivial scale; you know, when you only have developers. Maybe a handful of them. ..and like, one does-everything artist.
When you have multiple different teams including non developers working on actually building a significant game, crafting levels, assets, etc. the iteration speed of your handful of devs is really really a drop in the ocean.
There are a lot of very powerful tools in unreal for teams, and they have consistently invested in tooling (eg. File per actor) and real life production needs (eg. LED stage support) with their customers.
Unity has invested in different areas, with a lot of effort, and bluntly, nothing to show for it.
You seem to suggest this means it doesn't really matter? I run a startup with 4 employees (only 2 of us are developers). I care about stuff in this "trivial scale" and a lot of other developers are like me.
> The problem Unity have created is if something can be made with Unity it will get crowded out with clones in five minutes.
This really has nothing to do with Unity. Flappy Bird could have been built on any platform and you would still have a million clones of it. Because it takes a day to make it. It's just as easy to clone that game in Unreal Engine, fwiw.
Unity didn't create the concept of the quickly built game, nor is Unity responsible for society incentivizing this type of game dev. If anything, the new runtime fees will disincentivize this type of game, so maybe that's a good thing?
Compared to unity, yes (especially for 2D stuff which is more the norm on those platforms).
Unity is already imho pretty bloated but at least useable and a sensible choice for both, Unreal is just too massive and more suited for console 3D type of games.
My last comment there is a hint that might happen, as this shifts the calculus enough that for big casual players hiring devs to work on godot makes more sense. However, those players will also get preferential treatment anyway.
But everyone will be waiting for Godot to have the first widespread hit before jumping in like that.
Godot is not really optimized for thousands of entities but they're getting there. Also, the tooling for consoles isn't there. I use Godot almost exclusively and its impressive what they've built.
Godot is a little behind Unity in terms of technical features. It's way behind Unreal.
I do a fair amount of Godot development - for casual mobile games, limited PC games, or games where you're planning on a publisher to fund your port, I think Godot is a good choice.
Do you have an example of a 3d godot game that you have played? Searching returns no games I've heard of, even including 2d.[0] Cf. unity and unreal. I've never played any godot games as I don't like 2d games. With the exception of 2d rpgs for which rpgmaker seems to be better.
>Unreal is just another vendor with a hand in your revenues.
I'm a game dev and Unreal is not a Unity replcement imo.. Making a game in Unity feels like making a game in XNA, you just start writing code and can write your entire game from scratch and can ignore most of Unity's features.
Unreal on the other hand feels like you are modding an existing game and you must use their many existing systems and patterns.
I'm moving to Godot, it feels like the new Unity / XNA.
In the past fews years, it feels like Unity had exactly one programmer for each important package like SRP/UI Toolkit and all the other employees were sales and PR.
The pricing is a bit weird. Their criteria is based on gross revenue of >=$200k. But instead of charging a percentage of that, they charge per install at a rate of $0.20/install.
So if you made $200k off of 1M installs, you’ll now pay $200k and your total profit will be zero.
I guess the assumption is that each install will earn you >>$0.20, but that’s a very generous assumption. What about a F2P game that has millions of installs but only a fraction support the game with microtransactions?
There’s definitely going to be some cases where studios will owe more money to Unity than their game makes.
I think you need to read the table again. If you have that volume you shouldn’t be on the most expensive per install plan. And if you’re on a higher plan you wouldn’t qualify for the per install pricing at all.
Before this change, there would be no reason to spend $2100/seat on Unity Pro. The Personal/Plus plans would be more than sufficient for indie devs.
You’re right, some studios are going to be forced to switch to the Pro plan to save on per install pricing. That just seems like a really frustrating forced upgrade.
'made 200,000' that doesn't meant that you able to get any profits from that, and it lot of cases with 200k revenue small game studios only loosing money
my understanding is that the $2100 removes the life time install part, and that it's only for games going forward so you'd be able to do the math up front. It definitely stinks, but unity needs to make money. It's this or forcing ads down your game's throat more or spyware
In your presumed case the studio would already be breaking Unity’s terms to be using Personal or Plus as companies making over $200,000 in the last 12 months need to have Pro subscriptions! Dunno how flouted that is though.
In fact, the Plus plan is being removed completely. It's only mentioned off-handedly in the last paragraph of the article, but it's another giant change for indie devs (who have no choice but to migrate from Plus to Pro).
They are offering a free upgrade from Plus to Pro for one year, but that does nothing once that time elapses - you have to pay the Pro fees or drop down to Personal, which is not viable for most games.
His point stands tho. Think about mobile games, where games are significantly cheaper (0.99€-5€). That install fee will hit a lot different than for high priced desktop titles (30€+). In addition think about the turnover in mobile games.
The Unity Page does not mention free games with micro transactions, but especially there the user turnover is way higher. A lot of people will install it, play it for a few minutes (or days) and remove it again. Will the developer pay those install fees too?
This entire thing seems not really thought out.
I am also wondering what about trolls, who spoof HWID (or whatever the unique install id is based of) and spam-install it
Except it doesn't. Selecting Unity as your game engine is a business decision and part of your business model. If you cannot make a profit in your game after the fee, it's not Unity's fault that you have a bad business model.
I once crapped out a game engine over a weekend using python. I called it turdPy.
I released it under a commercial license of $20000 per CPU thread per developer device per day to use. With an additional 80-20 revenue share model (80% going to me) once the devs sell their game.
I never got any customers, and I always wondered why. But now I understand that it was because game studios simply didn't have a good enough business model.
I would think it would be weird for a game engine business to try to curate what type of creative talent utilizes their game engine product. It would seem to me from monetizing installs that you'd want anybody and everybody using your game engine product to generate _anything_ to get installed one or more times by a consumer.
To make your case, I think it would be more relevant if Unity decided to charge game publishers extra for publishing games that were only installed for some short amount of time on a device before going uninstalled. That is not the case here.
Anyway, I see where your mind is at, but I think the conclusion you came to is not correct. I don't see what incentive Unity would have to keep low quality games off of their product, they actively would want them to succeed to hit the thresholds for monetization. And besides, everybody already knows to judge the tool based on its potential, rather than judge it based on some mediocre games that came out and flopped, because that happens with any engine.
> I am also wondering what about trolls, who spoof HWID (or whatever the unique install id is based of) and spam-install it
You don't even need to get that technical. It seems that using a privacy respecting browser that blocks cookies and fingerprinting techniques will identify a simple page refresh as an install.
They've been pushing hard recently to get people to use their ads platform, my bet is they're hoping to push "under-monetized" games to run a ton of ads in order to make any money. This kind of a pricing model forces games to think about ads and monetization from the beginning instead of building a large happy user base.
Yeah, there's like a small size studio, or studios where they plan to not have like a very strong monetization curve, where this makes sense.
This pricing change pressurizes modestly successful long tail profits. And so I think yes competitor game engines that are more progressive will be more popular for those segments.
"Once a game passes the revenue and install thresholds, the studio would pay a small flat fee for each install (see the table below)."
This was not clear to me at first based on their table which currently shows 1-1000 installs as falling into the $0.20, but it's in fact actually the installs AFTER passing the threshold I believe. So assuming it was installs, it would be install 200,001 - 201,000 that would be charged $0.20?
This cannot be right, how can this makes sense with mobile gaming? Unity has a HUGE market share there, so they know the number. How can free games ensure a 0.20$ per install? Why not go with X% of the revenue?
Unreal isn't being used to crank out low end mobile games that are purely ad sponsored... betting that there are more shenanagians going on in unity's space that would means it hard to actually check the books versus someone with 1M in revenue
It's a shame Unity seems so intent on making itself unattractive to developers. I prefer writing c# to c++, and I think Unity's onboarding experience is much better than Unreal. But when it comes to a non-solo-development effort, when you need to start thinking about businesses and numbers and all the things that aren't making the game, Epic has made Unreal attractive, and partnerships with the Epic Games Store can boost that value even further.
Unity's recent moves to me speak to a fear that they've more-or-less hit their market saturation point, and now they're looking to extract more from the developers who live in their slice of the pie. I fear this will make that slice shrink, which will create more fear, and then the problem spirals.
I think a lot of people find the learning curve of c++ fairly extreme, especially when considering the amount of knowledge to do idiomatic programming in c++ required to “do things elegantly.” C# and related languages tend to have idioms baked in closer to the syntax and grammar. My view of c++ after 30 years of it is it’s great if you’ve got 10 years experience programming it within a team of seasoned c++ programmers who shows you the ropes. Even then I think rust is the language I wished for all these years (albeit not for game dev yet). Finally, for the reasons rust isn’t great for game dev, c# and ilk generally have excellent reflective and dynamic natures making them sort of the sweatpants and old T-shirt language for game programming.
That said, it locks you into using stuff like mono and stuff for cross platform which makes me a sad.
The new versions of C# can compile ahead-of-time, and have expanding support for value types and pointer-like semantics, so you're not stuck with the Java-y OOP For Everything paradigm if it doesn't fit your requirements.
The standard libraries are still an allocation party, of course, but that can be supplemented in an engine context.
Citation needed? Raw speed is likely similar; the cost overhead comes from GC cycles and the general approach to managing memory primarily in the heap vs stack, although C# can stackalloc if you're really diligent. Note that this is the same problem that blazing fast alternatives like Go have at competing with C/C++. These languages are mostly equivalent to C/C++ in speed, but lose the benchmark shootouts because of GC.
Calling Go blazing fast would be a stretch at best...the path to performance in C# is same as in Rust or C++: struct generics (aka templates), as short hot paths as possible, static partitioning of the work, sometimes hands on memory management and minimization of locking.
This is a pretty wild generalization to make. It's not hard to contrive scenarios where C++ with its notoriously slow stdlib (despised by game developers) is going to be slower than C# with its JIT doing runtime optimizations like guarded devirtualization.
C++ written by people who really good at writing fast C++ is faster than C#. Naive and readable C++ written by average programmers wanting to solve a problem in the obvious way on the whole isn't faster than C#
Better is relative. And it's just a different type of tool. To be honest I know many more better engineers who primarily work with dotnet over CPP. The learning curve for CPP is higher because the ability to shoot yourself in the foot with CPP is higher. It's neither better or worse. Just a different tool in a toolbox.
Keep in mind that in addition to the "learning curve" arguments, there is also the functional developer ergonomics of things like live reload (where you can maintain memory state) that are simply not possible to do with C++ without heavy limitations or customized tooling.
Being able to fix a bug without resetting memory state is a huge ergonomic advantage in game development where generating the right memory state can be incredibly complex and depend on a ton of very specific and hard-to-reproduce factors. Not to mention recompiling and restarting a game can be incredibly slow.
Yes, but it has many known limitations and isn't nearly as reliable as a runtime that has a full GC and virtualization optionality, which you really need in order to fully track what state can be evicted and what needs to stay.
Game devs want fast iterations above everything else, with performance being a close second. c++'s "toolchain" makes those iterations prohibitively impossible, even with decades of workarounds with hot reloading and extravagant methods to keep compilation times down.
If you're a AAA dev you give up a lot of that iteration because performance overtakes you, but there's little reason some indie 2d platformer will want to deal with even 30 second iteration times (which would be blazing quick for a AAA setup). C# is a mature, familiar environment for devs with similar syntax to C++ that can get decent performance as long as you maintain some discipline (for starters, no LINQ)
There was also Mono UE [0] - which was being developed by some of the Xamarin folks.
I’ve not played around with any game development for a long while - does C# end up popular here just because people are familiar with Unity? I definitely get that C++ is not the most productive language - though improving perhaps.
Simply loading the .NET Core CLR is not difficult [1] - but unless things have changed since I last tried binding C++ interfaces to C# is time consuming, especially if you want to be able to implement an interface in managed code.
Part of C#'s popularity with indies is due to the legacy of XNA. Thousands, probably tens or even hundreds of thousands of indies got started with XNA and released games using it, so it's natural to stay on C# whether you move to FNA, MonoGame, Unity or Godot
S&box is still in progress and using C# but it is now using the Source 2 engine instead. You can actually get invoted to it on Steam and play/build games for it now too.
It previously used UE4 and C# integration was all working with that but, as soon as they found out that they could get access to Source 2, they took the opportunity. Makes sense because the team is significantly more experienced with the Source engine since most of them have previously worked on or with Garry's Mod.
I don't mind C++, but can you delete the script file without closing the editor yet? It was such a turn off for me at the time that I abandoned all intentions of ever learning to use Unreal Engine.
Honestly, Unreal C++ isn’t that bad or hardcore. It’s fairly high level, and Unreal APIs are pretty well designed. You spend way more time dealing with Unreal specific stuff and your game objects than dealing with C++ issues.
I don't think that's true, and I don't think the juice would be worth the squeeze. Unreal's flavour of C++ is heavily managed, relying on preprocessing of header files to create garbage collecting pointers and a whole heap of other things you don't think you're signing up for when you think about a C++ codebase. There is no simple place to begin if you're trying to make it C# friendly.
But most of my issues have been with engine philosophy, where Unreal has bent over backwards to expose things to their visual scripting language. It feels like every single feature has a mandate to work in a blueprint tech demo, and as a result few of them are pleasant to code against and almost none of them work together coherently. These are not issues that depend on the language used.
C# being the deciding factor an incredibly common refrain in game development "what engine do you/should I use?"
Whether or not it's justified is another manner. I haven't personally dealt with the modern Unreal Engine but natively supporting C# would, at the very least, make people a lot more likely to switch over.
I was surprised that Unreal Engine didn't just translate Blueprint directly into C++ code. They already have a text-based version of Blueprint. You can see it when you copy a blueprint graph and paste it into a text file (or at least you could when UE4 launched).
Disagree. Unity is pretty strong on mobile and multi-plattform. Enough to survive on this alone (imo). I also think Blueprints is already a strong competitor for the share of users who find C++ too complicated (non-programers and people who have only dabbled in scripting). I think for "traditional programers" the difference between C++ and C# isn't big enough to make a difference and frankly people with a gamedev background probably prefer C++.
That being said as a non mobile guy who occasionally dabbles in engine stuff I'll be migrating to Unreal for good now. I haven't been a paying customer for a while now but I used to pay for Unity back in the super early days of AR.
Mobile is the kind of use case where the pricing changes will be massively impactful though. If you're selling a non-mobile game for $10+ then you can just eat the per-install fee, but if you're shipping a free to play app or a $1 app? The per install fee could make your business model nonviable.
I mean, knowing c++ and c#, I am always terrified about the former. There is an enormous set of things that shouldn't be touched and a whole set of gotchas in managing headers, writing macros, templates.
Granted none of the two are used at my day to day job.
There was C# support for Unreal (contributed by the Mono maintainers) at one point but Epic actively blocked it. They want everyone on C++ and nothing else
the megagrant appears to have happened in 2020, the blocking of unreal C# happened years and years prior and put an end to development (community and otherwise) at the time (pre-2017, I don't know the exact date)
The problem is that Unity has a lot of customers that make freemium/ad supported/low cost (mobile) games. $0.20 per install is absurd when most players are gone after less than an hour of playtime.
Of course if you sell games at $60 a piece it is not a whole lot, and the regular seat pricing of Unity is most likely a far greater expense.
This does look pretty bad for hyper-casual and casual Unity devs. The total earning per install could easily drop into the negative and even with the $200k revenue buffer, it'd be easy to end up with almost nothing. I imagine these folks will just shut their game down around the $200k mark if they see their LTV hovering at or below $0.20.
Wouldn't upgrading to Pro be a better option? Yearly subscription for a seat seems to be worth about 10k $0.2.
Also you're cost per install is almost certainly going to be significantly below $0.2 because every install outside of:
"United States, Australia, Austria, Belgium, Canada, Denmark, Finland, France, Germany, Ireland, Japan, Netherlands, New Zealand, Norway, Sweden, Switzerland, South Korea, and the United Kingdom" (I wonder how did they create this list, e.g. Spain and Italy seem to have a comparable or even higher cost-per-click than Sweden , Austria, Finland etc.)
You're right, upgrading to pro would be better at $2k/seat/yr which gets you a much larger million dollar buffer. Also, I'm noticing that the revenue thresholds seem to be per-game not per org - so actually, the new pricing isn't that bad!
Yeah, it almost seems to me that the $0.20 is there to force to encourage plus subscribers to Pro.
Which probably was a poor choice marketing wise since most people will just see a single number and not pay much attention at anything else.
Also it's only $0.2 fore a specific list of countries (US, CAN, AU, NZ, JP, SK and some richer EU countries). Everywhere else it's $0.02
I don't personally like this whole business model that much, but financially it seems to be pretty reasonable (I guess as long as you can somewhat predict your expected install count in advance which might not be that easy in some cases).
It does seem reasonable as an incentive for successful studios to switch to pro. However the issue is not purely with the price only.
The issue is the fact that the wording is unclear. Also a price per install seems like a bad target overall. How is it reported? Now they are saying that there are exceptions like gamepass installs. It is going to be a mess.
Also the change is retroactive. Imagine a vendor announcing that starting January 2024 you will have to give them a piece of your cake. Even if the piece is small, you are still going to contact your layers, and you will loose trust with this particular vendor.
> The issue is the fact that the wording is unclear. Also a price per install seems like a bad target overall. How is it reported? Now they are saying that there are exceptions like gamepass installs. It is going to be a mess.
Oh yeah, I 100% agree with this. On the very basic level I just hate the concept of a third party tracking and counting every user I have without my (or the actual user's consent). Not every game/app made with Unity is distributed on the App Store/Steam/etc. and there are plenty of other reasons why I wouldn't want to share that data with anyone (or even collect it).
Looking at their per install pricing if you have large number of users but very low revenue per user it would certainly make sense to upgrade to Pro where you would only pay ~$2k for each seat as long as you make less than 1 million per year. Which doesen't seem that unreasonable.
It's not necessarily about the pricing. It's how the pricing is determined. 5% of revenue is concrete. You can make a business plan and plan for the future based on that. With Unity's new pricing structure, it's impossible.
This isn't really a solid argument since stockholder investment isn't even "money"; it's collateral in the form of market valuation against which Unity borrows. The actual "money" (dollars in a bank account) comes from lenders who look at a bunch of factors and make determinations about how much $$$ to give. That money isn't free, but it's got very little to do with "the shareholders" in general.
> it's got very little to do with "the shareholders" in general.
no it's got everything to do with shareholders, because ultimately, the money the shareholders invested into the company will need to be recouped by the shareholders, by any method they can.
And in a cut throat business of game engines, unity is trying to squeeze out every bit of juice it can. It still has some advantages over godot atm (such as big install base, and a pre-existing network/momentum which is hard to dissipate), and my guess is that unity is trying to get revenue up before godot takes their lunch in a few more years.
How is Unreal's mobile gaming situation? I haven't worked in mobile game development for a few years, but at least through the 2010s, Unity was an undisputed king of free-to-play mobile games for studios who weren't rich enough to develop their own engines.
Unreal has limited traction on mobile, which is now >50% of the gaming market. It's likely one of the reasons Unity thinks they can get away with this. The last number I saw had Unity above 50% share with Unreal under 15%.
It's difficult to champion high end features for your engine but keep it suitable for low end smart phones. Epic made a good attempt to win mobile devs back in the Infinity Blade days, but given their recent focus (not to mention lawsuits against Apple and Google), it seems they intentionally decided to deprioritize mobile and focus on PC and console.
I have an open world game I have to make run in 1.3GB of RAM for my min spec. I just can’t see a world where I could do it in Unreal. And unity knows that and is trying to get away with murder.
> Unity's recent moves to me speak to a fear that they've more-or-less hit their market saturation point, and now they're looking to extract more from the developers who live in their slice of the pie. I fear this will make that slice shrink, which will create more fear, and then the problem spirals.
Charging a monthly fee on game installs is absolutely wild, considering that most games on Steam are one-time purchases. The personal fee (for first world countries) is $0.20 / month. If you charged $10 for the game, you'd be losing money after only 50 months (around 4 years).
They will most likely use hardware ID to track installs. So if you reinstall the game on the same machine it won't count, if you install it on a different one it will. Unless they let you bind it to some internal ID and track it that way.
On PC the only upgrade that would generate a new hardware ID would be a complete mobo replacement and that's somewhat rare. Upgrading your CPU/GPU/RAM does not regenerate the hardware ID.
On the recent Intel platforms upgrading your CPU required upgrading your mobo too, and there are many people who upgrade almost every generation, i.e. 1-2 years. Burdening game developers with this is unjust. The engine fee should be tied to the game's purchase, or game related purchases(DLC, other paid content).
AMD also promised (iirc) that the AM5 will only be good for 2 generations.
I'm aware. Yet I am prepared to wager that the number of people who upgrade their own mobo(instead of buying a whole new pc/laptop) is absolutely insignificant on the scale of the market.
Unless you get crafty, machine identifiers aren't stable on Windows and will change with updates. So if you update windows and reinstall an app, a lot of naive software will detect that as a fresh install on a fresh machine.
That would really suck for a small Unity dev to get screwed by a Windows update that forces reinstall of their users' game libraries - which isn't that uncommon.
> They will most likely use hardware ID to track installs. So if you reinstall the game on the same machine it won't count
Pretty trivial for a malicious user to spoof, but I wouldn't be surprised if it's something that calculates a new hardware id for trivial changes as we see so often with "don't install this on more than 1 computer" DRM implementations.
> We are introducing a Unity Runtime Fee that applies to certain Unity subscription plans based on per-game installs across any Unity-supported game platform.
> An install is defined as the installation and initialization of a project on an end user’s device.
> Each time a game is downloaded, Unity’s runtime code is also installed. The Unity Runtime Fee goes towards the continued investment in that code to support the billions of devices served every month.
So if BuyerX installs the game, I get charged, he then re-formats his hard drive, and re-install, I get charged again, if he goes to another of his machines and install, I get charged again? Crazy.
And a weirdo who hates a developer could keep auto-reinstalling (or just re-triggering the "new install" signal to unity servers) 1000 times per day, every day.
I still refuse to believe that's the right interpretation. That can't be real. Are you really going to owe more to Unity every time a user uninstall/reinstalls your game? If they want to play in their main PC and their Steamdeck?
Completely abolishes the incentive of pushing free updates too. You don't want to make new great features that would push people to re-download your game.
> We are introducing a Unity Runtime Fee that applies to certain Unity subscription plans based on per-game installs across any Unity-supported game platform. Creators only pay once per download.
> An install is defined as the installation and initialization of a project on an end user’s device.
Perhaps missed in the discussion so far is that the Unity Personal license (the one that's free up to a certain sales volume) will now require an always-on Internet connection to use.
That's a change from the past, and the FAQ doesn't provide a reason why. My guess would be analytics over licensing, but who knows really.
They got bought by an ad company, and have mainly been investing in ads and the 17th render pipeline internally so you can see where this is going: always on internet to deliver UHDQSRP ads
Sounds like I need to start a betting pool as to when ads will come to the editor.
Ugh, this whole thing is so frustrating. I’d love to cancel our unity projects and port to godot or unreal, but that’s just not possible in the near term.
Unity is doing everything they can to push devs away.
> Perhaps missed in the discussion so far is that the Unity Personal license (the one that's free up to a certain sales volume) will now require an always-on Internet connection to use.
Is that really such a problem? It looks like it'll work offline for up to 3 days.
Will there many people doing game dev that can't go online once every 3 days in 2024?
I think you're looking at it the wrong way around. The question isn't whether you have access to the Internet; the question is whether the server on the other end is up.
Products that require an Internet connection to function are effectively time bombs that stop working at some future date, due to an incident or a change in someone else's business.
I didn't say that was a "problem", but since it's harder to write a tool like this that fails when a server is down than to write one that keeps working... the question is why?
I wonder if installs could be faked? So find a project that has revenue of the 200k and then appear to install it couple million times... Is this sort of scenario considered at all?
The developer doing so would certainly result in bans and/or lawsuits, but it's not inconceivable that if it is something that relies on the installer being able to phone home that people start building it into ad-blockers or popularising some script to set the appropriate firewall rules. And if this does go through, there's bound to be thousands of people with the talent and influence to do so and a desire to spite Unity.
So I guess you can't make fully online games with unity anymore - the runtime will have to connect with unity servers at least once to report new installation.
Read the FAQ, which would have taken less time then you spent expressing your faux outrage on HN.
What is the Unity Runtime Fee?
We are introducing a Unity Runtime Fee that
applies to certain Unity subscription plans
based on per-game installs across any Unity-supported
game platform. Creators only pay once per download.
"We are introducing a Unity Runtime Fee that is based upon each time a qualifying game is downloaded by an end user. We chose this because each time a game is downloaded, the Unity Runtime is also installed."
This reads as something insane. If a player replays a game on steam, redownloads it, the developer still pays for the installation? I know people who redownload games all the time, like tens of times over the span of several years. I hope it's imprecise language and only the initial install/download is counted.
I hope these changes (whatever they actually are) won't push game developers towards developing games that milk users more, with loot boxes, in-game currency, cosmetics etc, and away from stand alone you-pay-once games, single player or multiplayer, only to be able to pay for the ongoing engine fees.
- What about maliciously installed copies? (4chan: "alright frens, time to install-bomb <gamewehate.exe>! Remember to click the IP address rotation button each time!"
And even if you assume they only charge for legitimate, authorized installations -- what about free demos? This seems to create a massive disincentive to make those available.
I think demos would be fine, if you create a separate project for the demo. It's effectively a separate game with no revenue. Development builds, on the other hand, would be the same game.
Information provided by Unity says that they can merge numbers for multiple games if they decided that they are sufficiently similar. So clever tricks of making separate game will not work. It depends on how greedy they are whether Unity will apply this rule to demos.
I posted this update in a discord server and that was the first thing a friend of mine said. Said "Great, lets reinstall [game they don't like but I won't name here] over and over again!"
You probably wouldn't need to install the entire game, possibly just install the first bits and then cancel. I'm sure our wonderful friends over at 4chan and other places full of honorable, upstanding citizens will come up with some interesting ideas.
Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for.
Yeah, there are definitely games on Steam I've played and deleted many, many times over the years.
Eufloria is a good example (for me), as I've played that one on several different machines over a few years. Probably played and deleted it more then 20 or 30 times overall. And will likely keep on doing more too.
Yup, it makes free-to-play games with high installation numbers and less exploitative mechanics that result in $200k (or over $1mil with the pro subscription iiuc) yearly income either non-viable, or much less viable using this engine.
They are also seemingly making Unity games online-only for the DRM/accounting purposes.
I’ve enjoyed using Unity for the last 6 years but this is a deal breaker. It’s just wrong and makes one wonder what other policies they’re considering.
After taking some time to mourn I plan on looking into Godot. I expect to take a big productivity hit but at least I won’t be continuing to invest my time into working on a platform that is so anti-dev.
What's super crappy about this is all the plugins, I've invested mega money in c# Unity specific asset store assets and now switching platforms is extra painful, vendor lock-in and all that. Foolish me.
It's impossible to have such a tool. Not even close. If there is that would be the biggest innovation in the history of computer science (yeah, seriously).
559 comments
[ 5.1 ms ] story [ 407 ms ] threadAlso, this continues my pet peeve of disguising bad news with neutral headlines. If they had made anything cheaper they would have put it in the headline. "Updates" means "price increases".
After reading the FAQ though I’m not sure it’s a good deal.
It also seems like you 100% have to enable spyware
I actually made a post explaining how the only terrain plugin available at the time didn't really work well in neither Godot 3, nor Godot 4: https://blog.kronis.dev/articles/terrains-in-godot-not-quite...
Then, a while later, a new plugin came out that's made by the community, which seems to address some of my concerns: https://www.youtube.com/watch?v=NwJEXOglBrQ (video by Gamefromscratch)
To me, it feels like Godot has a pretty nice future ahead of it. I'll probably stick with Unity for the time being, since I don't actually expect any of my small game projects to ever get big, so the change in pricing doesn't really affect me at the time. But in the future? Maybe I'll go back to Godot, even their C# support is getting much nicer now!
That said, wow. Charging a monthly fee on game installs is absolutely wild. The personal fee (for first world countries) is $0.20 / month. If you charged $10 for the game, you'd be losing money after only 50 months (around 4 years).
> What is the Unity Runtime Fee?
> (...) Creators only pay once per download.
https://unity.com/pricing-updates
Why does it say "monthly rate" if it's not a monthly rate?
> You will be invoiced monthly based on the month’s install data. Invoicing will be the same method as for your Unity plan subscriptions, though it will be monthly regardless of your Unity plan payment cycle.
I'm assuming that $0.20 is paid every time it's downloaded based on their wording, so that could introduce a new way to harm competitors. Buy their game and uninstall / reinstall on loop?
Yup, but don't worry. You can get a discount if you use Unity's ad network![0]
This whole thing seems...short sighted.
[0]: https://unity.com/pricing-updates "Can I get a discount on the Unity Runtime Fee?"
The engine now exists as a vehicle to show more ads, since that’s the primary revenue source of the company.
It is really frustrating how ads have ruined so many good products/platforms.
Don't worry, companies like EA are looking at that market, licking their chops, and continue to try and push such concepts as gacha into what used to be perfectly fine video games, and plenty of consumers eat up any excuse just so they don't have to go a year without the exact same videogame as last year but worse.
Is that insane? I'm not a game developer, but it seems like it's in the ballpark of what the app stores are charging, and with a structure that's actually enforceable at reasonable cost from Unity's perspective.
But you're at least the second person just in this discussion to make that mistake, so they probably need to reword that table!
But now that's on top of the app store fee. So, using your example and the "standard (aka 30%)" app store fee, after that 200k cliff, the game makes $0.50 for every $1 sale. That is going to drive people away from using Unity on mobile games imo. Who cares about a $0.20 fee for a $70 (rip $60) game, but for a $1 game where 30% of your rev is already gone... it changes the dynamics.
Maybe that's what they want though? Maybe they are trying to use this to angle as Unity is a "serious" engine now?
My guess is that the answer there is in this bit: "Qualifying customers may be eligible for credits toward the Unity Runtime Fee based on the adoption of Unity services beyond the Editor, such as Unity Gaming Services or Unity LevelPlay mediation for mobile ad-supported games. This program enables deeper partnership with Unity to succeed across the entire game lifecycle. Please reach out to your account manager to learn more."
My guess is that as long as Unity is getting a slice of your ads, you don't have to worry about per-install fees. So this may be more about driving free-to-play mobile devs to use their ad services.
Depending on how the legalese is worded, we might also see the comeback of demo versions and paid versions. So the free version has lots of installs but zero revenue, and the $0.20 bite only comes out of things you're charging for.
Are there any app stores that charge developers per install? It's only per-purchase/transaction, right? The principle behind that is you don't get charged except as part of a transaction where you're making money. If a user downloads your app for free or pirates it or doesn't make any transactions, you don't pay anything.
What Unity is saying that if I buy a new phone and re-download my apps, that should cost the developers money. That seems like a very different situation to me.
So tracking installs and distinguishing between pirated and legit copies, and fingerprinting consumer hardware, and dealing with malicious or troll installs is going to be something they're somehow better at?
I can't prove Unity's motivations, but I can quote directly from their article:
> Qualifying customers may be eligible for credits toward the Unity Runtime Fee based on the adoption of Unity services beyond the Editor, such as Unity Gaming Services or Unity LevelPlay mediation for mobile ad-supported games. This program enables deeper partnership with Unity to succeed across the entire game lifecycle. Please reach out to your account manager to learn more.
and I think it's reasonable to at least entertain that it's not enforcement trouble that's causing them to create this policy. Not for the least reason being that they still have a revenue requirement sitting in front of this policy, and they still need to engage in the exact same accounting and fights to figure out which companies have made $200,000 so they can start charging them per-install.
Note that nobody here really cares about total precision. Especially not their major customers who have negotiating power and who end up paying $0.01 per install. They're going to miss x% of the installs and have y% of spurious extras, and whether or not this approach advantages one side or the other is going to depend on a lot of factors down in the noise. If there's a large enough error it's going to end up as one more factor in the conversation with the account rep I'm sure they'll be having anyway.
> they still need to engage in the exact same accounting and fights
No, I think these are very different fights. A rev share means that every month everybody has to have the fight about what the actual revenue numbers are. I expect the way this work is that Unity will be tracking every game and looking at their app store metrics. If in their opinion they think you're making enough money to be worth squeezing, they're going to have an account rep call you. And if you don't engage, eventually they bring in the lawyers. So it's a one-time pain versus a monthly pain. Then the fight's just about install numbers, which are published and which I'd guess they have the ability to check on via instrumentation.
I disagree, these requirements refresh regularly and are applied per-game (note, I'm not saying that Unity is charging per-month, I'm pointing out that if you make $200,000 one year and $180,000 the next year, you dip back under the threshold and don't have to pay.)
This is still going to be a continual fight. Sure, I buy that you save some effort for studios that are clearly over the threshold, but it sounds like you're primarily talking about smaller companies anyway, and (correct me if I'm wrong) I don't see how it would be harder for a company to say "last year our 5 games each only made $190,000, it was a slow year for us".
> They're going to miss x% of the installs and have y% of spurious extras, and whether or not this approach advantages one side or the other is going to depend on a lot of factors down in the noise. If there's a large enough error it's going to end up as one more factor in the conversation with the account rep I'm sure they'll be having anyway.
> Then the fight's just about install numbers, which are published and which I'd guess they have the ability to check on via instrumentation.
I don't think these statements agree with each other. In any situation where it's simple to check install numbers (ie, Steam) -- Steam will also be tracking revenue. Where sales numbers are hard to track would be across multiple storefronts where... I mean, installs are also going to be hard to track. Unless they're planning to require an Internet connection for installing GoG games and Itch games because those installs aren't otherwise tracked. But I feel like that's going to be an issue for users if they do. Tracking revenue on a platform like GoG should be significantly easier than tracking installs, GoG has very little infrastructure I'm aware of to track installs of DRM free games.
I'm not an accountant, I don't want to make a serious claim, I could be wrong about the complexity, but it sounds like there is still going to be fighting over what installs failed, what was and wasn't pirated, etc... is that fight easier to have than "how much revenue did you take in?" :shrug:
Also bear in mind that this is not "you cross the threshold and then pay us for all installs", it's "you cross the threshold and pay us for installs after that point." So it's not just enough to ask if a company is making $200,000. When did they hit $200,000 in the current calendar year? How many installs happened specifically after that point? You still have to have that conversation with the company's accountants and you still have to try and confirm dates. And you have to do that yearly, and if you're already going to companies yearly and working with their accountants per-game to figure out when exactly installs start costing money... I don't know, again I'm not an accountant. I see that as a similarly complicated problem. Maybe I'm wrong.
----
My take is that Unity isn't saying that this makes their accounting easier, they're saying that it's going to encourage more "deep collaboration" with developers who purchase additional services, and that it supports the "continued investment" of the runtime. I'm inclined to believe the motivations that they're saying publicly. I'm sure that if they're pressed they won't reject a framing of accounting/ease of use, but it strikes me that it's not the motivation they're leading with. But I can't read their mind.
It looks completely insane terms for lot of mobile games where monetization is huge challenge and difference between profitable game and company bankruptcy measured in cents per user.
>The Unity Runtime Fee will apply to this game, as it surpasses the $1M revenue and 1M lifetime install thresholds for Unity Pro. Let’s look at the game’s installs from the last month: Prior month installs (Standard fee countries) - 200K Prior month installs (Emerging market fee countries) - 100K
The fee for install activity is $23.5K USD, calculated as follows: (100K x $0.15 (first tier for standard fee countries)) + (100K x $0.075 (second tier for standard fee countries)) + (100K x $0.01 (fee for emerging market countries)) = $23.5K USD
Have a game that's profitable enough to pass the threshold and then interest drops off? You're suddenly incentivized to completely take it off of the market and remove the game from people's libraries since you'll keep racking up fees from installs even if no one ever buys another copy.
I'm not denying that the quote does seem to imply what you're saying, but I have to believe that's a misprint or bad writing on their part, the implications of the threshold being lifetime sales are so bad. The policy is bad, but there's no way Unity is that comically out of touch, is there?
Yes and no. You need to meet _both_ thresholds, cumulative (lifetime) installs _and_ yearly(!) revenue. I (!)'d the yearly part there, because you still need to be pulling in a yearly $1M of revenue (I'm assuming Unity Pro here cause the math is simpler) after your 1M of installs.
So while there are some edge cases here that are legitimately ludicrous, it's not the case that you're on the hook for the game in perpetuity, because if your game falls off a cliff and you make $500k in revenue next year, you owe nothing in runtime fees. In other words, you're not incentivized to take it off the market after 1M installs unless the runtime fees made it so you started losing money on the game after your $1M of revenue-- there are some examples where this is possible but none of them are very realistic.
What about the contractors we pay to do a few months of work at the end and use their own licenses. What about the folks that do our PS5 and Xbox ports for us?
Unity attempted to clarify their position around Game Pass telling devs not to worry because Microsoft will pay, but that makes me more worried because MS will just pull those games. I think there are 25 million Game Pass subscribers, and that's a lot of 20c installs.
We were hoping for another stint in Game Pass as a follow up to Void Bastards.
The app stores track it, but they don't publish it, so Unity won't have access to it.
So now they are charging developers for something users have an incentive to try to do without paying the developer.
Ad platforms. It's common especially for mobile games to have a monetary rate where you pay per install.
I'd be open to more clarification if there's something I'm missing, but I still don't think this is comparable to app store fees.
/j
EDIT: The more I read the FAQ, the more I think this is a bad deal
https://unity.com/products/unity-pro
So I see $2040 per year per seat for Unity Pro. That doesn't quite explain why the per-install costs decline with volume for Pro/Enterprise licensees, but I suspect that's just that the Pro/Enterprise are more sophisticated and have better negotiating power.
The question has already been "Why aren't you using Unreal?" and that's just going to get harder.
Given the current VC taste for eliminating all things which count against gross margins now might be a good time to be an engine developer again.
C++. Sure, we can talk about Verse or even Skookum, but C# is much easier. Still, if any big game engine would have something like JS it would be even better for indie or small studios.
[0]: https://github.com/jmgomez/NimForUE
[1]: https://twitter.com/_jmgomez_
You do need to be disciplined, however, being able to simply start extending random instances of other types proves remarkably useful when developing.
I'm not sure such a thing would work well on a team.
Has a brief overview in its README if anyone wants to check it out: https://github.com/ldyeax/MazeEngine
I have more expansive ideas for it but for now the main demo is this silly museum. https://jimm.horse/maremuseum
It's a fun experiment in seeing what JS can do, it's cool having it run natively on the web, and annotations get you a lot of the way there, but in a context like Unity I'd never pick it over C#. Typescript might be alright but at that point why bother? C# has anonymous types, tuples, and such today too.
It was just about fine if you were doing very small projects but quickly got very hairy, and their compiler was full of bugs.
The name of the game is iteration speed. (I always think of Paul Grahams story about beating out the competition using Lisp.)
I've been working with UE since 2014, originally started in UE4 C++ and avoided blueprints and kept everything in C++. Was great 'for performance' and code diffs but now 10 years later I'm 99% blueprint and only go down to C++ if the performance requires it for the 1% of hot paths. My iteration time in UE using blueprints makes me shutter to think of all the time I spent waiting for C++ to compile.
I tried using blueprints for awhile, but it just feels so cumbersome and time consuming. I can bang out 10 lines of code basically as fast as I can think, but converting those same 10 lines of code to blueprints often involves much more time. You have to click around a bunch, rearrange the routing wires, make it look readable, abstract a lot of stuff into functions that usually don’t need it just because it helps condense the blueprints. Then the blueprints end up sprawling a large area and are very difficult to keep in my head at once (whereas it would normally take less than a page of C++ code to write it out and you can easily hold that in your head).
Basically, I was wondering if these downsides to blueprints effect you much or if you’ve developed suitable workarounds? I want to like blueprints, but the time it takes to click around and make it readable is painful, in my opinion, more painful than compile times for the C++.
It took me a while to build up enough experience where I could become more expressive with Blueprints than C++. The Lyra example has some good Blueprint hygiene worth reviewing where they organize all variables underneath a function call.. but until you have serious experience with Blueprints they are going to feel like a cumbersome mess.
My advice is to do what you feel most expressive with, doing the thing you enjoy more will lead to more hours of experience. Start with C++ and build up a good understanding/mental model of the engine and then eventually give Blueprints a try in a few more years and you will see them in a new light.
This will work just fine for small indie games and teams where the code is thrown out after a year, but there's no scaling this. I've worked with enough 10 year old Max/MSP patches to know that you will have an unmaintainable mess of wires that is as good as garbage after a while.
Larger teams typically use Blueprints to prototype but then rewrite in C++. This is a perfectly fine use case, but ultimately you still need it "written down" for the maintainability.
tl;dr Blueprints are a tool in the process to writing C++, they aren't a replacement.
Lack of Web and Mobile support
I tend to think the dev iteration speed is the core Unreal weakness.
The problem Unity have created is if something can be made with Unity it will get crowded out with clones in five minutes.
We couldn't even get Unreal to build as an embeddable library for a mobile app nor could we get it to build into anything that would run in a web browser despite more than a week of effort.
We had Unity working for both use cases in under a day.
PUBG mobile, which is in unreal, uses flutter for exactly this case.[0]
[0] https://flutter.dev/showcase/pubg-mobile
Yes. Well.
The idea that developer iteration speed is actually an indicator of project-completion-at-scale speed is really only true at a trivial scale; you know, when you only have developers. Maybe a handful of them. ..and like, one does-everything artist.
When you have multiple different teams including non developers working on actually building a significant game, crafting levels, assets, etc. the iteration speed of your handful of devs is really really a drop in the ocean.
There are a lot of very powerful tools in unreal for teams, and they have consistently invested in tooling (eg. File per actor) and real life production needs (eg. LED stage support) with their customers.
Unity has invested in different areas, with a lot of effort, and bluntly, nothing to show for it.
Aren't they making shitloads on advertising?
And that includes most games.
It's not just hobbyists and students.
This really has nothing to do with Unity. Flappy Bird could have been built on any platform and you would still have a million clones of it. Because it takes a day to make it. It's just as easy to clone that game in Unreal Engine, fwiw.
Unity didn't create the concept of the quickly built game, nor is Unity responsible for society incentivizing this type of game dev. If anything, the new runtime fees will disincentivize this type of game, so maybe that's a good thing?
Unity is already imho pretty bloated but at least useable and a sensible choice for both, Unreal is just too massive and more suited for console 3D type of games.
Unreal is just another vendor with a hand in your revenues.
But everyone will be waiting for Godot to have the first widespread hit before jumping in like that.
I do a fair amount of Godot development - for casual mobile games, limited PC games, or games where you're planning on a publisher to fund your port, I think Godot is a good choice.
>Unreal is just another vendor with a hand in your revenues.
* after 1M in revenue, IIRC
[0]https://google.com/search?q=popular+godot+games
So if you made $200k off of 1M installs, you’ll now pay $200k and your total profit will be zero.
I guess the assumption is that each install will earn you >>$0.20, but that’s a very generous assumption. What about a F2P game that has millions of installs but only a fraction support the game with microtransactions?
There’s definitely going to be some cases where studios will owe more money to Unity than their game makes.
You’re right, some studios are going to be forced to switch to the Pro plan to save on per install pricing. That just seems like a really frustrating forced upgrade.
My game has been around for a few years and has over 500k life time installs.
I May be getting very small install rate per month now, but would still have to pay a lot.
They are offering a free upgrade from Plus to Pro for one year, but that does nothing once that time elapses - you have to pay the Pro fees or drop down to Personal, which is not viable for most games.
Then you shouldn't be in the business of selling games with a model that bad. Who is charging 20 cents for their games?
The Unity Page does not mention free games with micro transactions, but especially there the user turnover is way higher. A lot of people will install it, play it for a few minutes (or days) and remove it again. Will the developer pay those install fees too?
This entire thing seems not really thought out.
I am also wondering what about trolls, who spoof HWID (or whatever the unique install id is based of) and spam-install it
Except it doesn't. Selecting Unity as your game engine is a business decision and part of your business model. If you cannot make a profit in your game after the fee, it's not Unity's fault that you have a bad business model.
I once crapped out a game engine over a weekend using python. I called it turdPy.
I released it under a commercial license of $20000 per CPU thread per developer device per day to use. With an additional 80-20 revenue share model (80% going to me) once the devs sell their game.
I never got any customers, and I always wondered why. But now I understand that it was because game studios simply didn't have a good enough business model.
Seems like having less of those games on Unity might improve Unity's brand.
To make your case, I think it would be more relevant if Unity decided to charge game publishers extra for publishing games that were only installed for some short amount of time on a device before going uninstalled. That is not the case here.
Anyway, I see where your mind is at, but I think the conclusion you came to is not correct. I don't see what incentive Unity would have to keep low quality games off of their product, they actively would want them to succeed to hit the thresholds for monetization. And besides, everybody already knows to judge the tool based on its potential, rather than judge it based on some mediocre games that came out and flopped, because that happens with any engine.
It's often easy to guess which engine a game is made on, because they tend to share certain elements (UI, rendering techniques etc).
If your engine is associated with poor quality games, than high value games may decide to use a different engine.
You don't even need to get that technical. It seems that using a privacy respecting browser that blocks cookies and fingerprinting techniques will identify a simple page refresh as an install.
This pricing change pressurizes modestly successful long tail profits. And so I think yes competitor game engines that are more progressive will be more popular for those segments.
This was not clear to me at first based on their table which currently shows 1-1000 installs as falling into the $0.20, but it's in fact actually the installs AFTER passing the threshold I believe. So assuming it was installs, it would be install 200,001 - 201,000 that would be charged $0.20?
I don't disagree that Unity need to make money, but they should go the Unreal route with % of profit or something.
Tons of games don't even make back 0.20$ per user (mobile or f2p), what's going to happens to those? Force to close because they cannot pay the rent?
Unity's recent moves to me speak to a fear that they've more-or-less hit their market saturation point, and now they're looking to extract more from the developers who live in their slice of the pie. I fear this will make that slice shrink, which will create more fear, and then the problem spirals.
That said, it locks you into using stuff like mono and stuff for cross platform which makes me a sad.
Microsoft's .Net Core runtime (now just .Net) has supported Linux and MacOS since 2016, so this information has been out of date for 7+ years.
https://devblogs.microsoft.com/dotnet/announcing-net-core-1-...
The standard libraries are still an allocation party, of course, but that can be supplemented in an engine context.
Being able to fix a bug without resetting memory state is a huge ergonomic advantage in game development where generating the right memory state can be incredibly complex and depend on a ton of very specific and hard-to-reproduce factors. Not to mention recompiling and restarting a game can be incredibly slow.
Visual Studio works with UE and calls that "Edit and Continue" and it works in C++, too.
If you're a AAA dev you give up a lot of that iteration because performance overtakes you, but there's little reason some indie 2d platformer will want to deal with even 30 second iteration times (which would be blazing quick for a AAA setup). C# is a mature, familiar environment for devs with similar syntax to C++ that can get decent performance as long as you maintain some discipline (for starters, no LINQ)
Maybe ChatGPT6 can port the UE C++ codebase to C# and we can call it UE6
I’ve not played around with any game development for a long while - does C# end up popular here just because people are familiar with Unity? I definitely get that C++ is not the most productive language - though improving perhaps.
Simply loading the .NET Core CLR is not difficult [1] - but unless things have changed since I last tried binding C++ interfaces to C# is time consuming, especially if you want to be able to implement an interface in managed code.
[0] - https://mono-ue.github.io/
[1] - https://learn.microsoft.com/en-us/dotnet/core/tutorials/netc...
Probably even a C or C++ background would allow you to do that. Maybe even knowing js is enough.
It previously used UE4 and C# integration was all working with that but, as soon as they found out that they could get access to Source 2, they took the opportunity. Makes sense because the team is significantly more experienced with the Source engine since most of them have previously worked on or with Garry's Mod.
Never interfere with an enemy while he’s in the process of destroying himself.
But most of my issues have been with engine philosophy, where Unreal has bent over backwards to expose things to their visual scripting language. It feels like every single feature has a mandate to work in a blueprint tech demo, and as a result few of them are pleasant to code against and almost none of them work together coherently. These are not issues that depend on the language used.
Whether or not it's justified is another manner. I haven't personally dealt with the modern Unreal Engine but natively supporting C# would, at the very least, make people a lot more likely to switch over.
That being said as a non mobile guy who occasionally dabbles in engine stuff I'll be migrating to Unreal for good now. I haven't been a paying customer for a while now but I used to pay for Unity back in the super early days of AR.
Or I guess take another serious look at Godot :D
I'm also surprised though they haven't just gone and added C# support as a first class option, it seems like such an obvious win.
Edit: am I wrong (mathematically?)
Of course if you sell games at $60 a piece it is not a whole lot, and the regular seat pricing of Unity is most likely a far greater expense.
Wouldn't upgrading to Pro be a better option? Yearly subscription for a seat seems to be worth about 10k $0.2.
Also you're cost per install is almost certainly going to be significantly below $0.2 because every install outside of:
"United States, Australia, Austria, Belgium, Canada, Denmark, Finland, France, Germany, Ireland, Japan, Netherlands, New Zealand, Norway, Sweden, Switzerland, South Korea, and the United Kingdom" (I wonder how did they create this list, e.g. Spain and Italy seem to have a comparable or even higher cost-per-click than Sweden , Austria, Finland etc.)
will cost just $0.02
Yeah, it almost seems to me that the $0.20 is there to force to encourage plus subscribers to Pro.
Which probably was a poor choice marketing wise since most people will just see a single number and not pay much attention at anything else.
Also it's only $0.2 fore a specific list of countries (US, CAN, AU, NZ, JP, SK and some richer EU countries). Everywhere else it's $0.02
I don't personally like this whole business model that much, but financially it seems to be pretty reasonable (I guess as long as you can somewhat predict your expected install count in advance which might not be that easy in some cases).
The issue is the fact that the wording is unclear. Also a price per install seems like a bad target overall. How is it reported? Now they are saying that there are exceptions like gamepass installs. It is going to be a mess.
Also the change is retroactive. Imagine a vendor announcing that starting January 2024 you will have to give them a piece of your cake. Even if the piece is small, you are still going to contact your layers, and you will loose trust with this particular vendor.
Oh yeah, I 100% agree with this. On the very basic level I just hate the concept of a third party tracking and counting every user I have without my (or the actual user's consent). Not every game/app made with Unity is distributed on the App Store/Steam/etc. and there are plenty of other reasons why I wouldn't want to share that data with anyone (or even collect it).
Looking at their per install pricing if you have large number of users but very low revenue per user it would certainly make sense to upgrade to Pro where you would only pay ~$2k for each seat as long as you make less than 1 million per year. Which doesen't seem that unreasonable.
no it's got everything to do with shareholders, because ultimately, the money the shareholders invested into the company will need to be recouped by the shareholders, by any method they can.
And in a cut throat business of game engines, unity is trying to squeeze out every bit of juice it can. It still has some advantages over godot atm (such as big install base, and a pre-existing network/momentum which is hard to dissipate), and my guess is that unity is trying to get revenue up before godot takes their lunch in a few more years.
It's difficult to champion high end features for your engine but keep it suitable for low end smart phones. Epic made a good attempt to win mobile devs back in the Infinity Blade days, but given their recent focus (not to mention lawsuits against Apple and Google), it seems they intentionally decided to deprioritize mobile and focus on PC and console.
Man, you just described [enshittification](https://www.wired.com/story/tiktok-platforms-cory-doctorow/) to a tee
It seems they will just bill monthly on the net gain in installs.
They still avoid the topic of defining how a install is tracked (do reinstalls count?) and so far on their forum have not replied to it.
Making the developer pay for user's hardware upgrades is still insane.
On the recent Intel platforms upgrading your CPU required upgrading your mobo too, and there are many people who upgrade almost every generation, i.e. 1-2 years. Burdening game developers with this is unjust. The engine fee should be tied to the game's purchase, or game related purchases(DLC, other paid content).
AMD also promised (iirc) that the AM5 will only be good for 2 generations.
That would really suck for a small Unity dev to get screwed by a Windows update that forces reinstall of their users' game libraries - which isn't that uncommon.
Pretty trivial for a malicious user to spoof, but I wouldn't be surprised if it's something that calculates a new hardware id for trivial changes as we see so often with "don't install this on more than 1 computer" DRM implementations.
https://forum.unity.com/attachments/upload_2023-9-13_1-49-36...
> We are introducing a Unity Runtime Fee that applies to certain Unity subscription plans based on per-game installs across any Unity-supported game platform.
> An install is defined as the installation and initialization of a project on an end user’s device.
> Each time a game is downloaded, Unity’s runtime code is also installed. The Unity Runtime Fee goes towards the continued investment in that code to support the billions of devices served every month.
Completely abolishes the incentive of pushing free updates too. You don't want to make new great features that would push people to re-download your game.
> We are introducing a Unity Runtime Fee that applies to certain Unity subscription plans based on per-game installs across any Unity-supported game platform. Creators only pay once per download.
> An install is defined as the installation and initialization of a project on an end user’s device.
The FAQ clarifies absolutely nothing.
Still bonkers for a cheap mobile game.
That's a change from the past, and the FAQ doesn't provide a reason why. My guess would be analytics over licensing, but who knows really.
Ugh, this whole thing is so frustrating. I’d love to cancel our unity projects and port to godot or unreal, but that’s just not possible in the near term.
Unity is doing everything they can to push devs away.
Is that really such a problem? It looks like it'll work offline for up to 3 days.
Will there many people doing game dev that can't go online once every 3 days in 2024?
Products that require an Internet connection to function are effectively time bombs that stop working at some future date, due to an incident or a change in someone else's business.
I didn't say that was a "problem", but since it's harder to write a tool like this that fails when a server is down than to write one that keeps working... the question is why?
There are at least a few of us here already. I imagine the "hacks" will be released shortly after this is available to the public.
Watch your games get auto removed after the developer goes out of business or doesn’t pay RENT
There’s no other way to interpret “standard monthly rate = 0.2”
Faux: made to look like something else that is usually more valuable
Common mistake, no worries
https://www.merriam-webster.com/dictionary/faux
https://dictionary.cambridge.org/dictionary/english/faux
This reads as something insane. If a player replays a game on steam, redownloads it, the developer still pays for the installation? I know people who redownload games all the time, like tens of times over the span of several years. I hope it's imprecise language and only the initial install/download is counted.
I hope these changes (whatever they actually are) won't push game developers towards developing games that milk users more, with loot boxes, in-game currency, cosmetics etc, and away from stand alone you-pay-once games, single player or multiplayer, only to be able to pay for the ongoing engine fees.
- What about pirated copies?
- What about maliciously installed copies? (4chan: "alright frens, time to install-bomb <gamewehate.exe>! Remember to click the IP address rotation button each time!"
There is a real risk of this happening.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
Eufloria is a good example (for me), as I've played that one on several different machines over a few years. Probably played and deleted it more then 20 or 30 times overall. And will likely keep on doing more too.
Unity is assuming that there is "success" due to an installation. That's a inconsistent assertion. And so, there are flaws with this billing approach.
They are also seemingly making Unity games online-only for the DRM/accounting purposes.
There's MonoGame, but man, it's really a mess, they're still using Microsoft.XNA.Game;
And I always have a hell of a time getting it hooked into Visual Studio.
Recently started a C# project that renders using DirectX onto Windows SDK window.
Hopefully I can continue along with that.
After taking some time to mourn I plan on looking into Godot. I expect to take a big productivity hit but at least I won’t be continuing to invest my time into working on a platform that is so anti-dev.
You'll need to do some prompt engineering and must have chatgpt4 to get good results.