Blueprint tricks

I set up the Graph Editors group in the Editor Preferences so forward splines are linear and only backward ones bend. I found that straight lines make the visuals less busy which helps parsing. (I’m not a big fan of the engine’s node editor UI in general. In this thread you can see some UI changes I proposed, including the latest mockup.)

Spline setup  Blueprint tricks BPTricks01 300x161
Breaking from a loop  Blueprint tricks BPTricks02 300x78

I often forgot to handle all possible outputs of forking nodes which lead to sneaky semantic errors so I got into the habit of never leaving execution outputs unplugged. If nothing else a single reroute node is connected to it.

Marking handled execution outputs  Blueprint tricks BPTricks03 300x115

Wires are merged back as soon as possible to minimize the length of lines on screen. This arrangement also makes the handling of different cases look like a single unit, separate from following steps.

Branch merging  Blueprint tricks BPTricks04 300x69

Loops have the body above the loop node and what follows bellow, to clearly separate the two.

Loop body separation  Blueprint tricks BPTricks10 300x85

When I started using UE4 I used comment boxes extensively to visually group nodes and describe high level functionality. After a while however I realized that it took too much time to adjust all the comment boxes to keep up with the changes of my constantly evolving node trees. Eventually I ended up relying on compound nodes for structure: the mechanics are arranged into multiple levels of compound nodes where each level has the minimal amount of nodes. If a step needs more than 4 or 5 nodes than it gets collapsed into a compound node.


This kind of partitioning keeps the node hierarchy from becoming visually overwhelming: The developer can move from high level overview to deep into the belly of a particular implementation in distinct steps and see only a single level. This prevents getting distracted by lower level details and also makes zeroing in on a bug faster.


On the right is part of the BaseDrone class’s main Event Graph. While this is one of the most complex classes in Drone Alone the node tree remains reasonably simple. It can be read like text thanks to the descriptive function, variable and compound node names.

Drone class high level node tree  Blueprint tricks BPTricks05 300x177

My Debug Print node prints some text on screen and to the log in “Actor name: String” format. If nothing is linked to the Actor input then the owner actor’s name is used. When the game is not in “Development mode” (set by a bool variable in Game State) then these messages are suppressed.

The Debug Print node  Blueprint tricks BPTricks06 300x144

There is similar node called Print Error: If Critical is true then it will print the error to both the screen and the log, regardless of “Development mode“. If false it will only show up in the log.

The Print Error node  Blueprint tricks BPTricks07 300x155

The (totally empty) ToDo macro marks places where I… well… need to do something. It was made back in the early days of the engine where searching in comments was unreliable but macro names were handled properly. Maybe it’s not necessary today but I like how it looks a bit different form other nodes and thus helps to distinguish todo comments from the rest.

The ToDo node  Blueprint tricks BPTricks08 300x125

A related node is the Hack node. Same idea as above except it helps to locate areas where only duct tape and bubblegum keeps things together.

The Hack node  Blueprint tricks BPTricks09 300x231

In the two years of the development a couple of times I ran into blueprint related engine bugs where certain classes became unloadable. While I had daily cloud backups, losing half a day of work was still stinging. The backup software I use, Cloudberry Backup, has local realtime backup capabilities so after a while I set it up to store the last 100 versions of every blueprint locally. While working with blueprints I saved often without compiling to have the backups closely reflect my progression. When a BP crashed the editor or became unusable in some other way I could start walking back on the saved versions to find the last working one.

I wanted a time of day change but pure dynamic lighting didn’t look good enough so I decided to create 4 statically lit levels instead. The morning, noon, afternoon and evening maps are exact copies of each other and only contain static actors. These levels are streamed by the persistent one where all the dynamic actors reside. My physics related classes (extending Actor, SkeletalMeshActor and DestructibleActor) implement one interface through which (among other things) they can be frozen in place during a time-of-day switch: All actors implementing PhysicsDriven_interface are frozen, current level is unloaded, new level is loaded, actors are thawed.

Trace weapons in Drone Alone can shoot through surfaces and certain actors. A 100m long trace is created and the information about all the hits are processed. If a surface has a certain physical material (glass, cloth, cardboard, etc) then the bullet’s power doesn’t decrease. If the trace hit an actor which implemented the Penetrable_interface then the damaged actor is given the current power of the bullet: damage is handled and the power is decreased by an amount set in the actor instance. When the bullet’s power reaches 0 then the processing of hits stops.

Notice: ob_end_flush(): failed to send buffer of zlib output compression (1) in /home/zoltanec/public_html/pages/wp-includes/functions.php on line 4552

Notice: ob_end_flush(): failed to send buffer of zlib output compression (1) in /home/zoltanec/public_html/pages/wp-includes/functions.php on line 4552