3 ms·

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

by hopfog 2y ago

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 2y ago
You probably found it already but performance wise you should look into WebAssembly: https://maxbittker.com/making-sandspiel https://maxbittker.com/making-sandspiel
- hopfog 2y ago
  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 2y ago
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 2y ago
  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 https://www.youtube.com/watch?v=prXuyMCgbTc ("Exploring the Tech and Design of Noita")
  - Joel_Mckay 2y ago
    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 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/particles/fluid_renderer/fluid_demos https://doc.babylonjs.com/features/featuresDeepDive/particle... Have a wonderful day =)
Drakim 2y ago
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.
nightowl_games 2y ago
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?

by hopfog 2y ago

speps 2y ago

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

hopfog 2y ago
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 2y ago

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 2y ago
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 https://www.youtube.com/watch?v=prXuyMCgbTc ("Exploring the Tech and Design of Noita")
- Joel_Mckay 2y ago
  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 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/particles/fluid_renderer/fluid_demos https://doc.babylonjs.com/features/featuresDeepDive/particle... Have a wonderful day =)

Drakim 2y ago

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.

nightowl_games 2y ago

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?