Thank you for checking this video out! In the next video I will talk about event dispatchers! Cheers guys!

The problem with this is that you implemented the "interact" event in both the switch AND the hidden door, this means that in case the overlap event of the player's capsule fires (might happen) while standing on top of the hidden door, the player can press E and the door would open without the need for the player to interact with the switch. The correct way of doing this is implementing another function in the blueprint interface that handles "indirect" interactions so you can send the "interact" message from the player's blueprint to the switch's blueprint "interact event" which then fires off and send the "indirect interact" message from the switch blueprint to the hidden door's blueprint "indirect interact" event. Doing this you completely avoid the "bug" I described earlier. I hope this might help.

The most simple way is to add the interface "Interact" to all interactable objects, then fire a linetrace from the camera view of the player and check if it is hitting an interactable object, if it is then call the interact function from the interface (it does all the things you want the objects has to do calling every time the same function)

Just started learning UE5 and was making action blueprints for every interaction. This has saved me from so many future headaches and streamlined my game logic.

Thank you i have been strugling with this for months, watching many tutorials and never really grasped the concept until I found your tutorial and it all came into place the best explanation out there by a mile.💯

Man. Like you I struggled with this. Watched a lot of tutorials before yours, but yours is the one that put me over the top. Thanks!

I really appreciate the approach you take in this video. It felt more like a lesson or class, which was 100% what I was looking for. You explained why you were doing each part precisely at a normal pace. Thank you so much for this video, subbed!

Awesome mate! Thanks for making this - really took me a year to understand these concepts. Blown away truly! Big thanks! Keep making more

This is the type of breakdown I've been trying to find! I've been struggling with understanding how to properly use both blueprints and interfaces with the constant tweaks I add to evolving systems.

Absolutely fantastic!!! Thank you for this. This is the kind of super high value content we like to share with our students.

I'm so happy I took the time to listen to this. Super useful for a casual user like me.

Amazing tutorial I keep coming back to this one whenever I forget.

Thank you! I've been watching so many Unreal tutorials and so few of them focus on good programming practices for scalability.

Thank you. You managed what none of the other videos have been able to explain. Others were able to explain the how in using them but not the why. I'm a veteran in C# but learning blueprints (before I swap to full C++) and I couldn't quite work out why casting would be expensive. Your use of the Reference Viewer made it finally click. Liked and subscribed.

This made Blueprints not only much more simple to me, but also has the benefit of perf. Awesome video thank you!

This is good stuff man seriously this is textbook material much luv for dropping dis gang 👏🏾

Coming from Unity and it's script components I was lost in Unreal trying to figure out how to make an interface. This video is SO helpful. Thank you very much! I'd love to see you make more Unreal tutorial content and you're very engaging and clear. Subscribing in case you do in the future.

ah yes this makes so much sense, I started ue recently and thank I'm finding right videos at right time !!!!!!! Thanks for making it!

Thank you Sir! This really was a clear way of understanding a very convoluted/complex concept.

You're coming into my feed at just the right time. I have a bunch of hard references I replaced. :)

fantastic video! It helped me out big time

Great video because not only did you show how to use interfaces you explained why. Thank you!

Appreciate the info! I have been looking to learn these kinds of optimization and more advanced best practices for game dev.

Wow! I always thought interfaces were a last resort for when I improperly structured my classes, but this really opens my eyes.

I just subbed because this is one of the most useful videos I've seen so far for Unreal.

Thanks for explaining it in such detail!

We usually use the able suffix for interfaces like Interact Interactable, Deletable, Archivable, etc.

Great video! I'm starting with UE and I'm finding it very interesting yet very difficult since programming is not my thing, but I think what you are showing here will help later on the road. Thanks for sharing this so people don't have to suffer with similar issues!

cant imagine how much time you just saved me, thank you x a million!

Awesome vid, really helped me understand this a lot. Thanks!

Great Tutorial, really helpful, thanks for sharing, I liked and subscribed!

Excellent job, Thank you for sharing 👍

Great video. I was having an issue implementing an interface, and this helped me better understand it. Though one part I needed to figure out was what was a const function and why I had that checked on my interface function. Unchecked that and worked great.

You are a very positive person, thanks for the course

Definitely glad to have come across this early on. Connecting blueprints was becoming a tedious habit of mine.

This is exactly what I needed. Thank you very much

This is so cool! thanks for this explanation!

Thankyou for this! Very easy to understand for a beginner :D

Oh man finally someone who actually explained it. Thank you very much, this was really helpful and I'm glad youtube has brought me here.

This is awesome. Thanks Bro!😎

Thank you ❤so much for sharing your experience

Interfaces becomes more useful for larger modularized solutions if used correctly. They do add some additional complexity due to an extra abstraction layer though so good to not overuse. Mainly useful for behaviors like this example and when building pluggable frameworks for other developers.

Wow, that’s awesome! Although knowing about BPI existence I was never aware of this referencing dependency, that’s very important and like you said when it comes to scaling your Project that surely makes things a looooot easier! Thank you for this video, awesome work! 🎉

Very nicely explained.

I come from a pretty extensive background in Unity and it's pretty funny that you mention the coupled workflow of working in Unity that so many tutorials showcase. I unfortunately do find my self with a project some time down the road where several systems just depend too much on referencing each other and it creates such a pain when you want to create new levels and then the number of singleton classes become way too much. I mean, I may be getting ahead of myself, perhaps you'll mention singletons are the way to go for decoupling, but i'll find out as I dig into your video here. It'll be great learning Unreal and getting a proper workflow down correctly from the beginning :)

Extremely useful!!

Great tutorial. I just want to let it be known that having that "does implement interface" step is usually unnecessary. It was used here to basically tell the ForEach loop that it's found the first instance of something you can interact with to then be able to break the loop. You can just call the "Interact" message function, and it won't do anything with any actors that don't implement the interface, which is one of the most powerful things about using Interfaces. Again that branch check was just to check that we ran into the first instance of an actor that implements the interface. If, for example you wanted to loop through all the interactable actors within the overlapped actor, you just need to stick a pin straight into the "Interact" message and it will trigger the interact function on every actor that has an interact function and skip the ones that don't with zero bugs or erroring out due to unexplained references and whatnot.

In Blueprint you actually don't have to check if an actor implements an interface before sending an interface message. You can just send the message, and if the actor doesn't implement the interface the message will just be ignored. In C++ you do have to cast the actor to the interface class to check if the interface is implemented. And for hard references: a problem that you didn't mention that everybody should be aware of is that, beyond just getting a massive tangle of dependencies that will make making changes to your game extremely difficult, when you use a hard reference in a blueprint it actually loads the referenced class into memory. So even if the referenced class isn't in the world yet (i.e. you have a game manager class that references unique objects in every level), those classes will be taking up RAM for the entire game session. And if THOSE classes contain hard references those objects will be loaded too, and if those classes reference... etc. This could potentially lead to your entire game getting loaded into memory at once.

Amazing, thank you

I totally feel you on interfaces. I even made a tutorial for using Interfaces based on someone else's tutorial that I saw, but I didn't actually understand what I was learning or teaching :P Your video is great because you explain in really simple terms what the interface is actually doing :)

Great video! Thank you so much!

These Interfaces are amazing!!! When i found out they were a thing I got soo intriged

Also, an alternative to using interfaces is to use components. So you could create and actor component called "InteractableComponent" that you can attach to your interactable actors. And then create a delegate "Interact" in that component so you can implement it in the Actors (this is what for example box collisions do when you implement the OnBeginOverlap delegate). And to call the method interact you just call Actor->GetComponentByClass("InteractableComponent")->Interact(). The advantage of using components is that you could have a default implementation as well and you can abstract logic in it. For example, you could have an enhanced input action in the interactable component so you could also implement the input handling logic there. The biggest disadvantage is that delegates don't support methods with return values, so interfaces are useful for those cases. Personally, i find interfaces an antipattern due to how often are abused. They're very useful when used to remove dependencies between modules (i.e ItemModule from InventoryModule, QuestModule from InventoryModule/ItemModule, etc). But when overused to isolate single Actors within a module (module as in collection of objects that perform a single purpose), they make things harder to debug and maintain.

My only extension of this (besides the bug fix mentioned below) would be to make the target actor variable an array, and implement the code to fire Interact for any objects within that array. This way you can have a switch that talks to multiple objects at once.

Great video. Easy to follow you. 😎👍

Great stuff, thanks :D

@2:14-2:24 Literally where I've ended up... When there is a mess of actors combined with other game mechanics, character blueprints and player controller, all intertwined it gets really messed up. I appreciate you taking the time to put this together

you are "da bomb" i absolutely needed this shit with the current project im working on. tysm bro

Thank you so much for this video. While I didn't think I needed to know this; this is exactly what I needed for my project I am working on. Which is a Vtuber/DM NPC puppeteering tool that is not leaning into simplified/anime trope assets, Unreal makes that very possible with their metahuman and vast resource library versus Unity. I needed agnostic blueprints/functions so that the end user could interject their own assets to be used and can call on them with ease via keypresses while avoiding me just using massive and constant index references which can threaten it all if a component somehow gets activated ahead of schedule. Your instructions helped me decouple hard references, making it much easier for the end user to adapt it to their needs or conditions I did not think of. (My end goal is to have a compiled thing like VSeeFace/VMagicMirror and a plugin+sample scene for advanced users to change it to their needs.)

God, it's about time people start teaching new devs this workflow. So many tutorials are like "Now open the level blueprint" and it's just a completely unrealistic way to build a game. Nice video. Subbed. Have you discovered event dispatchers yet? ; )

Thank you! 😊

great video, thanks. also a quick tip, i noticed when you a adding the input mapping (04:48) you choose the key in the dropdown menu, you can also click in the keyboard icon to the left of the dropdown and press the key you want :) i found myself sometimes searching for a specific key and not finding it and this helped me a lot. And it works for controller buttons too!

Good one, much appreciated : )

I will watch this. I use BPI, but each time it is eerie to get what I want working

I also came from artist background, though I could say art & management. I only have some basic programming studied in the course to know about the basics, and one of them is OOP(object oriented programming). Past recent years people are yelling about DOD(data oriented design), I tried to study(self-taught) but it's quite hard to understand since I don't know much about the framework and stuffs. When I play around in UE4 with blueprints, I followed tutorials and none of them could answer my questions or rather there is no solutions for my problems. Therefore I implemented my own solutions instead, and that's when I noticed about interfaces. With the experiences I gained by working on my own projects I finally put all those lessons I learned into practice, then I finally understood DOD. It's not about the framework and language syntax, it's about how you put things together to achieve a certain result. Obviously if you just implement hardcoded stuffs you'd see the results right away, but they're inflexible. That's when I started to optimize my project and learned about struct and event driven style code. Unreal mostly consisted of event driven nodes, that's why it's important to embrace the coding style(scripting just to differentiate between typing and build nodes). With the project became more complicate and the scope became bigger than just a game jam project, data became more relevant to the project. That's when struct came into play. Now you're playing with event driven, interfaces, and struct. It's already DOD without you ever try to be one, just by only trying to optimize the project more. About coupling(or dependencies), don't afraid to still use them especially when the specific blueprint is already the dead end of the grand scheme. No matter how hard you wanted to avoid coupling, the lower hierarchy of your data structure would always depends on the higher ones. Because those lower blueprints must take all the data from the upper levels in order to be functional. tbh the foundation of my project might be a bit too big for the scale of the game I'm making, when I think about it everything is much similar to how AAA projects would do because the scalability and the independent on higher hierarchy blueprints. Yeah, it took me about 2 months to work on them(though it's actually 1 month since the first month I just hardcoded stuffs and optimized them the following month).

You da man, as a greenhorn I love these videos!

Thx you so much!

Also your player can interact with the switch even if theyre facing the other. Here's a solution, in the switch after you check if player is inside the trigger box, call the function find look at rotation between player capsule and switch mesh, then get forward vector from that rotation and project on to (0,0,1) plan (horizontal plan) then normalize the result, this will give you the forward vector of the rotation between player and switch projected on the ground and with length of 1 unreal units. Then use dot product between player/Camera forward vector and the vector we found earlier, check if the dot is greater than 0.8 for example, and then send out the message to the door.

12:00 instead compile and save, you can do both "simultaneously", beside button compile there are 3 points, chuse "save on compile" "on success only" in this way when you press compile it will save automatically

Thank you!

Thank you SO MUCH for this! It expanded my mind on exactly what I had been thinking about but didn't know how to do. Followed along and everything worked out except for one part (which is no fault of yours or the tutorial): the action input mapping section (5:00 minutes in); those options are now deprecated (I'm in 5.2). I did not try to see if those options still worked. Instead I found another video showing how to use the updated action mappings. I hope it's ok to post a link to another video showing how to use the new action mappings (it helped me complete this tutorial because of engine changes between versions; and this tutorial is so great). If there is a better way to share this (or if this is already posted in the comments (I couldn't find any reference)) without a link I will. But maybe it will help someone else who runs into this. Again thanks for the tutorial. Here's a link to how to use the non-deprecated input action mappings: kzfaq.info/get/bejne/pL56qLuG3bfKkWw.html

For anyone who would like to learn more - read about SOLID principles. Those are general principles of designing software, applicable to anything that you can program in any way possible, but I didn't hear someone speaking much about it in game development. It might be tricky to understand at first, but if you manage to do so - you'll be on another level in how extensible and clean your projects are :)

Nice video :) This proof that has some basics in some scripting language is very helpful when using blueprints. Try to learn something about c# (even with not-so-funny Unity) to just learn how Abstract classes work, how Interfaces work, Delegates, Events, Inheritance, etc. Then will be much easier to organize everything in UE5 and more of these "light bulb over your head" (eureka) moments will come :)

Awesome!

You just deserved much more thab "just" over 300k subbers.

Thank you so much!

I didn't know Taylor from PKA had an unreal engine channel! Sweet!

I've been taking a class with UE5 for almost 3 months now and the Blueprint stuff with the nodes is the most difficult for me to learn. But I'm optimistic about getting better with it.

THX for this video i am total noob and i not get that far in a project that need interact optimization but this will solve that part BUT i strugled with a more for many trivial thing that this tutorial solved that is a "reference viewer" option! :D i see it but not even once try it and cheking out a lot of assets to see how thay solve something and keep lose myself what is conected with what all the time often some parts simple give up not get what happen and what the cause for it :D Thank you this just simple solve a major headeach for me :D

Good vid, thx! :-)

nice and useful, thanks. just a tip: "contains" node is considerably faster than "for each loop" maybe it helps in your case as well

Nice tutorial bro! Interfaces are just a collection of custom functions declarations that can be attached to an actor. As you said, when you use Interfaces, you don't have to cast anything, because Interfaces don't care about their owner's class. There's a design pattern called "Observer" that's a Talker-Listener relation. Where the Talkers send updates and Listeners receive those messages and reimplement the InterfaceFunction. In this example I'd do it a bit different... I'd use the "BPI_Interface" for Triggers and other Interfaces for flows. Save "GetAllActorsWithInterface" as a variable, do a ForEachLoop on that variable and call the function you need on each element. When completed, empty the variable to save memory. You'll have a lot of Interfaces, but it'll be completely modular, automatic and without inheritance. Just remember: Interfaces are for listeners.

I used to use bp-intefaces, but ur method is more universal and parametric, cool

Hi, thank you for the content. I would instead of "Get Player pawn" (BP_Switch) "Get Controller" and than "Get Controlled Pawn". So now in a Multiplayer Game, all Players can open the Door and not just the Player with index 0. You can also make an Input at the BPI and send the information from the everyone how want to use the Switch.

awesome !!!!

The thumbnail to this video was one of the first about Unreal I ever saw. I remember thinking "what the hell is this dude talking about", so excited to have learned enough that this is something that comes up for me when searching! :D

You showed me this at 29! Thank you

This may sound stupid but it took me FOREVER to figure out why the interface was not working and its because of that "[interface function name](message)" node. It literally does not show up through searching off of the BP search window. It only shows up if you are pulling off of a get reference otherwise you get this other one that is completely useless imo (At least Idk what it even does). So seeing you struggle with finding that at 16:46 answers all my problems. So thank you so much for this!! I really do appreciate it man :)

Thank you for this video, can you also make a video or point me to a tutorial that talks about using variables more? for more interactive examples?

A lot of good advice down here in the comments. Thanks for the video 😄

Thanks, awesome video, but why did you add implemented interfaces in character BP?

Very informative, thank you. I just started learning this year. Can this interact bpi be set up as a variable? Like to use as a throttle to an engine?

thank you very much

10 years ago i tried to make a game editor exactly like unreal.. and i had same ideas of blue print instead of coding which i did in my editor.. without even knowing the existence of unreal engine.. i had same mind set so everything their is in unreal i did as well in principle. . and i also broke my head for years till i got to conclusion how to simplfy things.. i stopped making this editor because it was too much for one person, with limited knowledge back than

Let's go Boilermakers! I'm currently studying Game Dev at the New Albany campus and I am still trying to learn this amazing program. I'm gonna have to start following your videos more often and see if I can learn a thing or two. Great video though because this aspect of Blueprints is continuing to confuse me.

Great video. But the interface function/message for the door should have a different name. Right now, I think you could press E if your capsule overlaps the door and have it open. To be really advanced, put your button blueprint into an actor component. Then you can have interactions on any actor (ie. any button, switch, etc. automatically becomes interactable just by adding the component and setting the target).

ahhhh, lost but gonna keep watching till I understand.

The quote is "Tight integration and loose coupling" ;)

Two questions please. 1. How would I go about a situation where I have a whole bunch of different interactable objects: doors that open, switches that turn on the light, actors that you can grab etc. Should I have a separate interface for each of these cases and then in my character loop though all of the actors and check if they implement each of the interfaces? 2. How would I go about having 3 switches that turn on 3 different lamps? How would you tie a switch to a certain lamp (I'm currently using tags for that, which is kinda frustrating)?

Thanks for the guide. By the way, you don't need to give interact interface to your character ( base on this guide, you might have plane for it later :) ) to make it work.