Handling non-finishing actions with multiple state responsiblities?

[Grofit]

I have asked smaller questions focussed around bits of this problem but I was trying to re-model to use sub-fsms (RunFSM) to split out responsibilities but I get stuck trying to model some of the more complicate behaviours.

So for example the scenario I currently have is my player's FSM listens out for any movement key to be pressed then starts a sub fsm which handles movement and animation of the movement.

So in the sub FSM, at a high level it turns the player based upon their left/right axis changes and moves them forward or backwards based upon their up/down axis changes (with a base movement speed factor).

I have attached a screenshot of the high level view, and you can see how much is happening in the move action.

So just to go over it quickly the entry point sets the base movement speed to that of walking. Then transitions to do the main Move state, this will continually loop listening for state changes needed:

- Run button pressed
- Run button un-pressed
- No axis changes

Any of them will fire of an event which is pretty self explanatory as shown in the attachment. Once that is done it gets the axis changes for Vertical/Horizontal changes, rotates the model based upon the horizontal changes, starts calculating the actual movement speed given the vertical axis amount and the base movement score. It also sets the animator's speed variable so it will start animating while the player is moving. Finally once it has multiplied the direction by the actual movement speed calculated previously it does a simple move to have the character controller go to the correct place.

Now I have a few problems currently, some are design related which I can live with, such as the move state having responsibilities for state transitions which imo should live elsewhere, but I cannot find a good way to model that. Some however are logic related, such as the player can run backwards, which I do not want.

So to solve this problem I need to be able to stop the run button check based upon the direction of the vertical axis, however I cannot see a way to make this work. Most of the issues come down to the actions not all firing finish events, which make it VERY difficult to break down into smaller chunks. I have thought about making my own custom Move action which will check once it has moved the given amount and fire a finish, this would let me split out the actions into different states, however I was hoping I am overlooking something and there is a better way to model this FSM.

So is there a way I can break up my Move state into smaller states which feed into a movement state? as I cannot find a way to jump out of the state without doing all the checks within it, and even if I were to move my axis checks and calculations to a different state and then trigger the move state purely to do the movement bit, it would never leave it, and forcefully calling Finish will just overrun the FSM as it state changes too much (tried that before).

So has anyone got any ideas on how to better model this simple behaviour? as I want to nail this simple scenario before I go doing more complex ones.

[Grofit]

I have tried to go down the route of having lots of smaller different FSMs and it is working a lot better, but it is like a rabbit hole I am at 3 FSMs running together and will easily get to 5 when or more when I have to deal with:

- Pathfinding
- Animation
- Attacking / Movement
- Input Handling
- Inventories

and there are many other things. One of my problems with having lots of FSMs are that I am hoping to have lots of active entities on the screen like dynasty warriors and diablo mixed but I can see playmaker having a large performance impact with this, so am still trying to use less FSMs wherever possible.

[Lane]

Hmm so this is basically just boiling down to logic in the systems and how to best segregate the FSM's so they don't get out of hand.

Personally I would separate the above situation into an FSM that just collects input information and runs math that needs to happen every frame, a single state that just does all the background stuff. You can send the resulting information to the appropriate FSM's and have them respond asynchronously in clearly defined states for each behavior.

After you can understand which things can be done at the same time then you'll find out how much you need to separate the FSMs but its only done as much as is definitely required. For instance it might be best to make a Run FSM that just checks to see if the run key is down and changes the core Movement Speed variable and it would be great because none of the other FSMs would have to react to that change, they just use whatever speed the Run FSM is defining. This simplifies your FSM's as a whole and lets you delegate a lot of things for the sake of simplicity and it often avoids some common issues with having too make transitions that leave a state and return after changing some variable.

Theres nothing wrong with making more FSMs, you should first just define when its definitely necessary to do so, why you're doing it, if there is another way, the pros/cons, whats easier, better for the long run, etc.. and then it'll start connecting together nicely.

For animation I would recommend using Mecanim, really you'll probably delegate an FSM to handling a lot of the animation so you might as well just mirror some of your input data to mecanim and set everything up there, keeping your FSMs cleaner and simpler.