Don’t get me wrong, I’m card carrying Unityman and just backed off of XR development recently in favor of more stable webdev work… but WebGL as a solution to high-performance browser gaming was an absolute shitshow from start to finish and I’m not even sure WebGPU lands in time for anything useful to be done with it to deprecate WebGL “support”. I assume that the lightweight 3D solutions based on threejs, etc. are going to drag the rest of the game engine industry kicking and screaming into whatever best solution arises and this wasm-as-k8s sounds like a neat component of that.
Games on the web face far greater issues than WASM or WebGPU can solve (like a complete lack of an asset delivery pipeline), unless you're only after casual flash-style gaming anyway. But mobile largely replaced that market.
To give you a scope of the problem of game assets, "small" indie games like Stardew Valley or Terraria are close to 500MB. How on earth are you going to deploy that on the web?
And if you are assuming a reliable, super-fast internet connection to stream game assets over (along with paying for the CDN to host it), well cloud gaming already does this better and already exists in a meaningful way. Why struggle to fight with the incredibly pathetic limits of a web browser when you can just stream a video?
With lazy loading? Or just an installation progress bar. What's the problem? The user has to click on the permissions dialog, allowing extended space usage, and that's it.
>reliable, super-fast internet connection
It wouldn't need a connection more reliable than what Steam requires for proper functioning.
>along with paying for the CDN to host it
I assure you the costs for a minimally successful game are minuscule when compared to the 30% cut Steam takes.
What you lose is the exposure that a release on a store like Steam gives you. That's not an insignificant problem, and is much more problematic than all the technical stuff you've mentioned.
>Why struggle to fight with the incredibly pathetic limits of a web browser when you can just stream a video?
Answered in a different comment.
And now you're back to 2006 era performance on a good day. 72 Mbit/s would be considered a pretty good internet connection. It's also the speed of a PS3's blu-ray drive.
People have been complaining about the 80-100MB/s on the outgoing generation of consoles for a long time now. Regressing by ~10x isn't a compelling argument.
> Or just an installation progress bar. What's the problem?
Without background downloads or updates? Every time someone wants to play your game, they're forced to stare at a progress bar that can easily take upwards of an hour depending on the game ("smaller" 3d games like subnautica push 10GB)? And you somehow don't see the problem?
> I assure you the costs for a minimally successful game are minuscule when compared to the 30% cut Steam takes.
And I assure you that you don't have to deploy on steam, either. You can both be a native game and get all the benefits of it and not pay anyone an app store fee! You don't have to suffer the web's treadmill of being a decade+ behind to have that.
If it's loading faster than user "consumes" assets, it doesn't matter how fast it is. It's not different for native games that allow you to play earlier than the whole thing finishes downloading.
>And you somehow don't see the problem?
Don't stupidly update the entire thing every time? Send deltas? Don't update as often? As for not having background updates it's a minor issue anyway (I for example don't start Steam unless I'm going to play), and there are Progressive Web Apps and Service workers to solve this issue.
>You don't have to suffer the web's treadmill of being a decade+ behind to have that.
Whoever needs the latest features can of course use a native platform. For developers who don't need the latest features or especially heavy graphics, WASM+WebGPU will be a viable option. That's all.
>You can both be a native game and get all the benefits of it and not pay anyone an app store fee!
And the user has to risk trusting me executing native code, which would definitely lower conversion rate.
AAA titles are already constrained by hard drive bandwidth, which is measured in Gbps on newer systems. They can’t keep all assets in memory. You’re going to have to have a top tier internet connection to get the same performance.
On top of that a browser thread can’t rely on having much more than half a gig of RAM assigned to it.
AAA titles are famously heavy in both GPU and CPU loads, and nobody is proposing to run them in a virtual machine, especially in the 32 bit one. ( memory64 is at the proposal stage)
Someone watching YouTube videos is sucking down hundreds of megabytes if not gigabytes per hour: the higher-resolution the video the more bandwidth required. Most video game assets require less bandwidth (megabytes per minute of consumption time), and can be cached locally.
When designing games for the web, creators will have clear incentive to apply more aggressive compression to everything they send over the wire and figure out how to make do with smaller assets, to cut bandwidth. Games designed to be downloaded have a relaxed size budget and can afford plenty of inessential bloat.
This is completely incorrect. Games regularly saturate and are limited by the 80-100MB/s that can be streamed from a PS4 or Xbone hard drive. This is in fact the biggest differentiating feature of next gen consoles - the switch to NVME and even streaming directly from disk to the GPU, bypassing the CPU bottleneck.
Meanwhile YouTube video, and indeed most streaming video, is well under 10MB/s. Netflix is even content to only recommend 25mbit/s for 4k HDR content.
> Games designed to be downloaded have a relaxed size budget and can afford plenty of inessential bloat.
This is such an arrogant and asinine statement. Games already exclusively ship highly compressed assets. They aren't just pissing away storage space for the lulz, and if they only tried a little harder could somehow cut sizes to 1/1000th of what they are today. Especially not to satisfy the needs of a platform that provides nothing but problems and headaches.
You can't simultaneously claim that WASM and WebGPU will enable a new era of high quality web based games while just entirely ignoring all the actual problems with shipping games on the web. Which WASM and WebGPU literally solve none of the issues. WebGL2 is already competitive on feature set and capabilities with mobile, and yet casual web games are still largely dead - a regression from the flash era, even.
> This is completely incorrect. [...] YouTube video, and indeed most streaming video, is well under 10MB/s.
10 MB/s is the same as 36 GB/hour. So we are in agreement.
But what game uses more than 36 GB of assets for 1 hour of play? I can’t imagine that is at all common. What kind of assets are they shipping that use that much data?
Think of it as if video keyframes were 1GB. Video streaming wouldn't exist in such a world as nobody is going to watch a loading spinner for 20 minutes. No, it'd all be a world of pre-fetched, downloaded content. Which unsurprisingly is exactly how game stores & consoles work.
Here's some coverage of the storage architecture of new consoles and why it's such a big upgrade: https://www.anandtech.com/show/15848/storage-matters-xbox-ps...
Trying to shove lazy asset loading over the internet into that picture just doesn't work.
Yes, and my estimate was “hundreds of megabytes if not gigabytes per hour”. So apparently Netflix also agrees with me.
> Games need to load that much data in under a minute.
This is based on design decisions from the programmers, not some kind of iron law of nature. Obviously you can’t just drop a game designed for one set of constraints into an entirely different context without change and expect it to work precisely the same way.
No, it's based on that's what textures and model quality expectations are. Reducing that size is directly reducing image quality.
You can make a web based game that looks straight out of 2002, sure. But you can't make one that looks contemporary, and WASM+WebGPU aren't changing that.
And of course no game developer is going to bend over backwards and make their game look like shit so it can run in a web browser for no reason other than to satisfy the ridiculous beliefs of web evangelists.
A friend of mine just got 350 Mbps optical fiber to his house. I was wondering what would come along to eat up that kind of bandwidth, you just answered the question. Someone playing a game on the web could also be seeding the thing on bit-torrent at the same time, thus cutting down the hosting fees for the developer.
2. The reason we don't see them anymore is because it's far easier to monetize them on mobile.
An interesting article on the topic (not written by me): https://www.fortressofdoors.com/tag/instant-games/
3D API for 2010 hardware or last generation raytracing hardware, what do you prefer?
Unity cannot do anything against castrated 3D APIs.
No wonder streaming is where everyone is going instead.
That is absolutely not going to continue being the case.
> No wonder streaming is where everyone is going instead.
"Pixel streaming" is great if you don't have latency requirements or your client has a poor GPU, but otherwise native 3D is superior.
Heck, 10 years of Web 3D and still there are no proper debugging tools that match native ones.
The ecosystem will explode, and the tooling will come with it.
Most devs would obviously still use unreal engine etc, but these engines will be able to give you improved performance of your games by utilizing WASM
In fact I'm quite certain that whenever portability or security ran up against performance in WASM's design, that performance always lost. Those other two goals were definitely a higher priority for WASM's designers.
Stable, portable byte codes are always inherently lossy. Information that could be (and often is) useful to optimizers is lost in that conversion. Then the conversion from byte code to running code also is on the hot path - it's on the hot path of starting execution. This is the same problem existing byte code solutions face, like CLR & JVM. WASM didn't manage to magic a solution where nobody else had. It's the same thing that's been done to death, just with "web" slapped on the front of it & bundled in a browser. That part of "being in a browser" makes it interesting for web devs, sure, but in the broader context of "all of computing" it's... just not? It's what we already have had (and been using!) for decades.
However, I think it would be possible to make systems in which similar instances, because they are written in a type-safe, memory-safe language in the first place, could bypass WASM and both start up fast and run fast optimised code.
I have done some research on portable bytecodes, and have some novel ideas for getting more performance, but I agree that the inherent problem remains. One thing that help make optimised C/C++ fast is that optimisers assume that undefined behaviour doesn't get triggered. But in a system for portable code, you can't just assume - you'd have to prove that it can not exist to be able to do the same optimisations, and that is far from straightforward. And when it triggers, it has to work the same say, or it won't be portable (bug-compatible) between hardware.
And since WASM uses linear memory and lacks things like ASLR, the code in the sandbox cannot achieve the same level of protection it could if it was in a hypervisor.
Also, not sure where the comparison to a hypervisor is coming into play. As @kllrnohj mentioned hypervisors are relying on actual hardware.
That is why we have signed binary execution to start with, WASM doesn't support any of this.
except it is, WASM is designed to be AOT compiled to native code.
Sure there is a bit of difference, WASM needs additional bounds checks and WASM also doesn't have all the info a more high level compiler has.
Now Unity is so much more then just a tool to make cross platform easier. So comparing it to WASM is kinda pointless IMHO. Though it probably is a grate choice for any extension mechanism, like mods or even in game scripting.
Interesting, I didn't know that. How does WASM handle different architectures? Do you build different binaries for x86/arm? Or does it do it the Apple way with the giant bundle that contains all binaries?
> Now Unity is so much more then just a tool to make cross platform easier. So comparing it to WASM is kinda pointless IMHO. Though it probably is a grate choice for any extension mechanism, like mods or even in game scripting.
Agreed, that was badly worded. Like you said, one could compare a module written in Unity and compiled to whatever Unity compiles to/is implemented in these days with a module in WASM.
Edit: Or does the AOT mean that the format that is shipped is some non-native format but the client compiles everything before the first run?
The same way JavaScript or C#/Java do. It's a bytecode format (typically the first stage in today's JavaScript engines is to turn into a bytecode), which the different engines then JIT for the OS and architecture they are running on.
For more details on a couple different engine implementations, you may find the below of interest.
- https://v8.dev/docs/wasm-compilation-pipeline
- https://hacks.mozilla.org/2020/10/a-new-backend-for-cranelif...
AOT is a counter part to JIT:
- AOT ahead of time (but still on the system, e.g. just before running)
- JIT just in time (while interpreting code you notice a hot section and turn it into native code)
So what most WASM runtime do is parse the WASM byte code, running certain checks for wellformedness and emit assembly (with necessary bounds checks, etc. to not escape the WASM sandbox).
This doesn't mean you can't interpret it, or interpret + JIT it, it's just that AOT seemed like a better choice then JIT or pure interpretation for WASM, as just interpreting it isn't fast enough compared to JavaScript JIT/or asm.js, to make it worth adding it to the web.
https://careers.unity.com/position/software-developer-unity-...
Our startup is working on support for Unreal to support WebGPU from 4.24 onwards, and we've already upgraded support so developers can use WebGL 2.0 instead of WebGL 1.0 like was available previously before Epic made it a community supported platform extension.
What all of them have, is being able to take advantage of 2022 hardware in 2022, with 2022 3D APIs.
As far as I know WebGPU doesn't lack any significant features beside raytracing (They are prioritizing the MVP, and raytracing could come later). Some of the newest features like mesh shaders are not yet supported by the native engines either, because there isn't a sufficient hardware base. Intel for example will support mesh shaders only in the yet to be released Alechemist GPU.
10 years later there still isn't something at the same level of Infinity Blade.
It definitely won't kill Unity or Unreal, but I have hopes that it will make developing without a ready-made engine a bit more attractive at least!
Want Vulkan/DX12/Metal without boilerplate?
Just use Ogre or Godot, among endless other options.
Even Qt is better than what WebGPU is capable of.
Castrated how? A single digit performance loss compared to the most extremely complex graphics APIs which aren't properly cross-platform?
>Want Vulkan/DX12/Metal without boilerplate?
>Just use Ogre or Godot, among endless other options.
"I want a graphics API!"
- "Use this game engine or this old and outdated graphics library instead"
>Even Qt is better than what WebGPU is capable of.
Ah, is it? Do you have any example of implementing forward+ rendering in pure Qt? No? What about GPU compute? Not that either?
> - "Use this game engine or this old and outdated graphics library instead"
That is the actual answer for when people ask that question, most of the time. Almost nobody is asking for a raw GPU API, which is what Vulkan, DX12, and WebGPU are. Rather they want a graphics API. Something that provides utilities and helpers. Something that can actually load textures, models, and animations. Or has a particle effect system.
But if all you want is a GPU API, as I mentioned far higher up in the thread there's no shortage of those today either (like bgfx, or even Angle). 'native' WebGPU isn't addressing some unserved market here.
Although if you actually do want a GPU API, there's also a good chance you actively don't want to use a middleware like WebGPU since it limits what you can do and gets in the way...
I'm mostly thinking of indie game devs who decide to write their games from scratch (which still happens, though it's becoming rare), or up-and-coming game engines such as Bevy. They might not have a team who can spend the time optimizing Vulkan (while also making sure MoltenVK runs it fine, if they want to target MacOS), and might prefer something more modern than OpenGL.
>WebGPU since it limits what you can do and gets in the way
Does it do that more than OpenGL ever did though?
By its nature cannot be more than that what browser do.
In case you missed the train, Qt now makes direct use of Metal, Vulkan, and DirectX 12.
I guess you were too busy keeping up with WGSL changes to notice that.
What security contraints are you thinking of which are making it castrated? In what meaninful ways is it castrated?
> In case you missed the train, Qt now makes direct use of Metal, Vulkan, and DirectX 12.
So with Qt, can I write a complete renderer with advanced techniques, and have it run on all 3 platforms without changing a single file? If not, how is it relevant to even mention?
Here is a little secret, thanks to extension spaghetti and driver bugs, there is seldom "without changing a single file" unless it is some toy app, instead of being used across all possible consumer hardware.
Plus you are focusing too much on Qt while being defensive for WebGPU on native deployments, there are plenty of other middleware I can use as example.
What are you talking about? Are you saying that https://doc.qt.io/qt-6/qsgmaterialshader.html is less "castrated" than WGSL ? Doesn't look like it. I don't even see the spec, it only says "Vulkan-style GLSL"
>Here is a little secret
Google and Apple definitely have more resources to spend standardizing WGSL (WebGPU has a Conformance Test Suite) than whoever owns QT this time of the year.
Because I still haven't heard a single argument against it from you that isn't extremely vague and handwavey.
For example, you skipping over my questions regarding more details on what you think makes WebGPU bad/castrated, or what is making Qt the better choice over WevGPU? (ignoring the fact that Qt doesn't seem to have a common shader language)
I'm open to hear the reasons, but it seems like your goal is to be contrarian.
And since you need to be Epic or a multi-million funded team with big scale to do an AAA game, but everybody could do a casual (and even more a hyper casual game), I'd say the latter is smarter than sneering on simpler games...
You might not care for those, but billions do. Heck, Wordle could make 10 times the money an average FAANG made in their whole career if it chose so...
That storm already happened. It was called Unity. And since then others have joined, like Unreal.
WASM + WebGPU doesn't bring anything to the table here other than being a decade late, slower, and with fewer features. Why would anything outside of a web app touch any of it? Why would steam bother? You still have to build so, so much platform-specific stuff to make it work (input, audio, windowing, etc...), why would you do all that and then just pay a massive performance overhead to avoid compiling a whopping ~5 times?
WebGPU could potentially see a use as a middleware for things that want to use the GPU but aren't concerned all that much about performance or overhead, things like image filter effects. But there's also no shortage of existing solutions for them, either, like bgfx (as well as domain-specific offerings like halide of course)