So I know that a working object reference system is what you want but I don’t think it’s what you need. Let me explain, take it or leave it.
It sounds like one goal is to allow level designers the freedom of level design without requiring a programmer. But what is described would require a programmer for the following:
- Changing the number or class type of characters that are spawned
- Changing the class type of pickups that are spawned
- Adding/removing pickup spawn locations
- Adding/removing character spawn locations
I think a better and more modular architecture would allow a level designer to control all of these aspects without a programmer involved. This would allow rapid iteration of different scenarios and level layouts, all without bringing up a window with any code.
The way I would approach this would be to create a new actor blueprint that is a
BP_ActorGoalSpawner. It would have the following data types defined in BP:
- Array of classes to hold Characters to Spawn
- Array of classes to hold Pickups to Spawn
- Array of object actor references to specify Character Spawn Locations
- Array of object actor references to specify Pickup Spawn Locations
- Optionally I might turn Pickups to Spawn into a struct that also has a data member for an interest value to map desirability to a particular pickup type.
Now a level designer can drag a new
BP_ActorGoalSpawner into a level and with a couple clicks can fill it full of the Characters and Pickups they’re interested in. Then they could drag out
EmptySceneComponents to indicate where they want their Character Spawn Locations and Pickup Spawn Locations, simply add those to the relevant object array of their
BP_ActorGoalSpawner through the world outliner and they’re done.
Now a level designer could try various scenarios without any programmer involved:
- A group of pirates invade a space station searching for power cores and food.
- A group of scientists enter a space station and are looking for research.
- A bounty hunter enters the station and is looking for his kidnapped daughter.
Another bonus of this architecture is that if someone were to try and delete any of these objects that are referenced by the
BP_ActorGoalSpawner, it would pop up a warning saying that the actor is in use. Also, if they rename any of these pickup locations, the underlying references would remain intact.
Now, none of what I’ve outlined has anything to do with . But obviously where would shine here is that the implementation side of this blueprint is so simple that you could sketch it out during a casual conversation on your lunch napkin. Things similar to this:
Anyway, food for thought, this is an architecture I would lean towards and advocate.