Architecture and first decissions

After the first step, we focus on how the client and players will interact.

If we want to get  a real online multiplayer and smooth game we have to respond smoothly to users demands. This means that if the client moves in some direction it should be reflected on the screen asap. You might think that this last premise conflicts with a client/server architecture. Not Actually. We are going to use player predictions to solve this issue. Let me explain myself. We are going to follow this guidelines:

•     Every remote player will move his own snake by his own. The objective is that the player can perceive the movements in real time on the screen.

•     Every remote player will send his movement at the end of his tick to the server. So, once every remote player have sent their moves, the server will send back to the clients the consolidated  movements.

•     Once the remote player gets the consolidated movements, he will move the other snakes.

The consequences of this guideline is that players will see a smooth game where the snake itself moves as if we were playing in a standalone game. The rest of the snakes will move with a certain gap after the own snake has moved. 

OK, it seems that it works but there’s always some issues that affects predictions...

What happens if, for any network reasons, a remote movement from player never reaches the server or it arrives once the server tick is ended? Yeah, this is a big problem since the server is going to send a different movement from one of the players that has already moved in a local way. To avoid this issue we must implement a local correction engine. This means that remote clients have to detect if the movement, already made, conflicts with the one sent back by the server.

At this point, we are going to take another critical decision. We decide that our server will be a mandatory server. What the server has in mind is what the world real is. So predictions will be the way it sounds: just predictions. If the remote client detects a conflict between last local movement and consolidated server movements, the client has to move back to the last local movement  and move again based on the server orders. As a consequence, every remote player will see the same game, that is what it is supposed to be. How this affect this game? Of course, it has consequences: the remote client will see, eventually,  that his snake will change his position once moved.

We will have to minimize this last effect from our game. Let’s Write down who will be our worst Enemy: Latency. In the following entries we will learn how to struggle this formidable opponent with some tricky strategies.