That question interests me too, because I would imagine it would do quite well. Godot's failings seem to be ones of omission, as a rule, and having less built in might help in browser-based games, because there would be less to download to get started, while still allowing for the basics in many classes of game. I know it's strong on 2D.

I don't know for a fact it's lighter than say Unity, it just seems like it would be. Anyone with more direct experience here?

I have written a few games in Godot, which also work in the browser for Ludum Dare. [1] Works great, 2D and 3D, with small differences, but I can only speak for GDscript. I'm not sure if C# exports are working.

First and foremost: Build time for all export targets together (windows. linux and web) takes less than 10 seconds and usually just work.

Some things like GPU particles had to be replaced with CPU particles and I remember that some texture compressions were not properly supported. But other than that, it mostly works out of the box. Can only recommend.

[1] https://ldjam.com/users/zubspace/games

It has been excellent, best browser game engine imo - however as of Godot 4, the web export is completely broken, unfortunately. Godot with C# straight up has no web export and no mobile export atm, just desktop.

> best browser game engine

> web export is completely broken

> Godot with C# straight up has no web export

Hmm, something is amiss here... They're already on RC5 and web export not working doesn't sound like the web platform is a focus of theirs. AFAIK, the web export being broken is not mentioned in "Known Issues" about V4 either.

In the Runtime Changes Section: "Mobile and web platforms are not supported at the moment, and will be worked on for a future Godot 4 release." / "For the mobile platform specifically we are going to use the Mono runtime."

Web Export for 4 is fine, just not with C#. That may be the same thing to some people, but there is a distinction.

No, it's not fine. It's broken on Chrome for macOS and freezes on startup for about 10-20 seconds. Has nothing to do with C#, this happens with GDScript, too. It's a known issue, has been discussed at length on Github (by myself as well) and there is no fix in sight at the moment.

I would consider that broken.

> AFAIK, the web export being broken is not mentioned in "Known Issues" about V4 either.

It may be outdated since the reason it no longer works is because of these C# changes, as mentioned in the article.

Regarding Godot 3.x and HTML5 export. Users reported crashes with GLES3. It seems stable rendering is based on GLES2 (WebGL v1.0). Some features don't work in HTML5 (e.g. "Some features are also not supported in WebGL 2.0 specifically."[1]; "built-in antialiasing will not look correct for translucent lines and may not work on certain platforms" [2])

[1] https://docs.godotengine.org/en/stable/tutorials/export/expo...

[2] https://docs.godotengine.org/en/stable/classes/class_canvasi...

Does anyone actually play games in the browser? I mean, there is no technical reason not to, but I kinda find it strange.

Sorry if my question was worded badly. Obviously, some people are playing games in the browser - perhaps I should have asked more specifically what the appeal is, e.g. is it mostly small casual games like what Flash used to be used for, or do people actually play more invested games?

And sorry again if the answer to these questions is so obvious to some of you that the question itself sounds dumb, but I'm simply not experienced with this topic.

Running games in the browser provides a bit of convenience of not having to download and run a platform-specific executable. There might be some security benefits too.

Depends on the nature of the game though. It works best for games that are lightweight and stateless.

Sure, this was clear to me too. My question was not so much about the advantages of browser games but rather if they actually have a market.

And speaking of that: what are the main monetization schemes? Are browser games sold like other games? Or are they mostly ad-based like other web content?

As one data point: https://itch.io/games currently lists 729397 games, 844 of which are tagged HTML5. It's nonzero but I guess it's not that big. But https://itch.io/games/html5 lists 301816, I am not sure how to reconcile these numbers.

Some of those are accepting donations, but I can't tell if they are profitable.

Browser based games are huge (often with kids). A lot of of popular games cluster on .io domain names. Shell Shockers has been a big FPS:

https://shellshock.io/

And there is a whole genre of multiplayer things eating things to get bigger:

https://agar.io/

http://slither.io/

Yes, lots of people do. Not as much long story based games, but more arcadey/casual games. This is especially common for kids using computers at school. Just think about all the old Flash games, that style of game is still popular.

Lots of indies like to make their games available and easily playable (e.g. no download) during development on itch so for that use case, yes, it's important.

That sounds cool and interesting - so, the idea is to eventually sell the final product as a stand-alone game, but target the browser for development versions from the same source code?

The binaries produced just for the engine itself (so exluding the game code and assets) is already several MB large when compressed with brotly or gzip. So it works, but it's too large to be competitive enough on web games portals. Most players will just go play another game if it takes too long to load (download). Only JS based game engines and to some extend Defold are good enough in this regard.

Note that the article mentions ahead-of-time compilation and binary size trimming as one of the explicit goals of this version.

Specifically if you're using .NET, that wouldn't apply to GDScript the same way.

We made https://rocketbotroyale.winterpixel.io in godot 3.5. ~ 20MB wasm binary, ~20MB game assets. We did however, have to do a ** ton of engine modifications to get the performance characteristics we needed on web, so mileage may vary depending on what you are actually building. But overall, 3.5 supports web very well. 4.0 is too unstable for us to use it yet, so jury still out on that one.

But the absolute, most amazing thing ( coming from the anxiety of app 'submissions', going through 'reviews', etc ), is the ability to update/fix/hotpatch everything instantly. Like within seconds. We have a simple CI/CD workflow that builds, updates & deploys a new godot site ( with dedicated gameserver backends) within seconds. The ability to just do this however you want, whenever you want, without going through some kind of platform distribution interface is great. With the exception of WGSL being such a dumpster fire of a spec, I'm pretty bullish on web for gamedev & distribution. There's some really great stuff being built right now, see: wasm+webtransport+wgpu

I want to say I'm a big fan of this game, simple and really fun! Good job!

Do you see any use cases to include WASI into your godot gaming support? Maybe midi music too.