One other organizational tip. For a function like Register Actor, where you connect a long thread from the start node, you can instead call "Get [Function Parameter]" and it will appear as a local variable get node inside that function. Very useful for avoiding annoying branching and reroute nodes
Self-taught hobbyist, one of the best topics i've run into was design patterns and UML charts... makes me wonder what else i've missed not getting a CS degree when i probably had a chance at one... I also think it's a valuable skill being able to see ahead and write gameplay hooks for future implementation... Anyway, i'm 4 major bugs off showing my game to friends and family... all from scratch too! I legitimately could get a job as a web dev with all the UMG and event logic i've had to write over the last few months LOL Also could be wrong, but I think that the sequence fires events whether or not the code has finished executing or not, so if your final sequence is a return, there's no guarantee it will finish executing before hitting the return
I have to add that people need to learn design patterns. Coupling vs decoupling. Dependency injection. Has a vs. is a relationships. Expensive lookups vs. optimized retrieval data structures.
I've been experimenting with UE4 for the past few days, and I'm curious about your opinion on collapsing nodes into a Collapsed Graph rather than putting them in their own function. A specific case for me is anytime I want to update the stored location of the mouse, I have to call both "Get Mouse Position on Viewport" and "Set Start Mouse Position" so I put those two nodes into a collapsed "Update Mouse Position" graph so it wouldn't clutter. Obviously this could just be a function, but was curious if you had any preference to one or the other.
I think collapsed graphs are fantastic. I wasn't really aware of how easy they were until you mentioned them. They are absolutely a viable replacement for functions in a lot of the situations I've mentioned! As usual, Unreal has a really easy way to do things... if you can find it. :D
The real benefit to collapsed graphs is you can still call things like delays and timelines, and have multiple output execution pins. Functions are also more performance because of compiler optimizations, so you should use Always a function if possible, a macro if it needs multiple execution output pins and is going to be reused, or collapsed graph if it's a one off bit of code that needs delays/timelines/output pins etc
It seems to me like this blueprint system is not the right thing for complex systems. I assume that was made with simple things in mind, like control objects that do just a few things.
@@CraigPerko Sure, but some games are much simpler than others. Your question is way more interesting than I thought at first. Perhaps code just looks simpler to me because I'm used to it. But to me it is easier to keep thing organized by using scriptable objects for data, pure c# classes for small local functions. And Mono behaviours for managers that organize the smaller bits. Or just an entity component system. Then again, that works for me, might be that this would be more complicated to others. I guess what scares me with those visual scripting systems is all the surrounding stuff. All the frames and backgrounds, to me that seems to bloat things up.
The UI definitely needs work in order to really make blueprint-style programming work as well for complex projects as code. But choosing between C++ and blueprints? Most humans would prefer blueprints. :D
@@CraigPerko Right, I forgot that UE is using C++. I don't know much about it since I mostly used C# and Java. So, I guess for now, I just assume you have your reasons to prefer the visual option.
