I enabled “Show Hidden Objects in Explorer”, and the player list is created/connected regardless of SetCoreGuiEnabled. There are API calls being done for every single player in the server, which is a big problem for large games that disable the player list.
This adds up to a grand total of 13 instances per player in the server, or 1300 instances in a 100 player server. This doesn’t include the all of the connections and API calls being made for each player, including waiting for Player.leaderstats, checking for friends, checking if a player is an admin, checking if a player is an intern, and checking if a player is an influencer.
This design is not scalable! CoreGui’s should be designed such that they can be connected/created and disconnected/destroyed as needed to improve performance on low-end devices. The default PlayerList could also benefit heavily from only initializing a player’s button and checking for icons when it is visible in frame (or almost in frame).
I did some testing, and many of Player's properties are also replicated to everyone in the game. This means there are a handful of values like CameraMaxZoomDistance being replicated once for every player in the game, to every player in the game, instead of selectively to the target client. Even just replicating every player in the server is unheard of in modern MMOs, let alone replicating a client’s camera and control settings to other players.
The Backpack also creates nearly 100 instances that are never used in games that disable it, although this isn’t nearly as significant as the player list.
This makes a lot of sense when the Playerlist is disabled via SetCoreGuiEnabled so we will change this so that the UI objects are not created if this is disabled.
However for the settings menu there is a trade off here with the creation and layout time of the UI so it isn’t clear whether this is preferable. There are other things we may look into in the future such as reusing GUI objects in the player scroll list if this memory usage proves to be a problem.
The settings menu uses the PlayerList objects? (I’m not sure what you meant with the trade off here)
But yes, this is actually an issue for large scale games, specially when you look into 200 player servers. The memory usage can get drastic on these amounts.
He means that the player list has initialization time. This is true, however items in the player list have a fixed height, so it’s not even necessary to create all of the items in the Gui list (just the ones in frame, and a few out of frame for console controls), if connecting the list proves to cause lag spikes when opening the menu.
The creation and layout time will be quite fast if the tabs themselves and their contents have the same as-needed behavior, instead of generating the entire UI including tabs, subtabs, button decoration, localized labels within each tab and button, etc.
Just create the tab when it’s opened, and create buttons when they’re in-frame. My entire game does this and it’s much more scalable. CoreGuis already generate the layouts using scripts, so it shouldn’t require too many resources to make changes to a few things.
The entire settings menu is fine as is for now, what I’m mainly concerned with is all of Guis and API calls being done constantly as players leave and join huge multiplayer games. If creating the player buttons when the player opens the settings menu causes a lag spike then I’m even more worried, and we should employ a more scalable solution.
Low end devices would even benefit from a different player replication solution if developers are going to attempt 200 player servers. You only really need to see nearby players + friends, and maybe have a menu that you can open to load who’s online.
At one point I tried parenting players to nil in my game to prevent replication and improve performance, but that made players unable to report eachother.
I want my game to have a massive world with hundreds of players, but features like global chat and global player lists are difficult to develop compelling alternatives for. StreamingEnabled is great, but we need an equivalent solution for player replication.
I think you should just revert the player list, the old design was fine but the new one has too many issues and most people hate how it obstructs gameplay.
Screenshot of PlayerListManager taking 2ms to update, and it updates every frame. A static player list should not take as much time to update as a physics simulation. In this case, the playerlist is disabled using game.StarterGui:SetCoreGuiEnabled("All", false), and there is only 1 player in the server
