Dependency injection in blueprints?

I have a character in my game that can be in many different states. In each different state I want the input buttons to do something different. For instance, if the character state is WEAPON_SHEATHED then the attack button simply unsheaths the weapon. If WEAPON_READY, the attack button attacks. I have a bunch of other states as well:

  • CARRYING_OBJECT
  • CLIMBING_LADDER
  • HOLDING_TORCH
  • SWIMMING
  • etc etc

At the moment on input I am doing a dirty branch chain that just rolls through and checks the player_state enum and “intercepts” the button press. This is long winded and inflexible and I hate it. What I want to do is delegate my input calls to a player state class that performs the action, and swap the class out whenever the state changes.

I have built this whole projects in blueprints so far - I’m not scared of c++ if I have to go that way but I’d like to keep it in blueprints. Is there a way in blueprints to have dependency injected classes like this? Does it need to be a component? A Variable? A totally separate blueprint that the player class messages? Is this doable in blueprints or am I going to need to fire up visual studio?

Thanks in advance!

1 Like

Just use a switch (here’s a list of already built-in switches for reference). Put the switch right after the input button, and the input will “switch” what it does based on the current state.

That would definitely neaten up my network thanks! But it doesn’t quite provide the modularity I’m looking for. I have other things occurring in the blueprint that rely on that state and they are all getting messy as well, and could be solved elegantly if I can use some composition in my blueprint. I believe this kind of injection can be done in C++ but I can’t see a way to express it in blueprints.

Then this may be what you’re looking for: Event Dispatchers (beginner), Event Dispatchers (advanced).

Other than that, if things are getting too messy, collapse your nodes to either a collapsed graph or a function; this is the equivalent of putting written code into collapsible branches.

I have an itembase with empty events and each child does what it needs to do with the event.
In the player I have an inventory with the reference to the “active” item and so only the input to that item is sent.

Ok, I see what you’re doing. You’re using actors for each weapon & item.

Weapon & item systems can be implemented many different ways. The way you’re doing it is not how I would do it. I would make the weapon & item part of the character; that way, I don’t have to communicate between blueprints. But I’m just gonna work off what you have already.


NOTE!: Don’t know why I forgot about this: you can get the input directly in the weapon blueprint, so you don’t even need to communicate with the player character or controller.


Tbh, your current setup is as simple as it can get when using multiple actors: you’re calling the events directly on the actor, which is the most direct way of communication. Here’s what I think you should do to make it more organized:

Put all the basic functions (fire_pressed, fire_released, etc.) in the base class and use functions, not events. The reasons why are (1) all events are put in the same graph (Event Graph) (i.e. they don’t get put in their own graph), and (2) it’s more logical to make a function of the actor a “function” (something the actor does) rather than an “event” (something the actor reacts to). Also, don’t have an event for “Play_Anim_Reload”; use animation blueprints for animation (though, if your animations are simple, you can use animation montages).


If you want a weapon or item to react to something (e.g. a gun changes colors when the character takes damage), you should add an event for that and bind it to the character event. If this event should happen only for a specific weapon, then make it part of that weapon’s inherited class to avoid filling the base class with something that’s unique to only one weapon.

Here’s an example of using events to make a gun change colors when the character takes damage:

Material:

Weapon:

Fire:

Result:
https://streamable.com/4dbq77

Notice how there is no code for the player controller or character pawn. The weapon is only responding to the event of the player taking damage.


Event dispatchers are for when one actor is supposed to broadcast to many actors. For example, if the character had a walkie talkie, the character could speak through the the walkie talkie, and the message would play to all other characters with walkie talkies.

Thanks for the extensive replies! @DomusLudus if I understand correctly, you have a fire_released event in your item_base class (essentially an abstract class) and then you extend that class into your weapon_base class, where you implement that function. Then in your character controller you have a local variable that references one of the child classes and gets switched out when gameplay demands it? That seems like what I want to do here. What is that item_base class, an actor component?

An @midgunner66 pulling the input straight into the child blueprint class makes sense in this particular instance, but I have other functions and events that also need to access this ‘state’ class - including pulling variables and calling functions on the state class so I really want it to be its own separate class. I have also learned a couple of things from your blueprint screenshots thanks!

1 Like

yes, even the nude hands are a Item.

is a normal Actor, I spawn it and add it to an array in the inventory.

hm ok, so your inventory has an array of instantiated actors (as opposed to class refrences), and somewhere you’re managing an index key to reference the inventory item in question?

yes, you need spawn the classes to used

And a simple change item function

but if I started again I would like to change the item classes childs for assest data

Very cool, thanks for the screenshots. And data assets are compelling as well. Thanks for the info!