It's really not as much of a stretch as you might think.
Let's put aside everything that the two libraries actually do for a second, and just think about them in the abstract. React very clearly tries to guide the developer towards correct patterns and abstractions. It's clear that React developers have thought very deeply about how to lead engineers towards the happy path of code with fewer bugs in it. It throws loud errors and warnings if you do something that could even potentially lead to an error down the line. They deprecate and eventually remove broken features. And it almost goes without saying, but they finish the features they're working on, rather than leaving them in the codebase in a half-finished state.
Unity does none of these things. Unity doesn't mark old features as deprecated: you could be using a deprecated or obsolete API for months without ever recognizing it because the only communication Unity gives you is a post on the Unity blog post from years ago. (This has happened to be multiple times.) Unity doesn't tell you when you're doing something wrong - you can still StartCoroutine with a string, even though you should be using a function reference. Unity absolutely does not try to lead your code towards the happy path of fewer bugs - GetComponent<>, possibly the most used Unity function, can easily trigger bugs because Unity does not statically verify that the component you're looking up exists, so if you forget and remove it later, your code will crash. React is very intentionally designed not to have problems like this.
>GetComponent<>, possibly the most used Unity function, can easily trigger bugs because Unity does not statically verify that the component you're looking up exists
I'm pretty sure checking this statically is simply fundamentally impossible since components can be removed at runtime.
You should usually only call GetComponent<> in your Awake function, then cache the result in a strongly typed instance variable. This is widely known standard operating procedure with Unity.
IDEs like Rider will highlight and warn you about using GetComponent in performance critical contexts like your Update method.
>Unity has a number of methods that get called very frequently. For example, MonoBehaviour.Update is called every frame, as is LateUpdate, and FixedUpdate can even be called multiple times in a single frame. Rider treats all of these methods as performance-critical, and will highlight the method in the editor gutter.
[...]
>Once inside a performance-critical context, Rider enables a number of inspections:
>Avoid usage of GetComponent methods
>Avoid usage of Find methods
>Avoid usage of AddComponent
>Avoid string based method invocation (Invoke, SendMessage, etc.)
>Avoid Camera.main
>Avoid null comparisons for Unity objects
>The links above will take you to the documentation pages for each of the inspections, which provide more details of why the method calls are highlighted, and what you can do to avoid them. You can get to this documentation straight from Rider, like with many other inspections, with the “Why is Rider suggesting this?” Alt+Enter menu item.
Totally and completely agree with everything you've said, but the fact that Rider - a 3rd party IDE - has to ensure all these things rather than them being baked into Unity is part of the problem.
But Unity isn't an IDE, it's a game engine. Totally different things. Better for Unity to spend their time and energy on the game engine and editor, not making yet another half-assed IDE. Developing an entire IDE simply isn't in their wheelhouse. While it's a lot easier for somebody like Rider who already has a full blown C# IDE to support Unity.
The thing is, avoiding usage of certain functions - like Find, Invoke, SendMessage, etc - does not have to be done at the IDE level. In fact, it shouldn't be, and the fact that Rider has to do these things is kind of a kludge already. These methods should be marked obsolete - or at the very least, they should have docstrings saying not to use them. Observe how the docs for SendMessage don't even discourage its use, for example: https://docs.unity3d.com/ScriptReference/GameObject.SendMess...
The Unity editor gives you compiler errors and warnings in its console window. Why shouldn’t it give you these warnings as well?
The Unity editor also has lots of features that IDE’s have already, including a profiler, ability to inspect the world hierarchy, inspectors for components on that hierarchy, and ability to pause and restart execution.
I can't understand how this is the case. Unity is a game engine which keeps users mostly by instilling goodwill that it's a productive environment and is saving them time over using another engine or homebrewing one. It would therefore seem to be in its best interest to prevent them from creating bugs where possible.
That's true, but I've always thought that removing components at runtime is such a rare thing to do, and the cost of allowing it on an engine level - inability to statically verify components - is such a high price to pay that the tradeoff just doesn't make sense.
If I was czar of Unity (ha!) I would never have allowed AddComponent and RemoveComponent to be a thing - I would have required the user to add all of the components they expect to need at edit time instead. The dynamism that Unity currently affords rarely improves my game, but it does lead to a lot of bugs. If users really want to turn components on and off, they could have an enabled flag.
Being able to add / remove components then query based on component sets an entity has is an important part of ECS data driven design, which Unity is trying to move to with eg. DOTS. Just leads to less branching etc. once your data is prepared. I'd rather just have my code express expectations upfront then query the entities that match, vs. needing to handle a combinatorial explosion of if/else based on existence checks.
Well so much for dynamic and procedural and data driven content, under your reign as Unity Czar. People use Unity for a lot more than Flappy Bird clones, you know.
Well, I would certainly hope that as my reign as Unity Czar would include guidelines for storing procedural content somewhere other than in Components :)
I mean, if you're adding a new component to a GameObject for every room in your dungeon or something, you're doing something very wrong. At least in my opinion!
Are you sure? My IDE (Rider) shows gives me a tooltip for any methods that Unity has declared deprecated. There's also console warnings and big notices at the top of the docs.
Package Manager also clearly marks certain packages as experimental or deprecated.
EditorUtility.SetDirty(). Rider says "Marks target object as dirty. (Only suitable for non-scene objects)" and it's not marked obsolete or deprecated. Seems fine, right? Nope, it's been deprecated since 5.3. To their credit, the full Unity docs do reference this, but who is going to consult Unity docs for literally every Unity function they ever use, in their entire project? It should be right in the IDE. Better yet, the function shouldn't even exist! Unity 5.3 came out over 5 years ago!
Hmmmm. Is it possible that a tutorial is deprecated without the actual feature itself being deprecated? i.e. there's no intent to get rid of AssetBundles in the near future but they don't want people who are just starting out to go down that path?
I can see that's a gray area (you are kinda deprecating it by doing this) but the strict definition of deprecation probably involves a pledge to remove that feature in a certain timeframe.
I'd be much happier to bitch about the stuff Unity has officially deprecated without having a good timetable for a replacement (Networking, Real-time GI) or done a terrible job of communicating the situation (Steam VR is "not officially supported" sounded pretty apocalyptic whereas it turned out to be not quite so bad - Valve had taken over responsibility for support and their solution was released to beta with a month of the doom and gloom corporate-speak announcement)
Maybe we're talking about two different things? To me, once you add a new feature intended to replace an old one, the old feature should be deprecated and should eventually be removed. Even if you can use AssetBundles, there's no reason you ever should because they've been superseded.
I've always thought that that is deprecation, but I could see your argument that it's not.
Fortunately I haven't had to deal with the officially deprecated features without a clear replacement. I can imagine that would be very frustrating.
> Even if you can use AssetBundles, there's no reason you ever should because they've been superseded.
You might have to use a superseded feature because you're maintaining old code. If Unity cares about backwards compatibility (admittedly, I'm not convinced they do), they need to keep supporting and documenting the old features even as they nudge you away from them.
Sure, but if that's the case, you should really be pushing new developers away from using the old thing and towards the new thing. Mark it obsolete in the editor. Update your docstrings to point towards the new thing. Maybe even give me a warning in my console if it's really serious.
The 'Addressables' are a abstraction layer on TOP of AssetBundles. AssetBundles aren't deprecated.
Honestly most of the criticisms you've gave are you not understanding how something works - like GetComponent.
I do agree with you on 'null' though! And how Unity uses it. I think that decision came from them trying to make it more beginner friendly to deal with destroyed/removed objects when it first started - then they had to live with it
If X is built on top of Y, and I should generally be using X, then the docs for Y should absolutely say that. Burying that away in some hard-to-find tutorial is not good practice. We could argue for a while over the exact semantic meaning of 'deprecate' and whether Y is truly deprecated if 99% of the time when you use it you should really be using X instead. But I'd hope that we can both agree on the central point of my argument here, which is that in Unity it's often incredibly difficult to figure out which of 5 vaguely-similar-looking APIs you should be using, and it's a bad sign when the best source of info is a "coming soon!" message on an out-of-date tutorial not even linked from the documentation.
Perhaps you should explain how I've misunderstood GetComponent.
The whole purpose of using 'GetComponent' in code is to get the component reference at runtime. Saying it's a problem that it doesn't statically verify it exists, doesn't make any sense
I understand that GetComponent is a runtime lookup, and what I'm arguing is that Unity made the wrong choice. Runtime lookups lead to more bugs. They lead to slower code.
The best practices that have sprouted up around GetComponent say "Use GetComponent<> only in Awake(), and don't use AddComponent or RemoveComponent at all." But once you start following all these best practices, you've lost all the benefits of having GetComponent be dynamic in the first place. So just enforce it at a code level, and give me the benefits of static typechecking and compile time errors when I screw things up.
AAA here. Actually, it is a stretch, because you’re expecting an entirely different discipline of software development to reflect the trends, knowledge, and assumptions of your discipline. We are a CryEngine shop but I’ve used Unity extensively for MVP pitches, spec work, and side projects. I also left the Web vertical to do this so I still have context from your side as well.
I took the time to read what you’ve written. Just about every single point you made in that essay can be distilled to “Web developer with strong convictions about Web software engineering and expecting game development to look like familiar territory,” with only a couple exceptions. I read that essay and I walk away with “that person is going to have a hard time if they pursue professional game development,” not the intended conclusion you had about Unity’s lackings. That’s reflected in nearly every concern about Unity expressed in this thread because this is a Web forum.
Unity has deficiencies we are all aware of in the industry, but none of them are in your essay. Several of your points are misunderstandings, several are just wrong, and all of them paint a picture which also gives a lot of AAA shops pause about hiring Web folks (and that I’ve had to deal with): there’s a pretty strong strain among the Web industry of “if you don’t do software like FAANG does, you’re doing it wrong and your stuff is terrible.” Meanwhile, the stuff you call bad/terrible/worse is generating billions in revenue and employing thousands. Seriously, Unreal is worse than Unity? Nearly stopped reading there.
I’m reminded of a friend who does control development for factories and had someone come in straight from a Google internship who started trying to reimplement SCADA from first principles using Kubernetes. The Web is one way to do software engineering. There are others, and one of those others is reflected in the design of Unity.
Game programming isn't—or at least shouldn't be—so different from other fields that fundamental software engineering principles do not apply. It seems like discarding criticism just because it comes from outside the immediate industry is going to lead to an insular culture and get in the way of any real change or progress.
Doubly so for an industry that still has high-profile, highly funded projects (Battlefield V, Anthem... etc) flounder because of technical debt and poor tooling. (And yes, these issues are all downstream of awful management for those particular projects, but that doesn't change the technical side of things!)
This goes in the other direction too: other fields can and should borrow ideas from game programming. At the end of the day the goals of different software projects are pretty comparable: we all want to produce quality code, minimize bugs and do it as quickly and productively as we can. The details and trade-offs aren't identical, to be sure, but at the end of the day different programming fields are far more alike than not.
Sure theres similarities, but game programming is usually at the bleeding edge of computing compared to most other areas. Its like saying engineering a space craft isn't/shouldn't be different than engineering a car. Sure, there's overlap, but the fundamental requirements differ so much that a lot of it is _not_ applicable.
I'm not a game developer, but I like to keep an eye on how its done specifically because it is fundamentally different from how I typically do things in SAAS / mobile app land. Its a good way to get a broader view on development, and I learn new things _constantly_ by looking at game development.
I'll happily hear examples of things which are "misunderstandings" or "just wrong". As your post stands, it's nothing more than a long extended ad-hominem - it roughly boils down to "your post is wrong, but I'm not going to tell you why."
I accept that Unity and Unreal Engine are doing fine financially and will probably continue to do so for a long time. That's no reason that they can also have issues.
Quote one sentence where I attacked you personally. I was quite careful to speak about your essay and its conclusions from the perspective of the intended audience, and if you think I’m going to engage after having that called an ad hominem, you don’t really understand the investment of time that would entail and why I’m strongly disincentivized.
A few quotes that I found particularly rough include:
> Several of your points are misunderstandings, several are just wrong
Like I said, I'd be happy to hear ways that I can improve. You saying that I am wrong but not providing specifics makes me feel bad without a way to improve my thinking.
> “that person is going to have a hard time if they pursue professional game development,”
You're passing judgement on my professional abilities, which makes me feel pretty bad. It's also an ad hominem: you've stopped attacking my argument and you've started attacking my professional character.
> “if you don’t do software like FAANG does, you’re doing it wrong and your stuff is terrible.”
Is it really necessary to include the thing about FAANG? I'm not even employed by FAANG. To me it feels like you're casting me out to be a FAANG elitist, which feels pretty alienating. It's also an ad hominem: you've stopped attacking my argument and you've started attacking me as a FAANG employee.
> all of them paint a picture which also gives a lot of AAA shops pause about hiring Web folks
Is the absolute "all of them" really necessary? That you dismissed every one of my points is pretty rough. Can you imagine if you wrote a 4000 word post and someone said "yeah I read it and every point you made gives me pause." and that's all they said, no further explanation? You'd probably be pretty frustrated, wondering what could possibly be wrong, but having no clue with which to even start understanding their different perspective.
> I’m reminded of a friend who does control development for factories and had someone come in straight from a Google internship who started trying to reimplement SCADA from first principles using Kubernetes.
You're comparing me to a friend that overengineers things. If you have specific things you think I'm overengineering, I'm happy to hear them, but a comparison like this without any concrete steps makes me feel bad without providing me a way to improve.
Perhaps your error is marrying yourself to your creative output and taking criticism thereof personally. Your essay is all over the place and plays a tune many folks in AAA have heard from many folks who got their start in Web development, and I was illustrating the broader context that, again, makes your intended audience develop that conclusion. Honestly, it reads like a projection of your expectations of software development, and that’s what I’m trying to tell you.
I was not accusing you of overengineering, I’m not accusing you of working for FAANG (I don’t even know you, come on), I was making the point that people default to where they’re comfortable, and if you’re going to put yourself in a a position of authority and claim that Unity is bad (and Unreal is worse), you need to be comfortable in the environment and practices in which they are intended to be used. There is a minimum level of comprehension required to criticize an implement of another profession, otherwise someone proficient in COBOL would pick up a torque wrench and ask “why is this necessary? This design is just bad.”
You used subjective indictment terms (“bad,” “worse”) to describe positions that you don’t have experience to develop. That’s fine. Elevate your argument and understand the why behind some of them. Example: we don’t give two shits about deprecations because they’re a distraction from a ship date and we ship vendored artifacts including the engine.
You selectively quoted more than one thing I said to twist a personal attack from them, by the way, but that’s your prerogative. It’s also odd to do when you’re crying ad hominem foul.
Edit: I took the time to read your essay, respond to it candidly, and we are ending this conversation with you lecturing me on tone, politeness, and productivity. Even in the face of great hems and haws I doubly endeavored to remain polite. One would be forgiven for thinking you are not approachable with criticism.
I understand your point about not elucidating the why. Thing is, I'm not an AAA developer, so often times I don't know.
All I'd like to know is a bit more on why specific points my essay were wrong. Like, if you don't think the thing about clearing the Debug window is correct, I'd like to know why that is.
I'm too lazy to write 1000 word essay from my phone, but having a bit of experience in both webdev and c++ gamedev on custom engine I certainly can say one truth here.
FAANG literally spend billions of dollars on developer tools alone, not even including browser runtime itself. There are thousands of engineers who work full time to make web and tools both fast and easy to use. There is also tons of open source developers competing to create best tools for other developers. And let's be honest tasks that average web developer has it's not rocket science.
Gamedev is nothing like this: resources are ever limited, budgets are tights, and there is almost never ending crunch to release ASAP. Till recently every AAA company mostly used it's own tech and everything was not only proprietary, but always closed source so only papers were shared. Oh there also proprietary secret under-NDA targets called consoles where you cant just expect user to buy faster hw and more RAM. And skills you expected to have to work in AAA as C++ programmer can be more than in let's say SpaceX.
So first of all you don't see how much better gamedev tools became in last decade. Other issue is that no one gonna hold your hand and force you into best practices because all games are mostly built of hacks and if you gonna enforce some strict rules it's mean developers wont be able to get those extra FPS, or better network latency or some absolutely unsupported feature that no one ever needed before.
Let's put aside everything that the two libraries actually do for a second, and just think about them in the abstract. React very clearly tries to guide the developer towards correct patterns and abstractions. It's clear that React developers have thought very deeply about how to lead engineers towards the happy path of code with fewer bugs in it. It throws loud errors and warnings if you do something that could even potentially lead to an error down the line. They deprecate and eventually remove broken features. And it almost goes without saying, but they finish the features they're working on, rather than leaving them in the codebase in a half-finished state.
Unity does none of these things. Unity doesn't mark old features as deprecated: you could be using a deprecated or obsolete API for months without ever recognizing it because the only communication Unity gives you is a post on the Unity blog post from years ago. (This has happened to be multiple times.) Unity doesn't tell you when you're doing something wrong - you can still StartCoroutine with a string, even though you should be using a function reference. Unity absolutely does not try to lead your code towards the happy path of fewer bugs - GetComponent<>, possibly the most used Unity function, can easily trigger bugs because Unity does not statically verify that the component you're looking up exists, so if you forget and remove it later, your code will crash. React is very intentionally designed not to have problems like this.
I wrote like 4000 words on this topic, if you want more detail. Feel free to dig in if you'd like: https://www.notion.so/UnityIsFundamentallyBroken-e3b1474e7af...