US20090325712A1

US20090325712A1 - Player character matchmaking with distributed peer-to-peer functionality

Info

Publication number: US20090325712A1
Application number: US12/164,024
Authority: US
Inventors: Timothy E. Rance
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2008-06-28
Filing date: 2008-06-28
Publication date: 2009-12-31

Abstract

Video game players may become matched with other players for the purposes of communication and/or playing together for the mutual benefit of each in an arrangement that uses a distributed network for implementing peer-to-peer connectivity in combination with a matchmaking server. When a player enters a new level in the video game, identifying information such as a level ID (identification) is registered with the matchmaking server which may be provided as part of a larger game service. Other players on the same level, for example, are located using a matchmaking query. A direct peer-to-peer connection is initiated between players, and position updates pertaining to the players are communicated in a peer-to-peer fashion. In an illustrative example, friends of players are given to friends who are ensured to be seen by reserving a predetermined number of connection slots for players or player characters on a friends list.

Description

BACKGROUND

Computer and video games have matured from the likes of “Pong” into epic adventures having rich storylines, photorealistic graphics, and complex interaction systems, thereby allowing players to immerse themselves in the alternative reality that is emulated by the video game. As used herein, video games may include, but are not limited to, any game played on a data processing device. Examples of video games may include computer games, game console games (e.g., playable on the Microsoft Xbox®, Sony PlayStation®, and/or Nintendo® 64 and Wii brand game consoles), coin-operated or token-operated arcade games, portable gaming device games (e.g., playable on the PlayStation Portable (“PSP”®), Nintendo Game Boy and DS™, mobile phones, smartphones, personal digital assistants, etc.), or other software-driven games that are played on personal computers.
Video games come in many genres, such as first-person shooters (“FPS”), role-playing games (“RPG”), simulation, sports, strategy, and driving, to name a few. Each video game is not necessarily limited to a single genre, and may indeed encompass multiple genres. An RPG generally refers to a game in which each participant assumes the role of a character in the game (such as an adventurer, monster, or other game character) that can interact within the game's virtual world. A character controlled by a player/user is commonly referred to as a game character or player character.
In the FPS genre, the display screen typically provides a first person point of view, e.g., as if the player is viewing the video game's virtual world through the eyes of the character the player is controlling. Popular FPS games include the HALO®, DOOM®, QUAKE®, and Half-Life® franchises. FPS games are very popular, in part because they are particularly well-suited to multiplayer gameplay.
In multiplayer play, each participant controls a player character within the virtual environment, and the participants either work alone or in teams to complete their objective(s) for a particular game. The wide availability of Internet connectivity has fueled the popularity of multiplayer video gaming as players can use their on-line connection to locate other players and then participate in a common game. In the multiplayer video game, players can typically see and interact with player characters controlled by other players, even if the other players are physically located in another state or country. Multiplayer FPS games may provide different objectives in various game modes, thus providing a variety of gameplay types to participants.
For example, in one type of multiplayer play, massively multi-player online (“MMO”) games, thousands of players share the same instance of a game world that is being played on a server. New players are added to the instance of the game world by logging into the server. This creates open access to the instance of the game world and allows players to interact with every player logged into the server.
In another type, massive open online role-playing games (“MMORPGs”), players log into a server in the same manner as they would in a massive multi-player online game. However, instead of placing all players in the same instance of the game, the server creates multiple parallel instances of the game. For each instance, the server automatically identifies a small group of players that are to be assigned to that instance. For example, the server may identify eight players that are playing within a single instance. In most cases, the groups are formed based on the position of the player characters, also termed “avatars”, in the game world. An avatar is the representation of the player in the game and can take the form of a character or even an object, such as a car. If an avatar moves too far away from the other avatars in the game world, the server will transfer the avatar to another group, and thus to another instance of the game. This transfer happens automatically without any input from the players.
In a third type of multi-player game, a player acts as a host and sends invitations to other players to join in an instance of the game. To send such invitations, the player typically interrupts a game they are currently playing to access a list of friends or available players and to initiate a command that sends the invitation to each of the players. If the host logs off of the game, the instance stops. This undesirable consequence is often termed “host migration”.
In general, such grouping is important because, while in many MMORPGs it is enough to coexist with other players since much of the gameplay centers on one-to-one interaction, other games require teamwork to successfully meet a goal, whether the goal is to defeat a high-level “boss,” retrieve a rare artifact, or defeat an opposing army. In this case, players must organize themselves together in groups or teams.
Prior attempts at such organization include lobby systems as well as in-game systems that essentially amount to “pick up” groups. While these attempts have met with some success, they require considerable user motivation; consequently, they do not generally provide a way for all players to become matched into a group.
This Background is provided to introduce a brief context for the Summary and Detailed Description that follow. This Background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above.

SUMMARY

Video game players may become matched with other players for the purposes of communication and/or playing together for the mutual benefit of each in an arrangement that uses a distributed network for implementing peer-to-peer connectivity in combination with a matchmaking server. The matchmaking server is typically only accessed at limited and discrete times. When a player enters a new level in the video game, identifying information such as a level ID (identification) is registered with the matchmaking server which may be provided as part of a larger game service. Other players on the same level, or having a similar identifier of affinity, are located using a matchmaking query. A direct peer-to-peer connection is initiated between players, and position updates pertaining to the players are communicated in a peer-to-peer fashion. In an illustrative example, friends of players are given to friends who are ensured to be seen by reserving a predetermined number of connection slots for players or player characters on a friends list.
The present arrangement for player character matchmaking further includes the display of simple representations of other players, in one example glowing orbs (here termed “virtual avatars”), that appear in one player's single-player instance of a game. The other players are generally playing in their own instances of the game (though some of these other players may already be combined into one or more instances), and their associated virtual avatars in the first instance may appear at the same position and level as in their own instances. The virtual avatar appearance may update in real-time so that the avatars may appear to move around in the level.
Advantageously, bandwidth requirements for positional updates are minimal using the distributed peer-to-peer network. Moreover, the CPU requirements are lessened as each client need only track a relatively small number of external players. In this way, the implementation is highly scalable, and little if any additional server software or hardware support will typically be required. The present arrangement further enables a reliable way to locate and track players on a friends list, as well as to provide players with additional ways to meet new friends. A solution to the issue of “host migration” is also facilitated as the present arrangement provides a peer-to-peer solution that needs no centralized host.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an illustrative gaming system that may be used to implement one or more of the features of the arrangement described herein;

FIG. 2 shows a functional block diagram of the gaming system shown in FIG. 1;

FIG. 3 shows a functional block diagram of an illustrative networked gaming system;

FIG. 4 shows a functional block diagram of an illustrative online gaming environment;

FIG. 5 is a flowchart showing operation of an illustrative gaming arrangement in which a first player character may view (and be viewed by) other player characters in a playgroup, and in so doing may choose to group with other player characters by inviting the player characters to a group;

FIG. 6 shows an illustrative gaming arrangement in which a first player character views various player characters in “ghost” or virtual avatar form; and

FIG. 7 shows an illustrative gaming arrangement in which players A-E are each connected to a matchmaking server.

Like reference numerals indicate like elements in the drawings. Elements are not drawn to scale unless otherwise indicated.

DETAILED DESCRIPTION

A server-based solution is described in U.S. patent application Ser. No. 11/766,466, filed Jun. 21, 2007, entitled “Live Game Lobby” owned by the assignee of the present application and hereby incorporated by reference in its entirety which uses an avatar-tracking server to which every player maintains a connection. A central server uses various parameters to determine which players to connect together, maintains all positional data, handles disconnects, and the like. This system is sufficient for smaller massively multiplayer online game populations but certain difficulties may be presented at larger populations with regard to the servers employed. Large populations tend to tax the server's bandwidth and CPU excessively. The system is less easily scalable overall, and the server is a separate application requiring its own hardware and support for deployment. In addition, if an attempt is made to ameliorate these above difficulties by distributing server functionality, then player generally encounter difficulty locating their friends. By comparison, the present arrangement for player character matching utilizes a highly scalable peer-to-peer networking arrangement that give priority to friends of a given player.
Turning now to the drawings, FIG. 1 illustrates an example of a gaming system 100 on which computer games, video games, and/or other electronic games (collectively referred to herein as video games) may be played. The gaming system 100 is only one example of a suitable gaming system and is not intended to suggest any limitation as to the scope of use or functionality of the features described herein. Neither should the gaming system 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the illustrative operating gaming system 100.
Aspects described herein are operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use include, but are not limited to, PCs, server computers, portable and handheld devices such as personal digital assistants (“PDAs”), mobile phones, smart phones, handheld game devices, tablet PCs or laptop PCs, media centers, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, electronic game consoles, distributed computing environments that include any of the above systems or devices, and the like.
Aspects herein may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The features described herein may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
The gaming system 100 may include a game console 102 and multiple controllers, as represented by controllers 104 ₁and 104 ₂. The game console 102 is equipped with a removably attachable hard disk drive 105 and a portable media drive 106 that supports various forms of portable storage media as represented by optical storage disc 108. Examples of suitable portable storage media include DVD (digital versatile disc), CD-ROM (compact disc-read only memory), game discs, and so forth.
Game console 102 has slots 110 on its front face to support up to two controllers, although the number and arrangement of slots may be modified. A power button 112 and an eject button 114 are also positioned on the front face of the game console 102. The power button 112 switches power to the game console and the eject button 114 alternately opens and closes a tray of the portable media drive 106 to allow insertion and extraction of the storage disc 108.
Game console 102 may connect to a television 118 or other display via A/V interfacing cables 120. A power cable 122 provides power to the game console. Game console 102 may further be configured with broadband network capabilities, as represented by the cable or modem connector 124 to facilitate access to a network, such as the Internet.
Each controller 104 may be coupled to the game console 102 via a wired or wireless interface. In the illustrated implementation, the controllers are USB (Universal Serial Bus) compatible and are connected to the console 102 via respective USB cables 130 ₁and 130 ₂. The controllers 104 may be equipped with any of a wide variety of user interaction mechanisms. In this example, each controller 104 is equipped with two thumbsticks 132 ₁and 132 ₂, a D-pad (directional pad) 134, buttons 136 (e.g., ‘A’, ‘B’, ‘X’, ‘Y’), and two triggers 138 (although only one trigger is shown in the drawing). These mechanisms are merely representative, and other known gaming mechanisms may be substituted for or added to those shown in FIG. 1.
A memory unit 140 may be inserted into a memory unit reader 141 in the game console 102 to provide additional and portable storage. In this example, up to two memory units may be supported by the game console 102. Portable memory units enable users to store game parameters and user accounts, and port them for play on other consoles. A headset 142 may be connected to the controller 104 or game console 102 to provide audio communication capabilities. Headset 142 may include a microphone for audio input and one or more speakers for audio output.
Gaming system 100 is capable of playing, for example, games, music, and videos. With the different storage offerings, titles can be played from the hard disk drive or the portable media 108 in drive 106, from an online source, or from a memory unit 140. For security, in some embodiments executable code can only be run from the portable media 108. A sample of what gaming system 100 is capable of playing includes game titles played from CD and DVD discs, from the hard disk drive, or from an online source, digital music played from a CD in the portable media drive 106, from a file on the hard disk drive (e.g., Windows Media Audio (“WMA”) format), or from online streaming sources, and digital audio/video played from a DVD disc in the portable media drive 106, from a file on the hard disk drive (e.g., Active Streaming Format), or from online streaming sources.
FIG. 2 shows functional components of the gaming system 100 in more detail. The game console 102 has a central processing unit (“CPU”) 200 and a memory controller 202 that facilitates processor access to various types of memory, including a flash ROM (Read Only Memory) 204, a RAM (Random Access Memory) 206, the hard disk drive 105, the memory unit reader 141, and the portable media drive 106. The CPU 200 is equipped with a level 1 cache 210 and a level 2 cache 212 to temporarily store data and hence reduce the number of memory access cycles, thereby improving processing speed and throughput.
The CPU 200, memory controller 202, and various memory devices are interconnected via one or more buses, including serial and parallel buses, a memory bus, a peripheral bus, and a processor or local bus using any of a variety of bus architectures. By way of example, such architectures can include an Industry Standard Architecture (“ISA”) bus, a Micro Channel Architecture (“MCA”) bus, an Enhanced ISA (“EISA”) bus, a Video Electronics Standards Association (“VESA”) local bus, and a Peripheral Component Interconnects (“PCI”) bus also known as a Mezzanine bus.
As one suitable implementation, the CPU 200, memory controller 202, ROM 204, and RAM 206 are integrated onto a common module 214. In this implementation, ROM 204 is configured as a flash ROM that is connected to the memory controller 202 and a ROM bus (not shown). RAM 206 is configured as multiple DDR SDRAM (Double Data Rate Synchronous Dynamic RAM) that is independently controlled by the memory controller 202 via separate buses (not shown). The hard disk drive 105 and portable media drive 106 are connected to the memory controller via the PCI bus and an ATA (Advanced Technology Attachment) bus 216.
A 3D graphics processing unit 220 and a video encoder 222 form a video processing pipeline for high speed and high resolution graphics processing. Data is carried from the graphics processing unit 220 to the video encoder 222 via a digital video bus (not shown). An audio processing unit 224 and an audio codec (coder/decoder) 226 form a corresponding audio processing pipeline with high fidelity and stereo processing. Audio data is carried between the audio processing unit 224 and the audio codec 226 via a communication link (not shown). The video and audio processing pipelines output data to an A/V (audio/video) port 228 for transmission to the television or other display. In the illustrated implementation, the video and audio processing components 220-228 are mounted on the module 214.
Also implemented on the module 214 are a USB host controller 230 and a network interface 232. The USB host controller 230 is coupled to the CPU 200 and the memory controller 202 via a bus (e.g., PCI bus) and serves as host for the peripheral controllers 104 ₁and 104 ₂. The network interface 232 provides access to a network (e.g., Internet, home network, etc.) and may be any of a wide variety of various wired or wireless interface components including an Ethernet card, a modem, a Bluetooth module, a cable modem, and the like.
The game console 102 has a dual controller port subassembly 240 which supports the game controllers 104 ₁and 104 ₂. A front panel I/O subassembly 242 supports the functionality of the power button 112 and the eject button 114, as well as any LEDs (light emitting diodes) or other indicators exposed on the outer surface of the game console. The subassemblies 240 and 242 are coupled to the module 214 via one or more cable assemblies 244.
A system power supply module 250 provides power to the components of the gaming system 100. A fan 252 cools the circuitry within the game console 102.
The game console 102 implements a uniform media portal model that provides a consistent user interface and navigation hierarchy to move users through various entertainment areas. The portal model offers a convenient way to access content from multiple different media types—game data, audio data, and video data—regardless of the media type inserted into the portable media drive 106.
To implement the uniform media portal model, a console user interface (“UI”) application 260 is stored on the hard disk drive 105. When the game console is powered on, various portions of the console application 260 are loaded into RAM 206 and/or caches 210 and 212 and executed on the CPU 200. The console application 260 presents a graphical user interface that provides a consistent user experience when navigating to different media types available on the game console.
The gaming system 100 may be operated as a standalone system by simply connecting the system to a television or other display. In this standalone mode, the gaming system 100 allows one or more players to play games, watch movies, or listen to music. However, with the integration of broadband connectivity made available through the network interface 232, the gaming system 100 may further be operated as a participant in a larger network gaming community. This network gaming environment is described next.
FIG. 3 shows an exemplary network gaming environment 300 that interconnects multiple gaming systems 100 _{1 . . . N}via a network 302. The network 302 represents any of a wide variety of data communications networks. It may include public portions (e.g., the Internet) as well as private portions (e.g., a residential Local Area Network (“LAN”)), as well as combinations of public and private portions. Network 302 may be implemented using any one or more of a wide variety of conventional communications media including both wired and wireless media. Any of a wide variety of communications protocols can be used to communicate data via network 302, including both public and proprietary protocols. Examples of such protocols include TCP/IP (Transport Control Protocol/Internet Protocol), IPX/SPX (Internetwork Packet Exchange/Sequenced Packet Exchange), NetBEUI (NetBIOS Extended User Interface where BIOS stands for Basic Input/Output System), etc.
In addition to gaming systems 100, one or more online services 304 _{1 . . . N}may be accessible via the network 302 to provide various services for the participants, such as hosting online games, serving downloadable music or video files, hosting gaming competitions, serving streaming audio/video files, and the like. The network gaming environment 300 may further involve a key distribution center 306 that plays a role in authenticating individual players and/or gaming systems 100 to one another as well as online services 304. The distribution center 306 distributes keys and service tickets to valid participants that may then be used to form games amongst multiple players or to purchase services from the online services 304.
The network gaming environment 300 introduces another memory source available to individual gaming systems 100, namely online storage. In addition to the portable media 108, the hard disk drive 105, and the memory unit(s) 140, the gaming systems 100 can also access data files available at remote storage locations via the network 302, as exemplified by remote storage 308 at online service 304 _N.
FIG. 4 is a block diagram of another illustrative online gaming environment 400, e.g. Xbox® 360 by Microsoft Corporation. Multiple game consoles 402 _{1, 2 . . . N}are coupled to a security gateway 404 via a network 406. Each game console 402 can be configured in a similar manner as game console 102 of FIG. 1 or FIG. 2, for example. Network 406 represents any one or more of a variety of conventional data communications networks. Network 406 will typically include packet switched networks, but may also include circuit switched networks. Network 406 can include wired and/or wireless portions. In one exemplary implementation, network 406 includes the Internet and may optionally include one or more local area networks and/or wide area networks (“WANs”). At least a part of network 406 is a public network, which refers to a network that is publicly-accessible.
In some situations, network 406 includes a LAN (e.g., a home network), with a routing device situated between game console 402 and security gateway 404. This routing device may perform network address translation (“NAT”), allowing the multiple devices on the LAN to share the same IP address on the Internet, and to operate as a firewall to protect the device(s) on the LAN from access by malicious or mischievous users via the Internet.
Security gateway 404 operates as a gateway between public network 406 and a private network 408. Private network 408 can be any of a wide variety of conventional networks, such as a local area network. Private network 408, as well as other devices discussed in more detail below, is within a data center 410 that operates as a secure zone. Data center 410 is made up of trusted devices that communicate using trusted communications. Thus, encryption and authentication within secure zone 410 is not necessary. The private nature of network 408 refers to the restricted accessibility of network 408 such that access to network 408 is limited to only certain individuals (e.g., restricted by the owner or operator of data center 410).
Security gateway 404 is a cluster of one or more security gateway computing devices. These security gateway computing devices collectively implement security gateway 404. Security gateway 404 may optionally include one or more conventional load balancing devices that operate to direct requests to be handled by the security gateway computing devices to appropriate ones of those computing devices. This directing or load balancing is performed in a manner that attempts to balance the load on the various security gateway computing devices approximately equally (or alternatively in accordance with some other criteria).
Also within data center 410 are: one or more monitoring servers 412, one or more presence and notification front doors 414, one or more presence servers 416, one or more notification servers 418, and a profile store 428 (collectively implementing a presence and notification service or system 430), one or more match front doors 420 and one or more match servers 422 (collectively implementing a match service), and one or more statistics front doors 424 and one or more statistics servers 426 (collectively implementing a statistics service). The servers 416, 418, 422, and 426 provide services to game consoles 402, and thus can be referred to as service devices. Other service devices may also be included in addition to, and/or in place of, one or more of the servers 416, 418, 422, and 426. Additionally, although only one data center is shown in FIG. 4, alternatively, multiple data centers may exist with which game consoles 402 can communicate. These data centers may operate independently, or alternatively may operate collectively (e.g., to make one large data center available to the game consoles 102 and 402).
Game consoles 402 are situated remotely from data center 410, and may access data center 410 via network 406. A game console 402 desiring to communicate with one or more devices in the data center logs in to the data center and establishes a secure communication channel between the game console 402 and security gateway 404. Game console 402 and security gateway 404 encrypt and authenticate data packets being passed back and forth, thereby allowing the data packets to be securely transmitted between them without being understood by any other device that may capture or copy the data packets without breaking the encryption. Each data packet communicated from game console 402 to security gateway 404, or from security gateway 404 to game console 402, can have data embedded therein. This embedded data is referred to as the content or data content of the packet. Additional information may also be inherently included in the packet based on the packet type (e.g., a heartbeat packet).
The secure communication channel between a game console 402 and security gateway 404 is based on a security ticket. Game console 402 authenticates itself and the current user(s) of console 402 to a key distribution center 450 and obtains, from key distribution center 450, a security ticket. Game console 402 then uses this security ticket to establish the secure communication channel with security gateway 404. In establishing the secure communication channel with security gateway 404, the game console 402 and security gateway 404 authenticate themselves to one another and establish a session security key that is known only to that particular game console 402 and the security gateway 404. This session security key is used to encrypt data transferred between the game console 402 and the security gateway 404, so no other devices (including other game consoles 402) can read the data. The session security key is also used to authenticate a data packet as being from the security gateway 404 or game console 402 that the data packet alleges to be from. Thus, using such session security keys, secure communication channels can be established between the security gateway 404 and the various game consoles 402.
Once the secure communication channel is established between a game console 402 and the security gateway 404, encrypted data packets can be securely transmitted between the two. When the game console 402 desires to send data to a particular service device in data center 410, the game console 402 encrypts the data and sends it to security gateway 404 requesting that it be forwarded to the particular service device(s) targeted by the data packet. Security gateway 404 receives the data packet and, after authenticating and decrypting the data packet, encapsulates the data content of the packet into another message to be sent to the appropriate service via private network 408. Security gateway 404 determines the appropriate service for the message based on the requested service(s) targeted by the data packet.
Similarly, when a service device in data center 410 desires to communicate data to a game console 402, the data center sends a message to security gateway 404, via private network 408, including the data content to be sent to the game console 402 as well as an indication of the particular game console 402 to which the data content is to be sent. Security gateway 404 embeds the data content into a data packet, and then encrypts the data packet so it can only be decrypted by the particular game console 402 and also authenticates the data packet as being from the security gateway 404.
Although discussed herein as primarily communicating encrypted data packets between security gateway 404 and a game console 402, alternatively some data packets may be partially encrypted (some portions of the data packets are encrypted while other portions are not encrypted). Which portions of the data packets are encrypted and which are not can vary based on the desires of the designers of data center 410 and/or game consoles 402. For example, the designers may choose to allow voice data to be communicated among consoles 402 so that users of the consoles 402 can talk to one another—the designers may further choose to allow the voice data to be unencrypted while any other data in the packets is encrypted. Additionally, in another alternative, some data packets may have no portions that are encrypted (that is, the entire data packet is unencrypted). It is also noted that, even if a data packet is unencrypted or only partially encrypted, all of the data packet can still be authenticated.
Each security gateway device in security gateway 404 is responsible for the secure communication channel with typically one or more game consoles 402, and thus each security gateway device can be viewed as being responsible for managing or handling one or more game consoles. The various security gateway devices may be in communication with each other and communicate messages to one another. For example, a security gateway device that needs to send a data packet to a game console that it is not responsible for managing or handling may send a message to all the other security gateway devices with the data to be sent to that game console. This message is received by the security gateway device that is responsible for managing that game console and sends the appropriate data to that game console. Alternatively, the security gateway devices may be aware of which game consoles are being handled by which security gateway devices—this awareness may be explicit, such as each security gateway device maintaining a table of game consoles handled by the other security gateway devices, or alternatively, implicit, such as determining which security gateway device is responsible for a particular game console based on an identifier of the game console.
Monitoring server(s) 412 operate to inform devices in data center 410 of an unavailable game console 402 or an unavailable security gateway device of security gateway 404. Game consoles 402 can become unavailable for a variety of different reasons, such as a hardware or software failure, the console being powered-down without logging out of data center 410, the network connection cable to console 402 being disconnected from console 402, other network problems (e.g., the LAN that the console 402 is on malfunctioning), etc. Similarly, a security gateway device of security gateway 404 can become unavailable for a variety of different reasons, such as hardware or software failure, the device being powered-down, the network connection cable to the device being disconnected from the device, other network problems, etc.
Each of the security gateway devices in security gateway 404 is monitored by one or more monitoring servers 412, which detect when one of the security gateway devices becomes unavailable. In the event a security gateway device becomes unavailable, monitoring server 412 sends a message to each of the other devices in data center 410 (servers, front doors, etc.) that the security gateway device is no longer available. Each of the other devices can operate based on this information as it sees fit (e.g., it may assume that particular game consoles being managed by the security gateway device are no longer in communication with data center 410 and perform various clean-up operations accordingly). Alternatively, only certain devices may receive such a message from the monitoring server 412 (e.g., only those devices that are concerned with whether security gateway devices are available).
Security gateway 404 monitors the individual game consoles 402 and detects when one of the game consoles 402 becomes unavailable. When security gateway 404 detects that a game console is no longer available, security gateway 404 sends a message to monitoring server 412 identifying the unavailable game console. In response, monitoring server 412 sends a message to each of the other devices in data center 410 (or alternatively only selected devices) that the game console is no longer available. Each of the other devices can then operate based on this information as it sees fit.
Presence server(s) 416 holds and processes data concerning the status or presence of a given user logged in to data center 410 for online gaming. Notification server(s) 418 maintains multiple notification queues of outgoing messages destined for a player logged in to data center 410. Presence and notification front door 414 is one or more server devices that operate as an intermediary between security gateway 404 and servers 416 and 418. One or more load balancing devices (not shown) may be included in presence and notification front door 414 to balance the load among the multiple server devices operating as front door 414.
Security gateway 404 communicates messages for servers 416 and 418 to the front door 414, and the front door 414 identifies to which particular presence server 416 or particular notification server 418 the message is to be communicated. By using front door 414, the actual implementation of servers 416 and 418, such as which servers are responsible for managing data regarding which users, is abstracted from security gateway 404. Security gateway 404 can simply forward messages that target the presence and notification service to presence and notification front door 414 and rely on front door 414 to route the messages to the appropriate one of server(s) 416 and server(s) 418.
Match server(s) 422 holds and processes data concerning the matching of online players to one another. An online user is able to advertise a game available for play along with various characteristics of the game (e.g., the location where a football game will be played, whether a game is to be played during the day or at night, the user's skill level, etc.). These various characteristics can then be used as a basis to match up different online users to play games together. Match front door 420 includes one or more server devices (and optionally a load balancing device(s)) and operates to abstract match server(s) 422 from security gateway 404 in a manner analogous to front door 414 abstracting server(s) 416 and server(s) 418. Other matchmaking aspects are discussed below in connection with matchmaking server 432.
Statistics server(s) 426 holds and processes data concerning various statistics for online games. The specific statistics used can vary based on the game designer's desires (e.g., the top ten scores or times, a world ranking for all online players of the game, a list of users who have found the most items or spent the most time playing, etc.). Statistics front door 424 includes one or more server devices (and optionally a load balancing device(s)) and operates to abstract statistics server(s) 426 from security gateway 404 in a manner analogous to front door 414 abstracting server(s) 416 and server(s) 418.
Thus, it can be seen that security gateway 404 operates to shield devices in the secure zone of data center 410 from the untrusted public network 406. Communications within the secure zone of data center 410 need not be encrypted, as all devices within data center 410 are trusted. However, any information to be communicated from a device within data center 410 to a game console 402 passes through security gateway cluster 404, where it is encrypted in such a manner that it can be decrypted by only the game console 402 targeted by the information.
One or more features described herein may be embodied in computer-executable instructions (i.e., software) stored in RAM 206, non-volatile memory 108, 105, 308, or any other resident memory on game console 102. Generally, software modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The computer executable instructions may be stored on a computer readable medium such as one or more hard disks 105, portable storage media 108 (e.g., CD-ROM, DVD, disk, etc.), solid state memory, RAM 206, etc. As will be appreciated by one of skill in the art, the functionality of the software modules may be combined or distributed as desired in various embodiments. In addition, the functionality may be embodied in whole or in part in firmware or hardware equivalents such as application specific integrated circuits (“ASIC”), field programmable gate arrays (“FPGA”), and the like.
Much of FIG. 4 shows an arrangement by which a game service such as an MMORPG may be played. FIG. 4 also shows a matchmaking server 432, as well as two peer-to-peer connections, which may form a portion of the game service.
Peer-to-peer connection AB 403 is shown connecting consoles A and B, i.e., 402 ₁and 402 ₂, and peer-to-peer connection BN 405 is shown connecting consoles B and N, i.e., 402 ₂and 402 _N. In such connections, it is noted that player A (also called user A) is playing game instance A on gaming machine A 402 ₁. Game instance A includes a game state A that describes the position and status of every object and avatar, including virtual avatars, in a three-dimensional gaming environment of game instance A. Player B and player N are playing respective separate game instances on respective gaming machines 402 ₂and 402 _N. Game instance B has game state B and game instance N has game state N. Game state A, game state B, and game state N are all different since game instance A, game instance B, and game instance N are separate instances of the game.
Note that game instance A, game instance B, and game instance N are all for the same game but are different instances of that same game. As a result, the separate instances may contain similar objects and environments but the status of at least one object or avatar will be different in any two of the game instances. Furthermore, the avatar for each player in a particular instance cannot affect objects in other game instances. Thus, the avatar for player A in game instance A cannot affect objects in game instance B or objects in game instance N. As described herein, players A, B, and N are said to be remote from each other because they are using separate gaming machines. It will be appreciated that although the players are said to be remote from each other, they may be located in the same building or room as long as they are using a separate gaming machine.
Turning now to FIG. 5, a flowchart is shown illustrating a method for matchmaking players. The method begins when a first user starts a game on the game service (step 502); in so doing the user also establishes a session with a matchmaking server. This matchmaking session is only for the purpose of matchmaking and in general no one else need join the session.
Typically, the first user may have to perform an action in order to log on to the game service. For example, during login, the game service may obtain a gamer tag (a unique identifier associated with the user) and a password from the user, as well as a console ID that uniquely identifies the gaming machine that the user is using and a network path to the gaming machine. The gamer tag and password are authenticated by comparing them to information stored in user records, which may be located on the same server as the game service or may be distributed on a different server or a collection of different servers. Once authenticated, the game service stores the console ID and the network path in user records so that messages and downloadable content may be sent to the appropriate gaming machines.
In some implementations, demographic information may then be passed to the game service (step 504). In combination or in a separate step (as shown), a level ID is then submitted to the matchmaking server (step 506), which may include a game identifier as well as other information such as level, region, language used, and the like. Additional details about such data are described below.
A query is then performed to identify the region, for example by a query module 510. The query may include a search to determine which of the user's friends are online (step 508). This query may be performed by comparing the online population with a friends list entered or otherwise compiled by the user. A remainder of the playgroup may then be determined (step 512).
In particular, the remainder of the playgroup may constitute any other players that are deemed as potential group members with the first player. These are in many cases strangers to the first player, in the sense of not being on any sort of friends list associated with the first player. Several factors, termed “affinity” factors, may play a role in the determination of the remainder of the playgroup. For example, players in the same geographic vicinity (in the game environment or in the physical environment, such as the same state or country) as the first player may be chosen.
Players who share a common language with the first player may be chosen, or those of similar skill levels or those who engage in similar in-game activities such as fighting or exploring. Players who are not on a “banned” list associated with the first player may be chosen. Players who have a common playing history, for example, that have previously played with the first player, may be chosen. Numerous variations may be implemented to meet the needs of a particular implementation. In addition, steps 508 and 512 may be combined into a single playgroup determination step.
In some cases, for each player B virtual avatar seen in the instance of player A, player B will see a virtual avatar of player A in the instance of player B. This may be configured to be always the case when player A and player B are on each other's respective friends lists.
A next step is the creation of peer-to-peer connections between the first player and other players (step 514) of the playgroup. Following the determination of the playgroup, the matchmaking server retrieves and provides the requisite network pathways, e.g., IP addresses, such that a peer-to-peer connection may be established between the first player and each other player of the playgroup.
In an alternative implementation, following the determination of the playgroup, a peer-to-peer connection may be established between the first player and each other player of the portion of the playgroup constituting friends (found in step 508), and the remainder of the playgroup (found in step 512) may have connections formed following the friends. In this way, friends connections, often deemed more valuable to players, are always reserved (and not used for strangers) and seen immediately. Other implementations will likewise be seen. The type of connection made may vary. However, one suitable type of connection is a Winsock connection. Other varieties will also be understood to be employable to create the peer-to-peer connection.
Once the peer-to-peer connections are established, the connections are generally maintained for the duration of the game or until a termination occurs. Terminations may occur when the first player traverses from one level to another, when one of the playgroup stops playing the game, or at various other times as dictated by the system, some of which are described below.
A next step is that the first user's instance is populated with virtual avatars of each member of the playgroup (step 516). That is, once the peer-to-peer connections are established in the foregoing step, the first user may receive data, in a peer-to-peer fashion, from each member of the playgroup, and this data may be represented as virtual avatars in the first user's instance. Each peer in the peer-to-peer network sends the current position (step 516 a) of an associated avatar in the three-dimensional gaming world to the instances to which it is connected. A virtual avatar is then created (step 516 b) and rendered (step 516 c) on a user interface of the first user.
The avatars are virtual since they do not interact with items in the first user's instance. The avatars are simply present to indicate to the first user that friends, and players to whom they have an affinity, are present and may potentially be joined in a group. In the case that they are joined in a group, the instances may be merged in any fashion, and gameplay may be synchronized between the players. Additional details of the virtual avatars, the way in which an avatar may replace a virtual avatar, conflict resolution, and synchronization techniques, may be seen from the patent application incorporated by reference above.
In some embodiments, each game instance may also send attributes of the player's avatar including level, region, indoors, outdoors, health, weapons, and awards. As the player moves the avatar within the three-dimensional game world of the game instance, the game instance provides position and attributes updates to its peers. Based on this information, the new position and attributes of the virtual avatar in the first user's instance are updated.
The peer-to-peer network structure is used to distribute information about the position of avatars so that an instance of a game knows the location of player characters in other instances of the game within a playgroup. The game instance then uses this position information to create a position object that can be rendered in the three-dimensional graphical environment of the gaming instance. For example, through these embodiments, player A is able to see a graphical representation of the position of player B's player character in a position corresponding to the position of player B's player character in game instance B.
The virtual avatars shown in a game instance are not able to interact with other objects in the game instance until such time as a group is established, in which case one or the other instance is played by both players. Prior to that time, each position object or virtual avatar may be displayed as a “ghost” object. Further, even though a player's avatar may be represented by a position object in another game instance, the player does not see the objects in that other game instance. Instead, the player only sees the objects in their own game instance. For example, if player B's avatar is represented by a position object in game instance A, player B would only see objects in game instance B and would not see the objects or game world of game instance A, although player B may be able to see a virtual avatar of player A's player character if player A is in player B's playgroup.
Following the population of the first player's instance with virtual avatars (step 516), gameplay may commence (step 520).
A feature of the present arrangement is to allow players to find other players with whom to group, e.g., for purposes of performing tasks, quests, raids, or the like, that they may not otherwise be able to achieve. For this reason, a group invitation module 530 is shown, having an initial step of one user inviting another to a group (step 518). If the invited player accepts the invitation (step 519), a group is established (step 522). These steps are shown in dotted lines as the steps are optional and are not required, generally, for performance of the arrangement.
One difficulty that may occur in certain implementations of the arrangement is that the same players may be returned by the matchmaking server time after time. To address this difficulty, a connection management module 540 may be employed to prevent the same group of players from being returned each time a query is made by the query module 510. This ensures that a given game is reasonably populated with orbs.
A first step performed by the connection management module 540 is to determine if the current population is below a predetermined high water mark (HWM) (step 524). For example, a high water mark may be set at 200 virtual avatars, which represents the entire playgroup, friends and non-friends. If the high water mark is reached in the initial query, then the high water mark flag may be set at once. If the population is below the high water mark, e.g., 200 virtual avatars are not immediately populated in the first user's instance in the initial query, then the connection management module 540 continues to populate the playgroup (step 528) as “external” players continue to join and be accessible by the matchmaking server. Once the population reaches the high water mark, then the connection management module 540 stops populating the playgroup, and sets the high water mark flag (step 526). Gameplay may then continue (step 520).
It is noted in this context that gameplay may generally be allowed during any of the above population steps. There is generally no need to cease or pause gameplay during the performance of the arrangement.
Once the high water mark flag is set for the first user, then no additional users will be added to the playgroup and displayed as virtual avatars in the first user's instance until the high water mark flag is cleared. In some implementations, players with set high water mark flags are consequently not returned in queries of other players. For example, as players log on and access the matchmaking server, players with set high water mark flags will not be displayed to those users. Of course, generally in such circumstances, a set number of friend slots, e.g., 50 slots for members of a friends list, will be maintained in the playgroup, so appearances of friends will not in general be blocked by the action of step 526.
So long as the high water mark flag is set, no additional players or users will be added to the first user's playgroup. However, external player connections will gradually be reduced as players change levels, stop playing, or the like. If the total number of connections drops to a low water mark (LWM) (step 534), then the high water mark flag may be cleared (step 536) to indicate the session is again open for incoming connections. Like the high water mark, the value for the low water mark may vary, but one exemplary value is 150 players. Once the high water mark flag is cleared, then the instance may continue populating (step 528) until such time as the high water mark flag is set again. If the total number of connections drops to a very low water mark (VLWM) (step 532), then the flow may proceed to the query module 510 to re-run the query step to attempt to bring the population up to a higher value. Like the high water mark and low water mark, the value for the very low water mark may vary, but one exemplary value is 100 players.
FIG. 5 shows how the matchmaking server becomes involved in the arrangement, following the initial query, once a very low water mark is attained. The matchmaking server also performs a new query whenever the first user's player character moves from one level to another, as in this case the prior virtual avatar population is less relevant, and a new virtual avatar population may be desired. The fact that a player moves to a new level will be registered with the matchmaking server.
FIG. 6 shows one exemplary depiction of a small number of virtual avatars in the region of a first user's player character 600. The player character 600 is shown in the center for clarity, but may generally be located anywhere. A number of avatars are disposed around the player character 600. Avatars for players with which the player character 600 is already grouped into a single instance, are shown in solid lines. Such avatars are not virtual avatars but rather represent other player characters in the same instance as the player character of the first user. Avatars 602 and 604 are indicated in this way.
Avatars 606, 608, and 610 are shown in dotted lines, and represent virtual avatars, and generally represent player characters in other instances of the game. The presence of avatars 606, 608, and 610 is based on information from the matchmaking server 432, but the location, update information, appearance, and the like, are based on information communicated in the peer-to-peer network. As such, the information need not pass through a central server, which could possibly create a bottleneck and reduce performance.
FIG. 7 shows one exemplary depiction of peer-to-peer connections between users as well as connections to a matchmaking server 432. In this example, arrows indicate exchange of position data. Dotted lines are matchmaking queries. The matchmaking server 432 includes a plurality of profiles 750, each including at least an affinity factor such as a level identifier, as well as an IP address for the game console. The profile may also include demographic information such as preferred language.
A game console may instigate a query of the profiles 750. The results of the query, sent back to the game console, may include a playgroup 710. The playgroup 710 may include a number of slots 720 reserved for members of a friends list, and the remaining slots 730 are used for others with whom the first user has an affinity.
The following events may then take place in such an arrangement. Player A 702 enters the level, e.g., level 3, on his own. Player B 704 then joins level 3, finds player A, who is listed as a friend, and connects to player A (connection I). Player D 708 joins level 3, finds players A and B, with both of whom player D is friends, and connects to both (connections IIa and IIb). Player C 706 joins level 3, finds player D, to which player C is a friend, and connects to player D (connection III). Player C also finds two strangers, players A and B, and connects to them as well (connections IVa and IVb) based on affinity, in this case level, as determined by the matchmaking server 432. For example, players A and B may have been displayed in a playgroup for player C. Player E then joins, but player E joins level 5, and thus does not connect to any of the level 3 players (players A-D) due to lack of affinity. Any of the peer-to-peer connections may be formed, e.g., by a Winsock connection 703, or by any other type of peer-to-peer connection.
Variations of the above may also be utilized. For example, the use of a matchmaking server need not be mandatory by all players. While the present arrangement may be of particular use where player characters are moving over multiple levels and/or locales, it may be employed in any game and game system. The code for a given arrangement may be downloaded or may be implemented as stand-alone code that may be placed into any game. While any type of code may be used, conventional peer-to-peer connections may be established employing the standard Microsoft® Windows ® SDK®. The term “level” used here should be understood to mean any locality or unity of circumstance that may give rise to one player finding a grouping with another player potentially beneficial. In many cases, a level may mean a mission, a quest, a locality, or a stage.
While the present arrangement has been described in the context of a video game, it may also be implemented in an educational context, such as to allow students working online on common assignments or in the same grade to work together. Other applications will also be apparent. For example, variations in the rendering of virtual avatars in a user interface may include only rendering virtual avatars within an angle of vision of the first user's player character, rendering virtual avatars on a map display, and so on. In addition, while the context of inviting one other player and player character within a playgroup to form a group has been described, multiple players and player characters may also be invited at one time or sequentially.
While the arrangement has been described with respect to a game console, it is to be understood that the arrangement may be implemented in any number of computing systems, including laptop computers, desktop computers, tablet computers, handheld computers, mobile phones, smart phones, game consoles, and the like.
And although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A system for implementing peer-to-peer matchmaking in a game environment, comprising:

a game console configured for executing programming to implement gameplay in a game environment;

a matchmaking server accessible by the game console over a network, the matchmaking server comprising a plurality of profiles associated with a set of game consoles and respective player characters, each of the plurality of profiles including an IP address assigned to the game console and level information associated with the player characters;

memory in communication with the matchmaking server bearing computer-readable instructions capable of causing the matchmaking server to determine a playgroup and to send information about the playgroup to the game console, the playgroup a subset of the plurality of profiles;

memory in communication with the game console bearing computer-readable instructions capable of setting up a peer-to-peer connection with at least a portion of the playgroup; and

memory in communication with the game console bearing computer-readable instructions capable of rendering virtual avatars of at least a portion of the playgroup on a user interface of the game console.

2. The system of claim 1 further comprising memory in communication with the game console bearing computer-readable instructions capable of inviting a member of the playgroup to a group, and memory in communication with the game console bearing computer-readable instructions capable of receiving an acceptance of the member of the playgroup to the invitation so that if the member of the playgroup accepts the invitation, the memory in communication with the game console bearing computer-readable instructions is further capable of merging an instance of the game console with an instance of a game console associated with the member of the playgroup.

3. The system of claim 1 in which the memory in communication with the game console bearing computer-readable instructions is further capable of setting a high-water mark flag if a population of the playgroup increases to a predetermined high-water mark.

4. The system of claim 3 in which the memory in communication with the game console bearing computer-readable instructions is further capable of clearing the high-water mark flag if a population of the playgroup decreases to a predetermined low-water mark.

5. The system of claim 4 in which the memory in communication with the game console bearing computer-readable instructions is further capable of accessing the matchmaking server if a population of the playgroup decreases to a predetermined very-low-water mark, the accessing to request from the matchmaking server information about a playgroup.

6. The system of claim 1 in which the memory in communication with the matchmaking server further comprises memory bearing computer-readable instructions capable of causing the matchmaking server to perform a query of the plurality of profiles.

7. The system of claim 6 in which the query returns profiles that are on a friends list associated with a profile of the game console and further returns profiles that have an affinity with the profile of the game console.

8. The system of claim 7 in which the affinity is based on at least one of a common language, a common level of a respective plurality of player characters, a common geographic locale of the game consoles, a common style of play, or a common playing history.

9. The system of claim 1 in which a population of the playgroup is predetermined, and in which a subset of the population of the playgroup is reserved for members of a friends list.

10. The system of claim 1 in which the peer-to-peer connection is a Winsock connection.

11. A method for matching players in a video game, the method comprising the steps of:

initiating gameplay in a first instance of the video game for a first player;

retrieving from a matchmaking server information about a plurality of other players in a plurality of other instances of the video game, respectively, the plurality of other players forming a playgroup, at least a subset of the playgroup members of a friends list of the first player, and a remainder of the playgroup determined by an affinity to the first player;

establishing a peer-to-peer connection between the first player and each of the playgroup;

receiving position information indicating the position of avatars associated with the plurality of other player characters forming the playgroup in the respective plurality of other instances of the video game;

creating a virtual avatar for each of the other player characters in the first instance of the video game; and

rendering a graphic representation of the virtual avatars in a three-dimensional space in the first instance of the video game at a position that is based on the position information for the avatar associated with the other player characters in the other instances of the video game to enable the players to be found.

12. The method of claim 11 including the further steps of receiving an indication from the first player that one of the plurality of other player characters is to be invited to play in the first instance of the game, receiving an indication that the one of the plurality of other players has accepted the invitation, and updating game state information for the first instance of the video game to include the avatar for the one of the plurality of other players.

13. The method of claim 11 including the further steps of establishing a high water mark for the playgroup, in which if a number of members of the playgroup reaches the high water mark, then setting a high water mark flag and not establishing any additional peer-to-peer connections.

14. The method of claim 13 including the further steps of establishing a low water mark for the playgroup, in which if the high water mark flag is set, and if a number of members of the playgroup decreases to the low water mark, then clearing the high water mark flag and allowing the establishing of additional peer-to-peer connections.

15. The method of claim 14 including a further step of establishing a very low water mark for the playgroup, in which if the number of members of the playgroup decreases to the very low water mark, then repeating the retrieving step.

16. The method of claim 11 in which each peer-to-peer connection is a Winsock connection.

17. The method of claim 11 in which the affinity is one of a common geographic locale, a common language, a common level, a common playing history, a common style of play, or a common region of play.

18. The method of claim 11 in which a population of the playgroup is predetermined, and in which a subset of the population of the playgroup is reserved for friends.

19. A computer-readable medium containing instructions which, when executed by one or more processors disposed in an electronic device, perform a method for operating a video game including player characters controlled by players, the method comprising the steps of:

initiating gameplay in a first instance of a game for a first player;

retrieving from a matchmaking server information about a playgroup formed by other player characters in a plurality of other instances of the game, the playgroup determined by players or player characters being on a friends list of the first player or player character or by having an affinity with the first player or with a player character controlled by the first player;

receiving position information indicating the position of player characters associated with respective members of the playgroup in the respective plurality of other instances of the game;

creating a virtual avatar for each of the other player characters in the first instance of the game; and

rendering a graphic representation of each of the virtual avatars in a three-dimensional space in the first instance of the game at positions that are based on the position information for the player characters in the other instances of the game.

20. The computer-readable medium of claim 19 in which the affinity is based on one of a common geographic locale, a common language, a common level, a common playing history, a common style of play, or a common region of play.