Extending Bolt: Which method to use, and why Custom Units might not be the answer.

Reality.Stop() 3 years ago updated by Lazlo Bonin (Lead Developer) 3 years ago 1

Hopefully, this clears up any questions in your mind about what Custom Units are, and what you might be missing by not using them. It's a dive into what each of the three extension techniques are capable of, and what factors go into deciding which to use.

In the video, I discuss a capability chart in great detail.  That chart is as follows

This might look different from what is in the video.  That's fine!  Bolt changes, we learn new tricks, and I always reserve the right to be wrong, too.  In fact, if you scroll down to the comments below, I'm sure there's plenty more discussion on the topic as well.

Bolt Version:
Unity Version:
Scripting Backend:
.NET Version (API Compatibility Level):

This is a really insightful video even for me, thank you for taking the time to reverse engineer Bolt, figure it out, and make a tutorial out of it.

I will listen to it again when planning future design decisions in Bolt, but my initial impression is this:

  • There are two ways to make the process of creating new units simpler: either giving more power to Super Units and Reflected Units, or making the creation of Custom Units simpler.
  • Because Bolt is a visual scripting tool, I want to minimize the amount of code users ever have to type.
  • Therefore, I'd go with the first approach, which means:
    • Supporting what you call "Advanced C#" in Super Units, especially LINQ and Delegates
    • Allowing for truly Custom Events in Super Units with Custom Event Definitions
    • Supporting C# events in Reflected Units out of the box
    • Adding more customization options to Super Units to get more "native Bolt feel", including:
    • Improving the UI of default values for reflected units so that they can be entirely ignored