Maintaining consistent spawn locations when list order changes

I’m having what feels like a really simple logic problem: I have a persistent data manager that curates information for each individual level, and when an area streams into memory it consults the data manager, gets a list of all the items and NPCs that it currently contains, and spawns them.

Since I’m trying to keep the data manager and the individual levels decoupled, the manager doesn’t know anything about the level- all it has is an ID for each level, and a corresponding set of lists that contain characters, items, and any other persistent content that needs to be spawned.

To actually place all this stuff in each level, I place individual Spawner prefabs in areas where it would make sense for a person to stand or item to drop, and when the level is initialized it takes the list of persistent content, iterates through its list of spawners, and instantiates one item of content on each spawner.

This works perfectly well, but because I spawn my content by iterating down a list, altering the list’s indexes changes where things are; if spawner 0 is a bench, and spawner 1 is a corner, picking up the loot from spawner 0 and then re-loading the room will cause whatever was located at spawner 1 to move to spawner 0.

The only way I’ve been able to think of to avoid this would be to couple my data to my geometry more directly, and instead of using spawner objects assign each persistent object’s struct a transform to spawn at. I’m hesitant to move in that direction because it’s less flexible, but I’m not seeing an awful lot of alternatives; am I headed in the right general direction?

If you want to always spawn item 0 at spawner 0 ect. just add to list of items index of spawner. So list would be <item0, 0>, <item1, 1>,… . So when you change list of items their spawner number is still known.
Or you can leave list of items and just add flag to all if it was used. Then list will always be te same and spawner would just check if it should spawn it.

Hmm, I hadn’t considered tracking it with the index instead of the literal transform… that’s still a little coupling, but it’s much easier to live with; thank you for the suggestion. :slight_smile: