What is an affordable way to communicate real-time data between players in a game?

Question

I have been building a card game web app with firebase. Because firestore charges by number of reads/writes, I have only been updating the opponents of your plays when you place a card, so other players just see a card you moved pop into its new position -- one write, one read.

I momentarily tested updating the other players whenever you are moving a card, such that they can see you moving cards around in real time, not only the final result when you place it in a new location. This results in hundreds of writes/reads per second as the onMouseMove event fires continuously.

This is too expensive to leave, so I undid it. But I'm disappointed and I feel there must be a better way, but I am too new to this to know what it is.

How can I affordably transmit very large amounts of update events between players?

To give an idea: assume 1000 games per day, each could invoke 500k to 1million move events (each card drag fires off hundreds, and there are up to 6 players!), so I would be transmitting a billion or more small pieces of information per day. The numbers sound large but this is just for a moderately successful small web game and pretty realistic. A lot of webgames handle this kind of traffic daily no problem.

How is it done affordably?

Answer 1

It sounds like you have a fundamental architectural problem here.

You describe using a database to communicate between different players' sessions. In a comment, you say that everything must be stored in a database because it's the only way to persist the game state if the user closes the tab and opens a new one. It sounds like you are using a framework which forces all sessions to be isolated from each other.

This isolation is not what you want for a game server! For a game server, you want to be able to just send things, when they happen. You want to be able to write this (pardon the lack of OOP):

void onCardMoved(Connection playerConnection, int playerIndex, int cardIndex, int x, int y) {
    for(Connection otherConnection : c.game.connections) {
        // Don't send the message back to the same page that initiated the action.
        // Note that a player could have more than one connection (several tabs open).
        if(otherConnection != playerConnection)
            otherConnection.send(new CardMovedMessage(playerIndex, cardIndex, x, y));
    }
}

You simply cannot write this type of code in this type of framework, no matter how much you want to, because there is no way for an event processed on one connection to directly affect the other active connections.

I'm not familiar with Firebase. It looks like an auto-scaling system where your app runs on multiple servers. Therefore, I assume there's no way to directly access other players' connections, because they might be connected to different servers. Consider using a traditional architecture where you have one server and everyone connects to it, and then store all the game state in memory (no database!). If your game gets so popular that you need more than one server, you can still do that, if you make sure that people who are playing together connect to the same server as each other.

If a player quits and reconnects, you can even connect them to the same game state, as long as it's in memory. You only need a game state database if you want to be able to restart the server while people are playing. (You might still need a database for other things, like user accounts)

Answer 2

This is done affordably by not using Firestore as the network layer for your game. A database is not really suited for the real-time movement of objects in a game.