koobas.hobune.stream
Assigning shared values easily
I often find myself using private static variables for sharing information between several instances of the same class (I'm against the general over-use of the whole Manager-idiom for reasons that I won't get into here). For instance, in a game I'm currently working on where the player can select several entities in the scene, I have this (slimmed down for relevancy);
using System.Collections.Generic; using UnityEngine;
public class Selectable : MonoBehaviour { private static List<Selectable> _currentlySelected = new List<Selectable>(); public static IEnumerable<Selectable> currentlySelected { get { return _currentlySelected; } } public void Select() { _currentlySelected.Add(this); } public void Deselect() { _currentlySelected.Remove(this); } public static void DeselectAll() { _currentlySelected.Clear(); } }
In this particular case, all is well since the behaviour itself adds the information to the static variable. But what happens when I want a GUI for selected items, say a health bar? I could solve this by making a new GameObject to the scene with its own GUI-script, but using OnGUI would be much more elegant. Here is my issue however. I obviously want a texture or two for my healthbar, and I obviously want all my Selectable to share the same texture, so how do I assign it?
What would be best in my opinion was if I could make another static variable typed as Texture, and assign it once from the editor. That obviously won't work as the Inspector in the editor does not show static variables. Another solution would be to have a public Texture defined on a per-object basis and in my Awake()-method have something like this:
public void Awake() {
if (_staticTexture == null && _nonStaticTexture != null) {
_staticTexture = _nonStaticTexture;
}
}
That way I would only have to assign the variable once and all objects would share it, but it's neither elegant nor effective having to remember what object had the actual reference.
How would you go about solving an issue like this? I'm open for all kinds of alternatives so even if this gets a couple of answers, do not feel your opinion is irrelevant.
Please note: I do not intend to have a healthbar for this particular script as all objects obviously doesn't have health. It was just an example used to explain my problem.
I'm finding it a little hard to fully understand what you're trying to achieve here, but as far as I can tell, you could do this by creating a prefab of your Selectable Thing.
You could then have the texture property as a public instance variable on the Selectable script.
Once this is in place, you can assign the texture to the prefab and all instances of the prefab will "inherit" this setting unless they explicitly override it (i.e. if you change an instance's texture in the scene hierarchy). This is different from a static variable of course - changing one Selectable item's texture at runtime won't change any of the others, but it seems to match your requirement in a round-about way.
Hope this helps.
This is - as far as I know - as close as I can get with the way Unity works at the moment, even if it's not quite what I want. The downside is that if I have 40 different kinds of selectable objects, this becomes tedious to maintain as it's see$$anonymous$$gly impossible to chain prefabs (eg, having a prefab assigned to a prefab).
Here are some other options:
- Create a prefab for your objects, and assign the texture to the prefab. All instances of the prefab will then share a reference to the texture.
- Create a central object that contains the reference to the texture. When your objects Awake, have them look up this central object (using FindGameObjectsWithTag) and ask it for the texture. You could even use the central object to hold your collection of selected objects. (If you're shying away from a Manager pattern, this solution may not be to your liking.)
As I stated above, the prefab becomes harder to maintain the more selectable objects you add, as I really want prefabs for most of my selectable objects (units in an RTS for example - as this happens to be - could end up getting a bunch of scripts and properties). The central object is sort of what I have now, except inverted. Ins$$anonymous$$d of objects looking up the texture in the central object, the central object injects the texture into a static variable. For now it works, but telling the level designer "copy+paste this object to new levels" is prone to errors.
