koobas.hobune.stream
How do I get information about objects in scenes that haven't loaded yet?
I'm building a game where I want to scatter some items around the world in various different scenes.
I have some randomization logic that takes a graph of nodes (places where an item could be) and edges (items required to traverse the space between nodes) and then gives me a list of which items should appear where - I can store this globally just fine and my scenes can spawn the appropriate item on load.
I'd like to be able to place and configure the node and edge data while editing my rooms in the Scene editor, but I need to get a graph of all of the nodes when the game first loads in order to pre-determine the item locations. I can plot nodes and edges within a single Scene just fine, but as soon as some of them are in a non-active Scene, I don't know how to get at them.
I can't randomise the items when the player enters the scene, for various reasons - they need to be randomized before play begins, when the player starts a new game.
I want to avoid having the node/edge data in separate files to the scene (e.g. just load it from JSON) because then it can get out of sync with the game itself and it'll be a pain to keep up to date during level design.
The loading zones between scenes are treated as nodes as well - the center of a room has an edge to the loading zone, and the logic class can already stitch the rooms together as needed if I can find a way to make GetNodes(scene) work.
Why does the graph relationship have to have anything to do with the game objects in scene? You know you can have a data structure which represents your game state that isn't in game objects right?
You can instantiate it at any time and manage it completely separate from unity and then reference that state in your gameobjects.
That said, nothing happens before play begins. Not in your unity application. Play is running that application.
To having something run before your application runs you will have to run it in a separate application and then figure out the best method for the two to communicate.
Oh sorry misread that you need it at editor time:
Why cant you just do it in a start or awake call, you can specify in Unity which script gets prioritised/ ran first?
And if you are doing that I dont really know why you need to do any graphing. The transform hierarchy is a graph that would already exist.
I found a solution to this by adding a SceneAnalyzer object that, when the scene is run from the editor, saves a .JSON file with the needed information. Then when I create a new save file, I load all the JSON files and do the randomization then.
Sounds like a decent case for singleton-like pattern. Create some kind of object, build a class, store the data in the object, keep it alive across scenes, done.
What you're describing is global, persistent game state to me.
You don't generally want to create a class that only stores data and does nothing else, but I am sure you could move some functionality within such a class in a coherent way.
Of course singletons are bad and can be abused, but they're also very effective, simple, and convenient when used within reason.
Unfortunately, this doesn't help with the need to know what checks will be in future (not yet been loaded) scenes when running the randomization logic. Once I have the randomization information, I do plan to store that in a singleton.
As I asked earlier. Why do you need to do it before it's loaded. What it sounds like you are trying to do is a post load action.
i.e. load the scene, do something with that data then start your game
I need to randomise the location of items between different scenes - i.e. sometimes the double jump should be in the chest in forest_1, and sometimes it should be in the chest in volcano_peak. This means I need a list of all the possible locations when I'm rolling to randomize the items' placement. I could achieve this by loading a file with a list of all the chest locations, but I was hoping there was a way to do it from the live data.
I can't do it on load as I need information about which chests are reachable with which items from the players spawn, which is encoded into the nodes in each scene.
A few things:
You dont need a singleton to manage game state
Making classes just to store data in memory is an absolutely fine reason to create classes
Singletons aren't inherently bad but abuse of global/ static state is normally their primary function here it seem. i.e. its an anti pattern because its to substitute for a lack of understanding of the better ways to do it with a complete ignorance of all the problems inherent with it.
So basically everything I already said.
I already mentioned the pros and cons. No one said a singleton was required. Everything else is completely debatable.
You've added zero value to this discussion.
