Is Blueprint Interface the correct way to achieve what I want?

Development Programming & Scripting Blueprint
,
1

Hey everyone! I’m making a simple top-down space exploration / shooter.

The issue I am facing (on a high level) is sharing a common variable between different Blueprint classes.

I’m trying to implementing a radar where, if a player has gone close enough to a point of interest, it now shows permanently on the radar.

I have a working radar on screen that spawns some widgets on the HUD that is pointing toward enemies and POIs. Currently, the only POIs are 3 spawned “Station” Actors. (done via Spawn Actor from Class > “BP_Station” on Event Begin Play in a custom “LevelSpawner” BP)

The way I am currently drawing the radar is via Get All Actors Of Class (BP_Station), then a For Each loop, where I read my “IsKnownByPlayer” variable that is set in BP_Station, when the player gets close to BP_Station.

Now into the issue: These POIs are not always going to be the station. Some POIs are going to be, for example, a black hole, or an enemy hideout, or any other possible point of interest. Point is, it’s a different Blueprint class.

To me (a not particularly logical person), the logical way to do this would be with another Blueprint Interface:

So I tried to add Another Blueprint Interface (BPI_PlayerDiscovered) with a bool variable “PlayerDiscovered”. From the BP_Station I message the interface with the bool set to true when the player gets close. Then, instead of Get All Actors of Class in my radar Widget, I use Get All Actors with Interface and target the “BPI_PlayerDiscovered”. The issue I encounter with this approach is I cannot find a way to just read that bool variable in the For Each loop located in the radar widget. I can only use the interface Event (Which “starts” the “execution chain” in the BP) or the interface Message, which seems to just set the variable to the Interface default again.

Should I watch more tutorials on how Blueprint Interfaces work? All I’d like to have is a variable on each actor with a value of False that gets set to True when the player gets close ( this is currently being done in the BP_Station with a BeginOverlap Event of a sphere component). Then using this true or false for each actor that is a specified POI, it either draws the dot on the radar or not.

My last resort would be to just cast to every single POI Blueprint, then read each’s individually made “IsKnownByPlayer” variable, but as this is intended for mobile platforms, I want to be as efficient as I can (within the constraints of Unreal :stuck_out_tongue: )

Thank you so so much for reading through my overexplained issue, if you think you have any way to help or just any other ideas, please don’t hesitate as at this point anything at all helps. Thanks!!

2

IMO the problem of using Get All Actors is that it will return those that are already in range. Why not just use a sphere component on the pawn and use begin/end overlap for the radar?

3

Hey! Thanks for the speedy reply!

Range is not the issue I am facing, unfortunately. As if the POIs are not yet discovered, I want to eventually implement a scanning mechanic to guide the player toward those unknown points of interest. The issue here is reading the value of the BP Interface, or alternatively, read a variable that is “shared” between BPs (not the same value per actor, but the same variable itself, “IsKnownByPlayer”).

4

If I understood correctly: I would explore with a radar component over an interface to handle the actor states in the radar. This way you wont have to overwrite functions for each class.

5

How do you measure performance? Because casting would be blazing fast when compared to get all + interface. There should be no need to loop anything (not for the discovery part) - which is the real performance killer in BP.

  • player Begin Overlap - query actor for a POI tag, if true:
    – look it up in a map variable
    • if it’s present, it has been discovered
    • if it’s not, add it to the map (as a free bonus - you can’t have duplicates and map look-up is pretty much instantaneous)

You never mentioned POIs need this info for anything, do they?. If they don’t need to be aware they have been discovered themselves, why bother? No need for Get All, cast or interface.

it now shows permanently on the radar.

The player has a map of what they discovered. It’s a matter of translating map content to what you consider the radar - this is the area for optimisation, the way you visualise it. Specifically, how often must you refresh it.

query actor for a POI tag

If you’re dealing with complex hierarchy:

Otherwise, regular tag may suffice.

6

To debate a little: What do you think of having components manage the radar state of the actors? They’re all registered at begin play but are simply not visible until their state says so.

The radar would only care to store references in a set. The components manage themselves with save game and quests.

I know it might be unnecessary for them to be there invisible, but if the target is for eventually all be discovered and on radar at the same time then the problem would not be just efficiency, but also preallocating and managing within budget.

1 Like
7

I wrap so much stuff with components. It should work great, versatile, modular, lightweight. Since 4.27 we can Add Components by Class dynamically. The POIs may not even need components until they are discovered - but that might be an overkill.

Depending on how things need to be represented, I’d experiment with extending the widget component and script the management inside. You get 2 in 1 - management and visualisation. If the scope is medium / large, it’s probably a good idea for the set / map to contain soft object refs.

1 Like