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 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
