It noticed just a few days ago that is wasn’t working on my iPhone because mobileSafari decided to stop reporting itself as safari and only as “mobile safari”.
That points to your code doing browser agent sniffing. There are much better approaches to feature detection these days, precisely because of the issue you've encountered. I can recommend https://developer.mozilla.org/en-US/docs/Learn/Tools_and_tes... as a good place to start.
It is hard to interoperate with the page, and it will keep changing on that point for a while, but that's not something that games do. For games it's all drawing on some element, what is very well defined already.
Try to play https://slither.io
The performance is horrible even in simple games.
iOS and everything on it using Webkit though, I'm sure there're some issues.
That's not neccesarily a bad thing but you can't complain if you're trying to run cutting-edge apps on a conservative browser.
This comment goes beyond browsers - it's such a bummer when I try to play a game I like or one that someone recommended and then "oops, we don't support your device/browser...".
At least on Desktop - it's not that much of a burden to have a second browser installed for certain apps, is it?
I use Firefox for daily browsing but I've got Chrome and Edge for those times I want to run something that Firefox doesn't support (which is fairly rare). I imagine it's much less rare with Safari.
Like you say, you like Firefox but say if you want to video chat in Microsoft Teams, they'd tell you "video is not available in your browser".
Some games are only available on Android, others only on iOS. Or you are on a Mac but you can't play because someone opted for the easy way out saying "Macs are not for games" even though I am certain what I want would run just fine, if it was available.
These as examples of gatekeeping and the fix is definitely in the hands of developers to make their stuff portable and working everywhere.
Apple is famously slow or simply refusing to implement features that Chrome, Edge and Firefox have adopted. Many of these features are critical for certain applications. Gaming being one of them.
How is this a developer's fault?
1. I need feature x - either to implement an aspect of my app at all - or at least to do it in a way that doesn't require a large amount of extra work and cost. 2. Feature x exists in every major browser except Safari 3. I choose to exclude Safari.
My only options as a developer are to spend a ton more time or cash (assuming it's even possible at all) or to build something different.
And this might be a solo project or a project with no realistic hope of paying for my time.
I think it's unfortunate that you can't have rock solid cross browser gaming yet (and Safari is not the only offender, but it's by far the largest). But that's not a reason to just shut it all down for the next decade until that's possible.
Runs at a couple hundred FPS if left uncapped, and has very good netcode.
Now everyone has phones.
The rise of web games, way back when, was to blow off some steam at work. With the rise of monitoring software, that niche has been filled with mobile games that can waste time at work, on the bus, on the toilet, at the dinner table and while watching the television.
Flash games are where I started making graphics and learning programming, so this is a wonderful introduction for younger people to programming (Godot doesn't come with a suite of drawing programs like the stolen version of the Adobe Suite that I "liberated" as a script kiddy a thousand years ago). They can readily host them for cheap or free and show them to their friends, but as for business viability, you're very right.
Apologies for the length of this.... it kind of got away from me =)
Why not?
The usual answer is "performance", but that's a non-answer. Not all games need cutting edge levels of performance, web performance for accelerated graphics is actually pretty good as once a shader is on the GPU there's very little practical difference between web and native, and most importantly nothing pushes performance to improve quite like developers trying to maximize performance. If we don't try to make web games (or any other performant apps) then there's no reason for browser vendors to work on improving the situations where things are slow.
If Godot's devs think web is an interesting and fun thing to target then they absolutely should be making tools like this.