"Unity is broken" - What are people referring to?

Every once in a while, you see people saying Unity must fix its engine before making new releases. And I'm curious... what exactly do you think has to be fixed?

I am not at all doubting that Unity has bugs, because I've seen some myself, but I'd still like to hear about it. I'm asking because in my 5 years of working with Unity, whenever I've heard that Unity was broken, 2 times out of 3, it was the person's fault and not the engine's.

As for me, the biggest "broken" thing I can think of right now is the way Monobehaviours work, with the messaging system ( more here ). But at least, we were assured that a new scripting approach is being worked on

 

Unity is at it's core a game engine written in C/C++ but it has a number of modules for additional features which add complexity to the engine. Now factor in the number of target systems supported, the rendering API's, target hardware.

And the fact that Unity have a legacy .net/mono scripting subsystem with an old and outdated garbage collection subsystem.

Unity are delivering a 2D/3D multi-threaded game engine across multiple-platforms.

And working on a IL2CP compiler to allow C# .net source to be compiled to C++ for Web and native platform compilation and Unity is a very complex game engine system.

Could you imagine writing code for a game engine that supports as many platforms, graphics api's and needs to be able to built to a mono or compiled to native software and work.

Maybe Unity is becoming too complex for it's own good?!

 

@PhilSA: Some people are encountering showstoppers for their projects and the threads are the result of their frustration.

 

No doubt about that. I really wish they'd dump a few of their platforms

 

They just cut out Blackberry, next up is webplayer. I have a sneaking suspicion that PS3/Xbox 360 might be dropped this year. It does happen.

 

The internet has a way of magnifying issues.

 

The only thing i really see as broken currently is the mobile, or it seems mainly android performance, compared to 4.x.
No matter what you do, you can't seem to reach 60fps on older devices whereas it was easy as pie with 4.x.
Even just a single fullscreen quad with unlit mobile material and no texture doesn't get me 60fps anymore on an Xperia Play, where i could have full game scenes run at smooth 60fps in 4.x (no GI, no sky and stuff like that in OpenGL ES 2.0).
Most of the stuff upgraded to 5.x from 4.x got me stuttering and about half fps.
And it hasn't really improved since 5.0.

 

It has been discussed thousand times.

For a start, mixed lights do not work properly. They're supposed to blend with baked shadows. THat issue has been around forever.

There's amazing enlighten issue - the thing is a resource hog, produces inferior results to previous lightmapping engine, (AFAIK) unusable for mobiles, drops random tints on modular objects, yet beast has been replaced, there doesn't seem to be a cheap alternative to enligthen.

Then around 5.2 release there was a wave of new bugs, including bugs in core systems, some of those were showstoppers.

In situation like that, poeple start perceiving engine as "broken".

 

It's probably just a matter of perception. If you're one of the "new people" who came in on the Unity 5 series and working on a little mobile game it's likely that for such a person nothing is broken.

If you didn't switch from 4 to 5 there are probably very little problems as far as Unity being broken. If you're not trying to push graphics to the max and compete with the best of the best in game graphics Unity is probably not broken. If you're not trying to make a huge scale game of one kind or another Unity is probably not broken for you.

So probably for 80% or maybe more of users Unity is not seen as broken. If you're one of the 20% waiting for bugs to be fixed from long ago or upgrading from U4 battling with framerate issues or focusing on things beyond the norm then you may well think Unity is broken.

 

user ineptitude

 

I'm always hesitant to call Unity broken when someone brings up framerate issues. I've seen some pretty crazy stuff from people who were advanced Unity users. Even I have been guilty of many of these things at one point:

1. calling renderer.material on update instead of shared material
2. Using high-quality shaders on mobile
3. using foreach on Lists instead of for(int i .....)
4. spawning hundreds of objects, each with their own monobehaviour attached instead of having one main object that updates all the hundred others
5. Using Linq at runtime
6. Using reflection at runtime
7. Using SendMessage()
8. Making a custom character controller that uses 10+ capsuleCasts per frame
9. Making every single object cast and recieve shadows
10. Using crazy Transform hierarchies with the intention of having your objects neatly organized "by folders"
11. Believing that Unity's generic built-in solutions (navmesh system, physics engine, animation engine, etc....) are meant to be used for any game ever, and even if you're making an MMO No Man's Sky, you won't ever have to make your own systems to replace those
12. Using any fancy graphics stuff from the asset store (volumetric lighting, fluid dynamics, reflections, image effects, etc...) without even looking at the source code
13. etc, etc....

Granted, Unity could do a much better job at educating its community about performance issues....

 

That's only true(sometimes) on one end of the spectrum. Im working on a project with a huge procedural generation element and Unity really struggles to keep from crashing whenever you leave focus of the editor(alt-tab is insta death). Literally about 35 crashes a day, we thought it was our code but it's been profiled endlessly looking for the issue. Started around 5.2. So yes, for some users with large projects, Unity is indeed "broken".

 

Also it should be noted that Unity's rendering engine is going through a major overhaul to allow it to work with the DirectX12 and Vulkan Graphical API's. 5.4 should be the first version with full DirectX12 support so things should settle down after this.

As Vulkan uses a similar low level approach to DirectX 12 and therefore should be easier (in theory) to add to the engine, as the fundamental architectural changes should be in place (using a low level graphics API on multiple-threads).

 

I wouldn't mind that .

 

I just wanted to give my two cents to that.
It should be faster that way, because you'll avoid the overhead involved in calling the Update() methods of all GameObjects after all. It should, but apparently isn't. I put it to the test and the result was rather confusing.

Here are the two scripts I tested this with:

Spoiler

SelfIterating.cs:

Code (csharp):

1. using UnityEngine;
2.  
3. public class SelfIterating : MonoBehaviour {
4.   private new Transform transform;
5.  
6.   private void Awake() {
7.       transform = GetComponent<Transform>();
8.   }
9.  
10.   private void Update() {
11.       transform.position += Vector3.right * Time.deltaTime;
12.   }
13. }

Manager.cs:

Code (csharp):

1. using UnityEngine;
2.  
3. public class Manager : MonoBehaviour {
4.   private Transform[] transforms;
5.  
6.   private void Start() {
7.       var tmp = FindObjectsOfType<SelfIterating>();
8.       transforms = new Transform[tmp.Length];
9.       for (int i = 0; i < transforms.Length; i++) {
10.           transforms[i] = tmp[i].GetComponent<Transform>();
11.       }
12.   }
13.  
14.   private void Update() {
15.       for (int i = 0; i < transforms.Length; i++) {
16.           transforms[i].position += Vector3.right * Time.deltaTime;
17.       }
18.   }
19. }

Of course I made sure that only either the SelfIterating instances or the Manager were active.
Here are the results:


As you can see, when updating the positions of 3200 GameObjects both, the average and worst case performance of the manager were worse.
I see three possible reasons for that.

1. 
   
   
   • I made a mistake
   • The way Unity handles the data on the C++ side of things introduces complexity we have no control over
   • Mono is phenomenally bad at managing CPU caches and produces crazy amounts of cache misses when iterating over huge arrays

1. I think that's rather unlikely as my example is about as simple as it gets.
2. This is my best bet.
3. This is also a realistic possibility, especially when we consider how outdated the Mono version of Unity is.


That being said, there is one thing that speaks for managing the objects using a central manager. Using 3200 Update() methods resulted in huge fluctuations in performance, whereas using one resulted in worse, but much more consistent performance.



nvm

 

There is a good Unity blog regarding this -> http://blogs.unity3d.com/2015/12/23/1k-update-calls/

I think the problem with your example is most of the work is being done locally on the objects transforms, so you are only measuring the difference in function call overhead.

Also you are re-calculating Vector3.right * Time.deltaTime within the loop e.g.

Code (CSharp):

1.  
2. private void Update() {
3.       Vector3 v = Vector3.right * Time.deltaTime;
4.       for (int i = 0; i < transforms.Length; i++) {
5.           transforms[i].position += v;
6.       }
7.   }
8.  

Try simplifying it to increase a counter on the objects and you should see more of a difference.

Also you might want to try different group sizes e.g. 100,200,400,800,1600,3200,6400 to see where the impacts are.

In addition the best benefits from this approach will probably be in games with massive unit counts e.g. Open World or RTS types of games.

 

Looks like the cost shifted though. Monobehaviour is clearly taking longer in total.

 

hmmmm... correct me if I'm wrong, it's still early in the morning, but I'm under the impression that your "with manager" approach still uses [presumably] empty Monobehaviours (SelfIterating) on each object. Even without Update() calls, empty Monobehaviours still have a secret performance cost according to Unity.

I made my own version of the test, with 10000 objects:

Test 1: Monobehaviours on everything:

Spoiler: Test 1

Code (CSharp):

1. public class Mover : MonoBehaviour
2. {
3.     Transform _transform;
4.  
5.     void Start()
6.     {
7.         _transform = gameObject.GetComponent<Transform>();
8.     }
9.  
10.     void Update()
11.     {
12.         _transform.position += Vector3.forward * Time.deltaTime;
13.     }
14. }

Code (CSharp):

1. public class MoverInit : MonoBehaviour
2. {
3.     // This is a prefab of an empty Gameobject with a "Mover" script on it
4.     public GameObject moverPrefab;
5.  
6.     void Awake ()
7.     {
8.         for (int i = 0; i < 10000; i++)
9.         {
10.             Instantiate(moverPrefab);
11.         }
12.     }
13. }

Test 2: Oject manager (only one Monobehaviour in the entire scene):

Spoiler: Test 2

Code (CSharp):

1. public class Manager : MonoBehaviour
2. {
3.     Transform[] managedObjects = new Transform[10000];
4.  
5.     void Awake ()
6.     {
7.         for (int i = 0; i < managedObjects.Length; i++)
8.         {
9.             GameObject newObject = new GameObject("ManagedMover");
10.             managedObjects[i] = newObject.GetComponent<Transform>();
11.         }
12.     }
13.  
14.     void Update ()
15.     {
16.         Vector3 movement = Vector3.forward * Time.deltaTime;
17.         for (int i = 0; i < managedObjects.Length; i++)
18.         {
19.             managedObjects[i].position += movement;
20.         }
21.     }
22. }

Here are the results:

Monobehaviours on everything:



Oject manager:




Here's some results in terms of average FPS (Monobehaviours versus Manager)
10000 objects: 115 FPS versus 430 FPS on average
3200 objects: 350 FPS versus 600 FPS on average
300 objects: 800-1500 FPS versus 1800-3200 FPS (it fluctuates a lot....)

That's.... a pretty substantial gain!

Absolutely, and I'd also add cases where you have to handle lots of spawned projectiles or effects. It is very common to see some sort of "Projectile" monobehaviour on every bullet in a game, or some sort of "TimedDestructor" on every spawned particle/sound effect. Of course, with the way things are right now, you're pretty much screwed if your projectiles require actual collision detection. Because a Monobehaviour is the only way to access collision events in Unity. I really really wish Unity would expose more of the PhysX API....

It's sad because even if I made a Unity Feedback entry for that (and I have made several of those in the past), it's not the kind of issue that the Unity community votes for. The Unity community is much more interested in a "Click to make MMO" button than in making Unity a truly professional engine

 

@PhilSA This seems reasonable to me. It's the benefit of being a programmer and having a better understanding of what is going on behind the scenes. Makes sense that people with such a background should always be able to make a better game technically speaking (performance, low number of bugs and probably only minor bugs at that, etc).

It'd be the same in any language and framework. More experienced more skilled people will get better results (performance and perhaps stability as well). Your test is actually a great example showing this thinking "programmers are not really needed anymore for game dev" is basically just wishful thinking. Although it is true for a large number of cases... whenever you are dealing with an unusually large scale it won't be true.

 

Hint, Particles can trigger OnParticleCollision()* events, but you will need to test if particles as bullets are more performant than GameObjects!

* Actual API call may have a different name.

 

This looks very helpful, thanks for sharing! It is great to see a thread get derailed onto a more constructive topic for once, but it's a pity that now useful information is "hidden" in a thread with a title that hint's at something entirely different. Could this maybe be merged into an existing thread about performance optimizations?
I once started a general performance question thread:
http://forum.unity3d.com/threads/performance-questions.368278/
maybe it would make sense to move the ongoing discussion there? Or at least add a summary of important things there, like the one you just posted?

 

I'd be super interested in participating in a thread like this. I'm sure I can think of a few more tips on top of those I already mentioned. I'll try to prepare something this week for a "General performance tips" thread with benchmarks and examples, and I'll report back here once it is started

 

There are things you shouldn't do immediately after getting up/before going to sleep. This was one of them, because apparently I was tired (read: retarded) enough to turn off the "Others" section in the profiler. You know, the one that shows you the overhead.
Anyway, thanks double-checking that. It made absolutely no sense, why it should be slower.

I don't think a thread would be good, because it will end up burrowed underneath new ones very quickly.
It really should be taken to the wiki, where the information will be easily accessible and stay that way.

 

That's a good idea, but I'd like to start it off as a thread anyway because there will most likely be a lot of insightful discussion and death threats relating to what I will write initially, and then corrections will be made

 

A performance forum would be nice where people could post their scripts and ask the community for feedback on how it could be further optimised.

 

@PhilSA :
Thread for discussion, article for the results? Sounds like a good idea. Could you write me a message once you start the thread? I made a longer post about some of the things you should and shouldn't do in Unity to ensure your game performs good some time ago. I'll scoop it out and repost it there for discussion.

 

Here it is: http://forum.unity3d.com/threads/general-performance-optimization-tips-for-unity.386338/

 

Or even if you are...Homeworld: Deserts of Kharak was published with Unity 5.2. Logically, it can't be that broken. The worst problem seems to be some systems using integrated GPUs instead of discrete GPUs in certain cases, although to be fair Unity's hardly the only thing that's ever suffered from that.

--Eric

 

It doesn't work like that. If unity-based product is released, it does not mean that unity itself is flawless.

It is possible to publish working product that uses broken or flawed framework.
You'll simply* need to find workaround for every issue, fix the bugs yourself or roll out your own tech to replace broken parts.

 

It does in fact work the way I said, which is, quote, "it can't be that broken." Not a single word or even a vague implication about being "flawless"...particularly since I specifically gave an example of a flaw. Please don't invent things for the sole purpose of being combative, especially when you're directly quoting people who clearly and obviously didn't say what you're claiming. Thanks.

--Eric

 

I don't "invent" things and I'm not being "combative". The wording wasn't quite perfect, though..

Clarification:
Unity game being released only means that the engine is still usable as scenegraph renderer, pretty much.

In practice that may mean removing, ignoring or recreating a lot of built-in functionality, or wasting time developing workarounds. It does not mean that the engine is "not that broken". Also 5.2 had bigger issues than using wrong GPU.

 

Likewise it also means they were able to find workarounds to any problems they encountered.

 

Yes. That's what I meant.

It only means that they had sufficiently skilled team of programmers that managed to force the engine into submission. It does not mean that the engine is in good or even decent shape.

 

You know... after all that, it's still a bit unclear to me what's "broken" about Unity. Maybe it's because I avoid mobile as much as I possibly can. Sure there are bugs popping up now and then between releases, but those are really just in the amount you'd normally expect from software as big as Unity.

Take the terrain system for example. It is old as hell, and not very pertinent to use anymore. But it's not "broken". It's just "not good". There's a difference. I know nothing's stopping me from making my own terrain solution if I need to.

The idea that a game engine is supposed to let you make any game ever just by using the built-in tools was pretty much born with Unity. But that's not even how things are supposed to be

 

It also means they didn't waste time showing up on forums complaining they weren't able to get any work done.

Although one would have to ask why they would stick with the engine if it were only usable in that fashion.

 

For historical reaosns, for example. If you start with unity, develop decent portion of the game and then hit some horrible bug with possible horrible workaround, it may be cheaper to make the horrible workaround instead of switching to another engine.

Not really.
For example:
http://forum.unity3d.com/threads/when-is-mixed-mode-lighting-going-to-be-fixed.332250/

^^^ That one is quite important for a modern game, and it hasn't been fixed in months or even years.

Other threads:
http://forum.unity3d.com/threads/de...ble-object-structure-patched-lighting.360549/
http://forum.unity3d.com/threads/baked-light-and-tinted-glass.359589/
http://forum.unity3d.com/threads/world-space-canvas-issues-in-5-2-1.356872/
http://forum.unity3d.com/threads/mecanim-animation-events-now-trigger-twice-in-5-2-1.357053/
http://forum.unity3d.com/threads/retargeting-prop-animation-on-humanoid-rigs-in-mecanim.341141/

There are tons of other small things, like editor taking eternity to redraw scene when you select few hundred objects, moving lights causing object-wide flickering in modular scenes, etc.

Yeah, having some minor issues is expected, but not in core features (like GI or mecanim) that are one of the selling points of the product.

 

"May mean." You don't actually have any facts. Perhaps you could read this article...the switch to Unity 5 isn't covered in much detail, but what's there is positive. If they had a terrible experience, they wouldn't have agreed to the article.

In any case, I don't doubt they had to find workarounds for problems...just like every engine ever, including previous versions of Unity. It also means that Unity isn't "broken" as such, since it would have been impossible to release a working game if that was literally true. Do we have to do this incredibly tedious internet thing where everything has to be either the best thing ever, or the worst? Is it not possible to move toward a more realistic viewpoint?

--Eric

 

Look, no offense, but I think right now you're being combative.

There are other articles worth reading:
http://www.extroforge.com/the-switch-from-unity-3d-to-unreal-engine/
http://martiancraft.com/blog/2014/08/an-unreal-decision/

I worked with unity engine, and managed to hit a lot of issues in the process. The experiences was quite negative. I wish they weren't. Your article does nothing to change my past experience with the engine.

It is entirely possible to release working game based on broken engine. Because that's what programmers usually do - given a blackbox that refuses to work for whatever reason, they develop a workaround for the situation. The thing is, when you hit a workaround in the core system, workaround can be expensive and may consist in replacing that core system with your own. And making your own mecanim from scratch isn't exactly fun. Speaking of deserts of kharak, they had to make their own determenistic movement system for vehicles, IIRC.

Instead of you being defensive about the engine, I would prefer if someone fixed the problems I experienced. Mixed mode lightning is a nice candidate to get started with. That would improve the engine great deal. Arguing about how "technically speaking engine is actually good" is a waste of time.

 

As someone who makes "the switch" to UE4 about twice per month and then switches back to Unity in frustration, I can guarantee that the grass isn't greener elsewhere. There are lots of advantages in using UE4, but also lots of problems and limitations

 

Never said UE4 is superior in every aspect. It is tough as nails and has steeper learning curve, plus some of the unity features are missing.

On other hand it doesn't have mixed mode lightning problem.

Either way, most people already know which of the engines is more suitable for which situation, so there's no point in spelling it out again.

 

It's not, unless you redefine "broken" to the point of meaninglessness. Apparently now it just means "has bugs which can be worked around," so I guess all engines are broken?

Yes, which would happen in every engine, that's just called "programming". You write systems that you need for the specific game that you're writing; it's unlikely that the engine somehow includes all of them out of the box.

Those are...really not comparative things. Whatever I say has nothing whatsoever to do with what Unity programmers do. Do you seriously imagine that people don't want Unity bugs fixed?

--Eric

 

Pretty sure Unity isn't broken all that much. My game taps on all kinds of nonsense from different parts of Unity. It's moaning a bit in the console from Unity error spam, but that's hardly broken and builds work fine.

One from 2 years ago when UE4 came out, and one that is adamant the problem is "we got to a point where a single aspect of the Unity Engine became a critical blocker - multiplayer networking" - should've used photon. Probably will use Photon on UE4 instead.

Grass isn't greener; it's not even grass.

 

I've seen a lot of complaints about mobile performance in Unity 5, personally I've not found any major issues.. Just minor one's like shadows flickering over long distances, but that was an issue when 4.X got released. Found some odd Physx / navmesh issues where the capsule collider was no where near the ceiling but still caused components to crouch. Which I "worked around".

Oh and when I was using rigidbody based characters with collison (OnCollison) it wouldn't work properly (or at all), which I also "worked around"..

 

OnCollision isn't bugged, check your code. I've used it for 6 years fairly intensively. Likely you missed something like not using mesh colliders, or doing stuff outside of fixedupdate.

 

Well I'm very happy with Unity. Specifically Unity5, and not only for the graphics enhancements. I'm even more happy that since v5.3, my GI baking times have gone down 50%. Just wanted to add a little counter-weight

Also had some people comment on other forums that they were surprised how much beauty I was able to get out of an engine, that for obvious reasons, doesn't have the best reputation.

 

If you say so, worked fine in some previous versions with exactly the same code.

 

Yeah if you do things outside of fixed update, it can change quite a bit. Also 5 changed collider behaviour. This isn't the same as being buggy. Example: rigidbodies can only have convex colliders otherwise you get junk results. Physx 3.x limitation.

 

All right. Would you kindly present a workaround for broken mixed point lightning, animation events firing multiple times, or gi producing random tints?

The biggest problem with unity is that while working with the engine I get impression of unreliable product. I get definite feeling that no bug is ever going to be fixed, and new releases will only break existing feature. That impression is a direct consequences of a flurry of bugs in 5.2 release, mixed point lighting never being fixed, and never receiving any response to any of bug reports I filed, and experience with the engine in general. Basically, the feeling I get is that the team does not give a damn about anything. That may not be the real state of affairs, but that's what it looks like from here.
I do not have that kind of impression while working with unreal engine, for example. Because you can get an actual dev to step in and respond to your query, or even a CEO himself on occasion, and you have source code.
And that is a big deal.

Instead of arguing about semantics and "one true meaning" of "broken", I would prefer if someone, for example, fixed the damn mixed point lightning bug already, because it has been around forever.

The end.

 

In what way did it not work properly?

I gotta say I agree with that. I'm certain Unity does care, but they are most likely stuck on bad past decisions and an engine that wants to support too much stuff for its own good. And with Unity, we'll always be stuck with this colossal, almost game-breaking handicap of having no source code access

UE4's community management, on the other hand, is top-notch. And their product is very solid. It's just unfortunate that they keep pushing their blueprints scripting instead of having a proper, efficient scripting language. I understand visual scripting is good for attracting all those game dev newcomers who hope to make their procedural planet MMO in blueprints with zero budget, but Epic should think about more intermediate/experienced devs too

 

I've gotten responses to most of my bug reports (haven't had to submit any for a while), and they typically do get fixed, so no major complaints in that department. I see responses from developers here on a pretty regular basis. I might want to see more, like how things were in "the old days", but since there's orders of magnitude more activity here now, I'm not sure how realistic it is. What I would really like to see is more focus on implementing basic features that aren't easily done as asset store assets, which sit untouched for unreasonably long times, such as the input manager. (Gee, look at that, 2009....)

Broken means literally not usable; I don't know why you'd insist on arguing about that in the first place. It's not productive having a conversation with someone who invents things and has words mean whatever he wants, so I'll stop trying.

--Eric