As an aside, one thing that's interesting and sad to me about WebGL is that WebGL + modern browsers are significantly more powerful than the PS1 and Nintendo 64, but we haven't had _anything_ even _remotely_ close to the completeness of an N64 nor PS1 game. Lots of small experiments and impressive demoscenes, but nothing in WebGL that takes advantage of this potential power. Frankly even compared to the completeness of Flash games, there are very few WebGL projects that even come close to that.
This article and output would make a great WebGL project, and they could embed real demos of it running right in the site.
What's missing that prevents us from building these types of complete projects in WebGL?
Monetization is the answer. Nobody is paying $50 for web games, there's no in-app purchase system, no web gift cards in stores, and the exploitative interstitial ad networks that enable free mobile games to make boatloads of money don't exist on the web.
That said, there is an ecosystem of web games and you might be surprised by the sophistication of some of them. https://venge.io/ is a good example, try https://poki.com/ for a sampling of more. https://playcanvas.com/ is the most advanced WebGL-specific engine.
Unless a AAA studio releases a main title for web that will be true as there are no $50 web games to buy to make this come true. I'd guess most non-AAA game sales on Steam aren't near $50 though but both of those can still be extremely lucrative.
> there's no in-app purchase system
90% of browsers support the Payment Request Web API and you're also free to make your own integrations to your payment processors directly yourself (which isn't always true of consoles/app stores).
> no web gift cards in stores
You can piggyback off the traditional payment backends (e.g. Google Play) and use their cards or use your own (like game specific Roblox/Fortnite cards in stores)
> and the exploitative interstitial ad networks that enable free mobile games to make boatloads of money don't exist on the web
I don't think you saw tons of interstitial ad companies for mobile prior to having mobile games that made sense to use them either. After all it's not like the web is incapable of delivering ads it's just there is no point in delivering these types of ads without that type of content.
.
I think the real reason is distribution pains. By the time you make a games impressive enough to garner strong sales it becomes a PITA to distribute via the browser. Large amounts of persistent storage are a pain to manage in browsers (if you can even get the amount you want) and delivering an entire game or designing it to be completely streamable is a ton of cost and overhead vs just serving persistent differential app updates via traditional means. You get less control of the environment the game is run in and what you get in return is worse performance and feature capability to work with out of the gate. Compare this to any other distribution means where you're able to manage distribution, use the full capabilities of the device, and more long term stable platforms with less overhead.
When I looked at it, I found that incentive ad networks want to use their blobs on mobile devices. They feel that the closed binaries protect them from ad fraud.
Google does offer a webgame interstitial ad network. You'll need volume for this.
I think you're right that the biggest technical reason is local storage. But I disagree about the difficulty of streaming. When properly implemented it comes with the huge advantage of drastically reducing install/patch/load times as well. Engine developers have been lazy and allowed install/patch/load times to get totally out of control. I think the game industry has been ignoring the huge benefit that reducing those times would bring them even on traditional platforms.
It's actually difficult to get smooth, realtime performance from webgl apps, there are just too many moving pieces.
I've written a lot of code for PS1, Dreamcast, Gamecube, PS2, XBox 360 and PS3, and except for the last two, what they had going for them was complete, absolute predictability. Your game was effectively running in realtime mode.
In a browser, you have a lot of jitter due to things out of your control; garbage collection, cpu frequency scaling, that kind of stuff. So, you see jerkiness, and that really breaks the feel of a game.
It will take a while to polish the browser tech stack to this level, and there seems to be no market to encourage that.
There have been lots of complete games built targeting the web browser.
Crosscode is pure HTML5 according to the devs. No webgl at all. Games like Quake have been ported to run in the browsers (and did so ~10 years ago).
I'm sure there are a lot more complete games out there targeting web browsers, but it isn't immediately apparent that's what they are using. A lot of the newer games I play feel like they are running in a web browser.
I think there are a lot of complete indie WebGL games, but they aren't nearly as well known as console titles from the late 90s. And that's because the market and technology are much more mature since then: demand for retro games like that is lower since the technology isn't state-of-the-art anymore, and supply is way up.
I have been reading a bit up on it for a side project and it's great, but resources for troubleshooting are slim and it's not compatible easily with modern frameworks so people tend to use particular Libraries for everything and finding vanilla webgl is a bit trickier.
This article and output would make a great WebGL project, and they could embed real demos of it running right in the site.
What's missing that prevents us from building these types of complete projects in WebGL?