After the big engine release of 7.0 (coming really soon!), I’m dedicated to focus on adding the web target as a new engine platform.
The goal is simple: allow you to recompile more-or-less any application you wrote using Castle Game Engine (using
TCastleWindow) to the web. So you can put your application on a website, as part of a normal HTML webpage, and users can play it instantly, without the need to download / install any native application or plugin.
We’re using FPC WebAssembly target. Huge thank you go to the whole FPC team of course for making it possible!
We will render using WebGL 1.0, with optional WebGL 2.0 features. This is very similar to current rendering on mobile, where we use OpenGL ES 2.0, with optional OpenGL ES 3.0 features.
For audio, we will add a new sound backend using WebAudio. This will be the default sound backend on the web (like the OpenAL is now the default backend on non-web platforms).
It is also possible our FMOD sound backend will also be ported to web, as FMOD supports HTML5. This would make FMOD a truly cross-platform sound backend, working on every platform we support in CGE.
I recently wrote more about WebAudio in the context of X3D 4.0. Supporting advanced X3D 4.0 audio nodes is not our priority, but since WebAudio will happen anyway, on the web… they will open this possibility. There is also LabSound that provides WebAudio-like API on non-web platforms, and in principle it could one day replace OpenAL, making web and non-web audio handling closer.
For data delivery, we know we’ll have to invent a simple format to carry our game data as one big binary blob. The simple plan is to just pack game data into zip.
For development purposes, likely we’ll add a “Run simple webserver on localhost” feature, to allow you easily run WebAssembly applications. This can be done using a number of things, I like most the idea of using fpWeb which can instantiate a standalone HTTP server in just a few lines of code.
What we have now:
Branch webassm_platformer_test in CGE contains a code that compiles (but it is not functional yet!) for WebAssembly. This means that CGE compiles, and also build tool supports a new OS/CPU. So you can enter any CGE project, and execute on command-line:
castle-engine compile --os=wasi --cpu=wasm32 # or castle-engine compile --os=wasi --cpu=wasm32 --mode=debug
We’ve encountered FPC issue #40229 (Wasm32 symbol xxx without index value error) but it is now happily fixed 🙂 Many thanks go to Nikolay Nikolov from FPC team for fixing, and Andrzej Kilijański for preparing a code to easily reproduce the issue.
Trung Le (Kagamma) has been doing lots of work with CGE + FPC WebAssembly. His fork contains a branch wasm32-wasi-port with lots of active work. I absolutely expect that we’ll merge it to CGE webassm_platformer_test at some point, and then to master branch 🙂
As noted by Trung Le (Kagamma), the important issue hanging on FPC now is #39547 (wasm32-wasi: Cannot create dynamic library). Go ahead and upvote it 🙂
File-size tests are promising. Compilation of examples/platformer, which practically uses 100% of CGE units, yields a binary
platformer.wasmthat has 16 MB. Gzipped it has 3.4 MB.
The gzipped size is really what matters — both web browsers and servers support gzip-(de)compression on the fly, you can also just put ready-gzipped version on the server and tell the browser to just decompress. So in all practical cases, users will download 3.4 MB, not 16 MB.
Note that above is for a release build. The debug build weights 51 MB, and gzipped 12 MB. How is the debug build actually useful on the web — I am not certain now 🙂
We could also use Brotli, a newer compression method also commonly supported by web browsers and servers.
I want to thank everyone involved in this and let’s push forward! Web target is a really cool feature, from my talks I know it’s an important feature for many CGE users, and I feel we have it in our reach. Let’s keep coding and enjoy making games 🙂