Playmaker vs Unity's Visual Scripting? (Bolt)

[AtomicJoe]

Hi there!
I was wondering how Unity's Visual Scripting package compares to Playmaker.

Programming in C# isn't an issue for me but I need a visual scripting language for scene specific things that are not performance heavy. The kind of things that will not be reused on other scenes. (for that I make my own systems in C#)

So now I wonder what to use: Playmaker or Unity's integrated Visual Scripting (based on Bolt) ?

I bought and used Playmaker in the past and performance was great and was overall nice to use, but I had a nasty bug that corrupted all my global variables so I ditched it and made everything with C# since then instead.

Although that was a veeery long time ago (years), so I guess the bugs must have been resolved by now.

So, does Unity's Visual Scripting hold up against Playmaker?
Which is nicer to use and has the best performance?

What do you think?

[djaydino]

Hi.
For performance, Playmaker is definitely better that Bold and Unity's integrated Visual Scripting (since they are using mirroring).

Downside is when you don't have knowledge of C# , you are a bit limited to the existing actions and assets that provide custom actions for their asset.

There are some action like Get/Set Properties to access scripts but they also use mirroring.

Since you have knowledge of C# PM would be the best choice for you.

for the Global issue, i did not encounter a corrupted bug on my globals.
But i only use GameObjects and on the game objects i access the variables.

also i have custom scripts with access to scriptable objects to access 'globally'

[Christoph]

I was going to say the opposite, bolt might be more in your interest because you already know how to code. Bolt is basically c# but visually. Playmaker is not and more so a high level scripting tool with premade code that you use as actions.

If performance is of your concern then yes, djaydino might have a point there. I didn't know that bolt was all built on reflection. That's actually crazy. I just got rid of all set/get actions, as well as invoke actions in my base project to avoid reflection completely. Project is now much more snappier.

[AtomicJoe]

I have been checking Bolt and Flow Canvas.
Bolt aka Unity's Visual Scripting is actually a dead end right now: it's a slow garbage generator that will be overhauled for its next version. How and when, nobody knows.
The fun part is that Bolt v2 was already well in development and it fixed all this issues, but the Unity team decided to just stick with v1 for the time being.
So, that's a nope for Bolt.

Flow Canvas is much like Bolt but better.
It's not a garbage generator but performance is not great, as it is based on reflections and is an interpreted language in the end. But if you have to choose between Unity's Bolt and Flow Canvas, Flow Canvas wins easily.

But the thing about Bolt and Flow Canvas is that it's just exactly as programming in C# but with visual boxes.
I don't get the appeal of that. I mean, it's much more efficient to just code in C# instead of building gigantic visual charts that end up being a huge pile of spaghetti in the end.
And all of this to have a slower code.

In my opinion, PlayMaker is better because it's much more streamlined and because you can do things you can't easily do in actual code, like finite state machines.
Plus it's fast and very easy to use.
So, for me, it's clear that of all the visual languages for Unity, PlayMaker is really the only option.
But I was so off-put by my experience with all the global variables getting corrupted and blowing up weeks of work, that I'm not really sure to go back.

In the end, I think I'll just stick to good old C# scripts and I'll just connect everything together with events.

[Christoph]

Yeah, if you are good with C# I don't see much reason to go with any visual scripting tool tbh.

Either way, always use version control so if something goes sideways like the global variables then you can go back easily.

[AtomicJoe]

Yeah, I do use a private GIT repo now although Windows's File History has been faster and more useful than GIT for small things up until now. (GIT is a pain in the ass to manage, even with GITEA)

About the reason to use a visual script if you know how to program in C#, there are legitimate reasons for that:

When you want to do small scripts for specific scenes, things that you will not be reusing and are tethered to the scene, it's not practical to write a C# script for that because it will grow your code base unnecessarily, slow down the overall compilation and it quickly becomes a mess of little scripts that you don't even know what they were wrote for.

For example, say you are making a point and click game and you want things to happen when the player interacts with some NPCs on a given screen.
It's the kind of thing that is perfect to do with a visual script, because it gets tethered to the scene, doesn't grow your code base (it's an asset that only gets loaded when the scene gets loaded) and all its references are local to the scene.

With code programming, everything you code is on another level of abstraction.
With visual scripting, things are managed and referenced locally.

Also, finite state machines are super useful for this kind of uses. While regular code is super cumbersome to use like that.

[djaydino]

Hi.
If you are good with coding playmaker just becomes more powerful actually.
And its much faster to do certain thing like enemy AI for example
especially if you need to test and change behaviors.