creating a singleton of the player to persisit throughout the game

  • Hi!

    This question could be applicable to 3D development as well.

    How do I instantiate the player as a singleton in scene one and then keep the player persisting throughout the game?

    Can someone help with a little bit of code or a pointer in the right direction?

    Thanks in Advance:)

  • If you mean the 3d object of the player, then it wouldn't be a singleton. However if you have a player class that needs to persist because it is holding data that you need for the duration of the game then you should use the doNotDestroyOnLoad function.You should check to see if another exists.


    now if you want the player itself to move from scene to scene and not have to have a new player object per level, I do that a bit differently. The player of mine has its own scene, own camera and its own lighting. This scene is never unloaded during gameplay. Scenes are loaded alongside this player scene allowing the player to travel seamlessly between all scenes. This is used mostly in games that have no loading or transition scenes.


    Hope one of these is what you are looking for.

  • Thank you very much for the reply. How is it possible to Load scenes alongside one that is never destroyed? Can you please explain that a little bit more? I do not understand the " The player of mine has its own scene, own camera and its own lighting. This scene is never unloaded during gameplay. Scenes are loaded alongside this player scene allowing the player to travel seamlessly between all scenes." bit.

  • IMHO it's not so important the player prefab's persistence but its stats. The stats are the ones you'll need to maintain from scene to scene.


    So in that case I would recommend to use one empty gameobject with the singleton script attached to it. In that script you'll have player stats, whatever other values you need to maintain during the game, setters and getters, audio manager, etc ... and the DontDestroyOnLoad.


    This is an example explained by Jonathan on his courses



    You create an empty GameObject and attach the GameManager script into it. Then you can call those methods from other scripts to initialize or modify values.


    For example:


    Code
    1. GameManager.Instance.Score = 0


    You can add to the singleton whatever you want ... live points, score points, booleans to check, bullets amounts ... everything you need to use in your game on every scene.


    I hope it helps :)


    EDIT: Now that I'm seeing, this script doesn't contains the DontDestroyOnLoad, but it should work. There are other ways to create a Singleton, this is one of them.

    Here you have other way to do the same



    It works like a charm also.

  • Be aware of Singletons! They're actually an anti pattern and shouldn't be used. There are better ways how you can solve this problem. My two recommendations would be:


    Either use a DI-Framework or use ScriptableObjects ( Scriptable Objects ).


    With both then will have the benefits of:

    • Testability
    • No direct dependency to the real implementation
    • No directly link to a certain GameObject
    • Reuseability
  • Be aware of Singletons! They're actually an anti pattern and shouldn't be used. There are better ways how you can solve this problem. My two recommendations would be:


    Either use a DI-Framework or use ScriptableObjects ( Scriptable Objects ).


    With both then will have the benefits of:

    • Testability
    • No direct dependency to the real implementation
    • No directly link to a certain GameObject
    • Reuseability

    You have a point. There are endless discussions about using singletons is good or bad.


    I get the anti pattern definition, but I also think that using them in a moderated way can be benefitial.


    If you're working solo and on a small project, using a singleton shouldn't cause you any trouble. It's different if you're working on large projects and as a part of a team.


    I'm actually working on a small project for mobile and I'm using just 2 singleton scripts, one for game management stuff and the other one for player management stats. That's it.

    They are really useful and I'm taking care of not messing with them :D


    I think it's great to know when to use it and if it's worth it.

  • It really doesn't matter if you're working alone or on larges project in team (I do both). They always reduce your code quality heavily. You can easily check your code quality by trying to write tests for it. Writting a proper unit test for a class using a Singleton is nearly impossible cause of the mocking problem.


    But there is also another problem: Every singleton is reducing your reusability because your classes just know too much:



    So the RelayOnGameManager-Class knows who is manipulating the data. But that information is completly uselss and expensive. That you could easily solve with a ScriptableObject in between of both:

    When you know pass the same GameData-Asset to all classes you have the benefit of Singleton without having the disadvantages.


    And never forget: Every big project has started as a small one. And the bigger your project becomes the more painfull are architectual mistakes.


    So I really would recommend you to follow best practices and usefull patterns and principles. I wouldn't accept anti patterns otherwise they one day might become a habbit.


    ----


    I know - programming discussions easily can turn into really toxic discussions. So to say it clearly: I don't want to offend anybody. I just want to give advices based on my knowledge due to my daily work as a software dev. In the end you (= everyone who reads this thread) have to decide about how you'd like to write your code.


    Last but not least: Cause nobody of us has to work with each others code we can give a fuck on the others code quality - so no need for emotions or toxic talks :-P