Join in-progress on-line game session

Abstract

A computer-based, multi-player, on-line, game session is capable of being joined while the session is in progress without requiring an invitation from the host of the game session. A player can join the game session via a set of User Interfaces (UIs) provided by the gaming system. The player is not required to contact the host prior to joining the game session. A game session is joinable if slots are available for additional players, the host has not declared the game session private, the player requesting to join the game session is not currently in the game session, and parental controls have not be set preventing the player from joining the game session.

Description

COPYRIGHT NOTICE/PERMISSION

A portion of the disclosure of this patent document contains material, which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawings hereto: Copyright © 2004, Microsoft Corporation, All Rights Reserved.

TECHNICAL FIELD

The technical field relates generally to gaming and more specifically relates to joining on-line, computer-based games in progress.

BACKGROUND

Computer-based, on-line gaming provides the ability for a large numbers of players to play a large variety of games. Thus, at any point in time, numerous game sessions could be ongoing. Joining a game session, in progress, however, can be cumbersome and time consuming. In current systems, for example, a player wishing to join a game in progress must be invited to the game session. This typically requires the player to contact, either directly or indirectly, the host of the game session and request an invite. Contacting the host may be difficult. Further, if contacting the host takes too long, the invite could occur after the session is complete, or close to completion.

SUMMARY

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description Of The Illustrative Embodiments. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

A game player can join a computer-based, on-line game while the game is in progress. The player does not have to contact the host to request an invite. The player can join the game session without requiring an invitation from the host of the game session. The player is not required to contact the host, or any other player in the game session, prior to joining the game session. The player can join a game session in progress if slots are available in the game session, the game allows joining while in progress, and no settings preclude join in progress. The player can join the session by interacting with a User Interface (UI) provided by the game system. It is not necessary for the player to insert a game disc or to launch the game to determine whether the host is joinable. Thus, initiating the joining of a game session can be accomplished without requiring a game disc to be inserted into a game console and without requiring the joining party to have previously launched the game. Thus, a player can quickly scan all hosts that player may be interested in joining. If the game allows joining while in progress, but no slots are available, the player can wait in a lobby until a slot becomes available. Joining a game session in progress can be prevented if the host of the game session declares the game session private, if a player trying to join a game session is currently in the game session, and/or if parental controls prevent joining the game session.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing summary, as well as the following detailed description, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating joining in-progress on-line game sessions, there is shown in the drawings exemplary constructions thereof; however, joining in-progress on-line game sessions is not limited to the specific methods and instrumentalities disclosed. In the drawings:

FIG. 1 is a block diagram of an exemplary computer network environment in which aspects of joining an in-progress on-line game session can be implemented;

FIG. 2 is a block diagram illustrating an exemplary console that can be incorporated into a network computing environment such as the network computing environment of FIG. 1;

FIG. 3 is a block diagram illustrating the interaction of a console with the remote service;

FIG. 4 illustrates the information gathered to build a user profile;

FIG. 5 through FIG. 14 are example illustrations of a user interfaces displaying user profile information;

FIG. 15 is a flow diagram of an exemplary process for joining an in-progress on-line game session; and

FIG. 16 through FIG. 18 are example illustrations of user interfaces for joining an in-progress game session.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

FIG. 1 is diagram of an exemplary computer network that serves to illustrate aspects of joining an in-progress on-line game session. Here computers 100a-100e can host various ones of the computing objects such as games and other applications. Although the physical environment shows the connected devices as computers, such illustration is merely exemplary and can comprise various digital devices such as PDAs, game consoles, etc. Moreover, communications network 160 can itself comprise a number of computers, servers and network devices such as routers and the like.

There is a variety of systems, components, and network configurations that support distributed computing environments. For example, computing systems can be connected together by wireline or wireless systems, by local networks or widely distributed networks. Currently, many of the networks are coupled to the Internet, which provides the infrastructure for widely distributed computing and encompasses many different networks. Aspects of joining an in-progress, on-line game session can be usable to distribute computer-readable instructions, code fragments, applications and the like to various distributed computing devices.

The network infrastructure enables a host of network topologies such as client/server, peer-to-peer, or hybrid architectures. The “client” is a member of a class or group that uses the services of another class or group to which it is not related. Thus, in computing, a client is a process (i.e., roughly a set of instructions or tasks) that requests a service provided by another program. The client process utilizes the requested service without having to “know” any working details about the other program or the service itself. In a client/server architecture, particularly a networked system, a client is usually a computer that accesses shared network resources provided by another computer (i.e., a server). A server is typically a remote computer system accessible over a remote network such as the Internet. The client process can be active in a first computer system, and the server process can be active in a second computer system, communicating with one another over a communications medium, thus providing distributed functionality and allowing multiple clients to take advantage of the information-gathering capabilities of the server.

Clients and servers communicate with one another utilizing the functionality provided by a protocol layer. For example, Hypertext-Transfer Protocol (HTTP) is a common protocol that is used in conjunction with the World Wide Web (WWW) or, simply, the “Web.” Typically, a computer network address such as a Uniform Resource Locator (URL) or an Internet Protocol (IP) address is used to identify the server or client computers to each other. Communication among computing devices is provided over a communications medium. In particular, the client and server can be coupled to one another via TCP/IP connections for high-capacity communication.

In general, the computer network can comprise both server devices and client devices deployed in a network environment (in a peer-to-peer environment devices can be both clients and servers). Communications network 160 can be a LAN, WAN, intranet or the Internet, or a combination of any of these that facilitates communication among a number of computing devices 100a-100e. Moreover, communication network 160 can comprise wireless, wireline, or combination wireless and wireline connections. Additionally, the computer network can comprise a distributed computing environment. In such an environment a computing task can be spread over a number of computing devices that are addressable elements in a computer network.

According to an aspect of joining an in-progress on-line game session, communication network 160 can host a service 150 that is accessible from the plurality of computers 100a-100e. The service 150 gathers information and tracks users of computers 100a-100e to provide computing services for all of the users of the service 150.

FIG. 2 illustrates functional components of a multimedia/gaming console 100 that can be used as the computers 100a-100e in the network of FIG. 1. The multimedia console 100 has a central processing unit (CPU) 101 having-a level 1 cache 102, a level 2 cache 104, and a flash ROM (Read Only Memory) 106. The level 1 cache 102 and a level 2 cache 104 temporarily store data and hence reduce the number of memory access cycles, thereby improving processing speed and throughput. The CPU 101 can be provided having more than one core, and thus, additional level 1 and level 2 caches 102 and 104. The flash ROM 106 can store executable code that is loaded during an initial phase of a boot process when the multimedia console 100 is powered ON.

A graphics processing unit (GPU) 108 and a video encoder/video codec (coder/decoder) 114 form a video processing pipeline for high speed and high resolution graphics processing. Data is carried from the graphics processing unit 108 to the video encoder/video codec 114 via a bus. The video processing pipeline outputs data to an A/V (audio/video) port 140 for transmission to a television or other display. A memory controller 110 is connected to the GPU 108 to facilitate processor access to various types of memory 112, such as, but not limited to, a RAM (Random Access Memory).

In an exemplary embodiment, the multimedia console 100 includes an I/O controller 120, a system management controller 122, an audio processing unit 123, a network interface controller 124, a first USB host controller 126, a second USB controller 128 and a front panel I/O subassembly 130 that can be implemented on a module 118. The USB controllers 126 and 128 serve as hosts for peripheral controllers 142(1)-142(2), a wireless adapter 148, and an external memory device 146 (e.g., flash memory, external CD/DVD ROM drive, removable media, etc.). The network interface 124 and/or wireless adapter 148 provide access to a network (e.g., the Internet, home network, etc.) and can be any of a wide variety of various wired or wireless adapter components including an Ethernet card, a modem, a Bluetooth module, a cable modem, and the like.

System memory 143 is provided to store application data that is loaded during the boot process. A media drive 144 is provided and can comprise a DVD/CD drive, hard drive, or other removable media drive, etc. The media drive 144 can be internal or external to the multimedia console 100. Application data can be accessed via the media drive 144 for execution, playback, etc. by the multimedia console 100. The media drive 144 is connected to the I/O controller 120 via a bus, such as a Serial ATA bus or other high speed connection (e.g., IEEE 1394).

The system management controller 122 provides a variety of service functions related to assuring availability of the multimedia console 100. The audio processing unit 123 and an audio codec 132 form a corresponding audio processing pipeline with high fidelity and stereo processing. Audio data is carried between the audio processing unit 123 and the audio codec 132 via a communication link. The audio processing pipeline outputs data to the ANV port 140 for reproduction by an external audio player or device having audio capabilities.

The front panel I/O subassembly 130 supports the functionality of the power button 153 and the eject button 152, as well as any LEDs (light emitting diodes) or other indicators exposed on the outer surface of the multimedia console 100. A system power supply module 136 provides power to the components of the multimedia console 100. A fan 138 cools the circuitry within the multimedia console 100.

The CPU 101, GPU 108, memory controller 110, and various other components within the multimedia console 100 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 a Peripheral Component Interconnects (PCI) bus, PCI-Express bus, etc.

When the multimedia console 100 is powered ON, application data can be loaded from the system memory 143 into memory 112 and/or caches 102, 104 and executed on the CPU 101. The application can present a graphical user interface that provides a consistent user experience when navigating to different media types available on the multimedia console 100. In operation, applications and/or other media contained within the media drive 144 can be launched or played from the media drive 144 to provide additional functionalities to the multimedia console 100.

The multimedia console 100 can be operated as a standalone system by simply connecting the system to a television or other display. In this standalone mode, the multimedia console 100 allows one or more users to interact with the system, watch movies, or listen to music. However, with the integration of broadband connectivity made available through the network interface 124 or the wireless adapter 148, the multimedia console 100 can further be operated as a participant in the larger network community as illustrated in FIG. 1.

According to an aspect of joining an in-progress on-line game session, when a game is executed on console 100, it provides information to a service 150 operating on communications network 160. The service 150 tracks the information for all of the users connected to the service 150 to provide a rich user experience. The service 150 tracks user information across games, consoles, computing devices, etc. By tracking the information for all users of the service 150, the service 150 can aggregate statistics for all users and measure game playing ability, provide a richer user experience by providing information about friends (e.g., what game they are playing and what skill level they have attained), track user achievements, and generally measure statistics for a game aggregated over a large user community.

In order to provide a consistent data set across games, the system contemplates a schematized, configuration driven process where each game generates a configuration file (according to the schema defined by the service) that defines the game data for a particular game. Through a game configuration process, games describe the data the game generates about each game player. By using the configuration process, the service 150 is able to understand the data as it flows from the game, and is able to integrate it in meaningful ways with the other data that the service understands to create a rich profile, of each user of the service. The profile will follow the user wherever he goes on the service, i.e., it is game and location independent.

For each user (alternatively referred to as a player or gamer), the service collects a number of pieces of data (called Profile Data) to build the User Profile in every game session-and even after a game session is concluded. In general, the pieces of the service experience that feed a profile can include:

1. What the user says about himself/herself (including account set up and the construction of an elaborate personal profile, including the preferred social gameplay “zone”).

2. What others say about the user (feedback scores and a publicly visible reputation).

3. What the games say about the user (game configuration and integration of data that comes out of game play to compute a player's skill, among other things).

4. What the system says about the user (time online, aggregates of games played, Friends list, console behavior etc.)

The system creates a “User Profile,” which serves as a building block for services and applications that aim to create a social community of gamers and grow relationships among players. The User Profile is the entirety of information (e.g., metadata) related to a specific user (i.e., the game player's digital identity). The User Profile is developed from a set of services that collect and exposes this information in a meaningful way to the community. The User Profile also provides for personalization such that users can customize and enhance their gaming experience. The User Profile comprises various components, including, but not limited to, a Gamercard, game achievements, and gamer preferences.

Referring to FIG. 3, there is illustrated an overview of an exemplary architecture that can be used to implement the User Profile interaction as well as user interaction with the game session service. The console 100 interacts with a remote service 158 that provides services 161 such as voice/chat, a friends list, matchmaking, content download, roaming, feedback, tournaments, voice messaging, join in progress, and updates to garners. The service 158 also maintains the Profiles in a profile database 162 and configuration data 164 used by the services 158 and games 154. The service 158 collects Profiles, aggregates, processes information supplied by other services 158, and fulfills real-time client requests for retrieving Profile-related services. The Profiles in the database 162 are also used by the games 154 to enable, among other things, personalization and customization, etc.

Using the console 100, the user can interact with a Guide 156. The Guide 156 provides an interface by which the user can navigate to, and enter, various online areas and options provided by the remote service 158. The configuration data 164 stored by the service can be used to determine features and options provided by the Guide 156. When the game 154 is running, a defined set of APIs (including SetContext, SetProperty, SetAchievement, and Session APIs for writing data about players, and a number of specialized read APIs for viewing statistics, achievements, and other Profile data) are used to call and interact with the services 158. When requesting Profile information via the APIs, the game 154 can pass a unique identifier of a user. The service can return a Gamercard (discussed below), game statistics, game achievements, affiliations, game settings, etc. pertaining to a user.

Service 158 assists in tracking and displaying a wide-variety of in-game statistics, such as number of points, best lap times, and (importantly, for calculating the skill value needed in Matchmaking) win/loss. These statistics can be provided for a user. All statistics are provided by the various games that a user plays and provided to the service for inclusion in a player's User Profile. For example, a first-person shooter title may want to define a ‘Point’Property to be tracked independently for each ‘Map’Context (e.g 5 Points on Blood Creek vs. 10 Points on Battle Range). That information could be displayed as:

“PER-MAP POINTS”
Map          Points
Blood Creek  5
Battle Range 10

Referring to FIG. 4, the Profile 166 represents a User Profile. The Profile 166 is created when a user creates a profile (selected from the guide 156) and chooses his/her unique Gamertag (a unique name), tile (picture/avatar associated with the user), and other options during an account sign-up phase. From there, a base Profile 166 is created. The Profile 166 can then be populated from several sources. For example, the Profile 166 can include self-described data 168 from the Profile owner. Other gamners 170 can provide feedback regarding the Profile owner. The service 158 can track the gamer's online and offline activity. In addition, the games 154 can report the gamer's statistics and game achievements.

The owner of a Profile can edit his/her Profile 166 directly and control who can view each section of the Profile. The Profile 166 can be edited via general fields (e.g., tile, country, language, gender, greeting, etc.) and/or system settings (e.g., voice output, controller vibration, character name, game format, game mode, etc.). Privacy/Opt-out Settings can be tuned for the Profile to, e.g., restrict presence information only to friends, allow game achievements to be visible to all, etc.

The Profile 166 can include feedback provided by other players 170. Feedback helps others learn about a particular gamer. For example, if the gamer uses foul language or aggressive play in game sessions, other gamners can submit feedback to the service 158. The feedback mechanism improves user experience by building reputations. Players can therefore be anonymous, but not unknown because of the accumulated feedback.

In another aspect ofjoining in-progress on-line game sessions, the service 158 and games 154 track online and offline activity of gamers to provide usage statistics in the Profile 166. When a gamer plays online, a particular game title is added to list of games played that is made visible to others. While offline, the game console 100 and game 154 track the gamer's activity via a mechanism for instrumenting games to collect detailed information about a specific player's in-game statistics and accomplishments. The Profile 166 is updated during the next connection to the service 158 to reflect the offline play. Game achievements can be reported to the service 154 by games via the Gamer Profile data mechanisms.

As noted above the Profile 166 can be used for customization and preference setting on a global level, as well as a per game level. Gamer preferences aid games 154 in choosing defaults for common settings such as game profile name, controller inversion and controller vibration, etc. For example, if a gamer likes using an inverted controller, this preference will be used for new titles as they are played. Games 154 have access to Gamer Profiles via the database 162 and services 161. In addition, game usage data can be mined to tune the game 154 to the user's particular preferences and game features updated after the initial game launch.

A presence service can be included to provide information about user's whereabouts and activities. Presence information is available to those users that the gamer wishes to share it. The Gamer Profile is the primary ways to access the presence information.

Referring to FIG. 5 through FIG. 13, the Profile can be viewed in a number of ways and forms, and is typically displayed in the Gamercard 172. The Gamercard 172 is the visual representation of the Gamer Profile (e.g., Profile 166 as applied to a gamer) that is available to games on the console 100 and, e.g., the web. The Gamercard 172 serves as a summary or snapshot of a player's Profile 166. Gamers can use the Gamercard to set up a matchmaking list where gainers are added to a preferred players list to play again in the future.

As shown in FIG. 5, the Gamercard 172 can be divided into two regions, a base area 174 and a context-specific (or extended) area 176. The base area 174 provides a set of Gamer Profile information in a standard and consistent way across multiple contexts, whereas the extended area 176 can be customized to fit a specific context. Although the Gamercard 172 of FIG. 5 through FIG. 13 are shown in the context of the guide 156, the Gamercard 172 can be visually separated from the rest of the screen and adopt the background color of the screen it is displayed on. In addition, the Gamercard 172 can be temporarily replaced by an animation while it is being loaded for viewing.

The base area 174 can be provided in different variants corresponding to differing contexts, while being a consistent view within each context. For example, an online Gamercard 172 is shown when one player is looking at another player's Gamercard 172 during an online session. The online base area 174 includes details such as the player's Gamertag, gamer tile, overall community rating, gamer Cred (a points-based reward points system), gamer zone, country, membership tier, awards, etc. An offline Gamercard 172 is shown when a player is looking at his/her own Gamercard 172. The offline base area 174 can include a subset of the online base area and can further include information regarding titles played and time played. In an exemplary embodiment, the base area 174 of a Gamercard 172 can be fixed in size, have a consistent, static layout and have a fixed placement of all information elements, such as Tile or Gamer Cred.

The extended area 176 can include a set of Gamercard Actions, such as “View Profile” and “Send Feedback,” etc. In an exemplary embodiment, the extended area of the Gamercard is not fixed in size, because it can vary based on the context. As shown in FIG. 5 through FIG. 13 a user can scroll through the list of other users via the guide 156 and a friends list 178. The Gamercard for other users can be displayed as the user scrolls among his/her friends or the user can be presented with an option to see a full view of the Gamer Profile. The full view mode consists of different views of the extended area 176 and can include several sections, such as a Profile Summary, Community Feedback, Game Achievements, Activity, and Social Network. The guide 156 can advance through the list of friends, recent players (and summary sections for each player), a user home page for navigating to various options and settings, etc.

The profile summary includes information regarding number of games played, time played, tile, greeting, etc. The community feedback includes ratings on style, sportsmanship, language, cooperation, etc. The game achievements section includes recent titles, experience points (gamer Cred), time played, game-specific statistics and achievements, etc. The activity section includes Gamer Cred earned, sessions played, total time played, active days on the service, etc. The social network includes friends, groups, positive/negative feedback count, etc.

The system can match players to game sessions based on social and/or skill related interests. For online, multi-player games, Matchmaking connects a game player to a session. A Match made session is an instance of game play that includes 2 or more gamers playing a game until they either decide to terminate the session or until the session meets its end criteria (as defined by the game). In an exemplary embodiment, the person who creates the session is the host. Some games are hostless, meaning that the game does not assign any special function to the person who originated the game. In such a case, the originator can be a person who was searching for a session with specific criteria and, when it was not found, the game created a session for the person and advertised it for others to match into it. Matchmaking involves joining a session that has, as a minimum, one player already in place. A gamer makes a Match by selecting “Matchmaking” in a game or in an out-of-game Matchmaking system. The Matchmaking UI can allow a gamer to add some filters to his search for a session (e.g., specifying a map or difficulty level), or it can push a gamer directly into a search query. In most cases, with or without filters, a gamer is given a session search result which consists of a list of sessions. Each session is defined by a session descriptor that includes a short summary of pertinent information about that session. If no search result is shown, a player can be dropped directly in the lobby of the game that best meets his/her search criteria.

When a game player chooses to Matchmake into a session, in the first session, the profile data he has set describing himself is used to “prime the pump” and find the best fellow new gamers to play with. Just by playing, the game player associates with a group of fellow gamers who become “Recent Players” on the Affiliates List. The service preferably prioritizes playing with Recent Players over strangers in future session, but once a game player give positive feedback, these “positive feedback” people are remembered by the system and are given even higher priority. Over time, as a gamer becomes very familiar with a set of players, he invites them to become friends. These friend gamers are given higher priority.

In addition to Matchmaking based on a query with User Profile, the Social Matchmaking system, in conjunction with the tracking of friends, recent players, and feedback on recent players, builds a network of Affiliates who are prioritized for Match.

The Affiliates list is a prioritized list of people for a player that includes (1) Friends (i.e. people who the player has invited, and who have accepted the invitation, to a preferred social network that allows exchange of messages and state information), (2) Positive Feedback people (i.e., people about whom the player has given positive feedback), and (3) Recent Players. The Social Matchmaking service always looks first (before conducting the query above) for the presence of Affiliate sessions on the service. If any person on a player's Affiliates list is online and in a joinable session, the service will return that session. If there are multiple Affiliate sessions, the ones with Friends are given priority over those with Positive Feedback People or those with Recent Players. Positive Feedback People are given priority over Recent Players.

In accordance with the above, FIG. 6 illustrates a list of Recent Players in the guide 156. The Gamercard displayed, when browsing recent players, can show the base area and an extended area that provides information regarding recent games, feedback, and presence of the recent players. FIG. 6 through FIG. 9 illustrate further details that can be obtained about recent players, such as general achievements and gamer Cred (FIG. 7); game specific achievements, gamer Cred, times/sessions played (FIG. 8); and a date-sorted achievement display (FIG. 9).

FIG. 10 illustrates an exemplary user home page from which the user can navigate among the various options provided by the service 158, edit Gamercard information, change game settings, set preferences and privacy settings, etc. Such settings and preferences can be accessed using the exemplary user interfaces of FIG. 11, FIG. 12, and FIG. 13. It is emphasized that the user interfaces (UIs) of FIG. 5 through FIG. 13 are provided for exemplary purposes only and are not intended to limit joining an in-progress on-line game as recited in the claims.

There can be differences, between how the guide 156, games 154, and players trigger Gamer Profile viewing. One instance is a user-instantiated Gamercard. Here, if a user receives a request from another gamer, the user and/or the game can pause the game 154 and bring up the Gamercard 172 to find out who is sending the request. There can also be a game-instantiated Gamercard 172, where a user can select to view the Gamercard 172, which brings up a Gamercard system application.

Players can join an in-progress, on-line game session without requiring an invitation from the host of the game session. In fact, a player is not required to contact, prior to joining the session, any player currently in the game session. Further, a player is not required to launch the game to determine whether a session is joinable. Players can join games in progress via the Gamer Profile UI, for example, depicted in FIG. 14. As indicated in the area 180, a player has several options from which to select. For example, as depicted in FIG. 14, the player can invite another into a game session, join a game session in progress (182), send a message, compare games, file a complaint, and block communication. Selecting join in progress (182) starts a process for allowing the player to join the game indicated in the Gamer Profile. A game session can be joinable if there are open slots available to the person seeking a slot. Some games that have join in progress sessions will advertise that a session is joinable until every public slot is filled. If a slot is available, a gamer can select a session and join it. If all slots are filled, a player can enter a lobby and wait until a slot becomes available.

FIG. 15 is a flow diagram of an exemplary process for joining an in-progress on-line game session. As described above, the player can search for a game session to join. Upon finding a game session to join, the player decides to join the game in progress at step 200. An exemplary UI for making this selection is shown in FIG. 14. The UI indicates if the game session is joinable or not. For example, as depicted in FIG. 14, the selectable button 182 would not be rendered, or be grayed out for example, if the associated game were not capable of being joined in progress. Also, the selectable join in progress button 182 would not be rendered, or grayed out, if the player was already in the game session. Further, for games that are capable of being joined in progress, in an exemplary embodiment, the host of the game session can decide whether the game is to be public or private. If the host declares the game private, the game session can not be joined in progress (not joinable). If the host declares the game session public, and the game is capable of being joined in progress, the game is joinable in progress. This declaration could be implemented, for example, by setting a flag, or flags, in a call game session API. Also, a game session can be not joinable if parental controls, or the like, prevent a player from joining a game. Thus, a game session can be not joinable if no slots are available to accommodate additional players, if the game is a non-joinable game, if the host of the game session declares the game session private, if the player attempting to join the game session is currently in the game session, and/or if parental controls prevent a player from joining a game session.

A game session can be partially joinable. A game session can be joined within a time frame, during predetermined portions of a game, of a combination thereof. For example, a race game may be joinable until the race begins. As opposed to a shooter game that be joinable at all times and during all portions. Flags in a call game session API can be set to indicate if respective portions of a game session are joinable or not joinable. The game can give the session host the option to advance the session into a state where it is no longer joinable. Alternatively, the game can require all session participants to confirm their readiness in order to advance the session into a non-joinable state.

If the player decides not to join (step 202), the guide is closed at step 204. This might be the case, for example, if after selecting join in progress, the player realizes that he misplaced the game disc. Also at step 202, the source of the game code is determined. If the game code is in the memory of the player's game console, it is determined at step 206 if the player is currently in a game session. If the player is not currently in a game session (step 206), the game is launched at step 212 and the game session is joined at step 222.

If the player is currently in a game session (step 206), the player is asked if he wants to exit the current game at step 208. An exemplary UI for presenting this question is shown in FIG. 16. If the player does not want to exit the current game session, the player responds according (selects “No” as depicted in FIG. 16), the guide is closed at step 210. If the player decides to exit the current game session (selects “Yes” as depicted in FIG. 16), the game is launched at step 212 and the session is joined at step 222.

If the game (step 202) cannot be detected on any connected disk drive device, the player is prompted to insert the disk at step 214. An exemplary UI for prompting the player to insert the game disk is shown in FIG. 17. The player also is given the option to cancel the join in progress at step 214. If the player decides to cancel, the guide is closed at step 218. If the player decides to continue, the disk is inserted and the game is loaded into the game console at step 216. The game is then launched at step 220 and the session is joined at step 222.

If the game code was not found either in game console memory or on a disk (step 202), or the player selects to download the game code, the game code is downloaded at step 224. That is, if the game is not detected on the game console of the joining party, the game is automatically downloaded and launched at the joining party's console. In an exemplary embodiment, this is true only for the games that are configured on the system as “Downloadable.” If the game is not configured as Downloadable, then the user is informed that a disc must be inserted. In an exemplary embodiment, the player is told that the game could not be found and that the player has the option to download the game, search again, or cancel the join in progress. An exemplary UI for providing this information and presenting these options is shown in FIG. 18. If the player decides to cancel, the guide is closed at step 204. If the player decides to search again, the process proceeds to step 202. A player could be instructed to search again, for example, after attaching a removable memory unit. If the player decides to continue (select “Yes” as depicted in FIG. 18, the game is launched at step 226 and the session is joined at step 222.

If the player would rather create a game session than join an existing session, the player can proceed to a screen that allows the player to pick a game title for which he would like to create a session. At that point, the player can define the game based on the game configuration options. For example, the player can select the level of play, the number of players, and so on. After the player defines the game session (defined by the game in the configuration process), the player enters a game lobby until participants join. That game session will then show up on other gamers' screens that were searching for a game to join. Games set up in this way are “hosted” games (hosted by the player who created the session) that result in a game “Party,” and when they are completed, all of the players have the option of either continuing in the same game, letting the host change the game settings for that game, or returning to the out-of-game lobby.

Private Parties can be managed in by identifying the assembly of players in the party separately from the gathering of players for a particular session of game play. In addition to waiting for gamers to join the game session, the player can actively seek participants and build a Party. The player can browse the Gamercards on friends list, Recent Players list and or otherwise find garners with User Profiles that meet certain search criteria, e.g., having a certain skill level, locale, and/or reputation, or who are otherwise friends or Affiliates. After finding the various matching gamers, the player can invite them to join a Party session directly by sending that gamer an invite to the Party session. If the player accepts the invite, he is joined in the OOG match Party lobby. Alternatively, a voice channel can be opened whereby the garners can communicate, e.g., about the game session. Finally, while browsing for gamers, selected garners can be added to the player's Affiliates list so that they will be noted as Affiliates in future game selections.

Rather than selecting to join an existing competition, the player can create a new competition and invite other to join via the process described above. A player has two options to create an out-of-game competition. First, the player can quickly enter a competition out-of-game on the web or in the Guide that was previously defined in its entirety via the configuration process. That is, the game developer provides a predefined competition setting for a game that is provided to the service via the configuration data. In that case, the player selects a game and then selects one of the available predefined competitions for that game. Similarly, the player can create a custom competition by selecting a game that has competition enabled and defining the various parameters for the competition that were defined by the configuration data for that game, e.g., the number of rounds, single elimination, and so on. A player selects these options on the web or in the Guide and creates a competition structure.

Whichever, mechanism the player engages to enter the competition, after entering the competition, the service maintains the competition structure and is viewable on the service over a web connection or directly from the Guide on the console. The competition structure for example includes the topology of the competition, e.g., single elimination tree structure, match ups of the various competition entrants, and so on. A competition home is set up where the topology and match-ups are viewable, both on the web and in the Guide, by all participants. Thereafter, the information is sent to the host console 100, e.g., the lobby unique ID, unique competition ID, unique round ID and unique match ID and the game play arbitration is started. Each round then starts and completes. At then end of each round, each console sends results back to the host along with the competition ID, unique round ID and unique round match ID. Thereafter the next round of competition is set up by the service and the process repeats until the competition is complete.

Those of ordinary skill in the art will understand that there are various modifications that will fall within the scope of the appended claims. While joining an in-progress, on-line game session has been described in connection with the illustrative embodiments of the various figures, it is to be understood that other similar embodiments can be used or modifications and additions can be made to the described embodiments for performing the same function of joining an in-progress, on-line game session without deviating therefrom.

Claims

1. A method for joining an in-progress on-line game session, said method comprising:

determining if said in-progress on-line game session is one of joinable and not joinable;

choosing to join said game session if said game session is joinable; and

joining said game session without requiring an invitation from a host of said game session.

2. A method in accordance with claim 1, wherein:

a game session can be determined to be joinable without requiring a game disc to be inserted into a game console; and

a game session can be determined to be joinable without requiring a joining party to have previously launched said game.

3. A method in accordance with claim 1, wherein:

said game session is determined to be not joinable if said host of said game session declares said game session private; and

said game session is determined to be joinable if said host of said game session declares said game session public.

4. A method in accordance with claim 1, wherein:

said game session is determined to be not joinable if a player attempting to join said game session is in said game session; and

said game session is determined to be not joinable if said game session has no available slots.

5. A method in accordance with claim 1, wherein said game session is determined to be not joinable if parental controls prevent joining said game session.

6. A method in accordance with claim 1, wherein said game session is partially joinable.

7. A method in accordance with claim 1, wherein said game session is joinable if at least one predetermined flag in an application programming interface for starting said game session is indicative of said game session being joinable.

8. A method in accordance with claim 1, wherein, if a game is not detected on a game console of a joining party, said game is automatically launched at said game console of said joining party.

9. A computer-readable medium having computer-executable instructions for performing the acts of:

determining if an in-progress on-line game session is one of joinable and not joinable;

providing means for choosing to join said game session if said game session is joinable; and

providing means for joining said game session without requiring an invitation from a host of said game session.

10. A computer-readable medium in accordance with claim 9, wherein:

a game session can be determined to be joinable without requiring a game disc to be inserted into a game console; and

a game session can be determined to be joinable without requiring a game to be launched.

11. A computer-readable medium in accordance with claim 9, wherein said game session is not joinable if at least one of the following conditions is true:

said host of said game session declares said game session private;

a player attempting to join said game session is in said game session;

said game session has no available slots; and

parental controls prevent joining said game session.

12. A computer-readable medium in accordance with claim 9, said computer-readable medium having further computer-executable instructions for setting at least one predetermined flag in an application programming interface for starting said game session to be indicative of said game session being one of joinable and not joinable.

13. A system for joining an in-progress on-line game session, said system comprising:

a plurality of databases for storing information pertaining to whether said in-progress on-line game session is one of joinable and not joinable; and

a service for: determining if said game session is one of joinable and not joinable, in accordance with said information; providing means for choosing to join said game session if said game session is joinable; and providing means for joining said game session without requiring an invitation from a host of said game session.

14. A system in accordance with claim 13, wherein:

a game session can be determined to be joinable without requiring a game disc to be inserted into a game console; and

a game session can be determined to be joinable without requiring a game to be launched.

15. A system in accordance with claim 13, wherein:

said service determines said game session to be not joinable if said host of said game session declares said game session private; and

said service determines said game session to be joinable if said host of said game session declares said game session public.

16. A system in accordance with claim 13, wherein said service determines said game session to be not joinable if a player attempting to join said game session is in said game session.

17. A system in accordance with claim 13, wherein said service determines said game session to be not joinable if said game session has no available slots.

18. A system in accordance with claim 13, wherein said service determines said game session to be not joinable if parental controls prevent joining said game session.

19. A system in accordance with claim 13, wherein said service is further capable of setting at least one predetermined flag in an application programming interface for starting said game session to be indicative of said game session being one of joinable and not joinable.

20. A system in accordance with claim 19, wherein each predetermined flag is indicative of a respective portion of said game session being one of joinable and not joinable.