2D Turn Speed Consistency
I've been using Sprites Complex to set up a character that moves in a similar way to Broken Sword. I've gotten most of it working via mecanim, and for the most part I've been successful when it comes to things like movement and acceleration. The one thing that's tripping me up here is turning.
I've created two "turn on the spot" animations, one left and one right, and got the animator to enter the animations at different points depending on the starting direction of the character. So far, so successful, but I kept seeing the characters take longer than necessary on about 30% of their turns - as a result, the animation would keep on going, before eventually they would snap back to the target direction they were supposed to be facing.
I set up a script to measure exactly how long the turns were taking, and while most 180 degree turns were taking 17 to 20 cycles, some would last between 70 and 100, particularly those involving vertical directions.
To sum up, I just wanted to check whether there was a way to ensure consistent turning speeds - e.g. "180 degrees always takes fixed number of seconds"
Many thanks!
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Comments
As a visual issue, could you share screenshots/gifs to help understand the exact situation?
When using Sprites Unity Complex, turning speed should be linear. When you say 180 degrees, are you actually comparing the exact degrees necessary to turn, or is this more a case of "facing up to facing down"?
I ask because a 2D character still has a 360 degree range of turning - even if they're only perceived to have 4 or 8 facing directions. Depending on the character's starting direction, you could have e.g. 170 to 190 degrees to turn instead.
If this is what's going on, we could look into "snapping" the facing angle before turning - but to test first: try a pair of Character: Face direction Actions (first instant) to check the motion when moving along a fixed 180 turn.
Both - in gameplay terms, I've got the character facing directions (e.g. "face upwards to face downwards"), but am using degrees to measure how quickly the turn is taking place
So, essentially I've got a turning animation, which covers all 360 degrees. For turns of 90 degrees while standing, it works just fine, with a roughly similar turn speed for each change of direction, meaning that the animation fits fine since it's lined up in quarters.
When making turns of up to 180 degrees, there's a lot more variation in how long the turn takes, which is where it becomes evident in the animation not matching up with the stage of the turn the character is actually at. The ~180 degree turns take roughly between 140 and 215 cycles.
Turning before walking is where the turn takes a great deal longer, by the looks of it the lerping towards the final direction slowing down towards the end, meaning that the character's "turn" animation reaches and passes the target rotation before the character's own rotation has.
At first I thought it might be the animator misbehaving, so I cobbled up the UI to time the turns - the top number is how many degrees between the player's current and target directions; number 2 is how long the previous turn took (in game cycles); number 3 is the size of the previous turn in degrees.
My best-case scenario was finding a way to ensure that the turn speed always remained constant - that x degrees would always take a certain number of frames of the animation.
Having had a look at angle snapping, the best approach may be to simply rethink how I'm doing the whole turning thing in terms of the animating, and make the animation itself somehow dependent upon the character's angle. Right now it's an animation that always runs at the same speed, and has an offset time depending on which direction the character is facing when they start turning.
Apologies for the long post!
Interesting situation - and I like the animation!
The deceleration when turning-before-walking is evident in third gif. This is likely a bug - I'll look into this.
For the exact 180 turns (2nd gif), I wonder if this is related to the scene's vertical reduction factor, which is a means of scaling back vertical directions relative to horizontal (so that it takes longer to move to/from the camera than sideways).
You can check if this is contributing by setting the Settings Manager's Vertical reduction factor to 1 under "Movement settings".
Thanks! My experiments in rotoscoping seem to be working out so far.
On your suggestion, I had a go altering the vertical movement factor, and unticking the "Character rotations affected by Vertical Movement Factor" box below it, unfortunately neither appear to have led to the desired outcome in this case.
When testing the 180 turns, as in gif 2, there's some degree of consistency - they all take roughly the same amount of time (95-102 cycles), with the exception of L>R and R>L turns, which are between 140 and 155 cycles. It also seems that the 90 degree turns take the same amount of time as the (consistent) 180 degree turns, both about 100 cycles.
On reflection, I should probably just go for a simpler system of turning, rather than all this jiggery-pokery with the turning animations.
I've wondered how Revolution handled their 2D motion system before now. As a guess, I'd say each frame carries its own data about how much the character should move/turn when played - similar to Unity's Root Motion system.
Though, I'm having trouble actually getting the behaviour you're facing in gif 3 - i.e. the turn speed slowing as they approach the correct direction. What is your AC version?
If you're using the latest, it might be best for me to have a tinker with this myself.
Hm, that gives me an idea about using a scipt to adjust things frame-by-frame within the animation itself.
I am indeed up to date on AC, but in taking a slightly different aesthetic approach, I think I can probably get around worrying about this issue.