When user closes my game I’m saving all game objects, that has been instantiated during runtime. When user opens my app once again, what I want to do is to continue from the same spot they’ve exited my app, so all those objects needs to be insantiated. So when user opens app at first he sees menu scene, if he/she clicks continue button, than I’m going to load game scene and spawn all previously saved objects,. However I’m not sure when to do that, instantiating many objects in Start function doesn’t seem correct, since it could take a while I guess and I’m thinking that could cause some trouble, but I can’t think of an alternative…
There’s not really one way to do things, rather, programming is about thinking up the easiest solution to match your specific needs, and implementing it. This starts with making a list of what all of your needs actually are, the things you need to work around, and the possible approaches you can think of (and adding to this from research). I will say though that you don’t really save GameObjects as a rule- you save the minimum amount of information necessary to recreate those GameObjects when loading.
Say you’re making a traditional JRPG and your characters grow in strength based on a level system. If your character stats are deterministic (one without “randomness”, meaning based entirely on the character and level), then you don’t need to store them in the character save file- all you need is “character: CharacterA, level: 17” (saved and loaded from Json or XML or whatever), and then you can recreate their stats from algorithms / tables when the game is loaded. You should always be thinking about the absolute minimum amount of info you need to recreate the state of the game, and avoid the mindset of dumping the contents of an entire scene into a save file somehow. The scene is a visual representation of game data, but for your own sanity, it should not be your game data.
As for the timing / manner in which the level itself is loaded, it’s really up to you. If your game doesn’t feature a save/load system per-se, but rather just autosaves for the current profile, and that profile is loaded by default when the game launches, then you can do your loading just after the splash screen and before the main menu. If you use a save/load system, you’ll have to wait until the specific save game is selected to load in the main menu.
In our case, we’re quite fond of one-scene games, and don’t really use the scene system in the typical manner. Our services are also not MonoBehaviour-based, so the startup sequence you’d find familiar in MonoBehaviours (Awake/Start) aren’t something we have to worry about either. I would imagine that the initialization process and loading save data depends a lot on the specific way in which that save data is stored and managed though- you may have one central system that does all of your saving in one place, then fires events/notifications when information is saved or loaded, so that the various other systems in the game can respond appropriately, or each individual system may have its own save/load procedures completely disconnected from eachother.
In short, there’s not really a “one size fits all” approach to this. If you google around for save/load systems in Unity though, you’ll find a ton of examples, like this one. One of them is bound to be pretty close to what you need, or at least give you an idea of how to implement one that meets all of the criteria.
Loading from Start seems fine- you shouldn’t be performing operations that directly touch on external GameObjects in Awake, so you really shouldn’t be running into initialization order problems with that. Look into coroutines if you want to spread the load over multiple frames (though with a basic load screen, it really shouldn’t matter if it’s a sync or async operation IMHO). Look into the Script Execution Order list and put your load behaviour dead-last if you do run into initialization order issues with other systems not being full prepared at the time that they’re called from your load system.
@DonLoquacious
Thanks for detailed answer, but I’m aware how to save/load data, I do save small data, like location of object and few other flags, than I just spawn this prefabs where they used to be. My concern is about when to spawn this prefabs and how to deal with issues if spawning those prefabs take long. I could load scene when splash screen appears, but than again question still persists, when do I spawn my saved objects?
Instantiating from prefabs is a sync operation- you can use a coroutine and put a frame or two between individual instantiations, but that’s the only real async-like spin you can put on it, and it’s rather weak and not truly async at all. It just means your little animated load icon can move another fraction of a degree to look like it’s not completely stalled, which I guess may be significant to some people, but it’s a micro-optimization for release- more important perhaps is that it may also give logs a chance to post in debug mode so that you can tell if/where the bottlenecks are.
There’s not some hidden function I’m aware of in Unity where you can affect this process in any significant way- if spawning takes too long, simply reduce the amount being spawned. Look into object pooling and start pooling common objects before the level is actually loaded in order to offset some of that work when it is, for instance, or break your load process into multiple stages so that most of the common objects are loaded at the splash screen, but the specific scene structures aren’t loaded until switching over to that scene.
The timing of whether to load after the splash screen or after the main menu doesn’t feel significant to me, otherwise. Or with Start or some Post-Start initialization function with a delayed invoke to avoid initialization order problems. Do what feels better to you for your particular game.