Unity Software Inc S-1

The problem is definitely churn and shaky foundations.

Unity has a "version 2" problem, the "second-system effect" is a major tenant of Unity engineering which sucks [1]. I really wish they locked down features like they did back when the team was very small. Maybe that is the problem, too many cooks.

The "move fast and break things" has also made very unstable systems and updating a chore. I like moving fast, but only break things if what is gained is more than before, not back to the same footing.

I have been using Unity since 2008, shipped many, many titles on it but due to their churn and every changing APIs/libs/features, updating games is a major pain even mere months out.

Networking is a major problem, always in flux and Photon is still the best probably. There are other third party solutions to it but I don't know I'll ever trust a Unity networking library again.

UI is a major problem, again always in flux, from GUI, to UnityUI, and now to UIComponents. Unity loves to push off all problems with a shiny new future thing that never really solves much but adds more problems.

Everyone knows about IL2CPP, the animation changes, particle system changes, rendering pipeline flux and more so I'll spare you [2].

It seems much of what Unity changes is driven by announcements, marketing/finance over what engineers want. If Unity went back to just making it code based, THEN add on the editor tools to that lib/api then we'd be in a better spot. They seem to drive things through the editor first then allow code/api access. Libraries like particle systems, animation, ui and more all had editor access before code access and that is frustrating. Let developers make tools needed and start with a clean, solid, well designed API that isn't going to change every version, change the guts of that system abstracted to a clean, simple, atomic wrapper.

Unity is still the best multi-platform engine for mobile and other areas, but it is nice that competition is here with UE4, Godot and others. UE4 and Godot are focused on simplicity, UE4 is arguably more simple than UE3 and largely that is because you can take the C++ route, Blueprint route (which rides on their apis) or a mix. Unity's big selling point is their editor, but it clouded their engineering focus as editor first over code first.

Unity really needs to make games on their platform that they must keep up to date with every build like Unreal, that way the pain points hit them more as well, and they will smooth out that process of shipping, updating, actually making games on their engine.

Unity is pushing to be Unreal, Unreal is simplifying to be more like Unity, Godot is almost a better indie/small/medium engine at this point because they are limited by how much change they can make. Progression doesn't have to slow down, we just need cleaner, more well thought out APIs and wrappers for subsystems that can change. People use Unity, Unreal, Godot, others for an engine team to think about these things. I wish more of it was standard in game development so it was a littler harder to change surface level functionality, not to slow things down, but to make a more stable platform/abstraction/atomic surface where shipping games and updating games is easier.

I think overall software today is stuck in the second system effect too much. No one values clean APIs that the surface, signatures, and actions are in a clean wrapped, abstracted, atomic system that the inner workings can change more easily. There are too many leaky abstractions today or no attempt to create atomic/standard interfaces that allow "move fast and break thing" underneath, rather than on the surface.

I liked it when you could read the docs, use the tool, and code libraries, and much of it made sense, simple, good naming, discoverable. Now they rely on training, youtubers and so many other things, probably to create more marketing, that there is less incentive to make it simple again. Engineering is taking complex and making it simple, not taking something simple and making it complex, then another complex system on top of that, then a few to decide from all that are EOL'd in a year or two.

My hope is Unity slows down a bit, works on stability, and really makes locks down some of these libraries. Though I thought that Unity would do that when they went subscription over having to promote new features every year to get you to upgrade. Subscription should have made them focus on stability, it didn't. I am hoping going public will do so, but it could also spawn more of the same.

With that said I love Unity, dig Unreal and others. But I do see people going to custom engines again that are more standard just so that breaking changes are at the whim of the developer, not the engine team that you pay for which force these breaking changes on you at sometimes inopportune times.

[1] https://en.wikipedia.org/wiki/Second-system_effect

[2] https://garry.tv/unity-2020

Your comparison was nonsensical in the first place, your entire take is painfully uneducated, but the comment you replied to is playing along. Then you're complaining they did?

Unity has created projects on a scale that would have failed if they were using a product that justifies hundred developer engineering departments to build crud apps with dynamic content...

> Unity to me seems like a team with a fantastic marketing department to contrast with a much weaker engineering department.

No one who has used Unity for any extended period of time would ever say this, and really this is where most people who use Unity would stop reading.

It hard to directly refute because Unity marketing was almost non-existent for years of their early success. It wasn't until they shifted to cloud based value-adds their marketing even had any teeth, and that was almost a decade after 2.0, which was where Unity really picked up it's stride

-

And that blog post, so much ignorance about the technology you're trying to bash!

You could find the answers to half your complaints by hopping on Stack Exchange or Unity Answers (yes, Stack Exchange, Unity Answers exists because there has an immense amount of knowledge that is Unity specific, and it predates Game Dev SO by years..

And half your complaints just read like someone who's used to a web framework that takes 1GB of ram if you leave it's creator's website running for too long.

Null behavior is due to the link between managed and unmanaged code, the two have separate lifecycles, so that's why it works that way. It's a reflection of the fact that a lot of what you use from Unity is written in unmanaged C++ so that you can actually do useful things with it...

GetComponent should be cached in Awake not because it's slow, but because that's common sense, you don't want to do more than you have to while the game is running. You want to be rendering at least every 16.7ms, why would you waste cycles peppering GetComponent calls everywhere?And as a bonus your complaint about missing editor references in code that's not called often becomes non-existant since your component fetch will fail immediately instead of at access

Also how old is this blog post, it's been half a decade since GetComponent didn't cache internally, and even before that it wasn't the reason for problems unless you were doing something really dumb, it was a best practice to cache, not a requirement for a performant game.

Really, for a title like "Unity is fundamentally broken" this list is almost comical. What's broken is your understanding of what it takes to make a game engine as widely useful as Unity, as confirmed by your first comment:

> why is it so hard to make a good game engine?

If you don't know why, you're in no position to be calling anything "fundamentally broken"

I used to do .net for a living and it was like every single interface or library I wanted to use was off-limits because it was claimed by the engine. Want to serialize your objects? All you get is an undocumented, doesn't-even-work .to_json function cause we somehow broke all the other .net serializers. Have fun!

I'd love a game engine platform that would come along and promise API/library stability for 5 years. Any game you built on that engine will be able to run 5 years later if you need to update it.

There isn't a ton that changes with game development surface level, the subsystems change quite a bit, that is fine. That is what the engine is for, to simplify the subsystems and create a stable platform on top to speed up development, not have a bunch of leaky abstractions and new unstable platforms on top of that.

I wish that game engines had more standards that were industry respected and you could bounce between engines more easily as well, like other frameworks do with standards.

We are in a "move fast and break things" age and I can't wait until it gets back to "let's move fast but not break things if we can help it unless it makes massive improvements that make it worth the cost/time and most importantly, maintenance tax on updates that aren't needed or break things for no reason. And when we do break things we will do it in a way that is parallel and if possible just swaps out the subsystem not requiring massive surface level changes that just get you back to baseline functionality".