Jump to content
  • Advertisement
Sign in to follow this  
VertPingouin

Precision on StateMachines

This topic is 1411 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi everyone,

I'v a little issue on how I should implement a state machine logic in my game.

(as described in http://www.gamedev.net/page/resources/_/technical/game-programming/state-machines-in-games-r2982)

 

I'm programming a platformer and state machine logic seems fine for it except for one particular case.
Let say I've three states for the player, idle, walk and attack

  • idle is the beginning state.
  • walk is triggered when pressing a direction and end when this direction is released or when another state is called.
  • attack is triggered when attack button is pressed.

All of thes states are neighbors from each other : each of them can transition to one another.

But if I press a direction, then the attack button (without releasing direction), when attack state is expired, the character should transition back to walk.

There's a bunch of solution tha crosses my mind for that but I'm not sure what's the best :

  • character has an internal state walking or not triggered by direction down and direction up, which is used to choose the next state after attack. It seems a little clumsy as it is kind of a parallel state machine.
  • adding an input event "direction pressed" in addition of "direction down" and "directionup" which is fired in event queue from the moment direction is pressed until it is released, walk event should be now triggered by this event.

or other things I hevn't thought of.

What do you think ?
 

Edited by VertPingouin

Share this post


Link to post
Share on other sites
Advertisement

Sorry, my bad, the link wasn't the intended one. I corrected it.

 

Thank you for you're answer, I'll look a deeper into it.

 

1,2)

I consider more and more having two state machine because the case I described is not really the only one after all. I realized that in 2). As my game is 2d, there is actually two direction to attack so instead of just having an attribute facing left or facing right, it could be another state machine... Then I realized there are more states than I thought (attack while in mid air, facing left, right etc...). Even if sprite and hitboxes will be the same inverted, that's different states ! 

 

The fist would be conditionned by my movement vector (walking_right walking_left, falling, ascending...)

The second by the input (attacking, jumping, countering etc...).


Another way to do things when I look at 3), is having more states with different default next state. In my case, a attack (idle neighbor) that leads to idle state and a walkattack (neighbor of walk) that leads to walk state, even if these two states are resulting in the same animation...

 

4) The stack thing is tempting but seems too generic for what I want to acheive. I'll think of it if I ever tried to do a versus fighting game !

5) I really want it to be explicit because I'm working in collaboration with another game designer, who's not a programmer at all.

 

 

States machines are more complex than I thought, but I still stick to it because I feel it might prevent complex bugs (which is worse !).

Share this post


Link to post
Share on other sites
For my little hobby projects I've started taking cues from more complex 3D games and going for a full data-driven animation state machine that drives all game character behavior. It actually simplifies your code quite a bit as it allows you to tie behaviors to events and state variables purely in data and decoupling all of the messy game logic from any hard-coded state machines.

The animation data gets more complex but everything else gets simpler. It's also much more easily data-driven. There're tools for building nice animations (2D or otherwise) using the approach.

For instance, characters have a few states: standing idle, walking, running, jumping, attacking, being hurt, etc. You can make copies for each direction or you can use state variables. All player input ends up being routed into the animation, the animation makes determinations as to whether a transition is legal (e.g. the hurt animation takes 0.5 seconds and has no transitions available until it's complete, effectively stunning the player after being hit... if you want to set it up that way). Likewise, the walking animation exports a "speed" or "impulse" variable that the character controller binds to the physics object, meaning that the animation can be in full or partial control of whether the player can actually move (and how fast). The player controller's job then is mostly just to route interesting events into the animation, feed it with state variables (is Left being pressed, etc.), and poll animation state variables to feed out to other systems. The animation can also trigger events during animation timelines or transitions for things like sound effects, particle effects, etc. so you can get accurately timed and synchronized footstep effects, timed attack hitboxes, and so on. Attachment points controlled per frame likewise let you do a lot of things.

The animation states can be easily specified in XML or JSON or whatever and edited with a number of different animation tools. Creating animations becomes more complex but far more powerful and flexible for the content creator and the total amount of code needed for new characters or AIs drops quite a bit.

That's all pretty much how we build skeletal animations and designer/artist-controlled character behavior in big 3D games. As much as possible it offloaded to the animation. A component might end up supplying some additional configuration data (e.g., speed scalars combined with animation movement outputs) but it does relatively little actual work.

The problem with hierarchical state machines for player control is that they don't match up with animations. Sure, yes, you can be walking left indpendently of whether you're attacking, but the resulting animation you play is very much dependent on both of those states. If you have completely independent hiarchical states then you still end up needing a full animation state system that can transition to the proper animation based on both controller state inputs. Or you can use a split player sprite (lower and upper torso) but the results of that make your game look pretty sub par.

Share this post


Link to post
Share on other sites


What do you think ?

 

i think you're tracking two states (moving and attacking) with one state variable.

 

as frob says, you can enumerate the combos as a single state variable, or use individual state variables, as described by sean:

 


If you have completely independent hiarchical states then you still end up needing a full animation state system that can transition to the proper animation based on both controller state inputs.

 

in a recent refactoring of AI code in my own project, i got good results switching from a single state variable to multiple state variables. and as sean says, you need an animation system that can draw whats required, whether that data is stored in a single state variable ,or multiple state variables,  in my case, the possible combos of taking fire, recovering from collision, resting due to fatigue, following orders, hunting, grazing, sneaking, moving, attacking, etc made multiple state variables the only real way to deal with things

 

.

Share this post


Link to post
Share on other sites

Thanks for thes enlightening answers. I know have a clearer vision of what I need to do :

 

2 state machines : action and movement (where attack is an action and walk a movement), and a bunch of activities corresponding to combination of states.

A can have object can have of course only one activity at a time.

  1. Player start moving : action = Idle, movement = walk >> walk activity
  2. player pushes the attack button without releasing direction : action = attack, movement = walk >> attack activity
  3. attack animation ends, action return to idle and movement still = walk >> walk activity

Share this post


Link to post
Share on other sites


2 state machines : action and movement (where attack is an action and walk a movement), and a bunch of activities corresponding to combination of states.
A can have object can have of course only one activity at a time.
That may be an option for your code, but it is not an option frequently taken in bigger games.  Usually locomotion (walking, running, sprinting, crawling, etc.) is considered an action or activity itself, and is not allowed to be mixed with other items.

 

If your game is built such that the two are truly independent, that is, an attack is entirely upper body and does not involve the legs at all, then it may work.  That will probably not work in practice, because compelling attack animations involve the full body. Without it either the swings will look feeble or the body will appear horribly out of balance.  I imagine their legs are daintily running while their arms are involved an a half-body body-slam, not slowing the legs nor using them for force or balance.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!