PSA: stop using unnecessary and useless loading screens unless needed!

I have seen sooo many people make “loading screens” that only add more wait times and bloat to the persons game and say that it loads things spite them either looping through game:GetDecendants() which makes their “game” take YEARS or them straight up just doing i kid you not:

--[it was a pain to recreate this....]--
wait(5) --[they didnt even use task.wait btw, i hate this]
for _,v in game.Players.LocalPlayer.PlayerScripts:GetChildren() do
    v.Enabled = true
end
 --[^^^^ completely useless since they dont even have a ModuleLoader/Service system 
-- in their game so theres nothing to even load from that]--

script.Parent:Destroy() --[end this monstrosity]--

AND THEY SAY THIS IS NECESSARY ^^^^^^

they dont use ContentProvider, they dont even use a ModuleLoader system for them to even need a loading screen in the first place they just lazily wait/loop through the game and wonder why it takes so long or why theres still unloaded meshes ingame spite just yielding for 5 secconds.

Please dont do this, it does not help your game doing loading screens like this only makes it worse…

instead if you need to load meshes/assets use ContentProvider with your loading screen and only loop through important/priority assets and not the whole game/workspace and if you dont have a ModuleLoader system in your game and you feel like you need to load in scripts… DONT as i said you do not need a loading screen for your scripts and if you do require your scripts to need to load in a sequential order and make sure they are loaded… PLEASE USE A MODULE/SERVICE LOADER.

Thank you so much for reading this!!! if you can spread this to other people who are new to developing and might make the same mistake many others did please do and again thanks! :3

13 Likes

what are you even talking about

its a method of loading code where instead of having a script or localscript for your code you have it in a ModuleScript within folders and you have 2 scripts one for the client and one for the server to load all those modules. if you get it.

2 Likes

That’s just stupid.
If you want stuff to load instantly, put it into a single script; don’t balkanize code for the sake of it.
That’s a misuse of ModuleScript.

1 Like

i mean only for specific things not ALL of your code lol sorry if i didnt clarify

That is not a misuse of ModuleScripts. There is an entire popular scheme called Single Script Architecture I believe that is literally this. Have all the arguments you want about whether that’s better than multiple scripts, but that does not mean misuse.

10 Likes

Content provider is not even required for a loading screen, the loading screen mostly consists of Data Loading, Render replication focus, Setting up of client systems and so on.

Content provider is useful if your game prioritize ImageContent.

1 Like

I have seen some Loading GUI Free Models that do a fake 60 second loading time.

1 Like

This IS literally multiple scripts performance-wise, but even worse.
People who use that don’t know what they are doing.

yea ik its just that mostly loading screens are used to load meshes/images and most people want to do that prob

its actually insane how long some games take to load i always question wtf they are loading :sob:
some of these games even have hundreds of thousands of players forsaken
and why does slap battles ui take years to load thats a thing in of itself

my game takes like 10 seconds max, it just loads player data from the server and the assets used for the main menu with cp

ME TOO!!! like the worst case ive ever seen of this was in a game my friend played called “let him go” which had to loop through EXACTLY 144594 INSTANCES YES YOU READ THAT RIGHT it took 10 MINUTES to “load in” and it was sooo painful just knowing that most of the game wasnt even made up of meshes but just regular parts and the fact that roblox already loads most of the things without any manual work in almost an instant and they just put it in either because:

  • they thought it made them look more professional (it didnt)
  • or they just didnt know about how roblox really loads things and thought they had to put it in

which just further proves my point on why people should NOT just watch a
youtube tutorial on how to make a “loading screen” and then decide loop through the entire game object with game:GetDecendants() to “load” it. :sob:

and more concerning is that some people really waited out the 10 minutes to play a game about a guy getting run over by a car DX

you are throwing around a nonexistent buzzword. please educate yourself.

1 Like

Absolutely reprehensible take :wilted_flower:

what “buzzword” what did i even use that pisses you off so much im genuinely curious :sob:

It’s just an organization technique, there’s different benefits to using each.

See, there is a difference between you and me. I throw sarcasm when it’s witty, and you throw sarcasm when you can’t win an argument because you know that you are lacking knowledge to do that.
Besides that, you seem to not understand that module scripts and the Luau compiler do not have any kind of linker to merge module scripts into a singular bytecode proto, so what you end up with is balkanized pieces of proto that are hard for the VM to execute. It’s like having multiple programs instead of a singular one running, basically.

@TimeFrenzied
If you want multiple scripts running, just do that; it will not create a trillion-layered stack like your “single script architecture does”, You seem to forget what language you are writing code for, and it all comes down to “initiating” module scripts.
If you don’t return anything from a ModuleScript and just use it for code execution, you’re literally using it as a glorified Script. That’s misuse by definition - the exact thing you’re defending.

1 Like

this is the general format i use for modules that i want to put code in them:

--[put in extra things for the main function like vars, instances, services ext]--
local WhateverNameYouWant = {}

--[or put vars, instances, services ext in here]--

--[this is uesd by the module loader script to execute the code]--
function WhateverNameYouWant:Init()
	-- put in code that you want to run
end

return WhateverNameYouWant --[return the module like you said i didnt]--

and this is obviously a small snippet how a simple module loader works:

for _, v in ReplicatedStorage.Shared.Services:GetDescendants() do
       --[optional to match name but still i do it because i sometimes have submodules to the
       -- main module that i only store data in, not code there are many ways of doing this]--
	if v:IsA("ModuleScript") and v.Name:match("Service$") then
      --[pcall to make sure something failing does not stop all others from loading]--
		local success, result = pcall(function()
			require(v):Init()
		end)
		if success then
			print(v) --[simple way of knowing if it loaded]--
		else
			warn("Failed To Load: " .. v.Name .. " : " .. result) --[warn with result]--
		end
	end
end
--[i have predefined the services for this i just didnt include them lol]--

so since you think that people do not return a module script when doing this i think that you dont know really what a module loader is and that you barley did any research on how they are usually done so please next time fact check before claiming something.

2 Likes

Single Script Architecture can be very nice. I’m not sure why you’re so vehemently against it?

One of its great use-cases for me is for determining when code runs. Sometimes some code has to be ran after other code, and single script architecture can simplify this process.

I’m not sure if you just don’t understand what it is? If you don’t understand it, there’s no reason to say people who use it simply, “don’t know what they’re doing.”

For me, it is also an effective solution to incorporate the behavior of loading screens into my game.

2 Likes

how about you don’t tell me what to do

Resources > Community Tutorials

1 Like