5 ms·

Rust

90 points by Philpax 3y ago

Earlier this year, we released our open-source game engine [0] built with Rust, WebAssembly, and WebGPU. Today, we’re happy to announce the Ambient platform, which brings web deployment, server hosting, and more to the runtime. With Ambient, you can make a game, deploy it to the browser in one command, share your URL and instantly play with others, no downloads or installs needed. 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 https://news.ycombinator.com/item?id=34906166 [1]: https://ambient.run/blog/platform https://ambient.run/blog/platform

Philpax 3y ago
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.
- Kinrany 3y ago
  Chief part-time officer? :) Congrats, this is an amazing project!
  - deleted 3y ago
    [deleted]
  - Philpax 3y ago
    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.
  - FredrikNoren 3y ago
    Haha indeed :)
ilikeyourdog 3y ago
[dead]
MrThoughtful 3y ago
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'".
- FredrikNoren 3y ago
  Which version of chromium are you on? WebGPU is really new so it may require a browser update.
  - deleted 3y ago
    [deleted]
- astlouis44 3y ago
  Firefox doesn't support WebGPU yet.
alcaide-mor 3y ago
Didn't work on Chromium, Version 117.0.5938.132 (Official Build) Arch Linux (64-bit). Console errors: https://pastebin.com/XSpEzhZW https://pastebin.com/XSpEzhZW
- Philpax 3y ago
  Yeah - unfortunately, Chrom[e|ium] on Linux doesn't support WebGPU yet: https://github.com/gpuweb/gpuweb/wiki/Implementation-Status#chromium-chrome-edge-etc 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.)
  - rob74 3y ago
    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...
    - Philpax 3y ago
      Absolutely, yeah. I've actually just opened an issue for this: https://github.com/AmbientRun/Ambient/issues/1038 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!
      - FredrikNoren 3y ago
        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)
        riskable 3y ago
Hamcha 3y ago
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
- FredrikNoren 3y ago
  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.
  - xeonmc 3y ago
    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 https://www.youtube.com/watch?v=5jP0z7Atww4
- olah_1 3y ago
  It looks like they're using WebTransport: https://developer.mozilla.org/en-US/docs/Web/API/WebTransport https://developer.mozilla.org/en-US/docs/Web/API/WebTranspor...
- gsuuon 3y ago
  Also getting pretty brutal input lag, sometimes up to a second between mouse move and panning.
  - 3y ago
dleeftink 3y ago
Lookgs great! I'd like to know, any pros/cons moving to WebGPU from WebGL (if any)?
- FredrikNoren 3y ago
  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.
- Philpax 3y ago
  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 https://github.com/gfx-rs/wgpu
- flohofwoe 3y ago
  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 https://floooh.github.io/sokol-webgpu/drawcallperf-sapp.html WebGL2 version: https://floooh.github.io/sokol-html5/drawcallperf-sapp.html https://floooh.github.io/sokol-html5/drawcallperf-sapp.html
xeonmc 3y ago
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.
- FredrikNoren 3y ago
  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?
  - xeonmc 3y ago
    > 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.
    - FredrikNoren 3y ago
      Thanks for detailed feedback!
olah_1 3y ago
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?
- pierd 3y ago
  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 https://github.com/AmbientRun/Ambient [1]: https://agones.dev/ https://agones.dev/
  - olah_1 3y ago
    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?
    - pierd 3y ago
      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.
deleted 3y ago
[deleted]
gsuuon 3y ago
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?
- Philpax 3y ago
  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 https://news.ycombinator.com/item?id=37767359
  - gsuuon 3y ago
    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.
hesdeadjim 3y ago
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.
- FredrikNoren 3y ago
  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!
- jauntywundrkind 3y ago
  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/2155 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.
lortr 3y ago
[dead]

90 points by Philpax 3y ago

Philpax 3y ago

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.

Kinrany 3y ago
Chief part-time officer? :) Congrats, this is an amazing project!
- deleted 3y ago
  [deleted]
- Philpax 3y ago
  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.
- FredrikNoren 3y ago
  Haha indeed :)

ilikeyourdog 3y ago

[dead]

MrThoughtful 3y ago

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'".

FredrikNoren 3y ago
Which version of chromium are you on? WebGPU is really new so it may require a browser update.
- deleted 3y ago
  [deleted]
astlouis44 3y ago
Firefox doesn't support WebGPU yet.

alcaide-mor 3y ago

Didn't work on Chromium, Version 117.0.5938.132 (Official Build) Arch Linux (64-bit). Console errors: https://pastebin.com/XSpEzhZW https://pastebin.com/XSpEzhZW

Philpax 3y ago
Yeah - unfortunately, Chrom[e|ium] on Linux doesn't support WebGPU yet: https://github.com/gpuweb/gpuweb/wiki/Implementation-Status#chromium-chrome-edge-etc 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.)
- rob74 3y ago
  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...
  - Philpax 3y ago
    Absolutely, yeah. I've actually just opened an issue for this: https://github.com/AmbientRun/Ambient/issues/1038 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!
    - FredrikNoren 3y ago
      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)
      - riskable 3y ago

Hamcha 3y ago

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

FredrikNoren 3y ago
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.
- xeonmc 3y ago
  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 https://www.youtube.com/watch?v=5jP0z7Atww4
olah_1 3y ago
It looks like they're using WebTransport: https://developer.mozilla.org/en-US/docs/Web/API/WebTransport https://developer.mozilla.org/en-US/docs/Web/API/WebTranspor...
gsuuon 3y ago
Also getting pretty brutal input lag, sometimes up to a second between mouse move and panning.
- 3y ago

dleeftink 3y ago

Lookgs great! I'd like to know, any pros/cons moving to WebGPU from WebGL (if any)?

FredrikNoren 3y ago
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.
Philpax 3y ago
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 https://github.com/gfx-rs/wgpu
flohofwoe 3y ago
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 https://floooh.github.io/sokol-webgpu/drawcallperf-sapp.html WebGL2 version: https://floooh.github.io/sokol-html5/drawcallperf-sapp.html https://floooh.github.io/sokol-html5/drawcallperf-sapp.html

xeonmc 3y ago

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.

FredrikNoren 3y ago
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?
- xeonmc 3y ago
  > 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.
  - FredrikNoren 3y ago
    Thanks for detailed feedback!

olah_1 3y ago

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?

pierd 3y ago
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 https://github.com/AmbientRun/Ambient [1]: https://agones.dev/ https://agones.dev/
- olah_1 3y ago
  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?
  - pierd 3y ago
    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.

deleted 3y ago

[deleted]

gsuuon 3y ago

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?

Philpax 3y ago
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 https://news.ycombinator.com/item?id=37767359
- gsuuon 3y ago
  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.

hesdeadjim 3y ago

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.

FredrikNoren 3y ago
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!
jauntywundrkind 3y ago
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/2155 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.

lortr 3y ago

[dead]