ncallaway / bevy_prototype_networking_laminar Goto Github PK

Build a simple two player pong game that can be played over the network. The goal of the pong example should be to demonstrate very basic gameplay functionality.

This should be a sample that can demonstrate basic interaction between components, but could also be built on for higher level networking plugins.

Therefore it should be:

• deterministic, to allow for future deterministic lockstep
• simple, to allow for it being a basic comprehensive demonstration of networking
• able to demonstrate the diagnostic plugins by showing injecting latency

Once the interface has settled for a bit, add some documentation to public members.

The messages are currently fully serialized whenever a message is changed. Clean this up to be a better representation of the desired sync model so that the server only sends the changes on a Reliable channel, and the Client can request the full list of messages when they connect, or need to reset their state.

On a per connection basis, allow injecting send latency and receive latency for diagnostic and debug purposes.

On the client connecting to the server, the cube disappears and either the plane or the camera moves around instead.

Currently we hardcode the laminar config for a socket

We should modify this so that this configuration can be provided when calling bind to allow external callers to configure some or all of the laminar config values.

The prototype right now doesn't have the ability to manually close a socket. Sockets are closed when the application exists. Add the functionality to manually close a socket.

The prototype currently only allows a single socket, but was designed to easily allow for multiple sockets.

Currently errors are resolved through .unwrap(), .expect(), .panic() or silently being dropped. The error handling should be cleaned up throughout the plugin, with a clean presentation of errors to the caller.

Once the interface has stabilized, consider adding some basic functionality tests in addition to the examples.

The testbed has some rough areas in the split between the net/mod.rs and net/prototype.rs. Consider cleaning up this interface to make it cleaner to implement a plugin integration

std::sync::mpsc was great for getting going quickly, but crossbeam-channels seems better in most regards and is popular within the rust community.

For a networking testbed, having a domain entity called Message is unreasonably burdensome. Rename these to something that doesn't have a networking connotation.

This depends on #20.

Create a diagnostic plugin that can simulate varying network conditions (low/medium/high packet loss, low/medium/high latency), with different variations over time (perfectly consistent, moderately consistent, extremely inconsistent).