How would I Organize My Scripting Better

Help and Feedback Scripting Support
#1

I was wondering how I could use modulescripts/folders to better organize my games scripting, And How exactly I would use modulescripts to do that?

12 Likes
#3

I’ve done a lot of scripting, Module scripts do have their place but for most of the work I do, they are more trouble then they are worth. A method I use is instead of having a module script just have a function at the top of a script before you start the scripting. Folders are always helpful for any type of organization. Just make sure you keep all main scripts inside of ServerScriptService, that is the best way to organize your work.

4 Likes
#4

Thanks for the speedy reply! Will work on making this a habit.

2 Likes
#5

How would they be more trouble? I use modules all the time and it has helped me organize and update code with ease.

3 Likes
#6

Its just most of the stuff I do, its either something small that I have to do several times such as making items which can be done with a function and return at the top of a script, or someone that I only have to do once, it harder for me to go into a module script, write it out, then come to a main script and use it then just doing it all in one script.

#7

Module aren’t meant to affect only one script. If it affects one script then there would be no purpose. Modules are meant for multiple scripts, for example a menu module. I made a menu module for my game and every time I want to close the menu, instead of typing:

function menu.close()
	if not menu.selected then return end
	if menu.selected.Parent == nil then
		menu.selected = nil
		if game.Lighting:FindFirstChild("Blur") then
			game.Lighting:FindFirstChild("Blur"):Destroy()
		end
	return end
		
	menu.selected:TweenPosition(UDim2.new(0.5,0,-0.5,-menu.selected.Size.Y.Offset), "Out", "Quad", 0.5, true)
	menu.selected = nil
	
	game:GetService("StarterGui"):SetCoreGuiEnabled(Enum.CoreGuiType.All, true)
	game.Players.LocalPlayer.PlayerGui:SetTopbarTransparency(0.5)
	
	if not game.Lighting:FindFirstChild("Blur") then local blur = Instance.new("BlurEffect") blur.Size = 0 blur.Parent = game.Lighting end
	local tween = ts:Create(game.Lighting.Blur, ti, {["Size"] = 0})
	tween:Play()
end

each time I want to close them menu, I simply require the module script at the start and type menuVariable.close(). This has saved me a lot of time, has helped me organize my code and has lead to a much easier time modifying it. Modules are a gift from heaven and you should definitely use it when appropriate. @TheKitDev, there are already many forum posts about this topic and you should refer to those instead of creating your own.

6 Likes
#8

With all do respect, how many scripts do you really need to close the menu from? In all of the menu’s I’ve made, I got 1 script that does open and closing function, then I got other scripts that power the content inside, such as buying items, changing clothing, etc.

Its basically exactly what I was saying, I can do it that way and have a module script that will do 1 task from 1 script and go through the trouble of going through and getting the module script, or I can just do it in the script to begin with, and if the rare case I need to do it from 2 scripts, just copy and paste it, might cost me 5 minutes, but big deal.

#9

On the contrary, I believe that module scripts are a major part of my work. They help with organization, classes, utilities to prevent repetition of functions and much more.

Organization

Module scripts allow you to create interactive systems and frameworks. Instead of having one script handle everything and having to search through thousands of lines of code, you can have a system of module scripts and edit one of them easily by the name of its job.

Classes

Classes allow you to, again comes organization, to organize objects and add functionality that you wouldn’t find in a non-modular system. There also comes metatables that can help further your class systems and makes the possibilities endless and create sub-classes, and so on.

Utilities

Last, but one I find important, is utilities. Modules allow you to have one script to allow multiple other scripts to require it instead of repeatedly writing a function in each individual script. An example, you find yourself needing to edit a function that is used in multiple other scripts. Imagine just editing that one function in a single script and you’re done compared to changing each individual function in each script.

Overall, in my opinion, modules help in so many ways and I would find scripting a lot more difficult without them.

7 Likes
#10

Of course everything I am saying is my opinion based off of experience, There is no one right way to do it because every person you meet you will tell you different, the best way is to just do it and see what works for you, but personally, module scripts are more trouble then they are worth.

#11

You need to learn OOP or a similar system. It will be very confusing at first, but it will make your projects many times better once you understand it!

3 Likes
#12

So here’s my experience. I used to think the same. I’ve later come to learn that if you’re not using lots of module scripts, you’re probably doing it wrong.

#13

I completely understand, I will admit using Module scripts make bug fixing easier, I’m sure one day once I find a need for it, I will most likely use them, just at this time and place, I am scripting full time and currently don’t have a need for them.

#14

1 in every 100 or so scripts, there might be a need for them, for something like a Gui menu that is changing clothing and you have 100+ options, in that view, they are useful. But in the view of basic scripting like a inventory system or a mini-game, aint really no use for them that Ive found.

#15

Modules are used whenever you have re-usable code or to store something for easier management.
Once you get into OOP and stuff like that, you’ll find modules a REALLY useful.

In my opinion, an example of good design is Aero game framework. It’s also a good usage of module scripts for both functionality and aesthetics.

2 Likes
#16

I have to take the side of ModuleScripts. This is coming from someone who has constantly, in the past, used separate scripts for each function of their game. Let me explain:

Using separate scripts is appealing and easy to set up. For example, let’s say I want to add a new tool to my game. All I would need to do is add another script to SSS, basically copy variables from another tool script, and continue on. But this is repetitive. I constantly found myself declaring the same variable(s) and event(s) across several scripts. Although this is not bad, I disliked how independent each script was. (This system has it’s benefits as you can imagine; I’m not disregarding it.)

I tried switching to having one main game script and many modules. Although this system is not active in my game yet, I am really enjoying the transition. It is very similar to the “many scripts independently do many tasks” workflow I mentioned in the sense that each module houses functions for a specific task. I feel like I have much more control over my code and that, if necessary, my partner would actually be able to understand my code. Although using modules has forced me to master coroutines, I think it is for the best.

As @12904 stated, we all have our own preferences and opinions. I respect yours. I just wanted to share why I have made this transition and the big benefits of it. In the end, use whatever works best for you. This is just what works for me. Thanks and sorry for the long read!

4 Likes
#17

Generally minimising the number of scripts running at once and using module scripts to extend the functionality of these scripts is beneficial and preferred.

Boring bit of history here which is semi irrelevant but gives a bit of background into why we do things this way. Feel free to skip this though.

Now why do I say this? First of all I would like to say that this is generally true with all of programming. If you look at the control flow of pretty much all major languages there is a single entry point (beginning of program) which goes on through lots of different files to eventually build up into the whole program. Let’s take C for example, you declare a main function which is our entry point and you require other code via the use of header files. Or Java, again you define a main function and import classes to use them.

Why is this preferred? Well originally all computers were single threaded. It made absolutely no sense to try running multiple bit of a program at the same time because they couldn’t run at the same time. And if you schedule them to emulate running at the same time by implementing a scheduler then you’ve just made a load more work for yourself. Not only do you need to make a scheduler but you now have multiple paths to try debug through if anything goes wrong. Bleh.

Nowadays schedulers are built into operating systems and we even have many cores to run things properly at the same time. Here it could make sense to run multiple bits of your program at the same time. But now we get into horrible confusing multithreaded problems such as one program writing a value at the same time as another. Then we get nonsense like 1+1=3? or 1+1+1=2? It gets messy fast.

Now we can get onto Lua. Lua runs on a single thread and runs one script after another making it seem like they are running at the same time. While this is a useful abstraction it’s helpful to remember. You can either have lots of scripts which lua will run back to back and weave into a single thread for you, or you can do this yourself and have full control. And when you think about it, why wouldn’t you want this?

With a single thread your program has to start somewhere. If you only have one entry point then it’s obvious where that is. You also know exactly in what order your code will execute. You know exactly what is assigning what to where. You don’t have to worry about things modifying other things in odd orders.

Now that boring part is out of the way let’s get to the fun analogies.

You can think of scripts as little workers. On their own they can’t do a lot. Now you could just chuck a whole pile of workers at a problem and make some amazing things (look at the pyramids!) but you can intuitively feel how inefficient this is. Instead you could give your worker some tools.

Modulescripts should be thought of as tools. Tools are fit for a specific purpose. They do one job and they do it well. They can be reused and have many copies made. You can give these tools to your workers and they will be able to achieve a lot more! I know I would definitely prefer to have a couple workers with amazing tools than have so many workers I can’t even remember their names!

Even better when you move to a new project you might have to hire some new workers however you can probably provide them with the same tools again. You can imagine how much faster this makes development.

While this is quite an abstract metaphor I hope it helps subtly convey the true nature of why modulescripts are useful.

48 Likes
#18

cohesion and coupling in a nutshell

4 Likes