So the vehicle physics are some what working, to an acceptable prototype standard at least, and the vehicle is made from loadable parts so that it can be created and modified in real time using a config string on spawn or real-time editor (not made yet). Now its time to move on to designing and writing the next part of the prototype; Networking.
I had zero networking knowledge before five days ago when I started looking into game Networking, so I advise that you don’t take anything written here as the only way, or even correct way, to do things.
I started researching networking by trying to understand the core concepts, something that can be a bit of a mind fuck to start. As anyone who’s played a networked game on Steam* knows, you have a or many ‘clients’ and a ‘Server’ or ‘Host’. The client is a player, and the server is the one who passes what the clients are doing to all other clients that need to know. The clients pass this information in packets of data, serialised and optimised down to the bit to be as small as possible. These messages are received by the server which then works out who else needs this packet and sends it to them. The receiving client then updates their world with whatever the other client told them about theirs. This type of networking is called none-authoritative. This is almost peer to peer, with the server being nothing more than a middle man relaying messages. This is great for none competitive or closed games where the client can be trusted to send such information, but when you start wanting to make sure a client isn’t claiming to have gotten 6 no-scope headshots with one bullet, the none-authoritative server doesn’t cut it.
Instead, an authoritative server is needed. Unlike the none-auth. server, the client don’t send the ‘results’ of calculations done on their own machine, rather they send just the player input messages. The servers takes these time-stamped messages and works out the results of all players inputs for it self. It then sends the resulting information (position, rotation, you’re dead etc) to all clients, resulting in fair game… to an extent.
The above describes an authoritative server approach, creating a ‘fair game’ for all clients, but this isn’t quite true due to lag. On a good day, a packet could take 100 milliseconds to reach a server and for the server to make a calculation and respond to the clients input. Not bad, but the server will likely only accept 10-15 of these messages a second, much more would result in huge amounts of bandwidth over time. The delay quickly mounts up. When a client shoots, chances are they’ll be expecting their weapon to fire the nanosecond their Razor H10000 mouse is pressed. It would be unrealistic for a client to be made to wait for a response from the server to work out that they have pressed shoot. To overcome this visually, the client can be allowed to predict what will happen by simulating the servers functions on their own machine. The result of these functions can be overwritten once the server’s packet comes back with the result of its own calculations. So if, for example, the server decides you are no longer living on its last update that was on its way back to you when you shot, it can overrule the fact you just pressed shoot whiles point at the enemies head, the gun went bang and you told him to ‘sit down’, because they already killed you but you didn’t know it yet due to the packets delay. This is the most basic example of how an authoritative solution can appear to lag, however much more complex scenarios exist.
Take a client moving in 3d space at speed, say 10 meters per second, he’s Usain Bolt, if the client is sending 15 updates per second and has a connection delay (ping) of 100ms, the receiving clients are going to have to make up the meter Usain will move between updates. One way to do this is simple extrapolation, where the movement is predicted based on the last update the clients received from Usain. This would work fine if he continues at a constant speed, however if he decided to change direction right after the last update, he could be 0.99m in the other direction to that predicted by everyone else. A second option to overcome this is interpolation. Instead of predicting where the Bolt is going to end up, clients run the game behind time between the last two received location packets from the server. If we know the server will be sending updates 15 times a second, we have 66ms to fill. At 120fps this is about 8 frames. Once the client reaches frame 8, the client will be at the end of the last update it received and the new one should have arrived. In the case of lost packets, extrapolation can take place at the risk of a greater jump later and the ‘walking through walls’ effect, or the client can simply freeze the other clients resulting in a jerking or super fast catch-up movement when the next update is received.
So that’s where i’m up to with my understanding of networking so far and i’m starting to design the network implementation for my vehicle. I think i’ll be using an authoritative approach due to its anti-cheating, lower bandwidth and joint accuracy. I have considered sending each players input to one another over a none-auth. server, but decided against this due to the speed I could send reliable packets and the chance of loosing the high-speed unreliable packets. If a client was to loose a packet containing vehicle break input, the simulation on the clients would be vastly different to that of the driver. Sending the exact position of the vehicle every now and then to ‘check’ the position of the vehicle on the none-driver client, over a none-auth server, opens up to cheating e.g. going 1000 mph. It may be possible to create a bit of a hybrid of the two to minimise bandwidth and server CPU.
For now, i’ll be sending the player inputs over to the server, getting the server to calculate the vehicle physics whiles interpolating / simulating on both clients whiles waiting on the servers results. If a server result conflicts with any extrapolation done client side, i’ll interpolate client side to smoothly correct the error over time whenever possible.
*I say on Steam as it seems to expose a lot of client side networking info in its UI, more so than say PS3 or XBox 360′s pick up and play style online matchmaking.
Tim Sweeneys Unreal networking
Master Server Compassion Chart
Impressive 100 page presentation on networked physics by Glenn Fiedler