How do SSA games handle GUI?

[devvrs]

I am just wondering how games using single-script architecture handled GUI. Currently I just have a localscript for each GUI, but I’m wondering if I’m suppose to use modulescripts in a certain way? Is there any benefit in trying to implement SSA with GUIs?

[BendsSpace]

Even single script setups use a Script and a LocalScript (or a Script set to client context), so it’s not really “single-script”.

If you mean having all the code in a Script and LocalScript, I would recommend against that.

If you mean having a script require various modules (would recommend), I would just have a module that is required by the client side of things and sets up the UI and has an interface for detecting actions, along with code to send actions back to the server.

For example:

local ClientShopUIManager = {}

function tryPurchaseItem(item)
    -- Send a remote event to the server to purchase an item
end
function createShopUI()
    -- Add the open button and build the shop UI
end
createShopUI()  -- Create the UI when required

ClientShopUIManager.Opened -- Have an event for when the shop opens, potentially used in other scripts to close the UI
ClientShopUIManager.Closed
function ClientShopUIManager:ForceClose()
    -- Close the shop, used when other UI are opened
end

ClientShopUIManager.ItemPurchased

return ClientShopUIManager

-- Required by the main LocalScript
local ClientUIManger = {}

require(script.ClientShopUIManger)
require(script.ClientMenuUIManger)

ClientShopUIManger.Opened:Connect(function()
    ClientMenuUIManger:ForceClose()
end)

ClientMenuUIManger.Opened:Connect(function()
    ClientShopUIManger:ForceClose()
end)

return ClientUIManger

You can do whatever you want though. The example above isn’t super well thought through.

[devvrs]

I still have multiple scripts (that do require different module scripts) for completely different aspects of the game, so its not totally SSA, but I’m not so sure on how to implement this architecture for UI.

From what I’m reading I assume there would be a modulescript for each UI and one single localscript for handling each UI event (mouse clicks, etc.) and sending signals to the server?
But you are also creating the UI every time the function is called, is that better than having different ScreenGUIs for each UI and enabling them when needed?

[BendsSpace]

You can encapsulate it how you like, when making modules a good way to think about it is what “interface” you want to expose.

For example, you could have one module that sets up the UI and exposes action events, another module for handling those actions (i.e. sending them to the server, applying effects, etc). Or you could just do both of those in the same module.

I generally have one client module for all the UI, that then requires separate modules for different groups of UI (e.g. a shop, menu, settings, etc). The main UI module does all the interactions between UI (closing UI when other UI are opened, etc.).

---

@devvrs

From what I’m reading I assume there would be a modulescript for each UI and one single localscript for handling each UI event (mouse clicks, etc.) and sending signals to the server?

I would make one module script per UI and have that module script also handle sending the remove events too. For the events, I like to have the module send them in a higher-level way than just clicks, so stuff like “equip item” or “purchase item” rather than “button pressed”.

@devvrs

But you are also creating the UI every time the function is called, is that better than having different ScreenGUIs for each UI and enabling them when needed?

When a ModuleScript is required for the first time it runs, but after that it doesn’t run again. So in the example module above, I was thinking it would create all the UI, including a button made to open and close itself.

It’s definitely better to not totally reinstantiate the UI all the time.