Peter Newton takes up the mantle for our second community led training stream. He’ll explain the Single Responsibility Principle, why it’s useful, and how to apply it to your own Blueprint projects!
Please feel free to post questions here prior to the stream and folks from Epic will join the live chat to help field your questions during the stream.
I’m excited for everyone to join me! My plan is for everyone to be able to take away skills which they can use now to help manage and maintain their Blueprint code. This has less to do with naming conventions, but now how you layout your nodes.
Notice that instead of showing all of the high-level functions, which tell us nothing other than something is happening.
Once changed, the Blueprint Visual Scripting code itself tells us what is happening. We don’t need comment nodes, although they can help.
This loosely follows the principles called Single Responsibility Principles. It’s true definition applies to classes and modules, but I am applying it to functions. Curly’s Law is the principle used for functions. But the take away is that your code is itself is understandable.
We don’t need documentation to understand the original authors intent. So I want to bring over a lot of principles which already exist, and that I have no part in creating. I am just bringing it to you, so that you all can benefit as I do from the benefits of SRP Principles, and the others like it.
If you’re interested in SRP and SOLID. Here are some awesome articles about it. SOLID on Wikipedia
In theory, it would be no different. But I could take the time to provide examples of how I would it. But it’s truly subjective, the end goal is, can you mentally follow your code? If you cannot without really trying, then you’ve failed.
When going back to code that is really old. It shouldn’t be impossible to understand. Which is the case if you don’t prepare. You should just have to take the time to step through all of your code. Most of the time, people don’t have the patient to collapse your code into smaller reusable code. Such as myself once upon a time. But, when you take the time to break everything into smaller segments and reuse them as necessary. You actually find that code is generally much easier to recall.
First things first.
I will be watching this for your incredible sense of humor.
Your skills, and tutorials helped teach me a lot, but your corny jokes, and your gigglesALWAYS keep my attention.
Thanks for everything you do.
I’ve always wondered what the L stood for. I guess it does have a better ring to it than just Peter Newton. Gotta have the L in there.
Good that there’s a stream that show that Blueprint shares the benefits of good coding practices with other languages. Always suspected that those who didn’t get into Blueprints never really learned to apply common coding style principles to their visual scripting.
Looking at the screenshot, it would be great to include a brief explanation when to use Macros, Functions and Events, because all the first google links only say what they are and what you can do with them, but fail to explain when to use which one. <3
I could do a stream just about that! I am currently writing a peer reviewed book on Blueprints with a few of the Unreal Engine Community experts. So we’re going to talk a lot about use of Macros, Functions, and Events/Delegates in the book. BUT, I can definitely talk to Epic about doing another stream on that topic.
You bring up a lot of excellent points. These are all extensions of this conversations. It’s not something that I could just explain in one breath, of else it would be common practice.
What I hope is by introducing a wave of different topics which I think are foundational to understanding where to place logic.
Think of this way, if you take the time to effectively break your code into pieces. It’s much easier to identify where it can be improved, but also just as easy to understand where to interject subroutines to expose parts of the functionality in graceful way. Instead of constantly making hacks when you need a particular variable.
The problem is if you don’t try to organize your code with any sort of patterns or principles, it’s nearly impossible to effectively improve your code. Bugs are harder to see, repetition is harder to see, and when you come back in 2-6 months. Can you remember what you where doing?
So all very good points, I’ll continue to bring up over the streams.
I for myself try to use as many Interfaces as possible.
I try to make an oldschool Action RPG where the Game stops when someone casts a spell for example.
Everything is handled by the GameState. And to access the GameState, I use Interface Messages.
I created multiple Interfaces for the Combat. for example “GetBasePhysicalDamage”. For Characters, this takes the Weapon and Status in Account, while it is a predefined number for enemies.
For hit detection i simply need to call getBasePhysicalDamage without caring about the actual type. This is why I like Interface Messages so much.
All they lack is Replication. At the moment you need to implement the Interface Event and then call a separate Event with your desired Replication Settings.