socket io When to use a database in a game

[mla]

Hi, 

I'm creating a node js game, using javascript and socket io.

I originally was not going to add a mongo DB, but now I'm thinking I should for anyone who may accidentally be disconnected from the game. 

What would the best game option be? To use a database or not, and the reasons behind it. 

Many thanks,

MLA

[chriswa]

Is your game turn-based or realtime? How much data will you be storing and how frequently will it change? What is acceptable behavior if your server crashes unexpectedly? How many simultaneous players do you want to support? How many non-simultaneous players?

A very simple solution could be to write a JSON file to disk ("saves/userid.dat") with their current state when a player disconnects. When they connect, look for a JSON file with their user id and load their state.

If you wanted to save every player's current position 30 times a second (in case the server crashes,) quickly search for any players near a position, or support robust trading between players, this simple file-based approach isn't going to work.

Databases basically improve read speed and write safety, but they have tradeoffs, including making your project more complex. I think it's important to determine what your requirements are.

P.S. Mongo doesn't support ACID transactions (except within a single document,) so it can't safely support trading, at least not perfectly.

[mla]

The minimum is 6 simultaneous players to a maximum of 12 simultaneous players.  

The game is pretty simple, and briefly explained below. 

• Host logs in and received a gameID
• Between 6 - 12 players access the game using the gameID 
• Each player is represented by a static non-moving image.
• When host starts the game, each player has 4 colored balls and a card showing the sequence of colored balls to complete.
• Each player passes balls around until the player completes their card showing the colored sequence of balls.
• This means that each player has 4 colored balls that are being tracked, and between 1-4 of each ball that matches their card. (When they get a ball matching their card, they will add it on the actual card. 
• So I am saving, for each player (min 6, max 12), 4 balls / player, plus the 4 balls appearing on each of their cards. Totaling 8 balls / player.
• Game ends when each player completes their card or time runs out.

What I am storing is the player id, name, 4 balls on hand, 4 balls on card, player status, x coordinate, y coordinate and static image. (The x and y, are where each player should appear on screen. They cannot appear randomly on the screen.) The only movement happening in this game is the balls being passed simultaneously around. (Player 1 can pass ball to player 2, while player 3 passes to player 4 at the same time, etc.)

My worry is not if the server crashes, but if one player loses internet connect during the game, example power outage at his home, then he will be booted out of the game. My aim is to allow that player to be able to come back, provided game is still in play, and continue from where he left off. 

[mattstyles]

4 hours ago, mla said:

My worry is not if the server crashes, but if one player loses internet connect during the game, example power outage at his home, then he will be booted out of the game. My aim is to allow that player to be able to come back, provided game is still in play, and continue from where he left off. 

I'm not really saying you do or do not need a database for this type of game, but, if that is all you're worried about then your game (and all of its state) will exist in memory on the server, so long as you can match up a player rejoining (i.e. ensure somehow that the joining player IS the one who just left) you can set their state appropriately, you don't need disk access for that (indeed, the fastest databases are in-memory, most will try to keep as much in memory as possible).

[chriswa]

I think the simplest solution would be to send the player their player id when they're first added to a game. Store it persistently client-side (for example in localStorage,) along with the game id. When connecting, the player should send their last known game id and player id from localStorage (if they have one.) On the server, check for a matching game id with a matching, disconnected player id. If you find one, reconnect the player, sending them a snapshot of the game state so they can keep playing. Otherwise, ask the player for a game id as normal, ultimately connecting them as a new player, with a new player id.

If your game ids and player ids are likely to conflict (e.g. always 0 and 0 for the first player of the only game on the server,) you may need to worry about players mistakenly hijacking disconnected spots when they are intending to enter a different game. You could make this issue statistically impossible by generating random ids.

P.S. I don't think you need a database for this game, unless you want to survive server crashes, or start tracking win/loss statistics for your players.

[mla]

Thank you chriswa!

After your first reply and then hearing from mattstyles, I decided to go forward with localStorage and not with the database. Since I'm utilizing local storage currently, I am re-coding the game entry part to recall the player id if it exists and show their last known information if the game is still in play.

Since I already am using random ids, there is no worry about conflicting player logins or hijacking spots.

I have a better understanding now of when to use a DB.

Thanks All!!