U.S. Pat. No. 11,192,032

DETAILED DESCRIPTION

The present disclosure describes a number of methods and computerized systems for seamless session management of a multiplayer network gaming community. Since currently-available multiplayer gaming systems are deficient because they cannot support the interaction between unique sessions without increasing computational resources and/or restricting game development/design, a system for session management that provides a seamless session merging and splitting can prove desirable and provide a basis for a wide range of network applications, such as creating a realistic virtual world that is not limited by hardware and software limitations. This result can be achieved, according to one embodiment disclosed herein, by a session management system100as illustrated inFIG. 1.

Turning toFIG. 1, the session management system100is implemented between a network110(e.g., cloud) comprising a server115(e.g., a single server machine, multiple server machines, and/or a content delivery network) communicating with a plurality of player consoles101(shown as any number of player consoles101A-101N). A player console101can be any system with a processor, memory, capability to connect to the network, and capability of executing gaming software in accordance with the disclosed embodiments. A hardware and network implementation suitable for the disclosed system is described in greater detail in commonly assigned application Ser. No. 13/894,099, entitled “System and Method for Network Gaming Architecture,” incorporated herein by reference.

The player console101A is shown in further detail for illustration purposes only. As shown, the player console101can include any number of platforms102in communication with an input device103. For example, the platform102can represent any biometrics, motion picture, video game, medical application, or multimedia platform as desired. According to one embodiment disclosed herein, the platform102is a gaming platform for running game software and various components in signal communication with the gaming platform102, such as a dedicated game console including an XBOX One® manufactured by Microsoft Corp., PLAYSTATION 4® manufactured by Sony Corporation, and/or WII U® manufactured by Nintendo Corp. In other embodiments, the platform102can also be a personal computer, laptop, tablet computer, or a handheld mobile device. One or more players can use a gaming platform to participate in a game. Multiple gaming platforms may be linked together locally (e.g., via a LAN connection), or via the network110(e.g., the Internet or other communication networks).

The network110can also include any number of wired data networks and/or any conventional wireless communication network, for example, radio, Wireless Fidelity (Wi-Fi), cellular, satellite, and broadcasting networks. Exemplary suitable wireless communication technologies used with the network110include, but are not limited to, Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband CDMA (W-CDMA), CDMA2000, IMT Single Carrier, Enhanced Data Rates for GSM Evolution (EDGE), Long-Term Evolution (LTE), LTE Advanced, Time-Division LTE (TD-LTE), High Performance Radio Local Area Network (HiperLAN), High Performance Radio Wide Area Network (HiperWAN), High Performance Radio Metropolitan Area Network (HiperMAN), Local Multipoint Distribution Service (LMDS), Worldwide Interoperability for Microwave Access (WiMAX), ZigBee, Bluetooth, Flash Orthogonal Frequency-Division Multiplexing (Flash-OFDM), High Capacity Spatial Division Multiple Access (HC-SDMA), iBurst, Universal Mobile Telecommunications System (UMTS), UMTS Time-Division Duplexing (UMTS-TDD), Evolved High Speed Packet Access (HSPA+), Time Division Synchronous Code Division Multiple Access (TD-SCDMA), Evolution-Data Optimized (EV-DO), Digital Enhanced Cordless Telecommunications (DECT) and others.

The platform102typically is electrically coupled to a display device104. For example, the display device104can be an output device for presentation of information from the platform102and includes a television, a computer monitor, a head-mounted display, a broadcast reference monitor, a medical monitor, the screen on a tablet or mobile device, and so on. In some embodiments, the platform102and/or the display device104is in communication with an audio system (not shown) for presenting audible information.

InFIG. 1, the platform102also is electrically or wirelessly coupled to one or more controllers or input devices, such as an input device103. In some embodiments, the input device103is a game controller and includes keyboards, mice, gamepads, joysticks, directional pads, analog sticks, touch screens, and special purpose devices (e.g., steering wheels for driving games and/or light guns for shooting games). Additionally and/or alternatively, the input device103includes an interactive-motion-tracking system, such the Microsoft Xbox One KINECT® device or the Sony PlayStation 4 Camera®, for tracking the movements of a player within a 3-dimensional physical space. The input device103provides data signals to the platform102, which processes the data and translates the player's movements on the display device104. The platform102can also perform various calculations or operations on inputs received by the sensor and instruct the display to provide a visual representation of the inputs received as well as effects resulting from subsequent operations and calculations.

In one embodiment, the platform102can be connected via the network110to the server115that can host, for example, multiplayer games and multimedia information (e.g., scores, rankings, tournaments, and so on). Users can access the server115when the platform102is online via the network110. Reference herein to the platform102can include gaming platforms executing video game software or game software (e.g., computer program products, tangibly embodied in a computer-readable storage medium). Additionally and/or alternatively, references to the platform102can also include hardware only, or a combination of hardware and/or software. In some embodiments, the platform102includes hardware and/or software, such as a central processing unit, one or more audio processors, one or more graphics processors, and one or more storage devices.

In some embodiments, a selected player console101A-N directly communicates with other player consoles of the session management system100via the network110. When data (e.g., game information) is exchanged without the central server115, the session management system100can operate as a peer-to-peer network. In some cases, such as for a video game, a selected player console101only can support a very limited, relatively small number of players in a single session. However, any number of sessions can exist in any multiplayer game.

For example, turning toFIG. 2, one or more sessions201can exist in a single video game. As shown, a first session201A and a second session201B can represent one or more objects202(e.g., virtual players, objects, virtual areas, and so on) in the same virtual world of the video game. Although two sessions201are shown for illustration purposes only, the video game can include any number of sessions201, each session supporting one or more objects202. The first session201A supports objects202A,202B, and202C. In one example, the objects202A and202B can represent a virtual player and a token used in the game, respectively. Similarly, the second session201B supports objects202D,202E, and202F. In some embodiments, the objects202of the first session201A are unique from the objects202of the second session201B. For instance, the objects202A,203B, and204B can represent three unique players in the same virtual world of the first session201A.

As previously discussed, in conventional multiplayer network systems, when virtual players (e.g., objects202A and202B) begin to congregate in the same virtual area of a map, for example, there may be a disconnect between players in different sessions. Stated in another way, the same objects202will not exist across different sessions (e.g., objects202in a first session201A may not exist in the second session201B). This can cause players to feel as if their virtual world is disconnected from the rest of the game. Advantageously, the session management system100dynamically manages sessions201by allowing players from different sessions—but in the same virtual area of the map, for example—to be merged into a single session. This allows players from previously different sessions to come across one another, thereby, making the virtual world seem more populated. As an additional advantage, seamless session merging handles many network failures silently. In prior art systems, a player who loses network connectivity can be kicked out of a session and may not be able to rejoin (because they are in a session by themselves). However, the session management system100allows for a disconnected player to exist in a session by themselves for a predetermined period before they are reconnected to the remaining players in the session or can be joined with another session.

With reference now toFIG. 3A, an exemplary method3000for seamless session management is shown. The method3000begins with monitoring a triggering event (step3010). In some embodiments, the triggering event defines when (step3020) to merge two sessions201or split a single session201. For example, when the object202A (e.g., virtual players) in the same session201A move physically apart from another the object203A by a predetermined virtual distance, this triggers (step3010/3020) the session management system100to split the session201A (step3040) into two different sessions. Likewise, if objects202from two different sessions201(e.g., the objects202A and202D) are within a predetermined virtual distance from one another, the session management system100can merge the sessions201A and201B (step3030) to allow interaction between objects202of the respective sessions201. Other examples of the triggering event being monitored in step3010includes, but is not limited to, a change in a player/objects position/visibility, players leaving/entering the virtual/game world (e.g., starting or ending a game), players inviting each other to a game session, game based triggers (e.g., ending/starting a mission), completing a “start-of-game” tutorial (i.e., merging players with the general game population after introduction without interference from other players), administratively removing players (e.g., moving players from one session to another), temporary loss of connectivity, virtual geography, team management, networking resources, social relationships (e.g., friends, friends of friends, recent players, groups), spoken language, skill level, matchmaking rating (MMR), game modes (for example, a player can be on a mission to follow another player), player housing, and so on.

In a preferred embodiment as shown inFIG. 3B, the process for merging (step3030) includes two phases: (1) resolving player IDs (step3031); and (2) resolving object IDs (step3032). This two-step process advantageously ensures that the players in the merged session have common object identifiers for all world objects. This allows players to communicate information about object state, e.g., I am giving you object X, and so on. This need to communicate object state favors shorter object IDs to reduce data transmission volumes. This is because object state data should be transmitted as quickly as possible (ideally all in one IP packet) to avoid latency (delay) issues. These constraints necessitate short object IDs. This results in the potential that different players will have conflicting object IDs. During a merge, these conflicts in object IDs need to be resolved. One option for resolving these id conflicts would be to just change conflicting object IDs throughout one player's instance of the game, i.e., change private IDs (discussed below). However, object IDs are often replicated throughout a game's code base for various purposes. Renaming IDs throughout the entire game would be time consuming and likely to introduce bugs or errors.

Turning toFIG. 4, an exemplary process3031for resolving player IDs is shown in further detail. As an initial matter, each player console101(or peer in the peer-to-peer system) represents a single player with a single player ID. Accordingly, in some embodiments, the central server115can maintain a public player index (step4010), which can identify the currently assigned player ID for each player of a selected player console101. In an alternative embodiment, each player console101can maintain a local copy of the public player index to reduce any need for a “central server” in a peer-to-peer system. For each player console101that is to be merged, a new unique player ID is assigned that avoids any conflicts (step4020). In some embodiments, each player console101(or each peer) in the merging session broadcasts a message (step4030) to each player console101that is to be merged stating the player console101is ready to receive messages using new player IDs in a merged session. For each player console101to be merged into the same session, a selected player console101replies (step4040) to each player console101that sent a broadcast message in step4030that all future communication will use the newly generated player ID list. In other words, when a peer knows another peer is ready to receive new player IDs by way of receiving the broadcasted message from step4030, the peer replies with a message to that peer indicating that all future communication will use new player IDs. Once all player consoles101to be merged have confirmed the new player ID list, all previously used player IDs are cleared (step4050).

With reference now toFIG. 5, an exemplary process3032for resolving object IDs is shown in further detail. Compared to resolving player IDs, resolving for object IDs typically accounts for multiple objects per player console101. Even further, each player console101can be said to “own” a particular object that exists in their session and the session management system100therefore must resolve ownership issues of objects between the player consoles101. In some embodiments, the central server115does not resolve any issues related to resolving object IDs. However, in some embodiments, the central server115can receive object IDs and resolve object IDs to simplify computational requirements on the server.

The exemplary process3032for resolving object IDs begins by waiting for each player console101(and each corresponding session201) to allocate a current ID for any local object in their related session (step5010). Each player console101transmits a copy of their mapping of local objects and object IDs to each player console101to be merged. Once all of the player consoles101that will be merged has provided their local object ID mapping (step5020), any object that is left unmapped is allocated an object ID and each player console101to be merged is provided a copy of this mapping (step5030). The session management system100then waits for object mappings for unmapped objects for all players (step5035).

However, as previously discussed, each player console101may have a different idea of what is unmapped. For example, not all players know about every object in the virtual game. Each player console101also may have an inconsistent/conflicting belief about which player console101is responsible for allocating the object ID for a selected object. Therefore, if any object is still unmapped after this step (step5040), any object that is left unmapped (or each object that a selected player console101believes needs to be mapped) is allocated an object ID and each player console101to be merged is provided a copy of this mapping (return to step5030). In the event of an inconsistent/conflicting belief about which player console101is responsible for allocating the object ID, a predetermined priority of player consoles can be used to determine which object ID is used. For example, priority can be based on lower object IDs, account IDs, lexicographic ordering of user names, Internet Protocol (IP) addresses, random, and/or any ordering can be used as long as each player console101follows the same ordering. Once all objects in the sessions to be merged have been mapped, a new public object ID is assigned to each object and a “ready” message is sent to all player consoles101to be merged (step5050). Once all player consoles101to be merged have built their new object mappings, the current IDs are swapped with the generated public object IDs (step5060) to complete the merge (step5070).

In one embodiment, a lookup table is used to translate common public IDs to client-local private IDs. Similarly, the lookup table (or a separate lookup table) can be used to translate public player IDs as discussed above with reference toFIG. 4. When communicating information about object state from one player to other peers the common public object ID is used. Translation is accomplished via the look up table. In yet another embodiment, object IDs are uniquely assigned based on a larger number (e.g., more digits) such that each object ID is guaranteed to be globally unique. For example, in some embodiments, a 64-bit number or a 128-bit number can be used for each object ID to guarantee a universally unique identifier. In some embodiments, to guarantee a universally unique identifier for an object ID, a player ID or session ID can be used as a prefix for the object ID to further limit the replication of object ID's across player sessions. Finally, in an additional embodiment, the server115tracks the IDs that are in-use and provides a set of unused IDs to clients.

During a merge, one session is deemed the receiving session and the other is the merging session. In some embodiments, selecting the receiving session from one or more sessions includes comparing the session ID of each session. The session ID that is the lowest (in value) can be used as the receiving session for receiving all other merging sessions. In other embodiments, the session management system100cannot remap an ID for a selected session. For example, when remapping objects, a selected session may include newly created objects and objects that are undergoing an ownership change. This selected session can be marked as “unable to merge.” However, the selected session can be the receiving session. In even further embodiments, a selected session that is the largest session (most participants/objects) is preferably selected as the receiving session to reduce the number of conflicts, ID changes, negotiation/network traffic. For example, with reference toFIG. 2, the first session201A can be designated the merging session and the second session201B can be designated the receiving session. In the event that the session management system100is merging more than two sessions, one session is deemed the receiving session and all others are the merging sessions. Object IDs in the receiving session will stay the same. IDs in the merging session will need to be changed to resolve conflicts. By way of example, assume the two sessions have the correlation between objects202and IDs as shown inFIG. 6A.

Upon merging there will be a conflict as to the object ID3(i.e., object202C and object202D) between the two sessions201A, B. The merging session201A will not be able to use the public ID3to represent object202C because public ID3already is used in the receiving session201B for object202D. The two sessions201A, B will recognize the conflict and the receiving session201B will provide the merging session201A with a notification of available public IDs. Accordingly, the merging player will re assign the public ID for object202C to6and the tables are shown inFIG. 6Bafter the merge is complete.

In yet another embodiment, the session201A can generate non-conflicting private IDs for objects202D,202E, and202F. An example of the tables are shown inFIG. 6Cafter the merge is complete.

In some embodiments, the session management system100can also split any number of sessions. As discussed, for example, when the object202A (e.g., virtual players) in the same session201A move physically apart from another the object203A by a predetermined virtual distance, this triggers the session management system100to split the session201A into two different sessions. As an additional example, the session management system100accounts for unexpected network problems for a particular user or when a player abruptly disconnects and leaves a session. In some embodiments, during a session split, the selected peer to be split off from the active session can sever their connection to the other peers (or other player consoles101). This causes one session to become one or more sessions. Every object that is known by any of the peers in the (new or old) session will exist in the newly split sessions. In some embodiments, this includes duplicating objects across multiple sessions. In other words, this session split can be handled as disconnecting from a session. For example, if two players are in the same session and both players see a car, a player who owned the car and disconnected from the session, the remaining player can take ownership of the car because the original owner has been removed. In this event, tables/IDs discussed above do not need to change. In some embodiments, when a player who split off from a session wishes to join a new session, that player must clear their previously known objects before they can be reintroduced to the general player population. In other embodiments, splitting a session is disallowed if it would cause duplicated objects. For example, once a session is split, there can be two sessions, each with their own distinct copy of an object. Avoiding this split can avoid players that intentionally duplicate valuable objects to exploit virtual game economics. If these two sessions were to later merge, there can then be two identical objects in the same session. In this manner, the session management system100advantageously avoids object duplication when two players are merged following a split.

By way of another example, with reference now toFIG. 7A-7F, the exemplary process3032for resolving object IDs is shown in further detail. Here, the first session201A can be designated the receiving session and the second session201B can be designated the merging session. Turning toFIG. 7A, the two sessions each include objects202and IDs as shown inFIG. 7A. As shown, the first session201A can include an object202A with a single player of a player console101A. The second session201B can include four objects202B,202C,202D, and202D with two participating player consoles101B and101C.

As discussed, each player console101can be said to “own” a particular object that exists in their session and the session management system100therefore must resolve ownership issues of objects between the player consoles101. In this example, the player console101B knows of objects202B-E and believes it “owns” objects202B and202D. Similarly, the player console101C knows of objects202C-E (and does not know of object202B) and believes it “owns” objects202C and202D. Neither player console101B, C believes it “owns” object202E.

The exemplary process3032for resolving object IDs begins by waiting for each player console101(and each corresponding session201) to allocate a current ID for any local object in their related session (step5010). In this example, the new player consoles101B and101C through communication with the player console101A will derive “new” IDs that are unique. For example, the player console101B can receive new object IDs2000,2001,2002,2003, and2004. The player console101C can receive new object IDs3000,3001,3002,3003, and3004.

Each player console101transmits a copy of their mapping of local objects and object IDs to each player console101to be merged. In this example, and as shown inFIG. 7B, the player console101B maps objects202B and202D as it believes it “owns” these two objects. The player console101B will not map objects202C and202E. The player console101C maps object202C and202D as it believes it “owns” these two objects. The proposed new player IDs are shown inFIG. 7B. As shown, both peers provide conflicting mappings for the object202D while neither player console provides a mapping for the object202E.

Once all of the player consoles101that will be merged have provided their local object ID mapping (step5020), any object that is left unmapped is allocated an object ID and each player console101to be merged is provided a copy of this mapping (step5030). In this example, the only unmapped object is the object202E. Therefore, as shown inFIG. 7C, the player console101B suggests mapping the object202E with the object ID2002; the player console101C suggests mapping the object202E with the object ID3002. Again, these are conflicting mappings.

The session management system100then waits for object mappings for unmapped objects for all players (step5035). However, as previously discussed, each player console101may have a different idea of what is unmapped as shown inFIG. 7C. In some embodiments, in the event of a conflict as shown here, the mapping generated by the player with a lower player index is used. However, as described above, any ordering can be used. For exemplary purposes only, the player console101B has the lower player index compared to the player console101C. Accordingly, the conflicts will be resolved by using the proposed object IDs from the player console101B, as shown inFIG. 7D.

If any object is still unmapped after this step (step5040), any object that is left unmapped is allocated an object ID and each player console101to be merged is provided a copy of this mapping (return to step5030). Once all objects in the sessions to be merged have been mapped, a new public object ID is assigned to each object and a “ready” message is sent to all player consoles101to be merged (step5050). In the example shown inFIGS. 7A-F, the following mapping for the incoming session201B can be used to merge the sessions201A, B:

Private IDPublic ID1000200020001000100130003000100110022001200110021003200220021003

Once all player consoles101to be merged have built their new object mappings, as shown inFIG. 7E, the current IDs are swapped with the generated public object IDs (step5060) to complete the merge (step5070), as shown inFIG. 7F. Turning toFIG. 7F, once the merge is complete, the player consoles101A,101B, and101C can now communicate freely using common public IDs. For example, from the player console101, the object that is known publically as object1000is known by the private ID of object1000. The object that is known publically as object2000is known privately as object2000. Similarly, for either of the player consoles101B or101C, the object that is known publically as object2000is known by the private ID of object1000. The object that is known publically as object1000is known privately to that client as object2000.

The session management system100advantageously selects sessions where there are no conflicts, or the conflicts can be resolved in any of the methods described herein. Accordingly, the session management system100provides the appearance of sharing the same space with many players without limitation on the geometry of the virtual world. Additionally, because session management system100does not require the full game state to be simulated by the server, much less computational resources are required. For example, the session management system100maintains a minimal subset of the game state (e.g., player positions, velocity, volume locks, session locks, and so on). Game state information that is not necessary for choosing a session (e.g., player health, weapons, running scripts, and so on) need not be managed for purposes of session management and additional resources can be freed up for session-based computations. Advantageously, the server need only be concerned about a number of small individual sessions as well as the information relevant to merging/splitting sessions to provide the illusion of a single-larger session. In fact, the session management system100scales like a small-session system and provides users with the feel of a large-session virtual environment.

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.