playMaker

Author Topic: public private fsm variables  (Read 5880 times)

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
public private fsm variables
« on: April 04, 2011, 07:12:03 AM »
Hi,

I think it would be good to be able to declare fsm variable as private or public, so that other fsm can or can not see them when setting variables of others. Not only it's a good practice as is, but in the perspective that an ecosystem will emerge with lots of ready made fsm, it will become necessary to guarantee protection just like normal script do as well.

 Bye,

 Jean

canadialad

  • Playmaker Newbie
  • *
  • Posts: 2
Re: public private fsm variables
« Reply #1 on: November 10, 2014, 03:57:07 AM »
I know this is a dead post, but it's worth a bump to see if others are interested.

I am currently using FsmTemplates to monitor the input of axis and keys.  Private/public FsmVariables would be particularly useful with my axis template.  There are a few variables I use internally to determine whether you have pressed or released either the negative or positive axis keys.  When I use them within a RunFsm action, I could potentially change the initial settings.  Because I could pass along my custom actions to someone else with PlayMaker, it would communicate the required information from the developer and expose nothing else to avoid confusion.

As Jean stated, there is a necessity for access modifiers in an environment that would provide ready-made Fsm's to other users, such as my axis and key state templates.  I, too, believe this addition would have a wholly positive effect on the versatility and robustness of the PlayMaker editor.

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: public private fsm variables
« Reply #2 on: November 11, 2014, 01:08:05 AM »
Hi,

 yeah :) and as I work more and more with templates and runfsm, I think the "interface" of an fsm, as in c# interface really appeals to me more and more. I woudl like to be able to describe an fsm with what's it's supposed to exposed as variables and events, so that any fsm could simply conform to that interface and other fsm could simply interact with others trhough this interface.

but I realize this is a very complex concept to create and explain and so it may conflict with the main purpose of PlayMaker, which is to be easily accessible and straight forward.

Bye,

 Jean

wilczarz

  • Playmaker Newbie
  • *
  • Posts: 5
Re: public private fsm variables
« Reply #3 on: June 03, 2019, 07:28:49 AM »
Hi Jean,
I wonder if you had any more thoughts regarding private variables in Playmaker.

Our studio currently starts using Playmaker in one of our projects, and as a programmer I am shocked that private variables are not implemented.

It seems that encapsulation does not exist at all in PM. As result, anyone can break the state pretty easily from any fsm. Moreover, variables are always duplicated! For example int moves must exist both on Logic fsm (representing the real state) and also on Canvas fsm (to update the label). Multiply this by number of variables and you get spaghetti - you're not sure which variable holds the real state and which is just temporary.

The way I see it, all it takes is one more dropdown public/private when defining the variable. You can even set the public as default for backward compatibility. But if I choose private, other fsms should not be able to access it.

Are there any good reasons agains this?
Thanks!

Fat Pug Studio

  • Beta Group
  • Hero Member
  • *
  • Posts: 1294
    • Fat Pug Studio
Re: public private fsm variables
« Reply #4 on: June 03, 2019, 09:56:36 AM »
I agree with Jean on this one, it kinda beats the simplicity of Playmaker, but it can be something that could be enabled in the preferences, a dropdown that enables you to set the variable as public or private (defualt would be public when the option is turned off).

The only problem i see in that approach is what happens to variables set as private/public one you turn off that preference.
« Last Edit: June 03, 2019, 10:30:18 AM by krmko »
Available for Playmaker work

djaydino

  • Administrator
  • Hero Member
  • *****
  • Posts: 7615
    • jinxtergames
Re: public private fsm variables
« Reply #5 on: June 03, 2019, 11:15:27 AM »
Hi.
If this would be added, i don't think it should be in preferences.

A good place would be in the Variables tab when you select a variable, on the bottom to have a checkbox (similar to 'Inspector') and default to false.

I do think that it would be a good idea tho.
So it can not accidentally be changed from other fsms.

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: public private fsm variables
« Reply #6 on: June 04, 2019, 04:20:52 AM »
Hi,

 This is the dilema indeed.

 I pushed for that for many years, and then realized Alex has a vision and he proved he was right over the years, with playmaker being the #1 visual programming system by far.

 So, yes, when you know about private and public var, and as a purist, you kind of want to bring these concepts back to playmaker, but actually, this will mess up what is actually working, and yes, you can get mixed up, and it can get ugly, but is that a reason for making the learning experience of playmaker more difficult? no. PlayMaker expects that you develop clean and adopt very early a protocol, some rules, and that you stick to it, which leads in forging yourself a kind of attitude towards how you handle data and fsm.

And in the end, it's better this way! because we can all agree I think that c# project can get ugly just as well as any other projects, and that it's always a matter of how clean the developer is and how strongly he respect the conventions setup for that project, I am dealing with lots of support, and I have seen a lot of projects, and the clear conclusion is that convention is far more beneficial than configuration and features. It has its flaws but a successful project is one that has very stricts conventions as opposed to doing anything and everything c# allows or PlayMaker allows. You have to gain experience with your tool and then define a way to work with it and stick to it making very small incremental changes to leverage new features and new contexts, as well as you being better at it, which leads to identifying flaws in your way of working that needs adjusting. This cycle is a beneficial and will always rewards you in the long run. I have projects done years ago that I can open and find my way around easily, because I still follow the same conventions for naming global events, handling data in metadata fsm, etc etc.

 Bye,

 Jean

wilczarz

  • Playmaker Newbie
  • *
  • Posts: 5
Re: public private fsm variables
« Reply #7 on: June 04, 2019, 08:03:39 AM »
Hi Jean,

As a software architect and programmer, I see the power of visual scripting and that is why I adopted Playmaker in our studio. I tried to create a workflow where programmers writing heavy C# logic can co-exist with artists using visual scripting.

After using Playmaker with several of our projects I have one conclusion. Playmaker may be great for absolute novices, but if you want to use it for something slightly more complicated, or share the work between the coders and artists it fails badly. It either grows enormously or breaks every object-oriented rule the coders try to enforce. The mess wins both ways.

Several concepts of Playmaker are responsible for that (lack of encapsulation being only one of them). As you say, the same reasons make it great for beginners, and probably that is why it is so popular. However I feel forced to try the competition, as Playmaker becomes really hard to use beyond the prototyping phase.

Thank you for your detailed explanation.
Tom

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: public private fsm variables
« Reply #8 on: June 05, 2019, 03:07:46 AM »
Hi,

Interesting :)

tltr? check out this video from Nate Gallardo about what you are trying to achieve with your team ( core dev and artists)



 it's very important to see what other solutions are out there, and we are totally fine with that of course, PlayMaker is a tool with a vision, and that vision may not be your vision, we are ok with that :) but if PlayMaker is the #1 visual solution for so many years, it's because Alex Chouls ( the developer behind PlayMaker) saw something that we didn't, and many have tried to create visual solutions and none so far are able to reach and hold up to PlayMaker.


My experience with PlayMaker which spans for more than 8 years now involve some huge projects, and I have a different outcome, I do think that PlayMaker has what it takes to handle large projects, but it is a paradigm shift in the way you approach it, and I think the problem you are facing is because of that paradigm shift not being complete.

What do you mean "enforced" Object oriented rules? If a developer is given a set of rules and doesn't follow them, it's not the tools' fault, what ever the tool. If I say don't use statics and singletons, and one dev creates a feature using that, I don't think c# or Unity is to blame, right?

PlayMaker is not object oriented, nor it Unity, so enforcing Object oriented approach has to make sense within this context. I love OOP in theory, but the downside is that true OOP is just like Java, and the main issue with this, is that once you decide on the structure, you can't change it, which is why so many project are doomed when they reach this critical time in the developement process where the client says "Let's do this instead..." which totally mess up your OOP structure and you are unable to deliver in time nor it becomes a clean project anymore. So OOP: yes, but loose and it's ok for it to be loose in my opinion :)

My very first big project with Unity years ago was to create a simulator for a Robot on a oil rig, which replace manual operations that are highly hazardous, the project spans over more than two years and is used to train employees before working on site so it has to be 100% realistic and true to the real thing, I also picked Playmaker, it just came out of beta) because of its Finite state machine, the client would give me a diagram of operations as they developed the robot itself, involves some very complex and ever changing rules, which if I had to do in c#, I would have certainly fail at it. With Playmaker, I was faster then the actual engineer in implementing new rules!! that is when the client was giving us instructions about how the robot should behave, the engineer that was suppose to code the robot ( no change in variables nor physical context, pure behaviour change), I was way faster! Every one was shocked. Even today if I had to start again, I would still pick PlayMaker, because c# doesn't offer any built in solution to create such a flexible system, and it would mean having to recreate an FSM or something similar to get there anyway.

My most successful approach so far when I have to create complex beasts with Playmaker is more an MVC approach actually, because of the way Playmaker can communicate so easily between each Fsms, without any boiler plates and event registrations, etc etc. So Maybe leaning towards a loose MVC ( Again because Unity and Playmaker are not fully MVC compliant context) will get you farther down the road than an OOP approach.

So, I differ from your conclusion that Playmaker is just for novice, Playmaker brings far more on the table then a quick learning entry level scripting solution, it offers a true production ready, performent, and battle tested Finite State Machine. I always say that Playmaker should not even advertise that it is visual, because it undermine what Playmaker is really about, it's a different approach.

- No more difference between synchrone and asynchrone operations! This is huge.
- No more boiler plates for event listening, this is also huge, but dangerous, I give you that
- No more compilation when making changes. Everytime I have to work with components or need to create a new custom actions, It hits me that I really got used to not having to wait for Unity to recompile to press play! this is massive in terms of production gain. I demonstrated that at Unite in texas few years ago, someone challenged me to write a quick logic, thinking playmaker would fail, what happen is, that by the time he was starting coding in visual studio, I was already playing. That was a a shock for that developer. This becomes more and more noticeable as your project grows as well.
- Total transparency at runtime, I can see where are all my fsm and what they are doing, Debugging is part of the development from scratch. The gains in production speed are also very noticeable, I curse everytime I have to debug a complex set of classes, which clearly is not as convenient to do than with PlayMaker.


I stop here :) but I'd be interested in learning more about what where your flaws, we can certainly learn from your experience and see if we can improve the workflow or maybe do some samples where we show how Playmaker can be integrated in a mixed team of core developers and artists.


Bye,

 Jean