Unreliable inputs with redundancy #221
Conversation
|
Thanks @albertok, both for looking into it and providing this PR! This looks promising, I'll do some testing on my end too. |
There was a problem hiding this comment.
Added some initial thoughts.
I'd classify this PR on the same level as a new feature ( which it kind of is, even though the API doesn't change much ), could you please bump the addon version to 1.6.0? You can run sh/version.sh bump minor, depending on your platform.
|
Tested locally as well - although it didn't disconnect ( somehow ) at 20% packet loss. The improvement is massive! It went from barely playable to playable with some slight jitters! Which is pretty good at a 200ms roundtrip with 20% packet loss. This is the command I've used: |
| the current tick. We send data unreliably over UDP for speed. In the event a packet is | ||
| lost or arrives out of order we add some redundancy. You can calculate your target | ||
| reliability % packet success chance by using the formula | ||
| `1 - (1 - packet_success_rate) ^ input_redundancy`. |
There was a problem hiding this comment.
Nice touch with the formula!
Co-authored-by: Tamás Gálffy <ezittgtx@gmail.com>
|
Good catch on the unnecessary resimulations!
I had been using which is a static 20% loss, random 20 I believe does 'random loss upto 20%' |
| var old_input = _inputs.get(t, {}).get(property) | ||
| var new_input = sanitized[property][i] | ||
|
|
||
| if old_input == null: |
There was a problem hiding this comment.
There's a tiny window for cheating if we allow re-writing of what's previously been received with
if old_input != new_input:
so changed it to only allow backfilling missing inputs.
Switches input rpcs to be unreliable but with redundancy.
The idea is we don't want a single lost or out of order packet to jam up the flow of our game. Something that becomes increasingly likely the more players you have or the faster you dial up the tick rate.
This simple change dramatically improved response times in my test games and stopped states of 'rollback choking' as Enet tries to recover from a packet discrepancy.
The other benefit is now UDP packets race to provide the next tick info at the cost of slightly more data.
Tested with upto 20% packet loss and game remained stable. At higher packet loss rates Enet kills the connection.
Relevant discussion: #194
How Enet works when set to reliable
Happy to change this to a switch if prefered. Let me know what you think :)