The on-GPU culling and LOD selection looks nice, congrats! I'm curious, are there any native-only wgpu features that you're especially interested in having web support for?
Thanks! Yes! The renderer completely relies on multi_draw_indexed_indirect_count to batch everything, but I don't think it's available on the web spec yet. Without it, GPU culling and LOD-ing are a lot more toothless as we need to download the results from the GPU to the CPU.
What sort of multiplayer are you targeting? There's FPS-style (latency is important, lag compensation via extrapolation and interpolation, rewindable time for shooter-wins hit detection, UDP serialization with priority and delivery guarantees, sometimes client-side or peer to peer physics resolution, small player count), MMO-style (latency is less important, server-side everything, UDP or TCP, MUD-style messaging/RPCs, high player count, area of interest algorithms to optimize traffic), webgame-style (HTTP or VOIP-tech in browser, coarse grained calls, high latency is ok). There's also client/server, peer to peer, roll-your-own lobby vs. e.g. steamworks integrations, etc.
Not much docs up yet on this topic and the demos are a little sparse.
The current networking stack is pretty straightforward; it's built on top of QUIC so we do get reliable and unreliable UDP with multiple channels so the latency is really low, but we don't do anything fancy. We used to do rollback networking but removed it to simplify things; we realized it was overkill to have it on everything and it would make more sense to implement prediction on the entities that actually benefit from it (like player camera). We're currently working on deploying Ambient to the web too, where we'll probably use WebTransport, which is built on top of QUIC and should give us similar characteristics. For filtering which entities are stream; we haven't implemented that yet but we'd like to do it one day.
For lobbies/matchmaking; yes we're planning to implement a service for that. Steamworks integration is a bit further down the line but would be nice one day too.
Wow, this is very exciting! What would you recommend to someone wanting to contribute to the project? I'm a 19 year old developer who would love to learn more about game engine development and 3D graphics programming. I'm familiar with Rust.
That's great! The first thing I would recommend is to try to build something in it, so that you get a feeling for how it works. If you can even create tutorials or examples for others, that would be a huge help for us! There are also issues labeled "good first issue" on the repository.
Multiplayer in games is a hard problem to solve because each game has their own set of requirements that are hard to abstract or make generic, you'll always have to make compromises wich is not idea, hence why everyone end up doing something custom
But having something ready out of the box is a nice competitive advantage over something like Unity for example
Yeah agreed, and we recognize that there will be lots of multiplayer scenarios this won't solve. But we hope to solve a large chunk of the "middle ground" multiplayer game scenarios, and make it easy for people to explore what happens when you involve other people in your game!
Very cool project. Given that the networking approach is to synchronize the data model across the server/clients, are there any considerations made around cheating? For example, could one client manipulate the positions of objects arbitrarily and cause them to "sync" with the other clients?
I believe Unity at one point (or may still) have some similar plug-and-play networking module to do something similar. For example, syncing arbitrary GameObjects between clients. (Maybe it's called "Unity Multiplayer"?)
Hey there! I'm one of the devs working on Ambient.
To answer your specific question, nope - the server is always authoritative over state, so clients cannot adjust reality for other clients. That being said, there are other concerns that result from this model, so I'm going to transclude my answer from Reddit (https://www.reddit.com/r/rust/comments/118wlda/introducing_a...):
"By default, components are not networked to the client; you have to opt into this using a component attribute (https://ambientrun.github.io/Ambient/project.html#reference). That being said, many of the core components are networked by default - we're thinking about how to best balance convenience of development with security, and it's an ongoing discussion."
Makes sense! Thanks for that context. I believe your approach is a sane default in many cases, and in some cases cheat prevention can even be a rabbit hole of premature optimization for smaller teams. Oftentimes in modern multiplayer games remediation is a manual human process (i.e. players are banned by administrators based on reports from players). There are many hugely successful and profitable games which take this approach, so I don't think it should necessarily be written off completely as "wrong". There are also many successful games (even AAA ones) where cheating is prevalent and widespread despite attempts at prevention. It strikes me as a tradeoff around velocity and time spent for the team. For smaller teams I suspect time is often better spent shipping rather than hyper-optimizing cheat prevention, but that is just my opinion and is also dependent on the context.
15 comments
[ 1.9 ms ] story [ 20.2 ms ] threadHappy to answer any questions about it.
Not much docs up yet on this topic and the demos are a little sparse.
For lobbies/matchmaking; yes we're planning to implement a service for that. Steamworks integration is a bit further down the line but would be nice one day too.
But having something ready out of the box is a nice competitive advantage over something like Unity for example
I believe Unity at one point (or may still) have some similar plug-and-play networking module to do something similar. For example, syncing arbitrary GameObjects between clients. (Maybe it's called "Unity Multiplayer"?)
To answer your specific question, nope - the server is always authoritative over state, so clients cannot adjust reality for other clients. That being said, there are other concerns that result from this model, so I'm going to transclude my answer from Reddit (https://www.reddit.com/r/rust/comments/118wlda/introducing_a...):
"By default, components are not networked to the client; you have to opt into this using a component attribute (https://ambientrun.github.io/Ambient/project.html#reference). That being said, many of the core components are networked by default - we're thinking about how to best balance convenience of development with security, and it's an ongoing discussion."