Your question is unpopular because everyone here likes the web and want to see it thrive as a platform. So do I, but still, I agree with you. Unfortunately, the web is not a viable platform for games. It had its moment for casual games some years ago, but mobile devices have taken that over. Thats why all the web game portals (the bargain bin bottom of the games space) are languishing, even Facebook Games, with its captive audience, is slowly dwindling away.
To put the actual game editor on the web makes even less sense. It's a cool technical feat, and the author may have thought of it as 'free', as some commenters have alluded to, given that there is already a web export, but anyone with a bit of experience knows that nothing is free, and certainly not a project like this. At the very least it's a months long effort (the author himself stated as much in the blog post), even before factoring in continued maintenance.
I love it as a technical feat, but I'll agree it doesn't make sense from a 'business' perspective (for lack of a better term, given it's an open source project).
Unfortunately, the web is not a viable platform for games.
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.
the web is not viable for games because browsers are unstable targets that change things constantly, breaking the games. Back when there was a stable deployment target (flash) games were everywhere.
This is very true. I built a game to go along with our wedding invitations. I’ve been maintaining it for the past 6 months, and it has stopped working on one browser or the other multiple times. This is despite the fact that I’m using a popular actively maintained JavaScript engine.
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”.
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.
Well for starters even getting a canvas based UI working that supports all DPIs, all aspect ratios, live resize, clicks, and multi-touches is non-trivial.
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.
Yeah, but then you need cavas and WebGL to draw and there isn't any way to know if they are actually being hardware accelerated, or if the browser vendor decided to blacklist the users hardware.
That definitely lags when there's more than one or two 'snakes' on the screen. The performance sucks. I'd argue that shows that specific game is poorly coded more than it shows web browsers can't handle performant games. If you look at something like https://beta.unity3d.com/jonas/AngryBots/ you'll see that browsers can, technically, cope with at least PS2 level graphics in a decent game running at a solid 60fps.
Surely that's a poor implementation? The parent post's point still stands. Browsers are "good enough" a very broad range of games. There's ample evidence of this if you wanted to look.
It doesn't work in Safari or mobile browsers. It's quite far from the expectations of a versatile web platform. WebAssembly has a lot of potential, so one day... perhaps.
If your favourite browser is Safari then there's a good reason developers might have targeted another browser - Safari is consistently slow in adopting the kind of features that enable more cutting edge web applications.
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.
I am happy they are experimenting with something fresh and cool. My complaint is that it can't possibly be anywhere near ready without being more inclusive.
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...".
But doesn't that mean Apple gets to choose the pace of advancement and be the gatekeeper of features?
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.
Not Apple... I think it's really the developer's responsibility.
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.
As a game developer that's done a bunch of web games, thank you. Parent is trying to shame game developers for not making choices that would destroy their businesses. It's quite strange to read.
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.
https://poki.com has 30 million monthly active users. That's more than e.g. DOTA 2, CS:GO, or any other single Steam game. Yes there is a lot of trash, but there is also some decent stuff on there.
Yeah, they did. Goalpost went from "is it even feasible" to "did the devs implement a compelling game" as if it was impossible to create a compelling game over the web.
People played browser games before because it was a way to play games without installing them. This is a use case that existed because of locked down computers in schools, universities and workplaces.
I hate to admit it (and it truly does pain me), but anything casual will be on a mobile platform. Anything on the web should just be ported to the mobile space.
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 =)
Advertisers were willing to pay quite a bit back in the days! While privacy is good, the advertising industry supported a p. large cottage industry of cool online game developers back in the days. A lot of people I know got their first buck that way in a way that's harder to do nowadays.
The web is reliably the best platform for the games our nonprofit produces. And we've produced dozens of them played by young people around the world for the past 15 years. (Yes, we've had setbacks with deprecation of Flash and Unity Web Player but webGL has been fantastic.)
Although the games are also available through the appstores or for direct download, those channels are not as accessible for many people, especially those on the other side of the digital-divide. No smartphone, tablet, or home PC? Then turn to the web instead: our evidence-based and award-winning games are used by educators in classrooms, by parents at home, and by young people who access them via public libraries.
The web is the best outlet for these games because it is by far the most accessible of platforms. These games are also much safer from a privacy perspective via the web than installing an always-on & always-tracking game from Google Play.
And though these are not AAA games and they don't include microtransactions or advertisements that merely means nobody is getting rich from them. But that isn't our goal. Our goal is to drive positive change in the most efficient way possible.
Genuinely free video games via the web is how to safely reach and empower hundreds of thousands of young people around the world about issues important to them.
My experience with WebGL has been hit and miss, because many people are blocked to use it properly, whereas native 3D APIs just work on the same system.
All due to how browsers block access to drivers or specific cards.
The editor UI is mostly implemented in the game engine, so dogfooding the web version of the engine for the editor will bring improvements in engine functionality and probably performance to all games.
I've seen a lot of people comment that they would love these for students, as their computers are locked down and they can't do much. Even trying to get the latest versions of the software installed is a burden if they DO manage to get the software installed.
This unlocks so much, in terms of being able to build games via the web browser without students needing to download software is pretty amazing.
Yes -- our non-profit publishes nearly all of our games to the web because they run reliably on browsers in schools and public libraries without plug-ins. We've deliberately gone in this direction to make games available to educators without risking the ire of network admins.
To put the actual game editor on the web makes even less sense. It's a cool technical feat, and the author may have thought of it as 'free', as some commenters have alluded to, given that there is already a web export, but anyone with a bit of experience knows that nothing is free, and certainly not a project like this. At the very least it's a months long effort (the author himself stated as much in the blog post), even before factoring in continued maintenance.
I love it as a technical feat, but I'll agree it doesn't make sense from a 'business' perspective (for lack of a better term, given it's an open source project).