[hopfog]

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.

[speps]

You probably found it already but performance wise you should look into WebAssembly: https://maxbittker.com/making-sandspiel

[hopfog]

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.

[Joel_Mckay]

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

[hopfog]

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")

[Joel_Mckay]

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 =)

[nightowl_games]

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?

[Drakim]

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.