If you're advanced you probably already know a few of these tips so make sure to use the timestamps to skip to the sections you think might be helpful for you and share this video with your friends that have dirty blueprints!
A good collection of tips. One note on the section about collapsed nodes: You don't actually lose access to local variables when collapsing nodes inside a function. It's true that any of the local variables included in the collapsed selection break, but this appears to be a bug of some sort. If you place a fresh "Get Variable" inside the collapsed node it will work correctly. This allows you to skip having to pass them in like parameters.
One of the very useful features for me (and i learned it too late xd) is interfaces. It's basically a way to connect blueprints without having them related. For example, if we wanted to check if an actor is available for interaction, we could cast to it, get the ref, check the variable. Sure, but if we had 10 different, unrelated blueprints (but still had the interaction part in common we'd like to check), we'd have to make 10 cast nodes, check if it's the right actor and then get the variable. If you add more bps it will get pretty messy. Instead you just implement an interface (and set it up), and then you just send a message. If it implements that interface, it will answer.
Nice list. These are all great tips. I'd add that Alt and Ctrl let you unplug and hold wires or just unplug them. I didn't figure this out until years deep.
I agree with a bunch of these (in fact, I considered making a similar video, and decided to do a search first), but I would like to note that functions and collapsing aren't always better. I always encourage compression based programming, where you only move things to functions when you start re-using a piece of code. Having the full set of nodes in front of you lets you use the spatial parts of your brain, and when something is hidden in a function, you have to imagine it. Sometimes that trade-off is worth it, sometimes it's not.
"I always encourage compression based programming, where you only move things to functions when you start re-using a piece of code" I do this as well, but the down's side is that some of my blueprint functions are HUUUGE
One thing I don't see a lot of people talk about that often is that you can create multiple Event Graphs. Actor components are super common professionally but beyond that its super helpful to keep major parts of BP isolated on their own Event Graphs within a Actor BP or AC.
Thank you, I'm glad you liked it! With my current schedule I'm releasing one video every ~2 weeks and already go the next one lined up to come out December 22nd :)
Best move I ever made with Unreal was diving into C++. Now when I do use Blueprint node graphs for certain things, it's AMAZING how much cleaner they are. I anyone reading this is serious about Unreal development and hasn't picked it up yet, I can't recommend it enough. I won't say there's no additional learning curve, but if you can write code in Blueprint then you're entirely capable of writing code in C++ (at least as far as Unreal goes). Your node graphs will be cleaner, your games will run more efficiently, there are still things you'll be able to do that you can't do in Blueprint, and you'll generally just gain a much better understanding of how the engine works under the hood.
Good advice. But I would rather remove 7, 8 and 9. 7 - You create extra graph depth, which is superfluous. If you want, you can create "Tick graph" for example instead of collapsed nodes. 8 - Better not to even try to use any async logic in functions. At a minimum, using the timer only by event will create the same design throughout the project. 9 - The select node doesn't take just one input, it executes all the code on each input and then selects one of the results. It may cause trouble if every input is a complex pure function.
My brain for some reason wants to think that the computer has to process each reroute node, making the game slower at runtime. It's kinda funny now that I think about it
Step by step tutorial to solve world hunger. step 1: become a beginner to unreal engines bps again. step 2: make a procedurally generated backrooms game in bp. if you finished the tutorial you should have solved world hunger.
Helpful tips! Curious how do you add a pinned comment? Like @ 7:35 where it says "Move spawn location forwards a bit". Is this only available in Unreal Engine 5?
@@CobraCode it's also problematic for asynchronous operations (like calling an API), as one operation can "end" (reach the end of the call) before it actually resolves (usually by triggering a callback function). Basically, much trickier once you have callbacks.
Do you mean 'Set Timer by Function Name'? But anyway this video isn't really about optimization, but about making things more readable and easier to navigate. Even if something is slightly less optimized, the improved readability and therefore faster workflow might be a worth wile trade off in many cases.
tip 2: Realize that even when you write c++ your code won't magically be clean and you still have to stick to certain principles to make it readable and re-usable tip 3: Realize that you will never be able to ship a game if you spend 80% of your time looking through documentation to see which headers you need to import and wait for your code to compile tip 4: Get frustrated and start working with Blueprints after all tip 5: Realize that c++ and blueprints were supposed to be used together anyway and complement each other tip 6: Come back to this video and learn how to clean up your blueprints
