Animation (week 7) progress and challenges (WiP)

Animation:

  • Listed and prioritised animations
  • Attempted to animate die roll/damage, encountered a number of obstacles:
    • The movement speed makes it difficult to make a damage animation
    • The die starts off in any of 24 orientations and I’m not sure how to attach the animations to play correctly; currently rolling is done in code because the pivot origin can be determined from global coordinates, then rotation is incremented easily.
  • Keep the die movement in code perhaps. Use material changes + interface cues for bounce/damage instead which can be animated more easily?
  • Initial idea: to make walls and stationary enemies bounce on impact
    • Will that make them appear weak? No, not necessarily.
  • Enemy jumps / being squashed a better candidate for animation clips. UI also essential but assets not ready.
The “taking damage” animation of the die that I started working on could have worked in slow motion, but when sped up to the tempo of the game, it appeared too frantic and therefore difficult to read.
  • Made a pawn jump / move forward animation.
    • First, had to implement code for enemy movement. The trouble was collision – by watching for variables in the debugger I was able to come to the conclusion that collider positions are not where I expected them to be; the Internet confirmed my suspicions (Physics.SyncTransforms() to the rescue).
  • Implementing the animation came with its own set of challenges.
    • The setup had to account for the animation starting early so that there would be a wind-up; (thus the implementation of a PreNotify() function as an addition to the Observer pattern).
    • The transform of an animated object cannot be modified; but the pawn needs to be moved mid-animation. So an intermediate AnimationContainer object was set up.
    • The transform of the AnimationContainer had to be manipulated using the localTransform. This also meant that, for a while, I was accidentally applying the wrong rotation which confused me greatly.
    • Syncing up the end of the animation to the change in position – used an animation event for that.
    • The animation event method still occasionally caused flicker – due to the beat timer code running concurrently with the animation code. I thought it was the end of the road for me; fortunately I figured that a coroutine can pause execution until the next frame; that fixed it.

All in all, overcoming the technical issues to implement the animation took most of the time; I think it might have been easier if the game took place in a continuous space/time rather than in distinct space/time steps. The rotating nature of the dice will be another problem to overcome.

After implementing the animation, it turns out that it can de-sync from the beat. Not sure what is causing the problem – it is quite unfortunate – but I will have to leave it for now to focus on other elements.

Jumping animation in-game (when it works).

Sad state of the burndown chart:

Tasks prioritised as ‘Must haves’ are colour coded in red.

Leave a comment