- the local human player's prediction, reprediction and (new!) reconciliation,
- interpolation for NPCs (non-player or 3rd person player entities),
- client effects (e.g. pulsating light sources, swinging or bopping items, etc.).
Can we apply prediction also to entities other than the local human player?
Prediction is the technology that gives us smooth feedback and immediate response for the local player's control input without lag or delay, even though the control input must be sent to, processed and returned by the game server first.
These aspects seem to be important for answering the question:
- The full state of all entities had to be serialized and synchronized over the network. For example, for movers or bots that have custom behavior scripts, the script state had to be covered by the serialization as well. We are well prepared for but have not yet fully implemented such functionality. Catching up on this would not be a great deal, as this change is required for implementing a "load/save game" feature, too.
- Event handling (sounds, particles) should not be a problem, as we have already resolved that for player prediction very well. Modifying another entity's state, e.g. when hit by a shot, should not be a problem either.
- Even if it was possible to predict NPCs analogously to the local player (it isn't, see below), it would imply that the reprediction runs after each
SC1_FrameInfoserver update message had to cover not only the local player, but all relevant entities, thus making them prohibitively expensive.
- Newly created entities (thrown grenades) would need special consideration. That is, in order to get rid of statements in weapon scripts, entities that were created during prediction would have to be cleared again when the related authoritative server response arrives.
Code: Select all
if ThinkingOnServerSide then ... end
- A big problem however is the actual "driving" of the prediction for the NPCs: While a local human player is both client-predicted and server-processed on the basis of its very own player input (whose frame rate and progress to the server is totally independent from the server tick rate and that of other players), it is not possible to predict the NPCs on the basis of the player's input as well: Each player input contains the related client frame time (the time span for which the input is to be applied), but at each server tick, the server would be confronted with the inputs from multiple players, and it would be impossible to decide how to apply them to the NPCs. Therefore, from the server's point of view, NPCs simply must be driven by the server tick rate.
Inversely, anticipating server ticks on clients would require careful synchronization, too, and generally seems not to be feasible. Even if it was possible, NPCs would be predicted again with the server tick rate, not with the client's frame rate.
Summarizing this item, moving NPCs with the client frame rate seems to be possible only with interpolation, because synchronization efforts and competitive player inputs seem to make prediction impossible.
- It is obviously impossible to predict other (3rd person) player entities.