Description
This article is from the netrek
Frequently Offered Clever Suggestions list, by Tom Holub
doosh@best.com with numerous contributions by others.
25. Have the client update the torps instead of the server.
Problem: A lot of network traffic is spent sending torp updates.
Proposal: This could be avoided by just sending the "start" packet
with direction and speed, and sending an "end" packet when the torpedo
dies.
Why Not: The main difficulty is losing synchronization with the
server. If a "torp death" packet is lost or delayed, the position of
the torpedo will be inaccurate because of torp wobble or possible
early expiration. It might reduce net traffic, but it could be really
confusing.
The biggest obstacle is "torp wobble", which is a random change in
direction added every update. If the client misses an update, the torp
will continue off in the previous direction until the next update
arrives, at which point it will jerk back on course. This can be
worked around by sending a random number seed to the client, and then
having the client emulate the wobble, but this is just making more
work for the client and creating the opportunity for borgs to
accurately predict wobbling torps.
Since borgs have all but disappeared from the scene, and most machines
aren't taxed for CPU, this change has become more realistic; however,
the problem of synchronization is not a small one. This idea is often
batted around when people discuss creating a format for recording
netrek games that doesn't take enormous amounts of space. It's a lot
of coding and testing, though.
Continue to:
Share and Enjoy
Bookmark this story so others can enjoy it:
Tags
game, netrek
