After fixing some of the more egregious bugs (see below), we are very confident in this week's build. Therefore, we're sending out alpha keys again! We'll be sticking to the old format: 100 keys on Friday plus every tester gets one #invite-a-friend key per week.
Changes
Here is a list of things that have changed since last week:
Players cannot use the debug fly cam anymore (oops)
Shotguns can be used to open doors again
Improved death cam
Fixed multiple issues related to disconnects and joining in progress
Mega match is a thing of the past
I don’t see nothing wrong with this…
Butterfly Effect
Now I want to take a deeper dive into the technical side of the network refactor and shine some light on one specific part of it. In an online FPS, due to latency, the clients and server can often slightly disagree over the current state of the game. The server is more important than the clients, though - what the server thinks is correct is considered the truth. The clients need to regularly correct their game-state based on updates from the server.
In our original version of the networking code, your actions played on the server whenever it received the corresponding message. In our new system, your actions will play at the time you executed them on your client. If the server receives an action from your client, it goes back in time and executes the action in the past. Not with a time-machine, mind you, but with the power of simulation. This can cause something like a “Butterfly Effect”: After introducing your action into the past, the server must then re-simulate all subsequent events to see what else could have changed as a result.
Let's take an example. We are at an arbitrary time 't' during a match, where the following things happen:
t+00ms: You shoot another player on your client and reduce their HP to zero.
t+10ms: The other player shoots at you and deals some damage.
t+60ms: The server receives the other player's message about shooting you.
t+70ms: The server receives your message about killing the other player.
In the old system, the server would calculate the other player shooting at you at 't+60ms' and reduce your HP. Then it would register the other player dying at 't+70ms'. You took damage because your message took longer to reach the server than your opponent's.
In the new system the server will do the following when your message reaches the server at 't+70ms':
Rewind time to 't'.
Calculate your shot with the game-state at 't'.
Fast-forward time to the present, by re-simulating the actions.
You killing your opponent invalidates their action of shooting you. Therefore, the server can remove your opponent's action from its game-state (i.e. you take no damage).
It will not automatically do it, but it has the choice if deemed appropriate. To decide whether to remove an invalidated action or to play it anyway is a very complex process. It depends on which kind of actions are involved and the current game-state. In the example above, it might seem reasonable to remove your opponent's action, but in other cases, it would break expectations. If you are shooting at an enemy on your screen, you don't want him to get away unharmed just because he moved out of the way on the server. Or even worse, a player you just killed spring back to life and kill you instead!
Gameplay
The game has gotten to a point where it can be 'fun' again. Here's a round from an internal playtest that played very differently for different members of the team.
The attackers have a plan…
Meanwhile on the other team…
I'll see you in the game this weekend,
th_pion