SNKRX VS threads.js

One thing that really helped me is looking at the source code and assets of one game that I really enjoyed -- SNKRX, the creator of the game, a327ex, put everything on Github so you can take a look how a finished game looks: https://github.com/a327ex/SNKRX/. The repo even includes the various images needed for Steam, this was very nice so I could make sure some of the assets I made aren't unfit for their purpose: https://github.com/a327ex/SNKRX/tree/master/assets/media . There are also some Photoshop files provided on the Steamworks FAQ which are very useful too, but they mainly show just in which area of the image you shouldn't put important text etc.

If it helps, here's a devlog for a reasonably successful game built in love2d.

SNKRX/devlog.md : daily breakdown of what he actually worked on from the start for his SNKRX game

SNKRX daily devlog for the first 3 months << very detailed of what he was doing each day

I'm the developer of SNKRX and on top of what most other people mentioned, the truth of the matter is that making games is hard and making games while working on someone else's codebase is even harder. Anyone who has the capacity to do anything useful with your game's codebase will likely also have the capacity to make their own game from scratch, so they'll just do that instead.

SNKRX is a commercial game and is open source (MIT), but it's not an open source project -- the developer is focused on improving their game for their gaming community and not building a development community around the game.

Threads.js makes it pretty easy to spawn a thread pool and handle multi-threading workloads.

We did this via the npm threads wrapper and esbuild. We first moved all of our compute code into a new file with minimal imports, called imageCompare.worker.js. We then added a pre-compilation step with esbuild to compile this file into a bundle. We then spawn the worker using this generated file as a blob, and interact with it via the threads promise interface.

That latter one is in it's own process, and I also use multiple threads with the threads library.

This app has a memory leak where your worker threads are spawning out of control. You can verify this in Chrome DevTools Source tab: after you click the Generate button, you can see the worker threads spawning out of control until you close the process.

I'd advise that you do a better job at manually spawning and terminating the threads with the TFJS process. I've had success using this library in combination with TFJS: https://threads.js.org/

You can use it for everything. Even the compute tasks you can offload to worker threads using something like https://github.com/andywer/threads.js or you could create intensive modules in Rust and integrate using something like https://github.com/neon-bindings/neon

Web worker meets worker threads – threads.js\ (3 comments)

threads.js