3 ms·
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
by 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 agoWell 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 agoWell, 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 agoBeing 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.