Re:Unity's oldest community announces dissolution
by ilrwbwrkhv on Monday September 25, 2023 @07:10PM
(#37652018)
And that's why people like Jonathan blow and Casey Muratori have for so many years now warned game devs about this and learn how to make a game engine from scratch. Hopefully some listened.
Re:Unity's oldest community announces dissolution
by Miraste on Tuesday September 26, 2023 @12:20AM
(#37654299)
Being wary of large corporate engines is a good piece of advice. "Make a game engine from scratch" is a terrible recommendation and shouldn't be linked to the first one. Every dollar and hour spent on a custom engine isn't being spent on the end result. There's a place for it, sure, for people like Blow who are in love with the craft--but most indie game devs don't want to make an engine, they want to make a game.
Re:Unity's oldest community announces dissolution
by ilrwbwrkhv on Tuesday September 26, 2023 @12:51AM
(#37654545)
Maybe, maybe not. Watch this talk https://www.youtube.com/watch?v=RsT-5VSqk8I
Re:Unity's oldest community announces dissolution
by raxxorraxor on Tuesday September 26, 2023 @05:20AM
(#37656571)
There are also costs to use the ecosystem of an engine, as you need training and experience. The main advantage is that an ecosystem exists that can provide advanced tooling and resource management. There are quite a few alternatives if it is just rendering and general media playback. There are some generic frameworks to develop games, but most rely on custom architectures. Adapting the read-to-use engine takes time as well.
Re:Unity's oldest community announces dissolution
by lolinder on Monday September 25, 2023 @07:42PM
(#37652310)
#1 would have been much less of a problem if it weren't for the IronSource merger [0]. When you merge with a spyware company and then announce you're going to use a weird new metric, it's entirely reasonable for your customers to assume you'll be using the spyware to measure that metric.
Re:Unity's oldest community announces dissolution
by deciplex on Monday September 25, 2023 @07:48PM
(#37652381)
> 4. Unclear definition of install was used. What they eventually settled on: once per unique end user per distribution platform (e.g. app store), was pretty much what Unity was going for anyway, but the initial announcement royally messed up here.
That was not a miscommunication though: it was brought up directly to Unity and the initial response was that it would be per install, per device.
Re:Unity's oldest community announces dissolution
by raxxorraxor on Tuesday September 26, 2023 @05:22AM
(#37656603)
Plus, as a user of the endproduct and not the engine, I am not keen of my installs getting tracked.
It has become quite normal to create device identifiers, some crazy people do it in the name of security even, but I resist this development where I can.
Re:Unity's oldest community announces dissolution
by jsmith45 on Tuesday September 26, 2023 @10:39AM
(#37660085)
Yes and no. In practice evidence suggests they were planning to heavily rely on app store install counts for games not using unity services, and thus for which they had no better data. This is part of the reason why they were being so cagey about how they would estimate the install counts, because they would be heavily using relatively crude approaches like that. (and also hadn't fully worked out the details).
For IOS, for example, reinstalls don't increase that counter. I'm not sure how it works with the Play Store.
They almost certainly said that reinstalls would could because they might count for some platforms.
The big drama causes 1. People assuming unity was going to add additional telemetry to track installs. (Reality: Unity seemed to always be planning on using App store numbers and the numbers from any opt-in unity services as the basis of their model). This one was a complete communication failure by unity.
2. Announcing a new payment model never before used by the industry. This alone (without looking at the details) is not a huge deal, but it makes people nervous.
3. This metric is hard to measure, and unity's initial announcement was basically that they would be estimating it in their sole discretion, which makes people uncomfortable. Their fix was to allow self reporting the data, which must be based on something that reliably approximates the revised install count definition.
4. Unclear definition of install was used. What they eventually settled on: once per unique end user per distribution platform (e.g. app store), was pretty much what Unity was going for anyway, but the initial announcement royally messed up here.
5. The metric was abusable, and there was apparently no cap to it. This was honestly one of the biggest issues. This got fixed by adding the 2.5% revenue share cap.
6. Trying to make this apply retroactively to previously published applications. This was the other biggest issue. This was especially bad because only a few years ago the company had another smaller scandal, and promised to allow people to keep using the terms of service of each version as it was when people downloaded it. Indeed, for a while this was explicitly part of the terms, and people who used those versions probably could get a court to side with them.
If they had listened to their engineers, I think they could have fixed/avoided 1, 4, and 6. Numbers 3 and 5 may have remained, still causing huge outcry, and eventually getting fixed, but at least if number 6 were addressed before initial announcement, it would not have been a loss-of-trust issue so much as a: you are a moron for proposing this without the needed backstop, and requiring companies to blindly trust your estimations.