Web client (compiling to WASM)

[ten3roberts]

If you have a feature request or issue regarding web support and running the Ambient client in the browser, please post it here.

• WebGpu in favor of WebGl when released
• Enable the network stack to use web apis
• Abstract task spawning/runtime (tokio/js)
• Abstract time and sleep
• Asset downloading
• Ensure rendering works identically
• #656
• Certificate setup
• https://github.com/AmbientRun/Web/issues/11
• #648
• #649
• #650
• #651
• #657
• #659
• #805

[philpax]

So a potential blocker in the future might be WASM client modules (#6). We don't have that currently implemented, but when we do, we'll need to figure out a way to make that work in the web.

I've asked the Bytecode Alliance Zulip about this, and they've suggested a few things. The main takeaway I had is that we could potentially unpack WIT components and load them as WASM on the web. To call it from our host code, we could add another host generator to wit-bindgen that calls into the web WASM.

This seems like it might be a fair bit of an engineering headache, though, as we'll need to abstract all of the WASM-interfacing code so that it can be backed by wasmtime or by web WASM modules. I suspect that we're unlikely to ship clientside WASM on the web soon.

Edit: although this might be a problem we need to deal with sooner rather than later if we do loopback-servers-on-the-web and they need to run their own logic

[ten3roberts]

Webtransport support in our networking stack is on the way

See #381 for details

[ten3roberts]

Thought I would give a condensed progress update on this issue as there has been some time, but also a great deal of movement forwards.

The port to the web is going along fantastically. Webtransport is fully operational, and we are now able to serve both Quinn(Quic) clients on native and webtransport clients on web.

The renderer mostly works except it has some issues with regards to our indirect renderer, which I am tackling now.

The big blocker which lies within arms reach is somehow running our client scripts on the web securely, and sandboxed, while also communicating with ambient runtime through our API. This is something I and @philpax will be tackling in a moment.

For native we are using wasmtime but doing so is not possible due to the low level machinery it uses such as jit compilation and function pointer passing which is just fundamentally not possible on the web.

Additionally, we will need to set up our server infrastructure certificates and appropriate portals to enable you, the users to access the hosted client and connect to running servers and Embers. This is part of @pierd's domain as well as the rest of our awesome team for setting up the website and portal.

[ten3roberts]

So a potential blocker in the future might be WASM client modules (#6). We don't have that currently implemented, but when we do, we'll need to figure out a way to make that work in the web.

I've asked the Bytecode Alliance Zulip about this, and they've suggested a few things. The main takeaway I had is that we could potentially unpack WIT components and load them as WASM on the web. To call it from our host code, we could add another host generator to wit-bindgen that calls into the web WASM.

This seems like it might be a fair bit of an engineering headache, though, as we'll need to abstract all of the WASM-interfacing code so that it can be backed by wasmtime or by web WASM modules. I suspect that we're unlikely to ship clientside WASM on the web soon.

Edit: although this might be a problem we need to deal with sooner rather than later if we do loopback-servers-on-the-web and they need to run their own logic

Since the time of this comment the state and plan of Ambient has changed.

Our games (Embers) are now increasingly dependent on client side logic for input handling, animations, ui, audio et al. These things were either not available or like user input spoon-fed to the server scripts by the Ambient runtime, but is now up to the game creator to decide on how to handle and send inputs or "commands".

Supporting client side scripting is as such of higher priority and must be done before shipping, as frankly even all but one of our examples currently require client side code.

[ten3roberts]

The client side scripts, the big blocker looming over us like a ghost 👻 with lots of unknowns with technologies and libraries which have yet to exist is soon to be merged.

I have followed the valuable input from my team members in order to arrive at a broader brush stroked solution to get it initially working. This however means that there are some todos left and smaller bugs left unadressed. See: #805