koobas.hobune.stream
Making a static class derive from MonoBehaviour in C#
Hello!
I'm just learning about "more" objective oriented programming in C#. I already made a small mobile game in UnityScript, but that turned out as spaghetti code.
Is it possible for a static class to inherit from MonoBehaviour? Because i'm making some classes like GameManager, SoundManager, UIManager etc. I want to be able to call functions on these from any GameObject, like so:
GameManager.SetScore();
SoundManager.PlaySound();
Without having to have a reference to the specific manager. Hence, I want them to be static. However, i'll need to use the built-in functions like Update, Awake etc in these managers. It seems I can only do this if the class derives from MonoBehaviour, and it can't if it's static. It just throws an error.
Am I thinking backwards here? If so, please tell me how you would do these managers. Thanks!
It's more complicated to code than the static approach, but I often make these Singleton classes ins$$anonymous$$d. Depending on what they're doing, they might have a Scene lifetime or exist for the whole lifetime of the Application (in the the latter case I'd usually put them in a loading or bootstrap scene ie one which is only entered once, on starting the application).
An advantage of this approach over the static way of doing things is that it enables you to give them public variables that you can set in the inspector, making it easy to tweak things.
Yes, I tried making a Singleton class like that. Like the one they make in the Unity 2D Roguelike tutorial, if you've watched that. But I found that a major flaw with that approach is that you have to load the bootstrap scene in order for the game to work. This is pretty annoying when testing levels out etc...
There are several possible ways around that.
Often it means that that particular manager doesn't need to have an application lifetime (like I said, with some you want to make a new one for each scene).
Another approach is to use lazy application-lifetime singletons, ie they're created when first required (you can still get the advantage I mentioned in my final para above, by creating them from prefabs).
Or I might use both the bootstrap method and the lazy one. For example with a class managing localisation I might have an instance in my bootstrap scene which checks the device's locale and loads the strings for the right language. But when there isn't a localisation manager (including when I've bypassed the bootstrap scene while developing in the editor), a simple lightweight one is created on the fly which doesn't need to bother with any actual localisation.
Like I said, the Singleton approach is more complicated. But it's also more powerful and flexible.
Well one thing you can do is, have static classes for these and call the required functions from the Monobehavior funtions of other classes. For example, say you have a SplashScreen UI that has a Monobehavior. In its Awake() you can call GameManager.init(), SoundManager.init() and do the initialization of the managers. Also instead of having Gamemanager and SoundManager their own updates, call the appropriate functions in the manager classes from the updates of other monobehaviors. Hope this helps.
So I could have like a $$anonymous$$anagerController or something, that's instantiated on the scene, and just calls functions on the managers on update / awake etc? That sounds like a pretty good idea! Thanks. :)
I'll keep this open to see if anyone else has another suggestion.
This would be the best way to approach this. For reference you may want to use a Static Constructor aswell, assumu$$anonymous$$g you are using c#. Take a look here for the documentation: https://msdn.microsoft.com/en-us/library/k9x6w0hc.aspx
Why dont you create only the methods you need static as static and let the class untouched?
Well, I'd still need to instantiate the class as a script on a gameobject then, right? I would prefer not to have to instantiate all of the manager classes i'll have, since it's unnecessary.
Can you give us some background do what your Game$$anonymous$$anager and Sound$$anonymous$$anager do? As for example if they need to use the $$anonymous$$onoBehaviour events frequently maybe having a $$anonymous$$onoBehaviour with some static methods could be a good idea as long as you are comfortable with static members mixing with non static members.
You could try having a single $$anonymous$$onoBehaviour called Events to simply manage calling certain static methods from your managers from Update, ensuring that only one $$anonymous$$onoBehaviour exists and you can keep the managers as purely static classes.
Copied from my comment:
"You could try having a single MonoBehaviour called Events to simply manage calling certain static methods from your managers using Update() or Start() or FixedUpdate() or even OnLevelWasLoaded(), ensuring that only one MonoBehaviour exists and you can keep the managers as purely static classes."
You could even go into using Interface events. I haven't tried this myself but try reading the MSDN page about it here: https://msdn.microsoft.com/en-us/library/ak9w5846.aspx
Yeah you can do that, it's called a Singleton. But the inspector would need to built as it could never be selected nor attached to a game object unless you want to mix instances with singletons. For my project I am putting those into an EditorWindow which can always stay visible, and made to appear from the Window menu. It seems there is multiple ways to do things, which is nice.
