What happened?
Is PlayroomKit.SetState non-reliable supposed to be called each frame? I'm experimenting calling it 20 times per second while the game runs at 60 pfs and the result is terrible. super lagged.
strings, json files
it depends on the message. most are 50 bytes. inputs are smaller
the less the worse. sending it every frame (60 fps) works fine. I don't feel too much lag. but sending less times, feels laggy. the game does not freeze, only the objects that need some kind of synchronization feel laggy
After some experimentation
So here is what I found after many tests trying to reduce the number of messages across the network and make the game run more smoothly.
My idea was to make the game run at 60 fps while sending messages at 20 fps.
Things I was doing wrong:
- SetState only if it changed. Since the packet is non-reliable, there will be a chance of that packet being lost and client not knowing the state changed.
- Send player inputs at a lower rate. Even if the server/host is sending data to players in a lower rate, clients must send their inputs to the server/host at normal speed, to make sure the server can process them as quickly as possible.
- Not implementing client-side prediction. I was trying interpolate the player state while simulating it locally too. That would never work. I had to implement client-side prediction + server reconciliation to fix that.
Things I was doing right:
- When the local player receives the state of another player, apply interpolation to make it run smoothly.
After that changes, the result is:
👍 Local player runs smoothly. The host runs normally as always. Non-host players predict their position, validade it when receive the message from the host and if necessary recalculate the current position and apply an interpolation to the visual error. Lag is rarely noticeable.
👎 Other players still look laggy to the local player, in despite of the interpolation. The reason for that is that many messages are lost, so instead of receiving a new state every 50ms, sometimes the player have to wait 1 to 3 seconds to the next message. This results in a very noticeable effect. The player object get stuck for some seconds and only when a new state is received it moves again. The most weird part of all this is that if I raise the message sending rate, it starts to get better but still not ideal. In short, I have to send a lot of messages only to receive few of them. I wonder if there is something I can do to improve that or it is a Playroom limitation.
Expected behaviour
By default, states should be unreliable so they are sent fast. We should be experiencing this lag with unreliable. It would only happen if somehow it is using reliable connection, or there is something bottlenecking the code itself.
Version
I'm using v0.0.14
What is your environment?
Unknown
Link to original discussion
https://discord.com/channels/997752993598419044/1128151935669764096/1234621333531394198
Relevant log output
Here's a link to test out the problem:
https://devsoccerparty.playroom.gg
click "custom" to create a new room, them with another instance of the game click "join" and enter the room code
What happened?
Is PlayroomKit.SetState non-reliable supposed to be called each frame? I'm experimenting calling it 20 times per second while the game runs at 60 pfs and the result is terrible. super lagged.
strings, json files
it depends on the message. most are 50 bytes. inputs are smaller
the less the worse. sending it every frame (60 fps) works fine. I don't feel too much lag. but sending less times, feels laggy. the game does not freeze, only the objects that need some kind of synchronization feel laggy
After some experimentation
So here is what I found after many tests trying to reduce the number of messages across the network and make the game run more smoothly.
My idea was to make the game run at 60 fps while sending messages at 20 fps.
Things I was doing wrong:
Things I was doing right:
After that changes, the result is:
👍 Local player runs smoothly. The host runs normally as always. Non-host players predict their position, validade it when receive the message from the host and if necessary recalculate the current position and apply an interpolation to the visual error. Lag is rarely noticeable.
👎 Other players still look laggy to the local player, in despite of the interpolation. The reason for that is that many messages are lost, so instead of receiving a new state every 50ms, sometimes the player have to wait 1 to 3 seconds to the next message. This results in a very noticeable effect. The player object get stuck for some seconds and only when a new state is received it moves again. The most weird part of all this is that if I raise the message sending rate, it starts to get better but still not ideal. In short, I have to send a lot of messages only to receive few of them. I wonder if there is something I can do to improve that or it is a Playroom limitation.
Expected behaviour
By default, states should be unreliable so they are sent fast. We should be experiencing this lag with unreliable. It would only happen if somehow it is using reliable connection, or there is something bottlenecking the code itself.
Version
I'm using v0.0.14
What is your environment?
Unknown
Link to original discussion
https://discord.com/channels/997752993598419044/1128151935669764096/1234621333531394198
Relevant log output
Here's a link to test out the problem:
https://devsoccerparty.playroom.gg
click "custom" to create a new room, them with another instance of the game click "join" and enter the room code