I’m a beginner, but I’ve been tinkering with UE5 for about six months, so I have some basic knowledge. Up until now, I’ve been using BP Interfaces and Event Dispatchers to pass variables between Blueprints. Recently, however, I learned about Actor Components, and they seem incredibly versatile.
For example, let’s say I want to create a setup where, after the player collects three items, an NPC calls out to them. In my current approach, each of the three item BPs would use an Event Dispatcher when interacted with, and then send a notification to the NPC BP via the Level Blueprint. Once three notifications have been received, the NPC would call out to the player.
The problem is that this requires me to prepare three separate events inside the Level Blueprint. Of course, by binding and unbinding events repeatedly, I can make it work, but I feel like this would eventually make the Level BP very messy.
With Actor Components, however, it seems possible to have the items notify the component when they are collected. Once three notifications are received, the component could then use an Event Dispatcher to notify the Level Blueprint. That way, it only needs a single event, and the dependencies are much cleaner. It feels like a really powerful system.
That said, I’m not sure if I’m using Actor Components correctly. How do people generally use Actor Components in their projects? Also, in the case of having an NPC talk to the player after they collect three items, how would you set that up? Could you give me a detailed explanation of Actor Components?
Shouldn’t be doing that in the Level BP. You can use a simple actor in the level as the manager. Items would dispatch to it with an ID. The Actor could store the ID in an array (Add Unique) then check length. Once it reached 3 OR a custom value then it would fire its event.
Many many ways to this that are far more efficient than messing in the Level BP. Personally the only time I touch Level BP is to do something to the Level itself. Day-Night Cycle for example.
Gameplay Mechanics and events should be governed by Managing Actors or Game Mode/State.
Actor components are typically used to “Extend” an Actor class… modulization without having to create multiple variation of the parent class.
Like Firing logic for a weapon. Single, Burst, Automatic. Each would be either its own component added to the weapon. Or you could create AC’s that have single and auto, or single burst, or all three.
AC’s for Inventory Management, Character → World Interaction, Character Abilities.
Thank you for your response. I am currently working on a small-scale story-driven horror game.
From what I understand, it seems best to avoid putting too much logic in the Level Blueprint in order to prevent it from becoming overly complicated in the future. Is that correct?
I also came across some information suggesting that using Game State may consume more memory, so it should be avoided when possible. Is this true?
Another point I struggle with is the communication between different Blueprints. For example, I find it difficult to send information from a BP_Item to an NPC without using the Level BP. Since I would like to avoid using Get All Actors of Class, how should I handle this if I move the logic into the Game Mode or Game State? How can I properly reference the NPC?
Additionally, I often hear recommendations to use an “Actor Manager” to control the story progression. I have seen a few videos on this, but I still don’t fully understand how to apply it in practice. For instance, I saw mentions of using IDs for managing progression, but I am unsure how this system works in detail.
Do you happen to know of any good reference videos or resources that explain this concept more clearly? I would really like to build up my knowledge in this area.
Yes, Level BP should technically only be used to modify/update the actual map itself. You can do minor data driven updates through it but not much else. It shouldn’t ever be required to reference pawns, controllers, components on a pawn or controller etc.
BP Interfaces is the best approach to communicating between actors. Hands down!
Whether to use dispatchers or interfaces for specific communication is based on what the mechanics are.
AI/NPC’s are Owned by the Game Mode (GM). The GM spawns all pawns, Player characters and AI. When it spawns an AI you should be storing a reference of it in an array.
In general “Items” don’t really communicate in a Item gets reference to NPC/Player and pass data way. Typically Players/NPC request data from the item after some level of interaction. Line/sphere trace, Overlap etc. You’d still use an interface here.
There’s no need to move basic interaction logic to GM or GS. You’re better served putting the request logic in the actor that needs the data, and have the response logic in the actor that’s interacted with.
This is basic interaction and communication. How you setup references here for interface calls depends on how the items and the NPC are added to the game world.
NPC and Items are placed into the map.
Items are placed, but NPC is spawned
Items and NPC are spawned.
Overall the Items need a generic Actor Obj Reference to the NPC.
When the player picks up an Item, the item calls an interface event on the NPC.
The NPC updates a state, then checks that state to determine if all 3, 5, 12 etc items have been collected. If so it calls an event on itself to call out etc.
Personally my interface call would have an input that’s used to tell the npc “Which” item is calling in, thus collected. The NPC class would then have more direct information about the interaction.
“Actor Managers” are more or less “Big Picture” directors. You wouldn’t use it for the item → NPC communication. You would though for the NPC Callout.
When the NPC calls out it would also send an interface call to the Actor Manager (AM) letting it know the updated progress. Then the AM would process/setup the next “Big” thing.