Andrew Fuchs wrote: > There has been a discussion on IRC about Crossfire's band with usage. > > One suggestion, is to store the information about static objects in > maps, client side. One problem is to try to define what is static and what isn't. > > Every time an animation changes state, data is resent to the client. > This supposedly uses a large amount of bandwidth, compared with > everything else. Why not send the animation once, and have the client > repeat it by itself? How would glowing crystals, and gates be > handled? That is what is tricky. Glowing crystals are not that bad - presumably, as part of the info that a space is animated, you send how fast to animate it. The problem is with gates and the like - keeping those in sync with the client is critical. For example, you could imagine a map that has spikes going up and down. The player sees them when he enters the map, but has to kill a bunch of monsters to get there. Unfortunately, the players computer isn't very fast, and got bogged down a little little when he cast that fireball, to the extent it lost a few ticks. Now what the client displays as the state of the gates vs what the server thinks is the state is no longer in sync - player tries to pass them, and gets skewered. Note that you can substitute player computer for server there also - there are known times that the server can't keep up, and would thus be behind. So to do this, a new flag is really need like 'static animation' or something to denote that this is a purely cosmetic animation only and doesn't have any actual effect on gameplay, and thus doesn't need to be kept in sync. For those, we could send the animation id and just forget about it. For animations that are relevant, treat them like they are now. Also, at some level, you start imposing higher CPU cost on the server to figure all this out. So there are also some tradeoffs there.