Organizing your Project with Bolt – Unity3D Visual Scripting

This entry is part of a series of tips I am creating as I make my game.

You can use Bolt for free by downloading it from the Asset Store.

Bolt is a visual scripting tool that can be used in place of C# scripting, and is especially helpful when you are a visual learner like me. In this series of tutorials, I’ll be sharing some of the insight I’ve gained while working with the tool!

Organization

When using Bolt, there’s two organizational things to consider (in my humble opinion): the purpose of your current ‘script’ (or Flow / State Machine as Bolt calls it), and how it’s organized in Unity3D so that when you return later you can understand what you made.

The way I keep things organized is by enforcing a ‘Single purpose’ per Flow/ State machine. When I add this new object to my hierarchy, I use the hierarchy itself and empty game objects (with adjusted names) to have the code speak for itself. Below is an example of ingame objects that hold Bolt Flow/State machines. Each one is named for its purpose, and the hierarchy determines who is dependent on whom.

As you can see, if I needed to know what Bolt Flow/State Machines were affecting the Animations of this character, I could easily restrict my search and know where to look. Another example would be if I wanted to add a new constant value to be updated for this characters Animations; I don’t need to refer to documentation to know where to go to do that.

Use Groups and Colors!

Organization in general will help you immensely the moment your project starts to get big, and Bolt has tools for organizing inside your Flow Machines (the equivalent of a C# script). You can do something called Grouping (The black box around the different tasks):

One thing I like to do is color the boxes based on their purpose. For example, the part of my graph that performs error checking/logging:

If you are looking for more options for colors, check out the Rainbow Folders asset!

Keep Each Flow Graph to a Single Purpose

It’s tempting to put an entire feature into a single Flow Graph, I know. Making more than one Flow Graph for something like ‘Detecting Enemies’ seems like it would be a chore, because then you would have to deal with I/O between the Flow Graphs. DON’T MAKE YOUR GRAPHS MONOLITHIC. I can’t say this enough, you have to separate things out. This is because the entire organization scheme I described above collapses if you overcomplicate individual Flow Graphs.

Here’s an example of a Flow Graph that is much too complex:

Imagine coming back to this after six months and you’ve long forgotten how everything works. You would have to dig through this graph, watch it operate, and dig through the variables it’s using. Even worse, how do you name the GameObject that’s hosting this monstrosity? The name wouldn’t mean anything because there’s a lot going on here; it probably represents an entire feature.

Instead, break this up into more manageable chunks like this:

There’s a clear left-to-right flow. From a glance, you can see where it starts and where it ends. The purpose is probably simple enough that the name of the GameObject it’s attached to will be more descriptive of what this actually does, and it’s position in the hierarchy will make sense.

Describe the Purpose and Reference Dependencies in the Flow/State Machine Description

As the above suggests, you should do this:

Use Dictionaries!

I can’t overstate how useful dictionaries can be. They are a little more complex to work with, but wonderful tools for organization. I can even prove it with an image:

In the end, this is only one of many suggestions so I encourage you to take the time to investigate what works for you. Feel free to comment below if this helped or you have suggestions!