See also:
Fabio: Thank you everyone for being here. My name is Fabio Alessandrelli, I'm the maintainer of the web platform of Godot game engine. Godot game engine is a free open source 2D/3D game engine. Which you can use to make all kinds of games. It tries to be a very generic game engine, without a specific game type or genre in mind. And as part of its export platform, it also has the web platform, which uses WebAssembly.
Fabio: We also have a Web editor which I will also show at the end to give you an idea of what it's capable of, and what is its status on the web. The presentation is titled Godot on the web, current status and future plans", and I will give you an overview of what we are at and what are the challenges we are facing, what are the consequences of some of those challenges, and what we plan to solve some of those problems we are encountering.
Fabio: First of all, Godot 4 was released on march 2023 as the fourth iteration of the game engine. We are currently in the process of releasing Godot 4.2. We are keeping up the pace of release with a reliable schedule every 4 months. We are a bit overdue for 4.2, but we are nearly there. We are currently in release candidate 2.
Fabio: Godot 4 in general has been a huge modernization of the engine. Godot has been in development... It was open source since 2014 but it was already in development since 10 years before. And it was becoming a bit old in this architecture. This fourth iteration really focused on modernizing it a lot and bringing it on par with more modern engines. One of the things we did, for example, is heavily relyin on threads to optimize both load times and performance in general. We added a new Vulkan renderer to get high quality, like AAA graphics or almost AAA graphics.
Fabio: We added a thing called GDExtension which allows to create binary addons so you don't have to modify the engine to write wrappers for third party libraries or SDKs, or those kind of things. You can actually build your own addon, compile it, and then Godot will will load it as a dynamic library.
Fabio: And in general, there's a lot of new features from animations to the asset pipelines, to the multiplayer system, and so on.
Fabio: This came with a bunch of challenges when it comes to the web. One of the things at first we wanted to explore, WebGPU... but sadly WebGPU is not ready yet. Unity announced a few months ago, or a few weeks ago, that they are adding WebGPU support. I've been trying to analyze support and, as kind of expected, it almost works on some browsers, but it doesn't work on most of the browsers. The wider issue was historically that the shading language of WebGPU was not standardized. Now it's finally being worked on but it's still in a draft status. Also, our abstraction layer for the rendering... because, as I mentioned, we added Vulkan support, but we are also adding DirectX 3D 12 and Metal rendering and they all work with an abstraction that we created for the engine. But suddenly that abstraction doesn't really fit WebGPU since, like many things on the web, some of the stuff must be asynchronous, and that is different from any other graphics library.
Fabio: Some of the consequences of these issues is that people who need to target mobile devices prefer... Oh, one thing I forgot to mention is that we also implemented a WebGL2 renderer! The people that need to target mobile devices still are stuck on Godot 3.x because WebGL2 on iOS doesn't work really well in Safari on iOS. There are a bunch of issues. That's one of the issues we are facing. The other thing is that, of course, we wanted to reap some of the benefits of WebGPU but that hasn't materialized yet.
Fabio: Some other challenges is about threads. As I mentioned, Godot 4 really relies on threads and the support for threading on the web is still not great. We're encountering a bunch of issues. It requires secure context, and also cross origin protection and cross origin embedder policy. We looked at moving the loop of the engine outside of the main thread of the browser. Because you should never block the main thread of the browser. But we are seeing some issues with WebXR because WebXR, which is supported by Godot, only works inside some specific callbacks which are not easily accessible from a different thread.
Fabio: Some of the consequences of choosing threads and requiring threads to work is that Web exports are kind of hard to monetize because advertisement platforms and in-app purchases won't work with COOP/COEP in most scenarios unless you are hosting the game, like distributing the game, on the same domain as the ad platform and the in-app purchase platform. It simply won't work because it doesn't allow you to embed elements from other domains. There have been some work here to allow credentialless either which means that you can embed them, but then the browser will refuse to send credentials in those cases. Which again is a huge problem when it comes to add purchases because you cannot validate the user in any way. And also for ad platforms because, again, in some cases, maybe the user is a paid user so you would want to remove the ads. But then you can't remove the ads because you don't know if the user is actually logged in to your game or platform, and is a paying customer.
Fabio: For this, most of the people are actually stuck with Godot 3.x on the web. And as I mentioned before, we couldn't really run the main loop on a dedicated thread because that would completely break WebXR. We're trying to figure out how we can proxy those goals but it's not a really easy thing to do.
Fabio: When it comes to GDExtension, there have been quite a few issues. One of the things is that WebAssembly didn't really standardize the linking metadata. So it did not standardize how functions should be exported and imported. And we also notice that threads plus dynamic linking seem to only work properly in Chrome. We have opened an issue and mentioned this to the Mozilla team. They are working on it but it's still only working on Chrome.
Fabio: Since there is no standard of linking metadata, everything must be built with the same tool. In our case, we use Emscripten to compile C/C++ code to WebAssembly. But changing versions, having different versions, sometimes means that the linking metadata has changed. You really need to use the same tool!
Fabio: The consequences are that most people don't use GDExtension on the web, and the Mono version (because Godot also supports scripting using Mono or C#). The Mono/.net version is still not available on the web because we are fighting these issues with different versions and different tools that are used to compile C++ code to WebAssembly.
Fabio: Some of the solutions that we are working on. We implemented, and this is already implemented, a GLES3/WebGL2 renderer. It's quite different from what we had in the past and it's more for compatibility. It doesn't have all the features, but at least it can run in most browsers. Again, there are still some issues on iOS, Safari specifically. We are exploring re-adding the WebGL1 renderer. This is tricky because, while the whole class of modern graphic libraries (Vulkan, Metal, DirectX 3D 12) and to a point WebGPU, share the same model, WebGL is quite different, like OpenGL, and that requires a lot of overhead from the rendering team to obtain these main rendering pipelines.
Fabio: And we are exploring further refactoring of the core abstraction to support WebGPU, using the same abstraction we use for Vulkan, Metal, and DirectX.
Fabio: For the threads, we kind of gave up on this. There doesn't seem to be any solution at the end of the tunnel. We will probably be reintroducing a single threaded version that brings back a bunch of problems we had in previous Godot versions, like the audio being not great whenever the CPU is struggling a bit. But at least people can move to Godot 4 and start monetizing their game on the web.
Fabio: We keep working on multi-thread support, the idea of moving the main loop to a thread, hoping for some general better browser support. And trying to figure out how we can work around the issues with WebXR.
Fabio: We are also evaluating a hack, basically adding a service worker with the games we export to automatically add the required COOP/COEP headers when they are missing because a lot of users are struggling... Even if they don't want to monetize, most of the platforms do not provide those either, and so they are stuck in the situation where they don't know whether they can publish the game unless they have their own web server. Luckily, we are in contact with some of the platforms, like Itch.io and others. They are adding those headers as an option. They have to make it an option because that kind of breaks most of the monetization options. One of the goals of Godot is to be simple and easy to approach and the need to know things about headers, web servers, is not something that Godot users in general want to care about. We are evaluating what I consider a hack.
Fabio: When it comes to GDExtension, we are working on documenting the fact that we are building with this specific version of Emscripten the official releases, and then basically telling our users: if you want to use GDExtension, then make sure to use this exact version of the tool, because anything else might - Here, be dragons - break.
Fabio: We want to mention to the user the limitations of browsers support, and hopefully wait for them to fix those issues. We haven't been able to make GDExtension plus threads support, which is a requirement, to work on any browser outside Chrome.
Fabio: And again, as we work on a single threaded version, we would probably suggest using that if you want to use GDExtension, at least until browsers manage to get the support that one would expect.
Fabio: We also have some more work that we want to explore. Which is WebAssembly 64 bit support. For now, we use wasm32 as a target. But it seems that wasm64 is reaching a nice stage. So we want to explore that. We want to also explore the Native File System API. Because, as I mentioned, we have a web editor that can work. But exporting your game from there is usually problematic, and basically accessing the project that you create is really hard. We have a tool that allows you to ZIP it and download it. But it's far from what we would like to see. But Native File System API again is only supported by chrome. Other browsers will implement the origin specific file system API. It's not accessible from the regular user file system. So it's kind of helpless for our goal.
Fabio: We are exploring more internal refactoring to support the fact that a lot of the APIs on the web are asynchronous. I mentioned it in the past, the fact that the Crypto API is asynchronous for reasons that are not really clear given that the Permissions API it uses then actually blocks the blocks the browser main thread anyway. I don't know why it's asynchronous, but it is.
Fabio: We are also working on getting the Asset Library to work with the web editor. The Asset Library we have right now relies on third party hosting. There are, for good reasons, limitations due to cross-origin policies, and even more now, that will require COOP and COEP. We basically need to write a new asset store that takes this into account. This was planned anyway but it's something that we are basically adding to the things to do.
Fabio: And this is mostly it. It wasn't a long presentation, but I hope it gives you an idea of where we are at and what we are trying to do.
Fabio: If you want, I can also show the web editor a bit. Just so you get an idea of what Godot is capable of, even in the current status. So let me share the screen again and try to get the correct page. This one. Can you see it?
Fabio: You basically go to editor.godotengine.org, and it brings you by default to the latest release. Which, right now, is 4.2 RC2. You can start the editor. Usually the first load is a bit slower because it needs to download the WebAssembly, which grew quite a bit in Godot 4.2 because we have been supporting a lot of new things, which impacted on the binary size.
Fabio: But it's still acceptable, I would say. We then use PWA and service workers to cache the WASM even if it would be too big for regular caches. The limitations are a bit better there. And then you can create a new project or you can import other projects by drag-and-dropping. You probably can't see this, but I will drag and drop a project here. And then it tells me: Oh, you want to install this project? Yes, let's install it and it will load inside the local. Everything is local. We don't have cloud services. We are not actually uploading it anywhere. Loaded into the Indexed database file system.
Fabio: This is a 2D platformer demo. Let me lower the audio otherwise it's gonna kill ears. You can try out your game by pressing play. Great! It's not laggy usually, but now I'm screen sharing, so my computer which is a bit old is not too happy about it. You can play it. Then you can close the game, edit for example the player position, move it somewhere else, and then play again. Then the player is in the new place. So you can basically try as you develop.
Fabio: We do not yet support exporting the game from the web platform. This is something that we hope to add. But you can download the project source. So when you click here, as I mentioned it, the engine will ZIP, maybe it isn't working right now, I haven't tried this part... It's definitely broken. The idea is that it will create a ZIP file of your project source, and then it will let you download it. Then you can re-upload it to another computer or open it with your native editor, and then actually do the export part.
Fabio: That was the small demo of the 2D version. Maybe I can also show the 3D Platformer demo. It is an old demo, but also on the web, we can't expect too much from the browser, especially on my computer. But this should still work. Importing a few things... Then press play. Still a bit laggy again. This is mostly due to screen recording. This is a 3D demo. Can I hit it? Yeah!
Fabio: I guess that's it. I don't have much more to show. We stayed in the 25 min that we agreed upon!