4 ms·

whew game engine running on WASM + WebGPU would finally be what it takes to power browser based AAA titles. We shouldn't have to download executables via garden

by spxneo 3y ago

whew game engine running on WASM + WebGPU would finally be what it takes to power browser based AAA titles. We shouldn't have to download executables via garden walled ecosystems that take a huge chunk of devs revenues

seanisom 3y ago
This right here. The web is the OS of the future - the standards are getting there, the tools are just starting to catch up.
- PaulDavisThe1st 3y ago
  What platform(s) do you think browsers will run on?
  - seanisom 3y ago
    More of a comment on how apps are being built in the future - web-first is becoming the default. I already see web even taking over in things like embedded UIs where native toolkits like QT historically were popular.
jasonjmcghee 3y ago
Can't https://bevyengine.org/ https://bevyengine.org/ do this? AFAIK https://wgpu.rs/ https://wgpu.rs/ makes this possible with Rust. --- But this is very different than what was demonstrated in the vimeo video.
- Animats 3y ago
  Not all that different. See these WGPU demos.[1] As someone who's been using the Rend3/WGPU/Vulkan stack for over three years, I'd like to see some of these renderer projects ship something close to a finished product. We have too many half-finished back ends. I encourage people who want to write engines to get behind one of the existing projects and push. [1] https://wgpu.rs/examples/ https://wgpu.rs/examples/
  - jasonjmcghee 3y ago
    My understanding of the project here (Renderlet) was it allowed direct embedding in other non-wasm projects, which I didn't fully wrap my head around, allowing for injecting this engine inside of others? Or something to that effect? Which is quite different than a renderer that targets wasm/webgpu. I think super highly of, and have used wgpu a fair amount. I just interpreted Renderlet to have different goals.
    - seanisom 3y ago
      That's exactly it. With renderlet, the goal is to compile the "frontend" code that's driving the rendering pipeline to WebAssembly, and provide a runtime that embeds that in any app, with the host app providing any configuration necessary to connect renderlet modules and use its canvas. On the "backend", we will switch fully to wgpu as we retool around wasi-webgpu. I explicitly don't want to rebuild a project like wgpu, and everybody should commit upstream to that - we will likely have stuff to upstream as well.
jms55 3y ago
I don't see WASM/WebGPU changing anything when it comes to gaming, as an industry, personally. 3d visualizations and interactive websites? Yeah definitely a nice improvement over WebGL 2, if years late. The OP's experience with Adobe is a great example of this. WebGPU is pretty far behind what AAA games are using even as of 6 years ago. There's extra overhead and security in the WebGPU spec that AAA games do not want. Browsers do not lend themselves to downloading 300gb of assets. Additionally, indie devs aren't using Steam for the technical capabilities. It's purely about marketshare. Video games are a highly saturated market. The users are all on Steam, getting their recommendations from Steam, and buying games in Steam sales. Hence all the indie developers publish to Steam. I don't see a web browser being appealing as a platform, because there's no way for developers to advertise to users. That's also only indie games. AAA games use their own launchers, because they don't _need_ the discoverability from being on Steam. So they don't, and avoid the fees. If anything users _want_ the Steam monopoly, because they like the platform, and hate the walled garden launchers from AAA companies. EDIT: As a concrete example of the type of problem's WASM for games face, see this issue we discovered (can't unload memory after you've loaded it, meaning you can never save memory by dropping the asset data after uploading assets to the GPU, unless you load your assets in a very specific, otherwise suboptimal sequence): https://github.com/bevyengine/bevy/issues/12057#issuecomment-1960810877 https://github.com/bevyengine/bevy/issues/12057#issuecomment... (I work on high end rendering features for the Bevy game engine https://bevyengine.org https://bevyengine.org, and have extensive experience with WebGPU)
- seanisom 3y ago
  Lots of interesting points in there, and working on Bevy I'm sure you have much more extensive WebGPU expertise than me. I agree that the feature set around WebGPU is constrained and becoming outdated tech compared to native platforms. It shouldn't have taken this long just to get compute shaders into a browser, but here we are. The lack of programmable mesh pipelines is a barrier for a lot of games, and I know that's just the beginning. For memory, architecturally, that's why I'm treating wander as a tree of nodes, each containing Wasm functions - everything gets its own stack, and there is a strategy to manage Store sizes in wasmtime. Deleting that is the only way to free memory vs a singular application compiled to Wasm with one stack/heap/etc. More of a data-driven visualization framework than a full engine like Bevy, which I still think is one of the most elegant ways to build browser based games and 3d environments.
MenhirMike 3y ago
We already have that ability, both Unity and Unreal can run in the browser (though it looks like Unreal moved their HTML5 stuff into a public plugin). I think Godot also works if you don't use C# and stick to GDScript, or use Godot 3.x instead of the current 4.x. The problem isn't the tech to run the game, it's the marketplace - how do you actually sell the games without losing the huge customer base that buys through Steam and platform-specific stores? If you're popular enough you probably still get a lot of customers, but I doubt it's anywhere near what Steam does for you. Oh, piracy and anti-cheat are also a problem, because you just can't have a AAA game without Denuvo and Kernel Backdoors anymore (greeting to the Apex Legends players out there!). There are probably still a few issues that would have to be solved on the game engine side, but I'm willing to say that the game engine is not the problem with browser-based games.
astlouis44 3y ago
Here's links to Unreal Engine 5 running in the browser, for anyone interested: https://news.ycombinator.com/item?id=39920890 https://news.ycombinator.com/item?id=39920890 https://simplystream.com/demos https://simplystream.com/demos

by spxneo 3y ago

seanisom 3y ago

This right here. The web is the OS of the future - the standards are getting there, the tools are just starting to catch up.

PaulDavisThe1st 3y ago
What platform(s) do you think browsers will run on?
- seanisom 3y ago
  More of a comment on how apps are being built in the future - web-first is becoming the default. I already see web even taking over in things like embedded UIs where native toolkits like QT historically were popular.

jasonjmcghee 3y ago

Can't https://bevyengine.org/ https://bevyengine.org/ do this? AFAIK https://wgpu.rs/ https://wgpu.rs/ makes this possible with Rust. --- But this is very different than what was demonstrated in the vimeo video.

Animats 3y ago
Not all that different. See these WGPU demos.[1] As someone who's been using the Rend3/WGPU/Vulkan stack for over three years, I'd like to see some of these renderer projects ship something close to a finished product. We have too many half-finished back ends. I encourage people who want to write engines to get behind one of the existing projects and push. [1] https://wgpu.rs/examples/ https://wgpu.rs/examples/
- jasonjmcghee 3y ago
  My understanding of the project here (Renderlet) was it allowed direct embedding in other non-wasm projects, which I didn't fully wrap my head around, allowing for injecting this engine inside of others? Or something to that effect? Which is quite different than a renderer that targets wasm/webgpu. I think super highly of, and have used wgpu a fair amount. I just interpreted Renderlet to have different goals.
  - seanisom 3y ago
    That's exactly it. With renderlet, the goal is to compile the "frontend" code that's driving the rendering pipeline to WebAssembly, and provide a runtime that embeds that in any app, with the host app providing any configuration necessary to connect renderlet modules and use its canvas. On the "backend", we will switch fully to wgpu as we retool around wasi-webgpu. I explicitly don't want to rebuild a project like wgpu, and everybody should commit upstream to that - we will likely have stuff to upstream as well.

jms55 3y ago

I don't see WASM/WebGPU changing anything when it comes to gaming, as an industry, personally. 3d visualizations and interactive websites? Yeah definitely a nice improvement over WebGL 2, if years late. The OP's experience with Adobe is a great example of this. WebGPU is pretty far behind what AAA games are using even as of 6 years ago. There's extra overhead and security in the WebGPU spec that AAA games do not want. Browsers do not lend themselves to downloading 300gb of assets. Additionally, indie devs aren't using Steam for the technical capabilities. It's purely about marketshare. Video games are a highly saturated market. The users are all on Steam, getting their recommendations from Steam, and buying games in Steam sales. Hence all the indie developers publish to Steam. I don't see a web browser being appealing as a platform, because there's no way for developers to advertise to users. That's also only indie games. AAA games use their own launchers, because they don't _need_ the discoverability from being on Steam. So they don't, and avoid the fees. If anything users _want_ the Steam monopoly, because they like the platform, and hate the walled garden launchers from AAA companies. EDIT: As a concrete example of the type of problem's WASM for games face, see this issue we discovered (can't unload memory after you've loaded it, meaning you can never save memory by dropping the asset data after uploading assets to the GPU, unless you load your assets in a very specific, otherwise suboptimal sequence): https://github.com/bevyengine/bevy/issues/12057#issuecomment-1960810877 https://github.com/bevyengine/bevy/issues/12057#issuecomment... (I work on high end rendering features for the Bevy game engine https://bevyengine.org https://bevyengine.org, and have extensive experience with WebGPU)

seanisom 3y ago
Lots of interesting points in there, and working on Bevy I'm sure you have much more extensive WebGPU expertise than me. I agree that the feature set around WebGPU is constrained and becoming outdated tech compared to native platforms. It shouldn't have taken this long just to get compute shaders into a browser, but here we are. The lack of programmable mesh pipelines is a barrier for a lot of games, and I know that's just the beginning. For memory, architecturally, that's why I'm treating wander as a tree of nodes, each containing Wasm functions - everything gets its own stack, and there is a strategy to manage Store sizes in wasmtime. Deleting that is the only way to free memory vs a singular application compiled to Wasm with one stack/heap/etc. More of a data-driven visualization framework than a full engine like Bevy, which I still think is one of the most elegant ways to build browser based games and 3d environments.

MenhirMike 3y ago

We already have that ability, both Unity and Unreal can run in the browser (though it looks like Unreal moved their HTML5 stuff into a public plugin). I think Godot also works if you don't use C# and stick to GDScript, or use Godot 3.x instead of the current 4.x. The problem isn't the tech to run the game, it's the marketplace - how do you actually sell the games without losing the huge customer base that buys through Steam and platform-specific stores? If you're popular enough you probably still get a lot of customers, but I doubt it's anywhere near what Steam does for you. Oh, piracy and anti-cheat are also a problem, because you just can't have a AAA game without Denuvo and Kernel Backdoors anymore (greeting to the Apex Legends players out there!). There are probably still a few issues that would have to be solved on the game engine side, but I'm willing to say that the game engine is not the problem with browser-based games.

astlouis44 3y ago

Here's links to Unreal Engine 5 running in the browser, for anyone interested: https://news.ycombinator.com/item?id=39920890 https://news.ycombinator.com/item?id=39920890 https://simplystream.com/demos https://simplystream.com/demos