2D Platformer - Character State Machine

Hey all.
I'm working on a mockup of MegaMan (well, at first, just to get the gameplay and basic design right, later I will work on its own individuality).

I've been thinking about having the game designed with FSM implementation in most things.
I've been playing around with the FSM design, but I want to know what do you think? What would you suggest? Any missing states?

Format: State Name (From, To, default?) -> Basic information

A MOB (Mobile Object) has 4 FSMs;

• Movement State Machine
• Weapon State Machine
• Vulnerability State Machine
• AI State Machine

Movement State Machine:

• Idle (From Any, except Ascend, to Any, Default) -> No user input, different idle animations
• Move (From Idle, To Any) -> Moving left/right
• Ascend (From Idle, From Move, to Descend, to Damage, to Climb) -> Ascending duringa jump
• Descend (From Any, to Idle, to Climb, to Damage) -> Falling, descending after a jump
• Climb (From Any, except Damage) -> Climbing up or down a ladder
• Damage (From Any, to Idle, to Descend) -> Damaged state (in MegaMan, the blinking state)
• Disabled (Special, dead/menu, cutscene) -> No calculation, ignores user input

Weapon State Machine:

• Idle (From Shoot, To Shoot, Default) -> Not shooting
• Shoot (From Idle, From Shoot, To Idle, To Shoot) -> Check if can shoot, shoot
• Disabled (Special, dead/menu, cutscene) -> No calculation, ignores user input

Vulnerability State Machine:

• Vulnerable (From Invulnerable, To Invulnerable, Default) -> Can get damaged
• Invulnerable (From Vulnerable, To Vulnerable, After getting hit - for a duration) -> Can't get damaged
• Disabled (Special, dead/menu, cutscene) -> No calculation

AI State Machine:

• Disabled (user-controlled, dead)
• Cutscene (for cutscenes, intro, etc...)
• Idle (Doing nothing, idle animation, padding between ai modes)
• Routine (Routine action, e.g. moving around)
• Chase (Found a target, chase it)
• Escape (Found a target, run away from it)
• Assault (Found a target, within assaulting range, attack it)

Each FSM will be connected to a part of the character (Vulnerabily to the HP script, Movement to the movement script, Weapon to the weapon script, AI to all of them) but they will also have some access to each other (Shoot can only happen during some Character states, Vulnerability has access to the Character state "Damage", for instance)

 

It has been moved?
Is that not game-design related?
It may not be feature-design, but still a game-design choice...
Oh well.

 

I really hate bumping, but I do want to hear your opinions before I go too deep into it.
Also, do you know of a good FSM (code-based!) implementation? I've got PlayMaker and BehaviourMachine, but they are visual.

 

Interesting 'design' layout MrPriest.

I am using PlayMaker at the moment, and I have no suggestions regarding code fsm systems, unless mecanim is considered that.

Here are my - vet artist, novice designer thoughts.
I'm not really clear on your MOB logic, and it may be due to my lack of experience. If I'm understanding your post - your only talking about your main player character and weapons for that character.
In movement your basically describing mecanim, and I gather these are animation cycles. I don't understand why you break down movement and vulnerability, again maybe because of my limited experience, I think these two could be combined with each movement state being either vulnerable or invulnerable. Only two movement states actually encompass disabled so these could transition off of any state.

Weapon SM and AI SM really describe animation states also, so just sitting here typing, it seems those could be in the same fsm as well. Unless weapons save power, charges, bullets etc. That's why right?
I can see Cutscene logic and health and/or power (buffs for player and/or weapons) being completely separate.

With my limited PlayMaker experience I think player movement fsm and weapon fsm would encapsulate your initial character design, with cutscene logic in it's own fsm with unique character and weapon fsm's if needed. I don't think I'd populate game play logic with cutscene logic - even if I was using the same assets, though for efficiency purposes I can see your layout being more optimized.
And a game manager to handle global variables such as health. (Is health considered a global variable since it is shared between more than one fsm?) If enemies use the same weapons and all weapons have power, bullets etc maybe the game manager could handle both weapon power/bullets and health.

Respectfully interested in your response, decision to break down into these 4 fsms.

bumps are fine around here as long as you give a day or two. bumps within hours is kind of pushy and annoying imo.

 

Thank you for your reply!
I am not experienced at all, for years I've been making small projects that never saw the light of day, so I've had a lot of thinking time, but nothing that shows result.
You can say I am experienced in theoretical design and never implementing it 100%

The reason I wanted to separate the FSMs is so it would be generic, and easy to implement on both enemy and player.
Having one FSM with all of these states (excluding AI) means a long FSM. I figured I can cut a MOB into a few objects (body/transform, weapon, hp) so I can manipulate each of them separately, having much less FSMs to worry about, as well as animations.

Rather than having "moving, moving + shooting, moving + flashing due to being hit, moving + shooting + flashing due to being hit" fsms, I would have moving, shooting, and vulnerability. Moving is moving, if shooting, then the weapon is extended, if not, it's moving with the body (yeah, I'll need to cut the sprites apart!) and if you were hit, it would add a flashing effect, as well as disable damage-taking.

However, this seems to be very complicated, so maybe I should just go for the normal one-dimensional FSM.
But it feels wrong to give up on the idea without completing it and comparing, so I'll probably do just that.
Sadly I don't have much time after work (or will! I am programming as a day job as well!) so I wanted to ask for more opinions

I am currently trying it with Behaviour Machine, it's not ideal (because each state seems to be it's own script, rather than one FSM script with all the states, though that might be possible? I'll give it a try) but it works well, with all the utilities it offers (state debugging, the FSM itself works well, etc...)

Also, I don't think the variables (ammo, hp) need to be global, just have the FSMs under one prefab that manages them all.
Another reason I think it will be problematic, is the amount of FSMs, it might be hard on a mobile device, but it might also mean less resources and code, so who knows... I'll have to keep on working on it.

 

Thanks for your response.
I'd like to see the fsm logic you end up going with when you've worked it out.
I'm currently 'fiddlin' with similar stuffs.

 

Thank you, I will make sure to post here my findings