Ok, I am not sure what the exact term for them are, I am naming it singleton server based on this discussion
— Description of it —
Basically to sum it all up, its a server instance that is only allowed 1 per universe, and allows all servers in the universe to connect to it, and send data instantly to it. So for example, I have 5 lobbies and 10 game matches going, this could be used as a main controller for all the servers. to keep track of players, and players queuing for a certain match type.
Its basically a roblox server that runs where all the game servers can communicate directly with using TCP/UDP sockets. This will allow us to program our own matchmaking and such. If Roblox makes this, it can be controlled easier than allowing custom sockets.
So basically, Roblox controls what Ip and such it connects to, it’ll automatically connect to the correct server, giving users No control over the connection except for sending/receiving.
Works just like a regular game server, this could allow us to possibly visit it for admin control panels and such to shutdown certain instances in the universe, as VIP servers do not show under game instances (Unless shutdown all works)
The Singleton is a feature that must be purchased for each universe. I would say 1,000 Robux, 1 time purchase.
— Methods, events, and variables to be added —
Create a new service called GameServerController instead
// These are Only for the game server’s usage.
i boolean ServerController:ConnectToController()[/i]
Used for game servers to connect to the singleton or controller as we can also call it.
returns true on connected, false on failed.
i boolean ServerController:DisconnectFromController()[/i]
Simply to close the connection to save data bandwidth.
returns true if succeeded, false on failure.
i boolean ServerController.IsConnectedToController[/i]
Variable, True or false depending if its connected.
i boolean ServerController:SendDataAsync(Mixed Data)[/i]
This is the way the game servers will communicate with the singleton.
Limited to 64 KB a second, which should be plenty for sending usernames, and match data.
Waits for the data to be sent, and holds the thread.
// These are used in Both types of servers.
i Mixed ServerController.OnDataReceived[/i]
An event used to receive data from the singleton, limited to binding on 1 script only, just how game.OnClose does it.
i ServerController.ConnectionChanged [/i]
This is just an event that will be fired when the connection was started or ended.
// These are used for Only the Singleton/Controller server.
i ServerController.OnNewConnection [/i]
returns (GSConnection Connector, String GameInstanceId, Int PlaceId)
This is fired when a game instance connects to the singleton. The Connector variable will be an object that can be used to close the connection to the game server manually.
Object GSConnection (Short for Game-Server Connection)
This is used for the singleton only.
(Function) void GSConnection:CloseConnection(string Reason)
Closes the connection to the game server, sends
(Function) boolean GSConnection:SendDataAsync(Mixed Data)
Simply sends data to the game server, limited to 64KB a second.
returns true on success, false on failure.
(Event) GSConnection.OnDataReceived(Mixed Data)
The event that can be binded for receiving data
(Event) GSConnection.OnConnectionChanged(boolean isConnected)
— Limits —
- The singleton server will NOT connect to all the servers automatically, and the game servers must connect to it manually through a script.
- Each universe is allowed only 1 singleton
- Game servers have no ability to connect to other universes or game servers, only their own singleton in the universe.
- Each game server is limited to sending 64KB per second to the singleton. The most popular games are like lets say 12 player slots, up to 3k players, that’s equal to 250 connections which can be calculated to an estimate of 15.6 MB/s for the singleton at maximum data sent. But most likely we won’t reach this point.
- Connections will stay alive between singleton and game servers, but will automatically close after 5 minutes of no data sent or received, this can save bandwidth.
- Sending instances like Models are not allowed to be transmitted, only Strings, ints, booleans, and possibly Lua tables.
- Players can Not enter the singleton server, except for the owner(s).
- These servers will disable physics and object creation completely (Parts, unions, terrain, etc)
Bandwidth limits can be discussed if it’s implemented. But I personally don’t see any need for more than 64KB/second. Since the whole idea is mainly for matchmaking.
Pros / Cons
Pros
- // Proper // match making would finally be possible!
- Allow for other types of communication like a global chat, as DataStores are slow for OnUpdate.
- The singleton could be used to give commands to the game servers, like show that tournaments are available or something (Even though datastore.OnUpdate can sort of do that.)
- ability to create large scale games without the use of spamming http requests.
Cons
- Nothing I can think of with the data limits.
Thanks to VitalWinter for the initial idea of the singleton server.
I think that I covered everything needed
Sorry if the formatting/organization of the post is messy, I am not used to formatting without different font sizes.
Thanks for reading, discussing, and possibly thinking of implementing this, it can be a solution to matchmaking.
