koobas.hobune.stream
Persistent Scene
I seen Unity's Adventure Game tutorial and I've tried to make Persistent Scene that would manage all persistent data and Loads, Unloads other scenes. Is this Idea good? Does making one persistent GameObject with childs is better, and why?
A lot of your question sounds like advice on an architectural decision, and frankly that's something that really is up to you. I will say that this idea is possible and that I personally have used it successfully. Whether it's good completely depends on what the rest of your game will be like.
With regards to any performance or extensibility concerns, there is no difference. Using DontDestroyOnLoad() to make a persistent GameObject has the effect of moving that GameObject to the 'DontDestroyOnLoad' scene, which is already a persistent scene that gets created as needed. If you only really need a monobehaviour or two to run persistently, this is the easiest way to do this.
The main reason to use a persistent scene that you create by hand and load in via SceneManager would be if you have a number of objects and scene settings that you want to apply globally and persistently. Generally, in this case, the other scenes are conceptually part of the whole that the persistent scene represents, rather than complete scenes themselves.
I am currently working on an open-world game that uses persistent scenes not just for persistent data but also global objects such as the UI, sun lighting, and networking, and even to apply global lighting settings. This is a good example of where Don'tDestroyOnLoad is less useful than a persistent scene- I don't need to apply an extra component to everything or create another script to instantiate them, and I can see changes immediately as I change them in the editor.
A previous project of mine, on the other hand, had a single persistent GameObject with a few large scripts that simply controlled networking and did simple IO for player save data. This is an example of where persistent scenes are unnecessary and cumbersome, as all of the functionality was fairly simple, and this way I could load and unload scenes as usual without needing to do any sort of scene management whatsoever. In this project, scenes corresponded to levels, and there was no need to do anything with them other than load the next one in.
So, long story short is, it depends on what you're making. This is a choice you have to make as a developer, and it largely comes down to the structure of the rest of the project. There are pros and cons when it comes to workflow, but no big difference in how any of it works behind the scenes.
Better late than never (and for those who will land here after me): Yes, it is a useful architecture. As @Zarenityx said, it depends on your game, but if you run into any problem with singletons as suggested by him, you would look into this solution. I am currently building an extended scenemanagement library (because there is one on assets store, but it is 22 bucks).
Basically you have to run the 'control-scene' with the gamemanager and scenemanager, where you can load and unload depending on an event.
