Battle interface

Animations of creatures

All animations of creatures in a battle are handled by storing currently displayed animations in pendingAnims vector. When server tells that an event requiring animation happens, info about it is added to pendingAnims. Every animation needs to be initialized (what indicates that this animation has started). show() function tries to initialize all not initialized animations every frame until it succeeds. Then nextFrame call-ins are called until animation removes itself from pendingAnims. During initialization it is checked if this animation can be played now or we must wait.

Showing sequence of stacks, obstacles and wall pieces

Firstly, all dead stacks are printed on the screen. Then alive stacks, obstacles and wall pieces are printed in order of appearance (number of hex they are placed on). This algorithm works fairly well if no creatures move, but due to the fact that while a creature is moving, its position is the destination, not the hex they are walking on, sometimes it makes some graphical glitches that are not easy to fix.

Desynchronization of state of the game and displayed animations

This problem is not limited to battles but here it is the most problematic. GameState is updated immediately after getting info from server while the player should see smooth transition between initial and final states, e.g. when one creature stack attack another one we should see decreased amount of creatures after the animation of attack is displayed, despite the fact that gameState contains the new amount before any animation is displayed. Sometimes it can even lead to crashes when an action of the user makes the battle finished in gameState but wants to see all remaining actions of stacks - but the engine cannot respond to new inquires and destroys all data about stacks that weren't duplicated by battle interface.

This issue can be partly resolved by stopping the processing of data from server but it's not widely used nor elegant solution.