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??
"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!
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.
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)
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.
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.
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?
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.
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 :)
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?
@@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.
@@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?
@@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.
@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'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
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.💯
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!
@@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!
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.
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!!
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.
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.
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.)
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 :)
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 :)
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!
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.
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.
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?
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.
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?
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!
@@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!
@@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!!
@@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.
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
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. :)
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.
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!
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
@@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.
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 ;)
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
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.
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).
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.
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? ; )
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!
@@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.
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).
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)?
2 роки тому+1
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.
Oh god, please no. Read about SOLID principles. Specifically, the single responsibility principle.
2 роки тому
@@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.
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.
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!
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!!
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.
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 UA-cam 😁 but always here if you have questions! Cheers!
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! 🎉
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!
- direct referecing - BP interfaces - event dispatchers I'm sorry Mr. UA-camr, 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 UA-cam 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.
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!
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!
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 :)
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.
Don't worry, in my 20 years of working as a software engineer, I can assure you, I've met many professionals who still don't understand the importance of loose coupling or interfaces, or if they do, they don't know how to actually achieve it.
I will have to go over this slowly to see if I can get a handle on the concept. One question. What would it look like if I had another button elsewhere that opened another trap door?
Hey Terry! Yes I recommend watching the video and following along step by step. To answer your question, do you remember the generic actor variable we made called "Target"? That variable allows us to select any actor in the world to test and see if it reacts positively towards our message we are sending. The good part about all of this is if you don't implement the interface correctly, it won't cause a null reference exception error and crash your game. It will just fail. I hope that helps! Let me know if that makes sense!
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.
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
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.
Interfaces I have had a very hard time wrappping my heads around. In comparison to classes where the analogy would be a class = construction blueprint of a house and instances = every house built from that blueprint. Every house then comes with its own set of independent base variables derived from the blueprint that was used in the construction (what color, what wallpapers, what room design, measurements ect) . They are derived from, but not coupled back to the class/blueprint (If you later paint your house in another color or rebuild a room this don't change the construction blueprint nor does it change the colors and rooms of the other houses built from it but only the color and shapes of your own house). Using that analogy I could wrap my head around classes and object orientation so much it is now my standard programming paradigm that I use for everything. Interfaces are a bit trickier. I tried to use the analogy like: Interface = An interface like the remote control you use with your stereo or TV to control it where the remote blindly sends out a signal and dont care or know anything about the device it is controlling and the recieving device in comparison just waits for the correct signal but it does not care at all about the device sending the signal. The 2 devices are not dependent on each others construction and programming other then the correct IR pulses being sent between them and also it is a one way communication from remote to controlled device with no feedback response back to the remote control. This seems to be the exact same idea as here so I guess this part of the analogy is correct and also explains why it is called interface. However this don´t explain to me some other more general concepts like in Java how interfaces replaces multiple inheritances and some other things, like what u said in the beginning that u promise a behaviour but with no implementation. I guess If I spend some more time using interfaces I will hopefullt grasp this just as well as classes and OO. Your explanation of the concept is the best so far that I have seen though.
Hey John! thank you so much for leaving your thoughts here! I really like your anaologies. Thank you for taking the time to write this post. I really appreciate it and I'm sure the people who are new to this concept do as well. Cheers!
I like your idea of analogies, never thought about using that, but could be helpfull. :) For me, it seems your analogie to interfaces is only half-way, because it is not a one way communication, as seen at the button that receives a message and sends a new message. Another approach could be something like: seeing the interface like a headmaster or trainee that receives messages, than makes a call out and sends the message to the them who answers. The call out can have limitations like "only actors inside the volume box" or "only target "door actor XY" ", that means only the button and door shown in the video respons to the call out and gets the message and doing things. Like in another comment mentioned, without the volume box and only the "only actor"-limitation, it would send the message to each actor with that interface implemented. (My knowledge about interfaces is currently limited to only this video, so let me know if I messed something up. I would appreciate it.)
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!
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.
Thank you for explaining everything. This has been very helpful! Will it be ok if you can show us as well how to create model or be able to influence geometry in Unreal Engine 5? I know there is a bunch of programs that I can do that, but I don't wanna use other programs if I know unreal engine 5 has now the capacity to influence geometry and eventually create models from scratch. Bceause all I see with so many tutorials that I watched, they just get assets from the store, and I wanted something more in depth, not just dragging already made objects into your scene. Thank you so much!
Hey there! Thank you so much for watching the video and reaching out through a comment :) yes! I would love to make a video over this topic! I do have some videos on blender you could check out if you are interested, but staying in engine is super powerful! I will try and make a video soon. Cheers!
Hey that was a great explanation thank you! I am already using an interact interface without really understanding why. On the switch in your example you had it opening the hidden door. If I wanted to use that same swtich to, like you say turn on a light for example, I could duplicate that switch BP and change the node from sliding the door open to turning on a light. Is that how it works? I am trying to make sure I understand correctly.
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 :)
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!
So is it like, "okay" to go absolutely bananas with this? (i'm still into my FIRST month of learning UE5 btw). Should we be able to use this method for literally EVERYTHING (that needs to reference / call another bp or actor)? Like in your final example of the BP Character, the weapon references the character, could this also be turned into a "WeaponEquip" interface that ALL weapons are tied to, and that the player character then uses to equip ANY weapon that is tied to that same interface? Did i understand it correctly lol.
So, big question, what about before the effect of the interaction happens (I.e the door opens)... What If I want to ask about the values of certain variables. So, let's say that the button was buttonless, so basically a boolean named "Can Interact?"... and let's say maybe the player had to go fetch a button from somewhere, so I'll have to ask the question "does player have button?" So when both of them are true, the player can finally interact with the button. How would I do this without direct referencing/ casting to an object? Edit: keep in mind that the solution would also have to work if I had other objects that I can also interact with using the same BPI.
Awesome stuff! Subbed! Im curious: wouldnt it be more efficient to not loop through all overlapping actors and just have the logic subscribe to an event that only gets fired on E Input if the player capsule is inside a proximity trigger?
@@harrysanders818 The reason for the loop is to just showcase some unique solution :) there are many ways you could do this, you could even do a line trace to what you are looking at. Either way, it's pretty performant to return a yes or no on this check. Making sure something implements an interface should not cost a lot on performance :) cheers!
Maybe coupling the player is not so great. How about checking the caller? Or sending over the interactor. Say you want to control two things that interact, or you implement some enemy ai that uses interact on things.
I mean we checked whether it was overlapping an actor in BP_FirstPersonCharacter while creating the for loop. Wouldn't it get a null pointer if we immediately try to incorporate it with the for loop and attempt to take an action on it? Imagine a person not overlapping with anything, and still using the InterAction. Also why do we check it if our character is overlapping with the box a second time in BP_SwitchDoor? We can check it only once within BP_FirstPersonCharacter, and send a message to the classes that implement the interface, which could directly open the door instead of checking.
That's why I made sure to go through all the fundamentals tutorials from Epic, they cover all of this and more. In fact make sure you understand fundamentals first every time you approach something new. But don't fall into the tutorial hell, cover the fundamentals and start doing something yourself asap.
![The Complete Story of Destiny! From origins to Shadowkeep [Timeline and Lore explained]](http://i.ytimg.com/vi/9mbDXvDNqTU/mqdefault.jpg)
Thank you for checking this video out! In the next video I will talk about event dispatchers! Cheers guys!
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??
"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!
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.
That's so awesome to hear!! Thank you for sharing this great news. Cheer!
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)
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.
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.
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?
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.
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 :)
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?
@@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.
@@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?
@@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.
@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
I hope this has helped! Thank you so much for checking it out! Cheers :)
@@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
@@GlassHandFilms 2 days later and I am a champion of Blueprint Interfaces... not even joking. I appreciate you.
@@MBAalrightgames this is amazing to hear! I'm super happy you were able to unlock the potential of blueprint interfaces! Cheers :D
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.💯
Oh wow that's so awesome to hear!! Thank you 😊 cheers!
I'm so happy I took the time to listen to this. Super useful for a casual user like me.
Thank you, Jamie. Super happy to hear this! Cheers!!
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.
Oh wow thank you! That's so cool to hear! I hope to continue to share more content soon. Cheers!
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!
@@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!
@@GlassHandFilms great idea
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.
I came here to learn blueprint interfaces.
I left knowing how to create a reroute node by double-clicking the wire.
Thanks!
😂 thank you for checking out the video! Always happy to help when I can! Cheers!!
I will be on my way, tidying up some of my blueprints… 😂
I don't know how many videos I've watched. I really thank you very much. I'm glad to have you, my friend.
@@ULGENX866 awesome 👍😁 glad you are here 👏 cheers!!!
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!
Awesome! So happy to hear this news 😀 best of luck as you continue forward. Cheers!
We usually use the able suffix for interfaces like Interact
Interactable, Deletable, Archivable, etc.
I really like this! I'm going to try and start using this in my projects as well. Thank you!
Thank you! I've been watching so many Unreal tutorials and so few of them focus on good programming practices for scalability.
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!!
cant imagine how much time you just saved me, thank you x a million!
amazing!! super happy to hear this, thank you for sharing. Cheers!
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.
awesome! yes this would work super well. Thank you for the comment! Cheers!
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!
hehe I thought I replied to this comment earlier in the week ;) Glad to hear the video helped! Cheers!
This made Blueprints not only much more simple to me, but also has the benefit of perf. Awesome video thank you!
Amazing! Thank you for checking it out! Cheers :)
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.
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.)
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 :)
@@GlassHandFilms Thank you.
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 :)
This interface stuff is something that comes from those principles and is just one thing to make it all better!
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!
Hey Corey thank you so much for watching the video and leaving this comment. I'm excited to keep learning together. Cheers :)
Amazing tutorial I keep coming back to this one whenever I forget.
Thank you so much for the comment ☺️ I abuse interfaces and love using them! Cheers!
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! I always thought interfaces were a last resort for when I improperly structured my classes, but this really opens my eyes.
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.
You are correct I did fail to mention this! Thank you very much for writing this comment!! This will indeed help many others! Cheers!
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?
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.
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?
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!
@@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!
@@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!!
@@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.
Great video because not only did you show how to use interfaces you explained why. Thank you!
Thank you, Gabe. I appreciate the comment greatly! I hope we can continue to learn together. Cheers man!
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
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!
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. :)
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.
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!
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
@@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.
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 ;)
@@GlassHandFilms could you make another video to reference the component method? would be interesting!
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
You da man, as a greenhorn I love these videos!
awesome! I hope they jumpstart your journey into blueprints. Cheers :)
Absolutely fantastic!!! Thank you for this. This is the kind of super high value content we like to share with our students.
Thank you, sir! It's a true story and I hope others enjoy using this technique haha cheers!!
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!
Amazing!! Thank you for checking it out 😁 cheers!!
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.
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).
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.
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? ; )
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!
@@GlassHandFilms Thanks! Can't wait to catch the next video!
probably because working in the level BP is easy to understand when just starting out
@@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.
I think they need to be teaching better.
Thank you Sir! This really was a clear way of understanding a very convoluted/complex concept.
I am so happy to hear that it helped you! Cheers :)
This is good stuff man seriously this is textbook material much luv for dropping dis gang 👏🏾
Awesome man I'm glad you enjoyed it!! Hope to post more soon! Cheers!
Awesome mate! Thanks for making this - really took me a year to understand these concepts. Blown away truly! Big thanks! Keep making more
My pleasure, thank you for watching!
I will watch this. I use BPI, but each time it is eerie to get what I want working
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).
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
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)?
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.
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! :)
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.
Absolutely not.
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.
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!
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!!
I just subbed because this is one of the most useful videos I've seen so far for Unreal.
So awesome! Thank you for checking it out!!
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.
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 UA-cam 😁 but always here if you have questions! Cheers!
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! 🎉
Thank you very much for the comment and happy to hear you enjoyed the video!! Cheers :)
I literally downloaded Unreal 5 yesterday. This is crazy overwhelming but I guess we all have to start somewhere. Cool vid. Cheers🥳
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!
- direct referecing
- BP interfaces
- event dispatchers
I'm sorry Mr. UA-camr, 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 UA-cam 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.
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!
Interesting. Thank you. I’m a JavaScript developer but my knowledge doesn’t transfer to blueprints very easily unfortunately. This helps.
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!
You're coming into my feed at just the right time. I have a bunch of hard references I replaced. :)
That's so awesome to hear! It's a great feeling decoupling classes in the reference viewer :) cheers!!
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 :)
Thank you for the comment! 🙂 I use interfaces all the time, probably too much haha cheers!
ahhhh, lost but gonna keep watching till I understand.
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 😁
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.
Hey there Joaquin thank you for the well thought out comment. I appreciate your time in writing this. Cheers!!
The quote is "Tight integration and loose coupling" ;)
Don't worry, in my 20 years of working as a software engineer, I can assure you, I've met many professionals who still don't understand the importance of loose coupling or interfaces, or if they do, they don't know how to actually achieve it.
Hey Condor! Thank you for leaving the message. This makes me feel better 😃 I'm always wanting to learn more! Cheers friend
I didn't know Taylor from PKA had an unreal engine channel! Sweet!
I had to do some googling but yeah we do look alike 🤣
Thank you ❤so much for sharing your experience
You are most welcome 🤗 thank you for watching 😌🙏
I will have to go over this slowly to see if I can get a handle on the concept. One question.
What would it look like if I had another button elsewhere that opened another trap door?
Hey Terry! Yes I recommend watching the video and following along step by step. To answer your question, do you remember the generic actor variable we made called "Target"? That variable allows us to select any actor in the world to test and see if it reacts positively towards our message we are sending. The good part about all of this is if you don't implement the interface correctly, it won't cause a null reference exception error and crash your game. It will just fail. I hope that helps! Let me know if that makes sense!
This is exactly what I needed. Thank you very much
That's awesome to hear! Thank you :) cheers!
Thank you! 😊
Thank you for checking it out, Patrik
you are "da bomb" i absolutely needed this shit with the current project im working on. tysm bro
Great to hear!!! Thank you for checking it out :) cheers!!
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.
You showed me this at 29! Thank you
I hope you found it informative! Cheers!
I used to use bp-intefaces, but ur method is more universal and parametric, cool
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
This helped me a lot, you have made it very clear, thanks for the effort!!!!
@@lightspot I love to hear this!! Thank you for watching ☺️
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.
Interfaces I have had a very hard time wrappping my heads around. In comparison to classes where the analogy would be a class = construction blueprint of a house and instances = every house built from that blueprint. Every house then comes with its own set of independent base variables derived from the blueprint that was used in the construction (what color, what wallpapers, what room design, measurements ect) . They are derived from, but not coupled back to the class/blueprint (If you later paint your house in another color or rebuild a room this don't change the construction blueprint nor does it change the colors and rooms of the other houses built from it but only the color and shapes of your own house). Using that analogy I could wrap my head around classes and object orientation so much it is now my standard programming paradigm that I use for everything. Interfaces are a bit trickier. I tried to use the analogy like: Interface = An interface like the remote control you use with your stereo or TV to control it where the remote blindly sends out a signal and dont care or know anything about the device it is controlling and the recieving device in comparison just waits for the correct signal but it does not care at all about the device sending the signal. The 2 devices are not dependent on each others construction and programming other then the correct IR pulses being sent between them and also it is a one way communication from remote to controlled device with no feedback response back to the remote control. This seems to be the exact same idea as here so I guess this part of the analogy is correct and also explains why it is called interface. However this don´t explain to me some other more general concepts like in Java how interfaces replaces multiple inheritances and some other things, like what u said in the beginning that u promise a behaviour but with no implementation. I guess If I spend some more time using interfaces I will hopefullt grasp this just as well as classes and OO. Your explanation of the concept is the best so far that I have seen though.
Hey John! thank you so much for leaving your thoughts here! I really like your anaologies. Thank you for taking the time to write this post. I really appreciate it and I'm sure the people who are new to this concept do as well. Cheers!
I like your idea of analogies, never thought about using that, but could be helpfull. :)
For me, it seems your analogie to interfaces is only half-way, because it is not a one way communication, as seen at the button that receives a message and sends a new message.
Another approach could be something like: seeing the interface like a headmaster or trainee that receives messages, than makes a call out and sends the message to the them who answers.
The call out can have limitations like "only actors inside the volume box" or "only target "door actor XY" ", that means only the button and door shown in the video respons to the call out and gets the message and doing things.
Like in another comment mentioned, without the volume box and only the "only actor"-limitation, it would send the message to each actor with that interface implemented.
(My knowledge about interfaces is currently limited to only this video, so let me know if I messed something up. I would appreciate it.)
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!
This is awesome. Thanks Bro!😎
my pleasure! glad you enjoyed it :) Cheers!!
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.
You are a very positive person, thanks for the course
Thanks, awesome video, but why did you add implemented interfaces in character BP?
Thank you for explaining everything. This has been very helpful!
Will it be ok if you can show us as well how to create model or be able to influence geometry in Unreal Engine 5? I know there is a bunch of programs that I can do that, but I don't wanna use other programs if I know unreal engine 5 has now the capacity to influence geometry and eventually create models from scratch. Bceause all I see with so many tutorials that I watched, they just get assets from the store, and I wanted something more in depth, not just dragging already made objects into your scene.
Thank you so much!
Hey there! Thank you so much for watching the video and reaching out through a comment :) yes! I would love to make a video over this topic! I do have some videos on blender you could check out if you are interested, but staying in engine is super powerful! I will try and make a video soon. Cheers!
@@GlassHandFilms Thank you so much! I am looking forward in seeing the video 👍🏻
You just deserved much more thab "just" over 300k subbers.
Hey that was a great explanation thank you! I am already using an interact interface without really understanding why. On the switch in your example you had it opening the hidden door. If I wanted to use that same swtich to, like you say turn on a light for example, I could duplicate that switch BP and change the node from sliding the door open to turning on a light. Is that how it works? I am trying to make sure I understand correctly.
What did you figure out?
@@austincable I didn't. I am taking a break from UE5
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 :)
Thanks for explaining it in such detail!
You're welcome! It's super powerful and I hope you use it in your projects! Cheers
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!
Thank you for checking it out and for the quick tip! I really appreciate it! Cheers!
Hola, nota: no es necesario agregar la interfaz al BP que utiliza message solo es necesario para el BP que genera el evento. Buen video.
Didn't know that. Thanks. Gotta check it.
So is it like, "okay" to go absolutely bananas with this? (i'm still into my FIRST month of learning UE5 btw).
Should we be able to use this method for literally EVERYTHING (that needs to reference / call another bp or actor)?
Like in your final example of the BP Character, the weapon references the character, could this also be turned into a "WeaponEquip" interface that ALL weapons are tied to, and that the player character then uses to equip ANY weapon that is tied to that same interface?
Did i understand it correctly lol.
Awesome!
Thank you, Fred!
Great video. Easy to follow you. 😎👍
Thank you so much for the comment! Glad you enjoyed it! Cheers!!
Definitely glad to have come across this early on. Connecting blueprints was becoming a tedious habit of mine.
Thanks for a good tutorial and keep producing!
@@ralfbierig thank you so much!! ☺️ I hope to share more soon! Cheers!
A lot of good advice down here in the comments. Thanks for the video 😄
So, big question, what about before the effect of the interaction happens (I.e the door opens)...
What If I want to ask about the values of certain variables.
So, let's say that the button was buttonless, so basically a boolean named "Can Interact?"...
and let's say maybe the player had to go fetch a button from somewhere, so I'll have to ask the question "does player have button?"
So when both of them are true, the player can finally interact with the button.
How would I do this without direct referencing/ casting to an object?
Edit: keep in mind that the solution would also have to work if I had other objects that I can also interact with using the same BPI.
Thank you!
Thank you for checking it out! Cheers man!
This is so cool! thanks for this explanation!
Thank you for checking it out!! Cheers :)
Awesome stuff! Subbed! Im curious: wouldnt it be more efficient to not loop through all overlapping actors and just have the logic subscribe to an event that only gets fired on E Input if the player capsule is inside a proximity trigger?
I think its exactly what you are doing :p ... I jus struggle to understand why the for each loop is used.
@@harrysanders818 The reason for the loop is to just showcase some unique solution :) there are many ways you could do this, you could even do a line trace to what you are looking at. Either way, it's pretty performant to return a yes or no on this check. Making sure something implements an interface should not cost a lot on performance :) cheers!
Maybe coupling the player is not so great. How about checking the caller? Or sending over the interactor. Say you want to control two things that interact, or you implement some enemy ai that uses interact on things.
I mean we checked whether it was overlapping an actor in BP_FirstPersonCharacter while creating the for loop. Wouldn't it get a null pointer if we immediately try to incorporate it with the for loop and attempt to take an action on it? Imagine a person not overlapping with anything, and still using the InterAction.
Also why do we check it if our character is overlapping with the box a second time in BP_SwitchDoor? We can check it only once within BP_FirstPersonCharacter, and send a message to the classes that implement the interface, which could directly open the door instead of checking.
What a fantastic tutorial
@@KINGDOMSONSTV thank you! I'm really happy you enjoyed it!!! 😄
That's why I made sure to go through all the fundamentals tutorials from Epic, they cover all of this and more. In fact make sure you understand fundamentals first every time you approach something new. But don't fall into the tutorial hell, cover the fundamentals and start doing something yourself asap.
I couldn't agree more! Epic had invaluable resources and a great staff of people to keep it up to date
Nuts! I can just duplicate the buttons and doors or w/e and just retarget them. brain explosion. Thanks a bunch 🤩