-
Notifications
You must be signed in to change notification settings - Fork 1
1) Basic Internet Theory
This page will serve as a basic introduction to the world of game networking. If you already know all of these topics, feel free to skip it.
Multiplayer games come in two main formats: Peer to Peer and Client+Server.
In a Peer to Peer system, players are keeping track of all information of the game at all times. For this to be possible, a lot of work needs to be done synchronizing the game state between players. For instance, it a player presses the A button, this data is sent over the wire and the game will not detect this input until all other players receive this information and agree that the button was pressed (otherwise, the two games would go out of sync). This isn't very ideal for most multiplayer games because it means that the player with the slowest connection holds everyone back, but at least everyone is able to agree on what state the game world is in at all times. Another problem is that it can be difficult to prevent cheating: Since all players need to be completely synchronized, that means that players will require access to information they should probably not have.
So games tend to opt for the Client+Server model. Instead, we have a central server that is running the game, and clients (players) all connect to this one server. This server is the arbiter who decides what is right and wrong, and is able to decide what information clients are privy to. Clients run their own version of the game, and periodically tell the server what is going on in their game. The server will then validate this information and send it to everyone else if necessary.
To communicate over the internet, there are two main networking protocols: TCP (Transmission Control Protocol) and UDP (User Datagram Protocol).
Without getting into the specifics of the implementations, TCP offers reliability, while UDP doesn't. Packets sent over the internet might arrive to their destination out of order, or might not arrive at all, so TCP will buffer packets to ensure everything arrives exactly as it was intended. Unfortunately, this makes TCP unsuitable for real-time games (not turn-based games), as speed is traded off for reliability. In a realtime game, packet reliability is not as important: for example if the game is constantly telling you the current position of a player, it doesn't really matter if you receive an old packet or don't receive anything at all for a few milliseconds because you are going to receive a more up-to-date player position packet in the very-near future.
In the example regarding player positions, you would be right to think "wait, doesn't that mean that if a player stops receiving position update packets, and then receives some after a second, that to them it will look like everyone is teleporting from place to place?".
Correct, and so games solve this by trying to guess where everything is going to be in the future, and correcting it later if necessary (because 90% of the time, it'll be correct). It would feel weird if you pressed the jump button but your character only jumps after receiving confirmation from the server (which could be significantly delayed). So instead, clientside, your character will perform a jump even though it hasn't received confirmation from the server. In the cases where it is wrong, the server will tell you so and your character will go back to where they were before attempting the jump.
Usually, a game server will be running at a fixed time step, (for instance, 30 ticks per second), and information will be relayed to all clients at this speed. But a game will usually be running at a framerate higher than the tickrate of the server, and so everything shown on a client's screen is a tick behind reality, as doing so lets you interpolate smoothly the positions of objects between ticks. This might sound bad, but every game engine which allows for you to have whatever framerate you want already works like this and you probably never noticed.
Finally, one other problem you might have is that a client will shoot an object on their screen, but this data takes time to arrive to the server, which means that the positions of what was shot might no longer be where the client saw it. Games solve this by having the server actually keep a record of the position of objects for a second or two, and then rolling back the simulation with the timestamp of the packet to check if it agrees with the client. The game server can't just trust the client blindly, because the client could be cheating.
If you want a more comprehensive understanding of what goes into internet connectivity in games, I would recommend the following articles:
- Gabriel Gambetta's Fast-Paced Multiplayer series - A series of articles that covers what goes into implementing a real-time multiplayer game. It provides lots of visuals and sample source code.
- Source Multiplayer Networking - This article covers how networking works in the Source Engine, and also delves into the topics of interpolation, prediction, and lag compensation. The source engine is also source-available, so you can read their implementation.
- I Shot You First: Networking the Gameplay of Halo: Reach - A comprehensive overview of the sort of challenges a developer might face in real-time game networking when two clients don't agree on the outcome of an action.