As far as I know, the most optimal and organized way to structure a game’s scripts is to have one server script (usually in ServerScriptService) and one local script.
The roadblock I’ve run into, or more a question of organization I’ve come to think about is this:
1 Main LocalScript is a bit of a tough situation. Mainly because it needs to be stored in StarterGui for Gui to be scripted (I’m Assuming?) so if you started scripting things like dodge scipts or running scripts, where should that ultimately go? The reason I ask is really just for the sake of organization. I don’t want my Gui scripts cluttered with things that shouldn’t be there, as organization is really important to me when programming.
Also, I’m pretty new to forum, so my bad if this is something that’s been talked about already. I did try and find it tho.
Using only one script isn’t going to work, imo. And I don’t get the organization part of it - sure, you only have one script, but a several thousand line script isn’t going to be easy to read. If you break it up into separate components where everything has a clear objective, that’s probably going to end up being much easier to work with.
Firstly, as you’re new to the forum, I would like wishing you a warm welcome. Anyways, if your game is filtering enabled, which is what you should be aiming for, then yes, GUIs can only be scripted through local scripts. They don’t need to be in StarterGui folder to script GUIs, they may be anywhere inside the player, that will still work. I kind of consider your aim tad confusing; you could have a main local script on player scripts, which could then command all local instances (GUIs, etc…) But it would turn out unpractical on the multiple user interfaces you could be striving for. Meaning, if you want a GUI which resets when the player spawns and one which doesn’t, it would be good having separate local scripts for each. It’s better having different ones for different purposes. Meaning, some for each GUI, along with a main starter character one and a main starter player one.
I hope this was of any use. Best regards, Eduritez.
Ah yeah. It most likely wouldn’t be thousands of lines. I’d be cutting down on a lot of it with ModuleScripts. That’s the whole point I’m asking after all, I want to be as organized as possible. Thanks
I keep all client-side code in one LocalScript inside StarterPlayer > StarterPlayerScripts and use ModuleScripts to modularise my codebase into smaller, logically separated, and easier to maintain units.
User input would likewise be handled this way. In-fact, I use ContextActionService, which allows me to seamlessly bind touchscreen, keyboard and mouse, and game pad input to the same action/callback (along with some other neat benefits).
It doesn’t; as long as you have a reference to some GUI object, you can manipulate it like any other. Every time a player’s character is loaded, the contents of their PlayerGui (parented to their Player instance) that do not have LayerCollector.ResetOnSpawn enabled are cleared. The contents of StarterGui that reset on spawn are locally cloned and parents to the player’s PlayerGui.
It is not necessary for you to use this service, though. Personally, I handle GUI parenting myself so it can be shown before the character first loads by immediately parenting a GUI folder inside ReplicatedStorage to the local player’s PlayerGui myself.
