Hey @Stormrage256, thanks for the reply and info, my apologies for the delay responding.
When you mentioned about checking the Does Implement Interface node, presumably this would be where the components are being added in a construction script? e.g. check to see if the interface is implemented, and then, if so, add the components.
I suppose that would give the greater control, although I could then effective “move up” this same question to another level in the hierarchy, e.g. what would stop someone inadvertently implementing a wrong interface.
Perhaps I’m thinking about this from the wrong direction, but I was considering say multiple people, same project, someone is designing the components, someone is adding those components to actors in the game. I was looking for the belt and braces approach to ensure the wrong things couldn’t happen, of course, in reality I am working on my own, but I would still like to implement that level of scrutiny and control where possible.
One thing I found with the interfaces/components (I think, I’ve been through a few iterations now and may have confused myself a little), was that the components couldn’t have the reciprocating responses to the interface calls, because they are not the “thing” which is implementing them, only the owning actor could. Whilst that makes sense, it does mean that I can’t wrap up all the health functionality, in this example, into the health component. The owning actor still has to have some awareness of things which are going on.
Is that kinda normal, or am I perhaps doing something wrong?
As I type that I have just realised that the components themselves could “implement” the interface… so, that now raises another question…>
Do you typically implement the interface on the owning actor, and then have the corresponding event in the owning actors event graph which then in turn communicates with the component, or, have the component implement the interface and then have the event wrapped up inside that.
At the moment I’ve done the former, but didn’t like the owning actor knowing so much about what the component needed to do, it also meant those additional nodes were kinda cluttering up the owning actor. The latter approach would tidy that up, but I’m not sure if it may create other issues.
Your thoughts are most welcome