3 ms·
And the dumb thing is that if they had listened to the engineers who were telling them the customer base was going to freak out at this, the company could have
by jsmith45 3y ago
And the dumb thing is that if they had listened to the engineers who were telling them the customer base was going to freak out at this, the company could have avoided large parts of the drama, since a few of their fixes were not even really a change in plan, so much as better more clear wording.
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.
- ilrwbwrkhv 3y agoAnd 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.
- Miraste 3y agoBeing 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.
- ilrwbwrkhv 3y agoMaybe, maybe not. Watch this talk https://www.youtube.com/watch?v=RsT-5VSqk8I https://www.youtube.com/watch?v=RsT-5VSqk8I
- raxxorraxor 3y agoThere 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.
- lolinder 3y ago#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. [0] https://news.ycombinator.com/item?id=32081051 https://news.ycombinator.com/item?id=32081051
- deciplex 3y ago> 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.
- raxxorraxor 3y agoPlus, 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.
- jsmith45 3y agoYes 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.