Status of antiping

[nzyuzin]

Hello,

Thanks for working on prediction for 0.7! Could you please tell me whether the code for prediction on antiping branch is any different from the one you pushed into teeworlds/teeworlds? Should it be more advanced prediction than what's now found upstream?

Also, what are your plans with regard to the antiping? Are you still planning to work on it? I could help working on it if needed, but I am not familiar with how it is typically implemented.

[axblk]

Hi! The code for antiping is mostly the same as teeworlds master. In addition, the antiping branch prevents projectiles from flying through walls.

Yeah, I have some plans for extending it. Actually there was a blocker in teeworlds that prevented proper rocket jump prediction (https://github.com/teeworlds/teeworlds/issues/1458) and I don't have a lot of time right now. The major issue right now is, that there is no prediction for weapon effects (rocket explosions, hammer force, ninja movement, ...) at all. The hardest part is proper rocket jump prediction. In many cases, the force of the explosion must be applied before the client even knows about the projectile. This means that the client needs to predict the spawning of projectiles when you shoot. Once the client is informed about the new projectile by the server, it needs to merge the local projectile (which was created by the prediction) with the remote one from the server. In case the server did not create a projectile (due to packet-loss of your input for example), the client needs to remove the local one after some time.

The goal is to have a simulation of the whole gameworld in the client, which is periodically merged with the info from the server. To do that, one can reuse the gameworld code from the server. The merging with the server snapshots will probably be rather hacky. The ID allocation for new projectiles is not deterministic, so you need to compare their position, direction, speed, ... to merge them. That is roughly what ddnet is doing as well, but I don't want to just copy their code, since they use a lot of ddrace specific physics code. However, some parts of their code could be useful, or at least serve as inspiration.

The whole thing also needs an option for custom game modes to opt-out of this. They might modify the weapons in a way that is not compatible with the vanilla prediction, so they should be able to disable the advanced prediction for each weapon.

[nzyuzin]

Thanks for the detailed explanation!

The major issue right now is, that there is no prediction for weapon effects (rocket explosions, hammer force, ninja movement, ...) at all.

Could you give pointers to which classes will require changes with regard to this? I guess game/client/gameclient and game/client/components/items certainly; is there anything else? (I'm not sure where to start looking)

[axblk]

Yes, game/client/gameclient.cpp is probably the most important one, game/client/components/items.cpp is only used for rendering. The gameworld simulation from the server-side is needed: game/server/entities/ and game/server/gameworld.cpp. The easiest method is probably to copy these to the client and remove all server dependencies from it.

In the gameclient you create a gameworld instance. Each time the client receives a snapshot, you need to do the following steps:

• Simulate the local gameworld until it reaches the new tick, use input from local player
• Merge the info from the new snapshot into the gameworld
• Discard entities, which were created locally but were not approved by the snapshot after several ticks

Then you do the actual prediction:

• Copy the local gameworld
• Simulate the copy until it reaches the prediction tick, use input from local player
• Use this predicted gameworld for displaying entities (tees, projectiles, ...)
• Once we get a new snapshot delete the predicted world