It's been over three weeks since the last entry where I wondered How To Implement Graphical Feedback in a roguelike. Thanks for the advice. I have been doing more thinking than coding. I am not happy with spending three weeks stuck on a problem, and I was questioning whether I was getting bogged down in a pointless obsession with having animation. Afterall most roguelikes, including famous ones, don't have animation and they play perfectly fine. In fact animation could easily reduce gameplay.

And that's one reason I have spent so long thinking about this. The other reason is that it turns out the animation solution chosen heavily influences the design of the turn system and the the way actions are performed. I didn't expect that, I was naively thinking animation was going to be some trivial visual thing, but no now I've looked into it I think it's possibly the most complicated part of the entire game. It's the only part of the game I can foresee that will be massively difficult and annoying to go back and change later, which is why I have been willing to spend three weeks to try and reduce the odds of that happening. I dread implementing some animation scheme and then in 2 months time finding a fatal flaw in it that requires a rewrite.

I have coded up a test implementation of the solution I reached that includes three test animations:

• Movement animation - the creature slides to its new tile.
  
• Melee animation - the attacker nudges towards and back again from the target.
  
• Damage animation - a number rises above the damaged creature indicating how much damage was done.
  
  Apologies for the poor video quality (the game graphics are not much better tho!) - plus there's no sound.
  
  [media]
  [/media]
  
  Some details:
  
  
  • Animations run sequentially. The cycle is Turn, Animate, Turn, Animate, and so on. I did consider parallel animations but there are huge problems with that. I'll probably write a post about it at some point.
    
  • The animation speed can be changed.
    
  • The player doesn't have to wait for all the monster animations to complete. Action keystrokes are queued. If there are keys in the queue then the animations run at max speed. In this way the response to user key presses is instant and animations take lower priority.
    
  • The damage animation is shown in real-time even if you skip. This is so the user gets a warning that they were hit even if they get over-excited with the key tapping.
    
  • Possibly most important: Animation can be disabled.
    
    It works well enough for me so far. There are minor downsides, it's made the code more complicated and less "pure" for example. I need to do more testing with more complicated chains of animations to make sure there aren't any annoying gameplay issues. I'll post about more implementation details once I've confirmed this works with more testing. I also need to record here all the solutions I looked at and the dead-ends I found, before I forget them.
    
    I'll still be implementing a message log at some point. The animations only go so far.