Hello! I’ve been following several tutorials in an attempt to make a functioning game (mainly an inventory tutorial, talking to NPCs tutorial and quest tutorial). All 3 of these tutorials mention needing an interaction interface. I firstly just made separate interaction interfaces for them all, but then I wondered whether I could just fuse them all into one interaction interface as they shared the same functions sometimes too (such as the actual Interact function and also a LookAt (the physical item) function).
What would be the best thing for me to do in this instance? I’m not sure if it is standard practice to just have 1 universal interaction interface. Thank you!!
Often, all you need to be able to say is ‘you have been interacted with’ to the actor, and that’s enough. That’s because, to a door, ‘interact’ means open, but to a book, ‘interact’ means pickup, unless you’re holding it, then it means ‘read’. And so on…
Sometimes, you might need to pass an int ( for example ), and less often, get a result back. Then you can build the interface spec with a couple of parameters.
I have two, in fact. One is just the ‘interact’ interface, and the other is a function which takes and returns a ‘payload’ structure, which is just a struct consisting of an int/bool/vector/array of float/etc.
there are a couple different ways you can deal with this, but in pure blueprints you will often be limited in the parameters your functions can deliver, and it will depend on what needs to know about what?
for example if I want the Door to know something about the object that is interacting with it, then I will probable need to pass in either the full Object that is interacting (in the form of an actor, or maybe in the form of a component) or just some int/enum meaning “The interacting thing is X”
another context there is the instigating object knowing about the object it is interacting with, this would be that the Object being acted upon having some kind of int/enum meaning “I am an X” so that when the Interact is invoked the result is more meaningful.
the last context is that neither of the objects actually know about each other where Interact is invoked, based on State Thing either happens or it doesn’t and maybe a reply (these can often be harder to work with as at some point calling interact on an ItemPickup might expect an Item to be returned in some form.
personally I lean toward the object having some int/enum and a parameter-less Interact() returning like a boolean in the interface.
first the Instigator checks the int/enum if it is within an acceptable value it then invokes Interact() and uses the boolean return and the int/enum to maybe do casting and call things beyond that.
sometimes if I want the communication to go “both ways” I will through in a CanInteract() and give both the CanInteract() and Interact() a parameter of some game specific component that has its own things that can be checked against:
for example if I have a ItemPickup and a Pawn (NPC or player) has some kind of MyActorComponent that has a pointer to the inventory the MyActorComponent is passed to the Interactable asking “can this Actor interact with this” which then if that returns true the Actor can then do something to call the Interact(MyActorComponent) which if that returns true it means the Interaction was successful (in this case it could mean that a UI screen should be opened, or just an item was added or not depending on implementation)
a payload based system would be more versatile and generalized, but at some point that payload needs to be constructed either through like a C++ Lambda/delegate or binding a Blueprint event. which both of these still require one of the 2 sides to know something about the other if not both.
an implementation of a purely Blueprint interaction system can be seen through the “Crop Out” sample project. it does nearly cast-less interactions, and “seamless” UI transitions all in Blueprints.
in the Epic Games Launcher-> Unreal Engine (left side of the interface) → Samples (top of the interface) → Crop Out (you may need to scroll down to “UE Game Samples”)
you are freely allowed to use any part or all of these “UE Game Sample” in even a commercially released product (the only stipulation is that it is used in Unreal Engine, you do not assert ownership of such assets for redistribution, and that you are in good standing with Epic Games [you would know if you weren’t])
