Playmaker Forum

Playmaker News => General Discussion => Topic started by: Jelvooo on November 08, 2017, 07:12:25 AM

Title: Why Playmaker and not Bolt
Post by: Jelvooo on November 08, 2017, 07:12:25 AM
Recently Bolt has came out, I want to buy Playmaker or Bolt. I really don't know what to choose. I like Bolt more because it is a lot more user friendly. But Playmaker has third party API's such as multiplayer and Bolt doesn't. Help me decide :P.
Title: Re: Why Playmaker and not Bolt
Post by: krmko on November 08, 2017, 09:28:26 AM
Longer in development, larger community, lots of actions for most popular 3rd party assets.
Title: Re: Why Playmaker and not Bolt
Post by: djaydino on November 08, 2017, 12:29:24 PM
Hi,
I actually learned c# thanks to playmaker!
When i started to use unity i had very VERY little knowledge of coding.
So i started to learn my self c#.
A few months later, frustrated that many things i could not get to work...i saw Playmaker on the asset store!
I bought it, watched some tutorials and then everything went quick.
Project only took weeks to do instead of months.
In that time there were not so much custom actions yet, so i started to look into the code how things worked.
A week later i started to make my own custom actions for the community.

Now There is a lovely addon called Ecosystem with Lots of custom actions, packages and samples. you can simple search what you need and get it in your project.

I have not use bolt, but i checked out their video and information.
For small projects in might be ok, but for bigger project definitely Playmaker.
Their comparison is a bit deceiving and inaccurate.

Maybe the starting learning phase is a bit harder than bolt, but i do not think that playmaker is less user friendly.

Playmakers forum is also very active and friendly which is a +
and easier to overview.

Playmaker has lots of user made tutorials.
And Playmaker is cheaper! (only like 5 bucks but still  :P )
Title: Re: Why Playmaker and not Bolt
Post by: jeanfabre on November 08, 2017, 11:50:07 PM
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


Title: Re: Why Playmaker and not Bolt
Post by: jeanfabre on November 08, 2017, 11:51:53 PM
Hi,

also, on Multi Player, you are right, we are actively supported Photon, and we have a close relationship with them to make sure all goes well with PlayMaker integration, so ping me if you have questions on multi player, I am the one in charge with the multi player support :)

 bye,

 Jean
Title: Re: Why Playmaker and not Bolt
Post by: shadowof047 on December 29, 2017, 12:22:27 PM
Having used both of them I can assure you of these facts :
1- Playmaker is ALOT more user-friendly once you get the hang of it .

2- Bolt is ALOT less user-friendly when you use it and not seeing it from afar !

3- what took me 30 second in playmaker to do , took me about 5 minuets to do in Bolt , because most actions in playmaker are a collection of code , but you should do everything in bolt yourself .

4-In bolt , there is this thing called "super Unit" which essentially mimics a function call, which you can assign input/output to . it substancially helps you not to repeat your code , which unfortunately playmaker cant do .

5-In bolt , there is saved variables , which makes process of saving very easy.

6-Fuzzy finder in Bolt is a MESS ! 50% of the time , even if you know the exact name of the node , it wont find it for you .  so you should navigate where it is manually which takes alot of time .

7-Bolt tries to introduce itself as blueprint for unity . Having used blueprint and kismet for many years , i say it is the farthest thing from blueprint in unreal.(sidenote : Blueprint is the undisputeable king of visual scripting)

8- i never understood what they mean by "Native Feel " !?

9- In Bolt , there is a window for variables , one for input/output.where the hell should i dock all that ?!
Title: Re: Why Playmaker and not Bolt
Post by: tcmeric on December 29, 2017, 08:36:14 PM
I only played with bolt shortly, but with bolt it is visual coding. Ie, it still feels like you need to code. You still need to understand unity API to know what you want to do. You are just puting together your code without writing words.

Playmaker is different. So far I have no desire to change to bolt.

Many playmaker actions are more like code snippets. They execute more than one line of code per state.

I also have learned how to code c# because of playmaker (although I am still a beginner). It doesnt take too much coding skill to integrate (most) third party assets into playmaker with your own playmaker actions. 9 times out of 10, its just figuring out which method to call, or which variable you want to set or get. That being said, its mostly optional. Many people here have made tons of games without learning c#, using playmaker.
Title: Re: Why Playmaker and not Bolt
Post by: verybinary on January 08, 2018, 01:12:18 AM
I, personally, have no intention of even trying bolt. Playmaker has done everything I've wanted it to, and how I've wanted to do it since Unity 3.(4?).
I've briefly looked at bolt, and I'm not impressed. It looks to me, similar to Unitys animation nodes(which I couldn't see easily working with a large project) Playmaker works perfectly with the way I think. I would have to learn how to think differently to try anything else, and no. With Playmaker, I can look at my "spaghetti" and know exactly how it does what it does. I recently opened one of my "first ever" incomplete projects. My FSM building has soooo matured, but I was never confused about what it did. Extremely inefficient, but I knew it worked, and I knew how it worked.
So yeah. I can't really say anything about bolt, but I'll say everything I can about Playmaker
Title: Re: Why Playmaker and not Bolt
Post by: jeanfabre on January 09, 2018, 03:47:13 AM
Hi,

 @tcmeric makes a very good point, PlayMaker is not a visual scripting as such, it is first and foremost a new way to think logic, Bolt is more a direct replacement of a code of line which really brings nothing on the table because indeed you need to learn conventional coding to understand Bolt.

 PlayMaker Action as indeed code snippets which allows to combine several features into one convenient interface for optimal usage and reusability, like lego blocks asn as such offers far more potential as is and even greater power when you start to combine both PlayMaker and Conventional coding. With Bolt, it would not bring any benefits.

 Bye,

 Jean
Title: Re: Why Playmaker and not Bolt
Post by: MostHated on March 10, 2018, 03:31:55 AM
Hey there, sorry to bring up an old thread but I stumbled across it while searching for something and wanted to ask about Multiplayer. I see you said it is well integrated with Photon, what if I am using uMMO2? What benefits does it offer in terms of multiplayer in general? I am not 100% sure what all Playmaker could do for me, but I am interested in finding out. I am making an RPG, what are some of the modules / things that Playmaker might be able to offer my game?
Title: Re: Why Playmaker and not Bolt
Post by: tcmeric on March 10, 2018, 05:04:06 AM
Playmaker is not a networking solution, but rather a coding solution.

Photon, uMMO are networking solutions. Even if you have Photon or uMMO, you still need to code your game in unity.

If you havent made any games before, I would suggest first trying to make a few test projects that  are single player first. You will first need to learn the fundamentals of playmaker or c# in order to make the actual game itself.
Title: Re: Why Playmaker and not Bolt
Post by: MostHated on March 10, 2018, 07:23:06 AM
I am aware, I said I currently use uMMO for my game (https://mosthated.itch.io/rpg), I know what it does. I was referring to a prior post that said "on Multi Player, you are right, we are actively supported Photon, and we have a close relationship with them to make sure all goes well with PlayMaker integration, so ping me if you have questions on multi player"

I was wondering what Playmaker offers that would warrant an integration. It integrates in what way, to accomplish what? I was asking what it provides to a game for multiplayer. I was hoping for "top-down" type of information. Such as, "when integrated with Photon for multiplayer, it lets you easily do or add _________." I just want to know if it's worth me buying.
Title: Re: Why Playmaker and not Bolt
Post by: tcmeric on March 10, 2018, 08:41:23 AM
This is a list of the actions and events for Photon.

You can also code your own. What it allows you to do is control these things without using C# to do it.

https://hutonggames.fogbugz.com/default.asp?W931

https://hutonggames.fogbugz.com/default.asp?W929

Playmaker doesnt come with premade modules. It is a visual scripting solution that you can build your own logic with. Although there are many sample projects and lots of tutorials online.
Title: Re: Why Playmaker and not Bolt
Post by: Phuzz on March 11, 2018, 01:21:32 AM
I have been using Playmaker for 4 years now. There will be a lot to say about how many releases I have made using Playmaker, and I have learned alot of C# since then and I did not have a coding background, now I create my own actions if needed.

Just the fact that a huge variety of Asset Store plugins provide ready Playmaker actions, shows which Unity3D plugin is most preferred. It is always a top seller and embedded in countless plugins too.
Title: Re: Why Playmaker and not Bolt
Post by: jeanfabre on March 13, 2018, 11:52:24 PM
I am aware, I said I currently use uMMO for my game (https://mosthated.itch.io/rpg), I know what it does. I was referring to a prior post that said "on Multi Player, you are right, we are actively supported Photon, and we have a close relationship with them to make sure all goes well with PlayMaker integration, so ping me if you have questions on multi player"

I was wondering what Playmaker offers that would warrant an integration. It integrates in what way, to accomplish what? I was asking what it provides to a game for multiplayer. I was hoping for "top-down" type of information. Such as, "when integrated with Photon for multiplayer, it lets you easily do or add _________." I just want to know if it's worth me buying.

Hi,

 Photon integration is officially supported by both PlayMaker AND ExitGames, meaning, that ExitGames is helping me supporting Photon for PlayMaker, and PlayMaker also helps me making sure networking solution can be supported. For example, the current beta is removing support for the old deprecated Unity networking solution, yet, Photon Integration is using som of these features, and so we kept it in PlayMaker so that Photon still works with PlayMaker.

It's difficult to do any better in terms of support :)

In terms of features, PlayMaker integration has massive advantages over a pure c# integration, because you simply check the PlayMaker variables you want to think over the network and that's it, something that otherwise takes many steps and coding.

But really, the bottom line of using PlayMaker is either because you can't code, or because you like PlayMaker paradigm :) and in my case, I coudl do it all in code, but Alwasy choose PlayMaker, because I am way, way faster than with c# only. So the best way to be convinced is to try, and I don't mean to try and make you buy it, I would just say the same about Bolt. The best way to testify is to get your hands on it, If you are serious about development and wants to make it as a developer in Unity, spending $100 on PlayMaker anbd Bolt and try them out is worth the shot in the long run. I purchased PlayMaker in 2011... and I of course covered it's cost on my first contract where I used it.

 Bye,

 Jean
Title: Re: Why Playmaker and not Bolt
Post by: netlander on July 29, 2018, 01:59:41 AM
Very biased replies above.

After having used Playmaker for a while I moved to Bolt and never looked back, here are my reasons:

Here's a comparison chart: https://support.ludiq.io/knowledge-bases/4/articles/222-compare-visual-scripting-tools-for-unity (https://support.ludiq.io/knowledge-bases/4/articles/222-compare-visual-scripting-tools-for-unity)
Title: Re: Why Playmaker and not Bolt
Post by: krmko on July 29, 2018, 03:52:52 AM
While we're at it, i could recommend one (actually two) solution that encompasses the best of both worlds, it's FlowCanvas + NodeCanvas. FlowCanvas is a typical visual scripting solution like Bolt (but i like it better, personal preference) fully integratable with NodeCanvas, which is a solution similar to Playmaker, state machines, actions, etc.

Never had the time to delve deeper though.
Title: Re: Why Playmaker and not Bolt
Post by: netlander on July 29, 2018, 04:29:47 AM
Yes I have looked at both (and the possibility of using them in tandem) but they just didn't have the kind of clear documentation that Bolt has at the moment (can't comment on anything else as I have not used them).

For me Bolt seem to have hit the sweet spot in terms of clear direction, ease to reason about, good visuals, responsiveness, flexibility, etc...
Title: Re: Why Playmaker and not Bolt
Post by: jeanfabre on July 30, 2018, 02:54:15 AM
Very biased replies above.

After having used Playmaker for a while I moved to Bolt and never looked back, here are my reasons:
  • One to one mapping with Unity APIs (helps you understand the ins and outs of Unity without any weird abstractions).
  • Feels less cluncky and more responsive
  • Ease of nesting Units
  • Better performance
  • Looks much better than the outdated PM UI
  • Fewer bugs (in my experience)
  • Fast growing community
  • Could go on... May be later (in middle of breakfast right now).

Here's a comparison chart: https://support.ludiq.io/knowledge-bases/4/articles/222-compare-visual-scripting-tools-for-unity (https://support.ludiq.io/knowledge-bases/4/articles/222-compare-visual-scripting-tools-for-unity)

Hi,

Yes, it's ok to prefer one tool over the other, that's the great thing about the Asset store.

 Do you have some benchmark for performances? I'd be interested in checking them out and possibly see where the performances differences are. What's important to understand with PlayMaker is that it doesn't use Reflection which is always impacting performances, but instead uses plain scripted actions, which means that de facto, performances are in theory better.

Not that PlayMaker do offer some Reflection when you are using SetProperty, GetProperty, or CallMethod, and it's not recommanded to use them unless you have no other options and you don't know how to code ( you can alwasy ping me if you need a custom action, I'll happily provide)

For example, one could try as an exercice to reverse engineer in Bolt the 2d platformer demo that I reversed engineered in PlayMaker, and then we would have a very good base for benchmark. I did extensive testing for that project and the footprint in memory is 1Mb ( size of the PlayMaker FSM dll) and 1 to 3/4 fps in the worse  scenarios ( webgl) compared to the original scripted version.

you can see all the results of the benchmark below:

https://github.com/jeanfabre/PlayMaker--UnityLearn--2dPlatformer

 Bye,

 Jean

Title: Re: Why Playmaker and not Bolt
Post by: djaydino on July 30, 2018, 03:45:21 AM
Hi.
I would also like to see a version from the Unity 2D Platformer Demo, as i don't think  that the performance will be worse than any of the other 'State Machine' visual scripting tools.

Also that comparison chart does not come from a independent party.
Which means that it is not reliable.
Title: Re: Why Playmaker and not Bolt
Post by: miguelfanclub on August 08, 2018, 03:53:54 AM
Performance is the reason I just downloaded bolt yesterday.
Playmaker is really slow, no matter computer. Timmings to just press play and wait until it finish is ridiculous on a mid size project.

Just having playmaker editor window on, is slowing down unity (slecting obejcts in hierachy etc)

On later versions just sleceting and fsm need like 2 seconds to show the nodes.

Im not talking about performance after you build (that is really good) but while editing your project.

Title: Re: Why Playmaker and not Bolt
Post by: djaydino on August 08, 2018, 06:48:30 PM
Hi.
@miguelfanclub
There are several prefferences that you can turn on/off to improve the performance
Title: Re: Why Playmaker and not Bolt
Post by: Broken Stylus on August 09, 2018, 02:43:52 AM
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.
Title: Re: Why Playmaker and not Bolt
Post by: Broken Stylus on August 09, 2018, 02:51:44 AM
4-In bolt , there is this thing called "super Unit" which essentially mimics a function call, which you can assign input/output to . it substancially helps you not to repeat your code , which unfortunately playmaker cant do .

Sounds like Run FSM.
Although Run FSM still feels really rough. I think a lot of improvements for future PM versions would need to focus on making FSM templates easier and clearer to use, especially on reading what happens inside an instantiated FSM at runtime; including its own vars (I haven't moved to 1.9 tho so perhaps there's been improvement on that side?).

Quote
5-In bolt , there is saved variables , which makes process of saving very easy.

Is it a form of serialization?

Quote
8- i never understood what they mean by "Native Feel " !?

Don't they use Unity's own graph view system, the one introduced with Mecanim?

Quote
9- In Bolt , there is a window for variables , one for input/output.where the hell should i dock all that ?!

I think that as a supplementary functionality (if it is), it's a good thing.
As for the docking, some devs work with very large screens or two of them so they move the kind of non-visual windows to the side or the second screen.
Title: Re: Why Playmaker and not Bolt
Post by: Broken Stylus on August 09, 2018, 03:05:08 AM
Hi.
@miguelfanclub
There are several prefferences that you can turn on/off to improve the performance

On that, I can confirm. A lot of the error checking and debugging really makes PM slow so if you're more in the WYSIWYG phase of your project, just deactivate all the stuff.

OH, IDEA!

Why not also create a function to save and load such setups instead of having to do it manually every time? It would also come with a list of three or four typical "modes" too, on top of which the user could create new modes.
A bit like the Layout Settings menu, see?
Title: Re: Why Playmaker and not Bolt
Post by: krmko on August 09, 2018, 05:34:33 AM
Great posts, Broken Stylus. Nice idea for setups, or at least one button to toggle all debugging/error checking would be neat :)

I have few more cents to add.

I tried Bolt, and while i personally don't like it, i believe you can work pretty fast in it (probably as fast as in PM) when you set up some macros and units. But the thing is, community is still so small that there is going to take years to surpass Playmaker in terms of what you get out of the box.

But the main difference between these two solutions remains, Bolt is visual scripting tool, and Playmaker is...well, Playmaker.

While there should be no competition between these two because they're completely different tools, it does exist and that is a good thing. I must admit that i had a feeling like PM devs were a bit (deservingly) resting on laurels until Bolt appeared and got shoved in our faces. Now i can clearly see the future of it and some exciting new things like native tweening and pooling are happening, paving the path for a complete game-making solution without any flaws.
Title: Re: Why Playmaker and not Bolt
Post by: Broken Stylus on August 09, 2018, 08:47:06 AM
I suppose that if one were to introduce a var browser, alongside a search function, a replace tool would be extremely useful.
It would let you do the search in the current state, the current FSM, current gameObject (if it has multiple FSMs), the current scene or all scenes.
You could target normal gameObjects or prefabs/instances too for the search.

As for vars, it would allow swapping all uses of a given var with another var of the same type.
Cherry on top: you could replace references to gameObjects with dynamic fields where you're invited to select a var instead.
For example, you have plenty of actions that refer to a specific gameObject in your scene, but after a change of mind you want those references to actually use a FsmGameObject var instead.

The replace tool would allow you to parse all fields and vars one by one or replace all refs or vars at once.