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

This forum is currently in read-only mode.
From the Asset Store
Best soundtracks for any game. High quality and engaging assets.
  • I think he means something like a family. Example for the family "door", I might want door_is open, door_is closed, door_is opening, door_is closing. Then if the state is door_is closed the whole family would be negated.

  • Plugin has been updated a bit. Im working on the adaptation to a behavior.

    Deadeye gave me the idea to have the option that when you set a state to true all other states are turned to false by default. this would be in addition to the normal changing state options. Do you guys agree or disagree?

    Well, if more than one state is on, then it's not really a state machine so I'd say it's a good idea.

  • You can have states nested within states. so more than 1 state returns true.

  • You can have states nested within states. so more than 1 state returns true.

    <img src="http://upload.wikimedia.org/wikipedia/commons/thumb/c/cf/Finite_state_machine_example_with_comments.svg/220px-Finite_state_machine_example_with_comments.svg.png">

    This is what a Finite State Machine looks like. A door cannot be opened and closed at the same time. You could, however, have ANOTHER finite state machine that is only used while inside one particular state (thus addressing nesting properly).

    For example, following the door diagram: the door could have a locking mechanism. When in the closed state, you could change to a lock state in the door machine. When in the lock state of the door machine, you could have access to a lock machine, that upon reaching a certain state, issues an unlock rule to the door machine, which takes it to the closed state again. This sounds rather complicated here, but it's veeeery simple using separate machines, and they never mix up.

    Pert diagrams allow multiple active states, that is how concurrency is designed. FSM are completely different from Pert diagrams.

    A finite state machine has only one active state, which is the current state of the machine. If there were any more active states, it woudln't be a state machine per definition.

    All that said, I

    have a request

    (two actually).

    • First the simple one: an expression to get the current state.
    • Second: A FSM is much more useful with transition rules. Could one add rules in the form of rulename->destinationstate? so then one could just do Sprite[FSM].trigger("jump") and if any rule in the current state matches "jump", it would go there. Additionaly, a loop for traversing these rules would be nice (with currentRuleName and currentRuleTarget expressions). One should also be able to check if a state has a certain rule or not, in the form of Sprite[FSM].ruleExists(state,rulename).

    The above, coupled, would enable pretty good AI.

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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • "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 don�t 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 you�ll 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 system�the 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 doesn�t 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, it�s 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 transition�from 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.

  • Thanks Aeal5566

  • 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

  • Nice

    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:

    <img src="http://dl.dropbox.com/u/939828/ICON.bmp">

    <img src="http://dl.dropbox.com/u/939828/SICON.bmp">

    I'd also recommend maybe making a behavior version of this as well, although people can just use containers to achieve instancing

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

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

  • Hi,

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

    many thanks,

    Dan

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

  • 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

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)