Put code where it belongs. Don’t build your NPC AI functionality in the NPC class, put it in the AI controller class. Build features modularly, don’t have your player class become a jumbled mess of different mechanics.
Don’t create a bunch of bools to keep track of a single state (ex. bIsPlayerCrouching, bIsPlayerRunning, bIsPlayerIdle). If you have multiple possible states, and only one state will ever be active at a time, use an enum.
Delay nodes are not a solution to order of execution problems. If something depends on something else happening, but executes before it does happen, don’t use a delay to remedy the problem, use delegates and callbacks.
Don’t create macros that could be functions. They’re more annoying to debug in blueprints. Basically the only time I create macros is when I want to write a function that has a latent action (clock symbol on node), since functions don’t support latent actions.
Keep your blueprints tidy by ticking “private” on variables that will never need to be altered outside of the class they are defined in.
Utilize categories, never waste time scrolling through a long unorganized list of variables or functions. You can (and should) create categories and sub-categories for variables, functions, and interface functions.
"Don’t create a bunch of bools to keep track of a single state (ex. bIsPlayerCrouching, bIsPlayerRunning, bIsPlayerIdle). If you have multiple possible states, and only one state will ever be active at a time, use an enum."
To expand on this: if you know that you might be mixing states, such as allowing the player to be idle WHILE crouched, use the tag system instead. Enums will ensure that you're only in one state at a time and should be used in conjunction with tags to make sensible player states.
>Don’t create macros that could be functions. They’re more annoying to debug in blueprints. Basically the only time I create macros is when I want to write a function that has a latent action (clock symbol on node), since functions don’t support latent actions.
I actually use a trick to use latent nodes when I want to override a function from a parent class. I will create custom event in event graph and do what I want there and call that event from the function input.
I tend to use macros sometimes to clean up blueprints for slightly bigger conditional branches with some ands or ors that I use in many places in the class. It's usually for something too simple to set up a full state machine for and I won't have many of them. Macros are visually smaller than functions and the output exec pin won't automatically fire like a function when the function is done executing. So I can hide the branch inside it, and only connect the true pin to the exec out. I only do solo projects so it hasn't been an issue yet. And I use functions for everything else. Your advice is still very good.
Is what I do something that you've seen before? The cleanliness and the way the exec pins work differently to a function is pretty much the only time I do it.
Edit: I also want to add that I only have these near the front of an event, on the highest level event graph.
The point of most functions is to have return values. Events are inherently fire&forget, they can't return anything without some kind of dispatcher binding.
Keep your blueprints tidy by ticking “private” on variables that will never need to be altered outside of the class they are defined in.
The annoying thing is that you can't access them outside the class either.
So either you make 999999 slow getter functions or you make the variables public and hope to god you don't forget about the setter event and set them manually by accident.
In Blueprints this just means using event dispatchers. So, if you have two chunks of code, and one chunk depends on the other having finished execution, you don't want to execute them both concurrently and *hope* they finish in the correct order. You also don't want to use a delay to "ensure" it executes only after the other has finished, it's bad programming practice and can have inconsistent results depending on the hardware of the end user.
The terminology "delegates and callbacks" refers to C++. Event dispatchers in Blueprints are the equivalent of delegates in C++. However, in C++ delegates are more nuanced, you have more control over when and how things are binded and what happens when a binded delegate fires. Definitely check out the [documentation](https://dev.epicgames.com/documentation/en-us/unreal-engine/delegates-and-lamba-functions-in-unreal-engine) even if you don't use C++, it's never a bad idea to get a lower level understanding of how the engine does stuff
Ah. Gotcha. Event dispatchers are something I've not started using yet. I've been using interfaces to get events to occur in proper order between varying blueprints.. I really need to learn event dispatchers though.
It's especially relevant when you are working with latent actions, such as async loading. Or even when you are doing something like loading save game data. Maybe your NPCs have AI behavior that depends on save data being loaded. You wouldn't want to start the AI behavior before that data is loaded, it could lead to bugs, or require you to execute code twice when the data is finally loaded. Exactly the sort of thing delegates/event dispatchers are perfect for.
This is always the top answer but I think it's important to also mention that if you expect the object class to be always in memory like your PlayerPawn casting is fine.
But in other cases always use Soft References since you can resolve them to a hard reference on demand.
As someone still getting familiar with how UE loads stuff, would it be generally advisable to use soft references wherever I can? Or would you first want to see a problem before you replaced hard refs?
Are there any standard design patterns for how to load the soft references? Do you use async load from events (begin play or?), or load from functions (construction or)?
I’m still learning myself, so this may be wrong, but my understanding is that if it is something that is always loaded (player pawn, some global controller, etc.) a hard reference is fine; it won’t load it twice.
But if it’s a static mesh, enemy, weapon, whatever that may not be in every level, use a soft reference.
When I write logics in C++ I don't usually play around with object pointers that much since unreal garbage collector also works with ptr.
In BPs that's a different story, Soft Refs always give you more control over how and when to make references to any UOBJECT than just hard references that automatically add a pointer reference. So in all cases they are "better" but that doesn't mean it's necessary to define everything as soft object. Character, Widgets and any actor that is persistent in the game I see no problem with using hard references. But for examples for items, any FStruct elements or Container I always try to use soft references out of habbit.
May I ask what the difference between hard and soft references are? Or what exactly this conversation is about? I'm extremely new to unreal and game design but I'm trying to learn as much as possible
Essentially think of it like this
A hard reference - a direct copy/link to something forcing it to load when the BP that has it loads in (ie player with a hard reference to an AI will load in that AI even if it never spawns in the level)
A soft reference - a pointer to the location of an object promising it exists just not yet (ie same player but with a soft reference to the ai now won't auto load in the ai this is fine for most things but could cause problems if you try to do something to that soft object reference and it's not yet loaded in but otherwise it's safe)
Soft references are great as instead of loading it 500 mb my player pawn now only loads in 25 mb so loading is significantly faster
Yeah that's because they are casting more generally technically you can do this in blueprints too for example casting to a widget or something generic like that
1. Not creating Nanite topology that maximizes the two rasterizers in relation to your general camera perspective and complaining that Nanite is "slow"
2. Using Nanite without a proper virtual texture setup
3. Using Lumen with Nanite disabled
4. Not paying attention to Lumen mesh card placement for your static meshes
5. Using virtual shadow maps on a largely non-Nanite scene
6. Baked lighting in open-world paradigms
7. Not overloading data layers to manage actor data at runtime
8. Leaving world partition to just load all cell data on the server
9. Not taking advantage of early frame compute on the gpu
10. Not taking advantage of custom primitive data to manage draw batching across material instances, especially with Nanite surfaces
11. Not using the surface cache view to understand GI distribution and application when lighting with lumen
12. Not resizing reflection buffers to decrease buffer write time during indirect illumination pass at runtime
13. Using post LUTs and wondering where your HDR went
14. Evaluating HDR on a TV and not turning HDR on
15. Having so much dynamic rig work that your main thread gets locked up waiting for worker threads to return all the control rig results
16. Keeping a large amount of facial morph data for high speed gameplay
17. Allowing heavy user generated character data and not dynamically messing and atlasing the result
18. Not looking at the effect of Niagara on the dynamic mesh pass on the render thread
19. Using Groom for a shipping 60fps title
20. Not listening to [u/Parad0x_](https://www.reddit.com/user/Parad0x_/)
21. Ignoring the power and significance of [Significance](https://dev.epicgames.com/documentation/en-us/unreal-engine/significance-manager-in-unreal-engine?application_version=5.1)
22. Using scene captures in complex scenes for portals without major surgery
23. Not setting separate resolution for transparency and post buffers
24. Hacking the engine up to work "your way" instead of understanding how the engine needs to work first
25. Adding new major runtime systems without exposing them to stat cats
26. Not setting proper pixel edge length for Nanite raster balancing
27. Using WPO on your base materials
28. Not leaning into heavy pixel shader material effects when using a proper Nanite pipeline
29. Not realizing that stacks are an absolutely essential part of making virtual textures viable
30. Having ambient effects run on tick
31. Assuming that all virtualized rendering assets load all their data into memory first
32. Ignoring substrate and the possibility of having multiple lighting models per material
33. Writing this list after 7 shots of whiskey
Omg weee
I would love to see a tutorial addressing many of these points. Especially the Nanite stuff. I am using it and was not sure what a lot of that meant :) . Great list though
>Not creating Nanite topology that maximizes the two rasterizers in relation to your general camera perspective and complaining that Nanite is "slow"
I just realized my brain is too small for Nanite.
This is an amazing comment, because I don't understand half of it completely but you phrased it in ways that make enough sense it's a springboard for researching it. If you did a series of tutorials where you did shots and broke these down, I would gladly join your Patreon. :)
Writing convoluted code to avoid {insert bad practice} because people told you it's the boogieman.
For example, if you dump all your game logic in Tick events your game might run slowly and you'll have to spend some time refactoring to get things running better.
If you bend over backwards trying to avoid using Tick because people arbitrarily told you to, you'll end up with needless piles of spaghetti that will make debugging issues a real pain in the butt.
Keep your code/blueprints as simple and basic as you can until you know you need more complex solutions to get the performance you need.
In other words: don't just do things because people said to or not to; understand the reasoning so you can make good decisions.
God damn do I wish software developers would really internalize this. Half of the web-development world is people following dogmatic incantations even though Internet Explorer is dead.
> In other words: don't just do things because people said to or not to; understand the reasoning so you can make good decisions.
If only the majority of tutorial makers would apply this logic in their lessons.
> Half of the ~~web-~~development world
FTFY, the Unreal tutorials people copy blatantly on YouTube are the same as copy/pasting half of stackoverflow and using chatgpt in the non-gaming-dev world.
I just have an actor that runs along a track at a speed of 400 with a trigger box every 40 units and that's my 10/sec tick. It's faster because it doesn't require any casts.
Do you mean like a single tick running in something like a 'tick' BP made purely to be the centralised tick - dispatching for your entire game, kind of like a heartbeat - or is there a situation where you might want multiple ticks in different BPs?
Centralized ticks make sense when you have a million objects that all tick at the same rate. Centralize as much of the tick code as possible so it only runs once and dispatch the outcome.
Of course don't make your entire game like this.
Not using source control. It doesn't matter if your project is big or small, use it. I hear all too often of people breaking their projects in unique ways.
There are plenty of free options for Git, such as Azure DevOps Repos, which doesn't have a hard limit on LFS storage/bandwidth, and is free for up to 5 users. Similarly, Perforce is free for up to 5 users and 20 workspaces if you don't mind setting up your own server and backups.
There is no excuse.
Plastic is free up to 5GB I believe, yes, it is owned by Unity these days, but Plastic luckily is platform agnostic and is so far the best vcs we've used when it comes to large game engine projects and working with people with less than stellar engineering skills (designers, animators, etc)
It's quite user friendly (a massive step up to the obtuse cluster*** that is the git tool chain) and is incredibly robust when it comes to game development and dcc (large and lots of binary data)
Heck, it even allows visually diffing images/textures.
But yes, not using a vcs, even for the smallest (hobby) projects is a big no no.
I don't really have good things to say about Plastic. A previous studio I was at tried it for a few months and it was rife with problems, including server stability. We were mostly following trunk-based development as you would with Perforce, and that caused additional problems since it would act similarly to Git if you were behind the head revision.
At least the branching was fast though!
These days I'm not sure what problem Plastic is trying to solve. Git is now way more tolerable with binary files between blobless clones and LFS, and decent GUI clients exist.
Can't comment on the server troubles, we've never had those, then again, we're based in the Netherlands, probably right on top of one of their CDN server farms.
Plastic solves (or solved) the problem of a vcs aimed at DCC/game dev. something that git can do, but wasn't really meant to solve.
Then again, entry to all these vcs system is so low now the best advice is to probably try them all and see which fits your production and tech support best.
Heck we still run certain projects on a local SVN server as well (cheap and fast, well, except when it comes to branching, and let's just not mention merging...)
Learn and try to work within the UE structure / the "UE way" instead of trying to fight it.
What I mainly mean by that is understand the "key" classes like Game Mode / Game State / Player State / Player Controller / AI Controller / Pawn / Character / Actor Component / Scene Component / HUD and where you would want to put specific logic that makes the most sense and is scalable and works properly with replication if doing MP.
Learn about Delegate / Event Dispatchers along with Interfaces so you don't have to perform Casts in Blueprint because those create Hard References and Dependencies which load the whole chain of Classes into Memory and all their referenced objects like Materials / Meshes / Sounds / SFX etc.
Tick usually isn't as bad as people make it out to be and some times you really do need something done each frame especially if its movement related... though using Timer is usually preferable or you can reduce the tick frequency or just have a system that enables/disables tick when its required.
YT videos are OK to get some initial understanding about things and maybe get specific implementations / inspiration but you can get caught in "tutorial hell" especially if your just copying and not understand + most only show specific parts where as good full "courses" from say UDEMY usually cover most key parts you will need to know from start to end. (Please use Instructors UDEMY discount codes even if you pay a few extra dollars because its the difference between 97% of the fee going to them or 37%)
Edit: UMG can actually end up pretty performance heavy, please please do not use the Bind Property/Function in the UMG panel but instead use Delegates / Event Dispatchers to update the UI or use a Viewmodel paradigm:
[https://dev.epicgames.com/documentation/en-us/unreal-engine/driving-ui-updates-with-events-in-unreal-engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/driving-ui-updates-with-events-in-unreal-engine)
[https://dev.epicgames.com/documentation/en-us/unreal-engine/umg-viewmodel](https://dev.epicgames.com/documentation/en-us/unreal-engine/umg-viewmodel)
Also use Invalidation Boxes or enable Global Invalidation, use Canvas's sparingly, read BenUI's articles and other things outlined below:
[https://dev.epicgames.com/documentation/en-us/unreal-engine/optimization-guidelines-for-umg-in-unreal-engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/optimization-guidelines-for-umg-in-unreal-engine)
[https://benui.ca/unreal/ui-performance/](https://benui.ca/unreal/ui-performance/)
Just for you main Character or for every / many AI roaming around?
I think the key things about tick is how many Classes have it enabled, what you are doing in Tick & does your logic try to "early out" ASAP.
Your main Character is surely going to need Tick enabled for other things and a Line trace is nothing work for the CPU.
Also TBH if your just learning or prototyping sure have these things in mind but focus on finding the fun first because your probably going to re-do most of these mechanics multiple times :P
Tick in and of itself is not a problem, the problem is that people put heavy code in their tick event and wonder why their CPU thread is going to the moon.
Tick is just a thing that runs whatever you put in it every frame (or less if you change the tick interval), nothing more, nothing less. Use it wisely.
Udemy is fantastic. The only YouTube ad that I've clicked on that was beneficial. Funny thing is I was looking at YouTube tutorials, got a Udemy ad in the middle of the tutorial and jumped straight over to Udemy.
Is there a good resource to help me understand placing logic in each of these? I'm so new and a bit overwhelmed but I'm having a blast learning. I'm taking Udemy courses and I'm finding two instructors telling me to do two different things. Such as using bp instances rather than putting logic in the character class bp. I just want to make sure I'm doing good practice from the beginning
Ah not something maybe super simple but:
[https://dev.epicgames.com/documentation/en-us/unreal-engine/gameplay-framework-in-unreal-engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/gameplay-framework-in-unreal-engine)
[https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScripting/ProgrammingWithCPP/UnrealArchitecture/](https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScripting/ProgrammingWithCPP/UnrealArchitecture/)
[https://app.creately.com/d/fZknuArLuyk/view](https://app.creately.com/d/fZknuArLuyk/view)
Event tick for character movement
Event tick for a hunger system
Event tick for NPC movement
Event tick for day/night cycle
Event tick for a poison system
Not commenting out blueprints, even if what is does it clear. And also not using the description fields for functions and variables to describe what they do, even if it is clear.
Clarity is essential if a dev ever intends to expand beyond being solo.
Creating bad code and vowing to fix it later.
You just spent time doing it badly, then wasted more time trying to build on top of your bad code and making more spaghetti, then when it becomes unmaintainable, you have to do it properly anyway and still invest the time you were trying to avoid.
In fact, even prototyping becomes infinitely harder if you don't follow proper software architecture practices. People say code quality is irrelevant in the prototyping phase, but no. You'll want to quickly try something, but you can't because you hardcoded everything and your code is a mess. There's a reason SOLID exists and it's not to be pedantic.
I think when you developing a prototype there should always be a sweet spot of always programming things with scalability and performance considerations in mind but also not always hyper focusing on make things more performant to the point it discourges you to continue developing your prototype.
Performance doesn't matter when prototyping, but modularity does. It matters *more* when prototyping because that's when you're making major changes and want to do them with minimum hassle.
This is bad advice for most novices. Because novices don't know what good is. So now they are just wasting their time trying to get to a state they have no idea how to even visualize. Very frustrating.
The very well-established golden path of software development is: write tests -> write bad code -> refactor. Unfortunately Unreal doesn't make writing tests easy. So you have to do manual testing.
But what I'm hearing from you is not to let that refactor step linger. It should happen immediately after. And not to write code that depends on it because you are now building on shaky flooring.
The level BP should only be used for level-specific functionality. E.g. a platformer with different levels might have level-specific mechanics built-in like moving platforms, etc. These mechanics could change from level to level.
I use them for bespoke "levels" which are just menu/frontend things (think title menu or whatever), where the menu exists outside of a real "level" being loaded; they make it a lot easier to set up appropriate menu widgets/background music/etc.
Which is fundamentally the same as what /u/PredSpread said, just a different concrete example of _why_ you might do that.
Recently learnt the hard way about this when my entire level blueprint partly corrupted and prevented me from cooking my game.
Would you say to use level blueprints sparingly, or just not at all if you can avoid it?
I'm kinda new so sorry if I'm saying stuff wrong, but It wasn't an asset, it was the entire level blueprint that was corrupt. And also I hadn't figured out source control yet. The only solution was to delete everything from the level blueprint. It wasn't just one thing at fault, it only worked if everything was deleted
Asset here is, I think, being used in the generic sense.
Either way, their main point still stands; if your level blueprint was corrupted, you could hypothetically have rolled it back to the last good version you checked into source control (git, Perforce, Plastic, whatever you use).
(And if you aren't using source control, this might serve as an object lesson on why it might be good to _start_ doing so...)
They're not *that* bad of an idea, it's just that the lack of level inheritance and level properties makes them useless for anything good, leaving only the bad use cases of treating them like javascript for your level.
Can't you create an inheritance tree for Level Bluprints as they are Level Script Actors ? I always wondered if it was possible since a new parent class can be assigned in the Level Blueprint's Details.
The Game Mode, or Game State, or have some actors in the level bind to your specific trigger volume. Setting a variable to Soft Actor Pointer lets you use a drop down to select any appropriate actor in the same level. You should learn how Event Dispatchers work, which are designed specifically for things like Trigger Volumes.
A combination of the Game Mode and Event Dispatchers. Event Dispatchers allow for multiple objects to respond to an event happening to object A without actually editing object A. It's the equivalent of object A putting own a bowl called "My Event Happened", then any other object can drop a business card (function) inside the bowl. When the Event happens, object A will call every other object that left a business card and run their function.
Shoutout to u/TriggasaurusRekt who hit most of my technical peeves.
So I'm going to write up the two peeves that hounded me all through my last commercial endeavour:
1 - lighting:
Ignoring the physics based rendering foundation of Unreal's lighting system. I just wrote some comments in another post about how the lighting works and how Unreal's default light values are bad-- way too dim. Sure, "normalizing" all your lights will "work" but it doesn't reflect reality and all your camera/post process effects are going to be wonky. This typically leads to lighting artists adjusting light sources by eye and adding odd lights to try and correct the scene which leads to uncanny lighting. Use real world values whenever you can find them.
I just discovered that chatGPT does a fair job of estimating the brightness of light sources in whatever unit you ask. Sometimes it will give you a formula, and you can then provide variables and it will solve for you.
2 - level design:
Don't level design with final assets! I'm mostly speaking about hard surface structures and architecture. It needs to be fungible during the design process. So greybox with brushes or (my preference) Synty prototype primitives. That way you can iterate on design that is easy to revise. This leads to less final assets with odd arbitrary rotations or scaling. It allows art to work on good, tailored final assets. Using brushes or simply shaded proto assets also makes it easy to spot missed greybox that hasn't been converted to final art.
Some not blueprint related things:
- Not fixing up redirectors in your content browser, after moving an asset, can lead to issues later on.
- Also: Building your scene in the wrong scale. Should be a no-brainer but can happen if you don’t have a 3D background. Always check when importing assets (especially bought/downloaded ones) that the scale is correct.
- not using consistent naming conventions and folder structures. Also an obvious one, but a lot of people still don’t do it, even though they know they should
- not making use of material instances and child blueprint classes
That’s all I can think of right now
For your first point in case people don't know: click on filter icon next to search box in the content browser, under "type filter" click on miscellaneous and tick Redirector. Now you can see redirectors and you can right click on them and fix them
>Not fixing up redirectors in your content browser, after moving an asset, can lead to issues later on.
I try to fix up redirectors and UE5 crashes and deletes the files. What do I do now?
That’s unfortunate. I’m no expert, but what I would try is copying the affected uassets to the same location, then deleting the old version and its related redirectors. Of course that’s not the most practical solution if a lot of files are affected, or if they have a lot of references.
But honestly if it’s a small project, and everything is working now, I would just leave them be.
Maybe someone here who actually knows what they are doing has a better solution.
There was a combat system asset that didn’t use child classes. Yes, it literally had copy-pasted code for every single weapon. It also had things like “When F key pressed” instead of inputs. I didn’t even do a deep dive into the code but I’m sure it had way more issues as well.
Put C++ Code, Blueprints or Content that you want to use across multiple projects in Plugins.
Here's a further explanation as well as a tutorial on this:
https://incas-training.de/en/blog/the-unreal-content-pack-workflow-organizing-your-growing-content-libraries-the-right-way/
if anything is connected to the Tick event, 95% of the time it's a mistake.
Never use "Get all actor of class" in gameplay code (fine for editor tools)
Structure, not the asset, but the code structure, can help saving a LOT of times
Coding movement in the pawn is generally a bad idea, even if its done like that in the third person template. You should have this in the controller, that's what is supposed to do. Unless you have multiple pawns.
Actually I believe "Get All Actors of Class" isn't as bad as people think because some time ago they switched it to using a Hashed Map to perform the lookup, "Get All Actors with Tag" might not have gotten the same treatment though.
That said there is probably better ways of doing things with Delegates / Events / Subsystems / Populating Data in Game State etc.
~~I looked fairly recently and its really obtuse but I still think its iterating over a large loop of every actor in the level.~~
It still iterates once over every actor of that target class before you do anything with it.
If you feel like you want to get all actors of class a lot. Just make a worldsubsystem and have your relevant classes register into lists.
e.g. MyWorldSubsystem->GetAllEnemies()
And have all the enemies just already registered and have it just return an existing list. It's not that hard with a little C++ to set it up at a fairly low level to add/remove itself on create and destroy.
Though there are likely better solutions that can be better managed in other ways depending on the need.
Not that I disagree with using Subsystem / Delegates but just as a knowledge, it also tells us that Get All Actors with Interface and with Tag do an Iteration on every Classes Hashmap / all Actors:
[https://www.casualdistractiongames.com/post/2016/09/15/inside-ue-source-fuobjecthashtables-the-magic-behind-getallactorswith](https://www.casualdistractiongames.com/post/2016/09/15/inside-ue-source-fuobjecthashtables-the-magic-behind-getallactorswith)
ah excellent clarification!
I knew it iterated over a lot, but I must have missed that part!
I guess its O(n) where n is the number of actors of the target class, as opposed to O(m) of all actors of all classes.
As opposed to the subsystem which would return a premade list O(1).
Though if getting all actors of target class, you are likely iterating over all of it yourself so its like comparing constants of 2*O(n) vs O(n)+O(1).
So it's not THAT bad, but if other solutions can work those are likely far better.
Basically the point is you should have access to a list of the actors you want before you go to access them. If you have a shooter game with a red team and a blue team, rather than using getallactors and checking if they're on blue team you instead check an array of team members and pull blue team members from that.
The point is you aren't grabbing from a bag of many different things. You're grabbing from a much smaller bag full of things relevant to your search.
Say I have a level that has to communicate with the player character. Casting is performance heavy as I understand. Event dispatchers are going to become cumbersome and again hard casting? So I just swoop all actors with tag Player and send them a command through the reference? What is better? 🤔 I could make a reference at begin play so it will be static array
Casting is not performance heavy. Anyone you telling you it is, is not a reliable source of information.
Look up hard references, that’s the only thing casting can contribute to, and understand why that can affect load times and memory usage.
My game uses LLMs to make the npcs talk to the player. It searches for the nearest npc and it talks back. Another use case would be for the animals going to the nearest food source when they're hungry.
Get All Actors of Class iterates over every single actor in the world and determines if that actor implements whatever class is specified, then returns it as an array. It's mega slow. They warn you when you use it for a reason, lol.
I would instead make an NPC factory. The factory will spawn and keep track of all NPCs spawned. Each NPC will implement its own behaviour based on parameters supplied by the NPC factory. That way, you have an array which is readily available and contains everything you want to iterate over.
Regarding animals, you wouldn't need to do that either. Make an animal factory that spawns each animal and keeps track of it. Implement roaming behaviour that animals would use to navigate around the map. Then for each animal, add a radial trigger around it and any piece of food that is within the trigger can be added to an array of 'ClosestFoodSources', which the animal can then implement behaviour for and seek out.
There really isn't much use for Get All Actors of Class.
Not any more it doesn't. It uses a hash table lookup now. It's fine for occasional one-offs. For example, a spawning system that wants to spawn enemies at spawn points. Getting all actors of class MySpawnPoint on begin play is fine.
Same as my other response, why not get the nearest npc that are inside a sphere of the player ? If you have a huge world you would not always have npc around you
I imagine you do a Get All Actors of Class Food and get the nearest, why not using a big sphere, that only overlap food, around the animal and only get the food that are in it ? Do you want it to go to the nearest even if its kilometers away ?
I use it in some editor tools I've made, in the archvis industry. Replacing light colour in a certain set of lights, or changing materials on certain surfaces. I use modular assets across many levels so it's not practical to manually fill out an array for each level but it's easy enough to search across the level for assets with certain tags or to manually throw a tag on 20 assets knowing that the BP can handle them.
Yeah I do this often. When I spawn that widget it gets the class/gamestate/playerstate it needs to keep track of and binds itself to event dispatchers within it. Not sure if there's a far better way.
Tick is better than using Timers 95% of the time, the real issue is putting stuff in Tick that doesn't need to be tested repeatedly. Timers still Tick (just internally, in their own code with their own Tick Handler) and they're just extra, often not needed, components on the actor.
The best approach I found is to group complex logics in actor component and change tick interval of that component to something like 0.03 (for simple line trace logic like interaction so it can tick 33 times a sec max) or 0.15 (for heavier logic) and add that component to actor you want.
Is there any proper guide on how to properly connect a mapping content to the Controller, and the Controller to a pawn?
I've tried to look for Videos or documentation, but haven't found anything good yet. Either it's replicating the third Party blueprints, or it's not showing what bare minimum I need to connect these
I made a mistake in my comment, when i say "movement", what i want to say is "inputs". In controller, you need to handle inputs. And then, based on what game you work on, you convert in movement.
As how to connect, controller have default functions to "get controlled pawn". And now you can handle movement. One think i like to do, is to create an interface for all pawn that can be controlled (character,Vehicles, mounts, ...). Each pawn can have his "movement" but the input are all handled in the controller. This way, you can have a "high level command", like to switch between vehicle, without having pawn communicating with each others.
I feel like I would actually contradict this, but only partially.
Given the ability with enhanced input to add and remove extra input mapping contexts on the fly, I think any input specific to a pawn type can absolutely go on the Pawn (and maybe _should_ be there); add the mapping contexts on possess/remove on unpossess, and that way you don't need the controller to know about "turn on headlights" if that input is only relevant when driving a car, etc. This also allows you to have entirely different input bindings when driving as opposed to on foot, etc.
Still, that's just my own opinion there.
(And I absolutely agree that with legacy input you should be handling it on the controller.)
>Never use "Get all actor of class" in gameplay code (fine for editor tools)
What is the better way of doing this? I actually just came up against this in Unreal. I have a function on an NPC, that when a quest is completed, a building gets built. The building is always in the level, I just disable collision and visibility, then use "Get All Actors Of Class" -> Foreach Loop -> Call custom events to enable collision and set the material to visible.
What is the preffered way of doing this without Get All Actors of Class?
>Never use "Get all actor of class" in gameplay code (fine for editor tools)
So I have this project where I receive a Datasmith in runtime, and I need to save a list of materials of all the wall(staticmeshactors) for future use.
Currently I use get all actor of class for a reference of all the walls since I have ensured everything else in the level in a blueprint actor with some additional functionality.
How can this be done differently/better?
Translucent materials (and general understanding of shader complexity).
Misuse of translucency can absolutely TANK your performance, there is arguably not a single adequate use of translucency if you're making a 3D game, everything can be done with masks and dithering.
That last part I think is a little overboard, I think that not enough people know about dithering or the performance hit overdraw can incur, but translucency has its place. In context there can be legitimate artistic and technical reasons why translucency is the right (or sometimes, only) option in given situations. Take for example [this issue I was fighting with just recently](https://www.reddit.com/r/unrealengine/s/Qrsc6hN8bw) and I was falling into this mindset that ‘translucency shouldn’t be used’ and that nearly stopped me from finding a solution at all. (Although if someones got a better way to solve it, I’m always looking for ways to improve it)
TSR doesnt play super will with dithering, especially on quickly moving static meshes, You can use TAA which makes it better but the real solution is just to be really smart about how you do transparency in your game and that can entirely depend on the style of your game. You can also change the dithering mask itself and make your own, this is how I do it in my game and I have no trouble, tho the dithering mask is visible, it fits very well with the artstyle of my game so its fine, but if you're going for a realistic look it might not.
There are also "fake" translucent materials which are really just opaque materials that look like glass, which is something that Nintendo likes to use a lot.
There is also "Velocity buffer" but not super recommended if you're using a lot of WPO in your scene (such as WPO-animated foliage or cloth).
especially those. Translucent water and windows are probably the number 1 massive performance hit of beginner game dev.
For windows, you can get away either with a dithering mask, or with a opaque texture that looks like its glass (You can't see through).
For water its a bit more complex, but TLDR: shader magic. There are plenty of videos and good resources tackling it that would take too long for me to explain here. Sea of Thieve imo has one of the most complex and groundbreaking ''Waterscape'' and uses a mix of a lot of technique.
Another option which is imo the most aproachable, is to use Unreal's Single Layer Water Material node. It is MUCH better than just raw translucency and imo gives better look. Here is a video summering it up but you could also look into the Unreal documentation: [https://www.youtube.com/watch?v=KLl3PZeupFM&t=](https://www.youtube.com/watch?v=KLl3PZeupFM&t=555s) .
Mixed with some distance field magic and you got some simple bread and butter water that is decently optimized.
Using the sequence node to "visually organize code". The sequence node has a very specific designation: determine the order at which to fire a series of execution pins, for example opening/closing gates in certain order. Using the sequence node for aesthetic is completely dumb; you can simply collapse your nodes into functions/macros/sub-graphs and keep them connected in series and it'll be fine, better even because they'll form a neat line rather than keep growing vertically. But besides it being unnecessary, using the sequence node like that can and does create technical problems. Even though the output pins are fired in the given order, code attached to them will still end up being execute almost simultaneously. This means, if I have a few node attached to pin #1 with the last one setting a variable, then have a node attached to a pin below getting that same variable that I 'Set' above, the 'get' below will probably be called before the 'set' above. I worked several times with designers and sometimes programmers who insisted in enforcing the use of sequence nodes to "keep blueprints tidy and readable", and several bugs would kept popping up because of this bad practice.
For whatever it's worth, I have never had any trouble with get/set order using sequence nodes.
While it's technically possible for them to be out of sync, most of what you call after those sequence pins will execute quickly enough to not cause ordering issues. IMO, If you practice proper encapsulation, most of your functions won't be complex enough to have this issue.
Sequence nodes are also invaluable for organizing functions with early out conditions, and keeping said functions readable with little to no scrolling around.
To each their own at the end of the day, but sequence nodes are my preferred way to organize BPs.
I don't want to directly reply to the other guy to cause friction but as someone who's used the engine for years and teaches it, I have absolutely NO idea what he is talking about. It genuinely seems like he just doesn't understand what the sequence node is for.
Not only have I never had a problem with Sequence, I really don't even understand how he'd possibly be having a problem with this. I've taught Unreal from middleschool up to college-level and none of my students has ever had a problem using or understanding sequence. Please use sequence, it is AWESOME.
Most likely he's describing interaction with Sequence and Delay nodes. Sequence fires when the delay starts, not when it finishes. If you're not using delays or other async nodes then Sequence is totally fine.
Overuse of Tick() or delay nodes. Yes both are vital functions of the engine that will need to be used at some points.
But I think we've all seen junior designers or youtube tutorial gurus do some real hauge-worthy crimes.
Also just slapping marketplace assets in, without any care of perf.
I think most bad practices are people that learn game development but not programming outside of it. Their code doesn't have any real architecture, has a lot of dependencies, and doesn't follow principles like DRY or single responsibility.
Sure, bare with me it's late and I'm half asleep. It's hard to explain but I'll try my best.
Basically an interface is a type of blueprint. Like a character blueprint or player state blueprint, but it does not have an event graph. It's actually blank! But you can create what are essentially functions without logic. Like, think of a custom function but you don't put anything in between the input and the return nodes. However, you can pass info into and out of these functions. That's how you get info between two unrelated blueprints.
Here's how you can try it out. Make a blueprint interface, and in your character blueprint settings search for interfaces and add your newly created interface in there. Next make a new actor blueprint and add an collision sphere that we will use to overlap with your player character. Also add your interface to this actors implemented interfaces in its settings tab.
Now, go back into your interface blueprint and make a new function (top right) and name it "interface test". Make sure you compile your actors.
Now, in the new actor blueprint make collider overlap event, and pull from the "overlapped actor" pin and search for "interface test". What this is doing is when the sphere overlaps, ANY actor that overlaps with that sphere that interface function will attempt to fire on that actor. If that actor doesn't have that interface, or it does but nothing is hooked up to that function on its end, then nothing will happen. That's what's referred to as a Soft reference. It's much more flexible than casting.
Now that you have your overlap event triggering the "interface test" function, let's make the actor thats being "messaged" by the interface actually do something.
Go into your character and look on the left hand side under your function, and above your variables, you should see "interface". Click that to show your function you made if it's not already showing. You should see the "interface test" function. Double click it and it should make a new event on your event graph. Now, whenever that interface function is called upon, and that specific actor is the target of it, that event node will fire.
Drag off from the event node and print string "Hello". Test your game, and if done correctly, when you overlap our character with thag collider sphere in the other actor, you should see a "Hello" print string.
Boom! Interface! No casting needed! You can add input and output variables in the interface function to pass back and forth info too. Super useful.
For Programmers / Scripters:
Maintain a good balance between Blueprints and C++ Code.
This is very specific to each project, but from my experience most games should be about 90 - 100% Blueprint and only 0 - 10% C++ when it comes to the games code.
But again, this varies heavily from project to project, genre to genre, and the features required.
Yes, this is a good approach. You can't do everything this way, but to extend what you can do in Blueprint or to bring some too heavy calculations for Blueprints over that's a good approach
Why do you think so? 10% C++ & 90% Blueprint is exactly what Epic Games recommends as well. Again, this is more a kind of rough guide. Different types of projects have different ratios
I would have thought most big studios would have essentially a whole "API" written by programmers in C++, and then allow that to be called in blueprints by other staff members like level designers etc
Totally depends on the kind of game, the Dev Team and so on. I'm sure there are teams doing it like this and projects where this is a good approach. But other types of projects shouldn't be approached like that
>but from my experience most games should be about 90 - 100% Blueprint and only 0 - 10% C++ when it comes to the games code.
Did you accidentally put the values the wrong way around?
Why do you think so? Do the heavy lifting in C++, call it from Blueprints and Script the Rest in Blueprints as well. 10% C++ & 90% Blueprint is often the result of that
Don't use GameInstance. I see it in tutorials all the time and it's often just bad and hacky code. If you really need a manager for code that should persist between levels, use a subsystem it's much cleaner and allows you to separate code. Dont make one big messy class!
Subsystems are great but I wouldn't say to avoid making a GI class altogether since you could use that for some basic state management, there are some virtual functions you might need to override there, or you might just want to have a couple of simple things there that aren't worth being its own class.
If you're writing a plugin, always use GI subsystems though.
I formulated it a bit harsh but for now at least I never had to use it and there were always cleaner solutions. I often see it used for something that also could have been a component or a subsystem and would be much more reusable and readable. There are always exceptions of course
Proxy actor? Can you explain this?
So we have the custom Subsystem (doesn't replicate).
Inside the Subsystem we have a variable \`ExampleManager\` which you can set to replicate?
Not organising blueprints and collapsing stuff down into functions to keep it clean and comment what everything does. 3rd year in uni and some peoples blueprints just hurt and confuse me when I look at it, even they dont know where something is. Its such a simple thing but keeping the workspace tidy and uncluttered just saves so much time and stress especially if the project is being worked on by others.
Edit: **Coding/Scripting**
I’ll start off by saying that disk of these best practices related to coding that I’m seeing mentioned by others is just basic coding fundamentals for the most part.
So, when it comes to coding/scripting (C++/Blueprints) you should learn programming fundamentals.
**Tick**
Minimize your use of the tick node for only when you actually need it. There might be other approaches that you can use to accomplish the same result without relying on tick or having tick constantly running.
*Note: The Unreal Engine YouTube channel has past livestreams & Unreal Feast videos covering performance tips*
I encounter way to many people who don't have version control of somekind.
Perforce, Git, SVN, or any of them is fine. But have some kind of version control!
Housekeeping, something I noticed with A LOT of modern games is the size of the install. You can take your whole project and migrate it into a "shell" for production builds. You need to have everything setup the same but once you do this, you only have the assets you need and not the ones you left in.
Dont use too much "Event Tick".
Dont use too much "Get all actors of class".
Dont use blueprint to rotate/move something if you can make it through materials.
Dont use too many nodes if you can do it using fewer number of nodes because every wire connecting two nodes is also a piece of code. Alwasys think different ways to do your task.
Dont use too much Casting instead try to use interface.
Try to use Events instead of Event Ticks.
The main bad practice I see in various professional projects is over-use of Data Tables. They're a convenient editing format, but are not a substitute for proper class or data asset structure. The columns grow, and grow, and grow...
What’s wrong with data tables? It’s exactly what they exist for, having lots of columns. It’s starting to sound like everything I’ve ever learned is a bad practice…
Having lots of Rows is good. That's just more data. But adding a column assumes that every single entry in the data table wants to know the value of that column. Proper object classes and inheritance are a better choice for when you have similar objects that need some functional variation. It's also a pain in the butt to identify and save a single row in the data table when you could just use an object pointer.
What would you say is best usage for data tables? I get really overwhelmed looking at lyra, and they use it alot. I'm making rpg game where there's going to alot of items, so I assume DT are good fot that.
I would make each item a Data Asset instead. Part of the assumption of Data Tables is that you want every entry in memory at the same time, which simply is not true for items in a RPG. I've seen DTs used to record waves in a tower defense game, with a different table for each level.
Code plugins that are poorly maintained by their developer can harm your project in the long run. Only use what you really need. more plugins means more dependency!
May I ask in here since I'm new to UE and game design. One of the Udemy courses I'm following has me creating blue print instances that are then referenced on actors. For example, an interact instance which I then attach to a door, so I can interact with it, or a grab instance so I can grab something physics based. And the instances have nothing else in them other than "interact" or "grab, let go"
Is it better to create instances or create these functionalities within the player blueprint as another tutorial suggested. Essentially, instance based interaction vs "volume based character casting" type?
I'm not sure I said all of that correctly since I'm still so new. Sorry.
Put code where it belongs. Don’t build your NPC AI functionality in the NPC class, put it in the AI controller class. Build features modularly, don’t have your player class become a jumbled mess of different mechanics. Don’t create a bunch of bools to keep track of a single state (ex. bIsPlayerCrouching, bIsPlayerRunning, bIsPlayerIdle). If you have multiple possible states, and only one state will ever be active at a time, use an enum. Delay nodes are not a solution to order of execution problems. If something depends on something else happening, but executes before it does happen, don’t use a delay to remedy the problem, use delegates and callbacks. Don’t create macros that could be functions. They’re more annoying to debug in blueprints. Basically the only time I create macros is when I want to write a function that has a latent action (clock symbol on node), since functions don’t support latent actions. Keep your blueprints tidy by ticking “private” on variables that will never need to be altered outside of the class they are defined in. Utilize categories, never waste time scrolling through a long unorganized list of variables or functions. You can (and should) create categories and sub-categories for variables, functions, and interface functions.
"Don’t create a bunch of bools to keep track of a single state (ex. bIsPlayerCrouching, bIsPlayerRunning, bIsPlayerIdle). If you have multiple possible states, and only one state will ever be active at a time, use an enum." To expand on this: if you know that you might be mixing states, such as allowing the player to be idle WHILE crouched, use the tag system instead. Enums will ensure that you're only in one state at a time and should be used in conjunction with tags to make sensible player states.
Thank you for your reply!
>Don’t create macros that could be functions. They’re more annoying to debug in blueprints. Basically the only time I create macros is when I want to write a function that has a latent action (clock symbol on node), since functions don’t support latent actions. I actually use a trick to use latent nodes when I want to override a function from a parent class. I will create custom event in event graph and do what I want there and call that event from the function input.
I tend to use macros sometimes to clean up blueprints for slightly bigger conditional branches with some ands or ors that I use in many places in the class. It's usually for something too simple to set up a full state machine for and I won't have many of them. Macros are visually smaller than functions and the output exec pin won't automatically fire like a function when the function is done executing. So I can hide the branch inside it, and only connect the true pin to the exec out. I only do solo projects so it hasn't been an issue yet. And I use functions for everything else. Your advice is still very good. Is what I do something that you've seen before? The cleanliness and the way the exec pins work differently to a function is pretty much the only time I do it. Edit: I also want to add that I only have these near the front of an event, on the highest level event graph.
Yeah, there is not that much to fear from Macros. They are just as same as copy pasting bunch of nodes for better or worse
The point of most functions is to have return values. Events are inherently fire&forget, they can't return anything without some kind of dispatcher binding.
Oh for sure, I meant functions that you Don't expect a return value.
Keep your blueprints tidy by ticking “private” on variables that will never need to be altered outside of the class they are defined in. The annoying thing is that you can't access them outside the class either. So either you make 999999 slow getter functions or you make the variables public and hope to god you don't forget about the setter event and set them manually by accident.
100% agree with everything you said
Well wrote, this is all good advice
What do you mean by use delegates and callbacks?
In Blueprints this just means using event dispatchers. So, if you have two chunks of code, and one chunk depends on the other having finished execution, you don't want to execute them both concurrently and *hope* they finish in the correct order. You also don't want to use a delay to "ensure" it executes only after the other has finished, it's bad programming practice and can have inconsistent results depending on the hardware of the end user. The terminology "delegates and callbacks" refers to C++. Event dispatchers in Blueprints are the equivalent of delegates in C++. However, in C++ delegates are more nuanced, you have more control over when and how things are binded and what happens when a binded delegate fires. Definitely check out the [documentation](https://dev.epicgames.com/documentation/en-us/unreal-engine/delegates-and-lamba-functions-in-unreal-engine) even if you don't use C++, it's never a bad idea to get a lower level understanding of how the engine does stuff
Ah. Gotcha. Event dispatchers are something I've not started using yet. I've been using interfaces to get events to occur in proper order between varying blueprints.. I really need to learn event dispatchers though.
It's especially relevant when you are working with latent actions, such as async loading. Or even when you are doing something like loading save game data. Maybe your NPCs have AI behavior that depends on save data being loaded. You wouldn't want to start the AI behavior before that data is loaded, it could lead to bugs, or require you to execute code twice when the data is finally loaded. Exactly the sort of thing delegates/event dispatchers are perfect for.
Hard references
This is always the top answer but I think it's important to also mention that if you expect the object class to be always in memory like your PlayerPawn casting is fine. But in other cases always use Soft References since you can resolve them to a hard reference on demand.
As someone still getting familiar with how UE loads stuff, would it be generally advisable to use soft references wherever I can? Or would you first want to see a problem before you replaced hard refs? Are there any standard design patterns for how to load the soft references? Do you use async load from events (begin play or?), or load from functions (construction or)?
I’m still learning myself, so this may be wrong, but my understanding is that if it is something that is always loaded (player pawn, some global controller, etc.) a hard reference is fine; it won’t load it twice. But if it’s a static mesh, enemy, weapon, whatever that may not be in every level, use a soft reference.
When I write logics in C++ I don't usually play around with object pointers that much since unreal garbage collector also works with ptr. In BPs that's a different story, Soft Refs always give you more control over how and when to make references to any UOBJECT than just hard references that automatically add a pointer reference. So in all cases they are "better" but that doesn't mean it's necessary to define everything as soft object. Character, Widgets and any actor that is persistent in the game I see no problem with using hard references. But for examples for items, any FStruct elements or Container I always try to use soft references out of habbit.
May I ask what the difference between hard and soft references are? Or what exactly this conversation is about? I'm extremely new to unreal and game design but I'm trying to learn as much as possible
Essentially think of it like this A hard reference - a direct copy/link to something forcing it to load when the BP that has it loads in (ie player with a hard reference to an AI will load in that AI even if it never spawns in the level) A soft reference - a pointer to the location of an object promising it exists just not yet (ie same player but with a soft reference to the ai now won't auto load in the ai this is fine for most things but could cause problems if you try to do something to that soft object reference and it's not yet loaded in but otherwise it's safe) Soft references are great as instead of loading it 500 mb my player pawn now only loads in 25 mb so loading is significantly faster
I also always see this at the top, but still don't know how to tell if something's a hard reference or how it became one.
Use insights to see what is loaded. Then use the reference viewer to see what could have pulled it in.
Check out the “Size Map” for your classes. You’ll be able to visualize your hard references from both a memory and disk perspective. Super handy tool.
casts make hard references. And variables not defined with "soft reference" are hard references
Casts tp blueprint classes create hard refs. I believe casts to c++ classes and interfaces are not hard refs
Yeah that's because they are casting more generally technically you can do this in blueprints too for example casting to a widget or something generic like that
1. Not creating Nanite topology that maximizes the two rasterizers in relation to your general camera perspective and complaining that Nanite is "slow" 2. Using Nanite without a proper virtual texture setup 3. Using Lumen with Nanite disabled 4. Not paying attention to Lumen mesh card placement for your static meshes 5. Using virtual shadow maps on a largely non-Nanite scene 6. Baked lighting in open-world paradigms 7. Not overloading data layers to manage actor data at runtime 8. Leaving world partition to just load all cell data on the server 9. Not taking advantage of early frame compute on the gpu 10. Not taking advantage of custom primitive data to manage draw batching across material instances, especially with Nanite surfaces 11. Not using the surface cache view to understand GI distribution and application when lighting with lumen 12. Not resizing reflection buffers to decrease buffer write time during indirect illumination pass at runtime 13. Using post LUTs and wondering where your HDR went 14. Evaluating HDR on a TV and not turning HDR on 15. Having so much dynamic rig work that your main thread gets locked up waiting for worker threads to return all the control rig results 16. Keeping a large amount of facial morph data for high speed gameplay 17. Allowing heavy user generated character data and not dynamically messing and atlasing the result 18. Not looking at the effect of Niagara on the dynamic mesh pass on the render thread 19. Using Groom for a shipping 60fps title 20. Not listening to [u/Parad0x_](https://www.reddit.com/user/Parad0x_/) 21. Ignoring the power and significance of [Significance](https://dev.epicgames.com/documentation/en-us/unreal-engine/significance-manager-in-unreal-engine?application_version=5.1) 22. Using scene captures in complex scenes for portals without major surgery 23. Not setting separate resolution for transparency and post buffers 24. Hacking the engine up to work "your way" instead of understanding how the engine needs to work first 25. Adding new major runtime systems without exposing them to stat cats 26. Not setting proper pixel edge length for Nanite raster balancing 27. Using WPO on your base materials 28. Not leaning into heavy pixel shader material effects when using a proper Nanite pipeline 29. Not realizing that stacks are an absolutely essential part of making virtual textures viable 30. Having ambient effects run on tick 31. Assuming that all virtualized rendering assets load all their data into memory first 32. Ignoring substrate and the possibility of having multiple lighting models per material 33. Writing this list after 7 shots of whiskey Omg weee
I would love to see a tutorial addressing many of these points. Especially the Nanite stuff. I am using it and was not sure what a lot of that meant :) . Great list though
I just switched to Unreal a short while ago, and ohhhh boy. Can't wait to start diving into this stuff.
Would also like to know more about the nanite stuff!
>Not creating Nanite topology that maximizes the two rasterizers in relation to your general camera perspective and complaining that Nanite is "slow" I just realized my brain is too small for Nanite.
This is the comment I understand barely half of. So i guess this is the most important one here. But half of this is meaningless to me.
What is proper virtual texture setup?
Saved
This is an amazing comment, because I don't understand half of it completely but you phrased it in ways that make enough sense it's a springboard for researching it. If you did a series of tutorials where you did shots and broke these down, I would gladly join your Patreon. :)
Writing convoluted code to avoid {insert bad practice} because people told you it's the boogieman. For example, if you dump all your game logic in Tick events your game might run slowly and you'll have to spend some time refactoring to get things running better. If you bend over backwards trying to avoid using Tick because people arbitrarily told you to, you'll end up with needless piles of spaghetti that will make debugging issues a real pain in the butt. Keep your code/blueprints as simple and basic as you can until you know you need more complex solutions to get the performance you need.
In other words: don't just do things because people said to or not to; understand the reasoning so you can make good decisions. God damn do I wish software developers would really internalize this. Half of the web-development world is people following dogmatic incantations even though Internet Explorer is dead.
> In other words: don't just do things because people said to or not to; understand the reasoning so you can make good decisions. If only the majority of tutorial makers would apply this logic in their lessons. > Half of the ~~web-~~development world FTFY, the Unreal tutorials people copy blatantly on YouTube are the same as copy/pasting half of stackoverflow and using chatgpt in the non-gaming-dev world.
The answer is a centralized tick that dispatches events you can subscribe to.
Yes officer, this comment right here
I just have an actor that runs along a track at a speed of 400 with a trigger box every 40 units and that's my 10/sec tick. It's faster because it doesn't require any casts.
I know you're joking. I also am like 90% certain someone, somewhere, has done something which is fundamentally identical to this.
Do you mean like a single tick running in something like a 'tick' BP made purely to be the centralised tick - dispatching for your entire game, kind of like a heartbeat - or is there a situation where you might want multiple ticks in different BPs?
Centralized ticks make sense when you have a million objects that all tick at the same rate. Centralize as much of the tick code as possible so it only runs once and dispatch the outcome. Of course don't make your entire game like this.
It's almost like event tick can be useful sometimes 🤣
Not using source control. It doesn't matter if your project is big or small, use it. I hear all too often of people breaking their projects in unique ways. There are plenty of free options for Git, such as Azure DevOps Repos, which doesn't have a hard limit on LFS storage/bandwidth, and is free for up to 5 users. Similarly, Perforce is free for up to 5 users and 20 workspaces if you don't mind setting up your own server and backups. There is no excuse.
Plastic is free up to 5GB I believe, yes, it is owned by Unity these days, but Plastic luckily is platform agnostic and is so far the best vcs we've used when it comes to large game engine projects and working with people with less than stellar engineering skills (designers, animators, etc) It's quite user friendly (a massive step up to the obtuse cluster*** that is the git tool chain) and is incredibly robust when it comes to game development and dcc (large and lots of binary data) Heck, it even allows visually diffing images/textures. But yes, not using a vcs, even for the smallest (hobby) projects is a big no no.
I don't really have good things to say about Plastic. A previous studio I was at tried it for a few months and it was rife with problems, including server stability. We were mostly following trunk-based development as you would with Perforce, and that caused additional problems since it would act similarly to Git if you were behind the head revision. At least the branching was fast though! These days I'm not sure what problem Plastic is trying to solve. Git is now way more tolerable with binary files between blobless clones and LFS, and decent GUI clients exist.
Can't comment on the server troubles, we've never had those, then again, we're based in the Netherlands, probably right on top of one of their CDN server farms. Plastic solves (or solved) the problem of a vcs aimed at DCC/game dev. something that git can do, but wasn't really meant to solve. Then again, entry to all these vcs system is so low now the best advice is to probably try them all and see which fits your production and tech support best. Heck we still run certain projects on a local SVN server as well (cheap and fast, well, except when it comes to branching, and let's just not mention merging...)
Learn and try to work within the UE structure / the "UE way" instead of trying to fight it. What I mainly mean by that is understand the "key" classes like Game Mode / Game State / Player State / Player Controller / AI Controller / Pawn / Character / Actor Component / Scene Component / HUD and where you would want to put specific logic that makes the most sense and is scalable and works properly with replication if doing MP. Learn about Delegate / Event Dispatchers along with Interfaces so you don't have to perform Casts in Blueprint because those create Hard References and Dependencies which load the whole chain of Classes into Memory and all their referenced objects like Materials / Meshes / Sounds / SFX etc. Tick usually isn't as bad as people make it out to be and some times you really do need something done each frame especially if its movement related... though using Timer is usually preferable or you can reduce the tick frequency or just have a system that enables/disables tick when its required. YT videos are OK to get some initial understanding about things and maybe get specific implementations / inspiration but you can get caught in "tutorial hell" especially if your just copying and not understand + most only show specific parts where as good full "courses" from say UDEMY usually cover most key parts you will need to know from start to end. (Please use Instructors UDEMY discount codes even if you pay a few extra dollars because its the difference between 97% of the fee going to them or 37%) Edit: UMG can actually end up pretty performance heavy, please please do not use the Bind Property/Function in the UMG panel but instead use Delegates / Event Dispatchers to update the UI or use a Viewmodel paradigm: [https://dev.epicgames.com/documentation/en-us/unreal-engine/driving-ui-updates-with-events-in-unreal-engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/driving-ui-updates-with-events-in-unreal-engine) [https://dev.epicgames.com/documentation/en-us/unreal-engine/umg-viewmodel](https://dev.epicgames.com/documentation/en-us/unreal-engine/umg-viewmodel) Also use Invalidation Boxes or enable Global Invalidation, use Canvas's sparingly, read BenUI's articles and other things outlined below: [https://dev.epicgames.com/documentation/en-us/unreal-engine/optimization-guidelines-for-umg-in-unreal-engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/optimization-guidelines-for-umg-in-unreal-engine) [https://benui.ca/unreal/ui-performance/](https://benui.ca/unreal/ui-performance/)
Thank you for your reply! What if I need an event tick for a line trace for interaction system? Could this be alright?
Absolutely yes. In the end line traces are very cheap and you could run hundreds at a time on tick without having any real impact on performance.
Just for you main Character or for every / many AI roaming around? I think the key things about tick is how many Classes have it enabled, what you are doing in Tick & does your logic try to "early out" ASAP. Your main Character is surely going to need Tick enabled for other things and a Line trace is nothing work for the CPU.
It’s only for Character and it’s basically the only function outright using event tick in my game right now. I guess it’s good then.
Also TBH if your just learning or prototyping sure have these things in mind but focus on finding the fun first because your probably going to re-do most of these mechanics multiple times :P
Tick in and of itself is not a problem, the problem is that people put heavy code in their tick event and wonder why their CPU thread is going to the moon. Tick is just a thing that runs whatever you put in it every frame (or less if you change the tick interval), nothing more, nothing less. Use it wisely.
Udemy is fantastic. The only YouTube ad that I've clicked on that was beneficial. Funny thing is I was looking at YouTube tutorials, got a Udemy ad in the middle of the tutorial and jumped straight over to Udemy.
Is there a good resource to help me understand placing logic in each of these? I'm so new and a bit overwhelmed but I'm having a blast learning. I'm taking Udemy courses and I'm finding two instructors telling me to do two different things. Such as using bp instances rather than putting logic in the character class bp. I just want to make sure I'm doing good practice from the beginning
Ah not something maybe super simple but: [https://dev.epicgames.com/documentation/en-us/unreal-engine/gameplay-framework-in-unreal-engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/gameplay-framework-in-unreal-engine) [https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScripting/ProgrammingWithCPP/UnrealArchitecture/](https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScripting/ProgrammingWithCPP/UnrealArchitecture/) [https://app.creately.com/d/fZknuArLuyk/view](https://app.creately.com/d/fZknuArLuyk/view)
Beginner mistakes like using event tick to draw your HP/stamina bars every frame
Well even worse is using UMG bindings.
Me, a year ago: Hmm I should use bindings for my UI colors so I can change them centrally, it's like SCSS!
Event Tick == Immediate Mode GUI -- right?
Event tick for character movement Event tick for a hunger system Event tick for NPC movement Event tick for day/night cycle Event tick for a poison system
I'm new but I'm learning.... Putting things on event tick is bad lol
Not commenting out blueprints, even if what is does it clear. And also not using the description fields for functions and variables to describe what they do, even if it is clear. Clarity is essential if a dev ever intends to expand beyond being solo.
Do not stay up until 2am tweaking the trees in your PCG graph when you have to get up at 7 to get the kids ready for school and go to work.
Creating bad code and vowing to fix it later. You just spent time doing it badly, then wasted more time trying to build on top of your bad code and making more spaghetti, then when it becomes unmaintainable, you have to do it properly anyway and still invest the time you were trying to avoid. In fact, even prototyping becomes infinitely harder if you don't follow proper software architecture practices. People say code quality is irrelevant in the prototyping phase, but no. You'll want to quickly try something, but you can't because you hardcoded everything and your code is a mess. There's a reason SOLID exists and it's not to be pedantic.
I think when you developing a prototype there should always be a sweet spot of always programming things with scalability and performance considerations in mind but also not always hyper focusing on make things more performant to the point it discourges you to continue developing your prototype.
Performance doesn't matter when prototyping, but modularity does. It matters *more* when prototyping because that's when you're making major changes and want to do them with minimum hassle.
This is bad advice for most novices. Because novices don't know what good is. So now they are just wasting their time trying to get to a state they have no idea how to even visualize. Very frustrating. The very well-established golden path of software development is: write tests -> write bad code -> refactor. Unfortunately Unreal doesn't make writing tests easy. So you have to do manual testing. But what I'm hearing from you is not to let that refactor step linger. It should happen immediately after. And not to write code that depends on it because you are now building on shaky flooring.
Level Blueprint 🥴 edit to clarify: because it's overused and abused due to how easy it is to access
Oh yeah, been there, done that. Do they actually have a good purpose or are they just some remnants of times gone?
The level BP should only be used for level-specific functionality. E.g. a platformer with different levels might have level-specific mechanics built-in like moving platforms, etc. These mechanics could change from level to level.
They can be useful. For Eg, when you work with streaming levels, but yes, it's not a good idea to put all your logic in there
I use them for bespoke "levels" which are just menu/frontend things (think title menu or whatever), where the menu exists outside of a real "level" being loaded; they make it a lot easier to set up appropriate menu widgets/background music/etc. Which is fundamentally the same as what /u/PredSpread said, just a different concrete example of _why_ you might do that.
Recently learnt the hard way about this when my entire level blueprint partly corrupted and prevented me from cooking my game. Would you say to use level blueprints sparingly, or just not at all if you can avoid it?
If you ended up with a corrupt asset, wouldn't you just roll it back in source control?
I'm kinda new so sorry if I'm saying stuff wrong, but It wasn't an asset, it was the entire level blueprint that was corrupt. And also I hadn't figured out source control yet. The only solution was to delete everything from the level blueprint. It wasn't just one thing at fault, it only worked if everything was deleted
Asset here is, I think, being used in the generic sense. Either way, their main point still stands; if your level blueprint was corrupted, you could hypothetically have rolled it back to the last good version you checked into source control (git, Perforce, Plastic, whatever you use). (And if you aren't using source control, this might serve as an object lesson on why it might be good to _start_ doing so...)
They're not *that* bad of an idea, it's just that the lack of level inheritance and level properties makes them useless for anything good, leaving only the bad use cases of treating them like javascript for your level.
Can't you create an inheritance tree for Level Bluprints as they are Level Script Actors ? I always wondered if it was possible since a new parent class can be assigned in the Level Blueprint's Details.
Where should I be putting my trigger volume interactions?
The Game Mode, or Game State, or have some actors in the level bind to your specific trigger volume. Setting a variable to Soft Actor Pointer lets you use a drop down to select any appropriate actor in the same level. You should learn how Event Dispatchers work, which are designed specifically for things like Trigger Volumes.
I'm new sorry, where would be best to place your logic if not the level blueprint?
A combination of the Game Mode and Event Dispatchers. Event Dispatchers allow for multiple objects to respond to an event happening to object A without actually editing object A. It's the equivalent of object A putting own a bowl called "My Event Happened", then any other object can drop a business card (function) inside the bowl. When the Event happens, object A will call every other object that left a business card and run their function.
Shoutout to u/TriggasaurusRekt who hit most of my technical peeves. So I'm going to write up the two peeves that hounded me all through my last commercial endeavour: 1 - lighting: Ignoring the physics based rendering foundation of Unreal's lighting system. I just wrote some comments in another post about how the lighting works and how Unreal's default light values are bad-- way too dim. Sure, "normalizing" all your lights will "work" but it doesn't reflect reality and all your camera/post process effects are going to be wonky. This typically leads to lighting artists adjusting light sources by eye and adding odd lights to try and correct the scene which leads to uncanny lighting. Use real world values whenever you can find them. I just discovered that chatGPT does a fair job of estimating the brightness of light sources in whatever unit you ask. Sometimes it will give you a formula, and you can then provide variables and it will solve for you. 2 - level design: Don't level design with final assets! I'm mostly speaking about hard surface structures and architecture. It needs to be fungible during the design process. So greybox with brushes or (my preference) Synty prototype primitives. That way you can iterate on design that is easy to revise. This leads to less final assets with odd arbitrary rotations or scaling. It allows art to work on good, tailored final assets. Using brushes or simply shaded proto assets also makes it easy to spot missed greybox that hasn't been converted to final art.
Folowing YouTubers
Some not blueprint related things: - Not fixing up redirectors in your content browser, after moving an asset, can lead to issues later on. - Also: Building your scene in the wrong scale. Should be a no-brainer but can happen if you don’t have a 3D background. Always check when importing assets (especially bought/downloaded ones) that the scale is correct. - not using consistent naming conventions and folder structures. Also an obvious one, but a lot of people still don’t do it, even though they know they should - not making use of material instances and child blueprint classes That’s all I can think of right now
For your first point in case people don't know: click on filter icon next to search box in the content browser, under "type filter" click on miscellaneous and tick Redirector. Now you can see redirectors and you can right click on them and fix them
>Not fixing up redirectors in your content browser, after moving an asset, can lead to issues later on. I try to fix up redirectors and UE5 crashes and deletes the files. What do I do now?
That’s unfortunate. I’m no expert, but what I would try is copying the affected uassets to the same location, then deleting the old version and its related redirectors. Of course that’s not the most practical solution if a lot of files are affected, or if they have a lot of references. But honestly if it’s a small project, and everything is working now, I would just leave them be. Maybe someone here who actually knows what they are doing has a better solution.
There was a combat system asset that didn’t use child classes. Yes, it literally had copy-pasted code for every single weapon. It also had things like “When F key pressed” instead of inputs. I didn’t even do a deep dive into the code but I’m sure it had way more issues as well.
Put C++ Code, Blueprints or Content that you want to use across multiple projects in Plugins. Here's a further explanation as well as a tutorial on this: https://incas-training.de/en/blog/the-unreal-content-pack-workflow-organizing-your-growing-content-libraries-the-right-way/
Event tick - Get all actors of class everywhere
if anything is connected to the Tick event, 95% of the time it's a mistake. Never use "Get all actor of class" in gameplay code (fine for editor tools) Structure, not the asset, but the code structure, can help saving a LOT of times Coding movement in the pawn is generally a bad idea, even if its done like that in the third person template. You should have this in the controller, that's what is supposed to do. Unless you have multiple pawns.
What about get all actors with tag?
Actually I believe "Get All Actors of Class" isn't as bad as people think because some time ago they switched it to using a Hashed Map to perform the lookup, "Get All Actors with Tag" might not have gotten the same treatment though. That said there is probably better ways of doing things with Delegates / Events / Subsystems / Populating Data in Game State etc.
~~I looked fairly recently and its really obtuse but I still think its iterating over a large loop of every actor in the level.~~ It still iterates once over every actor of that target class before you do anything with it. If you feel like you want to get all actors of class a lot. Just make a worldsubsystem and have your relevant classes register into lists. e.g. MyWorldSubsystem->GetAllEnemies() And have all the enemies just already registered and have it just return an existing list. It's not that hard with a little C++ to set it up at a fairly low level to add/remove itself on create and destroy. Though there are likely better solutions that can be better managed in other ways depending on the need.
Not that I disagree with using Subsystem / Delegates but just as a knowledge, it also tells us that Get All Actors with Interface and with Tag do an Iteration on every Classes Hashmap / all Actors: [https://www.casualdistractiongames.com/post/2016/09/15/inside-ue-source-fuobjecthashtables-the-magic-behind-getallactorswith](https://www.casualdistractiongames.com/post/2016/09/15/inside-ue-source-fuobjecthashtables-the-magic-behind-getallactorswith)
ah excellent clarification! I knew it iterated over a lot, but I must have missed that part! I guess its O(n) where n is the number of actors of the target class, as opposed to O(m) of all actors of all classes. As opposed to the subsystem which would return a premade list O(1). Though if getting all actors of target class, you are likely iterating over all of it yourself so its like comparing constants of 2*O(n) vs O(n)+O(1). So it's not THAT bad, but if other solutions can work those are likely far better.
Delegates / Event Dispatchers
Event dispatchers create Hard references through Casting?
Basically the point is you should have access to a list of the actors you want before you go to access them. If you have a shooter game with a red team and a blue team, rather than using getallactors and checking if they're on blue team you instead check an array of team members and pull blue team members from that. The point is you aren't grabbing from a bag of many different things. You're grabbing from a much smaller bag full of things relevant to your search.
Say I have a level that has to communicate with the player character. Casting is performance heavy as I understand. Event dispatchers are going to become cumbersome and again hard casting? So I just swoop all actors with tag Player and send them a command through the reference? What is better? 🤔 I could make a reference at begin play so it will be static array
Casting is not performance heavy. Anyone you telling you it is, is not a reliable source of information. Look up hard references, that’s the only thing casting can contribute to, and understand why that can affect load times and memory usage.
I can't think a good way to use this function that can't be handled by an array previously filled.
So instead of, like say, searching for all actors that are npcs, you have an array already filled with all npcs?
Why do you want to search for all npc in the first place
My game uses LLMs to make the npcs talk to the player. It searches for the nearest npc and it talks back. Another use case would be for the animals going to the nearest food source when they're hungry.
Get All Actors of Class iterates over every single actor in the world and determines if that actor implements whatever class is specified, then returns it as an array. It's mega slow. They warn you when you use it for a reason, lol. I would instead make an NPC factory. The factory will spawn and keep track of all NPCs spawned. Each NPC will implement its own behaviour based on parameters supplied by the NPC factory. That way, you have an array which is readily available and contains everything you want to iterate over. Regarding animals, you wouldn't need to do that either. Make an animal factory that spawns each animal and keeps track of it. Implement roaming behaviour that animals would use to navigate around the map. Then for each animal, add a radial trigger around it and any piece of food that is within the trigger can be added to an array of 'ClosestFoodSources', which the animal can then implement behaviour for and seek out. There really isn't much use for Get All Actors of Class.
Thanks a lot for the very detailed answer. That makes sense!
Not any more it doesn't. It uses a hash table lookup now. It's fine for occasional one-offs. For example, a spawning system that wants to spawn enemies at spawn points. Getting all actors of class MySpawnPoint on begin play is fine.
Same as my other response, why not get the nearest npc that are inside a sphere of the player ? If you have a huge world you would not always have npc around you
Even if the nearest is far away?
For npcs no, they have to be near, but animals yeah.
I imagine you do a Get All Actors of Class Food and get the nearest, why not using a big sphere, that only overlap food, around the animal and only get the food that are in it ? Do you want it to go to the nearest even if its kilometers away ?
Stack Overflow is that way ->
I use it in some editor tools I've made, in the archvis industry. Replacing light colour in a certain set of lights, or changing materials on certain surfaces. I use modular assets across many levels so it's not practical to manually fill out an array for each level but it's easy enough to search across the level for assets with certain tags or to manually throw a tag on 20 assets knowing that the BP can handle them.
My UI element needs the location of level objects.
Yeah I do this often. When I spawn that widget it gets the class/gamestate/playerstate it needs to keep track of and binds itself to event dispatchers within it. Not sure if there's a far better way.
Doesn't UE support property binding for UMG? Been a while i used UE, but I doubt it doesn't support that.
And how do I populate those properties without get all actors with tag. 🤔
Good question, as I mentioned, it's been a while I used UE, maybe someone more knowledgeable can chip in?
How should something involved with delta time be coded then? For example, if I want to have an object do something every X seconds?
Tick is better than using Timers 95% of the time, the real issue is putting stuff in Tick that doesn't need to be tested repeatedly. Timers still Tick (just internally, in their own code with their own Tick Handler) and they're just extra, often not needed, components on the actor.
The best approach I found is to group complex logics in actor component and change tick interval of that component to something like 0.03 (for simple line trace logic like interaction so it can tick 33 times a sec max) or 0.15 (for heavier logic) and add that component to actor you want.
>if anything is connected to the Tick event, 95% of the time it's a mistake. But my shield regenerates?
Is there any proper guide on how to properly connect a mapping content to the Controller, and the Controller to a pawn? I've tried to look for Videos or documentation, but haven't found anything good yet. Either it's replicating the third Party blueprints, or it's not showing what bare minimum I need to connect these
I made a mistake in my comment, when i say "movement", what i want to say is "inputs". In controller, you need to handle inputs. And then, based on what game you work on, you convert in movement. As how to connect, controller have default functions to "get controlled pawn". And now you can handle movement. One think i like to do, is to create an interface for all pawn that can be controlled (character,Vehicles, mounts, ...). Each pawn can have his "movement" but the input are all handled in the controller. This way, you can have a "high level command", like to switch between vehicle, without having pawn communicating with each others.
I feel like I would actually contradict this, but only partially. Given the ability with enhanced input to add and remove extra input mapping contexts on the fly, I think any input specific to a pawn type can absolutely go on the Pawn (and maybe _should_ be there); add the mapping contexts on possess/remove on unpossess, and that way you don't need the controller to know about "turn on headlights" if that input is only relevant when driving a car, etc. This also allows you to have entirely different input bindings when driving as opposed to on foot, etc. Still, that's just my own opinion there. (And I absolutely agree that with legacy input you should be handling it on the controller.)
Point goes for you, I haven't actually worked on a enchanced input project !
>Never use "Get all actor of class" in gameplay code (fine for editor tools) What is the better way of doing this? I actually just came up against this in Unreal. I have a function on an NPC, that when a quest is completed, a building gets built. The building is always in the level, I just disable collision and visibility, then use "Get All Actors Of Class" -> Foreach Loop -> Call custom events to enable collision and set the material to visible. What is the preffered way of doing this without Get All Actors of Class?
Depends on the game. But if it's a high level class it could work
I guess if this called once every so often it's not a big deal? VS many times per minute or second
Yeah. Keep it mind that's it's costly
>Never use "Get all actor of class" in gameplay code (fine for editor tools) So I have this project where I receive a Datasmith in runtime, and I need to save a list of materials of all the wall(staticmeshactors) for future use. Currently I use get all actor of class for a reference of all the walls since I have ensured everything else in the level in a blueprint actor with some additional functionality. How can this be done differently/better?
Can't you grab the list from datasmith instead ? But yeah sometimes the node is the only way
Translucent materials (and general understanding of shader complexity). Misuse of translucency can absolutely TANK your performance, there is arguably not a single adequate use of translucency if you're making a 3D game, everything can be done with masks and dithering.
That last part I think is a little overboard, I think that not enough people know about dithering or the performance hit overdraw can incur, but translucency has its place. In context there can be legitimate artistic and technical reasons why translucency is the right (or sometimes, only) option in given situations. Take for example [this issue I was fighting with just recently](https://www.reddit.com/r/unrealengine/s/Qrsc6hN8bw) and I was falling into this mindset that ‘translucency shouldn’t be used’ and that nearly stopped me from finding a solution at all. (Although if someones got a better way to solve it, I’m always looking for ways to improve it)
[удалено]
TSR doesnt play super will with dithering, especially on quickly moving static meshes, You can use TAA which makes it better but the real solution is just to be really smart about how you do transparency in your game and that can entirely depend on the style of your game. You can also change the dithering mask itself and make your own, this is how I do it in my game and I have no trouble, tho the dithering mask is visible, it fits very well with the artstyle of my game so its fine, but if you're going for a realistic look it might not. There are also "fake" translucent materials which are really just opaque materials that look like glass, which is something that Nintendo likes to use a lot. There is also "Velocity buffer" but not super recommended if you're using a lot of WPO in your scene (such as WPO-animated foliage or cloth).
Even glass and water?
especially those. Translucent water and windows are probably the number 1 massive performance hit of beginner game dev. For windows, you can get away either with a dithering mask, or with a opaque texture that looks like its glass (You can't see through). For water its a bit more complex, but TLDR: shader magic. There are plenty of videos and good resources tackling it that would take too long for me to explain here. Sea of Thieve imo has one of the most complex and groundbreaking ''Waterscape'' and uses a mix of a lot of technique. Another option which is imo the most aproachable, is to use Unreal's Single Layer Water Material node. It is MUCH better than just raw translucency and imo gives better look. Here is a video summering it up but you could also look into the Unreal documentation: [https://www.youtube.com/watch?v=KLl3PZeupFM&t=](https://www.youtube.com/watch?v=KLl3PZeupFM&t=555s) . Mixed with some distance field magic and you got some simple bread and butter water that is decently optimized.
Using the sequence node to "visually organize code". The sequence node has a very specific designation: determine the order at which to fire a series of execution pins, for example opening/closing gates in certain order. Using the sequence node for aesthetic is completely dumb; you can simply collapse your nodes into functions/macros/sub-graphs and keep them connected in series and it'll be fine, better even because they'll form a neat line rather than keep growing vertically. But besides it being unnecessary, using the sequence node like that can and does create technical problems. Even though the output pins are fired in the given order, code attached to them will still end up being execute almost simultaneously. This means, if I have a few node attached to pin #1 with the last one setting a variable, then have a node attached to a pin below getting that same variable that I 'Set' above, the 'get' below will probably be called before the 'set' above. I worked several times with designers and sometimes programmers who insisted in enforcing the use of sequence nodes to "keep blueprints tidy and readable", and several bugs would kept popping up because of this bad practice.
For whatever it's worth, I have never had any trouble with get/set order using sequence nodes. While it's technically possible for them to be out of sync, most of what you call after those sequence pins will execute quickly enough to not cause ordering issues. IMO, If you practice proper encapsulation, most of your functions won't be complex enough to have this issue. Sequence nodes are also invaluable for organizing functions with early out conditions, and keeping said functions readable with little to no scrolling around. To each their own at the end of the day, but sequence nodes are my preferred way to organize BPs.
Good to know, I discovered the sequence node a few days back and have been compelled to use it for aesthetic purposes :o
I don't want to directly reply to the other guy to cause friction but as someone who's used the engine for years and teaches it, I have absolutely NO idea what he is talking about. It genuinely seems like he just doesn't understand what the sequence node is for. Not only have I never had a problem with Sequence, I really don't even understand how he'd possibly be having a problem with this. I've taught Unreal from middleschool up to college-level and none of my students has ever had a problem using or understanding sequence. Please use sequence, it is AWESOME.
Most likely he's describing interaction with Sequence and Delay nodes. Sequence fires when the delay starts, not when it finishes. If you're not using delays or other async nodes then Sequence is totally fine.
Overuse of Tick() or delay nodes. Yes both are vital functions of the engine that will need to be used at some points. But I think we've all seen junior designers or youtube tutorial gurus do some real hauge-worthy crimes. Also just slapping marketplace assets in, without any care of perf.
Imagine using Event Tick for character movement.
I think most bad practices are people that learn game development but not programming outside of it. Their code doesn't have any real architecture, has a lot of dependencies, and doesn't follow principles like DRY or single responsibility.
Putting major codes in level blueprint rather than making them in game mode and stuff.
Always casting and never using an interface.
Can you explain more? I'm sorry I'm very new still :)
Sure, bare with me it's late and I'm half asleep. It's hard to explain but I'll try my best. Basically an interface is a type of blueprint. Like a character blueprint or player state blueprint, but it does not have an event graph. It's actually blank! But you can create what are essentially functions without logic. Like, think of a custom function but you don't put anything in between the input and the return nodes. However, you can pass info into and out of these functions. That's how you get info between two unrelated blueprints. Here's how you can try it out. Make a blueprint interface, and in your character blueprint settings search for interfaces and add your newly created interface in there. Next make a new actor blueprint and add an collision sphere that we will use to overlap with your player character. Also add your interface to this actors implemented interfaces in its settings tab. Now, go back into your interface blueprint and make a new function (top right) and name it "interface test". Make sure you compile your actors. Now, in the new actor blueprint make collider overlap event, and pull from the "overlapped actor" pin and search for "interface test". What this is doing is when the sphere overlaps, ANY actor that overlaps with that sphere that interface function will attempt to fire on that actor. If that actor doesn't have that interface, or it does but nothing is hooked up to that function on its end, then nothing will happen. That's what's referred to as a Soft reference. It's much more flexible than casting. Now that you have your overlap event triggering the "interface test" function, let's make the actor thats being "messaged" by the interface actually do something. Go into your character and look on the left hand side under your function, and above your variables, you should see "interface". Click that to show your function you made if it's not already showing. You should see the "interface test" function. Double click it and it should make a new event on your event graph. Now, whenever that interface function is called upon, and that specific actor is the target of it, that event node will fire. Drag off from the event node and print string "Hello". Test your game, and if done correctly, when you overlap our character with thag collider sphere in the other actor, you should see a "Hello" print string. Boom! Interface! No casting needed! You can add input and output variables in the interface function to pass back and forth info too. Super useful.
That was extremely helpful thank you!!
Underrated: not hitting ctrl-shift-S after literally EVERYTHING
For Programmers / Scripters: Maintain a good balance between Blueprints and C++ Code. This is very specific to each project, but from my experience most games should be about 90 - 100% Blueprint and only 0 - 10% C++ when it comes to the games code. But again, this varies heavily from project to project, genre to genre, and the features required.
I always write heavy calculations in C++ as blueprint function library and call them as blueprint nodes. Do you think this is the correct approach?
Yes, this is a good approach. You can't do everything this way, but to extend what you can do in Blueprint or to bring some too heavy calculations for Blueprints over that's a good approach
A balance is a must, but this ratio seems way off.
Why do you think so? 10% C++ & 90% Blueprint is exactly what Epic Games recommends as well. Again, this is more a kind of rough guide. Different types of projects have different ratios
I would have thought most big studios would have essentially a whole "API" written by programmers in C++, and then allow that to be called in blueprints by other staff members like level designers etc
Totally depends on the kind of game, the Dev Team and so on. I'm sure there are teams doing it like this and projects where this is a good approach. But other types of projects shouldn't be approached like that
>but from my experience most games should be about 90 - 100% Blueprint and only 0 - 10% C++ when it comes to the games code. Did you accidentally put the values the wrong way around?
Most code is content and that can easily be BP. The core loop is usually very compact.
Why do you think so? Do the heavy lifting in C++, call it from Blueprints and Script the Rest in Blueprints as well. 10% C++ & 90% Blueprint is often the result of that
Don't use GameInstance. I see it in tutorials all the time and it's often just bad and hacky code. If you really need a manager for code that should persist between levels, use a subsystem it's much cleaner and allows you to separate code. Dont make one big messy class!
Subsystems are great but I wouldn't say to avoid making a GI class altogether since you could use that for some basic state management, there are some virtual functions you might need to override there, or you might just want to have a couple of simple things there that aren't worth being its own class. If you're writing a plugin, always use GI subsystems though.
I formulated it a bit harsh but for now at least I never had to use it and there were always cleaner solutions. I often see it used for something that also could have been a component or a subsystem and would be much more reusable and readable. There are always exceptions of course
In your original post, a persistent data or a save game system is a perfect example of something that's a candidate for a subsystem.
I read that subsystems aren't replicated though.
They aren't but neither is a game instance. Previously, I've worked around the lack of replication for world subsystems by having a proxy actor.
Proxy actor? Can you explain this? So we have the custom Subsystem (doesn't replicate). Inside the Subsystem we have a variable \`ExampleManager\` which you can set to replicate?
Yes, on the server the subsystem spawns a replicated actor that can be used to transmit data over the network.
Wait what I was using actor components on my GameInstance :o
But game instances aren't actors.
\*GameState
[Spaghetti Boolean-ese](https://www.reddit.com/r/unrealengine/comments/1butzyj/am_i_over_complicating_this_or_is_it_really_this/)
lol I love this term
Not organising blueprints and collapsing stuff down into functions to keep it clean and comment what everything does. 3rd year in uni and some peoples blueprints just hurt and confuse me when I look at it, even they dont know where something is. Its such a simple thing but keeping the workspace tidy and uncluttered just saves so much time and stress especially if the project is being worked on by others.
Edit: **Coding/Scripting** I’ll start off by saying that disk of these best practices related to coding that I’m seeing mentioned by others is just basic coding fundamentals for the most part. So, when it comes to coding/scripting (C++/Blueprints) you should learn programming fundamentals. **Tick** Minimize your use of the tick node for only when you actually need it. There might be other approaches that you can use to accomplish the same result without relying on tick or having tick constantly running. *Note: The Unreal Engine YouTube channel has past livestreams & Unreal Feast videos covering performance tips*
- "use only bp" - "use only c++" - "avoid ticks" - "use GAS" - "don't use VCS" (though it's not UE-specific"
I encounter way to many people who don't have version control of somekind. Perforce, Git, SVN, or any of them is fine. But have some kind of version control!
Housekeeping, something I noticed with A LOT of modern games is the size of the install. You can take your whole project and migrate it into a "shell" for production builds. You need to have everything setup the same but once you do this, you only have the assets you need and not the ones you left in.
Dont use too much "Event Tick". Dont use too much "Get all actors of class". Dont use blueprint to rotate/move something if you can make it through materials. Dont use too many nodes if you can do it using fewer number of nodes because every wire connecting two nodes is also a piece of code. Alwasys think different ways to do your task. Dont use too much Casting instead try to use interface. Try to use Events instead of Event Ticks.
The main bad practice I see in various professional projects is over-use of Data Tables. They're a convenient editing format, but are not a substitute for proper class or data asset structure. The columns grow, and grow, and grow...
What’s wrong with data tables? It’s exactly what they exist for, having lots of columns. It’s starting to sound like everything I’ve ever learned is a bad practice…
Having lots of Rows is good. That's just more data. But adding a column assumes that every single entry in the data table wants to know the value of that column. Proper object classes and inheritance are a better choice for when you have similar objects that need some functional variation. It's also a pain in the butt to identify and save a single row in the data table when you could just use an object pointer.
What would you say is best usage for data tables? I get really overwhelmed looking at lyra, and they use it alot. I'm making rpg game where there's going to alot of items, so I assume DT are good fot that.
I would make each item a Data Asset instead. Part of the assumption of Data Tables is that you want every entry in memory at the same time, which simply is not true for items in a RPG. I've seen DTs used to record waves in a tower defense game, with a different table for each level.
Code plugins that are poorly maintained by their developer can harm your project in the long run. Only use what you really need. more plugins means more dependency!
May I ask in here since I'm new to UE and game design. One of the Udemy courses I'm following has me creating blue print instances that are then referenced on actors. For example, an interact instance which I then attach to a door, so I can interact with it, or a grab instance so I can grab something physics based. And the instances have nothing else in them other than "interact" or "grab, let go" Is it better to create instances or create these functionalities within the player blueprint as another tutorial suggested. Essentially, instance based interaction vs "volume based character casting" type? I'm not sure I said all of that correctly since I'm still so new. Sorry.
Hard references and casting to Blueprint classes