What’s the deal with this server side and client side stuff?

I was looking at our previous posts and I noticed that Scott had written a bit of an overview of what the server does, but I never made any attempts to make any explanations about the client, I guess that somehow I tend to think that everybody knows, but some times is better to talk about what you think everybody knows. The client, is, after all, the most visible part of the game.

If you write a single player game, normally you can get away with having everything in a single place (the executing machine). The natural question when you have an online multiplayer game is, What can you have in your client and what must be on the server?

Let’s imagine a simple game which can be played online, “Air Hockey”, and of course, keeping it simple, just two players. Each client could have a map (the table), the assets (the paddles and puck graphics), the sound effects and music. Since each player is using a different computer to render the table, paddles, puck etc,  we could quickly come up with two versions of the world, the one you see and the one your opponent sees, and that can greatly affect game-play. If you try to block the puck but it is not where you thought it should be, then you could unfairly loose a point.

Right away we understand why we need a system to make our worlds as similar as possible. So both clients must communicate with the server, and tell it where the paddle is, what is its speed, and perhaps some other information, the server in this case will communicate to both clients where the puck is, what is its speed and direction, where is your opponent’s paddle, and how it is moving, state that tells you if the puck collided and what it collided with, etc.

Now, in order to render things as synchronized as possible both clients must communicate with the server as frequently as possible, because the server is the source of truth, but at the same time there may be limitations that can cause you to not  be able to receive/transmit in each frame, however the game must maintain its fluidity, so your client must be able to decide what to do when it does not receive information from the server, and then communicate to the sever what happened so it can re-sync stuff.

What happens if you get disconnected? the client should be able to determine if it lost it’s connection with the server, and have some way to get you out of the game in a way that won’t make your game crash. You might get substituted by a bot, so the other player can finish, but that is up to the server.

Now let’s complicate things a bit, imagine that somebody invented a extreme version of air hockey combined with pinball “Pinbockey!”, there might be obstacles that react to the puck when they get hit, furthermore, imagine that the placement of these things can be customized, and some players create special tables.

When this happens we will have another complication, you won’t have all possible maps in your game, the server must transmit those maps before the match starts, and your game should be able to read that information and render the map as envisioned by the level designer in reasonable time. Asides from just rendering the table, it must be able to understand what events could happen, and how do those events look and sound, all of that  “protocol” should be established and the client must understand how the server will communicate the state to it, so it can render things correctly, play the appropriate sounds, etc. The main job of the client’s program is to display the world as consistently as it can to all the players, so all of them are playing the same game, and at the same time respect the physics and rules of the game in between the moments when it gets updates.

So far we have talked about a game with two players, but MMOs by definition have many players, and they could be doing things like jumping, running, engaging in conversation, interacting with the world, etc. Some of those things should be visible, and/or audible to you, each running client should create a representation of that reality which immerses each player in a single cohesive world.

Spycursion is a game with some particularities, you can hack, which means you will have devices that will connect to other devices, and that means that you will have GUIs that should react to devices, some nearby and some remote, which may at the same time be visible to other players,the client in many cases will just be a dumb terminal, or GUI and all of the things happening in this interface actually are communicated to and from the server. All of that must happen while keeping the physical world around you going, because Spycursion is also an espionage game, and people around you will be watching and hearing you and in some cases trying to gain access to your devices.

By this point you might be able to get some idea of what happens in the server and what happens in the client, the only thing I have not mentioned is that any program that is capable of showing a representation of the world that is understandable by the player could be a client for that game, so potentially several clients could be developed for a single game, and the visual appeal and performance of the client has a great deal of influence on the success of it.

I hope this was interesting to you, I tried to keep it non technical so all interested parties can get something from this post, we might revisit some of these ideas in future posts.

I hope you have fun and learn something everyday,  and keep an eye on this project, which will give you an opportunity to do both,