Unity's sinking into anti-user decisions

Let me expand on the title. I’m concerned because on the top of all the problems Unity has done to itself and its user-base, I am detecting an underlying problem which will and is preventing Unity’s return to the customers.
The thing is, Unity used to created solutions for the users, to make our life easier and make making games reachable and approachable for more and more people. In Unity’s words: democratizing game development.
And you could find tracks of this all over the place.
For (a very small) example: engineers found that safety is sometimes fragile, so they limited the download protocols.


It’s a good move, usually you want that. But then what about legacy stuff? Or unusual limitations? Unity recognized this, so they put a setting in place where you can choose the level of security based on the circumstances. They did the right thing. They made users’ lives easier.

But this kind of consideration is long gone when it comes to Unity’s latest additions. For example you can find a sudden, unannounced change here .

This absolutely doesn’t make any sense. Without any previous warning an API gets shut down basically, because engineers think it doesn’t work in some circumstances. And then when we start asking questions, they say “we may put a new API in place to solve the problem we just dumped on you”. They can detect when you call the CreateAsset method during the import process, because they warn you about it specifically. So they could choose to handle the things there properly. Well, they could do that, they chose not to. They just tell you to stop using that API during import, which dumps a big pile of crap on very many applications, since very many people are creating multiple assets on disk from one source asset.
They could keep the functionality, since in the majority of the time it just works good enough and maybe, just maybe shovel a setting in the settings so it can be secured in circumstances when it shouldn’t be used (like when an organization starts using the cache server). But they chose not to. They just cut you off without explanation or example how to get around this and make your life harder.

You can find similar anti-user sentiment in the [Graphics]( Water System for the High Definition Render Pipeline page-13) team as well. Example:

They could choose to make users’ lives easier and cut the crap and make a setup button and then users can go in and tweak if needed, they deliberately chose not to. Because users need to be educated or whatever crap. You can educate users by writing proper manual. When you make the setup button and users realize they need something slightly different, they can read the fricking manual and learn where to tweak it. When it is needed. Not every single time when they want to setup something.
This is extremely hostile anti-user and anti-UX behavior.

I wish Unity would go back and think this through and switch back to serve users, not some l’art pour l’art puritan BS. This is similar to something some coders do:
“We could make a software change which is faster, more readable, etc, but we can’t because it violates some BS convention or SOLID or some pattern or something.”

You are making Unity software for the users. Not that you can have a perfectly pure software system in place. People are messy, the best way to serve their ideas and their creativity is messy. Deal with it.

Sorry for the rant.

12 Likes

I’d consider it a strength to make decisions that sacrifice backwards compatibility in order to continue progressing. However, the issue lies in the fact that the replacement API or feature is often not an improvement; instead, it introduces different shortcomings and bugs.

9 Likes

I totally agree and I encourage that every occasion I get. But this isn’t about that. It is the complete disregard of any kind of UX or usability question.
If they made a new API for importing assets and they said, hey, you can use the old one just fine, but when you turn over to the new one, you will have this and this rule, fine. Even if they push out creature-comfort changes and additions later.
But this is not that. This is they putting an if (isImport) return; (or at least equivalent in functionality) into the postprocessing facility without telling it in advance and without giving adequate solutions to get over this limitation. Zero new API, zero improvement, it’s decreased usability for some misguided attempt to make the import pure and never touch any assets in the assets folder. Because of reasons.

7 Likes

[mention|9zBOANpCszZ8XraYIsjYBQ==] [mention|UoUASh3LN6H+qZSKHPwPww==] One of the examples of this that immediately comes to mind is the removal of the Display Resolution Dialog . No, I am not letting that one go. The tool may not have been the best thing ever, but it was extremely useful for doing quick test builds and prototypes.

So someone at Unity decided to remove it, without warning, and did so without FIRST providing a replacement. Unity point blank lied, claiming that they’d announced the removal in a prior blog post when in reality they’d only announced that it would be disabled by default, not removed.

The excuse for the removal was that most games don’t use it or they just make their own launcher. Which completely ignores its utility for test builds, trade show events, game jams, etc. and even just having it as a fail safe.

By all means, upgrade it, replace it with a new one, whatever. But why the heck wouldn’t you just leave the old one in until the replacement was ready? Because it has now been nearly 4 years and the replacement still hasn’t arrived, despite the claim that a replacement was in development.

This one really made me angry, not just because of the extra work it created, but because of how outright hostile and inconsiderate that type of move is to the user.

10 Likes

I personally don’t miss it too much, because there is a replacement API (well, command line access), so I don’t care that_much, but it would be better if Unity instead of reintroduce a testing-only dumb dialog box would develop a system helping making launchers properly. Instead of everyone who is working desktop doing for ourselves.

But yepp, the underlying behavior is the same. Removing things without meaningful replacements and proper ahead warning.

Thinking about it, didn’t this start around the time when Beast got removed?

2 Likes

Yeah, pretty much every commercial game has an “options” menu with graphics options and key-rebinding. Unity should have a little package or asset store download. Minimal, but modifiable.

Actually, you could have an input rebinding menu as an example scene included with the new input system. Likewise the graphics options menu could be an extra example included with URP/HDRP.

2 Likes

They have that.

1 Like

They have that, but it’s of course broken :wink:

6 Likes

For all the pain points with more recent Unity versions, nothing has come close to the removal of Beast.

That was a bit of a disaster for a project I was working on at the time, a mobile game with dozens of lightmapped scenes nicely baked in 4.x/Beast, and relied heavily on lightprobes.

Attempting to rebake with the new lightmapped gave completely different results. Relighting the entire game from scratch just wasn’t viable, and IIRC, lightprobes were broken to the point of being unusable for a long time after that anyway. The game ended up with downgraded/broken lighting - a hacky workaround to re-use the old Beast lightmaps and probes that never matched again.

(I think light probes were a pro-only feature back then, which may explain why they got so little attention - far fewer users finding and complaining about the issues with them?)

1 Like

I’m pretty sure Enlighten was added in Unity 5, which was when they removed the feature disparity. They were just busted, like pretty much everything related to Unity’s lighting system when they implemented Enlighten. Remember how mixed mode lighting just didn’t work right for literal years?

1 Like

I have to say this is distressingly common. A new feature is added, like UI, AR Foundation + XR Interaction Toolkit, etc. The examples are scattered all over the place, sometimes in the Package Manager, other times in a Git project. The one thing that is consistent however, is the examples are broken.

AR Foundation and XR Interaction TK both try to do the same thing - make AR development easy and consistent. However, they don’t work together. So, which is more important? Consistent gesture input or AR? Next up, the suggested pipeline is URP for a mobile project, but all of the foundation samples are using the built-in pipeline and 2019.xxx.

Likewise, the XR Simulation environment is also trying to make life easier for AR. However, it fails to detect touches ( i guess because I’m using XR Interaction TK?). I have to enable ‘simulate touches’ to test touch and gestures, and then disable it to navigate and move the camera. Are any of these developers in the same room? Have they never tried to develop an AR app, but just isolated features?

3 Likes

Yeah the multiple XR packages are great in isolation but absolutely **** the bed as soon as you use them together - you know like any cross platform project would often do to maximise platforms they can publish to

Right now its easier to have a seperate project per platform than go cross platform in a project with XR targets, which defeats the entire point of using unity

5 Likes

The unity saga continues…

in the future, you will have to operate unity with some form of esoteric abstract mouse movements which are considered on screen shortcuts which boost performance according to bleeding edge user-analytics you don’t have access to.

can you give me a practical example where this removed api issue you are talking about is used?

they are working on increasing the DRM strength they are not working on making the software usable. They want devs that will use unity only to support existing projects, to be tied up in the system as tight as possible.

Instead of having an offline unity version than sometimes you fire up to fix a bug or update some stuff google or windows decided it doesn’t like anymore, unity wants you to make you login all the time, say hello to them, keep actively visiting unity, not go away! jump around like a good boy. MAYBE in a few years you will turn around and you love them once more.

It is vital that they try to chain up to the wall devs because once they are gone they are gone.

And when the management presents data to shareholders they can claim all these active devs that interact with the software every month. Amazing.