US20060258463A1

US20060258463A1 - System and method for network interactive game match-up and server selection

Info

Publication number: US20060258463A1
Application number: US11/434,314
Authority: US
Inventors: Jared Cugno; Amir Haleem; Jack Skeels
Original assignee: Professional Interactive Entertainment Inc
Current assignee: Professional Interactive Entertainment Inc
Priority date: 2005-05-13
Filing date: 2006-05-15
Publication date: 2006-11-16
Also published as: WO2006124811A3; WO2006124811A2

Abstract

A computer-based system and method of interactive game challenge and acceptance for finding an appropriate game server for one or more individuals to play on given skill level, latency and numerous other factors; setting up the game server with the proper parameters; connecting those individuals to that server; logging the details of the match; updating those details to a database and updating or creating statistics related to those individuals for display and ranking purposes to be used for later match-ups.

Description

This application claims priority of the provisional application with Ser. No. 60/680,848 filed May 13, 2005 entitled Method and Apparatus for Internet Network Game Challenge and Acceptance.

FIELD OF THE INVENTION

The present invention relates to internet gaming and more specifically to a method and apparatus for matching players of a particular interactive game on the internet, using one or more applications in several formats, including: a challenge and acceptance format, an immediate match-maker format, an intelligent match-maker format or other formats and providing continually updated statistical analysis for the games and the individuals involved in the match.

BACKGROUND OF THE INVENTION

The entertainment focus in network gaming has become more and more centered on player versus player confrontations. As games have progressed in complexity and as the proliferation of high-speed internet connections has grown, more and more players venture onto large interconnected networks of computers in order to find challenging opponents. The limits of game artificial intelligence are nothing, to a veteran gamer, compared to the challenge of competing against one or more highly skilled players behind the controls. Therefore, there is a desire in the art for a simple and easy method and apparatus by which a player can find opponents who are a challenge and provide an interesting match for players of all skill levels. Considerations in creating a matches include rankings, player or game ratings, gender, age, familiarity with the game or game genre and various other player and game characteristics.
To this end, several applications have been developed whereby a user may find opponents on the internet. These range in complication from simple web forums whereby users can specify certain game servers at certain times for individuals or groups to challenge each other to a match, to more complicated software or interfaces whereby a user is ranked over time or whereby individuals may actually launch a game in real time in order to play against or join in the play of a friend.
Nothing in the prior art, however, has provided a simple single interface for the interaction of players, a ranking system of players with real-time tracking of relevant game-play statistics, real-time push-button challenge, random or intelligent match-up of players, and server-side, peer-to-peer or client side control of the game server chosen and methodologies for finding a game server available for the match. In the prior art, some of this functionality has been built into a single game, an interface including some of these elements has been created or other interfaces with limited chat-centric functionality with no challenge and acceptance element has been offered. Alternatively, other prior art has offered little more than a list of game servers with the option to join has been provided.
This invention improves on the prior art by combining the many desperate elements into a single simple interface, including the option to challenge individuals and the option for those individuals to be immediately put in-game by the method of this invention in order to determine a winner. Further, the capability to find, quickly and effectively, the an optimal game server, based upon criteria established by the user or users available to each user involved is novel and nonobvious. Finally, capturing statistics, behavioral patterns, playtimes, playstyles, abilities, skills, user-defined data and other relevant player and game-related data and tracking this diverse data set in real-time for player (or teams of players). In the context of this document, player may be used interchangeably with “team of players,” “teams of players,” “group of players” or “groups of players.” The capture and use of this data in ranking and in the various match-making methodologies when combined with the prior elements of this invention is novel and nonobvious.

BRIEF SUMMARY OF THE INVENTION

According to the present invention, a method and apparatus are described whereby a user of the invention may challenge an individual (or team) to a game, an automatic match may be made using various methods or intelligent match-making using various criteria, which the individual (or team) may accept. The invention will aid users in finding an optimal server upon which each player is able to play based upon user input, automatically or based upon a data set built by the system and method of this invention. In the preferred embodiment, the game parameters are set by the invention, the game is then launched and played, various types of game and player-related data is tracked and recorded, and each player's (or team's) data is then stored for later use in analyzing the player (or team) for future matches. A new ladder or game ranking of the player (or team) is made based on this data, relative to all other players in the ladder or game.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a depiction of the foyer page of the method and apparatus of this invention.
FIG. 2 is a depiction of an eight versus eight team lobby or pre-game holding area
FIG. 3 is a depiction of a ladder lobby for a four versus four game.
FIG. 4 is a depiction of a team ladder pre-game holding area.
FIG. 5 is a depiction of a dialog popup for forfeiture of a match.
FIG. 6 is a depiction of a dialog popup for reporting a no-show match participant.
FIG. 7 is a depiction of a dialog popup for a private message sent to a user.
FIG. 8 is a depiction of a team ladder start sequence.
FIG. 9 is a depiction of a team four versus four lobby.
FIG. 10 is a flowchart of the steps involved in a challenge and acceptance match-up.
FIG. 11 is a depiction of a team four versus four lobby depicting a user's profile.
FIG. 12 is a depiction of a dialog popup for a challenge issued by a user.
FIG. 13 is a depiction of a one versus one pre-game holding area.
FIG. 14 is a depiction of a dialog popup for a challenge rejection to be rescheduled at a later time.
FIG. 15 is a flowchart depicting the steps involved in a “play now” match-up.
FIG. 16 is a flowchart depicting the steps involved in an “intelligent” match-up.
FIG. 17 is a depiction of the server and client architecture of the preferred embodiment.

DETAILED DESCRIPTION OF THE INVENTION

The present invention connects players who desire to play network computer games with each other. According to the preferred embodiment of the invention, a webpage is used, whereby users are able to login, using a user-selected user identification and a user-selected password. Methodologies to connect to a customized webpage (or other network-accessible interface) are common in the art and will not be described in great detail so as to avoid confusion over the scope of the present invention. The means by which an individual may select a username and password are implemented using traditional web database methodologies and algorithms. In the setup process, elements that are unique to the present invention include the setting of “available times” during which a user may be challenged to a game or may be automatically or intelligently set up for a match. These times may be further sub-divided by type of game, if desired. For example, and individual might set as available playtimes times from 2:00 pm-6:00 pm each day. If the online during those times, individual is are available for challenge or for team play. Alternatively, a user may be available from 2:00 pm-4:00 each day for one type of game as, for example, single player match-ups; where from 4:00 pm-6:00 pm each day his or her team is available for a particular type of game only and only as a team.

Individual and Team Competition Structure

Referring now to FIG. 1, once the user has created a login and password and logs in, the user is then presented with a customized webpage. FIG. 1 is an example of such a webpage, though numerous differing versions of this webpage and all other interfaces described herein are available while still accomplishing the goals of this and other web pages. This webpage provides various forms of information to the user. In the preferred embodiment, hypertext links to numerous sections of the website will be provided, such as forums, news, and other data about games and the individuals active on the game server. Among other things, a web foyer, as depicted in FIG. 1, appears which includes games for which the user is involved in a ladder, league or other competition structure. On the foyer page, one may presented with multiple competition structures, one for each game the individual has played or to which they have subscribed as being available to play a game. For example, in FIG. 1, element 100, is the ladder for Battlefield 1942® 8 versus 8 “Deathmatch.” Multiple competitions structures may be presented for each game, such as the two game ladders depicted in element 102. There may also be various tournaments and leagues to which a user may subscribe or in which to participate. If one has already scheduled a match in a particular ladder and the time for commencement of that match is near, a button or link similar to the one depicted in element 104 may be shown. Clicking this button or link will bring up the match lobby for that pre-scheduled match.
The server which hosts these ladders, leagues, match-ups and tournaments in the preferred embodiment is a web server. This web server is connected, in the preferred embodiment, to a chat/lobby server. The chat/lobby server's responsibility is to match up players once they have chosen to challenge each other, be available for match-up or to take part in a ladder, league or tournament. Generally, the chat/lobby server is connected to the client software on each individual's computer and is capable of accepting direction from the client software concerning potential match-ups for games, then assists in game server selection on which the player will play those games, launches the game server with the proper parameters and instructs the client software to launch the client game software and connect to a particular server to begin the match. Alternatively, some games for which this methodology can be used will not use independent game servers. In these cases, typically, one of the two (or more) clients is used as a server, to which all other users connect before the match is played. The system and method of this invention may be used in those situations, whereby the word “game server” will refer to one of the client computers chosen to act as the “server” for that game and to which the other client computers will connect. The details of the chat/lobby server's operation in the preferred embodiment will be described in greater detail in subsequent paragraphs.
One improvement over the prior art are the built-in competition structures and methods for gathering the information used to create and maintain the competition structures. Competition structures include team and single player ladders, team and single player leagues, team and single player real-time match-ups (both intelligent/criteria-based match-ups and immediate match-ups), team and single player tournaments, team and single player practice matches and numerous other game and match-up formats. Leagues are similar to ladders, except they are typically more structured, requiring a series of games to be played at set times over the course of a series of weeks or months. At the end of a “league,” the top players may be awarded or may be “seeded” in a final League Tournament. Match-ups of all types are typically more fluid and subject to ongoing competition.
An example of one type of competition structure is a “ladder” system. A ladder is a ranking system for determining an order of skill for online players as they play. Ladders have been employed in multiple types of games, including traditional sports teams and have been imported, more recently, into the interactive entertainment field. In FIG. 1, the user is a member of six ladders, one of which is depicted in element 106, “Battlefield 1942 8 versus 8 Deathmatch.” Additionally, more detailed data may be displayed, such as player ranking on those ladders. This data is retrieved from a database of player data maintained on a server available to the webpage. In the preferred embodiment data is displayed detailing the number of players currently logged on who are members of the particular game's ladder (or other competition structure), an example of which is shown in element 108. Numerous other types of data are stored for every team or player using the system and method of this invention.
Another competition structures available to players is a tournament-style play. Single and double elimination tournaments for each type of game and player match up (i.e. one versus one, four versus four, free-for-all, etc) may also be constructed. The individuals in these tournaments will login to the match server and their tournament schedule for the day or week will be displayed. They may have a certain window, for example three days, in which to play a particular game versus someone else in their bracket. The tournaments, in the preferred embodiment are set up among players of similar skill, typically from players in the higher-rankings of the ladders of each type of game. League play results in a group of individuals or teams of the same type in the same game all playing each other or most of each other at least once. The team with the best record at the end of the “season” is the league winner or may be seeded in a league tournament.
For each of the competition structures; rewards and prize allocation is automatic. Once an administrator has setup a particular competition structure; the prizes for that competition may be set. Once the winners have been determined at the end of a set period of time, a “season” or tournament; the prizes are mailed to the confidential addresses of the individuals or team. Alternatively, they may simply be emailed with information on how to receive their prizes.
Referring now to FIG. 2, in the preferred embodiment, the web site is also capable of use as a team-creation mechanism. A logged-in user may create a “team” for a particular ladder or tournament. To create a team, the user selects options that enable the team-creation functionality. Then, the user enters details about the team, such as a team name, logo, profile and the type of ladder(s) or tournament(s) in which the team wishes to compete. The name of an example team is visible in element 114. The logo of an example team is visible in element 116.
Once created, team membership may be requested by selecting usernames, example usernames of individuals already in the selected team are visible in element 118, or by typing them into a list. The individuals associated with the usernames will receive an email or pop-up message (if they are currently logged into the client software) requesting their approval for inclusion in the team. Once an individual clicks a link in the email accepting team membership or click the “I approve” option in the pop-up message, by responding to an instant message, by responding to a “text” message on a cellular phone or other form of confirmation, membership to that team is confirmed. The individual is then able to challenge, be challenged, or participate in ladders, tournaments and leagues as a team member. Alternatively, join passwords may be provided to individuals prior to the creation of a team and individuals may join the team through their own action, once it has been created, using the join password.
Teams may be subdivided into multiple squads, organized by the team leader. A team leader is the creator of the team at the start, but may be changed once the team has been created. Team management into squads (sub-groups of teams) may be arranged and managed by team leaders or squad leaders. The capability to determine available play-times and other team attributes may be set by the team or squad leader depending on the management settings set by the team leader. A team may participate in different ladders, tournaments or leagues for different games or types of matches for each game.
The competition structures visible to an individual or team may be further subdivided by type of game play. For example, for a particular type of game, there may be competition structures for individual one versus one play, team four versus four play or squad eight versus eight play, as seen in FIG. 1, elements 100, 110 and 112. The types of ladders, leagues, instant match-ups or other competition structures available to an individual to subscribe to will largely be dictated by the type of game for which the structure is created. Some games may be capable of large-scale numerous connections, while others may only allow connections for one versus one play. The competition structures will be created and monitored by individuals involved in the administration of the site.

Game Lobbies

Each of the competition structures, for example the one versus one ladder for a particular game, will have “lobbies.” An example lobby is depicted in FIG. 3. There is, also, in the preferred embodiment, a lobby for individuals simply waiting to play any game generally. These individuals may be members of multiple competition structures, but wish to await a challenge or match-up to any type of game for which they are a member of a competition structure. These lobbies are waiting areas for individuals to join in anticipation of playing that type of game versus other individuals. A user may always change lobbies simply by clicking a button, an example of which is seen in element 126 and selecting a new lobby. Additionally, a user may be in any number of multiple lobbies at any given time. The user may wish to be available for any number of competition structures awaiting a match. For example, all individuals wishing to play a four versus four team game of Unreal Tournament 2003® will be logged into the lobby for that game. In a particular game-type's lobby, individuals will be able to see the usernames of other individuals in the lobby waiting to play. In FIG. 3, element 120, the users in the ladder lobby for Unreal Tournament 2003® are shown. The individual usernames, in the preferred embodiment, will also be able to be selected and various operations may be performed by an individual selecting another individual's username. For example, the individual may see the user's record on a particular game, as seen in element 122. Additionally, a user may see the ladders which a particular user is subscribed to, as seen in element 124. Alternatively, dependant upon the type of ladder lobby entered, the individual may see an entire team or squad's record and profiles by clicking on an individual member of the team in, for example, a lobby dedicated to a particular game with a four versus four or eight versus eight format. They may seek to see the individual's overall profile. This profile in the preferred embodiment may included data such as the individuals overall ranking on each competition structure in which they take part, the individual's record of wins and losses, kills and deaths, and other relevant statistics. The profile may also include data such as location, hobbies, user description, or other relevant information, depending upon the user's input. Additionally, visible data and other player and game-related data may be used to generate more subjective information. This profile could include prior ratings or write-ups about that player, either by the individual user, the player or other users. The profile could also include criteria, based upon relevant data, concerning the likelihood that the user and that player are a “good match” for a game, as individuals being of similar skill, playstyle, ability, record or other subjective criteria. Several pieces of these data are visible in element 122. A more detailed profile is available by selecting to view a user's profile.
The lobby for a particular game is launched by clicking the link for the game and type of play, such as Battlefield 1942® 8 v 8 Deathmatch depicted in element 100. Once the link is clicked, an application is launched from within the web-browser in the preferred embodiment. The main or “general” lobby may also be started in much the same way by clicking on a link dedicated to a general lobby, in the preferred embodiment detailing the total number of users logged into the general lobby. In alternative embodiments, the entire application may be stand-alone, requiring no web-browser portal for login. Alternatively, the entire application may be web-based. However, in the preferred embodiment, a java applet is launched by clicking on the link to a particular ladder. In the preferred embodiment, the java applet is responsible for most of the interaction between the client computer and the various server computers and other client computers. This applet, unless otherwise described will be referred to as the client software. The client software in alternative embodiments, may be stand-alone software, completely web-based or built-into the network software of various games. The java applet is only the preferred embodiment of the client software.
Once the link, depicted in element 106, has been clicked, in the preferred embodiment, a java applet window appears. Referring now to FIG. 4, an eight versus eight team ladder lobby or pre-game holding area that appears when a ladder lobby is selected is depicted. Lobbies are available for every type of competition structure described above. A ladder lobby is used here only for descriptive purposes. In other lobbies, much of the same types of actions are available and much of the same data is displayed to the user. In the preferred embodiment, the title of the lobby is displayed as shown in element 128, the usernames of individuals currently viewing that lobby is displayed and a chat window is displayed in element 130. For example, in FIG. 4, the ladder lobby title, depicted in element 128, is Battlefield 1942® 8 versus 8 Deathmatch. All individuals present in the lobby are depicted in the non-focused tab “in this room” tab shown in element 132. Also show is a focused tab for a buddy list in element 134. This buddy list contains the names of individuals whom the user has flagged as buddies. Also present in the preferred embodiment is the ability to review a user or team's profile, either in summary form or by right-clicking on a name and requesting a full profile. In summary form, in the preferred embodiment, the user's current rank, wins and loss record for the current ladder lobby are displayed as in elements 136 and 138, the number of challenges denied and any winning or loss streak. Also included in the preferred embodiment is a subjective ranking of the match-up between the two players. In a more detailed form, additional information may be displayed, such as age, location and time zone that the user has chosen to input into their profile. Additionally, a user may view an individual's full profile, in the preferred embodiment, by right clicking on that individual's username and selecting “view profile.” When this is done a full version of a user profile is displayed including the competition structures to which that individual belongs and the records, ranking, current streak, challenges denied and other relevant data, as described above, usually dependent upon the game, for each competition structure. In the preferred embodiment, the profile is displayed in a normal web page window using the web browser. Alternatively, the java applet may display the profile.
The competition structure's lobby may be used as a pre-waiting area before a game is launched or a challenge is made. As above, the user may be waiting in multiple lobbies simultaneously, so as to be available for multiple types and formats of games. This can serve to increase the likelihood of finding a match more quickly. From within this window, a user may “chat,” communicate via typed messages, with other individual's in that lobby. This functionality is depicted in the chat window 140 and the chat input box 142. Additionally, a user may simply review the individuals who are present in the lobby by viewing a tab entitled “in this room,” depicted in element 132. This tab will have a top to bottom scrolling list of the usernames of all individuals in the lobby. Some users may have “guild” or “clan” tags on their usernames. These tags are special monograms or other identification associated with the username, to identify those individuals as being a part of the guild or clan. Text chat will appear in another scrolling window with the option for the individual user to add his or her input, such as depicted in elements 140 and 142. If the competition structure is a group competition structure, such as two versus two or four versus four ladder matches, the lobby may also serve as a waiting room in which to wait until all the members set to play each other at a certain time arrive. The ladder lobby depicted in FIG. 4 is being used as a pre-game holding area.
Another functionality of the invention is to allow the scheduling of matches between individuals or groups for a time at some point in the future. These matches may be set up during the “challenge” dialog, through a “challenge later” dialog, through direct contact between the parties, through an automatic match-up for a later time, through “automatic” weekly or monthly scheduling as a part of a tournament or league, set up using the website or numerous other methods. Once all individuals have arrived for a prescheduled match, and have entered the game lobby or pre-game holding area, the match is almost ready to begin. There are buttons to the right side and bottom, in the preferred embodiment, which are used to indicate readiness, as in the “ready” button in element 144. This button indicates that the user is ready for the match to begin. Once all (or most) individuals have entered the room, the “ready” button 144 becomes available for clicking.
In the preferred embodiment, there is an “exit/forfeit” button 146 used to leave the lobby and forfeit the match. The exit/forfeit button 1346 allows an individual to leave the match, but at the cost of forfeiting the match. Should a player for one side or one of the individuals in a scheduled match fail to check-in during the alloted time frame, the match will be automatically forfeited. The results of clicking the exit foreit button 146 are shown in FIG. 5. The user will be presented with a popup box where element 152 is a “Yes, Forfeit the Match and Quit Application,” element 154 is a “No, Exit the Application, I will be back for the Match” and element 156 is a “Cancel” button. Forfeiting will affect the individual or team's record and ranking, but will enable an individual to leave who must immediately. There is also a “report no-show” button 148 that only is enabled when the time for the match has passed and which is used, once the match start-time has come and gone, to “report no-show” players and to force the other side to forfeit, depending on the ladder rules.
The results of clicking the “report no-show” button are depicted in FIG. 6. The user is present with a dialogue box that asks, in element 158, “Are you sure you that your opponent is a no show?” This is an attempt to avoid reporting no-shows before they really are no-shows. Additionally, the clicking of this box is logged, along with all of the individuals present in the room when this box is clicked. This may be used later to decide, if questioned, if there really was a no-show situation. This is because no-show situations affect ranking and ladder statistics. The choices are “yes,” shown in element 160, and “no”, shown in element 162.
Finally, referring again to FIG. 4, there is a “rules/help” button 150 that can be used to determine the rules of the match and to request help from administrators or web-based help. The rules/help functionality will bring up a dialogue box that will display various match-related criteria such as the match setup, the game to be played, the map on which the match will be played, the number of participants, the game type (two versus two, team, free-for-all, one versus one), and any custom rules dependant upon the game itself. These criteria may include options such as: friendly fire enabled (the ability to inadvertently harm one's team members), time, frag (number of kills by an individual or team of another individual or team) or flag limits or abilities or options that will not be available to the players. Also available to the players may be server-selection criteria such as a subjective “quality” of the server, server load, latency maximums for all players or other server-related criteria.
In the preferred embodiment, a “check-in” system is employed for pre-scheduled maps prior to entering the pre-game holding lobby. Using the check-in system, as each player arrives, up to thirty minutes before a scheduled match in the preferred embodiment, they can check-in to the match to be played. Once all the players are checked-in for a match, it will begin at the scheduled time. Checking in is done using the “ready” button 144, shown in FIG. 4. Additionally, the internet protocol address of the checked-in player will be logged to help insure against the possibility of another player logging in on behalf of a player involved in the match. This will aid in combating potential cheating in the game by having another player play for one or more of the individuals involved in a particular match.
Users may also chat individually with each other using means similar to those of chatting with the group at large. FIG. 7 depicts an individual one on one message between users. The dialog box depicted may be created by double clicking on a username anywhere in the application or by double clicking on usernames listed one's buddy list 134 or in this room 132 tab. This dialogue box enables private messages to a single individual to be sent. The individual to whom the message is sent is show in element 164 and the text to be sent is depicted in element 166. The “send” button 168 will send the desired text and the cancel button 170 will not send the text and will close the dialogue box.
Referring now to FIG. 8, once the individuals for the match have all arrived, as indicated by waiting for 0 players to join, depicted in element 172, and the ready button 144, from FIG. 4, or functionality has been enabled by all (or substantially all, as required by the rules of the particular competition structure) participants being present, player may select “ready” usually by clicking on the button. This process is depicted in the chat-box show in element 174. Once all (or substantially all, as described above) individuals have indicated that they are “ready” through clicking the “ready” button, element 144 in FIG. 4, or through other means, a match will commence. Each user has indicated that they are ready to play, as is output in the box in element 174. Finally, the announcement is made that the game will start in 15 seconds, as shown in element 176, and the match server finds and launches the game server, connecting the participants.

Methods of Match-Up

There are numerous methods which may be utilized for matching players for games. One example of a match-up methodology is the “challenge and acceptance” methodology, whereby one player selects another player and “challenges” them to a match. Another methodology, described below, is the “play now” methodology. In this type of match-up, the software's capability to view past statistics and data is used to find a “good” match-up automatically for a user. Another methodology is to allow the user to intelligently choose a match, based on various criteria. The software may then search the available players for an opponent meeting those various criteria. There are numerous other methods available, such as “scrimmage” now or predetermined scheduled matches also available to the user. The three methods described below are only for purposes of illustration.

Challenge and Acceptance Functionality

A lobby, as described above and seen in FIG. 9, may also used as a “staging area” for challenges. A challenge is one example of the way in which a match may occur. It is only one of several methods of taking part in various competition structures or match-ups. A challenge within a lobby may be initiated by a single individual in the case of lobbies dedicated to one versus one play or by a “team” or “squad” leader in lobbies dedicated to four versus four or other team-oriented play. Challenges are real-time requests for a match between two individuals or teams. A challenge may be initiated by right-clicking on a username and selecting “Challenge Now” or alternatively by highlighting a user's name and clicking the challenge now button, seen in element 178, that appears on the main interface of the ladder lobby. Additionally, if a highlighted individual username is a member of a particular ladder, the user may click a button to join that ladder, seen in element 180, and to become available for challenges on that ladder during available times. The user may also choose to challenge later, by clicking on the button in element 182. This button may be used to set up challenges at a later date.
Referring now to FIG. 10, a flowchart of one embodiment of a match-up, called the challenge and acceptance play sequence is depicted. First, an individual or team joins a particular lobby or ladder, as shown in element 182. An individual or team captain may then select an individual or group to challenge, shown in element 184. Next, the user challenges the individual or group, as shown in element 186, using a method described more specifically below. The challenged individual now is presented with three options of acceptance. First, they may decline, which will return the challenger to the step depicted in element 188, select an individual or group to challenge. If the user declines, they may select to schedule the match 190 for a later time. This option may be used when the current time is inconvenient for the challenged individual or group. Finally, the individual or group may accept the challenge immediately 192, which will cause them to enter the pre-game holding area 194. Next, the match will be set up 196, using a procedure more fully described later, but summarized in elements 198 through 204.
First, all players arrive in the pre-game holding area and indicate that they are ready 198. Once all players are ready, the game servers, there are many in the preferred embodiment, throughout the world, ping the clients 198. Next, the game server is selected 200 using predetermined criteria, including the ping times from the clients, as described more fully below. Finally, the players join the game server 202, based upon those criteria, automatically. Next, the match is played by all players, with statistics and data about the match being stored 204. The ladder ranking and statistics are updated 206 using the new data.
The flowchart may be described more fully by reference to a few additional figures. Referring now to FIG. 11, an UT2K3 Team 4v4 Ladder Lobby is depicted. “UT2K3” is Unreal Tournament 2003®, currently a popular multiplayer game. In the preferred embodiment, numerous games will be available, including newer games as they are released. The lobby has numerous people in it, depicted in the “in this lobby” tab 208 on the right. When no user, or when one's own username is selected in this menu, one's own ladder and match information is displayed. For example, user information may be depicted, such as in element 2, upcoming matches may be depicted, such as in element 21 and current ladders of which one or one's team is a part of may be depicted as in element 21. As in the prior depiction of a lobby in FIG. 4, users may view chat in the chat window 216 or input chat into the chat input box in element 218. Most importantly, however, one may challenge another or a group from this lobby.
Referring again to FIG. 9, once an individual's name has been highlighted, such as “Ganchmaster” in element 220 the “challenge now” button 178 or right-click “challenge now” option becomes available. Additionally, the “challenge later” 182 button becomes available. Referring now to FIG. 12, issuing the challenge will bring up a further dialog box to the individual being challenged. The dialog of the preferred embodiment appears in FIG. 12. This dialog will contain the individual issuing the challenge 222, the type of match being challenged 224, such as UT2K3 Player versus Player (PVP). Also displayed are current and three potential ladder rankings, as show in element 226. The current ladder ranking is based upon a user or group's current statistics and record. The potential rankings are based on the possibilities available to the individual. If the user accepts the challenge and wins, a certain ladder ranking will be awarded. This information is displayed along with the potential ranking if the user accepts and loses or if the user simply rejects the challenge. A ladder competition structure is shown here for simplicity, but various other types of structures offer similar functionality. For example, if this were a league lobby, instead of depicting potential ladder rankings dependant upon the outcome of the match, the next match-up, the potential league rankings or “advance to the semifinals” would be displayed.
The user may “challenge” another individual whose username is visible to a game of the type of the lobby that they are in or to any other competition structure type in which they are involved along with the user. The individual may be limited in terms of his ability to challenge by several factors. For example, the user may not be “available” for challenge at that point, one of the numerous settings the user may input as he sets up an account. If the individual happens to be on at times other than the “available” times, the user may or may not be penalized for not accepting a challenge. In the preferred embodiment, the user is not penalized for failing to accept a challenge during time designated as “not available” for play. However, setting these times in the preferred embodiment also limits the individual's ability to challenge others in times other than the “available time.” In the preferred embodiment, an individual may not challenge another during time designated by them to be “unavailable time.” However, in spite of all of this, if both players (or teams) are online simultaneously, the “challenge now” functionality will be available to both players (or teams).
Referring again to FIG. 12, the challenged individual, at this point, may choose one of three options in response to the question “do you accept this challenge?” as shown in element 228. Option one is to accept the challenge now, as depicted in the button denoted in element 230. This means that as soon as all challenged individuals (more than just the challenger and challenged if it's a team-based or group challenge) are present, the match will begin. Alternatively, the challenged may choose to reject the challenge, as shown in the button denoted by element 232. Using this option, the match will not start, but the individual may take a small loss in ranking, as shown in element 226, due to the failure to accept a challenge from someone. Finally, the user may accept the challenge, but set it up for a later date, as shown by the button denoted by element 234. This third option does not cause a loss in the challenged ranking, but brings up a further text box, denoted by element 236, whereby the challenged and challenger may set up a time at a later date when they will both or all (in the case of team or group matches) be available for a match. Also in this dialog box is the option to include a message to the challenger about the acceptance, refusal or challenge later options.
Referring now to FIG. 13, a pre-game holding area for a one versus one challenge game is depicted. Once the challenged individual or group has accepted the challenge or all individuals for a pre-scheduled challenge or match have arrived in the lobby, the individuals are moved to a pre-game holding lobby for their game. In FIG. 13, there are only two participants in the game, whose usernames are depicted in element 238. The details of each individual or each team including: records, statistics, wins losses, type of connection to the internet and location are displayed in elements 240 and 242. These are selected details from the individual's or group's profile. The window itself is very similar to that of a lobby, except that only individuals about to enter a particular game are within the lobby. There are the names of the individuals listed in the “In This Room” tab, shown in element 238, on the screen and there is a text box for chatting between the individuals or teams depicted in element 244. Also displayed in this room is the type of game being played and the name of the game, such as UT2K3 PvP Deathmatch, shown in element 246. Also, are the same buttons depicted in FIG. 4 for ready, exit/forfeit, report no-show and rules/help as shown in element 248.
Referring now to FIG. 14, if a player rejects a challenge, but chooses to reschedule the challenge for a later time, a display similar to the one depicted is presented to the challenger. A dialogue box containing text informing the challenger that the challenged individual has rejected the challenge is shown, as in element 250. Within this dialogue box is a text box containing the reason the challenge was rejected as input by the challenged individual or team, as shown in element 252. The challenger has but one option, “ok” as shown in element 254. The match will be scheduled, based upon available playtimes of both individuals or teams.
An example may demonstrate the steps described to this point. The first step is for a user to login to the webpage. This is done using typical login algorithms standard in the art. Once the user has logged into the site, the competition structures are displayed in which that user participates. So, for example, Battlefield 1942® 4 v 4, Counter-Strike®: Source 8 v 8 and Warcraft® III 1 v 1 may be displayed as ladders which this user participates. The user may then select one of those competition structures, such as Battlefield 1942® ladder by clicking on it. Once the user clicks, the java applet is launched and the ladder lobby for Battlefield 1942® is displayed. This lobby will have a text box, the user's buddy list, a list of individuals in the room. It will also have the option to challenge any four-person group (this is a 4 v 4 ladder) to a match.
The user may see a group of players who he has played before or who he knows is well-ranked. The user may view the ranking of those players by highlighting their names in the “In This Room” section of the lobby. When this is done, their profile as a team will be displayed. Their ranking may be number 15 overall in this ladder, whereas the individual's team, who are all currently present, may be ranked 24. The user may then challenge that team by highlighting one person's name and selecting “challenge” either as the button or by right clicking on a name and selecting “challenge” in the menu that appears.
At this point, the challenged may review the challenge window that appears on the challenged client software. This window will contain the opposing team's profile, their current ranking of 25, the ranking results of potential outcomes. For example, the dialog may display that if they refuse the match, they will be ranked 16, if they accept the match and lose the match, they will be ranked 17. If they accept the match and win, they will be ranked 14. This individual, may immediately accept the match or may schedule it for another date.
For purposes of the example, the challenged individual accepts the match immediately on behalf of the team being challenged. The challenger and challenged are then “moved” to a pre-game holding lobby. In this room, the profiles of the team, including the rankings, are displayed for both parties. The parties may chat while they await the arrival of all eight players. Once all eight players have arrived, the “ready” button will be available. Once all eight players have clicked the button, the match will be ready to commence.

The “Play Now” Functionality

Referring now to FIG. 15, a flowchart depicting the steps involved in a “play now” match-up are depicted. This is another type of match-up available to players in any lobby at any time. The first step is for a player to join a lobby 256. In the lobby, a player may select a button entitled “Play Now” (or perform other similar action) 258. At this point prior matches and team play in the particular competitive structure (such as a ladder or team play) will be used to create a “good” matchup between the players. If the player (or team) is relatively good, a player (or team) of similar skill will be automatically found based upon various criteria, including ranking, prior match-ups, recent play, playtimes, and numerous other criteria. A group of other opponents who have selected “play now” or who are otherwise available for play are searched for a “good” match 260. Then an opponent (or opponents depending on the game) is automatically selected based upon those subjective criteria 262. The optimal server is found for the players 264, including a determination of latency and based upon other player-input criteria such as server type, bandwidth, availability or server quality rating. The match is automatically set up 266 using one of the methods described above. The match is played and the data described above is generated and stored 268. This data is used to update the database of data, profiles and other rankings in a manner similar to that described above 270.

The Intelligent Match-Up Functionality

Referring now to FIG. 16, a flowchart depicting the steps involved in an “intelligent” match-up are depicted. This is yet another type of match-up available to players in any lobby at any time. The first step is for a player to join a lobby 272. In the lobby, a player may select a button entitled “Find a Match” (or perform other similar action) 274. At this point data pertaining to prior matches and team play in the particular competitive structure (such as a ladder or team play) will be used, by the user, to select or narrow choices down to a match between players. In the preferred embodiment of this match-up type, once the user presses the “Find a Match” button, he or she is presented with a dialogue box containing several suggested match-ups based on the data provided and the other players currently in the lobby or otherwise logged into the system. Next, the player is presented with numerous characteristics and criteria 276, in the preferred embodiment presented as drop-down menus whereby the player may select characteristics such as game type, player ranking ranges, winning percentage of opponents or any other objective or other criteria such as a subjective “good match” as determined by an algorithm using the available profile data in the database. The user then narrows his or her player-selection criteria 278. An opponent meeting those criteria will be found 280 who are available for play and a match will commence if that player or team accepts the match 282. The match will be played and data generated and stored 284. The data, profile and rankings will be updated using this newly-generated data 286.[0046] An intelligent match-up may also be made by means of a “standing order” to find “good” matches issued by the user, such that when that user logs in, based on his or her profile and other data, in conjunction with the profile and other data associated with other players a “good” match-up may be suggested by the software when that player or team first logs into the client software.

The Server/Client Structure Embodiments

Referring now to FIG. 17, the overarching structure of one embodiment of the invention is depicted. The method and apparatus of this invention runs using client/server software. The client software 288 is made up of the lobby software or client software 290 and game client 292 running on an individual's computer. Typically, many individuals using the client software 290 will be logged into a single chat/lobby server. Many lobbies exist for any number of game types, in the preferred embodiment, on multiple chat/lobby servers. The client software 290 is responsible for displaying the lobbies and pre-game waiting rooms, providing an interface from which to chat, maintaining a list of “buddies” and displaying profiles. The client software 290 is also used to communicate when individuals are ready for matches to begin and to send and accept challenges from other players, including the option to set up challenges for the future, and to setup or accept other match-ups. The client software 290 also determines an individual's ability to be involved in a particular game ladder, by checking to see if the individual has the current game client 292 software for that game. Once a challenge has been accepted or a match otherwise begun, the client software 290 also is responsible for launching the game client 292 software on the individual's computer, for example, the Battlefield 1942® executable file. The client software 290 uses the proper arguments (commands given to the software at startup) to launch the game and to connect it to the selected game server 300 for the match.
The chat/lobby server 294 is responsible for allowing multiple client softwares 258 to connect, chat, schedule matches, initiate criteria-based match-ups or automatic match-ups, challenge each other and to maintain a database of scheduled matches and profiles. The chat/lobby server 294 also maintains in a database, such as the one depicted in element 302, including competition structure rules, members, player and game-related data, rankings and player and team profile data including requirements for involvement in a particular structures. The individual and team profiles, as described above, will also be maintained, in the preferred embodiment, on a database server 302. The database server 302 will maintain information for each user, the competition structures they participate in, and other relevant information pertaining to the user. The database server 302 may also houses a list of game servers, one of which is depicted in element 300, on which matches may be played. In the preferred embodiment of the invention there are multiple game servers housed in numerous places throughout the world. This will enable the chat/lobby server 294 to select the optimal game server 300 for two individuals to play.
Game hosting servers 296, each capable of hosting multiple game servers 300 (of which there are many different types) may be found or allocated using numerous methods. In one embodiment, game servers 296 may be pre-selected always-running hardware located in strategic places around the United States or the world. A “strategic place” being a place in the midst of numerous potential player locations such that latencies will be low for players in that area (latency and game server selection is discussed below).
In an alternative embodiment, game hosting servers 296 may be individual user servers with an additional piece of software running such that they “inform” the chat/lobby server 294 that they exist. These servers would, typically, be less favored as they may not provide the best and most accurate game conditions for high-level competition. In situations in which valuable prizes would be awarded, these servers would, often, not be the first choice for matches.
In the preferred embodiment of the invention, the game hosting servers 296 would work in a peer-to-peer fashion. Peer-to-peer networking has become very popular in recent years in the art. The general idea is to allow the network itself to do the work which has typically been assigned to a single server (or cluster of servers). This provides several benefits. First, using peer-to-peer technology lets computers solve their own problems. If peer-to-peer technology is used, the software maker need not worry about server uptime as much, since the network of client software is typically, in the art, responsible for making most decisions.
Second, peer-to-peer technology is less expensive to maintain. The server software and server framework in a peer-to-peer situation need not be as robust as the usual server/client model common in the art. Because the server in the peer-to-peer technology is responsible for less of the work than it would be, were the client softwares not being used. For example, recent Voice Over Internet Protocol (VoIP) software uses peer-to-peer networking in order to send calls. This software has peer-to-peer clients locating each other and helping to forward calls along to each other. This lessens the bottlenecks of bandwidth which may occur if all of those VoIP calls were routed to a single location (the main server), then transmitted outward from there. If that were the case, large-scale VoIP might be impossible, but using the interconnection of the network itself, the bandwidth usage remains spread and the VoIP can be high-quality and fast.
In the game server and game server selection context, the game hosting servers 296 each “bid” for the opportunity to host each game. The game hosting servers 296, in the preferred embodiment, use a small piece of software that is always-running. This piece of software keeps track of the type of games the server is capable of hosting, the current “load” on the game hosting server 296 including the Central Processing Unit's (CPU) utilization, the network utilization and the potential load from prior or soon-to-start game instances. This software also contacts all known chat/lobby servers 294 for matches which are or will soon be in need of a game server 300. The game hosting server 296 then requests that it be put in a “bid queue” for the chance to bid on upcoming matches. The software on the game hosting server 296 is informed by a list maintained on the chat/lobby servers 294 of upcoming and pending games and will request to be put in the queue for a chance to “bid” for a given match. The number of active “bids” for a match is limited, in the preferred embodiment to fifteen, so as to not “flood” the clients offline with huge numbers of ping requests when the latency-detection process is initiated (as described below). Once an a game hosting server 296 is needed, those in the queue which meet the criteria are allowed to “bid” whereby their characteristics (if the user has selected to use any number of characteristics as limiting factors) are evaluated and they are asked to “ping” the client computer 288 who will be playing. They will then inform the chat/lobby server of these latencies and other characteristics. If the latencies are unavailable, the chat/lobby server may request that the client software 290 ping the game hosting server 296 instead.
The game hosting servers 296 are ranked using criteria, including player rankings as to their experiences playing on that server and using objective measures such as the server CPU load and the current and upcoming network usage. Also considered are the specifications of the game hosting server 296 and a server administrator set number of concurrent games or bids allowed.
In this process the chat/lobby servers 294 will continuously update a list of upcoming matches and matches waiting to be allocated a game server 300. The chat/lobby server 294 also manages the game hosting server 296 bid request, bid authorization, bid receipt and bid-ranking processes. The chat/lobby server 294 maintains a database of the currently available game hosting servers 296 as they inform the chat/lobby server 294 of their availability for utilization and as they make bids. The database would be housed on the database server 302. This database would also maintain the player ratings of the game hosting servers 296 and other relevant data related to the game hosting servers 296. In one embodiment, “better” rated or performing game hosting servers 296 may be awarded in some way by virtue of their being “better.”

Latency Detection and Game Server Selection

One game hosting server 296 may be better-suited to host a game than other game hosting servers 296. The most important considerations for gamers may be the above described player ratings, the current network and CPU load on those game hosting servers 296, the latencies of those game hosting servers 296 and other user-selected criteria. The user may choose to only play on well-rated servers or to play only on servers in a particular region (the west coast or east coast or mid-west of the United States). Users may even select to play, only, on their self-hosted server. Any number of criteria may be considered or be selected to be required by a player or players involved in a given match. All of these factors will be considered against the currently “bidding” game hosting servers 296. Once a group of servers has been selected using those criteria, if the users has selected to consider latency, the least latent of those servers will be selected by determining the latency of those servers using the following method.
Once each individual (or substantially all, as required by the rules of the particular competitive structure) has selected the “ready” option to begin a match, this is signaled to the chat/lobby server 294. At this point, the chat/lobby server 294 then coordinates with each of the game hosting server 296 to determine the latencies of each of the game participants. In the preferred embodiment, the chat/lobby server 294 requests that each of the available game hosting server 296 for the requested game perform a ping on each of the clients involved in the match. Alternatively, the client software 290 may perform a ping on each of the game hosting servers 296 to determine the latency of each client and then report that to the chat/lobby server 294.
A ping is a networking term that is well-known in the art. When a computer is pinged (the verb) by another computer, this ping “bounces back” in a fashion similar to that of a SONAR ping. The time at which the ping is sent is recorded by the first computer and the time at which the other computer's reply to the ping is received is also recorded. This results in a latency or ping (the noun)—the time it takes for one packet of data to travel from one computer to another computer and back to the first computer. In online gaming the latency is very important to a user. The better the latency (lower latencies are better), the more responsive the online game is to the player's movements. A very poor latency to a game server may result in a player's inability to control their avatar effectively and loss of a match or individual fight within the game. Latencies are largely determined based upon the connections used by the computers at either end. The locations of the computers involved are also a very significant determinant of latencies. Two computers connecting to each other each in the same city will typically have very low latencies, assuming each has a relatively fast network connection to the internet. Two computers communicating with each other across the nation, for example, from New York to Los Angeles will have a higher latency than two computers both communicating in Los Angeles.
Typically, avid gamers desire latencies less than 50 milliseconds. As latencies get higher than 100 milliseconds, the ability to control the actions of the avatar in the match degrade, reaching near unplayability at a latency of somewhere above 300 milliseconds. However, the importance of the latency is largely dependant upon the interactivity and pace of the game being played. For some games, latencies over 2000 milliseconds (2 seconds) will not affect game play at all. Examples of these types of games are typical online games such as hearts, checkers and chess. However, the types of fast-paced action games being played using the method of this invention will be very dependant upon a good latency, for example of 50 milliseconds, if attainable, or less. Additional criteria, as described above in the preferred embodiment, are used in selecting a server, such as the game hosting server's 296 CPU load, network utilization, upcoming (scheduled or allocated matches) network and CPU load and player ratings of the server created over time from player reviews. Once those criteria are met, latency is considered.
Once each player's latencies, after a ping, are received by the game servers, they are forwarded on to the chat/lobby server 294. The chat/lobby server 294 then, using the ping and other criteria requested by the user (or automatically), determines which game hosting server 296 will is the optimal server for the individual's involved to play the match. This is done by comparing the two lists of latencies-one for each person. The list is first narrowed, in the preferred embodiment, by finding all latencies for both parties for each game hosting server 296 that are within 15 milliseconds of each other. In other embodiments, particularly where latencies are not as important, larger latencies may be used. However, in the preferred embodiment, closely-matched latencies will be sought and 15 milliseconds of latency has been chosen as the range of acceptable differences between the parties. Removing latencies that are widely varying from each other will result in a narrowed latency list of potential game servers that are very close to the same latency for each party. Next, from those potential game servers, the lowest combined latency is chosen.
This concept may be understood more fully through the use of an example. For simplicity, an assumption is made that the four challengers in each group are in one room, connected to one network connection. This allows us to assume that their latencies to a particular game server are the same or substantially similar. For purposes of this example, the challenger team is in Los Angeles, Calif. and the challenged team is in New York, N.Y. Both have agreed to a match and all parties have shown up at the proper time or the challenge has been accepted in real-time. At this point, the chat/lobby server 300 software accesses its database 302 to determine the potential game hosting servers 296 for that type of match. In the preferred embodiment of the invention, numerous game hosting servers 296 for each type of game that a competitive structure has been created are available. The chat/lobby server 294 then requests that each of those game hosting servers 296 on that list ping all of computers of the participants and record the latencies sent back. The recorded latencies are then forwarded back to the chat/lobby server 294. The chat/lobby server 294 then performs the calculations necessary to assure both parties receive the best possible latencies for the match.

So, for simplicity the assumption is made that there are only three potential game hosting servers 296 on which to play. As stated above, in the preferred embodiment, there are numerous game hosting servers 296 available throughout the world so that any player may find a low-latency game hosting server 296 no matter where they are in the world and no matter who they challenge in the world. One of the game hosting servers 296 in this example is located in Los Angeles, Calif. and the other game hosting server 296 is located in St. Louis, Mo. The list of latencies received by the chat/lobby server 294 appears similarly to as follows:

Game Hosting Server/Player Latency Table

Game Hosting	Player Group One	Player Group Two
Sever Location	(Los Angeles, CA)	(New York, NY)

Los Angeles, CA	10 ms latency	70 ms latency
St. Louis, MO	30 ms latency	36 ms latency
Phoenix, AZ	20 ms latency	34 ms latency

The chat/lobby server 294 then uses the algorithm described above to determine the optimum game server for both parties. The first step is to narrow the list to one of only those game hosting servers 296 that have latencies within 15 milliseconds of each other. To do this the latencies are subtracted from each other as depicted in the following table:

Game Hosting Server/Player Latency Table

	Player	Player
	Group One	Group Two
Game Hosting	(Los Angeles,	(New York,	Latency	Eliminate
ServerLocation	CA)	NY)	Difference	From List

Los Angeles, CA	10 ms	70 ms	60 ms	Yes
	latency	latency
St. Louis, MO	30 ms	36 ms	6 ms	No
	latency	latency
Phoenix, AZ	20 ms	34 ms	14 ms	No
	latency	latency

As can be seen, the Los Angeles, Calif. game server will be removed from the list of potential game servers because the difference in latency is greater than 15 ms as required in the preferred embodiment. In other embodiments, larger latency differences or smaller latency differences may be used, dependant upon the needs of the players being matched. Alternatively, differing “tiers” of latency differences may be used. If the 15 ms latency difference is unattainable, the software may seek latencies less than 30 ms difference, then 60 ms and so on until the smallest difference possible is achieved.

The next step is to review the data to determine, in the now-narrowed list, which two latencies are the combined lowest for the parties. To do this, the two (or more in other types of matches) latencies are added together to create a data set similar to the following table:

Game Hosting Server/Player Latency Table

	Player	Player
	Group One	Group Two		Chose
Game Hosting	(Los Angeles,	(New York,	Total	This Game
Sever Location	CA)	NY)	Latency	Server

St. Louis, MO	30 ms	36 ms	66 ms	No
	latency	latency
Phoenix, AZ	20 ms	34 ms	54 ms	Yes
	latency	latency

Using this data, the chat/lobby server 294 is able to tell that the lowest combined latency is the game hosting server 296 located in Phoenix, Ariz. with a combined latency of 54 milliseconds. This game server is then chosen to be the game server for the match.
Once a selection of game hosting servers 296 has been chosen using this method, the chat/lobby server 294 communicates with the chosen game hosting servers 296. This communication is used to set up the match soon to start. This communication is automated and is designed to set various settings prior to the start of a match. These settings are largely determined by two factors. One factor is the game and ladder themselves. The ladder that the players are involved in may have set rules, such as the four versus four player game required by the particular ladder in our example. Additionally, there may be certain other requirements based upon the competition structure or game, such as time limits or frag (as described above) limits that are required as a part of being involved in a particular ladder. The other factor is the individual's launching the game themselves. To some extent, as the challenger challenges an individual, the challenger is able to set the parameters of the game, so far as they are allowed to be altered based upon the competition structure rules.
Based upon the player selected criteria, including the latencies of the player and the customization potential of the matches for a particular type of game, the chat/lobby server 294 then sets all relevant settings including the map (the level on which the game will be played), the time limit, frag or flag limit, and other relevant game settings. The chat/lobby server 294 then starts the game server 300 with those settings. The chat/lobby server 294 then also, in the preferred embodiment, sets a password for the game server 300. Only the chat/lobby server 294 knows the password and in the preferred embodiment, this password is not passed along visibly to the client software 290. Instead, once the clients have clicked the ready button, the chat/lobby server 294 performs the functions described to set up and start the game server 300. Once the game hosting server 296 is selected by the chat/lobby server 294, set up and started; the chat/lobby server 300 then forwards to the client software 290 for each individual involved in the map, the location (typically an internet protocol address), port (reference to a specific network port the game server is “listening” on for connections) and password that it has created for the match. The individuals using the client software 290 never see, in the preferred embodiment, any of this information. In alternative embodiments, the user may be supplied with this information and may be able to connect manually or without a password at all. Alternatively, the individuals involved in a pre-scheduled match may be emailed the password, internet protocol address and port for a game server to join at a scheduled time.
The client software 290 on each individual's computer then launches the game client 292 software of each individual's computer and connects them to the proper game server 300 and port using the password supplied to the client software by the match software. The game client 292 software on the individual's computer then starts, connects to the selected game server 300 on the selected port using the password as supplied. Once each individual is connected to the game server 300, the match begins.
As the match goes on, for a particular game, data is generated about the match. For example, as a kill is made by one individual or team, data about that death is generated. For example, for Battlefield 1942® data about which individual did what percentage of the damage to another individual in making a kill may be created. Also, data about which weapons were used in the kill by each player may be created. The time of the kill is likely logged. Throughout the game, as it is played, data may also be created such as percentages of attacks that landed or accuracy ratings for shooting in game. Titles may be attached to various activities, such as killing more than three individuals on the opposing team in a row may be dubbed a “killing spree” by a particular game. Shields and buffs (limited time enhancements to avatars within the game) may be acquired. Additional weapons or upgrades may be acquired by the players. Goals or sub-goals may be accomplished in the course of the game. All of these events and happenings generate data that is or may be recorded. For some games or game types, the game may create logs of this information. In other games or game types, a program residing on the game hosting server 296 may record relevant information or additional information not otherwise recorded by the methods employed by the game. The data generated using either of these methodologies will be referred to in the remainder of this document as a “data log.” Finally, the data concerning which individual or team won the match and under what rule, such as a certain number of kills reached or having the most kills in a set time-period, is recorded. All of this data is or may be recorded by the game server 270 or recorded by other means and stored in data logs.
In the preferred embodiment, at the end of the match, the chat/lobby server 294 requests that the data logs of the match be sent to the database server 302. These data logs are sent by the game hosting server 296. The preferred method of sending these data logs uses an FTP (File Transfer Protocol) client 298. These data logs will contain a great deal of information about the match, containing some or all of the data described above along with additional data about the match and players that may have been recorded during the course of the match. In the preferred embodiment, the database server 302 then compiles the data in these data logs and organizes the relevant portions of it for storage. The database server 302 then compiles or to recompiles a profile for each team and individual including the newly generated data, prior data. The most obvious statistics which may be generated from this data are number of wins and losses. Winning and loss percentages may be calculated. The individual players may be ranked within a team based upon their number of kills in all matches combined or for a more recent set time-frame. The most accurate shooting player on a particular ladder may be calculated from the database date for numerous games. The “most deadly” player on a particular ladder may be calculated using various statistics stored in the database server 302. The chat/lobby server 294 and database server 302 are used, potentially in conjunction with additional servers, to calculate various additional statistics and some or all of these are made available to the public using one or more web sites to which all individuals on a given ladder login. In the preferred embodiment, a record of every match played by each individual or team is recorded along with all relevant data. This data may be used to compile numerous other types of data and information, such as behavioral patterns, typical playtimes, player habits, player streaks or numerous other types of information.
This data and information is useful to the individuals on the ladder in comparing teams or individuals. The data may also be used to create more sophisticated ranking systems whereby win/loss record may not be the only factor included in the rankings. The data may also be used to more readily compare one individual player's contribution to the team or group situation than mere anecdotal evidence. Using the data generated from the match, the rankings of the two individuals, two teams or group of individuals are updated. Generally, winning a match raises the ranking on the ladder and losing generally lowers the ranking. In the preferred embodiment, win/loss record, number of forfeits, current points score (points being awarded for victories based upon the ranking of the individual or team defeated) and activity level (games being played weekly or monthly) are used to rank players or teams. A more complicated algorithm than simple win/loss percentage is used, but these algorithms are based upon the games themselves. For example, a ladder for team four versus four Battlefield 1942® might consider win/loss record, the opponents faced, the percentage of kills to death, the number of flags lost, the number of flags remaining and accuracy of each member of the team in shooting.
Also at the end of a match, either side may post comments about the match, both to be included in the profiles of both teams or individuals and on the forums. These comments or ratings of the other players or teams may also be incorporated into the relevant data. They may also provide feedback about the match to administrators of the competitive structure. This information, if it arouses the suspicion of the administrator may result in a review of the match and an alteration of the scores or invalidation if the match is determined to be fraudulently undertaken or if cheating was used. This review process is useful for ensuring accurate statistics and rankings.
In the preferred embodiment, the capability to record and/or broadcast either via the Internet or via live or recorded television a match is also included. The game server on which a match is played, for example, by two relatively-skilled teams may be monitored with software capable of “watching” the match in real-time. This software may create a feed for live Internet or television broadcast. Alternatively or additionally, the software may create a recording of a match from one or numerous players perspectives and save that file for later broadcast via the Internet or television. Additionally, in the preferred embodiment, users will be able to upload recorded portions or complete matches to a database server. This recorded match will be stored in the database server 302 database along with the data and other statistics for that match to be included in the complete record of the team's match history and profile. The profile, along with the statistics and any recorded or uploaded video or images from the match may be viewed along with the rest of the individual or team profile.
Administrators in this system may have varying levels of responsibility and access to portions of the site and to administrator capabilities. These range from being able to post responses on the forums to being able to create and manage groups of ladders, tournaments and leagues. Additional capabilities include the ability to remove users from the user-list, the ability to alter scores or revise scores based on user feedback or the ability to create content for the web site.
It will be apparent to those skilled in the art that the present invention may be practiced without these specifically enumerated details and that the preferred embodiment can be modified so as to provide additional or alternative capabilities. The foregoing description is for illustrative purposes only, and that various changes and modifications can be made to the present invention without departing from the overall spirit and scope of the present invention. The present invention is limited only by the following claims.

Claims

1. A computer-based method of network interactive match assignment and server selection for an instance of a computer game, comprising the steps of:

receiving a first player in a game lobby;

receiving a second player in said game lobby;

transmitting a request from said first player to said second player to play the match;

setting up the match between said first player and said second player; and

providing information sufficient to enable said first player and said second player to play the match.

2. A computer-based method of network interactive match assignment and server selection for an instance of a computer game, comprising the steps of:

receiving a first player in a game lobby;

receiving a second player in said game lobby;

transmitting a request from said first player to said second player to play the match, wherein said transmitting step includes at least one of the following alternatives:

a) challenging said first player to the match immediately,

b) challenging said first player to the match scheduled in the future,

c) requesting that the match be automatically found and started,

d) selecting limiting criteria based upon which the match is automatically found and started

e) requesting that a scrimmage match be automatically found and started, or

f) requesting the match using communication means;

setting up the match between said first player and said second player; and

3. A computer-based method of network interactive match assignment and server selection for an instance of a computer game, comprising the steps of:

receiving a first player in a game lobby;

receiving a second player in said game lobby;

a) challenging said first player to the match immediately,

b) challenging said first player to the match scheduled in the future,

c) requesting that a match be automatically found and started,

d) selecting limiting criteria based upon which a match is automatically found and started

e) requesting that a scrimmage match be automatically found and started, or

f) requesting a match using communication means;

using criteria selected by at least one of said first player or said second player to narrow game or game hosting server selection;

determining the latency from at least one game hosting server to at least one of said first or said second player;

selecting the game hosting server;

preparing said selected game hosting server for play by at least said first player and said second player; and

4. The method of claim 1, wherein said transmitting step includes a challenge to the match from said first player to said second player.

5. The method of claim 1, wherein said transmitting step is accomplished using an automatic match-up.

6. The method of claim 1, wherein said transmitting step is accomplished automatically using criteria selected by at least one of said first player or said second player.

7. The method of claim 1, wherein said setting up step includes consideration of at least one of the following:

a) determining the latency from at least one game hosting server to at least one of said first player or said second player;

b) using criteria selected by at least one of said first player or said second player to narrow game or game hosting server selection;

c) selecting a game hosting server;

d) preparing said selected game hosting server for play of a game by at least said first player and said second player.

8. A computer-based method of choosing an interactive game hosting server on which to play an interactive game comprising the steps of:

determining the players who are to be involved in a game;

requesting that at least one available interactive game hosting server ping said players;

removing interactive game hosting servers whose combined latencies to said players are more than a predetermined amount; and

selecting an interactive game hosting server from the remaining interactive game hosting servers using predetermined criteria.

9. The method of claim 8 wherein said predetermined criteria is choosing the interactive game hosting server with the lowest combined latency among said players.

10. The method of claim 8 further comprising a step following the determining step of narrowing the list of potential interactive game hosting servers using criteria set by at least one of said players.

11. A computer-based method of collecting data pertaining to interactive games and ranking players based on the data comprising the steps of:

monitoring an interactive game as it takes place;

collecting data pertaining to said interactive game; and

using the collected data to create at least one of statistics, indications of behavioral patterns, player rankings, player profiles, server rankings or server profiles.

12. The method of claim 1, further comprising the additional steps of:

monitoring the match as it takes place;

collecting data pertaining to the match; and

using said collected data to create at least one of statistics, indications of behavioral patterns, player rankings player profiles, server rankings or server profiles.

13. A computer-based peer-to-peer method of allocating game hosting servers for a network interactive match assignment, comprising the steps of:

receiving indications of game hosting readiness from at least one game hosting server;

adding said game hosting server to a bid queue;

receiving a request for a game hosting server allocation in order to play a match;

selecting at least one game hosting server in said bid queue to bid to host the match;

collecting bids to host the match from said at least one game hosting server in said bid queue; and

selecting one of said at least one game hosting server to host the match.

14. The computer-based method of claim 13, wherein said collecting bids step comprises receiving at least one of the following from said at least one game hosting server:

current latency data;

anticipated latency data;

current central processing unit load;

anticipated central processing unit load;

maximum number of allocable matches;

number of currently allocated matches; or

current bandwidth limitations.

15. A computer-based system for network interactive match assignment and server selection for instances of computer games, comprising:

at least one coordinating server designed to enable match allocation;

means for connecting at least two match participant client computers to said coordinating server, said two match participants client computers including interactive game software capable of network match play; and

means for connecting a plurality of game hosting servers, said game hosting servers including software designed to enable a bid process to host the match.

16. A computer-based system for network interactive match assignment and server selection for instances of computer games, comprising:

at least one coordinating server designed to enable match allocation using a bid process comprising the steps of:

a) receiving indications of game hosting readiness from at least one game hosting server;

b) adding said game hosting server to a bid queue;

c) receiving a request for a game hosting server allocation in order to play a match;

d) selecting at least one game hosting server in said bid queue to bid to host the match;

e) collecting bids to host the match from said at least one game hosting server in said bid queue; and

f) selecting one of said at least one game hosting server to host the match.

means for connecting said at least one game hosting server, said at least one game hosting server including software designed to enable said bid process to host the match.

17. A computer-based system for choosing an interactive game hosting server on which to play an interactive game comprising:

means for determining the players who are to be involved in a game;

means for requesting that at least one available interactive game hosting server ping said players;

means for removing interactive game hosting servers whose combined latencies to said players are more than a predetermined amount; and

means for selecting the remaining interactive game hosting server based upon predetermined criteria.

18. The system of claim 17 wherein said predetermined criteria is choosing the interactive game hosting server with the lowest combined latency among the players.

19. The system of claim 17, further comprising additional means for narrowing the list of potential interactive game hosting server using criteria set by at least one of said players.

20. A computer-based peer-to-peer system for allocating game hosting servers for a network interactive match assignment, comprising the steps of:

means for receiving indications of game hosting readiness from at least one game hosting server;

means for adding said game hosting server to a bid queue;

means for receiving a request for a game hosting server allocation in order to play a match;

means for selecting at least one game hosting server in said bid queue to bid to host the match;

means for collecting bids to host the match from said at least one game hosting server in said bid queue; and

means for selecting one of said at least one game hosting server to host the match.

21. The system of claim 20, wherein said collecting bids step comprises receiving at least one of the following from said at least one game hosting server:

current latency data;

anticipated latency data;

current central processing unit load;

anticipated central processing unit load;

maximum number of allocable matches;

number of currently allocated matches; or

current bandwidth limitations.

22. A computer-based system for network interactive match assignment and server selection for instances of computer games, comprising:

means for receiving a first player in a game lobby;

means for receiving a second player in said game lobby;

means for transmitting a request from said first player to said second player to play the match;

means for setting up the match between said first player and said second player; and

means for playing the match.

23. A computer-based system for network interactive match assignment and server selection for instances of computer games, comprising:

means for receiving a first player in a game lobby;

means for receiving a second player in said game lobby;

means for transmitting a request from said first player to said second player to play the match, wherein said transmitting means is capable of at least one of the following:

a) challenging said first player to the match immediately,

b) challenging said first player to the match scheduled in the future,

c) requesting that the match be automatically found and started,

e) requesting that a scrimmage match be automatically found and started, or

f) requesting the match using communication means;

means for providing said first player and said second player with information sufficient to play the match.

24. A computer-based system for network interactive match assignment and server selection for instances of computer games, comprising:

means for receiving a first player in a game lobby;

means for receiving a second player in said game lobby;

g) challenging said first player to the match immediately,

h) challenging said first player to the match scheduled in the future,

i) requesting that the match be automatically found and started,

j) selecting limiting criteria based upon which the match is automatically found and started

k) requesting that a scrimmage match be automatically found and started, or

l) requesting the match using communication means;

means for using criteria selected by at least one of said first player or said second player to narrow game or game hosting server selection;

means for determining the latency from at least one game hosting server to at least one of said first or said second player;

means for selecting the game hosting server;

means for preparing said selected game hosting server for play by at least said first player and said second player; and

means for providing information sufficient to enable said first player and said second player to play the match.