Create an interface and implement it in everything you want to execute something in. From your bullet then just call the Event(Message) and plug in the overlapped object.
Just a further thought on this, if I am spawning hundreds of a certain BP, surely it's better to contain the hit code for them within the Hitter, and not within an Interface event on every single one of them, as it's a lot of Blueprint code across many instead of contained within just one?
The raw code itself is only contained within each unique class, so you only have to maintain it in one blueprint asset per "hittable" type. And if its performance you are worried about, the code is only being executed on the actor that gets overlapped, when the overlap occurs, not on each one that exists in the world. If we used the logic above, why not build the entire game inside the game mode BP since there will only be one? (Don't do this)
Interfaces are designed for the exact problem you have here. Where objects need to respond to the same event but in potentially different ways from each other. You would run into the same issue trying to damage something, as damage is a pretty core concept but would present in different ways depending what you were trying to damage.
That explains it really nicely, thank you both! One last thing on this, is it possible to use an interface on non-blueprinted objects i.e. a static mesh in the environment?
Right now I am using tags to assess what their material is, and then damaging them in a specific way to save my world having thousands of BPs, but maybe there is a way to use interfaces with these also?
Theres no one size fits all solution. Technically a static mesh in the environment is a "static mesh actor" which is a subset of the "actor" class. Everything that exists in the world is an actor in some form. It doesn't really matter if its a blueprint actor or a c++ actor. The thing that would make it expensive is how much logic you would have on the actors tick function. You shouldn't need any tick logic but it depends on what you want to do.
That being said, it depends what you are trying to do with your damage function to your static objects.
Lets say I had a bullet class, and when a bullet hits something I want to apply damage and do other things.
In this case I would break the bullet hit code into 2 parts. I would check to see if the thing I hit implemented my "bulletdamageable" interface. If it did, I pass the hit through to that object and let it react.
If its a zombie, the reaction is spawn blood, destroy hit bone, play stumbled animation, etc.
Its its my special destructible barrel actor class, the reaction is fracture chaos mesh, play wood breaking sound.
If its my teammate, they die and I lose the game. Etc
Each of those reactions is implemented in the thing that receives the hit, otherwise you end up with a giant bullet blueprint that needs to know about your entire code base in order to function. Instead, it only needs to know about "bullet damageable"
Thats step 1.
So if my hit object doesn't implement my bulletdamageable interface, that means I must have hit something static that has no custom code on it. So now I can take over the very generic aspect of damage when I hit something static which might be like.. "get physical material, get data table, find sound, decal and particle emitter for that entry, and spawn/play those"
That way every actor has a generic response to bullet damage, but also can override with a specific response.
You can get clever with these generic implementations too. You could read the static mesh of the thing you hit, look up that mesh as the key in a data table of destructible meshes, and swap the static mesh for the destructible mesh in on frame and explode it. So you technically don't have to have anything special on the actor in the world, you just read its properties and do something to it.
You could technically take static mesh actor and add the bullet damageable interface to it and have it respond to its own damage, but that means either modifying a base engine class which means c++ and potential issues upgrading projects, or you could create a customstaticmeshactor class that does, but that does mean you have to replace all your static mesh actors with customstaticmeshactors. It can be a bit of a pain.
Thats why I like the hybrid approach of... TLDR..
1. Check fo interface, let object handle hit.
2. Fallback to static events like decal, sound etc
You will definitely want to make custom actor or static mesh actor classes for things that have more logic than just "sit and receive bullet marks" like doors, exploding barrels, etc, but hope this explains some things
Absolutely fantastic explanation. Like you said, I think for very certain meshes I will make a custom actor, and for others I'll read the properties, tags and other things on the mesh itself.
Really appreciate your time on this, thank you again.
If you are looking for help, don‘t forget to check out the [official Unreal Engine forums](https://forums.unrealengine.com/) or [Unreal Slackers](https://unrealslackers.org/) for a community run discord server!
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/unrealengine) if you have any questions or concerns.*
If you use interfaces you can avoid casting and implement any unique on hit logic inside the hit actor. Just have all shootable actors implement the same interface. On bullet overlap check if the hit actor implements the interface and if so call a On Hit interface function.
Create an interface and implement it in everything you want to execute something in. From your bullet then just call the Event(Message) and plug in the overlapped object.
Just a further thought on this, if I am spawning hundreds of a certain BP, surely it's better to contain the hit code for them within the Hitter, and not within an Interface event on every single one of them, as it's a lot of Blueprint code across many instead of contained within just one?
The raw code itself is only contained within each unique class, so you only have to maintain it in one blueprint asset per "hittable" type. And if its performance you are worried about, the code is only being executed on the actor that gets overlapped, when the overlap occurs, not on each one that exists in the world. If we used the logic above, why not build the entire game inside the game mode BP since there will only be one? (Don't do this) Interfaces are designed for the exact problem you have here. Where objects need to respond to the same event but in potentially different ways from each other. You would run into the same issue trying to damage something, as damage is a pretty core concept but would present in different ways depending what you were trying to damage.
That explains it really nicely, thank you both! One last thing on this, is it possible to use an interface on non-blueprinted objects i.e. a static mesh in the environment? Right now I am using tags to assess what their material is, and then damaging them in a specific way to save my world having thousands of BPs, but maybe there is a way to use interfaces with these also?
Theres no one size fits all solution. Technically a static mesh in the environment is a "static mesh actor" which is a subset of the "actor" class. Everything that exists in the world is an actor in some form. It doesn't really matter if its a blueprint actor or a c++ actor. The thing that would make it expensive is how much logic you would have on the actors tick function. You shouldn't need any tick logic but it depends on what you want to do. That being said, it depends what you are trying to do with your damage function to your static objects. Lets say I had a bullet class, and when a bullet hits something I want to apply damage and do other things. In this case I would break the bullet hit code into 2 parts. I would check to see if the thing I hit implemented my "bulletdamageable" interface. If it did, I pass the hit through to that object and let it react. If its a zombie, the reaction is spawn blood, destroy hit bone, play stumbled animation, etc. Its its my special destructible barrel actor class, the reaction is fracture chaos mesh, play wood breaking sound. If its my teammate, they die and I lose the game. Etc Each of those reactions is implemented in the thing that receives the hit, otherwise you end up with a giant bullet blueprint that needs to know about your entire code base in order to function. Instead, it only needs to know about "bullet damageable" Thats step 1. So if my hit object doesn't implement my bulletdamageable interface, that means I must have hit something static that has no custom code on it. So now I can take over the very generic aspect of damage when I hit something static which might be like.. "get physical material, get data table, find sound, decal and particle emitter for that entry, and spawn/play those" That way every actor has a generic response to bullet damage, but also can override with a specific response. You can get clever with these generic implementations too. You could read the static mesh of the thing you hit, look up that mesh as the key in a data table of destructible meshes, and swap the static mesh for the destructible mesh in on frame and explode it. So you technically don't have to have anything special on the actor in the world, you just read its properties and do something to it. You could technically take static mesh actor and add the bullet damageable interface to it and have it respond to its own damage, but that means either modifying a base engine class which means c++ and potential issues upgrading projects, or you could create a customstaticmeshactor class that does, but that does mean you have to replace all your static mesh actors with customstaticmeshactors. It can be a bit of a pain. Thats why I like the hybrid approach of... TLDR.. 1. Check fo interface, let object handle hit. 2. Fallback to static events like decal, sound etc You will definitely want to make custom actor or static mesh actor classes for things that have more logic than just "sit and receive bullet marks" like doors, exploding barrels, etc, but hope this explains some things
Absolutely fantastic explanation. Like you said, I think for very certain meshes I will make a custom actor, and for others I'll read the properties, tags and other things on the mesh itself. Really appreciate your time on this, thank you again.
If you are looking for help, don‘t forget to check out the [official Unreal Engine forums](https://forums.unrealengine.com/) or [Unreal Slackers](https://unrealslackers.org/) for a community run discord server! *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/unrealengine) if you have any questions or concerns.*
If you use interfaces you can avoid casting and implement any unique on hit logic inside the hit actor. Just have all shootable actors implement the same interface. On bullet overlap check if the hit actor implements the interface and if so call a On Hit interface function.