State Machine Plugin -v.91 - Beta[updated 2/17/20]

New releases and general discussions.

Post » Wed Feb 24, 2010 6:24 am

So rules would be a part of states so you could add rules to states I guess I really don't follow what you are saying...
If you could draw a picture or give an example of what you are talking about it would be easier for me to understand.
The get current State is easy enough I can do that no problem.
B
5
S
2
G
4
Posts: 632
Reputation: 2,829

Post » Mon May 03, 2010 7:18 pm

"Extended state machines can apply the underlying formalism to much more complex problems than is practical without including extended state variables. For instance, suppose the behavior of the keyboard depends on the number of characters typed on it so far and that after, say, 1,000 keystrokes, the keyboard breaks down and enters the final state. To model this behavior in a state machine without memory, you would need to introduce 1,000 states (e.g., pressing a key in state stroke123 would lead to state stroke124, and so on), which is clearly an impractical proposition. Alternatively, you could construct an extended state machine with a key_count down-counter variable. The counter would be initialized to 1,000 and decremented by every keystroke without changing state. When the counter reached zero, the state machine would enter the final state.

In extended state machines, a change of a variable does not always imply a change of the qualitative aspects of the system behavior and therefore does not always lead to a change of state.

The obvious advantage of extended state machines is flexibility. For example, extending the lifespan of the cheap keyboard from 1,000 to 10,000 keystrokes would not complicate the extended state machine at all. The only modification required would be changing the initialization value of the key_count down-counter in the initial transition.

This flexibility of extended state machines comes with a price, however, because of the complex coupling between the qualitative and the quantitative aspects of the extended state. The coupling occurs through the guard conditions attached to transitions

Guard Conditions

Guard conditions (or simply guards) are Boolean expressions evaluated dynamically based on the value of extended state variables and event parameters. Guard conditions affect the behavior of a state machine by enabling actions or transitions only when they evaluate to TRUE and disabling them when they evaluate to FALSE.

The need for guards is the immediate consequence of adding memory extended state variables to the state machine formalism. Used sparingly, extended state variables and guards make up an incredibly powerful mechanism that can immensely simplify designs. But dont let the fancy name (guard) and the concise UML notation fool you. When you actually code an extended state machine, the guards become the same IFs and ELSEs that you wanted to eliminate by using the state machine in the first place. Too many of them, and youll find yourself back in square one (spaghetti code), where the guards effectively take over handling of all the relevant conditions in the system.

Indeed, abuse of extended state variables and guards is the primary mechanism of architectural decay in designs based on state machines. Usually, in the day-to-day battle, it seems very tempting, especially to programmers new to state machine formalism, to add yet another extended state variable and yet another guard condition (another IF or an ELSE) rather than to factor out the related behavior into a new qualitative aspect of the systemthe state. From experience in the trenches, the likelihood of such an architectural decay is directly proportional to the overhead (actual or perceived) involved in adding or removing states (which relates to the actual strategy used for implementing UML state machines.)

One of the main challenges in becoming an effective state machine designer is to develop a sense for which parts of the behavior should be captured as the qualitative aspects (the state) and which elements are better left as the quantitative aspects (extended state variables). In general, you should actively look for opportunities to capture the event history (what happened) as the state of the system, instead of storing this information in extended state variables. For example, a state machine representing the behavior of a pocket calculator might use an extended state variable DecimalFlag to remember that the user entered the decimal point to avoid entering multiple decimal points in the same number. However, a better solution is to observe that entering a decimal point really leads to a distinct state entering_the_fractional_part_of_a_number, in which the calculator ignores decimal points. This solution is superior for a number of reasons. The lesser reason is that it eliminates one extended state variable and the need to initialize and test it. The more important reason is that the state-based solution is more robust because the context information is used very locally (only in this particular state) and is discarded as soon as it becomes irrelevant. Once the number is correctly entered, it doesnt really matter for the subsequent operation of the calculator whether that number had a decimal point. The state machine moves on to another state and automatically forgets the previous context. The DecimalFlag extended state variable, on the other hand, lays around well past the time the information becomes irrelevant (and perhaps outdated!). Worse, you must not forget to reset DecimalFlag before entering another number or the flag will incorrectly indicate that indeed the user once entered the decimal point, but perhaps this happened in the context of the previous number.

Capturing behavior as the quantitative state has its disadvantages and limitations, too. First, the state and transition topology in a state machine must be static and fixed at compile time, which can be too limiting and inflexible. Sure, you can easily devise state machines that would modify themselves at runtime (this is what often actually happens when you try to recode spaghetti code as a state machine). However, this is like writing self-modifying code, which indeed was done in the early days of programming but was quickly dismissed as a generally bad idea. Consequently, state can capture only static aspects of the behavior that are known a priori and are unlikely to change in the future.

For example, its fine to capture the entry of a decimal point in the calculator as a separate state entering_the_fractional_part_of_a_number, because a number can have only one fractional part, which is both known a priori and is not likely to change in the future. However, implementing the cheap keyboard without extended state variables and guard conditions would be practically impossible. This example points to the main weakness of the quantitative state, which simply cannot store too much information (such as the wide range of keystroke counts). Extended state variables and guards are thus a mechanism for adding extra runtime flexibility to state machines[6]

Actions and Transitions

When an event instance is dispatched, the state machine responds by performing actions, such as changing a variable, performing I/O, invoking a function, generating another event instance, or changing to another state. Any parameter values associated with the current event are available to all actions directly caused by that event.

Switching from one state to another is called state transition, and the event that causes it is called the triggering event, or simply the trigger. In the keyboard example, if the keyboard is in the default state when the CapsLock key is pressed, the keyboard will enter the caps_locked state. However, if the keyboard is already in the caps_locked state, pressing CapsLock will cause a different transitionfrom the caps_locked to the default state. In both cases, pressing CapsLock is the triggering event.

In extended state machines, a transition can have a guard, which means that the transition can fire only if the guard evaluates to TRUE. A state can have many transitions in response to the same trigger, as long as they have nonoverlapping guards; however, this situation could create problems in the sequence of evaluation of the guards when the common trigger occurs. The UML specification[1] intentionally does not stipulate any particular order; rather, UML puts the burden on the designer to devise guards in such a way that the order of their evaluation does not matter. Practically, this means that guard expressions should have no side effects, at least none that would alter evaluation of other guards having the same trigger"


http://en.wikipedia.org/wiki/UML_state_machine

So, yeah this is nice info for those that use state machines, but like most wikis it needs to be simplified.
B
2
S
2
G
4
Posts: 259
Reputation: 1,968

Post » Sun Jun 06, 2010 11:19 am

Thanks Aeal5566 :D
B
2
G
3
Posts: 16
Reputation: 882

Post » Tue Jun 15, 2010 5:30 pm

In the cap you provided with the plugin the inverted condition "Lol is true" does not have any effect. [text does not change, tried with other effects and does not work either] :/

Seems like a bug to me.

This plugin would be very nice.

A request: Can you add an option to set a state to a value in the same time it is created?
I mean you now have "Create state 'Lol'" I would like to have "Create state 'Lol' and set it to true" or "Create state 'Lol' and set it to false"
Edit: I see the option IS there but it is only not displayed in the editor. I confess repentantly and ask for forgivenes...and for making it displayed in the editor :)

Also what is happening if all your states will be switched to "No"? A default state comes to mind here so you do not have to create a big inverted condition stack for the thing you did not forsee like turning everything off :)
B
2
G
2
Posts: 23
Reputation: 696

Post » Thu Jun 17, 2010 9:15 am

Nice :D

Learnt about State machines at Uni this semester, and when combined with inter agent messaging it certainly makes creating AI a lot easier and logical.

The plugin needs some polish tho, as Ashley and a few others have said the text should say 'On State Activated' not 'On state false to true', just makes things easier to read.

Theres heaps of stuff you can do to a FSM to make it more advanced, such as having a 'state stack' so you can revert to the previous state, and then theres non-determininistic state machines where you have a 50% chance of doing one thing or another...but really I think that could be done with construct events anyway.

Also incase you wanted to change the icon I made you 2, but you dont have to use them:



I'd also recommend maybe making a behavior version of this as well, although people can just use containers to achieve instancing
B
4
S
2
G
5
Posts: 641
Reputation: 3,011

Post » Sun Feb 24, 2013 2:09 pm

Can someone re-up? the link is broken and this is an awesome add-on.

machine states are very powerful to create behaviors in "pages", to which you can change at will. I have worked about 2 years with a game engine that was based on a state machine, and i found that very good to keep your program's logic easily understandable.
Image
Image
Image
B
15
S
2
Posts: 48
Reputation: 1,595

Post » Mon Feb 25, 2013 3:19 am

I had to piece this together off the russian site a while back. It was in several pieces and I had to hack it up with notepad to fix it, so I'm pretty sure I'm the last person with a copy of it. :P

Enjoy.
B
5
S
2
G
5
Posts: 221
Reputation: 2,272

Post » Tue Feb 11, 2014 1:37 pm

Hi,

Is the state machine still available for download? I was thinking about the utility of state machine (or automaton, actually).

many thanks,

Dan
B
8
S
4
G
1
Posts: 205
Reputation: 1,354

Post » Tue Feb 11, 2014 4:24 pm

You can either wait till 2/17/20 (from thread title)

Or, click the link in the post before yours.

These Construct Classic threads are getting surreal.
Image Image
B
161
S
48
G
90
Posts: 7,356
Reputation: 66,767

Post » Sun Feb 23, 2014 3:09 am

I dug back through some old files and put up a new link. Here is the plugin as is: https://drive.google.com/file/d/0B7e-a4 ... sp=sharing
B
5
S
2
G
4
Posts: 632
Reputation: 2,829

Previous

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 3 guests