Hi Guys,

Wondering if I could get your thoughts on handling complex animation states? As my code is starting to get a bit spaghetti.

My player uses acceleration and deceleration to get a nice feel. But, things are starting to get complex as I add more states.

For example, if my player runs to the right, it accelerates nicely and decelerates if right is no longer pressed. If I push left (while the character is running right) deceleration is greater and I then play the turning animation and then eventually start accelerating in the other direction, back into a run sequence.

It starts getting more complex when I decide that I change my mind and want to run right again (mid turn), reversing the turn animation.

If have this all coded and working ok, but I have so many 'if' statements already. 

There is a bunch of other things I want to do also, jump, climb, etc. Which will all have there own transistion animations also (like the turn animation does).

I'm just wondering how I can structure this better and get on top of the code logic before the actual code gets unmanageable.

Normally I would have clear states setup, but the added complexity of acceleration, transition frames, and being able to opt out of the action (in some cases - like turning) are making it difficult.

I'd love to know what the best approach would be in this scenario.

Thanks in advance

Sounds like you might need to employ some software design patterns in your code.

For example, this could be of use:  http://gameprogrammingpatterns.com/command.html 

Possibly, this could also be useful reading: http://robert.zubek.net/docs/games-studio-2016/8-software-patterns.pdf

Thanks! I'll certainly have a read.

I certainly do need some sort of design pattern

masskonfuzion - Just had a quick read over these. Not too dissimilar to what I have going on at the moment. I might be able to glean a few tips from the articles though. Thanks again

If those articles aren't too dissimilar to what you're doing now, then you're probably in pretty good shape! :-D

The idea behind those patterns is just to cleanly organize the logic.  E.g., a command pattern implementation, or state machine implementation (a graph/node-based approach, not a hard-coded if/then/else approach) is very flexible, and scalable.  Logically, they're not different than if/then/else, they're just easier to maintain.

Cool, thanks man

Professional games usually handle animations and transitions between them as a state machine. This is a data structure that includes all the possible animations, the ways one can transition into another, and any conditions for such transitions. You probably need something similar.

Kylotan - Yeah. I suspect so.

I have a state machine for the animation states themselves now and it is extremely clean and nice. But, I am still struggling with the structure of the conditional code.

For example, this is the basic concept of what I need for a run / turn condition.

• Player starts IDLE when there is no input (no problems)
• Pressing right goes into the RUN cycle state, frame number and speed are acceleration based (no problems)
• Player then holds left and the TURN sequence initiates. Player decelerates.
• Player can then hold right and opt out of the turn. Requires a reversal of the turn sequence and apply acceleration again.
• Or the player can continue the turn and complete the turn sequence.
• Or the player can release the key, decelerate speed back to zero, and move back into the IDLE state.

There is probably more conditions (and there will be once jumping, running and then crouching, etc.. get applied).

Given the small example above, how would I stop this from exploding into a massive 'if' 'else' mess?

Currently the acceleration and deceleration components of my code are working great. It's the matching up of the correct animation sequence that is causing me the grief.

Thanks again for your help guys

The state machine needs to contain the conditional transitions as part of each state in which they're relevant. For the current state - whatever it is - there are probably only 2 or 3 possible transitions out of it. Either the animation finishes normally, or a button is pressed and it transitions to one of the other states.

A brief analysis of your situation suggests you have these states, each corresponding to 1 animation:

• Idle (loops, can transition to Run Right or Run Left)
• Run Right (loops, can transition to Idle or Turn Right to Left)
• Run Left (loops, can transition to Idle or Turn Left to Right)
• Turn Right To Left (one shot, can transition to Run Left or Turn Left to Right (maybe starting partway through))
• Turn Left To Right (one shot, can transition to Run Right or Turn Right to Left (maybe starting partway through))

Each state only has 2 transitions, so the conditions aren't that complex. The only awkwardness is being able to bail out of a turn half-way through, but if your turn anims are closely matched, you can ask to transition to a specific frame of the next animation in order to perform the change smoothly.

A bit of self-advertising but maybe my state machine article can inspire you