At least for DRM-free executables, they have no way to know when, if or how many times they're getting installed, it's not like they're retroactively changing Unity itself, the games that are already done are done
And I'm not sure if installing a game through Galaxy is traceable either...? for them at least, so that point is mostly a steam (and other platforms) problem

unity is slow anyway

Maybe it's slower in comparison; But there's a lot of games where speed isn't the most important thing. Board games for example.

Anything but unity. You'd even be better off with C++.

Hell, even PASCAL would be better for game programming than Unity at this point, and that's a bit of a reach on my part.

Hit these people where it counts: In their pocketbooks and dividends. Don't give any more money to unity if you're a game developer. I'm saying that as someone who will casually drop $20 on an indie title at the drop of a hat just to help put food on your table.

You can never trust riticello again. STOP using unity please, if you are a game dev.

Yong Yea coverage of this ordeal.

Every device/PC gernerates a random ID, which is kept until some significant changes (like updating to a new Windows verision). They use that to see if a games was already present on that system or not.
You are right, they can't know how often you actually install the engine, but they can see how often it was launched from the same computer. So this ID is a good thing, they would have to treat every launch of the game as separated installation otherwisae.

The rules were also changed shortly after the announcement. They don't count every installation, but every installation on different devices/PCs. So you can install or launch it as often as you want, it will still count as 1.

More like "they wouldn't even entertain the idea because it would be ludicrous" but yes lol
Still, even if there's some groundwork, I don't think it can be reliably used to count past installs, so at most it will be an estimate

Well, the past installations are not counted anyway. They won't charge devs for what was done in the past. If now someone starts a game, it counts as 1.

And I am quite sure that existing games are not affected anyway. Not even Oracle charges for the JREs released before the change of the licence. So using any original Oracle JRE up to 1.8 u201 (or something like that) is still free. JRE 1.8 u301 or higher would cost.

Wasn't there a lifetime install count? might have been changed/I misremember

Indeed, and AR Cast was also well worked with it with how the driver had worked; Too bad that project died. Looked fun for the Skyrim VR setup as well as for having Holographic displays for setting up D&D games.

Why don't you check what the guys from Unity have written on their own before making assumptions?
They clearly said, that past installations are counted/do count so they can see if a game is above the limit.
And because they can't fully track it they do use some calculation models and estimations (you could say they pull those numbers out of their ass).
And because they can't fully track anything in the future, they will continue doing so, while their fraud detection is basically "trust us, we don't got any idea how, but we will make it happen".

Well, after the update it says that no matter they count the number of different devices it was installed on, so 20 installations on one computer count as 1.

If they are legally allowed to charge for something that has already been done, that's a different thing.
But in case it is so ... If a game generates 200k per year, then the dev can afford to pay for future customers. And if he uses the Pro version, that's 1 million $ and 1 million players to begin with.

I don't know really. I just know that after the last outrage it was changed to a install/device combination.

So if you play it on your PC and your Ayaneo or GPD or Steamdeck, it counts as 2.
But it does not matter how often you actually installed it on these devices or how often you played it before.

But it's still a big pile of horseshit if you ask me.

I don't think this will affect a lot of games except the ones who really sell well and I find it fair to pay for a tool that you use to make money, but the amount of end users (to say so) should not be the criteria that defines the price. Afer all pirated copies count just the same (which might actually affect DRM free releases if devs are led to believe that only DRM can save them).

Personally I think they introduced this to bring devs into paying for the Pro or Enterprise version.

For the free version the treshold is 200k installations and 200k $ revenue per year, for the Pro version both is 5 times higher. So for a fixed price you can worry a lot less about how often your customers do what.
And my magic 8 ball now forsees that they will sell upgrade packages: Add 100k to your limit for x $ without worrying about getting billed all the time.

Two problems. First the number of installs is it's own category, meaning if you put out a free demo and it's installed a million times, you have to pay 800,000 x 0.20 in fees because it's lifetime installs, unrelated to the revenue.

Then say you put out a fremium game, say you get 2 million people to install and play and make 200k, but you now have to pay far more in fees than you made in revenue.


Apparently if it's a game pass or something they want to charge the platform like Microsoft, and i'm pretty sure they are going to rather remove the game as an option rather than deal with these fees.

Agreed. like WotC and the OGL, this is a big enough fuckup that i would say it can end a company.

That doesn't answer the question. What are the zeros there for, what do they represent? In all likelihood they are a part of something and not just "empty unused space." Zero is valid data too! And it happens to be very common data.

Anyway, turns out I own the game and decided to take a look inside. While reverse engineering that binary format in 15 minutes is beyond my capabilities, I can make this observation: the file contains lots of recurring references to things like Chandelier, WallTorch, LightEffect, Teleporter, Destination, SetOfTiles*, SpikesSet*. Thousands of these. Which suggests to me that the file contains the entire scene with all its objects losslessly serialized.

Level15 appears to contains approximately 10k of such objects. I took a quick peek at a playthrough of the game on YouTube, and while it is not very easy to get the sense of the levels' scale, I can tell that they are quite large and can easily consist of that many tiles (and objects & effects contained within said tiles).

If all objects with all their properties and relations and references to assets are serialized in binary, the size looks quite sensible. A few kilobytes per object times 10k is how you get to a few tens of megabytes.

While I personally would not implement a game this way, I don't see anything wrong with it per se. The zeroes would be part of these serializations -- possibly including any padding bytes, if the goal is to make these files fast and easy to read & write without any marshalling (i.e. just copy the blob -- possibly even mmap the file and start using the memory as-is!).

Disk space is cheap and losslessly dumping objects in and out is fast and simple. Developer time is *not* cheap and I can see why someone would not spend it optimizing the data files, especially given how well entropy coding compresses it for distribution anyway. Nope. But I have reverse engineered data files in games, including written a decompressor for the RLE compression in Killing Time and used that to uncompress & extract all the data files out of the archive.

Don't see the need to write my own huffman implementation given that there are plenty of free & open source implementations out there (including easy to use libraries). Also, if I wanted entropy coding, I would not waste time on old huffman. Arithmetic coding is much better.