I’m really trying to wrap my Head around coupling. Obviously No one wants to couple blueprints in Unreal Engine, however I’m not sure best practices to remove this when Blueprint communication is such an essential part of game development.
Here is What I know, and I hope you can clarify and expand on it!
Casting: Casting checks if an actor type is a specific actor and gives you access to the variables, But this creates a hard reference
Interfaces: Interfaces are generally better than casting for firing event based logic in actors without needing the full reference. I’ve recently learned that this still creates a hard reference?
Get (All) actor of Class: Does this create a hard reference? I use this all the time to get my HUD class to fire interfaces. I know the standard one gets the first instance of the actor in the world and the other will get ALL actors but can be expensive
Event Dispatchers: This one I probably know the least about. Does this create a Hard reference? I found little value using these since you need a reference to trigger it anyway, creating a hard reference. It was useful in the Level Blueprint where you can reference other actors easily
What are best practices to avoid decoupling? I like using managers for certain things, but my lack of programming background is clear here.
Yes, because you’re still mentioning the blueprint type.
Not related. These will always created a connection. The job of dispatchers in a one-many communication.
The secret of decoupling is to only use actor class references, or generic engine types ( like static mesh, player character, player controller, game instance etc ). Notice, not a reference to your ‘typed version’ of these.
For instance, you can talk to your controller by using an interface to talk to the generic player controller reference. Same with your player and game instance.
Maybe you can give a specific example, then I can describe how to do it without a hard ref.
So, we could say it’s ‘bad form’ to reach into one blueprint from another, and make it do stuff. It means that BP-a knows about the inside of BP-b and that’s called tight coupling. Which is what you’re experiencing.
It’s hard to say exactly what to do here, because I don’t know your setup, but the first port of call, is to ‘ask’ the player to do this for you, with an interface message. Then it all happens in the player, and your hard ref stops existing.
I’m guessing you probably have hard links between your player and all the weapons, could be wrong. If you want to know, go to the content browser, right click on your player BP and choose ‘size map’.
If there are hard links, you’ll see all your weapons are loaded at the same time as your player.
I notice you talked about ‘weapon parent’. This is a good thing because you make your parent fairly minimal, and put all the particulars in the child BPs. Then your player can have a reference to the parent, no problem, it has hardly any effect.
You can also ask your player for a reference to the weapon parent, but if you start casting it, you get more hard links.
I Assume because they can See all the variables in the player and they also are hard referenced? Kinda like if you reached into a pumpkin to grab one seed and all the interconnected seeds come out in that tangled gooey mess. (only metaphor I can think of)
I did open my size map and only see my weapon parent so thats good. only exception to this is my starting primary and secondary weapons since the weapon class is an inputs on my spawn weapon function which is run on in weapon parent. then outputs it back to my player. So just because they are mentioned, they appear on my size map. I understand now.
I do also see my HUDClass in there.. Although there is only 1 and it does need Values from my player (health, ammo etc) So like you said, better to get player character, run an interface function in my player like this ammo here. And then it outputs the data and doesn’t need to “peek inside” the player and exposes its innards?
Yeah, that looks fine You can always tell from the size map.
I does take a while to get used to, I had to rewrite loads of stuff once I found out about it.
Is this to get the weapon status on a widget? You could always write the weapon parent so it can make a widget or talk to one. That keeps everything related to the weapon, in the weapon.
Generally speaking is easier to get objects to handle themselves, rather than trying to do it from a central area.
BTW: There may be a very good reason you’re passing this info out of the player, so you can just ignore me in that case…
This particular Ammo Script is for my Reserve ammo, My player carries it around so it can be reused. Current Magazine ammo is stored in the weapon.
As you suspected, this interface function serves both the math for reloading and for updating the Weapon tray in my HUD, both of which are handled in the weapon parent with an interface message.
I’d like to connect with you to go over all this coupling stuff in more detail. I have a YT Channel and this is a very under taught and not understood concept and I try to keep learning and passing on info as I learn it. Basically the Mass Majority of Channels say Casting Bad, don’t do it. And Interfaces Good Do that all the time. Which I know isn’t necessarily true, and it’s a bit deeper than that.
because you make your parent fairly minimal, and put all the particulars in the child BPs. Then your player can have a reference to the parent, no problem, it has hardly any effect.
You can always tell from the size map.
