Our Thoughts on Using Singletons in Unity

sometimes in the awake function of a singleton a coder will check it if there are multiple instances of that object and delete them should I also do this for my player object since there should only be one Mario in Super Mario World a question about Singleton's you want to take that one Jason sir kick us off oh yeah this is this is an interesting one so I personally am NOT a fan of using that pattern specifically for anything that's not a manager so you're right technically that there should only be one player in your scene but the interesting thing about how games work is you often have to cheat so there's a lot of cases where you'll duplicate a player for the sake of some visual thing or like there's a very good example in half-life 2 I think no one wasn't half-life I don't forgot what game it was there was some game where the game didn't have vehicles so what they did is they made a character stuck a vehicle on its head and place it under the ground so it was literally a walking player with a vehicle for a head because it was a it was it was a rare case where they only needed this one odd instance now that's about the silly one but the point is conceptually that's nothing you ever think about doing but it works for a problem that they had a player to me is an entity that's active in your scene and so maybe you'd want some kind of manager class that would deal with that problem and it only has one instance but um I personally don't like to tie that kind of state logic to a single object of any kind that conceivably could have more than one there's a lot more to it than that in terms of when you're creating those kinds of managers there's also state and depending on how you manage your state if you're not persisting it out of the scene you can end up thinking you're you're deleting an object and cloning it but the version you have in the second scene is technically slightly different it like doesn't have a script you've added like when they equip something or there is a status effect in some object and so when you go to the next scene it picks not the one you think it will it'll delete the one you don't want and then keep the one you know whatever else and you end up with really odd scenarios so in short I don't recommend that pattern for that kind of an object I think I think you should have something that matter to stay and seek the instantiate a new player if he transition scenes and then sort of trying to duplicate state between them and have some sort of state manager that may have a singleton awake but not the actual actors themselves it's it's interesting to like what he just is describing is a very use case of a singleton or an implementation of a singleton that is specific to unity and it the implementation itself is doing stuff that I come from I go to my day job I work with an MVC framework called Grails and it's like a hundred percent convention over configuration meaning that if you follow the convention then things will happen a lot of magic happens behind the scenes like if you name something like visitor with a controller you put the word controller then it's it's seen as a controller in the framework and I don't like those implicit things that create magic because I personally have a really bad memory so I forget that sort of stuff all the time so and then on another note some people just don't know so there have been times where developers come on a project and they don't really understand Grails and you're like well they're they're competent developer so they should be able to help out and they do things that they did they just don't understand and it's not their fault it's just that that that particular framework relies so heavily on the convention and doing all these implicit secret things and I I think things like having an awake function that deletes a game object out of the scene in like the singleton pattern I just don't like that sort of implicit stuff because you know someone who doesn't know my like Jason said try to drag another player in just for a visual effect and all of a sudden the other player gets deleted and you're like what the heck what's going on here and then all of a sudden that developer who doesn't understand is chasing down code and even if it only takes him 15 minutes to track down the particular script oh I see here it's a singleton I mean that's 15 minutes lost that didn't need to get lost because he he thought it was a bug or she thought it was a bug and it really wasn't a bug it was a script acting as it was intended but it was doing it in such a secretive and magical way that it's like your he had to track it down and figure it out and I just don't I don't like things like that personally yeah and another thing too is depending on the complexity of your project people get very stuck on this is a major problem that bothers the hell out of me is a lot of people they see an implementation of design pattern and they internalize those lines of code meaning that design pattern but the pattern is what a problem at solving it's not the literal lines of code you're seeing it physically do so a good example of this a singleton that you're picturing is probably public static instance instance equals this or instance equals new whatever if it's not a model behavior but if you're using a dependency injection framework a singleton is just dot as single or as static or something to that effect because a singleton just means you get the ability to have more than one instance in fact if you're doing a c-sharp application say WinForms you can use something called the mutex and it makes your application a singleton it effectively means you cannot load more than one instance of it and if you ever had a have problem with if you never open a project where you wanted to have two instances side-by-side the application wouldn't let you and you got very annoyed that's a very good reason why it's don't good tunes yeah you want to let the client do that if that's gonna be something that they actually need for what they're doing so a singleton doesn't necessarily mean you know public static instance it means making sure this object can only happen once in the in the context of your code any get any method of getting this object will always return the same object that is what a singleton is the singleton instance pattern that you're used to seeing is just one implementation of it so if the real question is are Singleton's bad no can that particular version bite you in the ass probably if you use something like a dependency injection framework you can actually toggle on the instancing nature of an object and it's not as bad because you can control that at a contextual sort of configuration level but if you're baking singleton nests into an object you are forever declaring this is one thing and one thing only and it may make sense when you write it for the first time going there it's an audio manager it manages audio I only need one thing about it oh never changer well down the line you switch platforms to you know you're using f mod now or wise we weren't before and your previous order manager was master audio and everything you know what I'm just going to switch Atari I'll make a new audio manager and it uses the new system well some of that stuff doesn't play well maybe you've got certain files that have to load through unity because you're doing something with the mixer to do with your footsteps and you don't have a way at the moment of hooking that up correctly through F much no F month yes I can do all of that stuff but say you're kind of doing a part and parcel whatever long story short you find yourself in a weird scenario that doesn't make sense where you've got to audio managers now it might be temporary but you didn't see that coming so you have to be really damn sure when you're writing this is a single tuner that it really is a single day and that's why the things that normally take on the role of singleton is something where if two things took that same job the application would fundamentally break so a scene manager or an application state manager usually fits for a good singleton because it's not that you couldn't technically have two of them but is if you did if two of them your game would actually become unstable it would it would fundamentally not work the way you expect it to with two of them in it and if you ever find yourself needing two game managers you've probably broken something in your code if you're in a situation where you need to have two off the single game state running at once game instances different whatever I don't get really specific on details but the general point is a singleton literally is you declaring this can only be one of this thing because if there is more than one bad things will happen so till they are single things are bad but they can so often be misused that it's usually shorthand from senior developers to say Singleton's are bad because understanding what the caveats are but when you should and shouldn't use them are so specific that you're just better off not using them if you're finding yourself in a position when you don't know whether you should or not you know yeah and the answer so nuanced and it really does take either time to explain it or for the person you're explaining to how to have some experience with some of the pain points of Singleton's and that's that's one of the reasons why I haven't even touched it in a video yet and I've wanted to and I need to because it's a it's such a prevalent thing it seems in the he liked with community developers where the singleton like it always comes up to this day like I always see in forum posts or on on the subreddits I always see people asking about Singleton's and I don't know yeah it's just one of those things where like if you think about what you're what when you would use a singleton typically it's in a situation where it's like the easiest fix and you're like everyone's like oh wow it's so easy I'll just put in a singleton and that right there is almost suspect to me like if it's so easy that kind of makes me think maybe why is it so easy and is that okay I don't know just I'm kind of skeptical skeptical in that way yeah and again I keep boiling it down to whenever you're asking the question should I use a singleton don't think about the code itself think about what does that statement mean this thing in perpetuity will only ever have one of this thing ever then ask yourself do I need that statement to apply truthfully to the thing I'm writing it may sound like I'm saying the same thing but I'm really not a lot of software architecture people say should I use MVC here don't say that say MVC allows me to separate that the model of my code from the way it's presenting from the thing that controls it is that sensible in this case is it worth all that architecture to get that separation because I'm likely to change my model or change my presenter or change my controller so don't think of it as can I apply this or should I apply this ask yourself what it does what it's for what the pros and cons of it are and then do you need those that seems like the same statement it really really isn't

Channel: Infallible Code

Views: 9,836

Rating: 4.945055 out of 5

Keywords: prgramming, game development, unity game development, unity game dev, unity3d, unity c#, coding, game programmer, indie game dev, gamedev, game programming, unity, unity 3d, game development unity, unity 2019, unity tips and tricks, indie game development, game design

Id: x7DF4o-s0JI

Length: 10min 34sec (634 seconds)

Published: Tue Nov 26 2019