Making a Multiplayer FPS: Basic Movement

Introduction:

Welcome back to the second installment of my blog series. In this post, I’ll be discussing the implementation of basic player movement, a crucial aspect of every game. We will see the problems encountered as well as some possible solutions. Let’s dive in!

Implementing Basic Movement:

Basic player movement is now fully functional in the game. Players can move, jump, and look around. I first did it without the networking to test that everything works and then proceeded to implement the multiplayer part of it. It was quite straightforward, as you simply send the input data to the server, then the server moves the player in its instance and sends the new location to all the clients.

And why can’t we just move the player on the client and send the result to the server, wouldn’t that be faster and more responsive? You may be asking, well, even though it would be a lot faster and responsive, we would have massive problems with cheating, as any player could send the position they want their player to be at. In multiplayer games, we don't trust the clients at all, so we do all the calculations on the server.

One exception to the rule is the movement of the camera, as we don’t want to override the rotation of the player’s camera with information from the server. That would cause conflicts with the rotation that the client calculated while the server was still processing previous input. And jittering when simply moving your mouse around is something we really want to avoid. Unfortunately, that means that we’re trusting players to calculate their own rotation, making the server calculate it simply causes too many problems, and even if that’s the case, it wouldn’t be too difficult to make the client calculate what kind of mouse movement would rotate them to be aiming right at someone, and then sending that to the server.

This is a diagram that simplifies the architecture of a multiplayer game. In this case, there are multiple servers, each one in charge of a specific region, but they all do the same.

Testing and Tweaking the Movement:

To ensure that player movement feels just right, I created another test project to rapidly test new movement values without having to connect to a server or anything. By fine-tuning these movement settings in the test project, I can easily apply the optimized movement to the main project; this process is faster than having to have the server open each time you tweak a parameter to test it.

Jittering Movement Issue:

While the basic movement mechanics are in place, I’ve noticed a slight problem with the movement. And that is that the movement is jittery; this occurs because the server cannot send information every nanosecond, so it sends packets of information at a fixed number of times per second; this is known as ticks. In my case, the server runs at 32 ticks, so it sends information to clients 32 times per second; this is what makes the jittering problem.

To address this issue, there is a “simple” solution. In the future, I plan to implement interpolation, a technique that will smooth out movement by predicting a more fluid path between received positions. What basically does is that given 2 positions calculated by the server, the client will smoothly transition the player between those 2 positions.

This is a very simple example of how interpolation works:

It is important to know that the interpolation is only used by the clients, as seen in the image above, so the server will send the information as normal.