foxssake
feat: Add option to avoid broadcasting inputs
Hello! :wave:
While looking at the example project, I noticed that the _process function was using the input attribute to animate other players which made me realize that this is probably not something that should be done in most cases as it leaks what the intend of the other players might be.
and also because those information can usually be extrapolated from other data already replicated and that allows us to save some bandwidth!
Some example:
- Input Movement => Velocity
- Input Aim => Rotation This Merge Request adds a simple toggle to only send the RPC to the server (turning Broadcast Input to Off).
Here are some data using the the example project as a reference in LAN mode with:
1 Listen Server + 2 Clients
| Download | Upload | |
|---|---|---|
| Server (Broadcast) | ~16.3 KiB/s | ~66.2 KiB/s |
| Server (No Broadcast) | ~8.0 KiB/s | ~47.8 KiB/s |
| Client 1 (Broadcast) | ~32.6 KiB/s | ~8.1 KiB/s |
| Client 1 (No Broadcast) | ~23.3 KiB/s | ~4.0 KiB/s |
Obviously I am totally new to this project (and to Godot) and might need an implementation rework. I set the default broadcast value to true to avoid creating BC break as it is more a minor change here.
I also updated the demo project to use velocity instead of the input, it "works" but is probably not as good as the input implementation, I haven't looked too much into the code logic for it to be honest.
Let me know what you think!
Oh dang, now that you mention this @nicobatty, this would make a lot of sense to have. Let me play around with it in the next few days and get back to you with a review.
With this change, there seems to be some sync issues between the different clients. Though the server itself seems to be doing fine so other clients might be relying on the input itself.
I also discovered while trying to debug what was going on that by not submitting any inputs, the server stops running the rollback tick which is an issue since the physics like falling for example runs in this tick so the character will essentially stop falling.
In this case I think the general strategy for the server is to just keep using the same inputs for the next tick. Not sure if related to this or a separate issue though.
I also discovered while trying to debug what was going on that by not submitting any inputs, the server stops running the rollback tick which is an issue since the physics like falling for example runs in this tick so the character will essentially stop falling.
@nicobatty yeah that's the intentional behavior currently - if the server doesn't know the player's input for a given tick, it doesn't simulate it. Instead, it will wait for the input to arrive, so we know on the server side what's the player doing.
However, the client should always be submitting inputs for each tick, to the server. Is there a case where that does not happen?
@nicobatty added some commits. Thank you for the catch and the PR, much appreciated!