Stop Casting! use blueprint Interfaces Instead!
Вставка
- Опубліковано 1 гру 2023
- You've probably heard that you should avoid casting where you can because it's bad for performance. While I think that is very much overstated and people go WAY out of their way to avoid using any casts, it's still good to know when and how to avoid it, so today let's take a look at a common method, using Blueprint interfaces!
Get the project files here on patreon: / 93566119
or for youtube memhers, here : • Post
Join this channel to get access to perks:
/ @thegamedevcave
Join the discord for any help you need! : / discord
support the channel and development over on patreon : / thegamingcaves - Наука та технологія
this is so much better then begin component overlap into cast that every other tutorial does
most beginner tutorials use casts as they are easier to understand and are usually used in very small levels where there are only a handful of objects to interact with and the items being casted to are already in the levels so casting won't consume additional memory in such cases and won't have dozens of nested casts.
As soon as you're making a game that's bigger than a few objects or if it has objects that are not present in every level, casts should be avoided to keep memory consumption low, especially if you have nested casts.
Thank you so much for this. This is the type of stuff a lot of people don't make straightforward tutorials for, and yours are quick, to the point, and easy to follow. Plus, you actually explain the stuff (again, in a way that's easy to follow) and help us understand it so we get the importance of it and aren't just mindlessly copying what's on screen the whole time. Fantastic videos. As someone who's making an immersive sim, which means you'll have a TON of different objects to interact with in different ways, this helps so much.
Thanks! i am glad you found it to be helpful :) I put a lot of effort into making my video's a tool for learning rather than just copy-pasting like many tutorials are so it's nice to have that be apricated!
You have finally driven home a much needed part of this for me!!! The Input of your BP_PlayerCharacter in the Interface is such a vital part I was missing. I was trying to send variables through input and output but instead you send the reference to the entire Player blueprint and THEN drag off to get the variables inside. THANK YOU!
Check out my video on copy vs references too, because i feel that that may be the actual issue gou were running into
This is a great explanation! Lot's of tutorials use BPI without explaining what it is exactly, this helps everything make sense! Subbed
Glad it was helpful!
This is actually really incredible. I knew about interfaces but when using them I was always just a little confused about them since tutorials don't go in depth about how they work. Now I can hopefully get some more of my ideas working better with better performance.
yeah it's tricky to wrap your head around, especially since casting is so much quicker and more straight forward, so most tutorials use that instead. While I think a lot of people go over the top to try and avoid casting, it's good to know your options!
You do an excellent job of explaining why/how things work to actually help beginners/intermediates actually learn. I'm sure we all know a lot of tutorials out there are 'do this, connect this, Call this' and we do it and whatever system we are working on works, but we dont learn anything along the way
i'm glad that it's appreciated! :)
Very helpful tutorial. Appreciate you taking the time to make it.
Glad it was helpful!
thank you for your explanation about the blueprint interface and casting, It is the first time I understand how the interfaces work. I always had problems with casting, specifically Objects reference for casting.
it's still worth while understanding how casting works and when you should use it. but for something like the example in this video, interfaces work a lot better :)
this video is so underrated, It's straightforward and easy to understand and memories, thank you so much!!
Glad it was helpful!
I absolutely love these videos and I can't get enough. Thank you so much. All these more complex (for beginners) topics I don't see talked ever (unless they're in a 40-video-long playlist) made so simple to make independent game development that much easier. Hats off to you man :)
it's also 4 am and i've been binging these videos. just found your channel an hour ago
Glad you like them!
WOW keep up the great work still new to unreal love to learn
thank you, amazing explanation
I'm usually just a lurker, but this is a great video. Keep it up!
Glad you enjoyed it!
@@thegamedevcave I already knew the contents of this video, but I hope my engagement helps your channel!
When you create the Input as an Object Reference in the Blueprint Interface, it creates Hard Reference and it's the same like the Casting, it's still loading the Character BP the same like the Casting.
Yup
Sometimes, casting is more useful than calling a BPI. This is because you cannot know in advance whether a particular actor has implemented the required interface.
if you're casting to a class you know what class it is you're casting to, and as such you will also know if that class implements an interface. but with interfaces you aren't limited to 1 class (+children). So while casting has it's uses, very often interfaces will be better to use.
if you're worried about running something on a class that doesn't have the BPI implented, trying to message in that case simply won't do anything, so that's not really a problem. if for whatever reason you need to know if the actor you just tried to run your BPI function on does have it implemented or not, you can just add a bool on return , if that's false you tried to run it on something that didn't have an implementation for it.
Now if you need a very specific value or execute a very specific function that only that 1 class has, of course there's very little use in making a whole interface for just that, in those cases just doing a cast is more straight forward. As well as in cases where you know a class is going to interact a lot with another class. (your player character having a cast to it's weapon for instance), there it also makes sense. You certainly dont have to replace every cast in your project with an interface, but largely, a lot of people could do with casting a bit less and using some interfaces to keep their memory footprint under control.
So this is just like Interfaces on programming using object oriented method on C#, C++, Java etc. good to know its also in here it is indeed more memory efficient than hard references
yup, 100% the same, it's just an interface the same as in any other language you're used to. it's all c++ under the hood (kind of) at the end of the day after all
Good stuff
Glad you enjoyed
I'm very new to game dev/programming/UE, and still wet behind the ears.
Is there a "functional distance" on the line trace ? Or would you be able to interact fra across the map?
with a basic interaction ssytem like this I use a line tracer. for a lien trace you give it a start and end point, so it's limited in length. if you want to make that length uper longer, or super short, you can :)
@@thegamedevcave thanks man !
Hello, thank you for your vidéo. Time 05:20, I don't have the "Coin" variable. Not found with UE 5.2, 5.3 even without context sensitive...nothing! In my BPI, I'm in First Person Character Object reference. Do you have an idea?
you gotta add that to the player class first. I'd recommend taking a look at my unreal basics course playlist
@@thegamedevcave Ha, There are a lot of videos! Could you tell me which one please?
Unreal Engine 101 Basics Course ?
@@RV-bc9yi ua-cam.com/play/PLoReGgpfex3x295NSo3hZD6Ylq6hPqdz8.html
@@thegamedevcave Thank you so much for this video the BPI is clearer for me now !
How well does this work with child blueprints using inherited functions? I'm excited to start implementing this, but right now I use a lot of Child Blueprints off of one root interactable BP
I believe if you implement the interface in a parent class all the child blueprints may also have access to it, not 100% sure though but using interfaces makes the need for a parent “interactively object” unneeded anyway
@@thegamedevcave thank you for the reply! I'm just so used to using inheritance in coding to make sure I don't have to re-type anything, I was curious to see how the two concepts interacted in Blueprints. I'm excited to start playing around with interfaces! This is the first video I saw that actually explained them in a way that clicked for me. Thank you!
4:11 doesnt this create an hard object reference as well which would cost performance? would you put in a Actor object reference instead?
Yes but since the player is always loaded anyway, because it is the player it doesn’t actually create any issues
I keep getting a "Accessed None trying to read property K2Node_Event_[Interface Input Name]" everytime I try to get a bool variable from my player blueprint even though I set it and when I use print string I get the character value but the moment I put my bool variable i get from my interface into a branch I get this error PLEASE HELP
hard to say without seeing your node setup but that sounds like your character may not have the interface implemented? usually an error like that implies an actor variable not being assigned a value though.
Made me sub.
welcome! :)
It drives me crazy not seeing you compile or save anything as you do these lol
I have a question, is it more performant would you say to use a line trace on the characters feet to allow for an automatic interaction via interface, like stepping on a button, as opposed to using a box collision with a cast?
yeah, used to working in c++ where saving is less of a priority because when unreal decides to crash it doesn't delete all your progress XD
as for compiling, there's no real reason to do that, when you run the game in editor it auto compiles all your blueprints first anyway so pressing compile and then running the game is a waste of effort XD (now if you need to add variables to a blueprint that you need to get with a cast or whatever in another blueprint, compiling does matter of course)
as for your question, if you're making a button to stand on you probably want to go with the route of putting a box collision on the button (overlap) and check if the actor that overlaps is == to getPlayerCharacter. the player itself has no need to have any code regarding a button like that so you dont need to do that with line tracers and an interaction system like the one in this video.
@@thegamedevcave Ah ofcourse good point, so just creating an object reference to my pawn and checking if it's overlapping. No need for casting or line traces there then. My main priority at this time in my progress is figuring out ways of doing everything in the most simple and modular way I can come up with. Thank you :)
@@mosesgvr1456 yeah the overlap event for your button will come with a object reference to whatever actor triggers it (so that will be your player if the player steps on it, an enemy if it's an eney that steps on it, etc)
you can compare it to the reference you get from GetPlayerCharacter without having to cast or anything so you dont need to make any variables that hold the reference to the player, the overlap event and GetPlayerCharacter nodes will provide those for you
@@thegamedevcave This is great, so what I did was from the 'other actor' pin in 'begin overlap' I created an == and pulled out from that 'getplayerpawn'. Then from the bool pin I put that into a branch and it works perfectly. What's odd is that nearly every tutorial or instruction I come across always always uses cast from overlaps. Maybe it's necessary because I don't know all that much yet, but I knew there might be a way without casting to achieve the same result.
@@mosesgvr1456 casting is only needed if you want to access information or events on your player that don’t exist on a generic actor. If you just want to compare them you don’t need to cast. I have a video that talks a bit more about casting in my unreal basics playlist that might be worth checking out, it’s a tricky concept to wrap your head around haha
💯💯💯
I can't stand most tutorials out there. Everybody using casting, are they not aware it's terrible due to huge memory allocation?
Most of the time, tutorials showing off something entirely unrelated don't want to bother setting up an interface because it takes more time, adds more possible confusion for a viewer and just adds a lot of stuff that is faster to solve with a cast.
Where the issue comes in then is that people watching only 'how to make X feature" tutorials think that casting is the only option to communicate between objects of different classes, or even if they are aware of other methods see castings as the "default" way to do it because they just copy what they see in tutorials without thinking about what everything does.
In a lot of tutorials i will also throw in casts for those reasons but I also put in a lot of effort to make videos like this to make sure people have a recourse to learn more about how things work beyond just copy pasting nodes that I place. At some point, if people don't want to learn beyond a surface level though, that's on them.
btw, i also wouldn't call casting "bad" just misused and overused. the real danger in casting is, if you do it everywhere you create a cascading effect of dependencies, that is where it becomes and issue but there is plenty of scenario's where you just cast to a class which then itself doesn't do any more casts and that's fine really but those are things you have to be aware about, which thanks to a lot of tutorials indeed, a lot of people are not.
@@thegamedevcave I've also been following lots of tutorials lately, including interfaces from many different channels. Some even implement the interface in the player blueprint, some people don't. I didn't see you adding it to your player blueprint so I guess it's not needed there when just sending a call to the interact function of the interface?
I don't understand why this works. Does any interface's functions just always get added to all actor types as messages? Because in code, you'll still have to check if an interface is implemented or not, so blueprints just showing all messages confuses me.
blueprint just does that for you, when you try to messege, it checks if the interface is on that actor's class, if it it, it'll run the implementation, otherwise it'll just move on
@@thegamedevcave Dang. That's pretty cool. I'm refactoring my pickups as we speak. Dankjewel man
random aside, but my personal solution for a system where the player is able to interact with a great deal of objects was to create a parent object and name it something like "BP_Interactable," and put some empty "On Interacted Events" and just cast whatever we hit into an Interactable and call On Interacted.
ofc every interactable object you make must be a child of BP_Interactable. I'm too high to remember how to do it, but just do a blueprint function override on the On Interacted function and that way you can have your child objects be things totally different things like doors that swing open, boxes that break, priceless art which can be defaced, ect. It was a good enough solution and I wanted to share lol
that's a decent workaround but generally, using an interface does the same thing and avoids casting altogether and is more flexible.
But effectively this workaround works more or less the same way! (just annoying whenever you're deep into a project and you suddenly need to have a actor that's a child to a different class but should ALSO be interactable, unless literally every actor class you make is interactable but then you run into issues with, what if i want to make a pawn that can be interactable or a character? do you make your interactable actor class from the character class? because then you have the issue that everything in your game is now a character without it needing to be, etc.)
@@thegamedevcave yup! it works fine for something like a single player puzzle game with no NPCs or AI, but isn't flexible enough for a more complex project.
@@thegamedevcave Your videos are nice to watch, but damn, nobody would ever do it like that. That's simply not how you would use interfaces even in small scale productions. Inheritance, dispatchers, interfaces all go hand in hand. There are always different approaches, but the one you describe here is impractical and ends up being a total mess once you step over a certain threshold of scale in production. The way youtubers teach topics like this is horrendous.
@@aff3nm4nn of course there is no single "catch all" method. in some cases interfaces make more sense, in some cases inheritance makes more sense. and sometimes you dont want to use either and you're better off using delegates.
The issue with youtube tutorials is that they dont have production context, so just showing an example without any surrounding context is limited in how much you can truly show each usecase. All I can do is to show the options, explain what they do and what the upsides are and leave viewers to make their own decisions on what fits for them. Anyone watching tutorials and just blindly copying things over 1 to 1 isn't actually learning anything anyway, you always have to apply things to your own projects with all the context of that code you already have in that.
as for your comment "nobody would ever do it like that", i assume this is referring to the example in the video showing the basic interaction system? Because I think that this is a pretty good way to do things. You could use a parent "interactableObject" class instead if you wanted to but that could very much lead to limiting yourself down the line. Again, this is very context dependent, if you know that all the objects you will every interact with can neatly fit into your actor hierarchy, it might be easier and more straight forward to do that. But there isn't any "right" or "wrong way about this without a lot of surrounding context.
If you'd like to give some more details on your opinion I'm all ears though.
This still does create a hard referance to player tho right?
no, interfaces are kind of like event dispatchers, they just call out and if the object you're messaging it to has an implementation, it will run that code. the caller doesn't have to be aware of any classes it communicates to.
of course, any parameters you may put into an interface will still create hard references.
@@thegamedevcave i hope that is the case. but looking at reference viewer it has created a hard ref. it doesn't if there is no input for player character in the interface but creates one if there is one. (like you did to get coin)
i have to assume you have another hard reference between whatever classes you're working with because the interface's whole purpose is to avoid that. both classes have references to only the interface but not each other.
@@thegamedevcave i'm stomped. the BP has literally nothing but the Event from interface. with nothing attached to It either. Obvielsy event has the ref just like you created one around 4.20
do you have community discord by any chance?