I'm building a JavaScript game in my own engine, which in retrospect was a big mistake considering the game utilizes a lot of multithreading (the game is "Noita meets Factorio" so it's required for the simulation). You can only share memory between threads using a SharedArrayBuffer with raw binary data and you need special headers from the web server to even enable it. This means that I've had to write a lot of convoluted code that simply wouldn't be necessary in a non-browser environment.
Other than that I really like that I can piggyback on the browser's devtools and that I can use the DOM for the UI.
Yes, this is a really good article that I can highly recommend if you're interested in these type of "falling sand" simulations.
A big difference between a classic powder toy game like in the article and Noita is that Noita needs to run a much larger simulation that extends beyond the visible canvas. So while multithreading is probably not needed in the former it's most likely needed when the game is a scrolling platformer. I posted a GDC talk by the Noita devs as a reply to a sibling comment if you're interested in their tech.
There are plenty of babylon.js & physics package demos around.
The WebGL support can be an issue on some machines, but when it does work... things like procedural fog/pseudo-procedural-water/dynamic-texture-updates look fairly good even on low-end gpus. Also, the free Blender addon can quickly export basic animated mesh formats that will save a lot of fiddling with assets later, and the base library supports asset loading etc.
Like all js solutions your top 3 problems will be:
1. Audio and media syncing (don't even try to live-render something like a face mocap)
2. Interface hardware access (grabbing keyboard/mouse/gamepads is sketchy)
3. Game cheats (you can't trust the clients world constraints are true)
4. web browser ram/cpu overhead
The main downside of using __any__ popular game-engine is asset extraction is a popular hobby for some folks (only consoles sort of mitigate this issue).
If you haven't played Noita it's basically a "falling sand" or powder physics game where every pixel is simulated. You need a special cellular automata that is not your typical game physics engine, so I don't think Babylon.js would be a good choice but I may be wrong.
We use multi threading in the netcode for our browser based games built in Godot. I've been considering looking into using web workers _without_ shared array buffer so that we can use threads in all environments, even without cross origin isolation. Is that something youve looked into?
One might say MacOS users use Safari most of the time, but sadly it is not possible to get a pixel perfect (or at least not wildly off) canvas if a user changes the zoom settings:
This is a decision made for accessibility reasons on Apples part, but I can’t find the quote on that anymore.
Alternative mechanisms to size the internal resolution of a canvas correctly are also not supported on Safari.
Some time ago I needed some 3d on web so I did simple rotating textured cube demo and out of 30 webgl libraries tested only 2 achieved 60fps for such a simple demo. On web you have no performance to spare so when you plan on making larger project test performance first. If it's slow with simple stuff, it's only get worse as you add more and more stuff. (Sorry I don't remember which 2 were fastest, you should do your own tests anyway because when you will be writing your rotating cube demo you will read their documentation, maybe even posts on their community forums and you'll learn how good is doc and how friendly is the community)
Wow, how long ago and what device!? It’s definitely not an issue I’ve come across. Even when people have disabled HW acceleration I would think most devices wouldn’t even sniff.
Missing one of the best choices as long as "maturity" isn't on the top of your list: Bevy - https://bevyengine.org/
Game engine written in Rust, leveraging ECS in almost every place and way, with a really capable WASM export option. Wrestling ECS for the first time might take you some time, but in my experience helps you keep game code as clean and decoupled as game code could be.
Ah true, the heading is currently "Web Game Engines & Libraries" which seems to have confused me. A better heading would be "JS/TS Engines & Libraries" I guess, as many of the Rust ones enable "Web" usage too.
I really like Phaser 3, but if you're more accustomed to a traditional polling-style engine loop (inputs, logic, physics, render), it does take a little getting used to.
It's very much a "batteries included" game framework with the exception of a built-in map editor though you can just use something like Tiled.
Three.js is really good and Babylon.js looks good too. But when I was evaluating 3D engines recently I was surprised to find that neither one is properly tree-shakable -- you need to import almost the whole core engine even if you’re only using a tiny part of it.
Other engines are either lacking features, or also aren’t tree-shakable, or both. (For example, I think OGL is shakable but it’s much more low-level, just a very thin wrapper around WebGL.)
I guess it’s no big deal as both big engines minify down to around 500KB, IIRC. Just a shame they can’t get smaller than that if you just want to make a tiny little 3D widget.
I only skimmed the landing page but it seems like it helps more with the while pipeline (asset creation, packing and optimising) rather than just the end rendered.
I've been making a text adventure as my first Rust project and really enjoying it. Maybe one day I'll turn it into a crate for making text games that compile to both CLI and WASM.
While you absolutely can use Godot to export to web, I found the exports themselves to be pretty lacking. For one, the export size is much larger compared to other game engines and frameworks. Because we're targeting web and not desktop, small size is a must-have as many people who play web games are more likely to leave and never come back if they're waiting for the game to load.
Export size is very important. We got our Godot export (assets + wasm) down to < 10mb after brotli compression for
https://goobershot.winterpixel.io/
I believe the wasm is about 5mb and the .pck is about 5mb.
You can shrink the wasm by disabling unused modules in your Godot compilation and not compile stuff you don't need. You can remove debug symbols, and enable link time optimization as well. We could push our export size even smaller, but I have higher priorities.
three.js is not a game engine. it’s a 3d rendering library. It has no feature of a game engine. No collisions, no physics, no input systems, no facilities for game objects or ai or state machines etc…
I have a feeling other libraries on the list are similar
The heading of the section is "Engines and libraries", and the subtitle for Three.js is "3D library" so seems correct?
The page doesn't make the claim that Three.js is a game engine.
Other than that I really like that I can piggyback on the browser's devtools and that I can use the DOM for the UI.
A big difference between a classic powder toy game like in the article and Noita is that Noita needs to run a much larger simulation that extends beyond the visible canvas. So while multithreading is probably not needed in the former it's most likely needed when the game is a scrolling platformer. I posted a GDC talk by the Noita devs as a reply to a sibling comment if you're interested in their tech.
The WebGL support can be an issue on some machines, but when it does work... things like procedural fog/pseudo-procedural-water/dynamic-texture-updates look fairly good even on low-end gpus. Also, the free Blender addon can quickly export basic animated mesh formats that will save a lot of fiddling with assets later, and the base library supports asset loading etc.
Like all js solutions your top 3 problems will be:
1. Audio and media syncing (don't even try to live-render something like a face mocap)
2. Interface hardware access (grabbing keyboard/mouse/gamepads is sketchy)
3. Game cheats (you can't trust the clients world constraints are true)
4. web browser ram/cpu overhead
The main downside of using __any__ popular game-engine is asset extraction is a popular hobby for some folks (only consoles sort of mitigate this issue).
Best of luck, =3
If you haven't played Noita it's basically a "falling sand" or powder physics game where every pixel is simulated. You need a special cellular automata that is not your typical game physics engine, so I don't think Babylon.js would be a good choice but I may be wrong.
I've modeled my architecture after this fantastic GDC talk by the Noita devs: https://www.youtube.com/watch?v=prXuyMCgbTc ("Exploring the Tech and Design of Noita")
https://www.youtube.com/watch?v=rSKMYc1CQHE
It should port over if you are not hitting super fine granularity, and the collision model for the sprites is simplified.
Some of the Babylon.js fluid examples still need a bug report:
https://doc.babylonjs.com/features/featuresDeepDive/particle...
Have a wonderful day =)
But I just want to raise awareness that currently it is impossible to get 60fps for a canvas in chrome on MacOS without dropped frames:
https://www.vsynctester.com/
I have tested with an M2 Air and an older Intel MacBook Pro. I think this is related to this bug report (open for many years) but I am not sure:
https://issues.chromium.org/issues/41136434
One might say MacOS users use Safari most of the time, but sadly it is not possible to get a pixel perfect (or at least not wildly off) canvas if a user changes the zoom settings:
devicePixelRatio does not change on zoom as it does in other browsers and I believe the spec. https://developer.mozilla.org/en-US/docs/Web/API/Window/devi...
This is a decision made for accessibility reasons on Apples part, but I can’t find the quote on that anymore. Alternative mechanisms to size the internal resolution of a canvas correctly are also not supported on Safari.
Game engine written in Rust, leveraging ECS in almost every place and way, with a really capable WASM export option. Wrestling ECS for the first time might take you some time, but in my experience helps you keep game code as clean and decoupled as game code could be.
JS ECS libraries are listed here: https://www.webgamedev.com/code-architecture/ecs
It's very much a "batteries included" game framework with the exception of a built-in map editor though you can just use something like Tiled.
https://github.com/KilledByAPixel/LittleJS
Don't get me wrong, it's very simple, but it was fun.
Felt like using Flash again. :)
Other engines are either lacking features, or also aren’t tree-shakable, or both. (For example, I think OGL is shakable but it’s much more low-level, just a very thin wrapper around WebGL.)
I guess it’s no big deal as both big engines minify down to around 500KB, IIRC. Just a shame they can’t get smaller than that if you just want to make a tiny little 3D widget.
Though maybe I'm not the target audience.
https://hseager.github.io/you-are-merlin-www/
https://github.com/hseager/you-are-merlin
I believe the wasm is about 5mb and the .pck is about 5mb.
You can shrink the wasm by disabling unused modules in your Godot compilation and not compile stuff you don't need. You can remove debug symbols, and enable link time optimization as well. We could push our export size even smaller, but I have higher priorities.
I have a feeling other libraries on the list are similar