Playmaker Forum
PlayMaker Help & Tips => PlayMaker Help => Topic started by: Sly on August 22, 2011, 11:52:49 AM
-
Hello,
I am new to playmaker. I allready used workflow system in other engines. This one seems to be cool.
But I despairingly want to find/understand if there is a condition system. Because maybe I'm wrong but I didn't find anything for this.
I give you an example about what I try to do:
I used a variable name 'myvariableA' and this variable is used for scale a character. I add +1 to this variable every 1 sec. So every second my character is bigger. That's ok, it's work. But I want when my variable "myvariableA" will be equal to 10 to stop scall my variable.
I don't understant how to do this using playmaker, because I don't find any conditions way.
Is it possible? Is someone can help me, not to do my work, but to explain me what way to use.
Thanks
-
Well under Logic there are tests you can do on variables?
If that is what you mean.. Like Float Compare..
If it does not do exactly what you mean then you can write a custom Action easily to suit a need if it is something that you need over and over.
Q
-
Yea it can be like to compare float. If A < 10 do the scall actionm or if A >=10 do an other action.
I don't understand how to do that, and I hope it's possible because it exist in a lot's of workflow basic system.
Basicely, I want to do like on this picture (http://www.manageengine.com/products/msp-center/images/it-workflow.png)
And yea, I can't work without conditions. I hope I'm clear in my explications.
Thanks man
-
Ok so if you use Float Compare then you put in an event for = or > and do your increment loop in that same state.. Then have another state with a global event attached.. the same one you put in for => that it goes to for the => event you set up. And in that state it could do nothing or wait for some other event to leave.. It could also monitor it to see if it goes below 10 or slowly shrink it to 0 or something..
Very easy.
If you still dont get it i could do a pic of some kind.
Q
-
Yo,
Ok i will check with the Float Compare. I already take a look at the event, and it's a little weird for me for now, because I always use conditions directly on the arrow (like on picture) in others engine.
And for sure if you have time to make a pic It can be cool :)
Thanks a lot for your help and quick answer!
-
Here is a quick pic.. I assume this is what you want?
Q
-
Wow! That was not what I am thinking about, because I have not the reflexe yet to use event. I was thinking to have multiple arrows with different way.
But it seems to be a good way, I understand better. So I will test this like that when back home.
-
well that is like 1 of 10 different ways you can do it or similar....
To be honest i dont use the arrow wires much just global events and global transitions...
They are the same as far as i know. You still need to have a transition and an event to leave a state so why not just use a global transition and call the event that way... Its just how i do it
Q
-
Hi,
Well, I'd like to comment on this actually :)
I think using wires is something very important in some cases. For example if you implement an If statement. You create a YES and NO event and plug that as transition for your state, and from there you progress through your fsm.
the benefit of this for me is that I reuse the YES and NO event within my fsm, and keep the verbose within the state title. So I end up with a clear flow of what this fsm is achieving. If you only rely on global events, then it can become almost impossible to understand how that all works in 6 month time because everything is loose.
On complex project, for a given state you might request the system to perform differently. The problem with using only global events is that you loose that "state": how would you know that a particular global event needs to be active or inactive: you end up checking for this on each and every global events. if you use wiring, you can safely define several different behavior for the same system by simply triggering a top most global event that itself define the state of the system.
Another good reason to wire things up is during playback and debug, you can follow the flow. If you only use global events,it is impossible to know from where it just came out.
I have attached a screenshot of an fsm that shows how wires can help building complex behavior with only generic events like YES NO DONE, etc. This prevents ending up with hundreds of global events with no real added benefit cause each would serve a too narrow purpose. When I reach the end of this flow ( "carry on trip in" or "robot top grippers needs to come in" ) that's when I trigger global events. And I also use a global event to actually start the routine "ENGAGE ROBOT PIPE".
This flow is one of several dozens other similar processes defined in that system. During testing and approval. I have to react fast to questions like: how does it actually performs in a particular situation: If it's wired, I can simply look and most of the time don't even need to run the thing, cause there are visual evidences.
So yes. Global events are nice and convenient, but they should carry on a clear message meant to be global. In you particular case, this is perfect, but you should be careful not to extrapolate and only rely on such technic for bigger fsm and more complex behavior.
I do use global events a lot, but when I need to shout to the system really :) I have attached an fsm acting as a repository of events. This repository is used for a referencing, so that if I want to implement a listener for a certain type of event, I know where they are all described ( and I don't have to search the actual fsm that triggers it). Note that this fsm do not fire itself these events, it's only a "listener". For example this can be the root for updating the user interface, logging things in a file or triggering sound effects etc etc.
What do you think?
Bye,
Jean
-
Hello Jean,
I really prefer the first example with arrows and YES/NO. It's more "read-able" for me.
What does your event YES and NO? It's probably just a basic event name with this, but what do you put into this transitions? Because for now I don't understand how it's possible to pass to a transition to an other in the same state. How it can pass to the second transition without use the first transition arrow?
For the second choice, yea it's possible, but you need to be f**** organize (and more if you work in a team with other people).
Anyway, that's why I search for arrows with conditions on it :D
Thanks for your helps and your point of view
-
Yes Jean you are correct,,, ;D
I can totally see how using the arrows is way easier to follow.. In my current project i dont really have a lot of decision making in one FSM so i have adopted this style. Although a have a couple that are bigger and have more then just a few states in them so i have also used the wires/arrows to connect.
I dont know why i resist the wired versions...
What do you use for an IF Function then? Do you have a custom one or just use a couple of standard ones?
You could use one or two Float Compare Actions in a State to do a kind of IF statement... Create two Events in the Event Editor one YES and the other NO.. Then in your Float Compare Action set the Equals to Action to YES maybe and then Set the Less Than to NO maybe.. Then add the Two Transitions to the State and set them to YES and the other to NO
As far as the structure of the States and what is wired to what you just need to follow your own basic Flowchart structure for the most part.. Draw out the logic on a piece of paper or in your Flowcharting program and then build it in PM.
Q
-
Picture wise i think Jean had something like this in mind...
Although doing this i could not get the Float Add to work as Per Sec with out Every Frame enabled which would not work of course. So i am not sure how to handle the incrementing in this type of loop..
Q
-
The problem with this is that you will have a lot's of variables, maybe too many!
So yes it can be possible I guess but maybe too complicate in some cases.
For example if I need for an AI to check distance for target I will need to convert distance to a variable, and this for each AI :/ Nothing standard.
And what's happen if you have multiple state using transition YES or NO?
I really want to know if there are other way to do this.
-
Well i am getting out of what i know... But only one state is active at one time... in an FSM And each FSM is local unless you are accessing Global Variables or Global Events.. In these examples everything was local.. So another FSM could have Yes No set up for its local decisions too.. And i make Templates for my repetitive local setups.. That saves a lot of time.
What i do for logic in my simple project is... if there is some complex decision making to be done for different objects i create a separate Object that just does that decision making and i call it from my other objects passing variables along. It has all the logic in one place so that you can keep it editable and not spread all over the place.
I think you need to do some more tutorials and start building simple versions of what you are thinking.. I find that makes it way more clear for me and for getting help..
Q
-
Hello,
I am working in the professional field too, so I have the reflexe to always try to optimize my work and to have things standard, so I can re-use it. That's why I try to find a better way.
I tried to check some tuto about that but nothing special about what I want.
And I am trying a lot's of things for now the limitations. Variable and conditions are the most important for me because you can do what you want with it, but using a good way.
I need playmaker for a project, and I need to check for an other a little bit more conplicate.
But you are right, I will check more tuto.
And I am just curious to know how JeanFabre on his own method "YES/NO". If you can give more details it can be great (if it's really different than Qholmes' method).
For now, thanks for your advises guyz. Enjoy the sun :D
-
Well Jean is a good act to follow for sure.. I am just a hack trying to get better ;D
I would like to know how Jean does his IF as well just so i know.. always trying to learn better ways.
I still dont think i quite understand what you are looking for but i am sure that will come eventually.
later.
Q
-
Hi,
Yes, it's really a matter of context. As I said: I use both type of pattern, and most of the time a combination of them :) I also use global events to cut process that yre too long and too complex to build in one fsm... I started with just wiring the whole process, but ended with hundreds of states in one fsm... I had to cut it down into manageable chunks...
As for using a wiring technic on your case, here is a screenshot ( counter_wired ) of the same fsm that Qholmes did with the increment counter state set up to work. The key is to send an event with a delay and not relaying the everyframe nor per second of the float add action, this doesn't fit in our case.
another solution closer to "less wiring" ( as attached "counter_second_solution" )
I would actually keep the state as you did but instead of firing a global event I would fire a transition event instead so that visually I am moving out of this state when 10 is reached. NOW what if you actually wanted some way to interrupt the count. Then it make sense to use the "only one active state per fsm" feature and your original fsm would be perfect for this because another fsm could trigger "stop Increasing" for some reasons. Many options available :) yes playmaker is very flexible indeed :) I also added for example a "RESET" global event so that you can call that fsm to set the counter back to 0 and start counting again.
I only create "if" states that are synchrone: they do not perfom any "every frame" actions or stuff that wait for a variable to change state or something. This is not really intuitive when you read the fsm flow. An if statement is something direct and instant. For asynchrone state, I use "DONE" which indicates that some work has been "done" indeed. If it doesn't follow these two rules, I try to make it more granular so that it actually does.
YES NO events are really and only used within transition, I never plug such generic even in a global transition to enter a state, I use similar events like DONE, CONTINUE . They really only mean to be used as state transition ( something that was very difficult for me to grasp when I started with playmaker, it took me time to understand that I could plug ANY event in a global transition or in a state transition). I started a thread on this actually: http://hutonggames.com/playmakerforum/index.php?topic=38.msg111#msg111 (http://hutonggames.com/playmakerforum/index.php?topic=38.msg111#msg111) where I explain how I categories my events.
So the way qHolmes did it works fine for me, and your chart and expectations are completly doable with the methods mentionned in this thread. If you need a proof of concept of your diagram precisly, let me know and I'll roll a screencast so that you understand the production process as well ( which is part of the learning)
final notes:
You can have multiple state using YES and NO as transitions because playmaker detects this.
Bye,
Jean
-
Yo!
Thanks for explain with a lot's of details.
For sure I prefer the first method. Like you said it's more logical when you read it.
I had some trouble to understand how it work because usually there is states (command, script etc...) and conditions (If, variable math compare etc...) separate. But in playmaker condifions are state too.
For now you tried to understand (I speak more for you qholmes) what I'm doing with this. For explain I'm just testing the "If/condition" system. For me it's important to have this. And I'm testing hard stuff, if it's ok, I will be able to work on the rest.
Thanks for your helps guyz!