lag.htm

关于windows游戏编程的一些文章还有相关图形

<P>First we will start by determining what direction the player is looking, so that we can tell the other player's computer how to draw which direction your player is facing.

<P>If we have less than 256 directions the unit could be facing, then we can fit it into 1 byte. Most likely the game allows for more than this, but we can fudge it so that it looks correct enough on the other persons display so that this will be fine. If we store the direction a player could be looking up or down we will need an additional byte. This means we have 2 bytes that will need to be sent every update for the characters facing information. 

<P>Now we have the direction and speed/distance you are moving. To make this easier we can just send what game developers call a "delta", which in math they use to mean a change, so we will just send the changes in coordinates from the last position. To update the unit's position in the 3 axis's X , Y and Z we will need 2 bytes each to store a change of up to 64,000 unit positions in any axis. If we can shrink this movement down to be limited to a 256 unit change we can reduce the bytes needed from 6 to 3, but for arguments sake we will say we cant, so we need 6 bytes bringing the current total to 8 bytes.

<P>To figure out when the unit jumps a lot is left up to the user, as they may let go at any time, so we will just turn on a flag that says it unit is jumping and at what height position they are currently at. If the user lets go before we update again, it will be less of a mistake then if we only update where the unit's current height is, as you can only jump so high. So we add on another two bytes for the time the user pressed jump, which brings us to the total of 10.

<P>We'll use another byte to add on the time a weapon was fired and we also have to pass on what kind of gun we are using so that the other computer knows what type of projectile to attack with which will take 3 bytes, bringing us to 13 bytes. 

<P>Assuming that there can be 8 players at any time in a multiplayer game, we need to be able to send 104 bytes per update to give just this minimal information for each of their actions. There are a few more areas that need to be covered for players as well as some server synchronization items, but we will leave those out for this discussion.

<P>These 104 bytes needs to be sent over the Internet through a protocol, and the one most games use it called UDP, which takes up 8 bytes to address information about the packet and where it is coming from and going. So to travel over the Internet our packet would need to be a grand total of 112 bytes, which is well under the 340 byte per update limit.

<P>Unfortunately modems rarely get their full speed over the Internet, and packets are often lost. If we sent more information it might not matter if a packet was lost, as we may be able to send all the information needed each time. This is usually not done just because the idea is that if you have a bad Internet connection, you may not be able to play smoothly anyway, but if you have a good connection you will most likely have a better chance of fast updates by sending less information and having the risk of having to resend the packets that are lost

<H3><FONT COLOR=YELLOW><I>The Home of Lag: The Internet</I></FONT></H3>

<p>There are many things that can happen to your packet when it enters the Internet: 
  it can collide with another packet and need to be resent, it can get lost in 
  the shuffle of routers if a normal connection is down or it can be delayed on 
  a busy network or a number of them.
  
<p>Since going into full detail on the life of a packet would require a lot of 
  background and messy details, Ill skip to the real basics.
  
<p>Firstly, the more network devices your packet has to travel through, the longer 
  it will take, and the more chance it will collide with another packet and never 
  reach its destination. In network terms, we call these hops. A packet will hop 
  from your ISP's computer which you are connected to, to your ISP's router, then 
  to your ISP's feed's router, then it will hop along the feed's backbone's routers 
  a couple of times and land on the destination computer's ISP's router, then 
  ISP's computer, then your destination computer.
  
<p>That's a lot of hopping around, and a lot of chances that you will get a collision. 
  Physical location usually means you have less hops to go once you leave your 
  ISP to the destination ISP, but this isn't always so. You can actually track 
  the amount of hops from your machine to a destination with a tool called &quot;trace 
  route&quot; which will also give you lag times for each hop along the way, so 
  you can find the culprit slowing down your connection. Unfortunately, there 
  usually isn't much you can do about this, unless you find out its your ISP, 
  then you can switch to another.
  
<p>Average ping times to different sites with a good connection (T-1 or greater) 
  can be about 11-20 milliseconds (ms), average pings to slower sites range more 
  along 70-100 ms, slower pings can be up to 300 ms regularly and can get EXTREMELY 
  bad where it can take several seconds to reach. Packets however don't live this 
  long, they can only bounce around so many times before they are considered obsolete, 
  so the information is better to just be resent.
  
<p>Taking 300 ms as a time you may actually get often enough on a dial-in modem, 
  you can see that you have a lag time of 1/3 of a second between when you send 
  your information, and when you receive an update from the other player. This 
  means that what he did 10 frames ago (on the 30 frames/second model), you are 
  just seeing now, which means you are very out of sync with each other. If you 
  have a lag of 100 ms instead you will only have a 1/9 of a second or seeing 
  what happened 3 frames ago on your system. This is an improvement by far, but 
  if the game relied solely on this information your opponent would still seem 
  to move in a choppy fashion and seem slow to respond. So what are the solutions?
  
<H3><FONT COLOR=YELLOW><I>Smoothness via Duct Tape</I></FONT></H3>

<p>Since you cant make the Internet go any faster, and not everyone can have high 
  speed connections or be in the same room or building with each other when they 
  play game developers have had to come up with alternative solutions to how to 
  make multiplayer games seem smooth.
  
<p>What is commonly done is called interpolating the figures, this is just making 
  an educated guess. If the player is running forward now, then player will more 
  than likely be running forward still on the next update, so until we hear from 
  them, we will assume that they are running forward and move them on the screen 
  this way.
  
<p>This is how you end up with false kills and things that should have been hits, 
  but weren't, because the system was showing you something but in fact, the other 
  player wasn't really there, you just hadn't gotten the update yet.
  
<p>Other factors that are involved in this, is how the game determines what is 
  happening and what isn't. So far I have describe the networking in what is called 
  a client to client game. The individual computers just share information about 
  what is happening with each other. This doesn't work very well when you start 
  adding more people though, as you end up waiting for information on everyone, 
  which is taking more of your valuable modem bytes per second.
  
<p>So another model is what is called a client-server mode. One machine acts as 
  the server, and all updates are sent to it. Then it sends updates back to all 
  the clients and tells them what other clients are doing. Depending on how the 
  game developers made the software, the server may be the machine that determines 
  whether something is a kill or not, or it may all be individually handled on 
  the client machines and the server just passes on the information.
  
<p>How this is all accomplished could take up a whole article in itself, so lets 
  wrap this up....
  
<H3><FONT COLOR=YELLOW><I>It isn't as easy as it sounds</I></FONT></H3>

<p>Most likely you didn't read all of this and decide it was easy, but unfortunately, 
  it's even harder than I described it. Normally games are sending much more information 
  or stats then I originally provided for, and they don't just have to fill in 
  information for two people, they can have up to eight, or thiry two, or more. 
  That means you can send eight times less information with every update if you 
  expect to do it as often or update eight times less or some combination in between.
  
<p>There is a LOT of tweaking by adjusting small amounts of &quot;how much to 
  send&quot; and &quot;how often to send it&quot;, and it just can't be done off 
  the top of your head. This is an extremely hard process to design and implement 
  and it becomes all the harder because the major decision maker on whether the 
  information will get there or not is totally out of the designers hands: the 
  Internet.
  
<p>Hopefully this cleared up some of the questions you had about what lag is, 
  why it occurs and what is being done to try to work around it. Developers are 
  really trying to make the best multiplayer experiences they can and it takes 
  a lot of individual tuning for each game to do it properly and a lot of testing 
  to get it right.</P>

<!--Bottom Navigation-->
<A NAME="bottom"></A>
<!--End Bottom Navigation-->
</STRONG>
</FONT>
<!--End Body-->
<!--Bottom-->
<BR>
<IMG SRC="gradbar.jpg">
<BR>
<FONT SIZE=2 COLOR=#8B8B8B FACE=Helvetica>
<I><font color="#FBFBFB">T</font><font color="#F7F7F7">h</font><font color="#F3F3F3">e</font><font color="#EFEFEF"> </font><font color="#EBEBEB">G</font><font color="#E7E7E7">a</font><font color="#E3E3E3">m</font><font color="#DFDFDF">e</font><font color="#DBDBDB"> </font><font color="#D7D7D7">P</font><font color="#D3D3D3">r</font><font color="#CFCFCF">o</font><font color="#CBCBCB">g</font><font color="#C7C7C7">r</font><font color="#C3C3C3">a</font><font color="#BFBFBF">m</font><font color="#BBBBBB">m</font><font color="#B7B7B7">i</font><font color="#B3B3B3">n</font><font color="#AFAFAF">g</font><font color="#ABABAB"> </font><font color="#A7A7A7">M</font><font color="#A3A3A3">e</font><font color="#9F9F9F">g</font><font color="#9B9B9B">a</font><font color="#979797">S</font><font color="#939393">i</font><font color="#8F8F8F">t</font><font color="#8B8B8B">e</font> -