We need a Quality Offensive !

Unity Engine
1

I’m getting really fed up with Unity’s constant opaque crashes, errors and general quality that feels like it dropped through the floor in recent years.

After battling another dozen or so bugs, I’m now getting a corruption error ("
The file ‘…/Data/level0’ is corrupted! Remove it and launch unity again! [Position out of bounds!]") that has been known for years, has no good solution, no official answer from Unity and apparently has never been fixed.

And there are dozens of those. And that’s on the LTS version.

Working with Unity has turned from being a pleasure into a nightmare.

Please, Unity, get the message before it’s too late: You need to focus on quality and get rid of all this crap in your engine. You need to stop adding more broken sub-systems that are in 0.x for half a decade or get abandoned and raise your code quality. You need to stop making breaking changes in LTS versions, and you need to take bug reports more seriously (half of my bug reports never got fixed, it apparently takes weeks until someone even looks at them, so I stopped submitting them).

I know this is more of a rant, but the time intervals between me wondering if I should use UE instead are getting shorter and shorter. And that’s before even figuring in the commercial blunders and switcheroos.

4 Likes
2

By all means, bugs should be fixed.

BUT …

Keep in mind that we are working with numerous 3rd party assets (especially any scripted tools) that often are the real issue, not Unity by itself.

Case in point: rather often you see editor scripts that trash editor performance by doing something like this:

  • create an asset
  • mark it as dirty
  • save ALL assets
  • Refresh the ENTIRE AssetDatabase
  • and possibly doing this in a loop or in a frequently called event method

In my 10 years of experience working with Unity the clear majority of issues came from within the project itself, not actual Unity bugs. Of course those exist too.

I agree that in recent years we‘ve been treated too often with obnoxious issues like warnings or errors getting spammed to the console even in new projects. Things like where you only need to have an array field in the Inspector causing a nullref when that object is selected. Or frequent „native memory leak warnings“ after installing DOTS packages using only the recommended versions and doing a simple enter/exit playmode in a sample scene.

Perhaps this is also just my perception because I keep upgrading to the latest versions, I created or opened hundreds of projects last year in every major and minor version of Unity so I‘m more likely to see those. If on the other hand I had been working with one or two projects most of the time, and an issue occurs „out of the blue“ (ie a Unity version or package upgrade/install was not involved) I would definitely first look into possible causes from within the project.

There is a high likelihood you‘ll find one of two causes:

  • something (possibly non obvious) broken in your project, specifically scripts and how they use the Unity API
  • something (possibly obscure) triggering an actual bug in the editor, with a chance of finding a workaround (eg changing a setting, or organizing the mesh differently)

The painful part here is that it‘s our job as developers to narrow down the causes. I can assure you, almost every time you can either fix or work around it. In the remaining case you‘re likely to end up with a repro project that you can submit with the bug reporter.

Most of the complaints however come from developers who do not analyze these issues, and they keep working with them and blame Unity until, eventually the pressure builds up enough that it needs to be vented in a public post of frustration.

I‘m not saying that this is the case for you specifically, it‘s more of a general observation. What is notable however is often the lack of detail in such posts, and yours follows that scheme. You vaguely mention one issue that seems critical but we have no info on that, yet you claim it has existed for a long time and is getting ignored. Perhaps for good reason? You also mention many other bugs, but don‘t even say what they are.

If you could provide more details about these issues, maybe we can even get some of these resolved, or you learn that this has been fixed in a newer version, or tips on how to analyze these issues. Again, I bet at least some of these issues that are plaguing you and your project could be resolved right now and forever. :wink:

3

Some of what you write is true, but I’m not exactly new to all of this, I started using Unity back in the 2.0 days when it was a Mac-only engine.

The error I used as an example above can be worked around - by deleting the entire scene and creating it again in a new, fresh scene. Thankfully, copy-paste works. But that also makes clear it’s an issue with Unity corrupting a scene file and being unable to clean it up again. That’s ridiculous.

Submitting a full repository is nonsense. My current project is 10 GB. It takes an hour or so to upload. I’m not doing that repeatedly. Not when half the bugs I’ve reported in the past haven’t even received serious attention.

Then there’s a ton of QoL updates that Unity has just consistently been too lazy to do. Like the “missing script (but I’m not telling you which one)” problem. It’s not difficult to tell me at least the name of the script that went missing (it’s stored in the scene asset file for fuck’s sake!).

I could give examples, but the examples are not the problem. Every single one of them isn’t the problem. The problem is that there are lots of them, that they aren’t being fixed and that instead Unity is throwing the next half-baked, never finished, permanently in 0.x sub-system at us, chasing features.

By now, the engine is a collection of conflicting sub-systems, with old ones never abandoned, new ones never finished, and quality in general going down. There are now at least two ways to do almost everything in the engine, from rendering to gameobjects.

General code quality is down and complexity is up. That’s not something that goes away if someone looks and fixes the dozen or so engine issues that I’m having or had to work around. New issues will appear. Until someone makes code quality a priority.

4 Likes
4

This resonates with me, despite my projects being relatively small so far.

My feeling is that Unity should have pivoted to a new product line some time prior to the push for SRP, DOTS, ECS, and the recent price change shenanigans. Permanently building on a legacy codebase the way they have for so long seems like a mistake and I am sure that some of the talented engineers working at Unity would love the opportunity for greenfield development.

It also feels like things have worsened since the IPO in 2020, not to mention the question of profitability which I find completely mind blowing. Also, RIP Weta Digital I guess… so yeah, a lot of pressure from the top down internally I imagine.

It’s far from game over, but if things don’t improve in this regard I fully expect that people will begin to consider the growing number of alternative engines out there for future projects. Godot and Flax may not be widely considered as suitable substitutes yet, but I am watching their development with great enthusiasm.

5

Exactly why Unity (and every other software dev) is asking for a simple repro project, not the current production project.

Which isn’t a bad thing. C# is full of those options too. So is practically every complex software, like the video editor I use.

Developers just loooooove to start over, don’t they? :wink:
But it’s rarely the most sensible thing to do. Especially business-wise. You’d still have to support the old system too, and for many years to come. All the way the new system is deprived of features AND full of bugs because it’s heavily under development.

Splitting things up into packages has helped a lot, although there was a time when package versioning was all over the place and not coordinated. I’m sure at the time a complete rewrite has also been considered internally, at least there must have been engineers more than ready to “start over” as we so often like to do. For some it seems like the most obvious silver bullet.

The built-in API, as bad as it is (AssetDatabase or IMGUI stuff), well it just works and a lot of people know their way around this. But that’s the one I wish would get replaced over time. At least now we have UI Toolkit but editor scripting still suffers from xxxUtility static class crud.

6

But sometimes it is the most sensible thing to do. Business-wise it seems like the company is already facing challenges and I suspect that while engineers on all sides of the conversation want Unity to be the best product it can be technically, the directors and investors need it to be the best for profitability… and for obvious reasons.

Supporting legacy products while tasking other teams with greenfield development does not have to be the way you describe it, but it does need to be well managed and financed. This should have been possible a few years ago, maybe still is, but this is where we are… imbued with the power of hindsight.

That said I still have a lot of love for Unity and hopes for it’s future. Having tested some other engines recently I was reminded about all the things which Unity does really well.

It would be fascinating to have an offline chat with some folk at Unity to know how they feel about this stuff, because these are just the thoughts of one guy pondering while getting coffee!

7

I would like to include in the list that Unity should strive to return to simplicity. Many of the newer systems seem over-engineered and complex to use, with documentation that is not helpful.

1 Like
8

Which ones specifically?

I just gotten back to using Entities 1.0 after a short trial run with 0.5 and I have to say, that is pretty darn well designed API and good documentation. It is certainly a lot to take in though. The same could be said about Netcode.

Other packages, like Serialization, I agree. The documentation on that thing sucks even though it’s super-duper useful. It’s a hidden gem that needs at least documentation polish, but once you’ve grokked it this is a game changer when it comes to serialization.

The GraphView API, both the experimental and the deprecated package, are a sad story. Just to balance in something I tend to agree is a powerful feature that hasn’t gotten any love in years despite the possibilities for editor tooling.

That is an experience many encounter when switching engines. The initial learning process may be easy going but as you get to create custom stuff you suddenly realize that things you took for granted, if not automatic, are suddenly manual labor or require learning an entire module of the other engine only to do a minor thing that used to be a 5-minute setup with GameObjects.

9

Addressables, Input System, Localization, Timeline come immediately to mind.

2 Likes
10

Just as an example: The Localization package is actually pretty neat. But it was soooo obviously designed for huge projects. Stuff like having a bunch of tables should be optional with a switch to default to one table. The current way means extra clicks on every … fucking … text that you add to a gameObject, if you don’t need multiple tables. And getting the actual strings is more complicated than it needs to be, to the point where something like

private LocalizedString _myString;
public string myString { get { return _myString.GetLocalizedString(); } }

is now probably the most often repeated piece of code in my current project.

The new input system is a trainwreck, I’ve fought with it for way too long. I’m now importing Rewired into every project I do simply so I don’t have to mess with Unity’s input system anymore. The new one is a great example of over-engineering, where the most simple thing, like “do something when user presses the X key” is now a lot more complicated than it used to be. Sure, it is more powerful and can do silly things - but somewhere along the “let’s make it flexible” road, someone forgot to stop and think “wait, what are probably the most common use cases?” and “let’s make those easy”.

Honestly, it feels like the people who design and implement the engine haven’t actually made a game with it in a decade or so.

1 Like
11

Just out of curiosity what is hard on the Keyboard.current.xKey.WasPressedThisFrame;? (manual)

FYI, I made a thing to help this, static struct binding for localization entries, so you don’t need to write that for every single entry, if you don’t want to.
https://github.com/LurkingNinja/com.lurking-ninja.localization-codegen

2 Likes
12

@Lurking-Ninja has already given the simplest example. Though I remember these static shortcut methods weren’t available in the early versions - but maybe I never looked at them.

The thing with the Input System is that, compared to Input.GetKey() is that it takes some upfront effort to at least understand its concepts because they all have their use cases and pros/cons. The package also provides a sample that showcases the four event-driven ways of reacting to input. You can hook up events with UnityEvent instances in the Inspector or you can go all nuts with a code-only solution (terrible choice, often done wrong or in the most convoluted ways).

My best guess is that the Input System has seen many refinements and changes over the years, and a lot of tutorials are old and go about one specific way, not even mentioning there are several ways of doing things.

One can rightfully argue that these options make things more complicated but if we had only the simple solution, we’d be back at Input.GetKey with all its issues and users complaining about that. I feel giving everyone a choice even though it means understanding more of the concepts is the right approach here. The same could be said about Cinemachine for instance, which is complex but actually not that difficult, and far less difficult given how often beginners come here asking for help as they struggle to script their own 1st/3rd person camera controller.

I do see a lot of Unity apps using Rewired (you can view the list of packages used in a game in a text file) and was always wondering why that is the case. I would say ease of use (and a certain degree of habit or lack of need for alternatives) still beats covering all possible solutions and edge cases.

1 Like
13

Unity’s sample project was (and may still be) pretty bad. It came out before the current workflow guides and was an extremely verbose example when it had absolutely no reason to be. Once the new workflows were released I tried them out and found this one to be the best for me as it’s the best blend of editor UI and code approaches.

https://docs.unity3d.com/Packages/com.unity.inputsystem@1.7/manual/Workflow-ActionsAsset.html

14

No, but at the same time, we are playing in a house of cards ready to fall at the merest breeze sometimes, and I am symapthetic to the teams working on their own bits and its hard to check every bit works with every other bit , but isnt that why unit tests are made? so you dont introduce more issues than you fix?

example

I made a new 3d urp project in 2023.3b1 (yes im aware errors are more permitted but), i installed entities, and entities graphics (the latter cos for some reason it didnt think i might want to see them).

the console even after restarting unity to give it a fair chance

9567469--1353616--upload_2024-1-7_19-32-5.png
9567469--1353616--upload_2024-1-7_19-32-5.png704×218 17.8 KB

oh and an error about how dare i not be using the the render graph… um. it was supposed to be on by default, well apparently not for me… after someone told me where to find it, cos zero clues given on the forum announcing it in the alphas, and the error message not mentioning either… i turned that on

i made a normal game object plane, and a subscene - nothing in it…

if i run it

9567469--1353619--upload_2024-1-7_19-32-41.png
9567469--1353619--upload_2024-1-7_19-32-41.png720×63 14.3 KB

constant supply of these errors (a few seconds sees 900)

there is zero me code, ive listed the 2 things i did… you could even remotely claim as effort… so realistically this is basically a blank project with 1 plane and a subscene so dots bits can go in it… and its moaning like got to get up early on a monday morning…

heaven help me when i add some code and make a mistake…

1 Like
15

Stop.

16

Because it works, is not a complete mess of outdated and incorrect documentation, it works, has extensive and actually good documentation, and also: it works.

The time I’ve wasted with obscure failures on the new Unity input system, even if I would assume $1 per hour, would’ve easily paid for Rewired all by itself.

It’s also a ton easier to set up controls, change controls at runtime, access everything via script with actual speaking variable names, support even obscure controller types, add local multiplayer with multiple controllers and hook the events into your own bridge code into whatever weird code you write by yourself (my own observer-pattern system, in my case).

Rewired is everything that the new input system should have been, but isn’t.

17

Havent tried that one yet, but it does seem popular - cos of you, ive downloaded the trial to see how it goes