Simply: a service that facilitates sending messages between running servers in the same Game.
Why?
DataStores are meant to store data long-term, not for short, instantaneous messages. DataStores have request limits.
HTTPService requires programming one’s own service outside of ROBLOX, and makes games on ROBLOX reliant on external services.
Use cases:
Cross-server chat: game-wide, or just between friends.
Cross-server marketplaces, facilitating trade between any two players regardless of what server they are in
Social aspects to single-player games
Server browser without datastores
Smarter matchmaking by allowing servers to view others’ players, maps, and uptime without having to sync datastore keys to deal with datastore request limits.
I know there will be some people who will refuse to trust 3rd party services, but what if we made a reliable external service? I understand you wish to avoid HttpService … However, there are a lot of awesome things you can do with such.
No. You can’t make a reliable external service because there’s no guarantee it’ll be there the next day and it’s highly unlikely you’ll be able to handle the load of multiple popular games at once for free. I wouldn’t want to rely on your 3rd party service if it meant my game would suffer whenever the service may become overloaded by multiple games in the future. I wouldn’t want to pay you for an external service because it’d be more reliable to purchase my own service and have full control over whether it lives or dies.
A solution, which was denied (I think they thought I was suggesting server-implementation of web-sockets), is websockets. You could setup a simple nodejs script that repeats all messages and sends them to all the game servers, practically having a cross-server communication, where the node script would be the middle man.
I know this is off topic, but I recall someone implementing websocketa simply using RBXLua. I can’t remember who, or how. But I’d like to ask them if they would mind sharing.
I know who you’re talking about, just forget his name. But it was Not a web-socket, it was a loop that sent a HTTP request, then the server held it until it had something to return, then the http request would send again once it was returned, it does work, just inefficient.
What you are referring to is called long-polling. It’s not a very good solution at all, in my opinion at least (and yes I’ve implemented and used it before).
Trading, social aspects to singleplayer games, server browsing, and matchmaking are all pretty common features in non-Roblox games. I would call them more than just “cool” and consider them legitimate use cases, especially considering how common they are.
My actual original use case – for which I developed my own HttpService-based Cross-server Communication Service – was for a large open would game where servers are connected at the edges. Players could talk between nearby servers and you could see updates to players and blocks in nearby servers.
I never tested this game with more than 2 players and last I checked it had some errors preventing it from running.
I can think of some more:
Setting up parties to raid a dungeon across multiple servers. This could be from a singleplayer server or a server with many players in it. Letting players party up across servers will let players enjoy older dungeons a ton easier, as it may be hard to find party members in your current server.
Notifications/auto-join for when you can join a server that is waiting for players with long-running games. Think games like Risky Strats or other RTS where the rounds can last for many minutes and you can only spectate or hop servers. Having to wait for players to finish is boring and can drop the player count. Cross-server friend or party chat is also great here.
A synced, shared music playlist that players can suggest entries to, possibly for a price.
