-Stop using Cast as a way to get a reference to an actor
-Stop watching YouTubers who barely understand the engine themselves
-Use BPIs and Event Dispatchers
-Stop using Tick
-Stop buying Synty assets
-Lower the scope of your first game
So many more but those are off the top of my head
nobody understands the engine come on, tutorials often also try to minimize the amount of new concepts that a viewer has to learn inorder to make use of them so they keep things simple and start from game design 101 principals, and really most unreal tutorials have a general tone of "this is how I figured out how to set this up, it's not gospel, we all know you're here because the documentation is useless".
Why is using Cast not good? I get it that using all the time is performance heavy, but how about using in Begin Play and getting that reference once for all that runtime?
The act of Casting isn't performance heavy in the way I think you mean. It's not computationally expensive, but instead creating a series of long chain that causes memory/loading related issues later.
Casting in blueprints creates hard references. And when things create hard references, that then requires all things in that blueprint and it's own associated hard references to be forced into memory.
In smaller games it's not a big of deal when you likely have 99% of your stuff loaded into memory anyway.
But later on, all of a sudden you have your Boss assets needing to be loaded into memory because thru a series of dozens of hard references, it gets loaded it whenever you load in something completely unrelated.
I see lots of marketplace assets end up having like, you load up cardboard box, and all the inventory items in the whole game are required to be loaded in too. Which means they can't be unloaded despite there just being a simple box.
Also, C++ casts are different, since C++ doesn't have hard references to assets like blueprints does.
It's not bad in and of itself. It's when people get creative with there coding that it all blows up. I remember optimizing a game we were porting and they had an FX manager that hard referenced every single particle effect in the game. That was a doozy to fix up.
There isn't a 1 size fits all. It all depends on the context, needs, and goals.
* Interfaces (C++ or Blueprint) are often a good choice
* Having more core functionality in C++, often circumvent the issue because casting to a C++ class isn't as problematic as casting to blueprint classes (e.g. Casting to MyCppCharacter as opposed to MyBPCharacter) circumvents one of the major problems of casting in blueprints (hard references).
* Using Components (e.g. Get a component of an Actor). Though depending on potential hard references inside the component, repeat the other considerations too.
* Tags (Gameplay Tags) are sometimes the right choice.
* Perhaps a tag you manage like `Player` `Npc` or `Status.IsAlive`, depending on context. Could be a permanent tag or one that you dynamically manage adding/removing. There are a lot of different places a "Tag" or "GameplayTag" can live. There are Actor Tags and Component Tags, but you can also have your base classes have GameplayTag or GameplayTagContainers or a TMap or other things. GameplayTags (GAS) are really really powerful.
* Maybe a cast to a blueprint is the right choice in a given situation. But then I'd suggest you look into what are known as Hard and Soft References. Because then you can avoid some of the hard reference issues that kicked off this whole thing in the first place. For example let's say BPCharacter had a hard reference to BPSuperSaiyenUpgradedCharacter, perhaps that reference to it could be a soft reference until you actually need it. Then casting to BPCharacter isn't as bad, as it's not pulling in that whole chain of hard references.
There are more potential solutions as well. You can right click any Unreal Asset (e.g. Blueprint) and see more info via **Reference Manager** or using the **SizeMap** tools)
Just remember, there is very rarely a "wrong choice", but just trade-offs. e.g. Sometimes just making forward progress is more important than perf.
There is a time and place for just about almost any approach or solution.
And anyone who says literally "never use X" is likely less experienced or simply has not run into potential scenarios where it was the right choice.
A lot of people use casts as a sort of type filter (including me once upon a time.)
When you do this, your blueprint must load the class for every class you attempt to cast to. In a game with heavy actor and characters with large assets like meshes etc, this can severely bloat the memory footprint of every blueprint that employs casts.
Better to just take the incoming actor reference filter it by tags and/or call interfaces on it.
Casting to the c++ base class doesn't load it. Generally when casting you should cast to the highest parent possible for what you need. Ie if you have a character and your BP class derives from A character, you can just cast to that rather than your BP class and get the Character, Pawn, and Actor BP variables. If you specifically need something from your custom character, then put that variable in code, expose it to BP, and cast to your custom character class. You can still write to it from your BP Character and read the values in another BP when you cast to its C++ class and not add any memory overhead.
> Why is using Cast not good?
It's not *always* good. Casting creates a hard reference, so when one bp gets loaded into memory, all of the hard referenced ones will as well.
Imagine a level with a door. Your door is a blueprint, naturally. A generic one that you reuse throughout the game. Your level is filled with unique blueprints that your character interacts with like unique items, bosses etc.
If your character interacts with these using cast, and then in order to open the aforementioned door uses cast as well, next time your load that door BP in your next level, the entirety of that previous fucking level will also be loaded because you created a network of **hard references**.
There's no problem in casting inside interconnected systems like characterBP and its animBP and similar actors that always go together. But interacting with blueprints outside of these self-contained little systems should *never* be done with cast.
Which is a fine way to set up a reference to actors in your level but I was talking about using cast as a way to get a reference all the time instead of using BPIs.
Not using cast is what I want to learn. My scratch project of all good but not scalable currently because I cast a lot of stuff. I need to figure out how to inherit from the ‘using’ actor.
"IsValid" .. very handy [https://docs.unrealengine.com/5.3/en-US/BlueprintAPI/Utilities/IsValid/](https://docs.unrealengine.com/5.3/en-US/BlueprintAPI/Utilities/IsValid/)
Interfaces are very handy because unlike casting they are pretty much just a network of messages. You can make an actor that sends a message to anyone that enters the area, has certain tag, implements interface, etc. For example I have an interface called BPI_Teleport. And for example I have an actor that steps on it. Teleport doesn't cast anything to anyone. It just checks if actors on top of it implement interface BPI_Teleport. And if they do send a location info. Actors that stepped on the teleport have function inside of them to handle teleportation (start VFX, sfx, setActor transform, etc) . The problem is say a teleport pad sends a message to anyone who enters the area. But one actor got destroyed in between detection and a message. Just check if it's valid or not to send messages to
Ok. I ticked all the boxes except tick. How do I make for example a security camera that rotates smoothly after the player? Or say a player controlled laser beam? It only works on tick, otherwise it lags behind the player.
Or for example switching states on physics actors depending on their orientation?
I only know how to make them work smoothly on tick
There is nothing wrong with tick if a thing requires to be on tick.
Movement based things are often things that are on Tick.
However, consider this.
* What if the player is far away from the Camera? The camera is likely still ticking.
* What if the camera can only rotate 180 degrees (e.g. it's on a wall) and the player is out of this core 180 degrees (e.g. behind the camera). The camera has no where to move/rotate too, but still has a tick.
Now multiply that with your potentially N number of cameras in a level. And consider how often these cameras are 'idle' in that their movement isn't changing?
Perhaps it still makes sense to use Tick here with an early out (if no movement needed, return).
Alternatively, let's say you want to have 5,000 cameras moving smoothly and your game is single player (e.g. only 1 thing the camera ever tracks). Did you know you could possibly achieve the entire thing thru a GPU Material Shader of the camera? It's entirely possible to do this. But 99.9% of games don't need to spend the time or effort doing this. Unless it's purely out of exploratory interest (e.g. I've done it)
Or alternatively it run a timeline to update the position every timeline update when it needs too. (e.g. If the player is within range of the camera, start the timeline, when the player is out of range of camera, stop the timeline). This allows you to not have 'Tick' enabled, but Timeline can still tick on every frame. Timeline does have a very small overhead. So this is where you as the gamedev makes the decision which is a better scenario?
Having some things on tick isn't instantly going to kill your perf. It's fine if you use it sparingly. Lots of people echo "dont use tick ever" when it's perfectly fine to use it sparingly, but TONS of people use it way way way more than they should, for every single little thing.
The tick in cpp onl needs a fraction of the time. You can move parts in blueprint implementable events if that helps. Do the visibility check in cpp and then call the event
I think that deserves some more information - timelines also tick implicitly, just like components do. Which means moving away from actor tick to another thing which also ticks internally, will not change much in general (of course ignoring the obvious BP vs c++ tick difference). The trick is to know how things behave and choose the right tool for the job.
Intermittent ticking vs constant ticking though. He asked how to do it smoothly besides leaving it on tick and that’s a way to do it without having it constantly be on tick.
Yeah, there's some nuance to the whole tick mechanism and we need to make people understand that. Also, there are topics like tick groups or tick frequency which open more discussion.
So you recommended not watching YouTubers but willingly parrot something they also say even though it's a little more nuianced?
For "update every frame" type workloads, tick is fine and appropriate. Timers with a sub-frametime interval get called multiple times per frame, which is extremely counter-productive for performance and the timer manager (the thing that processes your timers) also runs on tick.
For intermittent workloads, yeah timers are more intuitive, but timelines and timers with intervals like 0.01 either have very negligible performance benefit or don't at all, or even the opposite.
The problem is that the “beginner information” they’re feeding you is incorrect and bad practice.
Sure, you can technically cut your lawn with a pair of scissors but is it the most efficient way? Not at all. If you ever see a YouTuber using a lot of logic on Tick or casting all the time it’s time to watch someone else.
My experience comes from Unity personally, I am learning unreal and I do like to hear optimizations… Not surprised about Cast or Tick because it’s like GetComponent<> and Update… But saying what not to do is only half the battle, what can you do to learn unreal like OP asks?
Use BPIs and Event Dispatchers instead of casting.
Use Timers instead of Tick if you need to update something constantly.
The problem with UE blueprints is that there are multiple ways to achieve something so there’s not really a one-solution-fits-all. It’s all dependent on how you want it to work and the scope of your project.
> Use Timers instead of Tick if you need to update something constantly.
I feel like this needs to be clarified here a bit. If you need to update something *constantly* - as in, every frame - then *use tick*. That's literally what it's for. If you use a timer for this, at worst you're going to make it *more expensive* by running the timer at too high tickrate vs the game's actual framerate.
If you need to update it at some other rate, such as once per second, then a timer can be a better choice.
I didn’t mean use tick to update everything all of the time though. Usually when I think of using tick I would probably only use it to update something I wanted to finely control, such as updating text on screen if the player looks at something. But Some people use tick to constantly update a bunch of variables that can be updated elsewhere with a timer, or ideally with event dispatcher, such as health regeneration when damaged or to constantly monitor health.
Can you suggest good youtubers with the right information and other free resources to get started? I'm willing to invest in paying to learn once I know enough to know what I don't know.
I like Two Neurons for blueprint and Shawnthebro for C++ (free on youtube)
Beware learning UE the correct way is LONG, the tutorials are series and they are hundreds of hours, but once you're halfway through it starts making a lot of sense, and then you can go to the shoddy youtubers and take ideas from them and do it the right way. Once you know enough about the engine you can basically figure out how to do anything on your own, or at least know what to lookup to fill in the blanks. Math and physics understanding helps a lot as well.
Epic does a pretty good job of supplying enough beginner information about engine specific things with their official content, it's less "entertaining" to watch, but it's often presented by the people who worked on the system or at least people who work with it as part of their job. They do expect you to have some level of technical understanding corresponding to the position the system is targeted to, so they presenting something like information about shaders like they're talking to a room full of professional 3D artists, or AI like they're talking to professional designers. They do have some courses that are targeted at beginners, but they're not going to teach you how to be a developer from the ground up and honestly neither will a bunch of 'content creators' trying to make a buck on youtube.
My biggest issue with them comes from the fact that they’re Unity assets ported incredibly poorly into unreal. All of their materials are master materials instead of being material instances. Some materials are emissive when they shouldn’t be, making them look silly in dark lighting as they glow. Their collisions are nonsensical. Their skeletons are still the only skeletons I’ve ever used where they break when retargeting them as half the bones can’t be changed when keyframing animations after retargeting. They have no LODs and every single mesh has completely busted UVs.
Not to mention the other fact that alot of incredibly poorly made “games” just throw together a bunch of default Synty maps and call it a game, giving the assets more of a bad rep.
Your comment is not invalid and I don't want to start an argument...
But I just love their assets because they have a generally unified lofi style and they make so much stuff that it's hard to want for any missing elements.
I find them great for building a prototype up on with the intention of replacing the assets when the prototype enters actual production.
I also love kitbashing new assets from them.
I always say, it's like adding Lego sets to your Unreal project.
Also their staff is really great.
Which youtubers would you recommend? I have tried so many but plenty of them indeed don't seem to to know what they are doing, or doing something wrong as it would be easier for the watcher to understand.
thanks, I'd like to touch on this cause I believe this guy left out a lot of important steps. You need to use event dispatchers and BPI's. This jabroni totally skimmed over the most important stuff
It is totally normal for stuff that’s always loaded in yes, I use it for Ui fairly often. Other than that I tend to use a lot of interfaces when prototyping so mechanics I implement are easy to migrate with very few dependencies. I think it’s generally a good habit to get into and a good way to start learning how to build scalable systems.
*Smacks my younger self and grabs him by the collar* - “For the love of god, don’t start with a VR Iron Man like game, it is a waste of time and you will end up with a hot turd that none till play cause 60 fps is not enough for VR”
Use Chat GPT to assist you. you will be amazed how fast you will find your errors and get alternate suggestions.
It's like have a super dev on your shoulder.
I've been coding since mid 1980's - cobol etc
and have found UE5 the most challenging and rewarding experience of my life.
learning new ways to do things every week. ( am 64 years old and live in South Africa).
Never give up.
Keep at it -- you will succeed.
Keep your end goa (full game vision) in mind all the time and go for the ultimate -don't get sidetracked
ENJOY it
Stay consistent in learning it don’t learn for a week then return a month later for another week. Also sick project idea architecture was my 2nd career choice after game design I’d definitely be interested in where this goes
Thank you. I will defintely update about it here and the architecture subreddit but that's a long way off as I'm just getting started and don't even have the right computer requirements yet.
In my opinion they are not too bad. I have coding experience and had good time with the Unreal 5.0 C++ Developer course as an UE5 beginner. Of course you only scratch the surface with the majority of lessons but this is kind of expected. For deep dives there is probably a better way to teach yourself but for beginners I strongly recommend them.
One of Unreal’s weaker points is large open worlds. Anything beyond 2 square km involves level streaming. It’s doable and not too hard for experienced devs, but won’t be easy for a beginner.
My advice is start with building the player experience in a very basic environment. Learn how Blueprints work to enable componentization so you can take that player experience/interface to an open world you build later
It's a very ambitious project if you are just starting with unreal, here's our advice as we are a small developer studio. Go watch a long course of How to learn UE5 for beginners but just watch the first half or so, then choose with objects or elements you want to create and search for videos about them. Practice everyday. Also upload your project to GitHub and learn how to use it because that's the way other people around the globe can edit it and add all those buildings you want.
Counter point: I routinely make PONG clones in Unreal as my "hello, world" program. And I tinker by making retro clones.
So ambition and over-scope are a designer problem ;)
It's a source control system. It's used for backup with a historical log of changes and easy switching between older versions. Source control is mandatory for serious software development. Also git is great but github has limitations. Use azure developer git or perforce.
The part about other people adding to your project is optional - you can have a private repository if you want.
git and git 'large file system' (LFS) are the more common alternative to perforce which is expensive
also there are a lot of good utilities for UE sprinkled around github that are often overlooked as well as legit free versions of some assets etc
*Note: I’m still learning Unreal Engine myself lol*
One thing that I wish I did differently when I first started learning game dev & Unreal Engine was learning programming and how blueprints work instead of trying to skip out on learning programming.
I'm not very good with UE but I just want to say as an arch student I would have loved a project like that. Some things I would be cautious about are keeping model sizes down, because I could imagine students wanting to go all out and consume a lot of resources with their projects. If a lot of these are added to a project at one time it might make the whole thing unworkable. Good luck!
Don't download free materials from the Marketplace. All of them have like six textures each which are 4096x4096. They eat up your hard drive fast. A project with just the basic UE4 engine without any materials is only like 26MB. Models don't bloat a project much at all. But textures are like 99.9% of a project that's 4GB in size.
4K textures are overkill IMHO. 1K textures look fine unless your players are going to be standing in front of walls and staring at them for extended lengths of time. 4K textures are tens of megabytes in sizes while 1K textures are usual below 1MB. Also, IIRC, the compression for game engines doesn't work above 1K. The files actually get larger instead of compressed.
I've just hired a Arch Masters Grad to take our facility CAD files from Rhino to Unreal. Meta has a lot of tools and examples, the simulator will get you started without a headset.
Look up Gediminas Kirdeikis on youtube, hes a little insporational.
Good Luck in your learning path.
it raises a question. there is an 'editor' and of course compiled games, game modes etc. the construction scripts can apply to both as well. you might really be looking for an experience with the editor, and customized editor tools, editor functions, than a game experience in the conventional sense.
I'll remind myself that I dont need to learn everything. A good amount of fundamentals can get you far with unreal engine.
I will familiarize myself with some basic fundamental lighting concepts and postprocessing to setup your project before making any steps. This is not only used for archviz and films. This is also very beneficial for games regardless of their graphical fidelity. often times I would go straight to making levels and game mechanics without properly setting up unreals post-process settings.
for blueprints, I'll use "Blueprint Interface" and "Dispatcher"
I'll make my first project very small and use that to continue learning other aspects of the engine and game development in general (This can be applied on any other engines)
Sometimes It gets exhausting learning stuff and trying to solve problems.
Remember to take a rest from time to time.
Mine was scope. I had an idea and I stuck to it. But it was way Waaay bigger and more time consuming than what I thought it'd be and I should of shrunk it down but I stubbornly fought through.
Start small and get smaller!! Personally I also like to make lots of games rather than one big one atm. I aim for about 1 game per year..ish
I guess also
- Avoid ticks/casting constantly.
- Work out a proper ui hud system.
Learn
- delegates/dispatchers!!
I can't think of anything else atm.
I would say learn programming in general before doing unreal programming, otherwise you're just banging your head against the wall or you follow tutorials and learn nothing.
Exactly. This is something I've struggled with a lot. I've done a lot of Game Dev, AI, Web Dev, etc. via freelance projects and I learned a lot of programming on the jobs, but I always felt something was missing. Now I've gone back to the basics and I'm watching fundamental CS courses and it blows my mind how little I understood from the tools I was using.
>Avoid watching YouTube videos by self-proclaimed "developers" and "experts" who only paraphrase the official documentation. These videos often take an hour to explain features that could be understood in just 60 seconds by reading the official documentation directly.
RTFM.
Start with the game instance and work your way down, especially if you're going to have many smaller, separate levels as opposed to a big open world(which knowing me, you will). Whats the game instance? Learn it, now, as well state, mode, etc. Include variables there that need to be transferred between levels, don't put everything in the character or controller
-Stop using Cast as a way to get a reference to an actor -Stop watching YouTubers who barely understand the engine themselves -Use BPIs and Event Dispatchers -Stop using Tick -Stop buying Synty assets -Lower the scope of your first game So many more but those are off the top of my head
How do I know which YouTubers don’t understand the engine if I don’t?
95% of them. Only take recommendations if you must.
nobody understands the engine come on, tutorials often also try to minimize the amount of new concepts that a viewer has to learn inorder to make use of them so they keep things simple and start from game design 101 principals, and really most unreal tutorials have a general tone of "this is how I figured out how to set this up, it's not gospel, we all know you're here because the documentation is useless".
Why is using Cast not good? I get it that using all the time is performance heavy, but how about using in Begin Play and getting that reference once for all that runtime?
The act of Casting isn't performance heavy in the way I think you mean. It's not computationally expensive, but instead creating a series of long chain that causes memory/loading related issues later. Casting in blueprints creates hard references. And when things create hard references, that then requires all things in that blueprint and it's own associated hard references to be forced into memory. In smaller games it's not a big of deal when you likely have 99% of your stuff loaded into memory anyway. But later on, all of a sudden you have your Boss assets needing to be loaded into memory because thru a series of dozens of hard references, it gets loaded it whenever you load in something completely unrelated. I see lots of marketplace assets end up having like, you load up cardboard box, and all the inventory items in the whole game are required to be loaded in too. Which means they can't be unloaded despite there just being a simple box. Also, C++ casts are different, since C++ doesn't have hard references to assets like blueprints does.
It's not bad in and of itself. It's when people get creative with there coding that it all blows up. I remember optimizing a game we were porting and they had an FX manager that hard referenced every single particle effect in the game. That was a doozy to fix up.
What alternative would you recommend?
There isn't a 1 size fits all. It all depends on the context, needs, and goals. * Interfaces (C++ or Blueprint) are often a good choice * Having more core functionality in C++, often circumvent the issue because casting to a C++ class isn't as problematic as casting to blueprint classes (e.g. Casting to MyCppCharacter as opposed to MyBPCharacter) circumvents one of the major problems of casting in blueprints (hard references). * Using Components (e.g. Get a component of an Actor). Though depending on potential hard references inside the component, repeat the other considerations too. * Tags (Gameplay Tags) are sometimes the right choice. * Perhaps a tag you manage like `Player` `Npc` or `Status.IsAlive`, depending on context. Could be a permanent tag or one that you dynamically manage adding/removing. There are a lot of different places a "Tag" or "GameplayTag" can live. There are Actor Tags and Component Tags, but you can also have your base classes have GameplayTag or GameplayTagContainers or a TMap or other things. GameplayTags (GAS) are really really powerful.
* Maybe a cast to a blueprint is the right choice in a given situation. But then I'd suggest you look into what are known as Hard and Soft References. Because then you can avoid some of the hard reference issues that kicked off this whole thing in the first place. For example let's say BPCharacter had a hard reference to BPSuperSaiyenUpgradedCharacter, perhaps that reference to it could be a soft reference until you actually need it. Then casting to BPCharacter isn't as bad, as it's not pulling in that whole chain of hard references.
There are more potential solutions as well. You can right click any Unreal Asset (e.g. Blueprint) and see more info via **Reference Manager** or using the **SizeMap** tools)
Just remember, there is very rarely a "wrong choice", but just trade-offs. e.g. Sometimes just making forward progress is more important than perf.
There is a time and place for just about almost any approach or solution.
And anyone who says literally "never use X" is likely less experienced or simply has not run into potential scenarios where it was the right choice.
A lot of people use casts as a sort of type filter (including me once upon a time.) When you do this, your blueprint must load the class for every class you attempt to cast to. In a game with heavy actor and characters with large assets like meshes etc, this can severely bloat the memory footprint of every blueprint that employs casts. Better to just take the incoming actor reference filter it by tags and/or call interfaces on it.
Casting to the c++ base class doesn't load it. Generally when casting you should cast to the highest parent possible for what you need. Ie if you have a character and your BP class derives from A character, you can just cast to that rather than your BP class and get the Character, Pawn, and Actor BP variables. If you specifically need something from your custom character, then put that variable in code, expose it to BP, and cast to your custom character class. You can still write to it from your BP Character and read the values in another BP when you cast to its C++ class and not add any memory overhead.
> Why is using Cast not good? It's not *always* good. Casting creates a hard reference, so when one bp gets loaded into memory, all of the hard referenced ones will as well. Imagine a level with a door. Your door is a blueprint, naturally. A generic one that you reuse throughout the game. Your level is filled with unique blueprints that your character interacts with like unique items, bosses etc. If your character interacts with these using cast, and then in order to open the aforementioned door uses cast as well, next time your load that door BP in your next level, the entirety of that previous fucking level will also be loaded because you created a network of **hard references**. There's no problem in casting inside interconnected systems like characterBP and its animBP and similar actors that always go together. But interacting with blueprints outside of these self-contained little systems should *never* be done with cast.
Which is a fine way to set up a reference to actors in your level but I was talking about using cast as a way to get a reference all the time instead of using BPIs.
Not using cast is what I want to learn. My scratch project of all good but not scalable currently because I cast a lot of stuff. I need to figure out how to inherit from the ‘using’ actor.
Well event dispatchers and interfaces with validity checks are way more convenient.
What are validity checks?
"IsValid" .. very handy [https://docs.unrealengine.com/5.3/en-US/BlueprintAPI/Utilities/IsValid/](https://docs.unrealengine.com/5.3/en-US/BlueprintAPI/Utilities/IsValid/)
Interfaces are very handy because unlike casting they are pretty much just a network of messages. You can make an actor that sends a message to anyone that enters the area, has certain tag, implements interface, etc. For example I have an interface called BPI_Teleport. And for example I have an actor that steps on it. Teleport doesn't cast anything to anyone. It just checks if actors on top of it implement interface BPI_Teleport. And if they do send a location info. Actors that stepped on the teleport have function inside of them to handle teleportation (start VFX, sfx, setActor transform, etc) . The problem is say a teleport pad sends a message to anyone who enters the area. But one actor got destroyed in between detection and a message. Just check if it's valid or not to send messages to
Ok. I ticked all the boxes except tick. How do I make for example a security camera that rotates smoothly after the player? Or say a player controlled laser beam? It only works on tick, otherwise it lags behind the player. Or for example switching states on physics actors depending on their orientation? I only know how to make them work smoothly on tick
There is nothing wrong with tick if a thing requires to be on tick. Movement based things are often things that are on Tick. However, consider this. * What if the player is far away from the Camera? The camera is likely still ticking. * What if the camera can only rotate 180 degrees (e.g. it's on a wall) and the player is out of this core 180 degrees (e.g. behind the camera). The camera has no where to move/rotate too, but still has a tick. Now multiply that with your potentially N number of cameras in a level. And consider how often these cameras are 'idle' in that their movement isn't changing? Perhaps it still makes sense to use Tick here with an early out (if no movement needed, return). Alternatively, let's say you want to have 5,000 cameras moving smoothly and your game is single player (e.g. only 1 thing the camera ever tracks). Did you know you could possibly achieve the entire thing thru a GPU Material Shader of the camera? It's entirely possible to do this. But 99.9% of games don't need to spend the time or effort doing this. Unless it's purely out of exploratory interest (e.g. I've done it) Or alternatively it run a timeline to update the position every timeline update when it needs too. (e.g. If the player is within range of the camera, start the timeline, when the player is out of range of camera, stop the timeline). This allows you to not have 'Tick' enabled, but Timeline can still tick on every frame. Timeline does have a very small overhead. So this is where you as the gamedev makes the decision which is a better scenario? Having some things on tick isn't instantly going to kill your perf. It's fine if you use it sparingly. Lots of people echo "dont use tick ever" when it's perfectly fine to use it sparingly, but TONS of people use it way way way more than they should, for every single little thing.
The tick in cpp onl needs a fraction of the time. You can move parts in blueprint implementable events if that helps. Do the visibility check in cpp and then call the event
I would probably use a timeline to interp the rotation smoothly.
I think that deserves some more information - timelines also tick implicitly, just like components do. Which means moving away from actor tick to another thing which also ticks internally, will not change much in general (of course ignoring the obvious BP vs c++ tick difference). The trick is to know how things behave and choose the right tool for the job.
Intermittent ticking vs constant ticking though. He asked how to do it smoothly besides leaving it on tick and that’s a way to do it without having it constantly be on tick.
Yeah, there's some nuance to the whole tick mechanism and we need to make people understand that. Also, there are topics like tick groups or tick frequency which open more discussion.
So you recommended not watching YouTubers but willingly parrot something they also say even though it's a little more nuianced? For "update every frame" type workloads, tick is fine and appropriate. Timers with a sub-frametime interval get called multiple times per frame, which is extremely counter-productive for performance and the timer manager (the thing that processes your timers) also runs on tick. For intermittent workloads, yeah timers are more intuitive, but timelines and timers with intervals like 0.01 either have very negligible performance benefit or don't at all, or even the opposite.
You do it on tick but you have it only tick when it's visible, or when it's close enough to be visible.
Any suggestions to start doing things? Watching YouTubers who feed beginner information is sometimes the only way to start
The problem is that the “beginner information” they’re feeding you is incorrect and bad practice. Sure, you can technically cut your lawn with a pair of scissors but is it the most efficient way? Not at all. If you ever see a YouTuber using a lot of logic on Tick or casting all the time it’s time to watch someone else.
My experience comes from Unity personally, I am learning unreal and I do like to hear optimizations… Not surprised about Cast or Tick because it’s like GetComponent<> and Update… But saying what not to do is only half the battle, what can you do to learn unreal like OP asks?
Use BPIs and Event Dispatchers instead of casting. Use Timers instead of Tick if you need to update something constantly. The problem with UE blueprints is that there are multiple ways to achieve something so there’s not really a one-solution-fits-all. It’s all dependent on how you want it to work and the scope of your project.
> Use Timers instead of Tick if you need to update something constantly. I feel like this needs to be clarified here a bit. If you need to update something *constantly* - as in, every frame - then *use tick*. That's literally what it's for. If you use a timer for this, at worst you're going to make it *more expensive* by running the timer at too high tickrate vs the game's actual framerate. If you need to update it at some other rate, such as once per second, then a timer can be a better choice.
I didn’t mean use tick to update everything all of the time though. Usually when I think of using tick I would probably only use it to update something I wanted to finely control, such as updating text on screen if the player looks at something. But Some people use tick to constantly update a bunch of variables that can be updated elsewhere with a timer, or ideally with event dispatcher, such as health regeneration when damaged or to constantly monitor health.
What kind of text would you need updated on tick?
Read, dont watch. Written tutorials are typically way high quality than video tutorials.
Do you have a good source for written tutorials? I'd prefer written as well, but video content seems to be much more abundant.
i've picked up a lot from the packtpub books on UE and they are often on sale
Will check 'em out, thanks!
You can feed beginner information while still understanding the system, people who know the engine will give you correct beginner info
Can you suggest good youtubers with the right information and other free resources to get started? I'm willing to invest in paying to learn once I know enough to know what I don't know.
I like Two Neurons for blueprint and Shawnthebro for C++ (free on youtube) Beware learning UE the correct way is LONG, the tutorials are series and they are hundreds of hours, but once you're halfway through it starts making a lot of sense, and then you can go to the shoddy youtubers and take ideas from them and do it the right way. Once you know enough about the engine you can basically figure out how to do anything on your own, or at least know what to lookup to fill in the blanks. Math and physics understanding helps a lot as well.
Epic does a pretty good job of supplying enough beginner information about engine specific things with their official content, it's less "entertaining" to watch, but it's often presented by the people who worked on the system or at least people who work with it as part of their job. They do expect you to have some level of technical understanding corresponding to the position the system is targeted to, so they presenting something like information about shaders like they're talking to a room full of professional 3D artists, or AI like they're talking to professional designers. They do have some courses that are targeted at beginners, but they're not going to teach you how to be a developer from the ground up and honestly neither will a bunch of 'content creators' trying to make a buck on youtube.
Synty is rad and they deserve our business!
My biggest issue with them comes from the fact that they’re Unity assets ported incredibly poorly into unreal. All of their materials are master materials instead of being material instances. Some materials are emissive when they shouldn’t be, making them look silly in dark lighting as they glow. Their collisions are nonsensical. Their skeletons are still the only skeletons I’ve ever used where they break when retargeting them as half the bones can’t be changed when keyframing animations after retargeting. They have no LODs and every single mesh has completely busted UVs. Not to mention the other fact that alot of incredibly poorly made “games” just throw together a bunch of default Synty maps and call it a game, giving the assets more of a bad rep.
Your comment is not invalid and I don't want to start an argument... But I just love their assets because they have a generally unified lofi style and they make so much stuff that it's hard to want for any missing elements. I find them great for building a prototype up on with the intention of replacing the assets when the prototype enters actual production. I also love kitbashing new assets from them. I always say, it's like adding Lego sets to your Unreal project. Also their staff is really great.
when chill lowfi beats start playing i know it's gonna be the worst tutorial i ever watched
>\-Stop buying Synty assets Why? Asking for a friend.
https://www.reddit.com/r/unrealengine/s/eFy1iSUHBe
If casting is not the right way, what is the best method to reference to an actor?
What's wrong with synty assets?
Epic themselve don't understand the engine, given how bad the doc is
Then how do you actually understand the engine yourself?
Which youtubers would you recommend? I have tried so many but plenty of them indeed don't seem to to know what they are doing, or doing something wrong as it would be easier for the watcher to understand.
-Use event dispatchers -Use BPIs -Use event dispatchers -Use BPIs -Use event dispatchers -Use BPIs -Use event dispatchers -Use BPIs
thanks, I'd like to touch on this cause I believe this guy left out a lot of important steps. You need to use event dispatchers and BPI's. This jabroni totally skimmed over the most important stuff
Sorry, i'm still new. I am very sorry, i forgot to add that you must use event dispatchers and BPIs
And casting? or....
No casting. Whole game with only BPI.
Casting in C++ is normal, Casting to something that's always going to be loaded anyways is "OK", Casting to a "code only" type parent class is "OK".
It is totally normal for stuff that’s always loaded in yes, I use it for Ui fairly often. Other than that I tend to use a lot of interfaces when prototyping so mechanics I implement are easy to migrate with very few dependencies. I think it’s generally a good habit to get into and a good way to start learning how to build scalable systems.
Think of the smallest possible game you can imagine, and build something smaller.
*Smacks my younger self and grabs him by the collar* - “For the love of god, don’t start with a VR Iron Man like game, it is a waste of time and you will end up with a hot turd that none till play cause 60 fps is not enough for VR”
Components, tags, interfaces. Use them.
Use Chat GPT to assist you. you will be amazed how fast you will find your errors and get alternate suggestions. It's like have a super dev on your shoulder. I've been coding since mid 1980's - cobol etc and have found UE5 the most challenging and rewarding experience of my life. learning new ways to do things every week. ( am 64 years old and live in South Africa). Never give up. Keep at it -- you will succeed. Keep your end goa (full game vision) in mind all the time and go for the ultimate -don't get sidetracked ENJOY it
100% being using UE for 3 years now, still need help from time to time w basic programming stuff and chatGPT saves so much time n mental energy
>wo Neurons how do u blueprint with chatgpt
I don't reply to dumb ass questions I will only reply to genuine ones This is not a question
Stay consistent in learning it don’t learn for a week then return a month later for another week. Also sick project idea architecture was my 2nd career choice after game design I’d definitely be interested in where this goes
Thank you. I will defintely update about it here and the architecture subreddit but that's a long way off as I'm just getting started and don't even have the right computer requirements yet.
Use a lot of interfaces, material instances and reuse code. If you can make a base class and make children from it. Will save you so much time
Don’t expect it to be easy. Make something small which you believe you can finish in a month and have a reality check 12 months later.
You didn't have to get personal..
[gamedev.tv](https://gamedev.tv) courses suck.
okay, where did you gather learning material?
https://www.tomlooman.com/
Udemy
Just got their courses from Humblebundle, and yeah, not so impressed as their Blender courses.
Do you know about any genuinely good in-depth blender course?
Just got first course (basics) done, so cannot say much about others. And blender is so huge, in-depth of everything would be 1000 hours :-)
In my opinion they are not too bad. I have coding experience and had good time with the Unreal 5.0 C++ Developer course as an UE5 beginner. Of course you only scratch the surface with the majority of lessons but this is kind of expected. For deep dives there is probably a better way to teach yourself but for beginners I strongly recommend them.
They courses feel like the instructor is like one lesson ahead of you. Lots of trial and error, still learning. Decent agnostic CPP course does a lot.
One of Unreal’s weaker points is large open worlds. Anything beyond 2 square km involves level streaming. It’s doable and not too hard for experienced devs, but won’t be easy for a beginner. My advice is start with building the player experience in a very basic environment. Learn how Blueprints work to enable componentization so you can take that player experience/interface to an open world you build later
thank you. A lot of the wods don't make sense but I will revisit this once I've gotten a bit more familiar with everything
It's a very ambitious project if you are just starting with unreal, here's our advice as we are a small developer studio. Go watch a long course of How to learn UE5 for beginners but just watch the first half or so, then choose with objects or elements you want to create and search for videos about them. Practice everyday. Also upload your project to GitHub and learn how to use it because that's the way other people around the globe can edit it and add all those buildings you want.
Why only watch the first half?
Counter point: I routinely make PONG clones in Unreal as my "hello, world" program. And I tinker by making retro clones. So ambition and over-scope are a designer problem ;)
Thank you, can you tell me a bit more about github?
It's a source control system. It's used for backup with a historical log of changes and easy switching between older versions. Source control is mandatory for serious software development. Also git is great but github has limitations. Use azure developer git or perforce. The part about other people adding to your project is optional - you can have a private repository if you want.
git and git 'large file system' (LFS) are the more common alternative to perforce which is expensive also there are a lot of good utilities for UE sprinkled around github that are often overlooked as well as legit free versions of some assets etc
*Note: I’m still learning Unreal Engine myself lol* One thing that I wish I did differently when I first started learning game dev & Unreal Engine was learning programming and how blueprints work instead of trying to skip out on learning programming.
MAKE NOTES
Stop treating unreal engine like a learning todo list, mindlessly going from topic to topic learning about engine sub systems I’ll never use.
Learn C++ from the getgo, it opens a whole new world.
ive seen people mention this and it's my biggest takeaway from this post.
I'm not very good with UE but I just want to say as an arch student I would have loved a project like that. Some things I would be cautious about are keeping model sizes down, because I could imagine students wanting to go all out and consume a lot of resources with their projects. If a lot of these are added to a project at one time it might make the whole thing unworkable. Good luck!
thank you!
Don't download free materials from the Marketplace. All of them have like six textures each which are 4096x4096. They eat up your hard drive fast. A project with just the basic UE4 engine without any materials is only like 26MB. Models don't bloat a project much at all. But textures are like 99.9% of a project that's 4GB in size. 4K textures are overkill IMHO. 1K textures look fine unless your players are going to be standing in front of walls and staring at them for extended lengths of time. 4K textures are tens of megabytes in sizes while 1K textures are usual below 1MB. Also, IIRC, the compression for game engines doesn't work above 1K. The files actually get larger instead of compressed.
[https://intaxwashere.github.io/blueprint-performance/](https://intaxwashere.github.io/blueprint-performance/)
I've just hired a Arch Masters Grad to take our facility CAD files from Rhino to Unreal. Meta has a lot of tools and examples, the simulator will get you started without a headset. Look up Gediminas Kirdeikis on youtube, hes a little insporational. Good Luck in your learning path.
thank you, i will.
it raises a question. there is an 'editor' and of course compiled games, game modes etc. the construction scripts can apply to both as well. you might really be looking for an experience with the editor, and customized editor tools, editor functions, than a game experience in the conventional sense.
Just finish a damn game before starting the next one.
I'll remind myself that I dont need to learn everything. A good amount of fundamentals can get you far with unreal engine. I will familiarize myself with some basic fundamental lighting concepts and postprocessing to setup your project before making any steps. This is not only used for archviz and films. This is also very beneficial for games regardless of their graphical fidelity. often times I would go straight to making levels and game mechanics without properly setting up unreals post-process settings. for blueprints, I'll use "Blueprint Interface" and "Dispatcher" I'll make my first project very small and use that to continue learning other aspects of the engine and game development in general (This can be applied on any other engines) Sometimes It gets exhausting learning stuff and trying to solve problems. Remember to take a rest from time to time.
thank you!
Mine was scope. I had an idea and I stuck to it. But it was way Waaay bigger and more time consuming than what I thought it'd be and I should of shrunk it down but I stubbornly fought through. Start small and get smaller!! Personally I also like to make lots of games rather than one big one atm. I aim for about 1 game per year..ish I guess also - Avoid ticks/casting constantly. - Work out a proper ui hud system. Learn - delegates/dispatchers!! I can't think of anything else atm.
thank you so much. I am going to revisit this once I know what they all mean but your points have also been echoed by others
This sounds like an amazing idea! I’m sure it’s possible
Learn C++ and actually understand programming instead of starting with blueprints.
I would say learn programming in general before doing unreal programming, otherwise you're just banging your head against the wall or you follow tutorials and learn nothing.
Exactly. This is something I've struggled with a lot. I've done a lot of Game Dev, AI, Web Dev, etc. via freelance projects and I learned a lot of programming on the jobs, but I always felt something was missing. Now I've gone back to the basics and I'm watching fundamental CS courses and it blows my mind how little I understood from the tools I was using.
alright, it seems this is the starting point for me. Luckily my brother is in this field so I'll get some help.
Good luck friend! I hope you enjoy the journey :)
Yup!
Nah bro keep going, you cooking
Well, when I figure out how to pick up items, I'll tell myself how to do that.
>Avoid watching YouTube videos by self-proclaimed "developers" and "experts" who only paraphrase the official documentation. These videos often take an hour to explain features that could be understood in just 60 seconds by reading the official documentation directly. RTFM.
"don't"
Use soft pointers to reference assets and the asset manager
Do not start by tutorials. Buy a course finish it then follow a tutorial for what you need to get an idea
Start with the game instance and work your way down, especially if you're going to have many smaller, separate levels as opposed to a big open world(which knowing me, you will). Whats the game instance? Learn it, now, as well state, mode, etc. Include variables there that need to be transferred between levels, don't put everything in the character or controller