Classes are a massive redesign that group variables and graphs together under a single entity for object-oriented programming, a.k.a. encapsulation.

Classes will replace:

• Dynamic Variables
• Machines
• Custom Events

A class in Bolt is a scriptable object asset created from the project window.

It defines:

• Its title, summary, icon, category
• Its scope (object, scene or global)
• Zero or more graphs, flow or state
• Zero or more variables, with a given name, type and default value
• Zero or more events, with configurable parameters

A class gets attached to a game object with a Class Component, which will run the asset, much in the same way that a Machine component currently runs a Macro asset.

The Problem

The Bolt 1 variable and machine systems have many flaws:

• Logic / Data Disconnect: Dynamic variables (data) are not linked to the graphs and machines (logic), meaning you can’t require a variable you know that logic will need (for example, a movement graph cannot guarantee the object will have a speed variable). Moreover, there is no easy way of creating all required variables for a recursive graph tree in the inspector, and even if there was, there would be no easy way to keep it in sync as the graph changes.
• Weak References: Renaming a dynamic variable is tedious, because you have to manually change the name in every text field everywhere across all graphs that use it.
• Weak Typing: The type of a dynamic variable is never reflected inside the graph, because we can’t guarantee their type early on. We can’t even guarantee it will exist!
• Boxing: Setting the value of a dynamic variable would always cause boxing, even in the generated runtime, because the underlying storage for variable values was object typed
• Single-Use: If you used the same macro on more than one objects, you would have to repeat the process of creating the required variables on every object, wasting lots of precious development time.