A way for example to manage several app scenes on the fly: pc.Application.loadScene() and so on. Or to make entities communicate between scenes by a sort of persistence mecanism. Think about players remaining health accross levels.
Separation of data and your scene hierarchy - is a good way to go.
If you have your player data separately, then there will be no problem of applying it to entities of player on level changes.
Although, I personally don’t like multi-scene approach. I would prefer some “async-entities” approach, but atm this is possibly only by writing a bit of bespoke code for loading entities from some other data source.
You can get Application handler: pc.Application.getApplication(). It is a single and global handler, and has events on it. So you can use it to throw events on it, for example: app.fire('level:change') then there is some other script that is subscribed to that event and implements own logic when event happens.
Events on global app handler - is quiet cool paradigm I’ve been using more and more around. It is sort of global messaging bus, that almost all scripts and other places can have easy access to.
One week later…
Thanks for the reply. Surely multi-scene is not very handy, because you have to handle things that don’t look like true assets (scene_id.json) found in project.
So, the system of events bound to the app ref, is a way I also tried, but not specially for a level (scene) change operation.
A script in ‘Script Priority’ (global script) can be used to store data accross scenes. It is easy to call a function of such a script from a scene entity, as for restoring a certain state. Isn’t it?
Even a level change should be performed like this. One will put the scenes IDs (again scene_id.json) in the global script, and then access them from an entity through the global func. It works.