The way that I see it, there are two ways of implementing GuiObjects into a game.
Designing it using the studio editor, moving it to ReplicatedStorage and then using :Clone() to access it in a LocalScript.
Using a ModuleScript to create the GuiObjects using Instance.new() then filling in properties and calling it through a LocalScript to access it.
I am thinking about converting a lot of the GuiObjects I have in my ReplicatedStorage into script-created GuiObjects. I can think of a few pros/cons for either one, such as using a ModuleScript keeps ReplicatedStorage clean and using ReplicatedStorage keeps the number of ModuleScripts down.
Which method do you prefer/use andwhy?
I don’t know if this is the right category, but I was told to move it to Help & Feedback
I personally use ModuleScripts to create GuiObjects due to the fact that it is a built in table, and I can add functions I feel necessary without being limited. It is also a bit more secure in the sense that; it is harder to exploit due to an exploiter having to decode your module without having access to it.
I also enjoy the fact that it is a lot cleaner of a script and requires less trouble shooting should something break, as oppose to cloning in which you would need to look at each individual step; though I guess again it could be a preference thing.
Most developers I know and have worked with are split in what they use, so it seems like it doesn’t effect the game in one way or another. Do whatever feels right to you and you are more comfortable with doing. I will say though, if it’s your first time making module functions I wouldn’t recommend experimenting on something somewhat complex like this would be.
IMO creating a little API that allows you to create and modify GUIObjects works better for me in terms of organization and how modular things are. It allows for things like this:
local Inventory = InventoryObject.new() -- Create the UI
Inventory:Populate({Item1, Item2})
Inventory:Show()
Inventory:Hide()
It really comes down to personal preference, it might be easier for you to just create it using the editor and leaving it at that.
I think a common misconception is that people who create UI using code is that they aren’t actually doing any design with the editor, most people who use code to handle their UI use a plugin that turns an existing UI into code which saves time in the long run. You really get what you make out of it, if you code yourself a nice API to go with the UI then you will get a lot more out of it than say just creating the UI with code when a player joins.
maybe I don’t understand correctly but I don’t do either of the above for GUIs in my games.
I like having every GUI in “StarterGUI” and having the unneeded ones being invisible, when they are needed a script calls on them to become visible (they are all designed using only the GUI editor and properties tab)
In what way does this serve as an anti-exploit measure or a safer route? There is no difference between keeping them in ReplicatedStorage or StarterGui other than for organisation or based on your use cases. The exploitability remains the same: the client can see it, the client can modify it.
No, it really isn’t. ReplicatedStorage is a container that contains instances replicated to both the client and the server in storage for later uses. StarterGui contains children that are replicated to the player’s PlayerGui upon respawn.
How is it more secure? What kind of empirical evidence do you have to support this stance? Where did you get this stance from?
To answer your question I would only create UI through modules if a large number of related UI element are to be constructed. What do mean by this? For example in a placement system game it would be best to create shop through a module because all of the individual buttons would be similar with the only difference being the picture and price label, and also it would not be feasible to make all those UI elements, and updating that UI when new items are to be added would be time consuming. Another example would be in simulator games where you have a shop with a ton of new items you can purchase, it would be best to have some sort of base button and then to create each button you would just use a table to house all the information about each item, and then iterate over that table to create each individual button, with the use of some sort of grid or list layout.
There’s no difference. I personally like to keep them in StarterGui as it makes sense to me and it’s just less of a hassle. If you have your GuiObjects in ReplicatedStorage, like Colbert said, it would not affect security. ReplicatedStorage can be accessed by both the client and server. Same with StarterGui.
I don’t know what kind of analogy you’re trying to make or how it’s relevant. The difference of “security” between ReplicatedStorage and StarterGui is absolute zero and you’ve yet to prove this in any sort of way (which you can’t). Please remain on-topic.
The player doesn’t automatically need to search for anything as a result of the difference between where you place it. ReplicatedStorage and StarterGui are equivalent containers at a fundamental level, the difference is their functionality and how they are used in a development environment.
StarterGui is intended to hold LayerCollector instances and render them to the player’s screen or in the 3D world in the case of Billboard and Surace Guis. ReplicatedStorage is meant to hold assets that can replicate from the server to the client but not vice versa. The client and/or the server can access its contents and use them as needed.
The reason why what you’re saying can’t be understood is because it doesn’t make sense in the first place. I did ask you before to provide a citation regarding the behaviour you believe exists and you’ve yet to do that. An analogy isn’t empirical evidence and it’s not saying anything useful either.
Basically it seperates modules into server, client and shared folders. Shared and client go in replicatedstorage (or wherever you want) and server goes in serverscriptservice.