U.S. Pat. No. 9,814,967

DETAILED DESCRIPTION OF THE INVENTION

In the following description of the various embodiments, reference is made to the accompanying drawings, which show by way of illustration various exemplary embodiments that practice the disclosed invention. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope of the present invention.

FIG. 1shows an exemplary multiplayer gaming system suitable for describing the present multiplayer time flow adjustment system. Multiple players10a-xparticipate in a combined multiplayer game. The players access the game through a gaming system, such as a personal computer, dedicated gaming console, arcade gaming unit, mobile gaming device, mobile device or other suitable computing environment, which are in communication with one another to play a game. Each of these gaming systems provides the players a view on the virtual game environment. In some cases, a game system might provide multiple views on the virtual game environment for two or more players through a split screen, multiple screens or some other mechanism. Through this hardware the players each control game characters in the virtual game environment. The game is embodied in gaming code running on the gaming system, networked computers, or some combination thereof.

FIGS. 2a-cdemonstrate the basic concept of a time slowing game mechanic.FIG. 2ashows the basic timing of a successful event for a video game. The event has a start e-s and an end e-e with some time in between the start and the end. The event in this context is anything that requires the player to react within some limited period. The bar20shows the player's reaction to the event. The player perceives the event20p, the player decides a course of action20dand the player takes some action20a. While these different parts are shown serially for the sake of simplicity, they often may overlap in varying degrees. Ultimately, if the player takes the proper action before the event end, the player succeeds in its task. Applying this to a concrete example, assume the game play for the game at issue involves enemy characters that try to kill the player's character and teammate characters that are on the same side as the player. The event start might be involve the player coming into the vicinity of another character. The player must see the other character20p, decide if the character is friend or foe20d, and, if the character is an enemy, manipulate the game's user interface to attack and defeat the enemy20a.FIG. 2ashows the successful accomplishment of such an event. In contrast,FIG. 2bshows the actions of a player that did not have enough time to successfully accomplish the game event. Here the player took a long time before it perceived the other character. This did not leave it enough time to decide and act on the event before the event end e-e. Here the event end might be the enemy character defeating the player. Here the extra time needed, but unavailable is shown by cross-hatching.

FIG. 2cshows the advantage of using slow time mode in the context of theFIG. 2bevent. By engaging slow time mode, the actions of the video game are slowed to less than real time. For example, if game time were slowed to half real time, the events in the game would look like they are occurring in slow motion such that things take twice the amount of time they normally would. Thus, the time between the start of the event e-s and the end of the event e-e is extended. Because the game events are slowed the player now has enough time to defeat the enemy.

FIG. 3ashows the interaction of two players in a multiplayer game environment. Because the game characters in this scenario are both controlled by human players, there is not a strict event start and end. Instead, the engagement starts when the two players come into contact with one another. In this example player31clearly has the advantage in reaction time over player32. In particular, player32appears to be slower to sight and identify the required actions compared to player31. Thus, at normal game speed, player31completes the required actions first, e.g., sight, identify and target, and defeats player32.

If, however, player32engages slowed time mode, the engagement will play out as shown inFIG. 3b. Here time has slowed. And, because player32engaged the slowed time mode, the in-game character controlled by player31is disadvantaged and slowed with the game. Even though player31has fast reaction time and can sight and identify what needs to be done as quickly as before, the game character controlled by player31is limited to acting out the controlled instructions in slow motion. For example, the system might only accept input from the player at a slower rate commensurate with the slowed time. Or the player's inputs could be ignored completely. In a preferred embodiment, a player's inputs are filtered based on the timing of the in-game character's animation. This filtering is then extended in accordance with the slowed animation of the slowed time mode. In contrast, player31has the advantage of having the game system react to the control of his player in real time.

The display of the difference in reaction time between the party advantaged by slow time mode and the player disadvantaged by slow time mode can be embodied in a number of different ways. For example, the character controlled by the time slow advantaged player could continue to move at the same, real time, speed as the player's inputs. This, however, would make the advantaged player's in-game character appear to move with at unnaturally quick pace in the context of the game. This could be useful to implement a character with a “super power” that allows it to move at faster than other players. If, however, the game implementer does not want the game characters to appear to have unnatural speed, this approach may not be desirable. In that alternative, the game control inputs for the advantaged player can be collected in real time but the in-game character would move at the slowed pace. This still provides an advantage, however, because it gives the player ample time to execute the correct in game movements. A hybrid approach could also be employed. For example, certain aspects of the game's user interface, like aiming and firing, could be done in real time, while other aspects of the game like the character's dodging and running speed remain slow motion. This would be advantageous because the advantaged player's targeting and aiming user interface can only appear on the player's viewing screen for the game, giving them beneficial feedback to take advantage of the slowed time mode. But the large moments of the advantaged player's in-game character that are seen by other players remain realistically slowed.

FIG. 4ademonstrates the determination of which players experience slowed time mode and which do not. The figure depicts a birds eye view of in-game character positions in order to demonstrate the innovative aspects of the present disclosure. But the figure assumes that the game would be operating in a first or third person view. Accordingly, the circles show in-game characters each controlled by a player participating in the multiplayer game. The arrows show the direction the character is looking, or more specifically the direction shown to the players in their user interfaces for the game. The initiator of slow time mode, player I, is looking at player A. Player A is, therefore, placed into slow time mode. If player I is trying to attack player A, player I would now have the advantage of having more time to maneuver the controls to execute a successful attack on player A. Meanwhile, player B is looking at player I. Player B is, therefore, also placed in to slow time mode. Player B, however, is not given the benefits of increase reaction time because player B is not the initiator. Players C and D are not seen by, nor do they see, players I, A or B. Accordingly, players C and D are not placed in to slow time mode. The dotted line depicts the players that experience slow time mode.

FIG. 4bdemonstrates another example determination of players in slow time mode. Here players I, A and B are oriented as they were inFIG. 4aand are all in slow time play mode for the reasons discussed above. Player C, however, has turned its field of view towards player B thereby placing player C in slow time mode as shown by the dotted line. Player D is still neither sees any of the slow time mode players nor is D seen by any of those players. Accordingly, player D remains outside of slow time mode and continues to perceive in-game time flowing at the normal rate. In some embodiments, the determination of players in and out of slow time mode can change during the slow time mode event. For example, if the arrangement of players inFIG. 4bprogressed from the arrangement shown inFIG. 4a, player C could have been placed in slow time mode by turning such that player B came into player C's field of view. This same approach could, optionally, be used to allow players out of slow time mode when they look away from the effected players.

FIG. 4bshows three levels of slow time mode. The initiator is level 0. Players A and B are at level 1 because they either see player I, e.g., player B, or are being seen by player I, e.g., player A. Player C is at level 2 of the slow time mode network because player C is in slow time mode by virtue of seeing a player at level 1 of the slow time mode, e.g., player B. Considering the players in these levels demonstrates an effective coding mechanism for implementing slow time mode. Using a graph based coding structure to represent the players in slow time mode, allows players to be released from slow time mode when the node that connects them to slow time mode is released.

Players are tracked in-game via a synced visibility matrix. Each player locally performs line-of-sight probes to other players to determine if the other players are visible and creates a list of which players are currently visible to them. In a third-person game the visibility probes would include both the in-game character's position and the camera view). This process could require a large number of calculations. For example, in a third-person game involving 16 players, 480 visibility determinations must be made (each of the 16 players must determine the visibility of 15 other players in two views, 16×15×2=480). In order to limit the burden of performing all of these calculations on each of the players machines, each machine can perform a subset of the calculations and submit its results to a list that is synchronized in a distributed fashion with the other players in the game. Other mechanisms besides line of sight probes could be used to determine visibility checks. For example, the same visibility lists could be based on occlusion tests, 3D volume, or other methods pertinent to the game implemented to use the system.

FIG. 4cdemonstrates another example determination of players in slow time mode. This arrangement of players is similar to the arrangement ofFIG. 4b, but player D has now turned so that he sees player C. Accordingly, all of the players in the figure are now in slow time mode. Player D, however, is at level 3 of the slow time mode network. Player D's presence in slow time mode depends upon the initiator (level 0), player B (level 1), and player C (level 2). Player D would exit slow time mode if anyone at a lower level exited slow time mode. For example, if player B looked away from the initiator, player D's chain to the initiator would be broken and slow time mode would end.

FIG. 4ddemonstrates a further example determination of players in slow time mode. As shown a barrier between player B and the initiator prevents player B from seeing the initiator and being placed in slow time mode. Accordingly, players C and D are not placed in slow time mode as they were inFIG. 4c. Because players B, C and D do not see any players in slow time mode there is no discontinuity of their game play if they remain in normal time mode.

Visual discontinuity between players inside and outside slow time mode is a consideration when making a decision whether or not to place a player in slow time mode. Accordingly, the game designer may choose to base the decision on whether or not to place a player in slow time mode based on considerations relating to the relative visibility of the other players. For example, player B inFIG. 4eis within the line of sight of the initiator, but is mostly obscured by a barrio. If only a small piece of player B's in-game character is visible to the initiator there is little risk of a visible discontinuity. Similarly, player C is in the initiator's line of sight, but is relatively far away (depicted schematically as a smaller circle). If the player C is so far away that it only takes up a very small, e.g. negligible, portion of the initiator's field of view there is also a smaller risk of discontinuity. If the game implementer deems these potential discontinuities to be negligible, it can set a threshold for judging whether the in view conditions met. For example, if the other player only appears on a very small fraction of the screen it can be deemed effectively not visible and the player can be left out of slow time mode.

The need for a visibility threshold may be mitigated, and other advantages provided, by altering the impact of the slow time mode based on distance criteria. If a player is truly far away such that they are not very visible to the other affected players, the slow time mode is likely to have a limited effect on them. Thus, there is less of a negative trade off to having them included in the time slowing mode. The criteria for distance can be measured in a number of different ways. The impact of the slow time mode can be based on a straight-line distance from the initiator, see the dashed line50inFIG. 5. Or, the distance can be based on the straight-line distance from the player that caused the player to be slowed to be placed into slow time mode. Alternately, the distance can be measured based on the line of sight distance from the initiator, see series of dotted lines55ofFIG. 5. The significant differences between these two approaches are shown inFIG. 5. As shown, player D is close to the initiator in real physical terms, but is only subject to time slow mode due to a long and circuitous path. A designer can choose to base its time slowing function on whichever of these two paths best accomplishes the designer's game play intent. As a further alternative the time slowing effect can change so that it is reduced at each level of the time slow mode network, e.g., the effect is reduced by 10% for each additional level.

The following table shows pseudo code for an advantageous embodiment for determining slowed time effect fall-off by distance from the initiator.

Table: Effect Fall-Off by Distance

Comments:

// DistanceFromSource—distance from initator to player we need to calculate fall-off for

// GameTimeStep—game simulation time step

// MaxDistance—maximum slowed time distance at this distance the effect disappears completely

// DistanceDecayRate—distance decay rate of the effect

// CurrentSaturation—calculated saturation for affected player, always in range [0 . . . 1] (0—no effect, 1—maximum effect)

Code:

CurrentDistance=DistanceFromSource−GameTimeStep*DistanceDecayRate

if(CurrentDistance<0) then

CurrentDistance=0

end

DesiredSaturation=(MaxDistance−DistanceFromSource)/MaxDistance

if DesiredSaturation1 then

DesiredSaturation=1

end

float delta=DesiredSaturation−CurrentSaturation;

if(delta>=0) then

delta*=SaturationSmoothingRate^GameTimeStep; // takesSaturationSmoothingRate into power of GameTimeStep//CurrentSaturation=DesiredSaturation−delta;
End

A further advantageous embodiment is provided by gradually ramping up the time slowing effect as a player enters slowed time mode and ramping down the effect as a player exits slowed time mode. This avoids the jarring effect of abrupt changes to the player's experience of time flow. This also avoids a stuttering effect if another player's line of sight state is changing rapidly. This can be accomplished by having the slowed time effect engaged via an interpolation from one time rate to another.

As discussed with reference toFIG. 1, the multiplayer game system typically involves a number of player computing devices communicating over a network. The shared virtual world accessed by these various computing devices requires a common clock to execute and synchronize the various events in the world. The operation of this world clock, however, is complicated where different entities present in the world are experiencing the flow of time at different rates. For example, when two players meet in the virtual world their systems must record the same time, despite the fact that one of the players might have previously experienced a time slowing event.

This is particularly true in a multiplayer game environment where the game is operated in a distributed environment. In a distributed gaming environment, each of the player's computing device runs code executing a local copy of the shared virtual world. The multiple copies of the “shared” virtual world are kept consistent and synchronized by passing messages over the network describing the actions of the various players. These event messages include a virtual world time for synchronization purposes.

In an advantageous embodiment, the synchronization of the various world events occurring at different perceived time rates is maintained by slowing the world clock to the rate of the slowed time mode. UsingFIG. 4afor illustrative purposes, if the initiator engages slow time mode, players I, A and B are intended to experience the slow motion effect. If the time slowing effect implements slowing by a factor of 10, players I, A and B should see actions that normally take one second stretch out to take 10 seconds. Slowing the world clock used by the games physics engine to one 10thits normal rate will accomplish this. Note that while the world clock that describes the game entities motion through the virtual space is slowed, games display frame rate maintains its normal refresh pace. Thus, the characters appear to move in slow motion, rather than the game merely looking choppy.

Of course, if nothing else were done, all game entities would move in slow motion including players C and D, who were not intended to be impacted by slow time mode. Accordingly, to maintain the appearance of “normal” speed for these players, all their movements must be speed up by a factor of 10. For example, if player D's in game character was moving at 1 meter second prior to engagement of slow time mode, it must move at 10 meters second while in slow time mode.

In a further advantageous embodiment, the players in the multiplayer game can be organized into teams of cooperating players. When teams are provided the game implementer can decide to give teammates of the initiator the advantage of slow time mode when they are placed into slow time network created by the initiator. In other words, the initiator's teammates will be able to react like the initiator, rather than being slowed like the competitors.

In another embodiment, the speed of different game elements can be separately controlled to provide an optimized in game effect. As discussed above with respect to the adjustment of time slowing based on distance, time slowing can also be done on a game element by game element basis. For example, in a shooting game improved slowing enemy characters to a near standstill might be advisable so that they barely move and present easy targets. But, if dodging bullets or other projectiles is an intended part of the game play, slowing everything down to a near standstill will remove the dodging element from game play. To accommodate both of the above elements in slow time mode, the bullets or other projectiles can be sped up by an appropriate factor as was described above with respect to players far away from the slow time initiator. Movement of the initiator can also be sped up to allow dodging to occur. These varied speeds can also be structured to apply different factors to different elements of a in-game character's capabilities. For example, a player might be able to aim, shoot, look and run all at separate speeds to embody the game play desired by the developer. This flexibility can similarly be applied to give the initiator's teammates somewhat less than the full advantage of the imitator.

The entirety of this disclosure (including the Cover Page, Title, Headings, Field, Background, Summary, Brief Description of the Drawings, Detailed Description, Claims, Abstract, Figures, and otherwise) shows by way of illustration various embodiments in which the claimed inventions may be practiced. The advantages and features of the disclosure are of a representative sample of embodiments only, and are not exhaustive and/or exclusive. They are presented only to assist in understanding and teach the claimed principles. It should be understood that they are not representative of all claimed inventions. As such, certain aspects of the disclosure have not been discussed herein. That alternate embodiments may not have been presented for a specific portion of the invention or that further undescribed alternate embodiments may be available for a portion is not to be considered a disclaimer of those alternate embodiments. It will be appreciated that many of those undescribed embodiments incorporate the same principles of the invention and others are equivalent. Thus, it is to be understood that other embodiments may be utilized and functional, logical, organizational, structural and/or topological modifications may be made without departing from the scope and/or spirit of the disclosure. As such, all examples and/or embodiments are deemed to be non-limiting throughout this disclosure. Also, no inference should be drawn regarding those embodiments discussed herein relative to those not discussed herein other than it is as such for purposes of reducing space and repetition. For instance, it is to be understood that the logical and/or topological structure of any combination of any program modules (a module collection), other components and/or any present feature sets as described in the figures and/or throughout are not limited to a fixed operating order and/or arrangement, but rather, any disclosed order is exemplary and all equivalents, regardless of order, are contemplated by the disclosure. Furthermore, it is to be understood that such features are not limited to serial execution, but rather, any number of threads, processes, services, servers, and/or the like that may execute asynchronously, concurrently, in parallel, simultaneously, synchronously, and/or the like are contemplated by the disclosure. As such, some of these features may be mutually contradictory, in that they cannot be simultaneously present in a single embodiment. Similarly, some features are applicable to one aspect of the invention, and inapplicable to others. In addition, the disclosure includes other inventions not presently claimed. Applicant reserves all rights in those presently unclaimed inventions including the right to claim such inventions, file additional applications, continuations, continuations in part, divisions, and/or the like thereof. As such, it should be understood that advantages, embodiments, examples, functional, features, logical, organizational, structural, topological, and/or other aspects of the disclosure are not to be considered limitations on the disclosure as defined by the claims or limitations on equivalents to the claims.