Most frameworks share a common characteristic - they operate using a single script, or more accurately, two distinct scripts: one for the server and another for the client. However, it is worth questioning whether it is truly beneficial to run our games with two separate scripts. Upon closer examination, it seems the approach appears to be flawed in terms of best practices and performance.
So would it be a good idea, to follow the trend?
I personally recommend having a script for each major action in your game. For example a fighting game would have a combat script and maybe a shop script.
Itâs not a good habit to get into. You might be able to say otherwise if your game is simple and doesnât require much effort. When dealing with a large amount of code, however, you should always try to consider whether something should be a module or not. It is entirely up to the developer to decide how to write their code and where to put it.
Never Scripts, only ModuleScripts. I think that everyone should only have one Scripts and only one LocalScripts but a max of well-organized ModuleScripts. However, Iâm curious to know if many people agree that only one script and one LocalScript to initialize the ModuleScripts is a good practice?
I would appreciate a talk about why its flawed. Simply stating it âhas flaws in best practice and performanceâ doesnât really help anybody since SSA is an extremely simple concept. What flaws specifically? What performance concerns?
Well what would the difference be in having multiple scripts for different purposes and one script with multiple modulescripts for different purposes?
I get that modulescripts can be used by multiple other scripts, but if only one script is using the module (assume said module is meant specifically for client or server) then why use it?
When it comes to frameworks vs multi-scripts, I think thereâs some benefits to both so it really depends on your use case.
Benefits of Frameworks (Iâve found at least when working with them)
Expandability. Probably one of the greatest parts of frameworks, lot of frameworks allow you to create custom services and easily call them from scripts. If you need new functionality, you can simply create a new service.
Consistency. Frameworks generally force you into writing consistent code. This helps with readability and also helps on multi-scripter projects. People â assuming they know the framework â will be able to join the project and get a simple grasp of everything.
Benefits of Multiple Scripts (note you still can have core modules like ProfileService)
Portability. As an example take the Roblox sword, since it uses a separate script directly parented to the tool, you can put it in any game and just expect it to function without the need for you to setup a framework inside of each game that you want the sword.
Coding speed. Frameworks generally make you think about future expandability and want you to write most of your code inside of functions or OOP. If your goal is to quickly get a game completed or add a small feature, it can be way quicker to create a simple local script or script. Also lets say you need a rainbow script, while you could create a component for that with tags. If you just need it in one place, just making a simple dirty script can do that trick (and you can move on to more important things)
I generally write with multiple scripts, cause I like to complete stuff quickly. Sometimes I develop games in a single day, and converting code to fit within a frameworks would take a bit too long. I live by the mindset that you can always go back and fix your code if you need to, but if your game never comes out due to you losing motivation, then you have no game to fix 
.
Personally, I adopt this approach because it makes code easier to maintain and it allows me to connect my modules together. This way I have precise control over the order of initialization, deciding the first and last module to be initialized.
Script:
LocalScript:
personally I use separate scripts for specific game mechanics such as a data manager, map manager, weapon manager, etc.
when I need repeated functionality such as different weapons with similar code I use modules.
A single local script which uses module scripts to perform its actions.
I started getting into using modules for everything (one script, one local script), and I can never go back. When it comes to having systems interact with one another, expandability, reliability, and so on, modularizing everything makes it a breeze.
How many Scripts and LocalScripts do you use?
I use one script, and one local script
People commonly think that making module scripts that run code is not making another script, when it is.
If you have a Script and ModuleScripts, then you have a single script that executes the code. ModuleScripts need to be initialized by a Script or a LocalScript to work, and thatâs what makes it interesting. You can choose the initialization order of your modules and connect them to each other. I used to use multiple Scripts and LocalScripts before, but I stopped this practice because it wasnât a good way for me to work on ambitious projects.
It can definitely help with project organisation. Having a framework of organised module scripts where the format of one module is similar to the rest? It makes learning the framework much easier for new members of the Dev team. Most frameworks also promote module interconnectivity. Being able to run a quick :LoadModule() and have any module you need in seconds is great, it can really help speed up your coding.
But as youâve pointed out, frameworks are usually initialised through a single script - a single script that every module runs through. From what I can tell, doing things this way doesnât carry a performance penalty. Not directly at least. Of course, you have to be careful when it comes to modules requiring each other and forming a loop - but youâd have to be careful of that regardless of whether you used such a framework or not.
The main issue then stems from an inability to do certain specific things. Such as run code in parallel. Which is honestly quite a niche thing at the moment, but itâs impossible to run parallel code through a single script. But then again, thatâs no reason to not use a framework where applicable, it just means it wonât cover 100% of every use case. But thereâs nothing stopping you from having some areas of your code run through a âsingle scriptâ framework, and other areas run on other scripts. Youâve got lots of flexibility.
âSingle scriptâ frameworks definitely have their place, and Iâve seen a few great games that use them. They do carry some great benefits, especially when it comes to writing code quickly and uniformly as a team. But like a lot of things, they wonât work everywhere. So really it comes down to personal preference and compatibility with what youâre trying to achieve.
Itâs bad decision. Enough is that fact that scripts have limit of 100 local variables.
Itâs actually a 200 Local Variable limit. And OPâs not talking about writing his whole game in a single script (which definitely shouldnât be done); theyâre talking about using a single script to initialise a large library of module scripts.
Doing so wonât count towards the local variable count of the initial script, so itâs nothing you have to worry about by using a framework like this.
As someone who uses SSA, Iâm not sure what âflawsâ youâre talking about. I use it because it makes it easier to debug (extremely simple control flow) and I hate having random scripts placed everywhere. Additionally, a lot of stuff in my projects is automated (instead of manually setting up UI animations I have a styles module that has all of the presets used in the game, which I can call a function on to apply to a UI element) so having a bunch of like 3 line scripts doesnât make much sense.
