0
\$\begingroup\$

I developed a playing cards web app using HTML/JS/CSS. Communication with the server is performed using WebSocket. The server is developed in Java Spring.

The game proposes to join one of the many available tables where you can immediately perform an action.

The players who are already in the table are perfectly in sync with each other, as when they receive a message from the server, I show a screen overlay preventing them from clicking on any element on the table while an animation is running. After the animation is terminated, the game becomes available and runs normally.

My problem is that if a new player joins the table after a message has been sent by the server, then he can perform an action while the animation is still running for the other players, thus starting a new animation for them at the same time and the game becomes messy.

Is there a way to either prevent the new joiner from performing an action before the animation has ended for the rest of the players ? Do you have any other idea how I can solve this issue ?

Thanks for your help

\$\endgroup\$
9
  • 1
    \$\begingroup\$ It sounds like your problem is relying on animations to drive what actions are allowed. That should be driven solely by your game state, and the animations should only reflect that state, not drive it. If I join a table whose game state says I am not permitted to act, my client should not offer me affordances to act, and the server/other clients should reject any requests for action that my client sends until the game is in a state where those actions are valid. \$\endgroup\$
    – DMGregory
    Commented May 4, 2020 at 20:54
  • \$\begingroup\$ Thanks @DMGregory. Actually, the animations do not drive the game state at all. The animations only run once the game state is updated and may take up to 20 seconds to terminate. If a new player joins the table, the game state is already updated and the new joiner is allowed to perform an action. The issue is that the animation has not ended yet for the other players who were already present in the table. I hope it is clearer. \$\endgroup\$
    – Mehdi B
    Commented May 4, 2020 at 21:03
  • \$\begingroup\$ It it's not yet safe to process the action without getting "messy", then you should not yet be in a game state that permits the action. You should have an intermediate game state that blocks interaction until you're ready to handle a new interaction. \$\endgroup\$
    – DMGregory
    Commented May 4, 2020 at 21:08
  • \$\begingroup\$ The issue with this is that the game state should be updated to allow a new action once the animation for all players have ended. This means all players need to send a websocket frame to the server once their animation has ended. this will make the game slower I suppose since the server needs to wait for all the players in the table to send the frame \$\endgroup\$
    – Mehdi B
    Commented May 4, 2020 at 21:20
  • \$\begingroup\$ That's driving your game state off the animation, which you don't want to do. Instead, put the game into a waiting state that lasts a fixed duration. You don't have to care about the animation, only whether the wait is completed. And you can verify that with a timestamp, no communication required. \$\endgroup\$
    – DMGregory
    Commented May 4, 2020 at 21:24

2 Answers 2

1
\$\begingroup\$

I would invert the logic from "You are allowed to do anything unless the server told you there is an ongoing animation" to "You are only allowed to do something when the server tells you that it is your turn".

The result would be that any new player joins in a state where they can't do anything (because they didn't receive the "It's your turn" message yet). Their UI would not become active until the server tells them that it's their turn. Which it would do immediately when there is no ongoing animation, but would delay if there is an ongoing animation.

\$\endgroup\$
0
\$\begingroup\$

Thanks to @DMGregory insights, I think the best solution is to put the server in a paused state for a fixed duration allowing the animation to be completed before starting to accept new requests from other players.

The drawback is that there might be an overlap of animations due to the latency between players having slow/fast connection speeds. But this would happen very rarely as the new joiner has to perform an action quicker than the latency of the slower player.

I guess this is the best approach to my problem.

\$\endgroup\$
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .