State Machine: Best way?

  • In hyperPad, what's the best way to make a state machine?

    Let's say, as an example, our hero is Sonic the Hedgehog and he has the following states:

    • Running
    • Walking
    • Resting
    • Spinning (that build up before...)
    • Spin Dashing FULL (infinite force)
    • Spin Dash LITE (less than infinite force)
    • Spin Jump Air (up and down whilst a ball of spinning fur)
    • Normal Jump Going Up (in the air, after a jump, not spinning)
    • Falling down during a normal jump (not spinning)

    In each of these states, our hero responds differently to events... hence the need for a state machine.

    Is there a recommended way to build a state machine in hyperPad? A best way?

    Or is it inevitably going to look like a serve of spaghetti meatballs fell into an open blender during a hurricane?

  • Let's us say that running is state 1, walking is state 2, jumping is state 3, etc, etc. You could then make an attribute titled "state", and change that attribute each time you are to change the state of that object.

    Then, just a bunch of ifs under some type of signal...

    That should not lag too much, I don't think.

  • @GameCRAZY Is there no way to avoid the spaghetti of chained "IFs" under what's just a variable rather than a state machine?

  • @GameCRAZY Let me see if I've got this right:

    Hero has Attribute: _state

    Messages are received by hero (from world events and player inputs) and each message received must be processed by a

    Get Attribute _state:
    If = 0, then do this....
    if = 1, then do this...
    if = 2, then do this...


    Wherein the cleanest way to handle this, rather than stringing logic under the "state machine", would be to send appropriate messages to somewhere else where the code can be neatly organised, findable, editable, etc

    Is this right?

  • @Deeeds I think so.

    For the sake of organization, I hinted that you should separately figure out the attributes and then separately calculate what they mean.

    If you are looking for efficiency, you should just trash the attributes and the ifs, so as soon as you figure out a state you can just execute it. This would be confusing for you, though, and it would be hard to add on to.

  • @GameCRAZY Please speak to me like I'm stupid, ignorant and childishly impulsive... and have a short attention span, understand little and know even less.

    I'm not good with hints. Literals are much easier ;)

  • @Deeeds Okay, but do you understand what I mean?

  • @GameCRAZY No. I'm not good with hints.

  • @Deeeds

    One option would be with the attributes:

    (insert some type of trigger, or a load of behaviors)
    Set attribute__state

    (insert some type of trigger, or a load of behaviors)
    Get attribute__state
    If = 0...
    If = 1...
    If = 2...

    Another option would be without this defining type of thing:

    (insert some type of trigger, or a load of behaviors)
    (do the same thing you would do if the attribute would be equal to 0)

    (insert some type of trigger, or a load of behaviors)
    (do the same thing you would do if the attribute would be equal to 1)


    You can create the illusion that you are using states, or even think of everything in terms of states, but you would not actually be creating these states. You would just execute them exactly when you would usually.

    If the user is switching some type of dial, just manually change what the user is doing each time, and don't actually use attributes.

    I would also consider something like this:

    (do the same thing you would do if the attribute would be equal to 0) (behavior off)

    (do the same thing you would do if the attribute would be equal to 1) (behavior off)

    (insert some type of trigger, or a load of behaviors)
    (behavior on__state 0)

    (insert some type of trigger, or a load of behaviors)
    (behavior on__state 1)


    You get the idea.

    I would consider all of these setups for different situations.

  • @GameCRAZY Now I know why your hints were making no sense.

    This makes even less sense.

    I don't have a quarter of the knowledge or insights into hyperPad you're assuming I do.

  • @Deeeds What is it you are not understanding?

    There is nothing crazy going on here, whatsoever.
    Do you know how attributes work at all?

    In the 2nd example, I am not really making any states or anything. I am just skipping straight to the action.

    In the 3rd example, I am just turning state behaviors on and off.

  • @GameCRAZY No, I don't think I know how Attributes work, at all. I thought I did, until I read your answer above... then I figured I don't know what I don't know.

  • @Deeeds Attributes might as well work like Labels, you know how those work right? You can set them to a value or text and you can get them. First you have to actually give your character an attribute, which works similarly to adding a Tag to an object. When setting/getting an attribute, you should be able to enter the key name for the attribute, but I’d just press the Dynamic and change it to the other one. I can try send screenshots if you need.

  • @Aidan-Oxley @GameCRAZY have either of you tried using Attributes lately?

    I just created 2 different ones, and then searched for them in a getter, in the predefined list.

    But that list is empty. So something's broken.

  • @Deeeds, is the behaviour selecting the same object that has the attributes? And also, you have to actually set the attribute through the editor for it to show up on the list, not through a behaviour; it's like setting a tag.

    I think GameCRAZY is describing if you want something to happen immediately when the state changes, but I'm assuming you're setting the state for later use. I think set/get attribute with a bunch of ifs is the best way for this, until we get something like switch statements.

  • @Jack8680 Do you mean the Scene Editor setting of attributes is required before they're initiated in the Behaviour Editor, where they're created, edited and utilised?

    If so... WHY?

  • @Deeeds Attributes work by setting a certain attribute of a certain object, each attribute of that object is given a key, which is then used to get and set Attributes. You can either use Predefined keys, or you can use dynamic keys where instead of selecting a key you type it in (this allows for the creating of new keys while the project is running).

  • @Aidan-Oxley Yes, I got all that, the first 3 times.

    The problem is... they're not working in the Behaviour Editor.

  • @Deeeds How are they not working? First you actually have to give the object an attribute key and default value. Best way to do this would be to just find the attributes tab when selecting the object in the scene editor, then press the plus button. After creating an attribute, if you select the object in get or set attribute, the attribute should come up in the Predefined list.

  • @Aidan-Oxley Why in the Scene Editor?

    They have no use in the Scene Editor.

    Why this extra round trip out to the Scene Editor to "create" something that's already been created?

    What am I missing from understanding what these things are?

Log in to reply