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.
- 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.
Sad state of the burndown chart: