4 ms·

>GetComponent<>, possibly the most used Unity function, can easily trigger bugs because Unity does not statically verify that the component you're looking up ex

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

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.