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!


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.

Shared_Variables requires outputs from Detect_Allies_And_Enemies. Detect_Damage_To_Me relies on the weapons found by Get My Weapons. Animation serves as the category for all animation scripts. Each game object should serve a single purpose.

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):

You can also add text by clicking on the top left corner of a Group box.

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:

Don’t underestimate the power of colors when organizing your project!

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

You can find the Rainbow Folders asset here.

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:

What’s even happening here?!

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:

Okay, I can kind of follow along this time!

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:

I can just click on this Flow/State Machine and see what it does and what its dependencies are!

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:

Look how easy it is to specify both a weapon and the damage it can do. A dictionary can contain multiple weapons in this case, not just an Axe.

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!


  1. Hi, I was wondering whether it’s possible to use Bolt as well as C# files (using Visual Studio) in the same project (I’m a bit comfortable with some parts of C# code but would also like to explore visual scripting for more complicated things).

    Liked by 2 people

    1. You definitely can use them together! In fact, if you really wanted to you could have a C# script directly updating a variable used by a Bolt Flow machine / State machine (or vice versa, if the C# script was pulling variables instead of pushing). Bolt has an API that can be used in C# scripts:

      I describe something similar to that in my other post (it focuses on integrating Bolt & Behavior Designer using a C# script that’s located at the bottom of the post):

      Hope that helps!

      Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: