Help needed! Multiple animations for character movement?
Hello all, we are building a side scrolling platformer and I was wondering how to rig multiple animations for our main heroes movement.
What I am after is the best approach to triggering animations without overlapping any of them. So far I have an idle animation for when the character is idle and separate run animations for both left and right movement. These are triggered by Boolean attributes. Is the method basically having a series of rules checking attributes and running the animations?
I am hopefully looking to set up the following...
All of these will need LEFT and RIGHT animations.
-idle animations. These would be used for once the character has stopped running left or right.
-Running.
-Shooting while standing still.
-Shooting while running.
-Jumping.
-Dashing.
-wounded.
-Death animation, no left or right needed.
Any advice would be appreciated
Cheers.
Comments
@zoogamingnz@gmail.com
instead of booleans for each type of action, I prefer to have one integer state attribute:
0 = idle
1 = running left
2 = running right
3 = jump left
etc.
or states for just the actions and a separate attribute controlling the direction.
These methods prevent conflicting states.
Just set the state attribute in your controls and trigger the appropriate animations accordingly.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Cheers man this and another post I found by old_kipper did the trick.
For anyone else searching this issue check out the link as well...
http://forums.gamesalad.com/discussion/22283/need-help-in-problem-related-to-animation-loop
I wanted to add that on top of the integer method that was suggested, which is the most optimal. Using the "else"{windows} or "Otherwise"{Mac} part of the rule set makes transitions from each integer state quite smooth. For example,
You could put the main rule as "if not = to 0} and have the idle animation in else, while the other rules in the "do" part.
Or you could do it in reverse, and have the 0 integer be "do", and then move on to else for 1-3, but when you get to the else, make another rule within it, containing the proper dynamic relationships of 1-3.
For example, for mines, my favorite is the transition from default speed>moving fast>moving faster. Where if the conditions for moving faster are met while in moving fast state, the animation for moving faster plays, since it is within the same rule{I can't remember which is in the "do" and which the "else".
Anyways, I soon as I utilized else and organized them in a manner where they relate to each other, I stopped getting "animation glitches", which turned out to just be conflicting animations from the old method which was to just put each state in a separate rule and one after the other{if doing it this way, even if you put them in order, sometimes one of the animations will try to play during anothers due to it's condition being met for a second, the integrated method makes sure only one at a time is really happening.}
But one issue is with multiple states otherwise will be an issue. Best method is stepping and integer as was suggested as the variable can only be one number at a time. This virtually eliminates crossing up the logic.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
For all i am using one flip horizontally and game.position att
when i press left move change attribute flip horizontally to true and change game.position to 1
when i press right move change attribute flip horizontally to false and change game.position to 2
after that you need to use game.position attribute right.
like this
if i press shot ; if game.position 1 he will shot to left with animation
.
.
.
something like that.
@Lost_Oasis_Games My mistake, I just remembered that the reason I had my code the way I described was due to extra attributes that activate UI elements and calculate damage prior to it being applied on the enemy{and reduce calculations done during that step}. Which then required me to organize them that way, since the values that weren't part of the integer could cause glitches. The method using the Integer by itself is sufficient for this thread's animation dilemma.