Feature Request: Finite State Machine Behaviour

  • Given how spaghetti-like any use of conditionals becomes in a visual programming environment, the limited editing facilities within hyperPad (no copy/paste, no UNDO), and how important states are to games, adding a state machine might be a good idea.

    In terms of ease of use, workflow and sanity, in a visual coding environment, I think they're essential for anything beyond Flappy Birds.

    For the purposes of education in the powers of virtual interactivity, the separation of states and their rules of transition are a boon (unlike any other) to conception, articulation and creation.

    But, more than anything else, they provide a clean, elegant and simple way to articulate ideal abstractions of state changing of state... because they're state machines.

    Add to this a while loop, cases, enums and switch, and you've got a lot more graceful and elegant ways to handle everything in games.

  • @Deeeds In the meantime, and considering that this is probably a fair bit of work, a shortcut suggestion:

    Storage Observer Behaviour

    By this I mean a Behaviour that watches the contents of a variable or Box Container, and whenever it changes, branches accordingly.

    This saves setting up a process to watch for changes in a variable, and all the conditionals required to handle its potential settings.

    You get most of the good parts of the functionality of a Switch and FSM without all the bother of making them.

  • @Deeeds So a behaviour that remembers all the values saved into some input field? Why not just save them in an array? Yeah itโ€™s more work, but more fun too ๐Ÿ˜‰

  • @Deeeds by finite state machine, do you mean a truth table like this:
    Or do you want to run a function of state and input? Both of these are possible with behaviours, but I can't see much use for them. I'm probably misunderstanding what you mean.

  • @Jack8680 Truth table is part of a good FSM's functionality.

    The main benefit (in games) of Finite State Machines, are two fold:

    1. Easily articulate and edit differing responses to events based on the state(s) of something(s)
    2. Create easily digestible and editable transition activities/restrictions between states of things

    A truth table is a part of the process of restricting/limiting/clarifying possible (and not) transitions between states. But it's a bit of a messy way to do it when the visual path is available ;)

    A visual FSM is kind of a joyous thing. Makes animating characters and coordinating their responses to events MUCH easier.

    Mainly because most game characters and entities are Finite State Machines by virtue of their virtuality.

  • @Deeeds okay, I've googled a bit and I see the visual aspect of a finite state machine. So it'd basically let you have events and states that switch to other states like in a truth table, but you show it visually like a flow chart. Then I guess you could have each state contain behaviours underneath that are turned on during that state. I can see this being a pretty cool feature actually, and possibly not too hard for them to implement.

    I can do this with behaviours, except I would have to make an editor for the finite state machine, or you'd be typing out nested dictionaries. It wouldn't work with a timer though since you'd need to turn it off when the state changes, so every timer would need to be a wait behaviour with an 'if' to check the state and if it's the relevant one, reactivate the wait. Although a finite state machine would suffer the same problem, unless it also stopped any timer anywhere down its behaviour tree from running when the state changes.

    I'm going to think about this a while as I try to sleep.

Log in to reply