Jump to content
  • Advertisement
Sign in to follow this  
smokyturbo

Determining next player state / animation (ECS)

Recommended Posts

Hi all,

I'm having a bit of trouble working out how to handle transitioning from one player state to another using an ECS, particularly with respect to determine the next animation to play.

For example, some of my current approach includes logic such as:

-> input system processes key down (left)
-> raises "intent event (left)"
-> intent system sets player vel.x
-> raises "started moving (left)" event
-> animation system plays appropriate animation

Now I have introduced jumping/falling, I'm not sure how to handle situations like the following:

In the collision system:

Player lands on ground, should we play the running animation or the idle animation? Depends on whether left/right input is held (which only the input system knows about). Or we could look at the player's x acceleration (but this doesn't necessarily mean left/right input is down, it could be due to some other force).

Do I raise an event to tell the input system the player has landed which then checks the current input state?

Do I need some sort of player state enum (within a state component?). Is there a corresponding state system, or is it up to all the other systems to update this as necessary?

Then there's situations such as when the player finishes firing a gun, should we change to running or idle animation? What drives this change, the animation system when the "fire" animation finishes?

All advice welcome as always,

Thanks

Share this post


Link to post
Share on other sites
Advertisement
On 4/6/2019 at 5:16 PM, Alberth said:

I wrote an article about animation handling and input a few years back, maybe it's of use to you...

Cheers for that, a very interesting read.

I definitely think (a) state machine(s) are looking promising. I've started off with a simple one.

I wasn't sure how things that happen outside of user input would work alongside a state machine, so for now I've just hooked the state machine into the event bus so it can receive events from other parts of the game code.

So for example, when the collision system detects than the player has landed on a platform, it sends a "landed" event which the state machine picks up. The "falling" state responds to this event and transitions the player into either an idle or running state after it checks the current keys pressed.

One thing I've noticed is that currently I have "LeftRunning" and "RightRunning" states, which obviously share nearly identical code, just with the directions reversed. I'm not sure yet whether to create a single "Running" state and parameter-ise it with a direction or not.

Share this post


Link to post
Share on other sites
13 hours ago, smokyturbo said:

So for example, when the collision system detects than the player has landed on a platform, it sends a "landed" event which the state machine picks up

You mixed too much duties to collision system. The collision system should only do one thing: check if the player is blocked, send the event "block" (not "landed"). The FSM handles the event, and check if the blocker is ground, and the player was not on the ground, put the player to "stand" or what ever.

One system only does one thing.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!