Benefits to using a Module System

Help and Feedback Scripting Support
1

Are there any benefits to using a Module System over a Framework besides Organisation?

1 Like
2

I’m not sure what you mean by “Module System” and “Framework,” they’re both essentialy the same things.

It is always good to use ModuleScripts, there is simply no away around it. If you don’t, consequences will soon reveal themselves, such as inadequate code failing, trying to find errors, wanting to change values for different scripts all at once, etc…

In short, if you wanna be a good little programmer, then you must practice D.R.Y (dont repeat yourself). And guess what? ModuleScripts are key to D.R.Y, so yes, if you have a game you genuinely are working on, and you dont use modules…

Back up, and get ready for alot of refactorization because simply, you just cannot as a human being, work with a messy codebase.

And no, it’s not for just organization, they’re used for many different things, implementing event-based-programming (Signal class), OOP, elements of OOP, inheritance, stc…

ModuleScript’s main use? Reusability, like if I have a wait() custom implementation, I’ll use that.

ModuleScripts are also great for script communication, say you have a Fart variable, and you wanna change that, but you also want it to be global, so other people (scripts) can access Fart

Real quick, remember that module scripts are CACHED. Meaning you can use them for communication (every modulescript is cached once on the server, then multiple times on clients)

So let’s make our Fart variable accessible by everyone!

Let’s use our default module assignment template.

local Farts = {}
Farts.Fart = 0



return Farts

Okay, so that’s done, so you can see that I define the Fart variable in the module itself, this can be done publicly or privately, (change Farts.Fart to local Fart = 0)

You should do this if you wanna only allow certain modifcations to be made to a variable.

Alright so by now, I think you know what we need to do.

local Farts = {}
Farts.Fart = 0

function Farts:FartSilently() -- little pipsqueak..
  Farts.Fart = Farts.Fart + 1
end

function Farts:JuicyFart() -- a nuke
  Farts.Fart = Farts.Fart + 10
end

function Farts:GetFarts() -- or just get Farts.Fart
  return Farts.Fart
end

return Farts

Perfect, now we have all the getter and setter functions we need. Let’s try it out on the server.

(Server Script #1)

local Farts = require(path.to.Farts)

print("My name is " .. script.Name .. ", and I currently see " .. Farts:GetFarts())
-- prints out "My name is ServerScript1, and I currently see 0


Farts:JuicyFart()

(Server Script #2)

local Farts = require(path.to.Farts)

wait(5) -- arbitrarily delays, should never use wait in real-world

print("My name is " .. script.Name .. ", and I currently see " .. Farts:GetFarts())

-- prints out My name is ServerScript2, and I currently see 10

There you go, ModuleScripts have alot of use-cases but generally are used for organizing (which is not bad…)

3 Likes
3

Framework is just one huge LocalScript or Script that manages everything that the context it resides from

1 Like
4

And those Variable names and Method names, they scare me with their childish names

1 Like
5

The two terms you mentioned can easily be the same thing, but don’t worry, I understand what you mean.

The benefits from making a framework based on modules vs a framework with one master script is simply; organisation, as you said, and reusability - being able to access and use the same code with multiple scripts.

6

They’re meant to give just an outlook to modules, it doesn’t take away the aspect of learning from my post, and 1 giant Script doesn’t sound neat or performant to me…

1 Like