U.S. Pat. No. 9,674,267

DETAILED DESCRIPTION OF THE DRAWINGS

Although the following detailed description contains many specific details for the purposes of illustration, anyone of ordinary skill in the art will appreciate that many variations and alterations to the following details are within the scope of the present disclosure. Accordingly, the aspects of the present disclosure described below are set forth without any loss of generality to, and without imposing limitations upon, the claims that follow this description.

Aspects of the present disclosure describe apparatuses and methods for hiding the latency in a multiplayer game played over a network. The multiplayer game may comprise an attacker and a defender. The attacker may be playing the game on a first client device platform, and the defender may be playing the game on a second client device platform. Both client device platforms may be connected over a network. According to aspects of the present disclosure, the attacker may initiate one or more attacking animations. The first client device platform may predict that the one or more attacking animations will result in a successful hit on the defender. When a positive prediction is made, the attacker's client device platform may generate a hit-event. The hit-event may comprise the one or more initiated attack animations, and a unique hit identifier (ID) that will be used to track the results of the one or more attack animations. The hit-event may then be stored in a hit table on the attacker's client device platform and delivered to the defender's client device platform over the network connection. The playback rate of the one or more attack animations may be slowed down on the attacker's client device platform in order to lengthen the available time in which the attacker's client device platform may receive a response from the defender's client device platform to indicate whether the attack was indeed a successful one as predicted.

Upon receiving the hit-event, the defender's client device platform stores the information in a hit table and then determines if the one or more attack animations result in a successful attack on the defender. By way of example, the defender's client device platform may determine that the attack was a hit, a miss, or a blocked attack. The defender's client device platform then generates a hit-response that comprises the appropriate one or more response animations and the same hit ID that was associated with the hit event. The hit-response is stored in the hit table and is also delivered to the attacker's client device platform over the network connection. Once received by the attacker's client device platform, the hit response is stored on the attacker's hit table as well. The attacker's client device platform may then execute the reply animations that were identified in the hit-reply.

Aspects of the present disclosure describe how the apparatuses and methods respond to differences in the length of the latency. Before the hit-event is delivered by the attacker's client device platform, the attacker does not know how long the latency will be, and therefore needs to be able to accommodate any potential outcome. The following steps implemented by the attacker's client device platform depend on whether the hit-reply is received by the attacker: (1) during a pre-hit period; (2) after the pre-hit period; or (3) after an extended hit-pause period (or never received).

According to instances of the present disclosure if the hit-response is received during the pre-hit period the attacker's client device platform buffers the response animations for playing at the point of impact between the attacker and the defender. According to certain instances of the present disclosure if the hit-response is received after the pre-hit period, the attacker's client device platform may implement an extended hit-pause period that may last for a predetermined length of time. This allows for more time to allow the hit reply to be received by the attacker's client device platform. Once the attacker's client device platform has received the hit reply, it may be stored in the attacker's hit table and the reply animations may be implemented after at least the standard hit-pause period has been completed.

According to certain instances of the present disclosure if the hit response has not been received before the predetermined maximum length of time, the attacker's client device platform may timeout. When the attacker's client device platform times out, all data in the hit table relating to the hit ID that did not receive the hit reply may be removed. Additionally, the reply animation may be replaced with a timeout animation. The timeout animation may depict a missed attack.

Aspects of the present disclosure further describe apparatuses and methods that provide seamless animation during the transition between the one or more attack animations and the one or more reply animations. This is critical because the attacking machine and the defending machine may execute the animations at different times due to the latency between the machines. In order to ensure that the attacker's animations remain in phase with the defender's animations, the attacker's client device platform utilizes information from the attacker's hit table. First, upon reading the table, if the client device platform detects that he should be in a hit-pause period as a result of any hit-event, then the client device platform will insert a pause at the first frame of the reply animation. Thereafter, the pause will be ended (and the reply animation will resume once the attacker's client device platform determines that both: (1) the hit-pause is complete according to the attacker's client device platform; and (2) the attacker's client device platform has received an indication that the defender is un-paused as well.

In other words, the reply animation is buffered and played on both attacker and defenders machine at the point of impact, e.g. the end of pre-hit, if it is available. The reply animation may remain paused on the first frame of this animation in the common case. The reply animation may then “unpause” after the hit reply and resume playing. This is important since game may look considerably worse if the hit reply animation does not have the first frame play at the point of hit.

Additional aspects of the present disclosure describe similar apparatuses and methods as described above with the addition of an observer, and an observer's client device platform. The addition of the observer requires that the hit-event and the hit reply be sent to the observer as well. Additionally, the observer may implement a seamless transition between the attacking animations and the reply animations in a manner substantially similar to that of the attacker's client device platform.

FIG. 1is a block diagram depicting three different client device platforms102,103, and104that may be able to communicate with each other over a network160. Each client device platform may be used by one or more game players at any given time. For simplicity, aspects of the present disclosure will depict each client device platform as having a single game player, but it should be evident to one of ordinary skill in the art that two or more players may be playing the game from a single client device platform. According toFIG. 1there is a client device platform102that is associated with an attacking player, a client device platform103associated with a defending player, and a client device platform104associated with an observing player. As used herein, client device platform102may be referred to as the “attacker”, client device platform103may be referred to as the “defender”, and client device platform104may be referred to as the “observer”. In instances where two or more game players are playing on a single client device platform, the labels “attacker”, “defender”, and “observer” may be specific to the individual game players and not used to define the client device platform as a whole.

The attacking player's platform102may include a central processor unit (CPU)131. By way of example, a CPU131may include one or more processors, which may be configured according to, e.g., a dual-core, quad-core, multi-core, or Cell processor architecture. Attacker102may also include a memory132(e.g., RAM, DRAM, ROM, and the like). The CPU131may execute a process-control program133, portions of which may be stored in the memory132. The attacker102may also include well-known support circuits140, such as input/output (I/O) circuits141, power supplies (P/S)142, a clock (CLK)143and cache144. The attacker102may optionally include a mass storage device134such as a disk drive, CD-ROM drive, tape drive, or the like to store programs and/or data. The attacker102may also optionally include a display unit137. The display unit137may be in the form of a cathode ray tube (CRT) or flat panel screen that displays text, numerals, or graphical symbols. A controller145may be connected to the attacker102through the I/O circuit141or it may be directly integrated into the attacker102. The controller145may facilitate interaction between the attacker102and a game player who may control the gameplay. The controller145may include a keyboard, mouse, joystick, light pen, hand-held controls or other device. The attacker102may include a network interface139, configured to enable the use of Wi-Fi, an Ethernet port, or other communication methods.

The network interface139may incorporate suitable hardware, software, firmware or some combination of two or more of these to facilitate communication via an electronic communications network160. The network interface139may be configured to implement wired or wireless communication over local area networks and wide area networks such as the Internet. The attacker102may send and receive data and/or requests for files via one or more data packets over the network160.

The attacker's platform102may access a game program106that has a multi-player functionality. There may be more than one game program106stored in the attacker102. The game programs may be stored in the memory132or in the mass storage device134. Additionally, one or more game programs106may be stored at a remote location accessible to the attacker102over the network160. Each game program106contains executable game code that is used by the CPU131to generate animations in response to inputs provided by the game player.

The preceding components may exchange signals with each other via an internal system bus150. The attacker102may be a general purpose computer that becomes a special purpose computer when miming code that implements embodiments of the present invention as described herein. By way of example, and not by way of limitation, the attacker102may be Sony Computer Entertainment's PlayStation 3 console, a PlayStation Vita hand-held console, a home computer, a cellular phone, or any other similar device capable of playing multi-player video games over a network.

The defending player's platform103may be a device substantially similar to that of attacker102. Elements of the defending players platform103that correspond to like elements of the attacker's platform102are denoted by the same reference numeral with a single prime (′) appended. However, it should be noted that the specific embodiments may be different, e.g., the attacker's platform102may be a PlayStation 3 console, and the defender's platform103may be a PlayStation Vita hand-held console. Additionally, the observer's platform104may be a device substantially similar to the defender's platform103and the attacker's platform102. Elements of the observer's platform104that correspond to like elements of the attacker's platform102are denoted by the same reference numeral with a double prime (″) appended. Again, the specific embodiments of the observer's platform104may differ from those of the attacker102and the defender103. WhileFIG. 1only depicts three client device platforms, one each of the attacker102, defender103, and observer104, additional aspects of the present disclosure include systems with a larger or smaller number of client device platforms. By way of example, and not by way of limitation, there may only be an attacker102and a defender103when there are only two game players playing the game106, there may be two or more observers104who are each observing the interactions between the attacker102and the defender103, there may be multiple defenders103if an attacker102is attacking multiple opponents at the same time, there may be multiple attackers102, if a defender103is being attacked by two or more opponents at the same time, or any combination thereof.

Aspects of the present disclosure allow for peer-to-peer gaming. Each client device platform may be associated with an avatar, i.e., the attacker102is associated with an attacker avatar, the defender103is associated with a defender avatar, and the observer104is associated with an observer avatar. Each client device platform may deliver state and event information associated with their respective avatars to the other client device platforms. By way of example, and not by way of limitation, the state information may include positions and movements of the avatar. By way of example, and not by way of limitation, the event information may include attack animations, such as swinging a club or punching, defensive animations, such as blocking or other evasive maneuvers, and reply animations that result from a successful attack, such as falling to the ground or being shoved backwards. The state and event information may be delivered by each client device platform at normal intervals, such as 30 packets per second. When displaying the gameplay on their respective display units137, a client device platform will utilize the state and event information to display proxies of the other avatars. For example, the attacker's avatar may be displayed on the attacker's display unit137according to the state and event information generated by the attacker102, and the proxy avatars for the observer avatar and the defender avatar may be displayed on the attacker's display unit137in accordance with the state and event data that has been broadcast to the attacker102from the respective client device platforms for the observer104and defender103.

Specifically, with respect to aspects of the present disclosure, event information related to attack animations and reply animations are discussed. Hiding the latency in the delivery of these events allows for gameplay that is fair to the game players and allows for more seamless animations.FIGS. 2A-2Care block diagrams that depict how hit events230and hit replies231are delivered and stored by the respective client device platforms102,103, and104.

A hit event230may be generated by an attacker102once the attacker predicts that the one or more animations will likely result in a successful attack. In general the prediction of a successful attack may be made by looking ahead in the animation to determine whether or not the attacker will connect with any of the collision volumes on the attacker. By way of example, the prediction may be made by assuming that the positions of the attacker and defender are stationary. From this starting assumption, the future path of the attacker's weapon, such as, but not limited to, a sword, a club, or a fist, is determined to see if at any frame after the initiation of the animation, there will be a collision between the attacker and the defender. The attack animation may be advanced frame-by-frame from a current time to a pre-hit time and at each frame the attacker's platform102may check for prediction of the collision with the defender. Hit events230may comprise the one or more attack animations that are predicted to result in a successful attack and a corresponding hit identification (ID). The hit ID is a unique identifier that may be used by each of the client device platforms102,103, and104to track the animations. In order to provide a unique identification, the hit ID may comprise an 8-bit random access memory (RAM) component and an 8-bit modulo component. The first hit event230may have a modulo component of “1” and each subsequent hit event230may be incrementally increased by 1. By way of example, a series of hit IDs may be {RAM-1, RAM-2, RAM-3, RAM-4 . . . }, where RAM is a random 8-bit number.

InFIG. 2Athe attacker102has predicted that one or more actions of the attacker's avatar will likely result in a successful attack on the defender's avatar. Therefore, a hit event230has been generated. The hit event is stored in a hit table235located in the attacker102. By way of example, the hit table235may be located in the memory132. The hit table235is used to associate the hit event230with a hit reply231that may be received from the defender103in the future. Additionally, the attacker102delivers the hit event230to the defender103and he observer104over the network160, as indicated by the dashed arrows.

InFIG. 2Bthe observer104and the defender103have received the hit event230and stored it in their respective hit tables235. The observer104should preferably receive and store the hit event230in order for the observer104to properly display the attack and response animations on its display unit137″. The information stored in the observer's table235will indicate when animations, such as a hit pause should be initiated and ceased.

In addition to storing the hit event230in its hit table235, the defender103may also resolve whether the one or more attack animations correspond to a successful attack. The problem of defenders103being harmed when they were already protected from an attack, as may be the case in the prior art, is prevented by resolving the success of an attack on the defender103. Instead of relying on proxy information that may not reflect the most recent position of the defender's avatar (as might occur if the attack was resolved by the attacker102) the one or more attack animations are resolved using the most current state and event information available to the defender103. After resolving the attack, the defender103may generate a hit reply231. The hit reply231is stored in the defender's hit table235and is also delivered over the network to the attacker102and the observer104. The hit reply may comprise information identifying one or more reply animations and the same hit ID that was associated with the hit event230. The one or more reply animations will correspond to the result of the attack. For example, if the one or more attack animations were determined to result in a successful attack, then the one or more reply animations may include animations that show the defender's avatar falling to the ground or being knocked backwards. Alternatively, if the attack was determined to be unsuccessful, the reply animation may include the defender's avatar blocking the attack, or avoiding the attack altogether. Since the hit event230is resolved immediately upon receipt by the defender103, any blocking or avoidance actions initiated by the defender103after the receipt will not alter the result of the attack. The hit event230may be received before there is contact between the attacking and defending avatars, and therefore, it may be desirable to disable subsequent blocking or avoidance animations of the defender's avatar once the hit event230has been received. This will prevent the game player controlling the defending avatar from feeling like they were hit even though they were in the middle of a blocking motion.

InFIG. 2Cthe attacker102and the observer104have received the hit reply and have stored the data in their respective hit tables235. The attacker102and the observer104may now be able to display the entire interaction between the attacker's avatar and the defender's avatar. The transmission of the hit event230and the receipt of the hit reply231must take place before the attack animation initiated by the attacker102has been completed in order for the animation to appear seamless. When latency is large enough that the data cannot make a round trip between the attacker102and the defender103before the attack animation is completed, the game play suffers. Therefore, the ability to hide the latency allows for improved gameplay in a multiplayer setting.

Aspects of the present disclosure hide latency with the use of one or more animation alteration modes.FIG. 3Ais a standard attack timeline300in a system that does not utilize latency hiding techniques.FIGS. 3B-3Ddepict examples of extended attack timelines301,301′, and302that utilize altered attack animation modes in order to hide latencies according to aspects of the present disclosure. It should be noted that the timelines depicted inFIGS. 3A-3Dare not to scale. InFIG. 3A, the standard timeline300begins when one or more attack animations are initiated at310. By way of example, an attack animation may be when an avatar controlled by the attacker102begins swinging a club at an avatar controlled by the defender103. The time period after the attack animation has been initiated at310and before contact between the attacker's avatar and the defender's avatar is made at312is defined as the pre-hit period311. The pre-hit period311may be a variable length of time depending on factors such as, but not limited to, weapon type, distance between avatars, power of the attack, strength of the attacking avatar, or any combination thereof. By way of example, and not by way of limitation, the pre-hit period311may be approximately 100 ms. In this case, where no latency hiding techniques are implemented, the hit reply231is received by the attacker102before the end of the pre-hit period311. Once the hit reply231has been received, a reply animation314is buffered so it may be initiated once the contact point312has been reached. The playback rate of the first frame of the reply animation314may be substantially reduced or even paused for a brief period of time in order to produce a hit-pause effect. The length of the hit-pause effect is considered the hit-pause period313. The hit-pause period313may be a variable length of time depending on factors such as, but not limited to, weapon type, distance between avatars, power of the attack, strength of the attacking or defending avatar, size of the attacking or defending avatar, or any combination thereof. By way of example, and not by way of limitation, the playback rate of the first frame of the reply animation may be slowed down to a small but non zero value, e.g., to about 1/1000 of normal speed. After the end of the hit-pause period313, the reply animation314may resume a normal playback rate. In an ideal case the hit reply animation may be initiated on attacker and observer machines at the point of hit, e.g., at end of the pre-hit but before hit pause.

FIG. 3Bdepicts an extended attack timeline301that incorporates an altered animation mode according to aspects of the present disclosure. Timeline301is substantially similar to that of the attack timeline300with the exception that the pre-hit period311is replaced with an extended pre-hit period315. The extension of the pre-hit period311provides additional time for the attacker102to receive the hit reply231before contact between the attacker's avatar and the defender's avatar is made at312.

The extended pre-hit period315is substantially similar to pre-hit period311with the exception that the playback rate of the extended pre-hit period315is slowed down compared to the playback rate of the pre-hit period315. As the playback rate of the extended pre-hit period is decreased, the amount of latency that may be hidden is increased. However, decreasing the playback rate of the extended pre-hit period311too much may result in attack animations that appear sluggish and unresponsive to the game player. The limit of how much the playback rate of the extended pre-hit period315may be reduced is dependent on the type of game, and the expectations of the players playing the game. By way of example, in a combat type game the playback rate of the extended pre-hit period315may be approximately two-thirds of the playback rate of the pre-hit period311without the animations appearing sluggish and unresponsive. As such, a pre-hit period311that lasts 100 ms may have an extended pre-hit period315that lasts approximately 150 ms. Ideally, the additional 50 ms is sufficient to provide time to receive the hit reply231before the contact between the attacker's avatar and the defender's avatar is made at312.

However, if the hit reply231is not received before the contact point312, then the hit-pause period313may also be used as an additional length of time to hide the latency as shown inFIG. 3C. Before entering into the hit pause period313, the attack animation310may be paused at or just prior to the contact point312. At some point into the hit-pause period313the hit reply231may be received. Once received, the reply animation314may be initiated at a reduced playback rate, such as a playback rate of about 1/1000 of normal speed. The reduced playback rate during hit pause is sufficiently slow that the animation is effectively “paused”. For example, slowing the animation to one-half of normal speed may be too fast. A playback rate greater than zero (e.g., 1/1000 of the normal rate) is desirable so long as it is slow enough that the animation is practically paused. However, a very slow (as opposed to zero) rate of playback may be desirable for visual effect. A slowed animation may look better than one that is completely stopped. After the hit-pause period313has ended, the reply animation314may continue at the normal playback rate.

It is noted that during the hit pause period the animation of the defender platform103may also freeze. The defender may also play a hit reply animation, e.g., corresponding to “getting hit” or “blocking” and the first frame of the defender's reply animation may freeze (e.g., timescale at 1/1000 normal speed, as with the attack animation) for visual impact during the hit pause period.

Extended timeline302inFIG. 3Dprovides an additional aspect of the present disclosure that provides even more time for hiding the latency if the hit reply231has not been received by the end of the hit-pause period313. In this circumstance, the altered animation mode may further comprise a supplemental hit-pause period316. The supplemental hit-pause period316extends the length of the original hit-pause period313in order to allow for additional time for the hit reply231to be received by the attacker102. The supplemental hit-pause period316may be an unlimited amount of time. In this case, the supplemental hit-pause period may be not end until the hit reply231is received. However, if the amount of time used for the supplemental hit-pause316is too great, the gameplay may become overly sluggish and unresponsive. Typically, the supplemental hit-pause316may provide an additional 200-300 ms before the pause becomes too distracting to the game player. If by the end of the supplemental hit-pause period316, there still has not been a hit reply231, then the attacker102may assume that a hit reply231will never come. In this instance, the attacker102may timeout. When the attacker102timeouts, the attacker will erase all data in its data table that corresponds to the hit ID that was not responded to and unpause from the supplemental hit-pause period316. At the unpause, a timeout animation314′ may be initiated. By way of example, and not by way of limitation, the timeout animation314′ may be a continuation of the attack animation resulting in a missed attack.

An additional aspect of the present disclosure involves the process of exiting the hit-pause period313(or, if needed, the supplemental hit-pause period316) in a manner that allow for the reply animation for both the attacking and defending avatars to be synchronized. Due to the latency that has been hidden, there may be instances where the defender103initiates the reply animation period314before the attacker102or the observer104initiates the response animation period314. In such situations, the proxy avatar of the defender103may be shown as moving on the attacker's display unit137before the attacker's avatar has begun the reply animation period314. This scenario creates a disjointed animation and is undesirable. In order to ensure that the transition from the hit-pause period313(or the supplemental hit-pause period316) to the reply animation period314occurs at the same time for both the local avatar and the proxy avatar, the client device platform should not make the transition until it has received confirmation that both the attacker's avatar and the defender's avatar have reached the transition point.

From the perspective of the defender103the determination of when to un-pause from and begin the reply animation period314is relatively simple. If the defender103determines that an attack has been successful, and the one or more attack animations included in the hit event230include an instruction to implement a hit-pause period313, then the defender103will initiate the hit-pause period313. There is no need to add in a supplemental hit-pause period316because there is no latency that needs to be hidden, because no additional information is needed by the defender103to initiate the reply animation. Once the hit-pause period313is completed, the defender103may initiate the reply animation period314for both the local avatar (i.e., the defender's avatar) and the proxy avatar (i.e., the attacker's avatar).

In order for the attacker102to determine if it can make the transition from the hit-pause period313(or the supplemental hit pause period316) to the reply animation period314the attacker102needs to know that both: (1) the state and event information in the attacker's hit table235indicates that the defender's proxy avatar is no longer in the hit-pause period313; and (2) that the attacker102is no longer in the hit-pause period313or a supplemental hit-pause period316. If either one of the two conditions is not met, then the attacker102must remain paused. Therefore, the transition from the hit-pause period313to the reply animation period314may occur as a result of two separate scenarios.

According to the first scenario, the attacker102may determine that the hit-pause period313for his avatar has been exceeded and is awaiting a response from the defender103that indicates that the defender's avatar has exited the hit-pause period313as well. The indication that the defender's avatar has exited the hit-pause period313may be delivered as part of the state information that is broadcasted to each client device platform. Once the attacker102receives an update that indicates the defender's avatar has un-paused, then the attacker102may un-pause as well. The first scenario typically occurs when the hit reply231is received before the end of the extended pre-hit period315.

The second scenario typically occurs when the attacker102needs to add a supplemental hit-pause period316in order to allow for a longer latency. In this situation, the defender103may have already transitioned from the hit-pause period313to the reply animation period314. Even though the defender103may be broadcasting to the other client device platforms that he is un-paused, the defendant's proxy avatar displayed on the attacker's display unit137may be kept in a frozen state because the attacker102has not yet received the updated state information in the hit reply231due to latencies in the system. Additionally, while in a hit-pause period the attacker102may ignore normal position updates broadcast from the defender103. Therefore, the defender's local avatar (i.e., the position of the defender's avatar as displayed on the defender's display unit137′) may have already begun moving backwards, even though the defender's proxy avatar (i.e., the position of the defender's avatar as displayed on the attacker's display unit137) is still frozen. The transition to the reply animation period314may then be made once the attacker102receives an update that the hit-pause period313is completed according to the information in his hit table235. When the attacker102finally does make the transition to the reply animation period314, the defender's local avatar and the defender's proxy avatar may be in different positions. Therefore, the attacker102may implement one or more actions in order to unite the locations of the defender's proxy avatar and the true position of the defender's local avatar. By way of example, and not by way of limitation, after the attacker102has completed the supplemental hit-pause316, the attacker102may interpolate a trajectory from the incorrect position (i.e., where the defender's proxy avatar is located during the hit-pause) that will quickly cause the proxy avatar of the defender to converge with the location and trajectory of the defender's local avatar. The conditions needed for making the transition from the hit-pause period313to the reply animation period314with respect to the observer104are substantially similar to that of the attacker102.

While in hit pause on all machines for which the defender is a remote proxy object (attacker and observer machines), normal position updates from the defender machine may be ignored while hit paused. Then when the hit pause is completed, the normal interpolation from the current position to the newly updated position quickly interpolates from the incorrect position, back into the trajectory that the defender has been put on as a result of the outcome of the attack. This may be implemented by a physical position update where we tween the paused position to the path of the defender resulting from the hit. Position updates are commonly used in game a to synchronize player movement. Basically, on the defenders machine, the defender has already reacted to the hit. On the attacker's machine the defenders reaction is delayed until the attacker's machine unpauses. As an illustration of this, imagine a baseball bat hitting a baseball crisply. The baseball (defender) is already flying in the air from the baseball's point of view. The baseball is kept frozen on the bat at the batter's (attacker's) machine until the batter's machine is ready to unpause the hit pause. Then as the baseball flies through the air on the batter's machine the baseball's position is interpolated such that it rapidly converges with the path of the baseball already flying through the air on the baseball's machine.

The previously described mechanisms for transitioning from a hit-pause period313(or a supplemental hit-pause period316) to the reply animation period314also apply when there are multiple hit events230and hit replies231outstanding. In many multi-player games a single game player may be both an attacker and a defender at any given time, or they may be attacked by a plurality of other players at the same time. Therefore, when determining whether to make the transition from a hit-pause period313to a reply animation period314, it is important to analyze all outstanding hit-pause periods313and supplemental hit-pause period316. For example, if you are an attacker102who has delivered a single hit event230to a defender103, but the defender103has been attacked by other players at approximately the same time, then you may need to wait until the defender102has indicated that they have exited all of the hit-pauses from the proximate attacks before you exit the hit pause period313as well.

As shown inFIG. 4, the attacker102and the defender103may be configured to implement a method for hiding latencies in a multi-player game according to an inventive method400. Various aspects of the method400may be implemented by execution of computer executable instructions running on the attacker102the defender103and/or the observer104. Specifically, an attacker102may be configured, e.g., by suitable programming, to implement certain attacker instructions481. In addition, a defender103may be configured to implement certain defender instructions482. Further, an observer104may be configured to implement certain observer instructions483. InFIG. 4the dashed arrows represent the flow of data between the attacker102, the defender103, and/or the observer104over the network160.

Initially, at484the attacker102may predict that one or more attack actions initiated by the attacker102will likely result in a successful attack against the defender103. Thereafter, the attacker102may generate a hit event230at block485. The hit event may comprise the one or more attack actions and a unique hit ID. Additionally, the hit event230may be stored in a hit table235located on the attacker102. The attacker102may then deliver the hit event230to the defender103and the observer104at block486. In order to provide more available time for hiding potential latencies in the data transfers between the attacker102and the defender103, the attacker may initiate an altered animation mode at488. The altered animation mode may comprise utilizing an extended hit-pause period315and/or adding a supplemental hit-pause period316after the hit-pause period313has expired if more time is needed to hide latency. While the attacker102is in the altered animation mode, the defender103may receive the hit event230at block487. The defender103may also store the hit event230in a hit table235located on the defender. Similarly, the observer104may receive event230at block487′ and store the hit event on a local hit table235. Upon receipt of the hit event, the defender103may determine if the hit event230will result in a successful or unsuccessful attack on the defender103at block489. After resolving the hit event230, the defender may generate a hit reply231at block490. The hit reply230may comprise information identifying the one or more reply animations that should be displayed in accordance with the success or failure of the one or more attack animations. The hit reply231may further comprise the hit ID that was associated with the hit event230. The defender102may also store the hit reply in its local hit table235. At block491the defender103may then deliver the hit reply231to the attacker102and the observer104over the network160. The attacker102receives the hit reply231at block492and may store the hit event231in the attacker's local hit table235. Likewise, the observer104may receive the hit reply231at block492′ and may store the hit event231in the observer's local hit table235. The hit reply231may be received by the attacker102before the extended pre-hit period316has finished, during the hit-pause period313, during the extended hit-pause period316. If the hit reply231has not been received before the extended hit-pause period316has expired, then an assumed hit reply231′ may be generated by the attacker102. The assumed hit reply231′ may ideally, but not necessarily, assume that the one or more attack actions did not produce a successful attack. At block493, the defender103may execute the one or more reply animations in accordance with the information included in the hit reply231. At block494, the attacker102may execute the one or more reply animations in accordance with the information included in the hit reply231. At block494′ the observer104may execute the one or more reply animations in a manner substantially similar to that of the attacker102. For each of the client device platforms102,103, and104the transition from the hit-pause period313(or the extended hit-pause period316) to the reply animation period314may be made once they have determined that, according to their local information, the hit-pause period313(or the extended hit-pause period316) have completed, and that they have received the defender's102broadcast his local avatar has completed the hit-pause313period as well.

As shown inFIG. 5A, a set of attacker instructions581may be implemented e.g., by the attacker102. The attacker instructions581may be formed on a nontransitory computer readable medium such as a memory132or the mass storage device134. The attacker instructions581may also be part of the process control program133. At584the instructions may include instructions for predicting that a successful attack will be made against the defender102. Next, at585the attacker102may be instructed to generate a hit event230. The instructions581may then have the attacker102deliver the hit event230to the defender103and the observer104. Thereafter, the attacker102may be instructed to initiate an altered animation mode at588. At593the attacker may be provided with instructions for receiving a hit reply231from the defender103. Finally, the attacker102may be instructed to execute the one or more reply animations in accordance with the hit reply231at594.

As shown inFIG. 5B, a set of defender instructions582may be implemented e.g., by the defender103. The defender instructions582may be formed on a nontransitory computer readable medium such as a memory132′ or the mass storage device134′. The defender instructions582may also be part of the process control program133′. At587the defender instructions582may include instructions for receiving a hit event230from the attacker102. Upon receipt of the hit event230, the defender103may be instructed to resolve the hit event230locally in order to determine if the one or more attack actions that were included in the hit event230result in a successful or an unsuccessful attack against the defender103at589. Next, at590the defender103may be provided with instructions for generating a hit reply231. The instructions then may direct the defender102to deliver the hit reply231to the attacker102and the observer103at591. Finally, at493the defender103may be instructed to execute the one or more reply animations that may be present in the hit reply231.

As shown inFIG. 5C, a set of observer instructions583may be implemented e.g., by the observer104. The defender instructions583may be formed on a nontransitory computer readable medium such as a memory132″ or the mass storage device134″. The observer instructions583may also be part of the process control program133″. At587′ the observer instructions583may include instructions for receiving a hit event230from the attacker102. Thereafter, at592′ the observer104may be instructed to receive a hit reply231from the defender103. Finally, at594′ the observer104may be instructed to execute the one or more reply animations that may be present in the hit reply231.

While the above is a complete description of the preferred embodiment of the present invention, it is possible to use various alternatives, modifications and equivalents. Therefore, the scope of the present invention should be determined not with reference to the above description but should, instead, be determined with reference to the appended claims, along with their full scope of equivalents. Any feature described herein, whether preferred or not, may be combined with any other feature described herein, whether preferred or not. In the claims that follow, the indefinite article “A”, or “An” refers to a quantity of one or more of the item following the article, except where expressly stated otherwise. The appended claims are not to be interpreted as including means-plus-function limitations, unless such a limitation is explicitly recited in a given claim using the phrase “means for.”