How an Online Server Game Works?

Hello.

my current problem is that I have some doubts about the term of an online game, if I want to get an explanation of how this works when uploading to the web and being executed by many users at the same time.

My main doubt is when a user run my game is created as a copy of my game only for him, this doubt arises because I do not want everyone to appear on the same terrain, if I want to create it separately, I have the idea of ​​storing some id that identifies the game variables of each in its own PlayerPrefs.

Another question is whether an online game uploaded to a server should be the same for each, then if user A could access user B’s variables, right? I ask because I want to add an action to attack another user and therefore I need user A to enter the combat area of ​​user B and I do not know if it is necessary to have to use a network system because the same game is going to be used by all, so I do not know if I can add a simple multiplayer system and that’s it.

First of all I apologize for my complete ignorance of the subject, but this is the first time that I will be something like this and I want to do well and without doubt of what I do. I look forward to your help and above all thanks.

Forgive my English.

There’s one authoritative version of the world held on the server. But various tricks are used to make sure the client machines are not waiting on the server before displaying action.

Each client machine sends a regular stream of packets to the server, where each packet would contain a simplified update of the player’s inputs. Each tick, the client might send a mouse position, or keys pressed. This is a low bandwidth stream.

Simulation code takes these input streams, simulates motion and resolves them into character / vehicle positions. This simulation can run both on the server and on the client.

Having received the input packets, done the simulation, the server sends out packets containing an authoritative version of all the client’s positions. In most cases this will precisely tally with what the client thinks.

These client positions only relate to mobile objects. All the static objects are never updated.

From a programming point of view, we need to cope with latency. In the time it takes for the message to arrive, things will have moved. To cope with latency, server code has to play tricks with time. When someone shoots a gun, we have to consider what they were pointing at back at the point of shooting, and not looking at the world state now.

In the majority of cases, the server packets will reconcile with simulations performed on the client. But when the two disagree, the server’s version is considered authoritative.

In the client-server model used by Quake 3 - the server does indeed sends back positions for every character every tick. In some more modern architectures, the traffic can handle more players by updating some clients less frequently.

This talk on the networking of Halo Reach describes such a solution