i’m having a tough time trying to keep the ui synced for all players in my game, basically i have a game state system. during intermission, players vote for a theme, and that part works fine – the countdown looks synced for everyone.
but after that, there’s a dialogue/message phase where the server picks a random message sequence and sends it to all players. the messages are supposed to show up at the same time for everyone, but some players get the messages slower than others. this causes some players to finish the dialogue earlier, while others are still reading it.
then the server sends the signal to start team selection (red vs blue), but some players still have the last messages showing, while th team selection ui (buttons + timeout) is already active. so the buttons end up overlapping the messages, which looks bad and feels out of sync. (obs: everyone was already in the server when this happened, so it’s not a late join issue.) it just seems like some clients are slower at updating the dialogue.
any ideas on how to fix this? should i wait for each client to confirm they finished the dialogue before moving on, or is there a better way to handle this kind of sync? appreciate any help, thanks!
1 Like
So first, absolutely make sure you don’t make the server yield on every player, since one exploiter could just delete whatever confirms they are done, and just make the game yield forever (along with many other bugs that could appear from that).
Id suggest just having the server sync where a player should be in the UI more often, just have more located on the server so everything runs on the server’s time, instead of the clients running their own things. I’m sure someone smarter than me could give you a better solution than making local UI more connected to the server, but that’s what id suggest.
1 Like
i didn’t quite understand what you meant about being able to be exploited because all the flow comes from the server
I was going off of
should i wait for each client to confirm they finished the dialogue before moving on,
which I interpreted as each client needing to fire a remote event to the server when they are done with the dialogue, or some system along those lines where the server waits for the client send something. Though I may have just misinterpreted what you said.
1 Like
ohh got it now. if i decided to go with the idea of waiting for clients that have “joinable” active, the server could maybe set a max wait time, and if it doesn’t get a response in time, it would just continue for the other players who are ready and remove that client from the queue or something like that. not sure yet — i’ll wait for more replies here on the thread, but thanks anyway for the help and attention!