Abstract:
Client position in a multi-client game is determined using dead reckoning. Clients send information to a server over a network. The server distributes this information to other clients. A client uses this information and dead reckoning to determine a character&#39;s position. The server may calculate the client&#39;s position using dead reckoning and send updates to clients when errors between actual and calculated positions exceed a threshold. Clients may calculate their position according to dead reckoning, and when an error between actual and calculated position exceeds a threshold, send updated information to other clients. This Abstract is provided for the sole purpose of complying with the Abstract requirement rules that allow a reader to quickly ascertain the subject matter of the disclosure contained herein. This Abstract is submitted with the explicit understanding that it will not be used to interpret or to limit the scope or the meaning of the claims.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     The present application is a continuation and claims the priority benefit of U.S. patent application Ser. No. 13/431,682 filed Mar. 27, 2012, which will issue as U.S. Pat. No. 8,734,258 on May 27, 2014, which is a continuation and claims the priority benefit of U.S. patent application Ser. No. 11/479,829 filed Jun. 30, 2006, now U.S. Pat. No. 8,142,289, the entireties of which are hereby incorporated by reference. 
    
    
     FIELD OF THE INVENTION 
     The present invention relates generally to video gaming and, more particularly, to on-line video gaming. 
     BACKGROUND OF THE INVENTION 
     Growth of the electronic entertainment industry has introduced new challenges for effectively transferring information between clients, or players. For example, many new video games allow multiple players to participate in the same game environment. Some newer games support multiple clients participating in a game environment using a wide or local area network, such as the Internet or other network, to transfer data between the clients. 
     As video games increase in sophistication and complexity the amount of data exchanged between players also increases. The increase in data exchanged between players places increased demands on the network. Increases in the amount of data transferred between players can cause decreased game performance, even with broadband network connections, such as DSL and cable modems. 
     Thus, there is a need for improved, more efficient, techniques for transferring data between players in an electronic gaming environment. The present invention satisfies this need. 
     SUMMARY OF THE INVENTION 
     In accordance with the invention a method and apparatus for improved, more efficient, techniques for transferring data between players in an electronic gaming environment is described. In one embodiment, clients send information to a server over the Internet. This client information may include, but is not limited to, character position, character velocity, character acceleration, and non-character information that may relate to the client&#39;s ability to process data in a timely manner. The server sends client information for other clients to each client. The client uses dead reckoning to determine the position of the character on the other clients. In one embodiment, the server also calculates all of the clients position using dead reckoning and sends updates to clients when errors between one of the characters actual position and dead reckoning position exceeds a threshold for that client. In other embodiments, clients can calculate their own position according to dead reckoning, and when an error between their actual position and the dead reckoning position is exceeds a threshold, send updated position and velocity data to the server or directly to other clients. 
     In one embodiment of the present invention, a server receives client information including, but not limited to, initial position and velocity data from a client. The server then sends a portion of that client&#39;s information, such as, its position and velocity data to other clients. The server continues to receive client information updates from clients and may calculate a dead reckoning position for each client. When the server determines an error between the dead reckoning position and a actual position for any of the clients exceeds a threshold level for any other client, the server sends updated client information for the client who&#39;s errors exceed the threshold level to the other clients. The position and velocity data can be sent through the Internet or any other network. Also, each client can have a unique error threshold for each other client. That is, individual error thresholds can be set for individual clients relative to each other. 
     In another embodiment client sends its client information to a server. The client also receives client information of other clients from the server. The client then calculates a dead reckoning position for the other clients. The client also determines if updated client information has been received from the server, and if it has, updates the client information for the other clients in response to updated information received from the server. 
     In yet another embodiment a client sends client information directly to other clients, and receives client information direct from the other clients in a peer-to-peer configuration. The client calculates a dead reckoning position for itself and the other clients. The client determines if an error between its calculated dead reckoning position and its actual position exceeds a threshold level for any other client, and if it does, sends updated client information for itself to the other clients. 
     These and other features and advantages of the present invention will be appreciated from review of the following detailed description of the invention, along with the accompanying figures in which like reference numerals refer to like parts throughout. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Various embodiments of the present invention taught herein are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings, in which: 
         FIG. 1  is a block diagram of an exemplary system configured for on-line gaming in accordance with aspects of the invention; 
         FIG. 2  is a block diagram illustrating an example of information sent between multiple clients in an on-line game; 
         FIG. 3  is a diagram illustrating directions in a game world environment; 
         FIG. 4  is a flow chart illustrating an example of a dead reckoning technique consistent with one embodiment of the present invention; 
         FIG. 5  is a flow chart illustrating an example of dead reckoning by a client; 
         FIG. 6  is a block diagram of another exemplary system configured for on-line gaming; 
         FIG. 7  is a flow chart illustrating another example of dead reckoning by a client; 
         FIG. 8  is a block diagram of an exemplary embodiment of a server in a multi-client game system; and 
         FIG. 9  is a block diagram of an exemplary embodiment of a client in a multi-client game system. 
     
    
    
     It will be recognized that some or all of the figures are schematic representations for purposes of illustration and do not necessarily depict the actual relative sizes or locations of the elements shown. The figures are provided for the purpose of illustrating one or more embodiments of the invention with the explicit understanding that they will not be used to limit the scope or the meaning of the claims. 
     DETAILED DESCRIPTION 
     In the following paragraphs, the present invention will be described in detail by way of example with reference to the attached drawings. While this invention is capable of embodiment in many different forms, there is shown in the drawings and will herein be described in detail specific embodiments, with the understanding that the present disclosure is to be considered as an example of the principles of the invention and not intended to limit the invention to the specific embodiments shown and described. That is, throughout this description, the embodiments and examples shown should be considered as exemplars, rather than as limitations on the present invention. Descriptions of well known components, methods and/or processing techniques are omitted so as to not unnecessarily obscure the invention. As used herein, the “present invention” refers to any one of the embodiments of the invention described herein, and any equivalents. Furthermore, reference to various feature(s) of the “present invention” throughout this document does not mean that all claimed embodiments or methods must include the referenced feature(s). 
     The explosive growth in the electronic entertainment industry has introduced new challenges to support new games, such as on-line games. For example, on-line games may allow multiple clients, or players, in remote locations to interact in a gaming environment. As the clients play the game, data relative to the clients is exchanged between the multiple clients. In many games, the clients control the movements of a character in the game. As the client moves the character, information about that characters movement must be sent to the other clients participating in the game. Transferring the data about a character&#39;s movement can significantly increase the bandwidth requirements of the network. 
     One feature of the present invention is that it provides a method of updating one client&#39;s character position and other information on another client across a network using a dead reckoning technique that can reduce the bandwidth required to play a multi-client game across the network. 
       FIG. 1  is a block diagram of an exemplary system configured for on-line gaming in accordance with aspects of the invention. As illustrated in  FIG. 1 , the system  100  includes at least one client  102 . Typically, there may be multiple clients  102  in the system. The system  100  also includes a server  104  and a network  106  that provides connectivity between clients  102  and server  104 . The network  106  in system  100  may be referred to as a client-server network since it comprises a plurality of clients  102  communicating with a server  104 . A network  106  may include a wide area network, a local area network, a wireless network, a personal area network, the Internet, or any other network. As described further below, in one embodiment, clients  102  send information to server  104 . As used herein “client information” may include but is not limited to information related to the game character on the client such as character position, character velocity, and character acceleration. This information may be expressed in multiple dimensions. Additionally, the “client information” may include non-character information such as information related to the client&#39;s ability to process data in a timely manner. Server  104  may then send the client information, or a portion thereof, to other clients  102  participating in the game. To reduce the amount of data that is transmitted across network  106 , a form of “dead reckoning” may be used. 
       FIG. 2  is a block diagram illustrating an example but not a limitation of the of information sent between multiple clients  102  and server  104  in an on-line game. As illustrated in  FIG. 2 , clients  102  may report location information about their respective character to the server  104 . This location information may include a position and velocity of the characters. In other embodiments, other information, such as acceleration, can also be included in the location information. Additionally, other information may be exchanged between clients  102  and server  104 . This other information may include information related to client  102 &#39;s current status such as a “busy signal”. 
       FIG. 3  is a diagram illustrating directions in a game world environment. As illustrated in  FIG. 3 , position and velocity in the game world can be represented as either three-dimensions, that is with x, y, and z components, or two-dimensions, with x and z components. 
     Returning to  FIG. 2 , clients  102  can report their positions on any schedule a game designer chooses. For example, the clients  102  can report their positions at purely periodic times, threshold-based times, or any combination of these two, or by any other schedule. Typically, the schedule is set to ensure accurate reporting of client information from each client  102  to server  104 . 
     In one embodiment, server  104  initially receives and immediately reports each position and velocity to every other client  102  in the game. Server  104  may save a copy of this data for future reference along with the time the data was received. Server  104  may also save a value called an “error threshold” for each client  102  relative to each other client  102  in the game. The error threshold is given by Σ k  for the k th  client  102  in the game. In one embodiment, server  104  may save the following data: 
     P ikx   save  x-position for the i th  client  102  last sent to k th  client  102   
     P iky   save  y-position for the i th  client  102  last sent to k th  client  102   
     P ikz   save  z-position for the i th  client  102  last sent to k th  client  102   
     V ikx   save  x-velocity for the i th  client  102  last sent to k th  client  102   
     V iky   save  y-velocity for the i th  client  102  last sent to k th  client  102   
     V ikz   save  z-velocity for the i th  client  102  last sent to k th  client  102   
     t ik   save  time last data about the i th  client  102  was sent to k th  client  102   
     Σ k  for the current error threshold 
     When k th  client  102  receives information (from server  104 ) regarding i th  client  102  it may save all of the above data except for Σ k  (which it may not receive). The k th  client  102  assumes that the position data it just received regarding the i th  client  102  is the present position for the player and that future positions are give by the dead reckoning algorithm:
 
 P   ix ( t )= P   ix   save   +V   ix   save   x ( t−t   i   save )
 
 P   iy ( t )= P   iy   save   +V   iy   save   x ( t−t   i   save ) (three-dimensional component saves)
 
 P   iz ( t )= P   iz   save   +V   iz   save   x ( t−t   i   save )
 
where:
 
     t is some future time (t≧t i   save ) 
     P i (t) is an estimate of future position of client i 
     (note the subscript k is unnecessary) 
     In one embodiment of the present invention the client  102  will continue to use the position calculated by dead reckoning until notified otherwise by server  104 . 
     As new client information arrives at server  104  for the i th  client  102  in the game, server  104  may compute the following error quantity, δ k  for each other client  102  in the game (i≠k):
 
δ x   =P   ikx   save   +V   ikx   save ×( t−t   ik   save )− P   ix  
 
δ y   =P   iky   save   +V   iky   save ×( t−t   ik   save )− P   iy  
 
δ z   =P   ikz   save   +V   ikz   save ×( t−t   ik   save )− P   iz  
 
δ k √{square root over (δ x   2 )}+δ y   2 +δ z   2  
 
where:
 
     P ix  is the x-position just arrived from the i th  client  102   
     P iy  is the y-position just arrived from the i th  client  102   
     P iz  is the z-position just arrived from the i th  client  102   
     t is the current time 
     It should be noted that δ k  represents the calculated error between the position just reported by the i th  client  102  and the dead reckoning model run by k th  client  102  for the i th  client  102 . 
     In one embodiment of the present invention server  104  passes on a portion of the client information just arrived from the i th  client  102  to the k th  client  102  only if δ k &gt;Σ k . Stated otherwise, server  104  only sends client information if the calculated error between the position reported and the dead reckoning position exceeds the error threshold. That is, if the output of the dead reckoning model is deemed to be “good enough”, then the new data is not passed on to client  102 , thus reducing the amount of data sent on network  106 . One feature of this embodiment is that the overall bandwidth usage of the multi-client game on network  106  may be reduced. 
     In another embodiment of the present invention provides a method by which a client  102  sends other non-character information to server  104 . In this embodiment the other information may contain “busy” or other signals that indicate that the k th  client  102  finds that it is too busy to process all of the incoming data from server  104 , client  102  may send a message to server  104  indicating this condition. Server  104 , in turn, can increase the error threshold Σ k  for that client  102 . An increased Σ k  will cause updates to that client  102  to happen less frequently thus further reducing the amount of data being sent to that client  102  on network  106 . This may additionally reduce overall network traffic. When the k th  client  102  finds its processing load returning to normal, a message indicating this fact may be sent to server  104 . Server  104  could then decrease error threshold Σ k . Several levels of error threshold Σ k  can be defined, thus allowing performance across the network to degrade gracefully in extremely busy network conditions. 
     In another embodiment, the dead reckoning technique can be performed in only two dimensions. For example, referring to  FIG. 3 , one of the components, like the y-component, can be dropped from the dead reckoning calculation. Reducing the number of components in the dead reckoning calculation reduces the amount of data server  104  needs to save for each client  102 . In the example described, the data storage requirement is reduced by approximately one third. 
     In yet another embodiment, server  104  may treat all clients  102  uniformly. For example, when it is determined that updated client information is to be sent, it is sent to all clients  102 . In practice, this means that the subscript k can be dropped from the equations above. Treating all clients uniformly greatly reduces the amount of data that server  104  needs to store in order to implement the dead reckoning technique. One drawback to this embodiment can be if feedback is being implemented, in the form of “busy” messages described above, one client  102  being overloaded, may cause server  104  to treat all clients  102  as overloaded. Thus a certain degree of fine-tuning, or network  106  bandwidth optimization, may be lost in return for reduced data storage requirements. 
       FIG. 4  is a flow chart illustrating an example of a dead reckoning technique consistent with one embodiment of the present invention. Flow begins in block  402  where a client  102 &#39;s information is received by server  104 . Flow continues to block  404  where the received client information is sent to other clients  102 . In block  406  a client  102  receives updates on other clients  102  from server  104 . In addition to receiving the actual position of the clients  102 , server  104  may calculate the dead reckoning position for each client  102 . For example, server  104  may calculate a dead reckoning position in the same manner as clients  102  are calculating dead reckoning position for other clients  102 . In this way, server  104  calculates the position that each client  102  calculates for the other clients  102 , and server  104  also receives the actual position of each client  102  from the clients  102  themselves. As noted above, the information sent to other clients  102  may not contain all information received from client  102 . 
     Flow continues to block  408  where server  104  determines an error between the calculated position and the actual position for each client  102 . Then, in block  410  the error in position for each client  102  is compared against an acceptable “error level” or error threshold for each other client  102 . In one embodiment of the present invention the error threshold can be different, for each client  102 . In another embodiment the error threshold may be the same for all clients  102 . For example, in a game, if a character on client  102  is a great distance from a character on another client  102  in game world environment, the error threshold for these clients  102  can be adjusted accordingly. In this example, the error threshold for these two clients  102  may be increased relative to each other because the clients  102  do not need great resolution due to their character&#39;s relative positions. Likewise, if the character&#39;s of two clients  102  are in close proximity to each other in the game world the error threshold may be decreased so that the clients  102  have more accurate information about the position of the character on the other client  102 . Additionally, the client  102 &#39;s error threshold may be adjusted on the basis of other characteristics that include but are not limited to the character&#39;s field of view, the clients  102  “busy status”, or bandwidth considerations on network  106 . 
     One feature of this embodiment is that the bandwidth use on network  106  can be optimized to provide more frequent updates to certain clients  102 , while other clients  102  may receive updates less often. This optimization can more efficiently use the resources of network  106 . 
     In another embodiment of the present invention, server  104  may disregard the relative position and other characteristics of the clients  102  and maintain a fixed error threshold for all clients  102 . One feature of this embodiment is that the calculational requirements is reduced on server  104 . Additionally, the error threshold, once set, may be static and the need to maintain different error thresholds for each client  102  relative to each other client  102  is reduced, further reducing the memory requirement on server  104 . 
     In a further embodiment, server  104  may adjust client  102 &#39;s error threshold responsive to non-character client  102  characteristics or network  106  characteristics. In this embodiment a client  102  that has sent a busy signal to server  104  may have its error threshold relative to other clients  102  increased so that it does not receive updates from server  104  as often. Additionally, server  104  may monitor network  106  traffic and increase all error thresholds for clients  102  as network  106  traffic increases thus providing a mechanism for more graceful degradation of game performance during peak network  106  traffic periods. 
     In block  410 , if the calculated error exceeds the error threshold, flow continues to block  412  where updated client  102  information for the client  102  who&#39;s error exceed the threshold is sent to the other clients  102 . As stated above, client  102  information is not limited to, but may include character position, velocity, acceleration, character field of view or non-character client  102  information such as busy signals. Flow then continues to block  406  and server  104  receives new client information from clients  102 . Returning to block  410 , if the error does not exceed the threshold flow continues to block  406  and server  104  receives new client information  102  from clients  102 . 
       FIG. 5  is a flow chart illustrating an example of dead reckoning by a client  102 . Flow begins in block  502  where the client  102  sends it&#39;s client information to server  104 . Flow continues to block  504  where a client  102  receives the client information of other clients  102  from server  104 . In block  506  client  102  calculates the position of the characters on other clients  102  using dead reckoning. Flow continues to block  510 , where client  102  checks to see if server  104  has sent update information, in the form of an update message, for any of the other clients  102 . If update information has been received, flow continues to block  512  where the client information for that client  102  is updated. Flow then continues to block  506 . Returning to block  510 , if no update information has been received, then flow continues to block  506 . 
       FIG. 6  is a block diagram of another exemplary system configured for on-line gaming consistent with embodiments of the present invention. As illustrated in  FIG. 6 , there is no server involved in the game. This configuration may be referred to as a peer-to-peer network since a plurality of clients  102  are communicating directly with each other. As such, this configuration is often called a peer-to-peer gaming configuration. In this example, clients  102  exchange their client information directly to each other over network  106 . Then each client  102  calculates each of the other clients  102  character&#39;s position using dead reckoning. In addition, each client  102  may calculate it&#39;s own character&#39;s position using dead reckoning. When a client  102  determines that an error between its character&#39;s actual position, and the position as calculated by dead reckoning, exceeds a threshold for another client  102 , the client  102  may then send updates of their client information to that other client  102 . 
       FIG. 7  is a flow chart illustrating another example, consistent with one embodiment of the present invention, of dead reckoning by a client  102 . Flow begins in block  702  where a client  102  sends it&#39;s client information to another client  102 . Flow continues to block  704  where the client  102  receives client information from the other clients  102 . In block  706  the client  102  calculates their character&#39;s position, and the positions of characters on other clients  102  using dead reckoning. Flow continues to block  708 , where the client  102  checks to see if the error in their character&#39;s actual position compared to the position calculated by dead reckoning, exceeds a threshold for any other client  102 , in the form of an update information message. If it does, then flow continues to block  710  and the client  102  sends its update client information to the other clients  102 . Flow then continues to block  712 . Returning to block  708 , if the error does not exceed an error threshold, flow continues to block  712 . In block  712  the client  102  checks to see if client  102  update information has been received from any of the other clients  102 . If update information has been received, flow continues to block  714  where the client  102  information is updated. Flow then continues to block  706 . Returning to block  712 , if no client  102  update information has been received, then flow continues to block  706 . 
       FIG. 8  is a block diagram of an exemplary embodiment of a server  104  in a multi-client game system. As shown in  FIG. 8 , server  104  includes a network interface  804 . In one embodiment, network interface  804  is adapted to receive client information from a client  102  over the Internet or other network  106 . The network interface  804  also sends its client information to other clients  102  on the network  106 . Additionally, server  104  and network interface  804  are configured to receive client information from clients  102  throughout the duration of the game. 
     Server  104  additionally comprises a processor  806 . The processor  806  may be configured to calculate a dead reckoning position for each client  102  in the multi-client game. The processor  806  may also calculate an error based on a calculated dead reckoning position and an actual position received from a client  102 . Server  104  may also determine if an error between the calculated dead reckoning position and an actual position for each client  102  exceeds a threshold for any other client  102  on the network  106 . If server  104  determines an error threshold is exceeded it may direct network interface  804  to send update client information to clients  102  whose errors exceed the threshold level for the other clients  102 . 
       FIG. 9  is a block diagram of an exemplary embodiment of a client in a multi-client game system. As shown in  FIG. 9 , client  102  includes a network interface  804 . In one embodiment network interface  804  is adapted to send client information to server  104  and to receive client information of other clients  102  from server  104 . The client information may be sent and received over the Internet or any other network  106 . In another embodiment, a peer-to-peer configuration as discussed above, network interface  804  may be configured to send client information directly to other clients  102  on network  106  and receive client information directly from other clients  102  on network  106 . 
     Client  102  also includes a processor  806 . Processor  806  may be adapted to calculate a dead reckoning position for each client  102  in the multi-client game. Processor  806  may also be adapted to determine if update client information has been received from server  104 , and update client information for a client  102  in response to update client information received from server  104 . In an alternate embodiment, processor  806  may be configured to determine if update client information has been received from another client  102 . In this embodiment, if update client information is received processor  806  may update client information based on the received information for the other client  102 . 
     In another embodiment, processor  806  may be adapted to calculate a dead reckoning position for its character and the characters of other clients  102  on the network  106 . Additionally, processor  806  may be configured to calculate an error based on the calculated dead reckoning position and the actual position of a character for the client  102  and other characters of clients  102  on the network  106 . In one embodiment, if a calculated error exceeds a threshold level for any given client  102 , processor  806  may direct network interface  804  to send update client information to the other clients  102 . 
     Thus, it is seen that apparatus&#39; and methods for communicating client data in a multi-client gaming network are provided. One skilled in the art will appreciate that the present invention can be practiced by other than the above-described embodiments, which are presented in this description for purposes of illustration and not of limitation. The specification and drawings are not intended to limit the exclusionary scope of this patent document. It is noted that various equivalents for the particular embodiments discussed in this description may practice the invention as well. That is, while the present invention has been described in conjunction with specific embodiments, it is evident that many alternatives, modifications, permutations and variations will become apparent to those of ordinary skill in the art in light of the foregoing description. Accordingly, it is intended that the present invention embrace all such alternatives, modifications and variations as fall within the scope of the appended claims. The fact that a product, process or method exhibits differences from one or more of the above-described exemplary embodiments does not mean that the product or process is outside the scope (literal scope and/or other legally-recognized scope) of the following claims.