A quick word on Blueprint style

Development Programming & Scripting Blueprint
1

Let’s say we’re creating an actor with a mesh component that’s attached to a root scene component. We’ll expose three float variables that allow the location and scale of the mesh to be adjusted relative to the root: DistanceFromView, LengthScale, and RadialScale:


In the Construction Script, we want to set the relative location and scale of the mesh component based on these values. The work needed to accomplish that is trivial, but there’s a right way and a wrong way to do it, even with the exact same nodes.

Let’s look at the wrong way:

http://awforsythe.com/i/bpstyle_reticle_graph_bad_t.jpg

We’re doing what was asked for, but it’s hard to see what’s going on. Look how much space we’re using for two function calls. Look how far our eye has to travel to figure out what arguments are being passed in. Notice how everything is encased in a comment block that doesn’t give us any new information: we can tell very easily from the two function calls that we’re setting the location and scale, thank you very much.

If you were implementing the same actor in C++, you surely wouldn’t write code like this:


Any programmer worth their salt will tell you that this code is horrible! Inexcusable! Ugly as sin! It produces the result we asked for, but that’s not the only thing it needs to do. It also needs to be readable and maintainable. Another programmer should be able to come along and understand what this code does at a glance.

Here’s how this simple example would look, in C++, with good style:


And here’s how it should look in Blueprints:

889×340 86.9 KB

We can see the execution flow, straight across. We can see that there are two function calls, and we can see the arguments that are being passed to each function. There’s no guesswork. We’ve gone from a haphazard arrangement to one that reflects the intention and behavior of our code. Just like proper use of whitespace in C++ makes code easier to read and helps us group related statements, proper use of the 2D space given to us in a Blueprint gives us the same benefits.

So please, pay attention to style when creating Blueprints. Keep things orderly and organized and readable. You’ll end up producing better code for it.

2

Well, you are only focusing on the execution workflow, not the overall execution AND informational workflow. Ignoring just the pure OCD factor, there are psychological and physiological reasons why your “wrong way” is the proper way to structure blueprints. Mainly, it is easier to process linearly presented information when there are no cross lines and when the inputs/outputs are spacially located close to each other. Having said that, I would tighten up the positions of the inputs in the first example.

I understand that you are trying to equate this to C++ programming, but visual programming cannot be treated the same way. There are many benefits doing one or the other and they should be embraced rather than trying to force both to work the same way.

3

Interesting design choice. I’ll probably do this for nodes that don’t need additional calculation/nodes (like get var), and stick to horizontal node placement for more complex situations.

4

Agreed, when I see the coding newbies that don’t nest their if statements, I wonder how they can live to see their code, same goes with the examples you gave.

5

Agreed with mairsil. Your ‘wrong way’ example is fairly exaggerated and could be cleaned up while keeping the horizontal layout. I feel like you’re comparing apples with oranges here, as mairsil said visual programming is different from writing code.

Personally, I do not like the crossed wires in your 2nd example. It looks cramped, and i could see it being difficult to read clearly if there were more than just a few inputs.

When it comes to visual programming I think people are going to do what feels more natural and easiest to read for them. I agree code needs to be readable, but whether or not your ‘improvement’ is more readable than the ‘wrong’ way is, it seems to be, largely subjective.

6

Agreed, the crossed wires bug me as well, I personally would just keep the variables to the left of the inputs.

7

This seems more like personal preference than a “right vs. wrong” way of doing Visual Scripting. I actually prefer the linear approach of the first example over the second; for obvious reasons posted by others about crossed wires. Otherwise, why would Epic have provided the “reroute” node? :slight_smile:

8

Well, please try this when you have to set calculated values into a 20+ members structure element and let’s see how readable it is.
In long run productivity with blueprints goes down as you spend more time on arranging nodes than doing actual development, beautification in code is done so much faster and cleaner. Or cases when you have to build functions just to have less spaghetti instead of using them for reusable code. Or functions with 10+ inputs for which you have to make a bunch of local variables so that you don’t drag their connectors across the whole graph. Rant over.

9

I usually do your second “correct” example with Branch nodes having the simple condition being “attached” to the bottom of the node. I also do your “incorrect” example for most of the other nodes. I also use Reroutes and Comment Boxes. At times both, so the execution lines always enter and depart the Comment Box in the same position (placing a Reroute node at the left and right sides of the Comment Box).

That’s when I’m cleaning things up a bit. When I am coding it, things come out in a general left-to-right fashion. Lines going here and there.

10

If you bunch thing up too much in blueprints they all overlap each other and look very unclear when you zoom out a little and the nodes expand. I don’t think there is any right way or wrong way, I personally find that a lot of good practice in other programming styles applied to node based scripting actually defeat the purpose of visual scripting and make them difficult to follow for no real gain. That’s just my 2 bob though.

11

Yep I think if you just lined up your actual variables in the first example instead of putting them a mile below the nodes then you would have much cleaner than stuffing them all underneath and crossing the streams. Crossing the streams causes bad things to happen.

12

“Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light.”