A Dedicated Singleton for Graphical Interfaces

[index_self]

Currently, the only way to render graphical interfaces on Roblox is by placing it under the PlayerGui instance that is (usually) automatically created under every Player instance.

This has many downsides with relation to developer ergonomics and performance, namely:

1. The GUIs get unnecessarily replicated for every player, but only when their character spawns. This makes working with GUIs before a character has spawned hard to pull off.
2. To have your GUI components dispatched, you must put it inside the StarterGui singleton. This is also the only place where they will render inside studio, which makes its runtime behavior seem unintuitive.
3. The existence of both the PlayerGui and its intended contents are not determined, because they are cloned based on character spawning. This leads to ugly and very hard-to-debug :WaitForChild chains.

Among many other problems. Because of this, I believe introducing a new, separate singleton will help mitigate these issues and make GUIs a little less of a hassle to manage both internally and programmatically.

The Proposal

Add a new service, named something like Graphics or Interface, which acts similar to a PlayerGui. When a client connects, the contents of this service will be replicated before any local scripts run.

Every GUI component in this container will be rendered, just like they are in PlayerGui. These components will also render in the Studio viewport, just like if they were in StarterGui. Changes on the server will be attempted to be replicated on the client like any other replicated container.

[metatablecatmaid (metatablecat)]

@index_self

• The server gets an unnecessary replica for each player’s GUI. This makes working with user interfaces through the server very hard to pull off, because each player has a separate instance.

Because you shouldn’t be. Unless you’re maybe trying to control if the client has a gui (and even then there’s better solutions).

Manipulating UI on the server with the expectation it replicates to each client creates ping issues. Its better to send messages down to the client with remote events (or instance changes), and let the client solely handle the UI.

On the main thing, if we have a singleton UI for each player, how do we create UI that is specific to each player, such as the player name?

[index_self]

Yes, I was thinking more about the intuitiveness of that behavior, obviously you should never try to do that. I’ve replaced that with another point.

---

@metatablecatmaid

if we have a singleton UI for each player, how do we create UI that is specific to each player

Scripts would be expected to add and edit things inside this container locally, and that shouldn’t be more awkward to work with because that’s what we essentially do with for GUI currently.

I would want this new singleton to replace StarterGui completely, but if need be, someone could still manually work inside the PlayerGui.

[sanjay2003 (Sanjay)]

I feel like this entire thing can be replicated by either a remote or something similar that pulls a gui from a place that already exists and then, manually parent’s it to the client’s gui after the character loads. Not sure if I am reading this correctly. It’s a bit confusing to read.