Won't BZFlag 3 eat bandwidth

[jpenguin]

if everyting is going to go through the server, won't a lot more data have to be sent and received? Won't that eat bandwidth, will BZFlag 3 be a LagFest?

[JeffM]

you are greatly misinformed.

The simple answer is, no, it should not.

The complex answer is:
"everything" is not "going to go through the server" for 3.0, at this time only a few things have been moved to the server, and they do not add any appriciable network traffic since they are the same messages that you got before, just from a different source (server instead of another client). In fact most messages will get LESS lag, since they will come from the server, and only have to travel to you, not from the other client, to the server, then to everyone else.

As more things "move to the server" in later releases the important things (such as movement and shots) will also be left on the client. The server will simply be involved when there is a discrepancy between the client and the server (and the server always wins). This lets your local view stay smooth. You will only see differences in cases where you have very high lag/packet loss, or are cheating. In these cases, only you will see the issues, others will still see the updates from the server and will not be as affected by your personal lag.

The clients are actually doing lag compensation in 3.0, so the amount of lag you have plays less of a role in the game play. The client will compensate where it draws other tanks based on lag (this means no more 'leading' your targets based on the lag value).

Please remember that bzflag was initially written to be a LAN game, and was never meant to deal with lag times over a frame time. Much of what happens now is considered "bad" so there will always be changes as the game gets closer to modern standards. Our goals are to make the gameplay experience as consistent for all the players to make it more fun.

[clarahobbs]

Yay, lag compensation! I didn't know 3.0 would have that! The only problem is that it might do some weird stuff if someone laggy stops and his tank is drawn ahead of it's position according to a non-laggy player's client. Wouldn't that cause his tank to appear to jump back when the non-laggy guy sees that it stopped moving?

[blast]

Yay, lag compensation! I didn't know 3.0 would have that! The only problem is that it might do some weird stuff if someone laggy stops and his tank is drawn ahead of it's position according to a non-laggy player's client. Wouldn't that cause his tank to appear to jump back when the non-laggy guy sees that it stopped moving?

Try it and find out.

[JeffM]

Yay, lag compensation! I didn't know 3.0 would have that! The only problem is that it might do some weird stuff if someone laggy stops and his tank is drawn ahead of it's position according to a non-laggy player's client. Wouldn't that cause his tank to appear to jump back when the non-laggy guy sees that it stopped moving?

yeah, that happens now in 2.0.x. In the stopping case, the effect will be the same as it is now. The DR will treat the tank like it keeps moving based on the last update, and when you get the "stop" message from the remote player, his tank will pop back to where he stopped. There isn't much else you can do about that. Computers can't predict the future

In the case where he is going from stopped to moving there will be some (good) differences.In 2.0.x when you get his "move" message, his tank would snap to where it WAS when the packet was sent. This is not the same place where his tank is now on his screen, because he kept moving during the time the message was getting to you. So his tank is always "behind" on your screen.

3.0 has a timestamp in the packets that is synced with the server clock, so everyone can compensate for the time the packet is on the wire. and when the tank pops it pops to where he really is. This makes players and shots appear in the same place at the same time on all clients, making things a lot easier.

The disadvantage is that the pop will be a little longer then the 2.0.x case, but the advantage is that during the rest of his movement in the simulation is much more accurate. Since accuracy in position affects shooting, it is one of the key factors in our gameplay. Gameplay accuracy outweighs the change caused by a small blip when tanks make large movement changes. 3.0 also enforces acceleration values on tanks, to help smooth out these motions by preventing tanks from making "instant" direction changes. This gives the packets some time to travel and helps minimize the visual pop.

[jpenguin]

you are greatly misinformed.

The simple answer is, no, it should not.

Yay

I'm happy to hear that