As a web developer I'm used to a straightforward flow where all interactions typically correspond to a database read/write and the life-cycle corresponds with a single request.

As a learning exercise I wanted to write a basic multiplayer card game and realized I have a lot of confusion about where to best store active game state.

While I know a card game could easily read/write to a database per action, I was wondering if it is as simple as (in my case, a javascript node server):

  1. Create a global state object
  2. Create an active game object
  3. Push it to an array in the global state
  4. Perform actions on this active game in memory, broadcast new state to frontend via websockets
  5. When the active game is complete, write the results to a database for persistent storage
  6. Remove the active game from the state, thus freeing memory?

My questions:

  1. Is this a reasonable solution or is it a bad practice? (global variables, memory management, state loss on process crash/restart etc...)
  2. Would it make more sense to set up a redis server for handling temporary state?

This is quite different from a frontend perspective where redux/vuex makes handling state a straightforward task, and from what I've read, it is desirable for the backend to be 'stateless' - it just seems weird to me to read/write to a database for things that don't require long-term persistence.

Edit: I also know firebase could be a very suitable solution, I just prefer to avoid vendor lock-in if possible.

  • \$\begingroup\$ Coming to this question late, but it sounds to me like you understand the trade-offs you're making with this choice. You can store the state in memory at the risk of loss of progress if the server resets during a game (and all clients in a match must use the same server), or you can log progress to a more persistent store for higher reliability (and scalability) at the cost of increased complexity. Whether that trade-off is worthwhile for the kind of game you're making is a question that you're better-positioned to answer, since you know your game and your intentions for it better than we do. \$\endgroup\$
    – DMGregory
    Aug 23 at 10:46

Strongly suggest you write the game prototype purely on the front end to start with.

This will give you a far better handle on how such a game should be structured, without worrying initially about Node's way of doing things. Then you can switch over the mocked parts to Node later, using whichever Node paradigms you feel best match what's already been implemented in your mock-server. Front-end logic obviously just remains where it is, on the client.

You can mock async calls to your mock-server using setTimeout to pretend a typical response delay of say 50ms. Make sure you do this right from the start, for every such call.

For that purpose, suggest separating your front end classes into /client, /server-mock, and /common (which ultimately will be available on both client and server).

Again: First focus on learning architecture for such a game, THEN worry about migrating to Node. It will be faster this way, and if you maintain good separation of concerns, it will be easier to factor out the server as a Node application, later.


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.