Giters

AmbientRun / Ambient

The multiplayer game engine

Home Page:https://ambient.run

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Explain the network protocol and its current limitations

philpax opened this issue · comments

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.
commented

I am interested in helping with this. @philpax

commented

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

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 👌

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 😄

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/

commented

For UDP on the web, geckos has a few problems that make it neat for small projects but unpractical at scale, notably requiring all the ports of a machine to be open, not working in docker/kubernetes...
See geckosio/geckos.io#245

Instead, although support is still limited to chrome-based browsers, using WebTransport (based on QUIC) would likely be a better choice. Although there is no rust implementation yet, there is a C++ one: https://github.com/google/quiche

commented

Matchbox could potentially be used for UDP traffic over the web, but using WebTransport is likely preferable anyhow. I'm not sure if WT will work with pure QUIC (i.e. our existing Quinn), or if there's another layer that needs to be implemented first. More research is definitely needed in this area!