Web Game Engines and Libraries(webgamedev.com)
webgamedev.com
Web Game Engines and Libraries
https://www.webgamedev.com/engines-libraries/web-game-engines-libraries
36 comments
You probably found it already but performance wise you should look into WebAssembly: https://maxbittker.com/making-sandspiel
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.
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).
Best of luck, =3
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
Thank you!
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")
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")
If all you want is 2D fluid flow with points, than Sebastian Lague's talk is very practical for the frame-rates he hits:
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 =)
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 =)
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?
For me personally, that's exactly the sort of thing that ends up teaching me so much, so it's very valuable in it's own right.
A bit off-topic,
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.
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.
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.
Check out Renderlet https://www.renderlet.com/
Yes! You should be able to get nearly native performance for that sort of pipeline out of a WebGL backend.
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.
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.
These are only JS engines. There is a dedicated page for Rust with Bevy: https://www.webgamedev.com/engines-libraries/rust-game-dev
JS ECS libraries are listed here: https://www.webgamedev.com/code-architecture/ecs
JS ECS libraries are listed here: https://www.webgamedev.com/code-architecture/ecs
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.
Bevy doesn't have great wasm support currently especially with multithreading but they are working on it.
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.
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.
I've been building in LittleJS a lot recently, and it's very enjoyable (for small games, at least.) I get Pico8 vibes using it.
https://github.com/KilledByAPixel/LittleJS
https://github.com/KilledByAPixel/LittleJS
Kaboom was a pleasure to use.
Don't get me wrong, it's very simple, but it was fun.
Felt like using Flash again. :)
Don't get me wrong, it's very simple, but it was fun.
Felt like using Flash again. :)
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.
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.
One of the sites has a fantastic landing page: https://needle.tools/
(you scroll through 3D scenes)
the marketing is indeed super slick, in terms of added value for the framework, as needle is built on top of threejs, I'm not sure I'll bite
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 admit it's really cool, but it's not a good fit for a landing page IMO. Would be great if it was behind a "demo" button or something.
Though maybe I'm not the target audience.
Though maybe I'm not the target audience.
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.
https://hseager.github.io/you-are-merlin-www/
https://github.com/hseager/you-are-merlin
https://hseager.github.io/you-are-merlin-www/
https://github.com/hseager/you-are-merlin
I'm in love with Gamemaker, which got me interested in programming: https://gamemaker.io
https://godotengine.org/ and export to web .
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.
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.
If you were serious about making anything this would be the way to go.
these guys seem to be serious https://equinox.space/ and they used threejs
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
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.
Three js has quite a few examples of collision and LOD in its examples folder, I feel you are underestimating it
[deleted]
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.