Pay attention to WebAssembly

Just interested because you're in this business: do you genuinely think 30% keeps being the number? Seems like that's not long for this world from my limited perspective.

Hard to disrupt Steam if they're taking 10-15%, and I assume Valve still makes a mint at that price point because Steam is ~all they make.

This is great, my hope is for wasm packaging and delivery to have more metadata and code signing signature support. I say this because I fear potential security nightmares in the future. Imagine Log4J in wasm except it is also in cars, IoT devices , corporate intranet sites,etc... It's easy to leave that problem to whoever maintains the app but being able to revoke vulnerable or backdoored wasm apps/components will make everyone's lives easier I think

This is already being addressed in thread but I’d like to share some “it depends” thoughts based on experience from recent experiments with WASM and N-API. As others here and elsewhere have said, it depends on:

- how compute-heavy your workload is

- how long it runs

- how much you need to pass data back and forth

That last point is hard to overstate. It’s such an overhead that “notoriously slow” (however outdated the notoriety) JS operations like structured clone run circles around highly optimized native-bridge/WASM data transport solutions.

It’s such an overhead that—for short bursty interop around values that can’t meaningfully benefit from being passed through—you have to write JS that might as well be native integer wrangling but has to be written in JS to reduce the cross-talk. That covers pretty much any workload that involves passing around JS functions as values, or preserving inheritance chains, or dynamic usage of functions generally.

I’m excited about WASM and other JScompiled interop, it has a bright future. But unless and until JS as a standard and JS VMs at runtime specifically provide ways to optimize crossing that boundary, the vast majority of already hard to optimize JS use cases are either better solved natively in general with minimal interop (where WASM et al will shine) or better solved by optimizing the JS implementation where the use case necessarily deals with JS functions.

I think it depends

Problems with *traditional* games via WASM/WebGPU in the browser

* Many games are 10-100gig+ in size. The browser provides no good way to store this data for your game and the fact that you had to wait 15mins to multiple hours means you gain no advantage. Further, browser have a balance to keep between letting any site put gigs of data on your machine vs not. And on top of that, the browser provides no way to prevent losing the data. The user clicks "refresh" or something similar and now the user has to re-do that 10-100gig download.

* Browsers have to work around driver bugs and it takes time to fix them and get them through the release cycle. For a native game, if a new driver come out that breaks something you can try to work around it immediately. That's harder on browsers. Your game can try but it's a moving target.

* Browsers change stuff that affects perf more often than native. Today "for = i to N" is faster than for of, tomorrow "for of" is faster (not a real example). My point is, in my experience, it's much easier to optimize for native since you're writing native code. In WASM you're not. Further, you're closer to the metal in native. Today video -> texture is fast, tomorrow it's slow, the next day audio is no longer allowed without a click, etc... I guess I don't have any stats which change more, browser APIs or native. My gut though is that I've had to change browser content often to keep it running

* Running games on any device is mostly fiction. Users range from 3090s to 7yr old intels to 7yr old androids. From touch screens, to mouse and keyboard and with other different limits (no fullscreen on iOS, no pointer lock, ...). Depending on your game that's half your market.

In other words, IMO, games you generally find on Steam are not a good fit for the browser.

On the other hand, you could design games that load fast, start up fast, possibly stream data if they need more, etc and you could possibly make some hit games. Maybe even some of the biggest hit games ever. Remember when Farmville was #1?

Still, my feeling is UnrealEngine in particular, is not a good match for making web friendly games. Most game devs won't pay attention to what it would take to make a web friendly game. Instead they'll just follow the patterns for native games and pick "Export to Web" and basically put out a very poor experience for web.

The Interface Types Proposal is Wasm's answer to what you're describing: https://github.com/WebAssembly/interface-types/blob/main/pro...