koobas.hobune.stream
How to mimic Unity's Components based System
Hey everyone,
I'd like an insight or opinion about how to implement a good component based system.
Example: Whenever a GameObject gets a Rigidbody Component attached, the transform gets automagically altered when running the game due to PhysX. From what I understand is that Unity checks all GameObjects for their components and plugs them into it systems.
Now my question is how I would go about doing the same thing with custom components?
Let's say I create a component that makes a GameObject touchable (adds a boxcollider2D too). I don't want every GameObject to run an overlapPoint on itself to see if it was touched. I'd rather run that once and the object found accordingly, let's call that class InputManager. This already means I have to write a component and a system that works it.
How do you guys setup the necessary system? does every component register itself to the InputManager, where that instantiates itself on the first call (singleton)? Or do I keep an InputManager System on a GameObject in the scene which searches the whole scene in the beginning? Or just check the touched GameObject if there's the corresponding component available and call stuff on it? Do I need to do that for every component, write an outside system? I mean, this is how Unity works, right?
It might help if you could explain how this is about using Unity3D. Right now, the question is more about how not to use Unity.
I would assume one of the reasons Unity wants us to use AddComponent (ins$$anonymous$$d of just a new) is because it does register every Component with the proper handler, at Start/creation.
Every component Unity provides works right out of the box. Add a Rigidbody, Object falls down. Add a Collider, Object collides. Everything just by adding that. I would like to design a component, if added, that makes the GameObject selectable. But not by querying the Input-Class in its Update function. That would basically mean every GameObject would do that. Ins$$anonymous$$d there should be an InputSystem which checks the Input once and works with those Components. Just like PhysX works with Rigidbody Components. I don't know how to explain this any better. $$anonymous$$y guess is that NOT the Rigidbody component itself is doing calculations but PhysX is, and on GameObjects with one such component. Therefore I'd also like to create such a System, that operates on Components. But I don't know what the best way is to get those together properly.
I think what you're asking is clear enough. What isn't clear is how it relates to you making a game using Unity. In general, we purposely don't care how Unity does most things, unless they have quirks that can affect the game.
Could you explain this further, I think I don't get it. Who is we (Devs or Users) and how is not caring about how things work a bad idea? I just want to adapt to good practices and patterns and try to understand how Unity uses them.
Another example would be a health component. Adding that to a GameObject would give it the possibility of losing or receiving a certain amount of a total amount of health. But HOW would then dying be implemented? Health doesn't know about any animator or what GameObject it is the health of (Boss, Ship, Player?)
There must be some greater "$$anonymous$$d" interpreting and handling that ("if health == 0, kill the guy by doing that and that and that). So again, there's the component, but something else ("System?") must be running the show, which needs to know about all "Health" Components to handle them properly
Singleton is good especially if you want to keep data between scene. Make legacy to make vector of mother. And then you can use it to call update of all children. If a component requires other , test if the component is null.
