Currently, my game’s framework is handled like this:
There is one local script and one server script for the client and server both individually.
These scripts require and initialize every single module script in replicated storage and server storage separately.
my questions are:
Is this bad?
How should I implement multithreading into this. as my whole game is ran on one script?
If this is bad, how should I fix this?
I wouldn’t necessarily say it is a bad thing, if your game is running the way you intended, then you all set.
The only thing that would concern me is when either script, local or server, breaks due to an error, which would break the whole game. The breaking of the script could be caused by a number of things, such as excessive ping times from poor connections, or third party clients entering the game with ill intent. The latter of the issue’s i’ve shown can be prevented by having anti-cheat code in both scripts but I believe that would require it to be constantly checking for any signs.
It’s indeed bad for organization and you should consider change from 1 script to few scripts in main mechanics, for instance one script can handle data stores, second inventory, third tools ect.
This isn’t bad at all. You’re using modules so your game is organized and works the same way as it would without them. Large frameworks like Knit work the same way.
It’s literally how most professionals Studio work, since they use Rojo and Knit ( probably ), you just call your different services ( for server ) and Controller ( for client ) in their respective part, very efficient !!
asynchronous function, promise and Coroutines can do it though… lots of things can enable your script to do two things, contrary to expectation Roblo doesn’t read your script in a linear fashion, so there’s no worry !
But why not split code into the most important sections and then use it? rather than relying on one script? it’s much easier to manage if every system/framework have it’s own main script, unless your game is simple you should consider this split, also it allows you for parrarel luau
well tbh we basically have 2 scripts that require everything else ( client script and server script ), you did split everything into multiple section to make it readable and then regrouped them, that could be used for example for debug purpose where you could track which part exactly exploded
Yk, having code in one single scripts is not that good as i said, you can’t use parrarel lua and also your devs might struggle with reading them, i really advise you to split this script into let’s say 10 systems with 300 lines instead of 1 big script with 3000