Throughout the past few months to a year several opensource Discord Webhook modules have surfaced paving the way for things such as faster debugging, data collection, and much more.
It raises the question, seeing-as I am relatively inexperienced with coding outside of Lua, what steps would I take in order to send payloads from Discord to ROBLOX?
Proposed Idea:
Lets use the typical ROBLOX command format as a rough framework for how this system would work: you type a command in Discord, a bot picks up on the message and it broadcasts throughout the entirety of your game servers.
Proposed Commands (a basic list):
!notify (message)
!shutdown
!ban (player/userid)
Obviously these can all be accomplished using the same replication method but just for the sake of having a solid list to build off of, I have included it.
Question:
Is it possible at all? If it is possible, what could I do in order to create one such replication method to send payloads from Discord → Roblox?
Third party resources cannot send any payloads directly to Roblox so you’ll probably have to do some kind of polling. There are a couple of resource threads about Discord-to-Roblox services and I also have one currently running in my group. I have access to the Lua-side of the bot, at least, which is my citation regarding this.
The group I mentioned earlier currently supports a Discord bot which can control various game states and actions: three examples are bans, remote shutdowns and event hosting. Every 10 seconds, we will send via HttpService a request to the endpoint where the bot is hosted and pull data accordingly, then update it for the server. Based on this data, we’ll trigger actions in our game, mostly via BindableEvents to enforce an event-driven system.
The general gist of it is… you can send requests from a Roblox game server to a third party API and receive a response back, but not vice versa. Polling will be required to do that.
I personally recommend to use long polling as it is a lot less wasteful as far as http request usage goes, and responds near instantly.
A basic understanding of long polling is to send a request to the server, but have the server wait to send a response until a timeout is reached (e.g 30 seconds) or when data can actually be sent (a command is sent, for example.)
I use this for many of my projects, and it works very effectively and is not hard to implement either.
The main advantage to using long polling over short polling because it uses less HTTP requests, and Roblox will receive the requests near real-time.
It uses more server resources (on the backend, not sure on Roblox’s side) so the more servers you have, the more concurrent connections you have. For example, 10k roblox servers would be 10,000 http connections to your server.
This shouldn’t be an issue for small-medium games, and shouldn’t be an issue if you have a decently high max player count.
Another small disadvantage (or advantage, in my eyes) is that the amount of http requests used will be equivalent to the amount of commands sent. For example, if you send 100 requests, that’ll use up 100 http requests on roblox due to the way long polling works.
This can be “mitigated” by simply adding a max amount of requests per minute however as long as you don’t send a large amount of commands a minute, you shouldn’t reach any limits anyways.
So, disregarding the high server connections, so long as there is not a consistent stream of payloads being sent (or if there is a limitation on the potential number of requests active at one time), it’s virtually a foolproof method?
Depending on what you mean by “foolproof”, yes. Long polling uses more requests the more often payloads get sent (but uses less if no payloads get sent), so this is probably the biggest disadvantage as far as long polling vs short polling goes.
Upon looking through it, it certainly is helpful though it is directly oriented with supporting banning/unbanning players only. I can certainly edit this and turn it into something I can use though, so thank you once again.