5 ms·

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

by johnfn 6y ago

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. 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-e3b1474e7afb42bdb05cadcd3c2dbd77 https://www.notion.so/UnityIsFundamentallyBroken-e3b1474e7af...

ImprobableTruth 6y ago
>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.
- johnfn 6y ago
  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.
  - DonHopkins 6y ago
    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. Components do have an enabled flag. https://docs.unity3d.com/ScriptReference/Behaviour-enabled.html https://docs.unity3d.com/ScriptReference/Behaviour-enabled.h...
    - johnfn 6y ago
      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!
  - nikki93 6y ago
    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.
- DonHopkins 6y ago
  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. https://blog.jetbrains.com/dotnet/2019/02/21/performance-indicators-unity-code-rider/ https://blog.jetbrains.com/dotnet/2019/02/21/performance-ind... >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.
  - johnfn 6y ago
    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.
    - ezconnect 6y ago
      Unity is a game engine first, the quality of their product will suffer if they have to teach all their user to program properly.
      - johnfn 6y ago
        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.
andybak 6y ago
> Unity doesn't mark old features as deprecated 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.
- johnfn 6y ago
  Absolutely. Here's a few examples, though I could produce a hundred more: AssetBundles. Not marked as obsolete. Not marked as deprecated. Unity docs look fine, with no references to anything else you should do: https://docs.unity3d.com/ScriptReference/AssetBundle.html https://docs.unity3d.com/ScriptReference/AssetBundle.html. They are in fact obsolete anyways. See here: https://learn.unity.com/tutorial/assets-resources-and-assetbundles# https://learn.unity.com/tutorial/assets-resources-and-assetb... "this tutorial has now been deprecated. We now recommend using Addressables for your projects" 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!
  - andybak 6y 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)
TremendousJudge 6y ago
I'm currently learning unity, and even for very, very basic stuff it's impossible to know what's the "correct" or "intended" way of using the engine
xex70 6y ago
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.
- johnfn 6y ago
  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.
  - xex70 6y ago
    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.

by johnfn 6y ago

ImprobableTruth 6y ago

>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.

johnfn 6y ago
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.
- DonHopkins 6y ago
  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. Components do have an enabled flag. https://docs.unity3d.com/ScriptReference/Behaviour-enabled.html https://docs.unity3d.com/ScriptReference/Behaviour-enabled.h...
  - johnfn 6y ago
    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!
- nikki93 6y ago
  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.
DonHopkins 6y ago
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. https://blog.jetbrains.com/dotnet/2019/02/21/performance-indicators-unity-code-rider/ https://blog.jetbrains.com/dotnet/2019/02/21/performance-ind... >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.
- johnfn 6y ago
  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.
  - ezconnect 6y ago
    Unity is a game engine first, the quality of their product will suffer if they have to teach all their user to program properly.
    - johnfn 6y ago
      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.

andybak 6y ago

> Unity doesn't mark old features as deprecated 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.

johnfn 6y ago
Absolutely. Here's a few examples, though I could produce a hundred more: AssetBundles. Not marked as obsolete. Not marked as deprecated. Unity docs look fine, with no references to anything else you should do: https://docs.unity3d.com/ScriptReference/AssetBundle.html https://docs.unity3d.com/ScriptReference/AssetBundle.html. They are in fact obsolete anyways. See here: https://learn.unity.com/tutorial/assets-resources-and-assetbundles# https://learn.unity.com/tutorial/assets-resources-and-assetb... "this tutorial has now been deprecated. We now recommend using Addressables for your projects" 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!
- andybak 6y 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)

TremendousJudge 6y ago

I'm currently learning unity, and even for very, very basic stuff it's impossible to know what's the "correct" or "intended" way of using the engine

xex70 6y ago

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.

johnfn 6y ago
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.
- xex70 6y ago
  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.