jankuss / shroom

Room Rendering Engine for Retros
https://jankuss.github.io/shroom/docs
GNU Lesser General Public License v3.0
62 stars 28 forks source link

Enqueueing animations for room objects are problematic #122

Closed sindreslungaard closed 3 years ago

sindreslungaard commented 3 years ago

Currently when moving room objects with walk() or move() you are not actually moving the object immediately, but enqueueing it to be moved as soon as possible. Consecutively moving an object will eventually make it go out of sync with whatever is issuing the movement.

You can test this by moving a user back and forth between two tiles for some time. With the walk() function it will eventually stutter with no motion for a short period of time before catching up. This desync is even more notable when using move() and updating the directions of avatars manually; the avatar will start changing direction before it finished moving to its current destination (because changing the direction manually is not tied to the enqueued movement)

One way to try mitigate this is by calling clearMovement() before all walk() or move() calls. This helps the client get caught up to speed when tabbing out and back in after some time, but does not fix the desync problem as it does not clear out the currently ongoing movement animation.

One possible fix to this would be to make clearMovement() actually stop the current ongoing movement animation to allow for walk() and move() to execute immediately.

The best solution in my opinion would be to remove (or make optional) the enqueueing of movement animations for room objects entirely. When the server (or whatever is calling the move function) tells it to go somewhere, it should drop what it's currently doing and start animating to the new destination, from the previous destination (even if it didn't get there in time) immediately.

TLDR; walk() and move() on room objects should execute immediately rather than being enqueued

sindreslungaard commented 3 years ago

I realize now that the reason this desync happened so often for me is because (from what I can tell) animating an avatar from one tile to another takes longer time in shroom than the flash clients. Changing room ticks from 500 to 530ms serverside makes consecutive avatar movements pretty smooth without desyncing for a long time.

jankuss commented 3 years ago

I think it would be good to remove the enqueueing aswell. It seems to create more problems than it solves.