top of page
gculloton

Organizing UE4 Blueprints

Blueprint can be… frustrating. But it can be slightly less frustrating if you take the time to organize it neatly and logically. It really doesn’t take that long and makes it much easier for everyone to understand what your Blueprint is doing.

For the unfamiliar, Blueprint is Unreal’s visual scripting system. It provides non-programmers with a method of scripting gameplay elements with a variety of dang-and-drop nodes. Used properly, it provides you and your team the ability to visualize mechanics and variables operating behind the scenes.

More often than not, though, Blueprints get pretty unruly. All those nodes crisscrossing over each other can be difficult to parse, defeating the purpose of using a visual scripting language in the first place. You have to learn how to keep your Blueprints organize, otherwise you’ll end up with your fellow devs wanting to throttle you.

So, today I’ve got a tip involving the Select node. You can place one by right clicking and typing Select.

Consider this example scenario: When damage is dealt, you want to play a different sound based on the Damage Type.

In the blueprint event where we want to implement this logic, we are given the damage type as an enum, so we need to use that to decide which sound to play. One way you could do this would be to use a Switch, like so:

This is pretty straightforward, but we’ve got 3 duplicate nodes on the right that only differ in one way: which sound is being played. Right now, it’s not too messy, thanks to the reroute nodes, but we do have some crossing lines, which would be nice to avoid. And what if we add another damage type? Then we have to place another Play Sound node and hook it up to everything. And after we add another 10 or so damage types, we’re going to have quite the spaghetti mess on our hands.

We can simplify this significantly by using a Select node instead of a Switch. A Select node is similar to a Switch in that it behaves differently based on the input, but instead of choosing between which exec pin to execute, it chooses which input pin to pass through to the return pin.

Here’s the same event as above, but implemented with a Select node instead:

We no longer have any crossing lines, and we’ve reduced the number of duplicate nodes by a factor of 3.

The difference is even more dramatic when you have many possible values you’re switching or selecting between.

Here is an extreme example of just how bad it can be, especially when you don’t make effort to align nodes or make lines straight.

Don’t be this person. Please. For all our sakes.

20 views0 comments

Comments


bottom of page