Chrome and Firefox have supported WebGL since 2011 and WebAssembly since 2017.
What is the reason we don't have at early-2010s quality AAA game experiences running in the browser?
What is the reason we don't have at early-2010s quality AAA game experiences running in the browser?
AAA is by definition games that aim at the top end of what can be done in performance and graphical quality. Browsers prioritize other things. Put another way you can't be both AAA and in the browser, because if you tried, other people would come along and simply do better than you outside and you wouldn't be AAA anymore.
Specifically, browsers insist on very strong levels of sandboxing at the cost of high overhead, and they don't want you to run native code either, so you lose both performance and compatibility with most existing game libraries/engines. They also insist on everything being standardized and run through the design-by-committee meat grinder. Whilst Microsoft are polishing up the latest version of Direct3D browser makers are still trying to standardize the version from five years ago.
Browsers are optimized for lots of tiny files, but game toolchains tend to produce a small number of big files. For example browsers aren't good at resuming interrupted downloads or pinning data into the disk cache.
PC gamers have unified around Steam, which offers various advantages that raw web doesn't. Steam is intended for native apps.
Many games need to be portable to consoles because that's where the revenue is (bigger audience, less piracy). Consoles don't run web apps.
Browsers not only don't make it easy to implement anti-cheat but actively make it as difficult as possible.
Debugging tools for native code in the browser aren't as good as outside.
And so on and so on. That's not a full list, it's just off the top of my head. Other types of apps the web ignores: CLI apps, servers, anything to do with new hardware, OS extensions ... the list goes on. Really, we must ask why we'd ever think it'd make sense to ship AAA games as web pages. If you want the benefits the web brings for without the problems then you'd want a new platform that tries to learn from all of this and be a bit more generalized. I wrote up a design doc a month ago that tries to do that, see what you think:
https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI...
You don't want to wait minutes or even hours to download all assets before the game can start (and then again next time because the browser can't cache so much data).
TL;DR: the web platform is different enough from native platforms that ports of bleeding edge games (even from 10 years ago) are not feasible. You'd have to design the entire game around the web platform limitations, which are mainly asset streaming limitations.
But that doesn't happen because there's no working monetisation strategy for 'high profile games' on the web platform, the whole business side is just way too risky (outside some niches which mainly focus on casual F2P games).
The 3D API is only a very small part of the entire problem space (and by far not the most important).
In the end it's mostly about the missing 'business opportunity'. If there would be money in (non-trivial) web games, the games would come.
We still don't have any debugger quality like Renderdoc, Instruments, PIX, and there is nothing with the quality of Infinity Blade, the game Unreal and Apple used to demo iPhone's GL ES 3.0 capabilties.
Streaming like XBox Cloud seems to be the only path for "AAA game experiences running in the browser".
I think a main technical factor is that the devs and middleware authors interested in the platform have been constantly kept waiting for the next platform features just around the corner, and making big games is a long, 5-10 year process.
But then there's the business side. There's a longish history of web games and there are game genres that don't need 3D acceleration, but there still aren't many (any?) profitable web games.
https://wasm.continuation-labs.com/d3demo/
Released in 2004, but still quite impressive
> Performance is decent with around 30-40 FPS on a modern desktop system (ranges from 20 FPS in Edge, 40 FPS in Firefox, to 50 FPS in Chrome)
Achieving 2004 levels of performance & quality with nearly 20 years of hardware improvements is hardly impressive. It's really rather pathetic if anything, although I also got better performance in the opening area than the project page claims but I didn't play very long to find out if it drops later on.
But also note that it's not actually Doom 3 proper, but includes changes from other ports as well as a completely different renderer. There's sadly no side-by-side original vs. port screenshots to compare what the differences are.
* Deploying large software (i.e. games with all their textures and sounds and models) to the browser is a pain in the ass. Your content will get dumped out of the cache, the user's connection may be spotty, and the browser tab might use up too much RAM and get killed. Console and PC game distribution has an install stage because you need one and that simply is not possible in the web model [1]
* Browsers provide bad latency and stability characteristics. They will drop frames frequently due to garbage collection or activity in other tabs. The amount of multiprocess communication, buffering, etc involved in running a webapp also adds input and rendering latency. This makes games just feel sluggish and janky. If your only option for releasing your game is the web, you'll pick the web, but if players could get a smoother experience on Steam or PlayStation instead, you'd be a fool not to release there. The worst scenario is mobile, where in some cases the input delay on touches is upwards of 100ms.
* Browsers have subpar support for user input, especially on phones. For native games users can pick up an input device of their choice and begin playing immediately (unless it's an ancient PC game that doesn't support hotplug - this is more common on Linux for reasons that aren't obvious to me). In the browser, gamepad input doesn't report until you press a button - moving the analog stick to move a menu cursor isn't good enough - which is a weird and jarring experience. Fullscreen is required for certain types of input as well, which means people who prefer to game in a window on their desktop are out of luck. Apple gets bonus points for just intentionally making all of this stuff worse on iOS to force you into the App Store for that sweet 30% cut.
* AAA game experiences are expensive and more importantly time-consuming to develop. There are studios that started building AAA web game experiences a long time ago, and over the course of years most or all of them flamed out. Game development is hard so these failures aren't exclusively the fault of the web platform, but the web platform certainly didn't help. See https://www.gamedeveloper.com/business/rts-studio-artillery-... for one example - they started out building an AAA web game, then pivoted to native because they couldn't get around all the problems with web games, and then eventually shut down.
* Browsers have limited access to resources. I gestured at this in the first bullet point, but if you run in a browser tab you have less address space, less compute throughput, less VRAM, and less bandwidth at your disposal than you would in a native game. For "AAA" experiences this is a big problem, but for simpler games this is not really an issue. For large scale titles this can be the difference between 30fps and 60fps, or "all the textures are blurry" and "it looks crisp".
[1]: There are some newer APIs that alleviate some of the issues I listed, but not all of them