- Home /
Adding custom data to built in components
Is there any way to add extra fields to the built-in components?
For example, if I have an AudioSource, and I want to add another field to specify, say, whether its volume should be randomly adjusted by some amount (a float would suffice to store the value, and I will have another script that will read the value back). Can I add the data somewhere to the actual component? How can I store extra data about components in the scene if they're not custom components (i.e. I can't just find the source code and add a new field)?
Answer by Bunny83 · Sep 30, 2011 at 10:08 PM
Components are build to achieve a very specialized task. An AudioSource can playback an AudioClip at the objects position and have some parameters it need to complete it's task (like volume, pitch, dopplerLevel). Components (especially built-in) can't and shouldn't be changed. It's a modular system, each component / behaviour do what it has been created for.
If you want to add functionality to a GameObject you should write a behaviour script and attach it to the object. If you write a script that changes the volume randomly and it needs to store extra information this behaviour should hold this data, because that's the place where it belongs to.
That's actually the whole point of OOP. A class is a collection of data and functions that is created for a specific task. You don't have to worry about how it performs the task internally all you have to know is how you can use it. That's why we have the accessibility-modifier so stuff that belongs to the class that is needed internally but shouldn't be changed be the user is marked as private or protected. Only public fields / methods can and should be used by the user.
Usually to extend a class you can derive your class from another to inherit all of it's data and behaviour. However all Unity classes are marked as "sealed" because they don't want you to derive from their classes. Only the MonoBehaviour class can and should be used as "interface" between Unity and your stuff.
I would argue that in OOP the desired approach would be to extent (subclass) the AudioSource and add the new fields there (I would be making a specialization of the class, that inherited the normal behavior and then added my own functionality) - however, since the classes are sealed this is not possible. It's more a philosophical argument than a practical one however, since its not possible (because of the sealed nature of the AudioSource class).
I ended up just making a new class that has all the fields on AudioSource and then the extras I wanted, and used that to construct an initialize the AudioSource in the manner I wanted at runtime. This also allowed me to modify the default values (since some of them were not appropriate to my use).
I totally agree but even in OOP there are multiple ways of doing things ;). In usual application development you would derive from a base class and extend it's functionality. However long inheritance chains will reduce the performance needed in games, that's why a lot of games (and engines) use the strategy-design-pattern ins$$anonymous$$d, like Unity.
Every object in game is a GameObject. It can actually do nothing but you can attach behaviours and components to give the object the desired functionality. It's like a big plugin system ;) That keeps the inheritance-chain quite short and open up even more possibilities. In C++ you can derive your class from several base classes but not in C#. If you have a Renderer class and a $$anonymous$$eshFilter class you can't derive your object from both classes. The strategy gives you the power to plug the components together in almost any possible combination.
Answer by kevork · Sep 30, 2011 at 09:43 PM
You can store that data in the script component that you are creating to randomly adjust the volume.
Your answer
Follow this Question
Related Questions
handle gameobject Component in c# 3 Answers
Flash raw animation data to Unity 0 Answers
Cant destroy object, dont know how to fix help pls 1 Answer
Unity editor bugging out 4 Answers
UNet bugs all over the place, fixed after re-building the Player prefab. 0 Answers