Unreal Engine 5 - Things I Wish I Knew - Global Variables
ฝัง
- เผยแพร่เมื่อ 29 ก.ย. 2024
- This video will help you learn how to use variables more effectively as well globally!
Make a Horror Game from Scratch: • UE5 - Make A Horror Ga...
My Social Links: linktr.ee/Dark...
Help Support Me: / darkslayertv
My Games: darkslayertv.i...
![CAMPปลิ้น | EP.82[1/2] แก๊ง 3 สาวเพื่อนซี้บุก CAMPปลิ้นครั้งนี้ห้ามเสียอาการ](http://i.ytimg.com/vi/_6WUjXHe1TM/mqdefault.jpg)
Thank you! I never understood this and now I finally do.
be careful with casting ! in a small test project it will be fine, but in a real large game the things will start to go crazy for memory usage.
its not just in unreal engine its in programming in general , i learned this 15 years back when i started programming
i made such mistakes early as (casting heavy files "includes()") to the main just to call certain Variables/Functions
and i thought just because im using one or two variables from the Included file it will be a light task, ( wrong ! )
the website was taking like 8-12 seconds to load,, & after i stopped (casting) the entire files into each other
the website start to load in 1 - 2 seconds !! Huge diff
let me explain it in an easy way
the difference is that "interfaces" is like calling a pizza dude to bring you only the specific pizza you want with the details you asked
just one piece !
while "Casting" is like you calling the entire food truck + a portable kitchen with all it expenses to come to your house
and both (the food truck + the portable kitchen truck + the Entire Crew ) have to wait beside your house < day / night >
st so you can ask for ( anything anytime )
now which one is going to be more expensive and more resources consuming ? i thing the answer is clear
interface bring only the Variable you need (AKA color) without having to read the entire blueprint file (actor / pawn .. etc) of the target
so your memory will be chilling
while Casting Load the Entire file -> (((( then it Hold it in memory )))) and wait for you to choose anything you like from there
which is called ( hard reference ) you shoving something heavy into the Memory and leave it there as long as your character is alive
now the performance if the blueprint you are casting is light no worry it will be fine
but that's when things goes crazy for memory usage >>
that's why interfaces is always the (Safest/best) practice
-- also a very important advice id give you :
" don't measure game performance based on your biffy PC, the majority of your players will not have the same powerful machine "
Excellent bit of advice everyone should read and consider!
This is good advice, but it has its own issues. You need multiiple blueprints that talk to each other. You need one blueprint that needs to get all the blueprints with your interface. It's going to get that blueprint, wether or not it implements any function from it. So if you have a 100 blueprints, it's going to dump that into the array. Then the one blueprint will send the interface function message to each of them; again regardless of wether they are used or not. Now what happens if the blueprint that has the interface, hasn't even been created yet (such as a widget)? Nothing. So what's the better solution? We need a way to access global variables without the need to cast or send. We can use the GameInstance, but again you have to cast to use it.
If you find yourself needing to avoid the potential memory overhead associated with casting in certain scenarios, consider alternative design patterns or refactor your code. One approach could be to utilize conditional checks before casting, ensuring that the cast is only performed when necessary. Additionally, you might explore design patterns like the observer pattern or events to establish communication between objects without resorting to casting in every situation. Careful consideration of your game's architecture and the specific requirements of each interaction can help mitigate unnecessary casts and optimize performance.
Optionally you could save brain keys in GameMode or GameInstance.
or GameState
Thats what i tought ! why would you want a new blueprint to do this? The only reason i think would be to keep the GameMode or Game instance clear, and be able to destroy the bp brain once you dont need it anymore.
Does a Global variable equate to a variable that persists between levels? Ive been looking for that video and would like a demonstration on cross-level stored states for my variables ( like key ring persisting between levels)
The game instance is an amazing place to store variables that need saved between levels. Otherwise you have to have a saving and loading system to carry them forward. Best of luck!
8:00
WTF did you just bypass the need for casting or bpi??
- but then you wouldn't need any bpi at all
*I'm so confused!1!*
Key - ID - Mundi
Please I face this problem when I tried to export my game to android. The light seems good when playing in editor but when I export to android, it gets dark. I've done all I can to the lighting, it is still dark on export to android. I use ue5 early access. What can I do to sort out this?
Unfortunately there's a lot of scenarios that could cause this. My suggestion would be to make sure you didn't set your lights to 'static.'
That is a shader issue. You're viewing the project on your PC with SM5 shader preview, but when you package it to run natively on mobile, your shaders are limited to vulkan or ES3.1. There are numerous solutions to this, but I must stress, there is no easy way to 'brighten up' what you've already built so far. First though, you need to set up your preview in UE to mobile ES3.1 or vulkan for a more accurate idea of what the final build will look like.
thank you!!! @@GetawayFilms
Right-click to turn single into array = mind blown. Thanks for that tidbit! 😅
I would say tho that this is a great case for using a DataAsset or the GameInstance to store the variable instead. The benefit of using the DataAsset is that you can create different DataAssets which store different variables and run different code depending on to what they are relevant.
Still good stuff. Thanks for sharing!
I am using Data Assets to store variables for my characters, to make a "race system". To implement this tutorial to make my "Brain" actor to get this Data Asset variable, All I would have to do is, instead of adding the variables needed from the Data Asset one by one into the "Brain" actor blueprint that stores the variables, I would just assign the Base Character Data Asset from which all my character data assets are derived from, as its own variable in the "Brain".. correct? Or would I need to add more variables than that?
I cannot get the point.... why we not just put global variables in level blueprint or gamestate? or even place them in a game instance?
I believe to promote encapsulation, because blueprints are based on C++ which is an object-oriented programming language. In general, Global variables are something you should avoid, because they can be changed anywhere in the program; possibly resulting in bugs that are very difficult to find.
I can't get this to work in a slightly different case - When I click on my "key" object ( I'm using Left mouse event instead of Overlap ) I don't just get the "KeyID" from it, I get all of them from all of the key instances. Instances kicking my ass again and again and again - can anybody help?
An Actor Component is an excellent place to store variables and information. You can add the component to whatever blueprints you want, pretty much, and then use the variables in it; especially useful for widgets. When it comes to multiplayer it's a must!! Because then you can get the owning player, their specific component, and change things for just that one player versus the entire server of players. So rather than your brain being a blueprint Actor with a viewport and all that, a component is more just information... It's where you would store health stats, the reference to the individual player HUD, etc. But the concept is the same as what you've done here, just a different base/parent class.
Not sure if any of that made sense with how I've worded it. Haha!
Anyways, nice tutorial! :) Keep it up!
I was trying to do something similar with gameplay tags container and tags...but Im not sure is possible. Anyway, cool and usefull video! I wish u'll continue on this way! Thank you!
The quality of your tutorial is great!
But that's not global variables, you just created an object in the scene and make other objects reference that.
You said you wanted to make everything looks clean, but all objects would have to implement that boilerplate code if they want to access your "global variable".
If the "Brain_BP" doesn't exist in a scene, all objects that reference it will potentially break, so they would, if you don't implement a way to check if your brain_BP is valid in the logic of each object, but that's only ends up making you need to write more boilerplate code.
You're also creating lots of dependencies to one class, so if you change something in your Brain_BP, all classes that reference it, would potentially break.
There are much better ways to implement that, you can, for example use your Game Instance + Interfaces to access the values.
I feel very sorry to say this, but I feel like I was click-baited and wasted my time watching this video.
Also I don't want to offend you, my intention is just to give you a constructive criticism.
Agreed, and I feel similarly 'baited'. However, I feel his lack of understanding was the cause of the accidental 'clickbait' title. He genuinely believes the title to be accurate. I'm sure it wasn't intentional, and I know you feel the same way. :)
I like your comment and I see your point, correct me if im wrong, but the term should be "Public" every variable is global until you tell the engine to be local. Btw the Game instance + interface way that you suggest was excatly what i tought ! Why would he want a new blueprint to do this? The only reason i can think about would be to keep the GameMode or Game instance clear, and be able to destroy the bp brain once you dont need it anymore, i guess..¿?
@@guillermofleitaspulido A global variable is a variable that is acessible to any object at any given moment while the application is running, public variables are variables that can be acessed as long the object that stores the variable exists.
Basically, as long the program is running, a global variable can always be acessed.
Maybe he's not using the game instance because he doesn't know that this is a thing, also, if he wanted to keep the game instance clean, he can create a Game Instance Subsystem, which is basically a singleton that is initiated alongside with the game instance,
8:38
Anyone else catch that?
"( pink )Key and the brain"? hurr... no?
its completly fine to store a ref to the Brain since is basically an empty actor, but then casting to the first person character from the brain will make everything that needs the brain, needs to load the first person character, so u making your door or whatever it is, get a ref to the first person character, other than that, its fine and a good idea to have actors that control other actos.
Nice video. How do I make first actor’s variables appear in second’s detail panel?
congratulations! you hitted 1k subs you desereved it now road to 10k ;)
Thanks! I appreciate it!
Nice tutorial, Clean and Straight, keep it up
Following the tutorial step by step but I am getting an "Accessed NONE" error when trying to get the Brain REF Variable!
Great
Funny...I came here hoping that this was the way to do it and I was right. Instinctively you would think you would put these variables in the Level BP but that apparently is an issue so this works perfectly. Thanks!!!!
If you have multiple keys for a door do you use multiple contains?
Daiiiuummm
im fairly new to Unreal ( i had to use it in a university project and now im kinda hooked) and this opend soooo many new options for programming
thank you
im picking up what you putting down !!!! i love it
Thank you! This is really great!
Would this also work with a set of buttons? To make the game remember which button's collision is already set to active, or pressed, when transitioning to another level?
nah only gameinstance blueprint is persistant (dont reset when transitioning to another level), simply way is just hold some variables in gameinstance, but propably better way is just make "Save Game Object"
so the eye for making variables public doesn't seem to be doing what its supposed to do, i have a simple cube that i need to be able to assign its X, Y, and color values in the level editor however the variable i created to do this doesn't seem to appear in the details panel any help would be much appreciated
There's a few ways you could interrupt exactly how you're doing it, but tbh to change an objects material in real time might not be possible? Tbh I'm not 100% sure though, not something I've tried to tackle.
Found this very handy just now, thanks!
🙏👊
How do you get the keys to persist across levels? If a player grabs a key on one level doesn't it reset to default on level 2?
When switching levels you'll need the game instance to hold information for you or have a save game you can load from.
This is like a singleton
Sort of but he says he is only using it for one level; So, if he makes one for each level then it would not be a singleton; And it also does not look like he is using global variables either; Global variables are something you should anyways avoid.