I just added a Box Collision to my NPC, to become able when the Player overlap the Box, that it plays a sound.
I added a Check if the overlapping Actor is a Player by using “Actor Has Tag”. Otherwise the NPC fire the Event itself. And this is the Point i dont like. I feel this is the wrong way to solve this, or is it well done?
To be clear. The Blueprint i´ve done works. It feels just like an unclean and bad way to me.
I want to improve my skills and learn! So how “you” would solve/do this Blueprint to make it better?
I personally try to avoid using component tags as much as possible, (anything I have to manually type in is prone to errors, although sometimes it cannot be avoided).
Two ways I would do this. One is simple, and one is more complex (which is how I actually do it).
Simple way:
I would not use the tag but insead cast the other actor to player character, if that succeeds then continue like you have, except for the way you handled the sound. I would use “spawn sound at location”, becuase this will give you a reference to the audio component that you could then bind the “on audio finished” event to if you need to do something when the sound is finished. It also gives you an “is playing” function so that you do not need to create, set and unset that “sound active” bool.
Complex way:
I would create an actor component named “Affiliation Component” which every character in the game would inherit. This component would have some variables on it that allows me to choose which teamID and affiliations each character has with other teams. I would also implement a function on the component called something like “Compare affiliations” which would take in two affiliation components and return weather the two characters are friendly, neutral, or enemies, and what team they are on. I would also implement an interface which gives easy access to the component with a getter function. And again I would use the spawn sound at location again.
Looks fine to me. If your goal was to play the sound when the player approaches the NPC from any direction, then it’s ok.
You may want to refactor it later, when things get a bit complicated. The same could be achieved by casting OtherActor to the PlayerCharacter. Cast failing ignores non-player entities. A successful cast gives you access to the player character which you might need for additional interaction.
While tags may seem prone to mistyping (they are), if you use inheritance they help weed out the unwanted entities.
edit: I now see Steve’s informative answer. Using components + interface like this is a grown-up and modular way to approach things in BPs, agreed. Gives you scope for expanding this beyond simple interaction.
I was sure that my BP´s is “ok”, but im aiming to be more professional…
I think i´ve learned a bunch of Stuff in the last time and i´ve done already a lot of things in Unreal.
But it does not make me happy anymore that things are just “working”.
I want to start to make things right, as they should be!
Thats why i sad already in the above Comment, that i will go for the Components.
Im not shame to say i did not even know about them. I should spend more time on the Unreal Docs. But there are so huge… and its surely more fun doing things and playing around some times as just reading and learning
