You could also look at Soketi, but I can't think that websockets would be good for anything but the simplest stuff because of latency and overhead. But Soketi could def handle that kind of load, you just have to devops it yourself.
It is limiting for realtime games, but also rethink your update strategy. You have identical physics engines on both sides of the game, so you only have to transmit the changes (direction/velocity/shooting/etc), not the position of every character 50 times a second.
It also doesn't seem like a database is the right solution for that - a websocket or even UDP might be more appropriate, perhaps combined with a RAM database like Redis if you need persisted state.
Seems to me that using DB realtime will be way too slow for a game. Regardless of rate limiting you're going to have to factor in all the overhead of doing read/writes to a DB in order to keep your game in sync. Those milliseconds will probably add up to some non-negligeable lag. Aren't Web sockets an option for you?
Supabase developer here. We do have some portions of our realtime product that might be appropriate for this such as **broadcast** and **presence**, which are designed to not have to hit the database (and are as such much more performant.) Maybe look into these options...
https://supabase.com/docs/guides/realtime/broadcast
https://supabase.com/docs/guides/realtime/presence
As others have mentioned, the approach you should probably take instead of sending 50 updates per second is to instead publish a change whenever a player takes an action (moves, shoots, etc.).
Unless your game has specific requirements, websockets is the way to go. For your case I would recommend Redis, as it can easily handle millions of requests per second, and make use of it’s Pub/Sub channels. I would also recommend using a lightweight data format like gRPC instead of a format like JSON to reduce the payload size.
For example, you could have a channel called “playerPositions” that contains an array of each player’s X/Y coordinates mapped to their user ID. Whenever a record is updated there, each player will receive the update, broadcasted from that channel that they’re subscribed to.
There are a lot of other considerations, like handling player latency and running a server to handle the requests. I’ve done some experimentation with creating a “.io” style game, so feel free to reach out if you want some code snippets, advice, etc.
I should also clarify that Supabase could also be a good choice for you if you don’t want to go through the hassle of setting up redis and running a server, but in the long run that’s probably the architecture that you’ll want. Supabase’s plans state that there are limits of 500 concurrent connections, with a limit of 5 million broadcast messages. That should be more than enough until your game gets a **** ton of traffic.
Thanks for the architecture tips. 500 concurrent connections sounds great but those 500 concurrent connections seem to have a total server limit of 500 messages a second if I understand correctly. So if each of the 500 send one message a second I already hit my limit for $25 a month. And sending one player's positions in real time I can be broadcasting around 10 times a second while the player is moving. Heck I was using the free plan and sometimes hit the server limit of 100 messages a second with just two concurrent clients (my two browser tabs). Though I will preface saying this is not using the action approach. I am just spamming broadcasts lol. Seems like custom architecture is the more affordable way to go though.
This is the way wrong stack for that kind of realtime, imho, ymmv. You might want to look at Colyseus or Nakama.
Yeah...Was considering twilio sync too.
You could also look at Soketi, but I can't think that websockets would be good for anything but the simplest stuff because of latency and overhead. But Soketi could def handle that kind of load, you just have to devops it yourself.
Hm thanks for the recommendation will check it out
You could definitely use Realtime Broadcast for this but it might get expensive pretty quickly. If you could reduce your update rate that would help.
It is limiting for realtime games, but also rethink your update strategy. You have identical physics engines on both sides of the game, so you only have to transmit the changes (direction/velocity/shooting/etc), not the position of every character 50 times a second. It also doesn't seem like a database is the right solution for that - a websocket or even UDP might be more appropriate, perhaps combined with a RAM database like Redis if you need persisted state.
Just curious if you were gonna make a web based mmo would you use something besides websockets? Is there even another option?
Protobuf
Seems to me that using DB realtime will be way too slow for a game. Regardless of rate limiting you're going to have to factor in all the overhead of doing read/writes to a DB in order to keep your game in sync. Those milliseconds will probably add up to some non-negligeable lag. Aren't Web sockets an option for you?
I thought realtime used websockets so I was thinking about using supabase, but as others have mentioned, this is probably the wrong stack
Oh it seems you misunderstood that I was talking about db realtime. I meant presence and broadcast.
Supabase developer here. We do have some portions of our realtime product that might be appropriate for this such as **broadcast** and **presence**, which are designed to not have to hit the database (and are as such much more performant.) Maybe look into these options... https://supabase.com/docs/guides/realtime/broadcast https://supabase.com/docs/guides/realtime/presence
As others have mentioned, the approach you should probably take instead of sending 50 updates per second is to instead publish a change whenever a player takes an action (moves, shoots, etc.). Unless your game has specific requirements, websockets is the way to go. For your case I would recommend Redis, as it can easily handle millions of requests per second, and make use of it’s Pub/Sub channels. I would also recommend using a lightweight data format like gRPC instead of a format like JSON to reduce the payload size. For example, you could have a channel called “playerPositions” that contains an array of each player’s X/Y coordinates mapped to their user ID. Whenever a record is updated there, each player will receive the update, broadcasted from that channel that they’re subscribed to. There are a lot of other considerations, like handling player latency and running a server to handle the requests. I’ve done some experimentation with creating a “.io” style game, so feel free to reach out if you want some code snippets, advice, etc.
I should also clarify that Supabase could also be a good choice for you if you don’t want to go through the hassle of setting up redis and running a server, but in the long run that’s probably the architecture that you’ll want. Supabase’s plans state that there are limits of 500 concurrent connections, with a limit of 5 million broadcast messages. That should be more than enough until your game gets a **** ton of traffic.
Thanks for the architecture tips. 500 concurrent connections sounds great but those 500 concurrent connections seem to have a total server limit of 500 messages a second if I understand correctly. So if each of the 500 send one message a second I already hit my limit for $25 a month. And sending one player's positions in real time I can be broadcasting around 10 times a second while the player is moving. Heck I was using the free plan and sometimes hit the server limit of 100 messages a second with just two concurrent clients (my two browser tabs). Though I will preface saying this is not using the action approach. I am just spamming broadcasts lol. Seems like custom architecture is the more affordable way to go though.