Do you want to make an online multiplayer game, but don't want to struggle with making a server? Firebase might be your solution!
4 min read
·
By Ole Kildehaug Furseth
·
December 6, 2022
Whether you are making a game of your own design, or just want to implement your own version of chess, taking the step from two players sitting in front of the same computer to playing online might seem daunting. You need a server for that, right? And you’d really prefer it if you could just write game logic and make everything look pretty in React. Well, Firebase has got you covered – at least to an extent.
Firebase is perhaps most known for being a place where you can quickly and easily deploy your first React app without having to spend any money. While ease of deployment certainly helps, the real value for your online game lies in Firebase’s Cloud Firestore.
Cloud Firestore is a NoSQL cloud database that offers data synchronization through real-time listeners, meaning any connected device can instantly receive all changes made to the database. To make your game fully online, all you have to do is write your game state to Cloud Firestore, make your clients listen to changes in said game state, and you’re golden!
Setting up the database and connecting your React/Java/Go/Ruby/Flutter/Unity/…-application to it is very straightforward. Really – read the docs – you’ll be writing to your brand new Firestore in half an hour.
Your Firestore consists of collections, which contain documents, which again contain the data you will be reading and writing. Firestore having a NoSQL data model means you can write data exactly how you want: Documents go in – containing everything from simple strings to complex nested objects – and documents come out. Very handy when your game state attempts to get out of hand.
Using a chess game as an example, making a move might look something like this:
const gameRef = doc(db, 'gamesCollection', 'gameState1');
setDoc(gameRef, { C4: "White King", C3: null }, {merge: true});
The first line specifies the document called gameState1 in the gamesCollection-collection as the one we want to be writing to.
Writing the second line to the database would indicate the white king piece moves to square C4, leaving square C3. Realistically, the gameState1 document contains fields for every square on the board, in addition to tracking things like who is the active player. The merge at the end of line 2 ensures only the C3 and C4 fields are updated, all others remain unchanged.
Setting up a listener to receive changes in real-time is just as simple
cons unsubscribe = onSnapshot(doc(db,'gamesCollection', 'gameState1'), (doc) => {console.log("Game state: ", doc.data());
});
Of course, instead of simply outputting the data to the console, you are now free to do whatever you want with – perhaps update your frontend to show the white king piece on square C4.
And that’s all there is to it. Write your game state to Cloud Firestore and set up listeners to receive changes and update your frontend immediately after your opponent makes a move.
So, just slap a Firestore on it and you’re good? Well, depending on the type of game you are making, not necessarily.
Firestore lends itself well to a certain genre, namely board games or slow-paced strategy games with a relatively low frequency of discrete actions and a relatively low number of moving pieces. While Firestore largely provides updates in real-time, it is still a database, and having two or more players competing for several writes a second can certainly lead to a responsiveness players might find lacking.
A high number of moving pieces isn’t a problem in and of itself – though your wallet might disagree. Firebase’s pricing model is based on the number of reads and writes made, so think twice before you deploy Chess 2: Sparta with 300 pawns! Still, if money isn’t an issue it should theoretically be possible to implement something as complex as the Civilization games.
If, however, you are looking to implement a new fast-paced shooter, I’m afraid Firestore will not be able to help as much. While tracking continuous 3D movement and ballistics in a database certainly is an interesting challenge, I believe that is a task best left as an exercise to the reader.