Even if I need to spam scripts, it’s possible to have a module that interfaces with multithreading so I have a just one example script that gets cloned to spawn jobs through requiring modules. The biggest hurdle for me would be changing my game’s data system so that some data can be loaded by different threads (right now it requires modules/data once when the server replicates it then dereferences it.)
I think I would spawn threads using actors until require starts returning a cached value within an actor’s script (not all at once, just as jobs are created.) You could think of each thread almost like a client without FilteringEnabled; There’s no reason to run the same script on the same client multiple times when its jobs could be handled by a single script, especially if your game is already modular. From there I would set up a lightweight job manager on each thread, and allocate jobs to each thread by firing BindableEvents.
Here are a few use cases that would benefit from multithreading:
- Simple predictable CFrame animations. This includes things like tree animations, candle flames, custom water graphics, cloth movement, etc.) A BulkMoveTo equivalent for bones would really help with performance for these uses. This is the first thing I would multi-thread.
- NPC AI and character physics on the server. NPC responsiveness in relation to players might take a hit if its inputs are off by a few frames though.
- Skeletal animation systems in Lua. I would need to make a lot of changes in my game to multithread the game’s current characters, but it has a lot of potential. My main worry would be that multithreading local character graphics might cause events or animations to be off by a frame. This would also benefit from a bulk method for bones.
Multithreading can really help make your systems scalable. For games with huge worlds and high player counts, the server has the most to gain.
