Show HN: Ambient, a multiplayer game engine and platform using WASM/WebGPU/Rust (ambient.run)
Our WASM use is innovative; it is being used as both a sandboxed runtime for user code, and as a way to run the entire Ambient runtime in the browser. This, paired with our ECS data model, enables a highly modular architecture that allows other developers to make isolated packages (code, 3D models, tools, etc.) that they can add as a mod to your game.
Once deployed, these packages can be activated on-the-fly while running the game in the browser, acting as their own small applications inside the game. This can be great for testing out game features, but it also enables building games with others - whether they be friends or strangers. In the future, we hope that whole communities can build games together, not unlike open-source development.
The runtime already has many of the features expected from a capable game engine, including physics (PhysX), a React-like UI toolkit and a GPU-driven renderer.
Check out the blog post [1] to learn more, and to try out a live multiplayer demo on supported browsers. The team and I will be around to answer any questions you might have.
50 comments
[ 3.1 ms ] story [ 123 ms ] threadOur CPTO is FredrikNoren, and he's also happy to answer questions.
Congrats, this is an amazing project!
Thanks, we appreciate it! We're excited to see where it goes next.
Firefox: "Your browser does not support WebGPU"
Chromium: Hangs on "Loading" and the console is spilled with errors. The first one being "panicked at 'Failed to find an appropriate adapter'".
As one of the folks using Linux, I'm hoping that this will get resolved sooner rather than later, too. (Well, actually - I'd prefer Firefox get support, but that looks like it might take longer. Alas.)
Rest assured we'll have this sorted for the next release; we were aware that Linux/Chrome/WebGPU were incompatible, but we didn't bubble that error up correctly. Our bad!
As I mentioned in another comment, we're considering adding a fallback renderer, but our hope is that Firefox will be able to complete its implementation sooner rather than later - as a Firefox user, I would much rather use it than Chrome myself!
[0]: https://github.com/gpuweb/gpuweb/wiki/Implementation-Status#...
Running Vivaldi and Brave on a RTX3090 btw
When it comes to loading resources ahead of time: this is something devs can choose per-game (i.e. show loading screen or not), but yeah you might be right that it would be better for the examples we have to show a loading screen instead.
Since it would be up to the individual gamedev to implement their own client prediction, I don't think you can really "fix" the lag issue on a platform level unless you provide a system for automatic prediction and synchronization of arbitrary user-coded behavior, like Overwatch's StateScript framework: https://www.youtube.com/watch?v=5jP0z7Atww4
60 ms is already borderline even for conscious discernment of transactional state changes.
For self locomotion feedback that is a huge value. And for proprioceptive signals like mouse input it is absolutely astronomical.
https://www.youtube.com/watch?v=5jP0z7Atww4
However, our renderer was built with native capabilities in mind (compute shaders!), so we would have had to rewrite it to support WebGL. We decided we'd keep up with WebGPU and see where it takes us :)
In the future, we may write a fallback renderer that's compatible with WebGL/older GPUs, but we wanted to focus on getting our existing renderer working first.
[0]: https://github.com/gfx-rs/wgpu
Don't expect an automatic jump in performance when naively porting well-optimized WebGL code to WebGPU though, currently WebGPU is still in the "make it work" phase, and not yet in the "make it fast" phase. Some high-frequency calls currently have much higher overhead in WebGPU than comparable calls in WebGL2. Case in point, this 'microbenchmark' demo is slower in WebGPU than WebGL2 (in Chrome at least, haven't tested elsewhere yet):
WebGPU version: https://floooh.github.io/sokol-webgpu/drawcallperf-sapp.html
WebGL2 version: https://floooh.github.io/sokol-html5/drawcallperf-sapp.html
https://caniuse.com/webgpu
---
EDIT:
Found them. There is no singular Launcher client. They are tucked away inside each individual games' "store page" under a dropdown.
The input lag is as bad on the desktop as it is in the browser.
---
EDIT 2:
The reason the latency is so bad is because the game has no local simulation, so any state update will require a full client-server-client RTT.
So the latency is effectively Google-Stadia level.
Oh gosh, I know how obnoxiously unhelpful it is when someone answers "All of it!" to such kind of questions, but in this case it's literally my visceral reaction when using the website, that I couldn't possibly exhaustively list out what felt wrong, but here are the most obvious pain points:
1. huge font that spans the entire screen combined with the arial/helvetica typeface.
I actually didn't realize that the text were not in ALL CAPS until I re-checked the website to type this response. Somehow the text is just constantly screaming in your face yet you couldn't comprehend any of what it's saying unless you force your eyes to enumerate individual letter and re-assemble them in your head
2. The colors makes it really hard to tell what's foreground and background. Again, I have to force my eyes to stop and scan the screen and reassemble them in my head before I could understand what elements are what.
3. Sporadically placed ALL CAPS with no sense of hierarchy that only confuses me further when I'm trying to read it. Again, had to deliberately slow down, scan, and mentally reassemble to comprehend.
Yep. This is temporary; we have a native version manager, but it's still a work in progress as it doesn't handle connecting to servers with different versions yet. The per-game native client downloads are a workaround to enable people who can't use the web client to connect to a running game, but we agree that it's not ideal.
In the near-future, our plan is to have a single binary that you can download that will automatically retrieve the right version of the runtime for the game you're running locally or for the server you're connecting to. The first half of this - running locally - already works, but we can't distribute it as a general solution until it handles servers, too.
> The reason the latency is so bad is because the game has no local simulation, so any state update will require a full client-server-client RTT.
Yes and no. We offer the ability to run code on the client - so simulation is possible - but you're correct that we don't do any automatic prediction yet. This is for two reasons:
1) PhysX does not run on the web at present. We'd like to rectify this by upgrading our version of PhysX, or switching to an alternate physics engine, like Jolt or Rapier. Until this, we're reliant on the server to provide physics updates, which limits what we can do with physics prediction.
2) Our end-goal is to make it possible to provide prediction as a package, and not as an inherent feature of the runtime. We're aware that there is no one-size-fits-all solution for prediction - what works for a fighting game won't work for an open-world game - so we are purposely avoiding being prescriptive about this.
Of course, it's going to take a while before we get there; we'll need to build up a significant amount of functionality to do so. In the meantime, we hope to build towards this in gradual steps so that our users can benefit, even if the full solution's not there yet.
---
Thank you for the honest feedback - we know these are pain points, but we're committed to addressing them. There's a great many things we'll have to address to see our vision through, but rest assured we're not ignoring them.
> Backend servers will be created on-demand to host your game, and will be automatically shut down when no one is playing. This means that you don't need to worry about getting and managing servers for your game; that's all handled by us.
This is a bit jarring to me. Because everything else about your platform is extremely open. Open web technologies. But then the server management is closed. I'm sure this is just the best way to do it for now, but for some reason I was hoping for something that would better match the ethos of the rest of the technology, idk...
Maybe I was expecting WebAssembly to run a server from my browser?
The servers in question are part of the main Ambient application [0]. The server part is open-source just like the rest of the engine. You can start your own server using native build of Ambient (check cli help for `ambient serve`).
As for the orchestration and creating servers on demand, we are using Kubernetes and Agones [1]. Both of them are open too. We just have a thin API server that receives requests that a server is needed, checks if there's already one running and if not it uses Agones to allocate one.
[0]: https://github.com/AmbientRun/Ambient
[1]: https://agones.dev/
My understanding with WASM is that you can run full desktop applications in the browser. Wouldn’t that mean you could include the server as well?
Having a selected host on one of the clients (as you mentioned) could potentially work, from network topology point of it wouldn't be much different from hosting a native server on their computer. There is a few cons to this approach:
1. We become limited on that person's uplink. First bottleneck will be bandwidth as they have to send all data to everyone. Secondly it's very difficult to ensure reasonable latency in this setup (it's already difficult with dedicated servers). Thirdly they have to be reachable by all other players (NAT/firewall headaches).
2. We rely on that person's computer and network to be up for the duration of the game session. We could try to migrate game server to another one if there are problems but again this becomes really complex really quickly.
3. Cheating. Not something we are worried at this stage but having a game hosted on one of the player's machines opens it up for abuse and might give a slight advantage to that player (starting with extremely low latency).
So that's when we compare running a non-dedicated server on one of the client's nodes. If we were to venture to pure P2P then it brings another set of challenges like state synchronisation.
Input latency is too much for first-person or third person games. Do you plan to add client-side prediction? Can developers handle that themselves?
> Input latency is too much for first-person or third person games. Do you plan to add client-side prediction? Can developers handle that themselves?
Somewhat, and yes. I've gone into more detail here [0], but the general idea is that we want to avoid implementing prediction within the runtime itself; instead, we want to make it a userspace thing, so that you can choose the prediction solution that will work best for your game.
Developers can already start experimenting with this now; we've opted for pure client-server in our examples/games for conceptual simplicity and to ease people in, but we'll be experimenting with introducing more userspace prediction in the future and seeing how we can genericise the solutions we build.
[0]: https://news.ycombinator.com/item?id=37767359
I just watched your intro youtube video - the collaborative world building aspect is exciting! The DX looks nice. Good luck with the project, would love to see this come together.
There isn't any indication that the browser is ever going to be a competitor to standalone builds, and as a game developer I would never consider using an engine that immediately sacrifices the livelihood of my studio by precluding every platform I can make money on.
That said, we do believe that the web _is_ changing, and that it's becoming more and more viable that one day we'll see big hit games actually played through the browser, for one simple reason; sending a link to someone where they can jump in and start playing with you immediately is a very powerful interaction (not having to wait for downloads etc.). And there are fundamental technological shifts that are making this more and more possible; WebGPU is opening up for more advanced graphics, WASM is making it possible to run near-native code, and WebTransport is making it possible to run more high-demand netcode in games. We're building Ambient on top of all those three, and while it's early days still, we're really excited to see what people can accomplish with them!
Games such as Battlefield have already used web technology to power much of the game chrome. Taking this a step further doesn't seem like a real constraint. Microsoft themselves are working to extend fast performance webviews to Xbox uwp's. https://github.com/MicrosoftEdge/WebView2Feedback/issues/215...
You're also not acknowledging the upside. Plenty of games would love to have an easy-to-make runs-anywhere multi-parryty game. Letting people log in from work or their phone could be a huge advantage to reaching markets. The market of people with access to web browsers is much bigger than the market of console owners!
You're also constraining your thinking to a narrow band in other ways, again ignoring plenty of great potential. Unreal has had huge success gaining entry into all kinds of unexpected spaces; cinema, architecture, events. Engines have a much wider market than just games, and having engines available on a much broader set of modalities than conventional game engines can unlock new use cases. No one's going to build a navigation tool requiring everyone to have a Steam Deck, but if all it takes is a phone then maybe that becomes interesting.
This also seems like an amazing starter kit for education and hobby coders. Wouldn't it be amazing to be able to be a year or two into learning development, and be able to create your own virtual world? That anyone can easily join & access from any device? That potential makes me thrilled.
Maybe this innovation isn't for you & you want to stick to conventional modalities. Fine, great! Don't use this. I for one see a lot of potential & reason for excitement. I think it has plenty of revenue potential, and vast amounts of cool potential.