Announcement

Collapse
No announcement yet.

UFSM: Finite State Machine

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    I see. Although uFSM is really nice, I'm looking for an asset that has a custom editor as I need it to be extended. Thanks for the discussion, I hope one-day uFSM evolved into what we discussed above. Cheers!

    Leave a comment:


  • replied
    No, I don't want to use custom graphs.
    Once they are added in, the possibility of having undetectable bugs is exponentially bigger than just let the engine do its default thing on Details Panel.

    I cannot afford that possibility, I need the component to be solid even though isn't pretty.

    Leave a comment:


  • replied
    BTW, is the FSM editor a custom editor? or you are just using Anim BP? If you are using Anim BP, it might be difficult to extend it for HFSM or even adding BT node. If so, I'm sorry for asking for the wrong feature request.

    Leave a comment:


  • replied
    Hm... I'm not sure but it looks like Main and Base are independent of each other and it's more like hardcoding states using programming. Emulating HFSM is not difficult. If you make multiple states running in parallel, in theory, it's HFSM. But my point is that it's really difficult to understand what states are running at the same time and how each state related to each other. To make a proper HFSM, we should be able to show the relationship on the diagram. By looking at the diagram, we should be able to see what states are in the stack.

    A basic FSM can be viewed as having one level deep Stack and all Transition(wire going from one State to the next State) is just basically Jump state(pop and the push) in terms of HFSM.

    HFSM will have more than one level deep Stack and each Transition can be either Push or Jump state. So we need to modify HFSM editor to show the two different types of Transitions.

    To explain about HFSM Transition, Transtion can be either Push, or Jump. Also Transition can be tagged if the Transition is will be returned to the previous State (Auto-return Transition) or not. Many State Transitions are temporary for example, Idle -> Attack -> Idle. Attack is a temporary State and Idle->Attack Transition is an Auto-return Transition. Since it's returned to Idle State automatically(unless interrupted), we don't have to show a wire going Attack->Idle Transition in the diagram. It will help simplfy the diagram.

    The whole point is that we need to do this in the State diagram without resorting to programming or BP graph. Otherwise, I wouldn't have brought it up.
    Last edited by ChrisK; 10-01-2020, 09:54 PM.

    Leave a comment:


  • replied
    I understand what you are saying, but with these nodes, I would do something this:


    On Character graph add a "Main" (BaseState):





    and within "Base" graph would do this:





    The results are the same, what matters is then what "Actions" on each State node will do when that node is ticking (node stops ticking when On Exit wire is called).
    In that case "Base" graph is still always ticking while alternating between Idle/Attack graphs and Actions;

    Leave a comment:


  • replied
    RFSM looks interesting and useful as you can layer actions. It's more like having multiple Action Components in Stack and I'm afraid it's not the same thing as having States in Stack.

    When people talking about HFSM, they often have different ideas. Most commonly mistaken by nested FSM ( FSM within FSM). It's a useful concept but it's not HFSM.

    HFSM requires having States in Stacks and you should be able to dynamically manage the States in the Stack at runtime.

    A simple illustration as I mentioned above can be given by the common damage handler. It works like this. I'll try to use just Idle, Attack, and Death states to simplify the illustration.

    1. First of all, you will need to have BaseState and put common event handler(such as damage in this case). Within this BaseState, you will implement a damage event handler. Damage event handler will react to damage, decrement health, and if the health is below zero, go to DeathState and so on.

    2. When first running HFSM, it will first push Start State into the stack. In this case the BaseState.

    3. Create IdleState and AttackState. When there is no event, IdleState will be pushed into the stack (now you have BaseState and IdleState in the stack).

    4. If attack input is pressed, you will pop IdleState and push AttackState(now you have BaseState and AttackState in the stack). This pop and push is commonly used and we can call it Jump stack or Replace stack.

    5. When attack is finished, it will pop AttackState and push the default IdleState into the Stack (now you have BaseState and IdleState in the stack)

    As you can see, BaseState is always at the bottom of the Stack so that it can deal with damage event at all times.

    An interesting situation is that when damage is received while attacking, the damage handler in the BaseState will send the state to Death. BaseState is at the bottom of the Stack, therefore, it will pop AttackState first. This way, you can have a nice interrupt mechanism as the bottom State can cancel whatever it's doing on top of it.

    In summary, there are two things to implement HFSM.

    1. How to manage Stack: Push will just add new State to the top of the Stack, Pop will just remove the top of the State, Replace will pop the top of the State and push a new State.
    2. How to deal with events: events are handled from the top of the Stack to the bottom Stack. Top States always have the first chance to handle the event, and also it can override the bottom Stack event handler.

    I hope I explained it clearly. I have seen some online doc that talks about but I can't find it now. If I find it, I'll post it here.

    Cheers!

    Leave a comment:


  • replied


    "Reactive State Machine" (RSM) is an Action Stack based Hierarchical FSM system that can be added as a node to any blueprint's uber graph, including the graphs of a FSM Component, within another RSM's graph or itself's graph... and because of that, they can become very complex really quickly however powerful.

    You can create 'Action Blueprint' classes and add/remove them to customize each Node/State behavior, making the node to be its State and Machine itself.

    I haven't talked much about them because it's not heavily used on projects I work and I haven't finished 100% development on them yet, there are points they can be improved;
    But I talk a bit about them here:

    https://forums.unrealengine.com/unre...41#post1717741
    https://forums.unrealengine.com/unre...17#post1805517


    There's some major game project out there using this system and it's weird that they know more about it than I do, they have been implemented tons of 'Action' blueprints and have these State/Node running everywhere, but I haven't received any serious feedback yet.

    Leave a comment:


  • replied
    BTW, I read about HFSM being reworked on. Is it still the thing? or just a smoke in a chimney? I'm familiar with HFSM but I haven't seen a good implementation since Serious Engine days. I also saw Stack-Based FSM in Unreal Marketplace. I really haven't used it to say it for sure, however, they seem to get the implementation right. To properly implement it, you have to use Stacks to represent the hierarchy.

    Why do you want to use HFSM? It can help to simplify FSM quite a bit by sharing States. A common use-case, for example, is Damage. Whether you are in Idle, Attack, Patrol, they will all have to deal with Damage.

    If you are using HFSM, you can put the Damage state at the bottom of the stack and push other states(Idle, Attack, Patrol) on top of it. This way you don't have to duplicate damage handler to individual states. Basically, HFSM allows you to modularize the States by combining several States to create new States. Combining States different ways can give you very interesting behaviors. And this behavior cannot be emulated in BT. BT and HFSM is totally different animal.

    Anyway, it's not super critical but it's a very sexy feature if you are looking for improving uFSM.
    Cheers!

    Leave a comment:


  • replied
    Wow, so quick! I really appreciate it. Yeah, the better visualization can come later but it looks like it will do what I asked. I'll give it a try and let you know how it went.

    Leave a comment:


  • replied
    Originally posted by ChrisK View Post
    Do you think we can add a node that calls BT in UFSM?
    FSM Blueprints (Components), I am adding a system where you can link Behavior Trees to a particular uFSM State.
    You will have to link them from your FSM's Details Panel, I did not have the time to make visual graphs for these "linked" things.
    When you change your "State Tree" array from Details Panel, "State Bahavior" slots will open so you can attach a BT to a particular FSM State...
    State will abort given linked BT when that state is exiting, and restart the BT if that State is active again (FSM's c++ runtime will deal with activating them on enter/exit state changes).

    Obviously they will do nothing if the BT is not set or the owner of FSM Component is not a pawn controlled by AI Controller.
    For "Action" graphs of a 'Reactive' FSM node, I have included these nodes that can be used to control BTs:

    Last edited by BrUnO XaVIeR; 10-02-2020, 09:12 AM.

    Leave a comment:


  • replied
    Awesome! If there is a roadblock, please let me know. I'll try to file a request to Epic. Cheers!

    Leave a comment:


  • replied
    Okay, I will keep this noted and see if I can come up with plausible result.
    Majority of Behaviour Tree system is locked behind private/protected implementation so I don't know how far I can go, but last time I checked this was several engine versions ago. Maybe things are more exposed now, we'll see.

    Leave a comment:


  • replied
    I guess the difference is that you will have to write such functions every time you call BT. The function has to make sure it stops previously running BT when entering a new state and also to stop the current BT running when exiting the state. It adds quite a few steps and error-prone. And visually it's not clear if it's calling BT looking at UFSM diagram. You will have to open the graph to search for it.

    Having a special BT node to FSM will automate these steps and it's much cleaner and visually easy to track what's going on. I'm wondering, how hard is it to add a custom node?


    Leave a comment:


  • replied
    ChrisK I understand what you're saying, but what would be the difference if you use the already existing "Run BT" node from within a uFSM "On Enter" state function ?

    What would be the necessity for C++ integration which that above cannot achieve..
    I mean, the node already exist in Blueprints engine. What exactly is the path you see could be better?

    Leave a comment:


  • replied
    I like to clarify why having both BT and FSM to work together can be a very powerful concept.

    Both BT and FSM have their own advantages and disadvantages.

    FSM is good for representing overall AI (large granular) states such as Idle, Attack, Flee, Patrol, and stuff.
    And it's up to the user to implement what each state states do.

    BT is good for implementing specific AI task(fine granular), like Attack(a state) behavior. Having a BT to represent many behaviors(states) in a single large BT can get out of hands very quickly.

    Therefore, using both FSM and BT together can complement each other very nicely.

    I've used such system (Nodecanvas Unity) for good success.

    If we can call "RunBehaviorTree" directly from UFSM, it will allow us to work with BT and FSM as I suggested.
    The attached image shows some states (Patrol, Attack) is just calling BT from Nodecanvas to give you some ideas.
    In other words, a state can be represented by BT.

    I hope it makes sense.

    Do you think we can add a node that calls BT in UFSM? If so, it will make UFSM very valuable and I would really appreciate it.



    Attached Files

    Leave a comment:

Working...
X