How should I organize GUI scripts in SSA?

I’m trying to make a game with single script architecture, which is pretty difficult since I’m pretty new to scripting. I don’t know how to organize GUI in this game.

So far I only have a module for managing vehicles, but there’s GUI correlated to the vehicle, and I’m wondering if GUI should be managed in multiple different modules (driving GUI in driving module, inventory GUI in inventory module), or if there should be a central GUI manager module that handles all of that and sends relevant information out to anything that needs it.

In short, I just don’t know how I should program GUI into my single-script architecture game.

1 Like

Because the vehicle GUI will need to be accessed by the vehicle module and the inventory GUI will need to be accessed by the inventory module, I would say that the GUI should be handled with it’s associated modules.

Having a module that handles all of the GUI just seems unnecessary.

Hope this helps!

2 Likes

You don’t, I mean tbh that sounds very horrible to have a game only have 1 script. I couldn’t image how painful it would be to dig through stuff. Seperate everything you can, make module scripts for each GUI, this is what I see in most bigger games. Local scripts in starterplayerscripts to update them, remote events to send information back and forth. I can’t find it good practice at all to do what you are doing and I highly recommend you practice new methods of scripting.

1 Like

From the way I understand it, I believe he has modules for everything (meaning he has a module for vehicles, inventory, etc.) which all manage their own section of the game.

I don’t believe everything is in one script.

Single script architecture is a generalized practice in modern Studio programming and a lot of games use it. The concept is that there is a single LocalScript and a single ServerScript that both require several ModuleScripts that have very specific purposes. This allows everything to be localized and function in a determined order.

I would agree that it can get confusing, however, it is more performant and effective in the long run.

1 Like

I haven’t really seen that before in most games its 1 script per game logic, for example if I had two game logics, 1 for redeeming codes, one for daily rewards.
Each system should have seperate scripts in SSS.
“Codes”
“DailyRewards”
Regardless of if you have 1 million module scripts or 5 local scripts, you shouldn’t limit it to 1 script and combine Codes and DailyRewards. They should remaine seperate. I hope that better explains what I was saying as never, you should never, have 1 script do many different game logics. Btw you can absolutely do that but again bad practice.

1 Like

Here is an article explaining everything: (Click)

The way it works is that you aren’t combining scripts. You are making modules out of the scripts, and then using 1 script on the client and server to run all of the modules’ events.

This concept makes it so that there are hundreds of ModuleScripts in your game, but only 1 LocalScript and 1 ServerScript running all of the events.

Once again, it’s a way to “localize” all of your code. This also makes it easier to recall and reuse code, as it’s all stored in module events that can be called as many times as necessary.

1 Like

Ah okay, that makes a little more sense to me. I was thinking he had 1 script handle everything.

1 Like

Lol no. That would be absolute hell lol.

1 server script and 1 local script and everything else is in modules, idk i read it somewhere and it sounded good

i’ll do it that way then. thanks for the advice!

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.