How does server code modify game state on the server while still accepting additional server game calls

Question

Question first, then explanation second.

How can a webservice backend to a game modify and alter the server game state while the game simultaneously accepts webservice calls from other users of the game?

These are my assumptions of how browser-based games work. They may be full of misconceptions, and please correct me if I am wrong!

1. Turn-based games are intuitively games that would best be represented by a single instance of a game.
2. Turn-based browser games with a server backend would typically call a sort-of "webservice" on the server.
3. A webservice has to complete its entire operation and then return.

I'm getting confused during the conversion between the "entire operation" part of the webservice and the non-static "single instance" of the game backend itself. How can a webservice, with their static nature, modify and alter a game while the game simultaneously accepts webservice calls from other users of the game? The only way I can see this occurring with static method calls is that the webservice saves and loads the game for each call, which seems horrifically wasteful on resources.

For example, consider a 3-player connect-four board, where only one player can play at once but users can change their color at will. The user should be able to change their color while waiting for the other players to play.

The question I have here is both conceptual and implementation-oriented, although it's mainly the conceptual that I'm curious about.

Answer 1

Every "message" that is sent to the server should have an ID. Your server constantly accepts those messages from every connected client.

Let's take your example with the 3 players. They are all connected to the server and are registered there as player 1, 2 and 3. Now, at this moment it might be player 2's turn but he's still thinking about his move and player 1 wants to change his color. This can be done very simply.

The server, as mentioned before, constantly accepts messages and loops over all available ID's that those messages might have. Player 1 who wants to change his color will send a packet with ID CHANGE_COLOR for example which holds a struct with the name of the player (player 1) and the color he wants to be. The server will receive this message and check the ID it has. It will then run through the code associated with this ID.

This does not interrupt the fact that player 2 is now doing his move (which might be the following packet the server receives). This packet could have the ID PLAYER_MOVE. This packet could hold a struct with, again, the name of the player and his movement. The server will check if the player that sent this packet is able to make this move (check if it's his turn) and then run through the code associated with this ID. If player 1 would try this the server could simply reject his move and reset it to the previous state.

I hope this is what you wanted to know. If you want code, take a look at the basic tutorial for RakNet. This library uses the system I explained.

Answer 2

When players start a game a new instance is spun up on the server and given an ID.

when players make a change, their command is created with their game ID and sent to the web service.

The web service there merely acts as a router that uses the game ID to send the command onward to the proper instance, which holds it in a message queue until it can retrieve them.

In this way one client can play multiple, simultaneous games because each they start has its own ID. Similarly, each web service is handling multiple, simultaneous instances. Also, multiple players can interact independently in one game because messages are queued up at the game's instance and not at the web service interface.

Given all of this, no commands really happen simultaneously, the instance receiving the command from the web service simply retrieves them one at a time from its incoming queue.

Answer 3

I disagree with the direction a few of the other answers went in. They all seem under the assumption that your game server must be its own distinct process with its own protocol. This is mostly true for real-time games, but a truly turn-based game can quite easily be a Web service built the usual way you'd build any other large, scalable Web application.

Turn-based games are intuitively games that would best be represented by a single instance of a game.

As above, not necessarily. Depends on what you mean by "instance of a game," but if you mean individual process, then definitely no.

Turn-based browser games with a server backend would typically call a sort-of "webservice" on the server.

The should, without the quotes. Some turn-based games have particular needs that do require their own game server processes and protocols; certainly not your example game, though.

A webservice has to complete its entire operation and then return.

Yes, but that operation could well be "enqueue an action that is executed shortly by another server." The trick is that you in some fashion need to tell the players when things happen and when their turn starts. This could be done with Websockets, server-side events, or the traditional polling (long polls or frequent short ones; long polls are better for bandwidth).

This answers your direct questions, but I feel you would be better served if you posted a new question with more specific details about your game.