I Struggled With Blueprint Interfaces for Years!! (Unreal Engine 5)

[@GlassHandFilms]

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

[@Odb718]

I feel like Event Dispatchers are less functional than BP Interfaces. But I'm a complete rookie. I was wondering if an Interface would be good for a HUD, or a menu? I need something that will allow me to press on an icon on a drop down menu, and that will save a variable to the character and load the end of the map. Is the interface able to send a value to a different actor or blueprint's variable like that??

[@t.m.182]

"Unfortunately" this wasn't new to me, I use interfaces alot. But seeing you enjoying yourself for learning this and the way you explain it to ppl is awesome, you're awesome. Thumbs up!

[@guystech8052]

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)

[@Levolpehh]

While line trace works, personally I feel it's pretty clunky unless you're doing a first person point and click game. Having all the options pop up when you enter a collision feels more intuitive.

[@NeatWolf]

I'm moving my first steps in Unreal(Blueprints) - and I'd say this sounds more like it should be done. Coming from Unity - you simply cast a line (with a certain distance and params) -> you loop through all the actors in the line, and stop at the first one handling the event. Probably the door should have a different interface.

[@Ex3meTV]

And if I have different types of interactivity. For example, a door, a lever, or just a static mesh that needs to be lifted. How can I best implement this?

[@ethanbelton9522]

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.

[@GlassHandFilms]

That's so awesome to hear!! Thank you for sharing this great news. Cheer!

[@mon4d]

I came here to learn blueprint interfaces. I left knowing how to create a reroute node by double-clicking the wire. Thanks!

[@GlassHandFilms]

😂 thank you for checking out the video! Always happy to help when I can! Cheers!!

[@mon4d]

I will be on my way, tidying up some of my blueprints… 😂

[@SB-jx6ox]

Best explanation of these I've seen yet. You caught me early in my journey. Thank you for likely saving me from a ton of headache later on!

[@GlassHandFilms]

Awesome! So happy to hear this news 😀 best of luck as you continue forward. Cheers!

[@brunoverde2769]

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.

[@GlassHandFilms]

Hey Bruno thank you so much for taking the time to comment! Yes this makes a ton of sense. I'm definitely going to start implementing solutions like this in my projects. I appreciate the advice! Cheers :)

[@Baleur]

So basically the player character ONLY talks to the button, which then relays the signal to the door, rather than the player character talking to BOTH at once?

[@brunoverde2769]

@@Baleur In short yes. If you use the same functionality in both door and switch, the character's capsule component might clip through the door (so the overlap event is triggered) and if the player is fast enough he might open it without the need to "press" the switch. It's basically a bug that might happen.

[@pibetry]

@@brunoverde2769 What about in scenarios where the Player is trying to BPI communicate interacting with ONE specific blueprint object, but TWO of the SAME blueprint objects are within Player's collision? How does UE know which specific blueprint object they wish to interact with, lets say for instance the most recent object to enter Player's collision?

[@brunoverde2769]

​@@pibetry If you use the method shown in the video, only the first stored overlapped actor will receive the BPI message since the loop will break with the first stored overlapped actor that has a BPI implemented. If you want to make the player interact with only one SPECIFIC object out of many others (let's call them actors from now on) you need to "write" specific code that tells the engine how to handle that. In your specific case about handling the most recent overlapped actor, it's quite simple to do: inside the loop you just need to use a branch that checks if the current array index is equal to 1 and if it's true fire the BPI message. Note that this is a very specific case and it will work ONLY if the player is currently overlapping two actors. If the player is overlapping more than two actors then you need to first get the length of the overlapped actors array, subract 1, check if the array index is equal to that resulting number and then fire the BPI message. Note that I don't actually know if the "overlapping actors" array stores the actors in the correct order but I assume it does hence what I wrote up here. If you want to really make sure to get the most recent overlapped actor you need to use a variable that overrides everytime the player overlaps an actor (make sure to use checks here, for example check if the overlapped actor has a BPI so the code is permormance friendly) and then fire the BPI message to that stored actor. Quite hard to explain here on the comments but in reality it's quite easy to do.

[@KyleKatarn145]

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.

[@ChubbyHubby00001]

recently started using Unreal Engine and what you said totally blew my mind. I have absolutely zero experience in this, but by creating reusable formulas, you can make your life so much easier. It makes it easier to create NPCs, areas that repeat, objects/objectives that repeat. Pretty much anything that repeats. Thank you!

[@GlassHandFilms]

@@ChubbyHubby00001 yeah interfaces make everything so modular. I've recently been naming my interfaces "clickable" or "interactable" or "consumable". That helps me abstract it even further. Cheers!

[@KINGDOMSONSTV]

@@GlassHandFilms great idea

[@protophase]

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

[@GlassHandFilms]

Thank you so much for the comment ☺️ I abuse interfaces and love using them! Cheers!

[@mx-gamesdev8287]

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.💯

[@GlassHandFilms]

Oh wow that's so awesome to hear!! Thank you 😊 cheers!

[@HansFriedrich532]

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

[@GlassHandFilms]

I really like this! I'm going to try and start using this in my projects as well. Thank you!

[@ULGENX866]

I don't know how many videos I've watched. I really thank you very much. I'm glad to have you, my friend.

[@GlassHandFilms]

@@ULGENX866 awesome 👍😁 glad you are here 👏 cheers!!!

[@puppetmaster1777]

I literally downloaded Unreal 5 yesterday. This is crazy overwhelming but I guess we all have to start somewhere. Cool vid. Cheers🥳

[@GlassHandFilms]

I understand how you feel! Unreal Engine (or any game engine) is very much the Dunning Kruger effect. haha! But that's the best part! the learning does not stop and there is always a new technique to add to your toolbelt. Wish you the best of luck in your journey, and thanks for checking out the video!

[@Nomadjackalope]

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

[@GlassHandFilms]

Being able to pull apart your assets and have some decoupling is so important! Unfortunately so many of us learn this too late, including me haha glad you enjoyed the video!!

[@MBAalrightgames]

@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

[@GlassHandFilms]

I hope this has helped! Thank you so much for checking it out! Cheers :)

[@MBAalrightgames]

@@GlassHandFilms I'll be real with you man, I've spent way too many hours trying to nail down this BP Interface thing with my player controller... Can't get the interface to carry the value to the pawn blueprint, doesn't give me a message just an event call... I'll get there eventually, with folks like you who post this stuff so an engineer with a taste for games can make a damn cool physic based game. Stay tuned lol

[@MBAalrightgames]

@@GlassHandFilms 2 days later and I am a champion of Blueprint Interfaces... not even joking. I appreciate you.

[@GlassHandFilms]

@@MBAalrightgames this is amazing to hear! I'm super happy you were able to unlock the potential of blueprint interfaces! Cheers :D

[@pseudonym108]

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

[@GlassHandFilms]

Thank you, Jamie. Super happy to hear this! Cheers!!

[@katelinthurman7842]

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.

[@Giofear]

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.

[@GlassHandFilms]

Oh wow thank you! That's so cool to hear! I hope to continue to share more content soon. Cheers!

[@mihaiwilson]

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!

[@GlassHandFilms]

hehe I thought I replied to this comment earlier in the week ;) Glad to hear the video helped! Cheers!

[@claudiocortese885]

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

[@MNFL24]

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.

[@GlassHandFilms]

awesome! yes this would work super well. Thank you for the comment! Cheers!

[@MortalVildhjart]

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

[@GlassHandFilms]

Amazing! Thank you for checking it out! Cheers :)

[@darkarps]

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

[@GlassHandFilms]

amazing!! super happy to hear this, thank you for sharing. Cheers!

[@Zesilo]

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!

[@GlassHandFilms]

Hey Corey thank you so much for watching the video and leaving this comment. I'm excited to keep learning together. Cheers :)

[@arpanmahor4840]

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!

[@GlassHandFilms]

Amazing!! Thank you for checking it out 😁 cheers!!

[@Fafhrd42]

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.

[@GlassHandFilms]

You are correct I did fail to mention this! Thank you very much for writing this comment!! This will indeed help many others! Cheers!

[@ferinzz]

The question is. Once you're aware of this, how do you identify what makes these hard references and view all the dependencies all the way down the chain?

[@SuperJohnsmith]

I'm curious what the overhead of sending the message through a blueprint is as well. If C++ requires you to cast the actor and blueprints are built on C++, that'd mean within the send message process it has to do this anyways, it's just more convenient. I'm fairly new to unreal, as I mostly worked with unity but the send message features there were often costly and best avoided as a general good practice.

[@souhaibbenchaker4824]

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.

[@DronX_]

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

[@gabeaskew8092]

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

[@GlassHandFilms]

Thank you, Gabe. I appreciate the comment greatly! I hope we can continue to learn together. Cheers man!

[@Solsund]

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.

[@rayloh8259]

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.

[@roystonwilson6846]

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

[@GlassHandFilms]

My pleasure, thank you for watching!

[@davidgordon3744]

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.

[@danielovaska]

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.

[@Cronofear]

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.

[@GlassHandFilms]

Thank you for your in depth comments, Kevin. I have really enjoyed reading them! Yes, honestly using actor components makes sense to me because of the single use principle :) it also reminds me a lot of how I would create prefabs in unity and I really like that way of scripting functionality. I hope to make a video on this soon, and I hope you can check it out. Thank you and cheers!

[@freezerain]

Interface IS abstraction while component is inheritance. Generaly speaking modern code style is in favour of interfaces then superclasses. I am not very strong in BP but in any C language your statement will be exact opposite

[@Cronofear]

@@freezerain Yeah, I should have been more specific. Interfaces in BP are an epic workaround and doesn't work the same as interfaces in C languages, they're very limited in what they can do and, in BP, you couldn't even reference only the interface part of an object so implementing the Liskov substitution principle was/is not possible (I think it's now possible using TScriptInterface). IMO the way to look for the "best" way to code in Unreal is to look at how the Lyra project does it. They use a combination of components and interfaces depending on what they're trying to achieve.

[@thomaskneisel1854]

The SOLID coding principles are good practice to make code testable and maintainable. However sometimes the abstractions become a performance problem and you have to break your principles to get uselfull code. They called principles not rules for a reason ;)

[@jephrennaicker4584]

@@GlassHandFilms could you make another video to reference the component method? would be interesting!

[@VolcanoMilk]

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

[@GlassHandFilms]

That's so awesome to hear! It's a great feeling decoupling classes in the reference viewer :) cheers!!

[@joseph.cotter]

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

[@lightspot]

This helped me a lot, you have made it very clear, thanks for the effort!!!!

[@GlassHandFilms]

@@lightspot I love to hear this!! Thank you for watching ☺️

[@romanchannel69]

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

[@TorQueMoD]

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 :)

[@GlassHandFilms]

Thank you for the comment! 🙂 I use interfaces all the time, probably too much haha cheers!

[@josemarcano6591]

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

[@GlassHandFilms]

I am so happy to hear that it helped you! Cheers :)

[@Latvian3Dman]

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

[@Kuziminski]

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.)

[@GlassHandFilms]

Thank you for sharing your project and experience!! So awesome! Please let me know how it's going. Sounds like a very useful tool. So happy you found this video helpful! Cheers :)

[@Kuziminski]

@@GlassHandFilms Thank you.

[@reggieisnotadog4841]

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.

[@GlassHandFilms]

Hey there! Thank you so much for leaving a comment and reaching out!! I will definitely make more content in the future. I try to balance my day job, small business, and KZbin 😁 but always here if you have questions! Cheers!

[@Drumaier]

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!

[@GlassHandFilms]

Thank you!! That's exactly what I wanted to do with this video. I wanted to guide your creative thinking and allow for a more modular approach. Thank you for sharing your thoughts and I wish you the best as you continue on your coding journey!!

[@UnrealSolver]

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! 🎉

[@GlassHandFilms]

Thank you very much for the comment and happy to hear you enjoyed the video!! Cheers :)

[@cxlflvrdfriends7001]

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

[@GlassHandFilms]

Awesome man I'm glad you enjoyed it!! Hope to post more soon! Cheers!

[@stoneageprogrammer432]

Hey this is a cool video and I've subbed you. I've been studying GameInstance lately, but I'm still very new to GameDev and Unreal. I'm making a game with multiple levels, and discovered that the gun that I found in one level does not transfer into the next level. So I discovered GameInstance, but I still don't know how to code that. I got a note from another dev who described the logic. Here is what he wrote: "Gameinstance is like this. 1. You create a Gameinstance. 2. You set in Project Setting to use your Gameinstance. 3.Before you switch a level you save all what you want keep to the Gameinstance. 4. After you switched the level. You call the Gameinstance and load all the things which you saved in the Gameinstance back to the new level. I don't know how you make an inventory System but I think they use data tables. Lets make an example with your gun. Lets say step 1 and 2 you did. Step 3 is : Save the gun mesh in your GameInstance as a gun mesh variable. 4. You are switching the level. In the new level you need set your gun mesh. So you call your Gameinstance, find the saved gun mesh and use this saved gun mesh to set the gun mesh in the new level. Now your new level has the gun from before. I am not sure if this is the best way but as a start point it should work." Like I said, I don't know how to turn that into Blueprints. Do you think you might do another tutorial demonstrating this procedure?

[@GlassHandFilms]

Hey there!! Thank you for taking the time to share this! I will definitely make a video talking about game instances. They are persistent in memory so they are perfect to store variables between levels. I'll try and post a video in the next few days :) cheers man!

[@stoneageprogrammer432]

@@GlassHandFilms Dude, you are completely awesome! Thank you for the reply, and I can't wait to watch your tutorial, as always. I love your channel, I love watching your videos, and you are a fantastic Game Dev. Thank you for everything you do!

[@GlassHandFilms]

@@stoneageprogrammer432 thank you! You are too kind! I just started a new job as a director of real time production so my schedule has been all over the place, 😅 but I love connecting with people and sharing videos so I will get on this ASAP 😁 thanks again for the suggestion!!

[@stoneageprogrammer432]

@@GlassHandFilms That is awesome! Congrats on the new job. Sounds fun. Well, thank you for taking up the challenge, I have learned a ton from your videos.

[@SquarePurple-wp4pv]

This is awesome. Thanks Bro!😎

[@GlassHandFilms]

my pleasure! glad you enjoyed it :) Cheers!!

[@LupusMechanicus]

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

[@GlassHandFilms]

awesome! I hope they jumpstart your journey into blueprints. Cheers :)

[@sergeyfilinsky5398]

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 :)

[@sergeyfilinsky5398]

This interface stuff is something that comes from those principles and is just one thing to make it all better!

[@MCNeko6554]

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

[@quietlyworking]

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

[@GlassHandFilms]

Thank you, sir! It's a true story and I hope others enjoy using this technique haha cheers!!

[@jamesonvparker]

Interesting. Thank you. I’m a JavaScript developer but my knowledge doesn’t transfer to blueprints very easily unfortunately. This helps.

[@GlassHandFilms]

Hey Jameson! I'm not a developer, definitely an artist background with an interest in programming. I do know that this is a very useful solution for JavaScript. Thank you for checking out the video and sharing! Cheers!

[@dreamingacacia]

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).

[@ta01ack]

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: kzbin.info/www/bejne/pImtpouLrbaZl5o

[@m198891]

You are a very positive person, thanks for the course

[@maddiereneeart]

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

[@GlassHandFilms]

So awesome! Thank you for checking it out!!

[@QuiteDan]

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

[@PirateDion]

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

[@joacotossello]

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.

[@GlassHandFilms]

Hey there Joaquin thank you for the well thought out comment. I appreciate your time in writing this. Cheers!!

[@lightcer5339]

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 :)

[@fictionalgaming912]

I would say for debugging - if you are expecting to interact with an Actor in the world, it is far better in terms of debugging to print the name of the Actor you interact with instead of a custom message. This way if you are NOT interacting with the desired actor then you know for a fact that something is not working, but if it does the actor name you did interact with will print to screen. While the way that was presented here is NOT bad or incorrect, it is a less ideal choice for this particular debug case. Normally when I use the UELOG/AddOnScreenDebugMessage function in C++ on a function that is intended to interact with an actor (damage, grab, impulse) I will utilize an Actor pointer: AActor* HitActor = Hit.GetActor() Then in a debug message I say something like "You hit actor: %s" *HitActor.GetActorNameOrLabel() which will print the NAME of the actor to the log. Even if it is a blueprint actor class. Again the method shown in the video is NOT a wrong way to debug, it just will leave you open to potentially misinterpretation of success or failure of what you are trying to accomplish. My tip would be to grab the Actor name or label and feed it into the String Node in the Print String function BP node. This way you know for a fact that you are interacting with exactly what you are intending to interact with and not something else. All in all ----- 10/10 video loved it. Easy to follow and Understand.

[@JVStorck]

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!

[@GlassHandFilms]

Thank you for checking it out and for the quick tip! I really appreciate it! Cheers!

[@Storytelling-by-ash]

Thank you ❤so much for sharing your experience

[@GlassHandFilms]

You are most welcome 🤗 thank you for watching 😌🙏

[@ralfbierig]

Thanks for a good tutorial and keep producing!

[@GlassHandFilms]

@@ralfbierig thank you so much!! ☺️ I hope to share more soon! Cheers!

[@galaktuss]

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

[@NeotronicGames]

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

[@GlassHandFilms]

I had to do some googling but yeah we do look alike 🤣

[@MichaelKocha]

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? ; )

[@GlassHandFilms]

Hey Michael! Thank you for the kind words! Awesome channel btw :) I subbed to you as well! My next video I want to make is about event dispatchers and why to use them. Keeping with a similar format. Cheers man!

[@MichaelKocha]

@@GlassHandFilms Thanks! Can't wait to catch the next video!

[@commoncure3335]

probably because working in the level BP is easy to understand when just starting out

[@MichaelKocha]

@@commoncure3335 I mean, it depends. I'd argue that finding out that the level editor doesn't really work in any modular workflows and having to redo all that work the right way is a lot harder than just learning it the right way, the first time.

[@Pdrum2]

I think they need to be teaching better.

[@dbnet_]

- direct referecing - BP interfaces - event dispatchers I'm sorry Mr. KZbinr, I'm going to be a bit critical here. If you are just discovering communication outside of direct, not only is it irresponsible to educate, but you've been actively harming your inexperienced viewers in the past. These are fundamentals of blueprint communications, available in free courses provided by Epic Games. You're here talking about scale, implying you have some authority or extensive experience, but you admit to lacking in experience with BPI. I know this was a long time ago, I don't aim to ruin your day. I'm simply speaking from experience. In 2008 I used KZbin to learn audio production, and people with well-intentions stunted my growth with false understanding. People will remember the lesson you taught them, but not necessarily you. Quality education is important. Cheers and I do hope this message's meaning finds you well.

[@GlassHandFilms]

I appreciate the critical comment :) I do have a video on my channel introducing Direct Blueprint Communication, I do not however have one about event dispatchers. Yes, there are a few missteps in this video, definitely not perfect, but the goal here is to get folks into Blueprint Interfaces and continue their journey with BPI in mind. Cheers!

[@iraisynn.attinom]

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

[@ColeWithAGoal]

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 :)

[@alienrenders]

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).

[@GlassHandFilms]

I love this idea! Thank you for sharing! I've been abusing actor components a lot lately! I did a small video about them but hope to post more soon

[@DaMaster1983]

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

[@blackivy011]

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

[@maxostlund9334]

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

[@GlassHandFilms]

Hahaha thank you! I know the thumbnail is cringe, but it really did take me forever to learn interfaces and take advantage of them :) cheers!

[@maxostlund9334]

I have never related to something as much as I related to that thumbnail lol... This was a really great tutorial, thank you so much! I was wondering if maybe you have a tutorial on sending over variable values via blueprint interfaces, because I really struggle with doing so without hard references and there really aren't any good tutorials on the topic. :)

[@Mac_Daffy]

Thanks for explaining it in such detail!

[@GlassHandFilms]

You're welcome! It's super powerful and I hope you use it in your projects! Cheers

[@libshastra]

A better way to explain the interface is to say they are analogous to real world contracts. Your interface is a contract between the caller and the callee. The caller doesn't care how the callee handles it's request as long as it gets the results from its call. Good tutorial!

[@MikeyBison]

ahhhh, lost but gonna keep watching till I understand.

[@GlassHandFilms]

Definitely try this out for yourself in a small test project! Once you get the hang of it, I'm sure you will using it a lot 😁

[@tomtomkowski7653]

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 :)

[@ThePavilionWeb]

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

[@xXESproductionsXx]

This is so cool! thanks for this explanation!

[@GlassHandFilms]

Thank you for checking it out!! Cheers :)

[@hakeemadam955]

This is exactly what I needed. Thank you very much

[@GlassHandFilms]

That's awesome to hear! Thank you :) cheers!

[@yeye3999]

Nuts! I can just duplicate the buttons and doors or w/e and just retarget them. brain explosion. Thanks a bunch 🤩

[@lyfezbane]

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

[@GlassHandFilms]

so awesome! Thank you for checking it out! Cheers :)

You can also have one interface for everything. Just add a function with one or two integers and a float or a separate function with int and a vector etc. After that add a "switch on int" to the receiving end and have different logic for different actions.

[@GlassHandFilms]

Thank you for sharing! That is a very cool way to do things. I'll have to try this out in my own projects! Cheers! :)

[@Cronofear]

Oh god, please no. Read about SOLID principles. Specifically, the single responsibility principle.

@@Cronofear Just because you can do something does not mean you should do it in every situation. Separate interfaces are good for grouping. For example "Get all actors with interface" is very useful.

[@danielovaska]

Absolutely not.

[@unsolvedbc]

Great video, just clarified some things for me.

[@GlassHandFilms]

@@unsolvedbc awesome!! So great to hear. Thank you for leaving a comment to let me know. Cheers!

[@fahood9242]

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

[@GlassHandFilms]

Great to hear!!! Thank you for checking it out :) cheers!!

[@Par8dox]

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

[@KitBitUK]

Excellent job, Thank you for sharing 👍

[@GlassHandFilms]

Thank you so much! I really appreciate it 😊

[@moshmoshpitpit]

This earns a sub. Thank you for the great content!

[@GlassHandFilms]

Thank you for watching, Timothy! Happy to see you enjoyed it and hope to create more that you'll enjoy in the future! Cheers!

[@MrAlireza41]

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.

[@leo10royplays]

concepts finally line up in my brain and...well, who knows? Maybe I'll be able to make sotNice tutorialng now.

[@tiberiusgames1109]

fantastic video! It helped me out big time

[@jacobhughes1314]

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.

[@invert6actual585]

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?

[@DhaoistAzazel]

You showed me this at 29! Thank you

[@GlassHandFilms]

I hope you found it informative! Cheers!

[@DakotaRileyMedia]

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.

[@GlassHandFilms]

Thank you, Dakota and boiler up! Try to keep at it and absorb yourself more and more into it, and I promise it will start to make sense. :) Cheers man!

[@alexanderalikin1210]

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)?

[@KINGDOMSONSTV]

What a fantastic tutorial

[@GlassHandFilms]

@@KINGDOMSONSTV thank you! I'm really happy you enjoyed it!!! 😄