Hacker News Reader

Comment by hopfog | Hacker News Reader

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.

View on HN

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.

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

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

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.

Reply on news.ycombinator.com