I am building a simple turn-based game in node.js using sockets.io. My web experience with node.js has typically involved saving everything to a relational database. I set this up for my game. I am using sqlite3 for development and I might use something like PostgreSQL or MySQL for production. I will be doing this for account information regardless of what I set up for handling the actual game.

My concern is that, every time an event is emitted from the socket the whole game-state is loaded into memory from the server. I feel that in practice this will be less efficient than just keeping all of the gamestate data in memory. Events will probably be emitted every 5 seconds or so. A gamestate consists of a set of about 120 groups of small strings and integers (about 10 per group but subject to change).

Is it good practice to keep this type of data in memory?

Should I stick with relational databases?

Should I switch to a third option like a file-based storage structure?

Should I not load the whole gamestate in for every event even though that will lead to a lot more read/writes (at least triple)?

Edit* Clarification: Even though the game is turn based I want the player to be able to see what the opponent is doing on their turn in real time and give the player real time feedback about illegal actions.

  • \$\begingroup\$ Have a look at LokiJS, an in-memory, document-oriented datastore. It includes instructions for syncing to a backend service of some sort. lokijs.org \$\endgroup\$ – datashaman Jul 16 '17 at 10:44
  • \$\begingroup\$ PouchDB is also an option: pouchdb.com \$\endgroup\$ – datashaman Jul 16 '17 at 10:44

The exact answer depend on your exact use case so I'll try to stay general.

Basicaly, memory is cheap and fast. If you can afford to keep X games states in memory at once, then go away with that. The only thing you have to take care of is to store only one version of each game so that the state stay in sync between players. Also don't forget to store that state somewhere else where you can load it (in case of a crash)

Database are made for consistency and performance. They arn't as cheap and as fast as diret memory access, but their job is to store data across mltiple clients and they are better at that than anything you can come up with. If you need to make sure the game state as to stay 100% consistent no matter what, even in case of a crash, even with multiple node instance, then go with a database.

The best approach for performance is an hybrid of the two: use memory for rapid access, save to database on each change, and load from database when there is nothing in memory. It adds a lot of complexity I don't really recommend it neither (like: when to load games? how to resolve conflics when two players commands are executed at the same time? when to clear old party data).

I think the best way for you is to go with the safest and fastest route: use a database handle all that complexity and focus on making your game playable and fun.

As a side note, maybe give a try to a noSQL database. They can be faster than relationnal database. And you can store your gameplay objects (or concepts) directly as documents.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.