Running your entire framework through a single script, is it truly a wise decision?

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?

5 Likes

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.

4 Likes

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.

4 Likes

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?

7 Likes

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?

4 Likes

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?

2 Likes

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 :stuck_out_tongue:.

4 Likes

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:

2 Likes

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.

1 Like

A single local script which uses module scripts to perform its actions.

2 Likes

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.

2 Likes

How many Scripts and LocalScripts do you use?

1 Like

I use one script, and one local script

2 Likes

People commonly think that making module scripts that run code is not making another script, when it is.

1 Like

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.

1 Like

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.

3 Likes

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.