I recently made a medium-small script that handles all of my UI-related code. I was wondering what was better for optimization. A big script OR several small scripts.
Here is the code (its not finalized. Just basic functions).
local Button = script.Parent
local Play = script.Parent.Parent.PlayButton
local TeleportService = game:GetService("TeleportService")
local BackButton = script.Parent.Parent.Parent.TextFrame.BackButton
local TextFrame = script.Parent.Parent.Parent.TextFrame
local sound = game.Workspace.Sound.MenuSound
TextFrame.Visible = false
TextFrame.Credits.Visible = false
TextFrame.Line1.Visible = false
TextFrame.Line2.Visible = false
TextFrame.BackButton.Visible = false
sound:Play()
if sound.IsPlaying == false then
sound.TimePosition = 50
sound.Play()
end
Button.MouseButton1Click:Connect(function()
TextFrame.Visible = true
wait(0.5)
TextFrame.Credits.Visible = true
wait(0.5)
TextFrame.Line1.Visible = true
TextFrame.Line2.Visible = true
wait(1)
TextFrame.BackButton.Visible = true
end)
BackButton.MouseButton1Click:Connect(function()
TextFrame.Visible = false
TextFrame.Credits.Visible = false
TextFrame.Line1.Visible = false
TextFrame.Line2.Visible = false
TextFrame.BackButton.Visible = false
end)
Play.MouseButton1Click:Connect(function()
TeleportService:Teleport(6531645220)
end)
I personally use only one LocalScript for all of my UI code. However, if I’m handling MarketPlaceService stuff, I would use a separate script to do that.
I think what you are doing in that code is fine, it’s nothing to worry about at all.
If you want to be organized, don’t have too many scripts, but a central script for handling one type of thing (like a local script for UI) would be better than having a local script for each button (it’s a bad practice tbh)
I feel like I use too many scripts and I have to redefine the same variables. I think as long as you handle errors properly, then one script is the better option.
I personally feel like the less scripts you have, the easier it is to optimize and manage your code. However, at the end of the day, what works best for you or your team (if applicable), is the best choice.
I also think it’s good to avoid having too many scripts that perform a similar task. However, I think it’s also pretty important not to stuff separate, not-so-related functions into one script especially as the scale of your game increases. As for the tasks that many separate scripts in the game have to accomplish, use module scripts!
Looking at your code example specifically, I think you’re doing great! There doesn’t seem to be a need to use a separate script for now. However, if you want make the code a little more compact, I would suggest using this function for changing the visibility of multiple objects:
local function SetVisibility(Objects, VisibilityToSet)
for _, Object in pairs(Objects) do
Object.Visible = VisibilityToSet
end
end
SetVisibility({TextFrame, TextFrame.Credits, TextFrame.Line1, TextFrame.Line2, TextFrame.BackButton}, false)
Ok so I’m just gonna point out after everyone here is suggesting to make very long scripts… That is a very bad practice!
It’s important to organise your scripts neatly, create neatly stored modules, a clear naming scheme, etc.
Scripts with similar behaviour should probably be using the same script and/or module, not many copies. In general, don’t copy longer pieces of code between scripts.
The industry standard everywhere in programming is to make short, understandable and reusable scripts. The functions inside should be short and aiming to perform only one task each.
This helps to keep your code modular, and in the end helps you find what to change where more easily: as your projects complexity increases, a bug in a spaghetti script with thousands and thousands of lines will be very hard to find.
While only few programmers take these standards all the way to the max - it’s simply so practical to do several things in a function - you should at least take the advice a little bit. =P Any scripts over 1000 lines should be a clear red flag, grouping way too many things to do, that should be in their own module.
Incidentally, this script is not too long, in my opinion. The functionalities also seem related, so there is no problem there. If there were many more buttons, you should probably start separating them by category to their own scripts.
In terms of performance/optimization of your code, it won’t make any difference wether your scripts are long or short. But what does matter is the time it takes us to find something going wrong, and properly naming our functions and scripts in the end makes that much easier in bigger projects.
By making more scripts and by using modules, the game will look cleaner and it will be easier to manage. I usually create custom services with modules, and create roact components with them too.
What I personally prefer to do is use as few scripts as possible.
For example: one for UI, one on the server, and one in ReplicatedFirst.
Each of these scripts requires a few modules, which require their own modules that they need etc.
Especially if you implement the 4 pillars of OOP, and keep 1 class per module script, your code will become easier to read and maintain.
This is quite a decent article if you wanna learn more about OOP
But it is up to you if you want your game to be maintainable, it does make it way easier to make changes and add features.