Show HN: Ambient, a multiplayer game engine and platform using WASM/WebGPU/Rust(ambient.run)
ambient.run
Show HN: Ambient, a multiplayer game engine and platform using WASM/WebGPU/Rust
https://ambient.run/
50 comments
What are you guys using for multiplayer? I tried the cold chicken and had crazy high input lag. Also in general it seems like the input systems is crazy bad in the other demos as well, panning with the mouse feels super choppy. Also why don't you load all the resources ahead of time? The Second Life-ish pop-ins and stutters really ruin the experience.
Running Vivaldi and Brave on a RTX3090 btw
Running Vivaldi and Brave on a RTX3090 btw
It's built on top of WebTransport, which is also quite new. But yeah, we're also seeing the input lag issue here and we're on it, will be fixed soon!
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.
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.
It seems like the latency is due to all the games being coded to only enact state change upon server message (à la League of Legends aka "no netcode at all")
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
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
It looks like they're using WebTransport: https://developer.mozilla.org/en-US/docs/Web/API/WebTranspor...
Also getting pretty brutal input lag, sometimes up to a second between mouse move and panning.
It takes a full network RTT to the server before your mouse input actually updates the client camera.
Yeah, it's part of the problem, but that would normally only give you ~60 - 100 ms lag (at least if you're on a decent connection, close-ish to the server). But we're experiencing another bug where WebTransport doesn't get a chance to send/receive data when the framerate is < 60fps (because the thread is starved), which makes it much worse than that. We're aware of it and working on it. This is the core issue: https://github.com/w3c/webtransport/issues/543
> but that would normally only give you ~60 - 100 ms lag
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.
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.
Oh yeah, absolutely agree, we're not stopping at 60 ms. Client side prediction is planned (see Philpax answer https://news.ycombinator.com/item?id=37767359 and our netcode roadmap: https://github.com/AmbientRun/Ambient/issues/671).
This is IMO a pretty good reference example for making a framework-based solution that can be reused by non-coders:
https://www.youtube.com/watch?v=5jP0z7Atww4
https://www.youtube.com/watch?v=5jP0z7Atww4
Errors out on both, Firefox and Chromium here:
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'".
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'".
Which version of chromium are you on? WebGPU is really new so it may require a browser update.
[deleted]
Firefox doesn't support WebGPU yet.
Regarding how the multiplayer works:
> 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?
> 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?
Hi, this is Kuba from Ambient team, I work on Ambient backend.
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/
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/
Would a more p2p system ever be possible? Just choose the host and their client is the one that orchestrates? Then you’d just need a proxy to connect users?
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?
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?
It's possible but it gets complex really quickly. Just running the server in the browser is the easy part ;)
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.
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.
Didn't work on Chromium, Version 117.0.5938.132 (Official Build) Arch Linux (64-bit). Console errors: https://pastebin.com/XSpEzhZW
Yeah - unfortunately, Chrom[e|ium] on Linux doesn't support WebGPU yet: https://github.com/gpuweb/gpuweb/wiki/Implementation-Status#...
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.)
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.)
Be that as it may, but maybe you should show some kind of error message so the user knows what's up instead of showing "Loading..." until they get bored of looking at a black screen - not everyone is savvy enough to check the console messages...
Absolutely, yeah. I've actually just opened an issue for this: https://github.com/AmbientRun/Ambient/issues/1038
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!
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!
It's fixed on the website now as well (it'll show you a nice warning screen on non-webgpu browsers, instead of just loading forever)
I have enabled webgpu in Firefox (set `dom.webgpu.enabled` to true) but it just says, "your browser does not support WebGPU". No, actually it does support WebGPU it's just that you're not detecting that properly.
We've just tested internally with Firefox nightly with WebGPU enabled (you should also be able to test this with the fix Fredrik just pushed out), but it doesn't seem to work - Firefox's WebGPU implementation doesn't implement enough of the spec [0] to be able to run our renderer.
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#...
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#...
Hm yeah, we need to fix the detection as part of instantiation, which happens in the engine. I'm adding a "Try anyway" button for you in the meantime, it should be up in a couple of minutes.
This is cool! I think multiplayer first and web native is a great combo. Once WebGPU implementations are more widely available this will be a much easier way of getting into casual games, especially party games with friends. Streaming assets by default makes a lot of sense for web, I've always hated having to download 100GB before even opening a AAA game.
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?
Thanks for the feedback!
> 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
> 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
Default prediction packages for common scenarios (like camera and player movement) would be nice. For example, I wouldn't care too much about physics prediction but player input should provide immediate feedback.
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.
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.
I can't find any download links for a native client. The website layout is unreadable to the point of being aggressively obnoxious.
---
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.
---
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.
> Found them. There is no singular Launcher client. They are tucked away inside each individual games' "store page" under a dropdown.
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.
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.
So if you browse to any game on you should see a download button to the left. Sorry to hear that the website doesn't feel good! Which parts of it specifically are you referring to?
> Which parts of it specifically are you referring to?
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.
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.
Thanks for detailed feedback!
I have to ask, what's the goal of an engine focused on web deploys?
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.
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.
You say that being web centric precludes usage on conventional gaming platforms. What about all the games that are PC only anyways? They could use Tauri or whatnot & have incredibly easy time porting to native.
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.
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.
So we view the browser as one distribution channel among many. We want Ambient to run everywhere. The first platforms we built out Ambient for were actually desktop native, we've since then also added the web support.
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!
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!
Lookgs great! I'd like to know, any pros/cons moving to WebGPU from WebGL (if any)?
Main advantage of WebGPU is compute shader support, which allows to move more work from the CPU to the GPU with much less hassle than WebGL2, and it also moves most state management from the 'render phase' into the 'initialization phase' (at the cost that almost all state is baked into immutable objects, so you better know upfront all state combinations you're going to need later during rendering).
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
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
Funnily enough, we've never actually been on WebGL! The runtime's built against wgpu [0], which is an abstraction layer that supports the native rendering APIs, WebGPU, and yes, WebGL.
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
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
Pros: It's basically just a more modern API, so we can do a lot more (compute shaders for instance). There's a lot we can do on the performance side with it to make it faster than what we could do with WebGL.
Cons: It's not yet available on all browsers unfortunately.
The major con is that only 28% of internet users have a WebGPU-supported browser, mainly because it's not yet supported on any mobile devices.
https://caniuse.com/webgpu
https://caniuse.com/webgpu
[deleted]
Hi HN! I'm one of the engineers working on Ambient; I'm primarily responsible for the devex, but I work on all aspects of the runtime and platform. (We're a small team!)
Our CPTO is FredrikNoren, and he's also happy to answer questions.
Our CPTO is FredrikNoren, and he's also happy to answer questions.
Chief part-time officer? :)
Congrats, this is an amazing project!
Congrats, this is an amazing project!
Hah, if only :) CPTO stands for Chief Product & Technology Officer; it's becoming more popular, especially among startups that need someone who can both define a vision and execute on it.
Thanks, we appreciate it! We're excited to see where it goes next.
Thanks, we appreciate it! We're excited to see where it goes next.
Haha indeed :)
[deleted]
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.
[0]: https://news.ycombinator.com/item?id=34906166
[1]: https://ambient.run/blog/platform