GameObject properties collection can be added to?

So, I feel the answer to this is no, but here goes.

I have various GameObjects in my project with their various behaviors controlled by multiple scripts attached to each.

I would like to have a property on the GameObject ITSELF that the behavior scripts could read, as opposed a public variables placed in one of the scripts that I have to reference from each.

For example, let's say I wanted to, in certain points of the game, turn whole categories of behaviors on and off.

I could:

1. Try to remember, one by one, the set of behavior component scripts on each of my list of GameObjects and call a BehaviorOn() or BehaviorOff() routine in each.

>>Obviously problematic as the GameObjects grow a more diverse set of behavior scripts.

2. Make a separate component script that has BehaviorON() and BehaviorOff() methods that then calls all the various BehaviorOn() and BehaviorOff() routines on the various behavior component scripts.

>>Also problematic because the script name cannot be reused easily, thus still relying a a list to be remembered.

3. Make a separate component script that public variable BehaviorON that could be set to true or false that I need to reference in all the behavior scripts.

...or maybe a dozen different variations, all to accomplish what I actually want to accomplish which is setting a property of the GameObject itself

Can one simply make and set a property of a GameObject in Unity? Something that does not need a component referenced?

 

Pretty sure you can't extend GameObject like this. But a couple of fairly simple things you could do:

This seems a little sloppy, but you could add a static boolean property to the behavior script, and call it "BehaviorOn". Since it's static, there's one and only one value for it. You could set it to true or false depending on whether any instances of that behavior should be active currently. Then, within the class itself, you could check whether BehaviorOn is true or false before doing something. The advantage is it's a single property to toggle that would affect all instances of that component, and no need to go finding the instances. The downside is the components might still be using up a fair bit of resources even if BehaviorOn is off, and it feels kind of ugly.

A better approach would be to create a singleton class that keeps track of instances of objects of a given type. In the Awake() method of your class, you register the instances with the tracker, and in OnDestroy you unregister. The tracker might just keep a list of all registered instances of each type. Then, when you need to do something that affects all instances of a particular type, you can easily iterate the tracker's collection of these, enabling or disabling the component, or setting arbitrary values.

Lots of ways to do what you want, but those two came to mind.