Hi,
User Friendly is difficult to assess if you haven't actually used the assets. PlayMaker is going to get the job done far quicker than any other visual scripting for a very good reason, it is not a visual scripting tool ! ... 
There is a huge misunderstanding with this, PlayMaker is first and foremost a Finite State Machine, and the thinking process is totally different than scripting ( visual or not), so with PlayMaker you never take a line of code and turn it visual as such, you need to understand what it does and think about how to do it from a finite State Machine point of view, it's a paradigm shift in design patterns.
The visual aspect comes from wiring together the states and Finite State Machines components on each GameObjects. That's all.
Also, PlayMaker actions are not just wrappers for each Unity Api function, or property, it provides a lot more and as such makes production a lot faster as a result, typically, to move an object, you are presented with a lot of options, all combined intuitively in one action.
It all comes down to testing them solution for real, Unfortunatly it means purchasing it, hopefully one day, PlayMaker will be offering a trial version.
Bolt will likely resonnate big in Unity Community, it is indeed very well executed, they currently are both the top grossing asset, which tells a lot about the need for Visual Scripting inside the Unity community. So here it will really be a question of feeling, I think both are totally viable solution, but as Kurt mentionned, PlayMaker is battle tested and has been around for 6 years now, HutongGames is also aggressivly investing back your money into support to make sure you are not left on your own for learning. Basically, PlayMaker is here to stay, new tools come and go, some make it, some simply fade off after a year or two. It doesn't look like bolt is going that way tho, proper effort seem to go for this tool and it's good.
The other thing to be aware of is that Unity is likely going to come up one way or the other with its own visual scripting, and I know why they haven't committed yet, because they are facing a very difficult choice:
either you use an all around solution like Bolt and Kismet ( visual scripting for unReal Engine), but you rely on either code reflection which is bad for perfs or generated code, which sucks and also has perfs impact and limitations, or you go the PlayMaker way, where each api is wrapped around a regular script, and you leave the visual aspect for handling the high level communication between these actions. The downside is that you need to constantly support new api and new features for non coders ( PlayMaker has reflection in some actions to let you access new stuff, but it;'s generally not recommended, ask us for a custom action instead).
Remember that PlayMaker visual scripting tools is not just for non coders. I can do everything by code, yet I use PlayMaker for 100% of my personal project and client's project, because I am faster with it then with pure scripting, I verify this everyday... It's quicker to write a custom action and reuse it over and over in various projects than writing the same lines of code many times and end up with duplicates of the same features in every projects of yours... PlayMaker helps with this tremendously.
Bottom Line, there is a chance Unity will come up with its own solution and its likely to look more like Bolt than Unity, because it's less risky for the market and a direct competitor for Kismet. PlayMaker is on a league of its own.
PlayMaker helps both world, you are non coder, fine, you are a code fine... with bolt, I don't see any coder getting into this because it's a one to one relation with regular scripting. PlayMaker brings on the table far more. I was at Unite last month, and the remarkable feedback that we got was that many developers would just stop by and thank PlayMaker for having helped us make it in the industry, they started without coding experience, then slowly started getting into scripting because it's not that hard and you start by writing simple custom actions, and after a while, you end up using PlayMaker and scripting combined and you litteraly reach the sweat spot, being totally empowered to do anything you want with Unity: fast and fun.
There is also the Ecosystem browser, which is a convenient In Editor browser for custom actions hosted online on various github repositories, giving you access to thousands of custom actions, samples and packages.
Bye,
Jean
Hi!
That's a hot topic I had with some friends and workers. Playmaker is an insanely good tool. It's a god send.
Now, in my opinion, Playmaker is definitely unique but to me it still is a VST. Just one of a kind, a cleverly disguised one.
We talked about that a lot and even I had to read many versus threads to get the hang out of PM before going into it.
A Playmaker dev uses actions that can be dragged into the graph view and they behave like function blocks. However the trick is that the block is in fact a state, yes, and can host more actions, contrary to a VST's block which will not.
Depending on one's needs for clarity, one may add more or less actions within a single state. However, a VST can easily emulate the finite state machine idea by grouping such blocks, which mimics the way PM works.
PM's actions are fairly rich and save time by avoiding having to build "methods" one block at a time, although this would logically be solved in a VST by providing plenty of templates for, say, translation, rotation, zoom, typing strings, collision tests, etc., alongside the initial list of function blocks.
In PM, states really are easily handled groups within which a user doesn't have to do the circuiting.
Although a VST tends to natively have an autoconvert ability, one that was only added recently in Playmaker (1.9).
A VST will also make vars easily read straight from the graph, while in PM it requires going in the graph view inspector, which is slower, or expand the FSM component on the game object, which thanks to Unity's way of collapsing and expanding components, really becomes a chore.
I suppose that something like expandable floating windows inside the graph view, ontop the states' visual layer on Z but next to them on X and Y, would partially remedy this. It may need to be independent of the debug option too...
The inputs and outputs of FsmVars are not visually represented by links that enter and exit states in PM; one doesn't need to link input and output nodes. It is both a strength and a weakness of PM. It's faster somehow but adds a layer of occultism (lol).
Also, a VST "script" is a more complicated "circuit board" than in Playmaker because PM allows only one path at a time within a FSM whereas a VST will allow multiples flows within a single graph. This adds lots of clarity if one cares about state vision but it also means one has to create multiple FSMs on a single object running in parallel, which makes the reading of the whole thing quite complicated if these FSMs have to exchange values and keep an eye on each other and, for example, wait for another FSM to do X before continuing.
And Unity isn't really designed and built to have multiple copies of the same type of component on a single object so PM somehow has to circumvent that and creating one game object, child or not, per FSM isn't exactly the most elegant thing to do either; nor does it solve the problem of lack of clarity of communication between FSMs.
I wonder if another new window function that would be more VST-ish should be introduced to Playmaker, maybe. One that would precisely allow the user to monitor several FSMs at once and by simple sight alone, if not all of them; that would be some kind of meta-FSM which would add a veneer of VST clarity and fluidify.
Because PM already acts like a meta-VST in the way states act like groups, but oddly enough fails short of offering a clean way to monitor multiple flows at once between several FSMs that are inter-dependent.
As for the topic per se, Bolt has a cute and coloured interface. It's pretty and full of shiny lights, very well detailed and rather robust for what it does, but it's way too young atm to provide a strong alternative to PM. Although with the advertising it gets from Unity, I'm sure it won't take more than two years for the most important publishing add-ons to flock to Bolt too (iOS, Android, Switch, VR, AR, major advertising SDKs, etc.).
There's more backing behind Bolt than there was behind uScript (which was promising) or that even more obscure Antares tool. Unity has also matured a lot in their PR so this will help too.
One thing that needs to be compared too is the final weight of the build. PM is a bit fat on that side of things, I don't know how much space Bolt takes inside a build, where it still matters on mobiles where the market can only expand in low tier economical countries now, places with cheap and midrange devices relying on not so advanced GSM networks, where sometimes even owning a credit card isn't a given.
It's also totally true that PM really encourages you to give a look at simple coding first; it lowers the fear effect of entering it but you can still bypass the coding entirely as Ecosystem gets bigger and bigger and the community content is quite huge now. It's really that cool and yes, whilst coders will just scoff at VS, they tend to be easily tempted to integrate PM into some projects.
Talking about MONEY ------ I wouldn't mind if for the next very big and clean update, like Playmaker 2, said update would be paid (at a reduced price for owners of PM).
You provide all your updates for free and that's great but it's also a bit worrying when wondering if this business model solely based on the initial paywall works on the long term.
