AmbientRun/Ambient

Explain the network protocol and its current limitations

philpax opened this issue · 5 comments

philpax commented

The guide should have a document explaining the current state of the network protocol, what our next steps are, and what the current limitations are.

Here's a quick list of facts that can be used to write up a more complete document:

  • We currently only support desktop clients, and use QUIC through the quinn library as our communication protocol.
  • We are actively working on web deployments. To begin with, we may use WebSockets (due to their support across all browsers), but we would like to adopt WebTransport as soon as possible. This is dependent on browser support and wasm-bindgen availability.
  • The HTTP (TCP) port is 8999 and the QUIC (UDP) port is 9000.
  • We synchronise all entities with at least one component marked with the Networked attribute. Only the components marked Networked will be sent to the client.
  • Most core components are Networked. This may have unintended ramifications in terms of cheating, especially for hostile clients.
  • By default, custom components are not Networked. This is something users have to opt into.
  • The client is fundamentally designed around runtime flexibility of logic, which is non-ideal for avoiding cheaters. Further R&D is required, but it is likely that there is no silver bullet and the solution will be game-dependent.
  • All gameplay logic is currently server-authoritative.
  • We currently do not have any form of latency-hiding, including prediction, rollback, or clientside logic.
  • We previously had rollback, but removed it due to its relative inflexibility.
  • Our plan is to introduce clientside and shared logic that can be used for user-defined prediction with runtime assistance, but this will take some time.
xunilrj commented

I am interested in helping with this. @philpax

ggambetta commented

Happy to brainstorm about client-side prediction and server reconciliation :) I've written a bit about this.

philpax commented

I am interested in helping with this. @philpax

Go for it! Fork the repo, add a Markdown file to docs/src, and add a link to it under the SUMMARY.md Reference section. It's just mdbook, so you should be able to work on it locally.

Once you get started, I'll assign the issue to you 👌

  • 👍1
philpax commented

Happy to brainstorm about client-side prediction and server reconciliation :) I've written a bit about this.

Awesome! I've seen your articles before and they're great - I've shared them with other people to help explain the intricacies of networking.

We can't do any work on prediction until we have #6 - but I'll definitely catch up with you and others once we get there 😄

  • 👍1
canadaduane commented

Have you considered using WebRTC at first, for its ability to support UDP? Here is an implementation example of a javascript server & client: https://geckos.io/