Question Using component as basic variable container ?

Hello, I'm thinking about creating various component containing only a variable (FloatVariable, Vector2Variable for ex). Then various scripts would just reference this component. For example I will have a healthManager with a FloatVariable field and also a healthBar with a FloatVariable field too.

I want to have this structure to make it more modular, there is no dependency between healthBar and HealthManager. I've seen this kind of structure used with scriptableObj but never with component.I'd like to have it component based so it's easier to have multiple prefab instances with their own FloatVariable.

I've never seen this used anywhere else, what kind of problem would I encounter with this structure?
Thank you!

 

Hello,
a priori, in terms of workability, none. Any class is basically a variable container. If it suits you better to make them components, why not?
Now inheriting from MonoBehaviour just to store variables will clearly not be the most optimal approach.

You're literally describing ScriptableObjects.

Now you say you've never seen this used anywhere, I've seen this kind of approach quite a lot. Usually it's not for "health" or things like that that usually need to be inside another object (ennemy, player...) but often, when you're making, for example, a NoiseUtility to modify terrain, said component would rarely have something else (maybe 1 method, like Evaluate) than variables.

I have to tell you that it's really a good idea to think about the whole architecture before going on so, good for you for thinking ahead !

 

I don't think the architecture you're describing will work with Components as well as it does with ScriptableObjects. It's easy to create, reference and differentiate SOs because you can name them in the project. If you have 5 different FloatValue components attached to your GameObject, how are you going to know which is which (especially at runtime?).

 

I can make a GameObject for each FloatValue and rename the GameObject, so it's easy to see which variable is which in the inspector.

 

Watch this video:

There really is no reason to do it the way you're thinking as a much more efficient system already exists.

 

I've already watch the video and it's awesome for global variable such as player health, when there is only one variable but it doesn't work when you want to instantiate variable at runtime.
Now I've done my research and I saw some people instantiate scriptable object at run time for this kind of things, but they still need a monobehavior scriptableObject instantiatior so why not have the variable directly store in the monobehavior?

 

I mean, you do you mate. You're going to have a hard time convincing anyone here that it's anything other than a logistical and architectural nightmare.

I'll note that this only works at the scene level as well, while scriptable objects can be referenced across multiple scenes.

If you're concerned about the appearance in the inspector, you'd probably be better off investing in learning some editor scripting, or forking out for an addon along the lines of OdinInspector.