You already can, Unity has their own section of Unity on the web games you can play. They aren't graphically impressive usually but comes down to lack of development resources.

Then there's examples like Townscraper (https://oskarstalberg.com/Townscaper/) which are graphically nice and already playable on the browser. There are also many games on itch.io of varying quality, but IMO Townscraper is the nicest.

The problem of storage is also quite important, it's hard to push a high quality game on the browser when a lot of people won't stick around for the 10GB+ download needed, not like they would if they're downloading from the Xbox store or something like that. So it's a bit of a cultural issue as well on that front.

I don't think it's a cultural issue. The difference is you only have to download a game once from the store compared to downloading 10GB+ every time you load the webpage.

Quite a lot of cache storage can be used and can be expanded on as well if there was a serious demand for it. Browser games don't technically have to redownload the entire game every load. The reason I claimed it as "cultural" is because of how we view browsers and interactive media within them. We are totally fine with opening a games store app, clicking download, and waiting and playing. The same is technically possible within the browser, but people are far less likely to wait for it.

It's like sound. People are OK with video games with clicky sounds going through menus with background music playing, but find it very obnoxious if a website does the same. Not a technical problem, but one of culture and how we view the mediums.

No it can't, for security reasons.

Browser games have no idea how long their data is around and how big the cache actually is.

You need to design a web game around the download bandwidth, and only stream data right when it's needed instead of preloading everything upfront. Porting existing games with a different streaming model usually doesn't make much sense. And once you build a web game from the ground up anyway, there's little reason to use one of the humongous game engines like Unity or Unreal which have been designed for a very different data streaming approach.

Well, you don't need to download the whole world data-file to play the game. All you need is to stream whatever you can possibly interact in the next couple seconds.

You can also load low-res textures and models for users who just showed up, and then, as they have been playing for hours/days, upgrade to better higher quality models.

I still like that physical discs can be played, maybe just in campaign mode, without network/subscription.

Browser based games will go to GaaS subscription or even "Insert $.25 to Continue" very quickly.

And when whoever controls the server pulls the plug, it's game over.

Definitely interesting technically-wise, but considering the implications, no thanks.

I still like churning butter by hand but I don't really expect the local hardware store to carry a wide selection of butter churns you know?

So go out to the woodshop and make your own! Churning your own butter in a store bought churn is mailing it in.

Why hamstring the game by running it in a VM?

Easy portability would be one benefit

Middleware engines have been offering that for at least two decades with better tooling.

Oh brilliant, I'll go an start to play latest CoD on my mac then. Oh, wait.

You also won't get it with WebGL 2.0 anyway.

> So when are we going to see modern Unity and Unreal games running on the web?

What, in your mind, would be the killer advantage?

Anything besides easy distribution?

Isn't easy distribution the killer advantage of the web, period? It ain't a small thing.

I suppose.

But it seems to me that, esp. in the case of gaming, it isn't just distribution that win, but the ability to discover, and pay, for games easily in a single place. So App Stores seem to have won the distribution game and have added several other capabilities that are all together make for a more compelling story than easy distribution alone.

If that weren't the case, why aren't we seeing more games distributed this way (web)?

From the consumer point of view, web-based distribution isn't really any easier than the status quo anyway.

We're trying to build this with bash.gg!

Never, I hope. Browsers are an awful platform for software

This has already been possible for years - Unity and Unreal have had ports for a long time. The problem is that the web is a horrible platform to release AAA or AA games on. No way to pre-install, arbitrarily small local cache for your assets, long load times (due to slow I/O and code compiling every time), graphics API feature set from a decade ago, limited support for multithreading, SIMD not really widely usable yet (but close!), etc. On Android your game won't start because phones don't have enough RAM to run 64-bit Chrome and 32-bit Chrome doesn't have enough address space for your game. Don't get me started on how bad some of the other APIs are - for example, wanna stay fullscreen on iOS? You can't unless you're using a <video> element, it will constantly boot you out if it even lets you in at all.

WebGPU will help with the 'graphics API feature set from a decade ago' problem but you may have to wait like 2 years extra for it to show up in Safari and ordinary Android phones since Apple delays new features and Android phones don't get updates. Android phones also have horrible video drivers, so it may not work on many handsets ever. Plus you have to rewrite all your shaders in their special snowflake shader language and wait for them to compile on every page load.

Ultimately, Apple doesn't want you shipping browser games because they would rather get 30% of your revenue via the App Store. The Chrome team probably does want you shipping browser games but they're in a difficult situation with the state of the mobile market, they probably need to do painful stuff like implement compressed pointers if they haven't already.

Exactly my point of view, 3D Web APIs are only good for 3D models in e-commerce, shadertoy like playgrounds, retrogaming and casual games with PS3 like capabilities.

And even the PS3 at least had a proper graphics debugger.

Yea I was working on a Unity game that originally had a WebGL build. At one point I implemented a 3rd party plugin that required multi-threading for real-time rope simulation (Obi Rope), and at that point WebGL basically became impossible for the game.

Unreal4 at least has been able to do it for quite a long time[1].

https://docs.unrealengine.com/4.26/en-US/SharingAndReleasing...

That said, nobody really releases games that way and nobody plays them that way. Not everything needs to be a web app.

No, Unreal can't export to the web using newer versions of engine actually.

And UE5 does not have support for it out of the box at all.

The header on the previously linked docs page brings us to the GitHub repo where Epic OpenSourced it as a plugin. The missing support can be confirmed in the issues. Seems like web support was quietly removed after all.

https://github.com/UnrealEngineHTML5/Documentation/issues/10...

It was, because no one was using it and it isn't as if 3D Web is capable of stuff like Nanite.

I'm not sure what the benefit is. Slightly easier to release between windows mac and linux, meanwhile taking a 20% perf hit from native?