« first day (4574 days earlier)      last day (740 days later) » 

Curio
Curio
08:45
I'm wondering if it's good practice to use "static" in this way:
I have some classes that need to be called in a lot of scripts. For example, I have a DialogueManager that makes appear dialogues on the screen. So I just have to write DialogueManager.instance.MyFunction();, where instance is a static variable, whereas MyFunction is a non-static function of DialogueManager. I used the same approach for MouseCursor and in general for every one-instance gameobjects in my scene. Is that correct?
 
6 hours later…
DMGregory
DMGregory
14:33
@Curio What you're using is called the Singleton Pattern. It's a common thing to reach for because it makes it easy to get a reference to your dependencies. But it does have some drawbacks.
The biggest one is forced uniqueness. The fact that there's only one instance is deeply embedded in the pattern. If you ever find you need two instances (say, to support local multiplayer where two players can each talk to a different NPC independently), then you suddenly have major refactoring to do.
With something you're very confident you'll only need one of - like a mouse cursor - this is probably not a huge risk. (Though do watch out, if you want to support tablets with multi-touch, might those touches need to behave like multiple "mouse cursors"?)
They're also often a form of mutable global state, which is a common place for bugs to arise. Since every piece of code everywhere can access the singleton and ask it to do something anytime, it's harder to coordinate those actions. If somehow the singleton gets into an invalid state, you have a tough job puzzling out which call from where made that happen, because it could have come from literally any file anywhere.
They can also make unit testing more cumbersome, since you can't as easily create a mock interface to pass into your test, and instead have to arrange a bunch of global state to test against.
A lot of these problems are difficult to completely avoid in Unity, since things like FindObjectOfType<T>() let pretty much anyone access anything from anywhere anyway. And for classes with a very well-defined responsibility and clear contract, the problem of bugs accumulating from improper uses hidden somewhere in the codebase is manageable.
If you want to avoid some of these issues, one strategy is to use a Service Locator - often your "Game Manager". Instead of saying "Hey you, the only Inventory in existence" you instead ask the locator "Can you direct me to the Inventory that I should use for player 1?" - that makes for a smaller refactor if you ever need to add multiplayer or other reasons to have more than one of a formerly-singleton class.
Another common strategy is dependency injection / inversion of control, where you pass the service that's needed as an argument. So when the player object interacts with the NPC, instead of saying "Talk to me... but go find the Dialogue instance on your own", it says "Talk to me with THIS Dialogue instance". That way each character (or test) can provide their own instance as needed, with no global state to contend with.
Curio
Curio
15:14
Thank you for your super detailed answer :)
DMGregory
DMGregory
15:43
You'll find singletons can be kind of polarizing in gamedev circles. Some folks take an extreme stance that singletons are always wrong to use, other folks use them everywhere even where there's neater ways to achieve the same goal. My usual recommendation is to just use them with caution. Check if there's a better way for each instance, but take advantage of their simplicity for cases where their drawbacks aren't an issue.

« first day (4574 days earlier)      last day (740 days later) »