How network gaming works - Unity Tutorial

- [Instructor] Network Gaming is different from normal game development in one really big way. The main job of a game developer is to write code that maintains and manipulates the state of a game. The game state is the overall big picture. If you take every instantiated game object in your game at any discrete point in time, all these together form the game state. The most relatable representation of a game's state is thinking about a saved game. When you save any game, you're writing a representation of everything in the game that can be later restored, as if you'd never stopped playing. The process of writing out game data is called serialization. What's different about network gaming is the game state must be shared. The sharing part is referred to as network serialization. The same mechanism you'd use to save a game to a file can be used to share the game state between networked players. You can probably immediately see the first challenge. Let's say we have two players, Alice and Bob, who play our proposed tank combat game on their individual computers connected by a network. When Alice fires a weapon at Bob, Alice's computer instantiates a projectile, which using normal rigid body dynamics, can be moved forward in the hopes of destroying Bob. How does Bob's computer get the information? If we go back to the earliest network games, such as Age of Empires in 1997, the game's network was basically a Peer to Peer setup. In Peer to Peer networks, every computer is connected to every other computer in the game, and for every player move, the player's commands are simultaneously transmitted to all other player's computers. That covers how the data are transmitted, but not how the game state is handled. The original Peer to Peer systems use a client authoritative architecture. Each computer is in charge of the game state for its player, and updates are received from everyone else. In our example, Alice fires on her computer, which instantiates a projectile. Then her copy of the game, that is her client, sends a message to all other players' clients telling them she fired, where she was, what she aimed at, et cetera. Then each client would process that instruction, then process instructions from the local player. In essence, all the clients are synchronizing their understanding of the game state over time. This mode of operation comes with some challenges. First, the gameplay is limited to the speed of the slowest person's connection, which can sometimes be downright terrible. If you play these games on a LAN, especially today when gigabit switches are cheap and plentiful, everything would be fine, but remember this is 1997, and what we really wanted to do was play games on this thing called the internet. Network latency concerns aside, what happens if, by the reckoning of Alice's computer, she destroys Bob, but Bob's computer experienced a slight lag, and according to Bob's computer, he narrowly escaped Alice's attack, so who's right? When John Carmack created the game Quake at id Software, he came up with a solution and a different idea. Client server architecture has the game running on the server. Each player connects to the server which displays a simulation of the game state on their local machine. But in fact, in a perfect scenario, no code ever runs on the local machine. Inputs from the player are transmitted to the server, which assembles and coordinates the game state. In this case, we're talking about server authoritative. With server authoritative, you solve the problem of determinism, which refers back to the idea that it's best for one computer to control the game state. The game state is maintained solely on the server, but the network latency problem still exists, so Carmack made another adjustment when playing QuakeWorld when he wrote, "I am now allowing the client to guess "at the results of the users' movements "until the authoritative response "from the server comes through. "This is a big architectural change. "The client now needs to know about the solidity "of objects, friction, gravity, et cetera. "I am sad to see the elegant client-as-terminal setup "go away, but I am practical above idealistic." He changed the client's role such that it runs a lot more code than what would be ideal in a client server architecture. The client can now make guesses on what the game state should be, go ahead and adjust locally, but then correct if the server sends back some information that conflicts with the client's predicted state. This strategy effectively hides the latency so none of the players notice.