Server Updated Shots

From BZFlagWiki
Revision as of 03:31, 14 April 2007 by (Talk)

Jump to: navigation, search
Picture Frame.png This page contains the design document for an enhancement or feature. It is a work of collaborative development, and may not represent the final design. If you are not part of the development or design group, please post comments and suggestions on the talk page and not in the middle of the design.

This document describes planed changes to shot handling on the client and server.


Shots can not be updated in mid flight. We need the server to be able to modify any shot in flight and have the game clients adapt to the new changes.

Server Shot State

To do any of this we need the server to have an accurate picture of the shots in the game. We need to move the shot strategies over into libGame so they can be tracked by both the players and the server. Shots are Time Stamped with a server clock so syncing the states should not be too hard.

GM Update Changes

The MsgGMUpdate should be changed to only send out the newly targeted player. This should happen after a PlayerUpdateMessage, so the server has the most accurate state for the player. If the lock-on change is valid ( verified via the server DR state that should now match the client DR state ) the server will send out Shot Updates for the GM shot to all players, including the shooter.

Generic Shot Updates

A new MsgShotUpdate should be created that can send a new time stamp, position, vector, and lifetime for any shot. Any client that receives this message needs to find the shot, delete the old shot path, create a new shot path/strat with the starting position, vectors, and times, then plot the shot position forward to the current server time. This may make shots "pop" as they update if there is a discrepancy, but all states will be valid. This prevents clients from providing invalid GM shot updates, and lets the server do non standard shot dynamics such as gravity well, and enforcing shot ends in a predictive manner. Shot updates should be exposed to the API.

Shot ID

Shot IDs should be separate from the slot. The client should take all newly fired shots and assign them a temporary shot ID until it gets the shot back from the server. At this time it would replace the shot ID with a valid server ID to be used with shot updates at a later date. The local client should send it's temporary shot ID when sending a new MsgShotBegin and be passed that local ID back in the verification message. When the server sends the shot back to the local player, it should recompute the shot path from the new data as if it was a remote path, as the server may have modified it. All local shots can go into one big list on the client, as they will have unique IDs.