Shared authority over a component

[onkoe]

Hi again! Is it possible to "share" authority over a component on an entity that's otherwise server-authoritative?

An example

I'd like for players to be able to change where they're looking on the client, without the server intervening much. Otherwise, there are two problems:

• A client might change their camera rotation, but get rollback'd by the server. This should never happen unless they're dropping packets for an extended period of time.
• For an FPS game, the server and all remote clients would need to know every client's sensitivity, alongside anything else in a player's configuration that could affect their aim.

"Shared" authority..?

For those two reasons, I can't have the PlayerView component (which just contains a Vec2 saying where a player is looking) be solely server-authoritative.

Now... I did say, "without the server intervening much." What I meant by that is the vertical clamp: the server should be maintaining the clamp of 90..=270 degrees for a player looking up/down. Otherwise, modders could potentially flip the player head backwards and freak people out. (the world would be a better place if cheaters did stuff like this instead of their typical actions, but I digress)

In essence, I need a way to kinda "share" authority over a component, with the client sending a raw value, and the server verifying that value for itself, that local client, and all remote clients.

So, I know that you can do this with Messages (probably using a custom channel, a special Message ty, and server/remote client handling). However, is there any more specialized way to go about it instead?

I can totally imagine some kind of .verified:

component_registration_pretend_this_exists_please::<PlayerView>()
    .verified(|comp: &mut PlayerView| { 
        *comp.rotation.x = *comp
            .rotation
            .x
            .clamp(90_f32.to_radians(), 270_f32.to_radians()); 
        });

Is there any way to do this without resorting to Messages? Or is that the best way to go?

Thanks for the great crate! :D

[onkoe]

Messages work great here! But... it's suspiciously great. It's the least finicky part of movement in my project, actually.

Huh? Suspiciously great?

It seems that most other kinds of movement are sometimes lost. This might be an issue with my tickrate, which is Duration::from_secs(1.0) / 120), or 120Hz. However, turning that down results in noticeable delay, possibly exasperated by the clients/server having desync'd physics engines.¹

All of the non-message inputs (actions) are sometimes lost, causing numerous forms of desync. In my view, this is due to the default Channel defined for actions, the InputChannel, having unreliable settings.² That property makes it unfit for many kinds of input.

On the other hand, the "custom messages" route lets you define channels with SequencedReliable modes for actions like crouching or proning (which are currently lost on the server at times). Such a change would remove the desync I currently experience with inputs in lightyear.

So, as an answer to my question, no: lightyear has similar performance characteristics to professional-grade networking libraries. And, maybe more pertinent to this discussion, messages are wonderfully lightweight³ and are perfectly viable for low-latency scenarios like player movement.

Some message tips

Here's some various things I learned when using messages for a couple kinds of input when solving this in my project...

Channel mode

For inputs, make sure your ChannelMode is something like SequencedReliable (fieldless enums; things like crouching/proning), UnorderedUnreliable (high-activity stuff like raw inputs) or SequencedUnreliable (useful when you're sending something that's on a global frame; e.g., player rotation). The other modes were slower or inconsistent in my experience.

Receiver/Sender placement

Your MessageReceiver and MessageSender need to be in your Client and/or Server bundles (sometimes called the "Link" entity). Otherwise, your reader isn't going to get any messages from the writer. And that's kinda hard to debug... trust me.

Sender uses a channel generic in its method; Receiver does not

There's a generic in tx.send::<C>(msg); (where C is a Channel), but not one in rx.receive();. It feels weird, almost like you're doing something wrong, but rest assured - it's fine.

If you need to ensure the channels match, you can instead use rx.receive_with_tick() (which is kinda misnamed) to get a ReceivedMessage<M>:

pub struct ReceivedMessage<M: Message> {
    /// The wrapped message.
    ///
	/// You can get this standalone with `rx.receive()`.
    pub data: M,

    /// Tick on the remote peer when the message was sent.
    pub remote_tick: Tick,

    /// Channel that was used to send the message.
    pub channel_kind: ChannelKind,

    /// `MessageId` of the message.
    pub message_id: Option<MessageId>,
}

You will, however, need to compare the channel_kind to that burrowed in the MessageManager (spawned alongside your Link entity/bundle) to ensure it's the right channel. But, the IDs are stored in private fields that aren't accessible to you.

So, you can hash it yourself. That's probably not worth it to you, but I'd really like to ensure, at least with debug assertions on, that everything matches as expected.

Takeaways

Anyway, I'll keep this little thread updated as I continue finding ways to enhance user input in my Bevy Engine + lightyear project.

Footnotes

1. My project uses bevy_rapier3d, and there's no Rapier integration! For more info, see discussion Should we be using Avian instead of Rapier? #1101. ↩

2. The InputChannel uses ChannelMode::UnorderedUnreliable as of v0.21.0, so you might wish to use your own. However, it doesn't appear to be configurable at present, so you'll likely need your own message passing infrastructure (or a lightyear patch) for many common player actions in an FPS game. ↩

3. Each message is bincoded, which is fairly fast. (Though bincode isn't as fast as non-Serde implementations, the bevy ecosystem only has limited serde support, and no support for really anything else. So, the cost is worth it... unless you're newtyping each and every imaginable component! In which case, patch this crate to replace bincode with your favorite alternative. Ya tryhard.) ↩

[cBournhonesque]

Wait, you're not supposed to use custom messages to send inputs; you should use the InputsPlugin (that uses the InputChannel under the hood but with tons of extra guarantees around tick-syncing, input-delay, etc.). I'm actually surprised that things more-or-less worked for you using raw messages.

It is guaranteed that your input emitted on the client on tick T will always be received on the server by tick T (it is buffered under the hood by an input buffer). The flow is supposed to be:

• add InputPlugin
• an ActionState component will store the current state of your inputs for your entity at tick T (on both client and server)
• you have to add an InputMarker component on the client for the entity you want to control
• then you should have a shared system on both client and server that takes the ActionState component as input and applies some movement logic (the system should be shared because the client will predict the action, and we want the prediction to give the exact same result as the server)

For example like this: https://github.com/cBournhonesque/lightyear/blob/main/examples/deterministic_replication/src/protocol.rs#L77
In the example above, no state is replicated, only inputs, but the simulation with avian is entirely deterministic thanks to the input buffer.

You can also look at this example: https://github.com/cBournhonesque/lightyear/blob/main/examples/fps/src/client.rs#L32
to see how the client can update the 'direction of view' input

[onkoe]

Thank you for the response! Do you mean that, despite the InputChannel being UnorderedUnreliable, inputs are always guaranteed to arrive if a connection is stable? Or that, if everything arrives correctly and on time, that physics will be deterministic at a specific tick?

Some inputs could be Unreliable, but others seriously require Reliable to feel at all good, such as crouching, proning, or reloading. Currently, lightyear seems to drop those more than half the time, which is concerning for a purely local UDP setup. I'm sure my configuration is wrong, though - I'll absolutely take another look! :)

When I get something that works very well, I'll likely PR a 3D example with lots of tips/explainers in comments. I'm a big fan of the crate's architecture, as it addresses a lot of issues I've experienced in past Godot and Unity solutions.

Anyway, I was also surprised by how well the naive message trick worked, but sure enough, it worked well enough to noticeably reduce desync and lost inputs.

[cBournhonesque]

Correct, despite InputChannel being UnorderedReliable, it is guaranteed that inputs will arrive correctly and on time.
This is done in 2 ways:

• I always send the last 10-20 ticks' inputs, so even if one message drops the next one will contain the inputs
• the timelines are synced so that you have a bit of buffer before receiving the inputs; so even if the message doesn't arrive on time for one tick; the next message will contain the inputs

I've only tested with 64Hz though, so I don't know if things change at 120Hz

[onkoe]

Great, thank you! I'll give the InputPlugin another try through lightyear_inputs_native.

Do you know if there can be more than one instance of lightyear::input::native::plugin::InputPlugin? (last question before I let you rest 😭)

[cBournhonesque]

Sure; yes you can have multiple InputPlugins; one per different action type!
(and don't hesitate to ask more questions)