Server system, team formation method in network game, and information storage medium

Abstract

A play level value of each player which is changed depending on game results is stored in a player management DB. When accepting a matching request from a player terminal, all candidate teams including the player who has issued the matching request are calculated. Candidate teams of which the average level values are almost equal and which completely differ as to the players belonging thereto are determined as opposing teams.

Description

Japanese Patent Application No. 2006-51692 filed on Feb. 28, 2006, is hereby incorporated by reference in its entirety.

BACKGROUND OF THE INVENTION

The present invention relates to a server system for a network match game which is connected with a plurality of player terminals via a communication channel and forms teams of players and the like.

The number of players utilizing an online network game has steadily increased along with development of communication technology: The most attractive feature of the online network game is that the player can enjoy the game by sharing a single game world with an unknown player by forming a party or the like. In the case of a one-to-one match game such as go or chess, the players can compete anytime and anywhere.

A process of searching for a partner for the party or a competitor is called a matching process. Various technologies have been proposed for the matching process. For example, JP-A-2001-344372 discloses a technology of forming players having a common objective into a party.

However, the above technology cannot be directly applied to a team match game. For example, since the technology disclosed in JP-A-2001-344372 is a technology for forming one team (party), the opposing teams cannot be coordinated. Specifically, since the difference between the total level of one team and the total level of the other team is not taken into consideration, a difference in level may occur between the opposing teams. Moreover, a team with a distinctive feature, is not necessarily formed by merely forming a team of players having almost equal play levels, whereby interest to the game is reduced.

SUMMARY

According to one aspect of the invention, there is provided a server system for a network game which is connected with a plurality of player terminals via a communication channel, the server system comprising:

a play level value storage section which stores a play level value for each player which is changed depending on game results;

a request acceptance section which accepts a matching request from the player terminal; and

a team formation section which forms a team of players whose matching request has been accepted by the request acceptance section and whose play level values satisfy a specific almost equal condition based on the stored play level values.

According to another aspect of the invention, there is provided a server system for a network game which is connected with a plurality of player terminals via a communication channel, the server system comprising:

a play level value storage section which stores a play level value of each player which is changed depending on game results;

a candidate calculation section which calculates candidate teams formed of combinations of players;

a team level value calculation section which calculates a total play level value of each of the calculated candidate teams; and

an opposing team determination section which determines candidate teams of which the play level values satisfy a specific almost equal condition as opposing teams.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING

FIG. 1 is a view showing an example of the installation state of player terminals.

FIG. 2 is a view showing a schematic configuration of a game system.

FIG. 3A is a view showing a game space map. FIG. 3B is a view showing an example of a game screen.

FIG. 4 is a functional block diagram of a server system.

FIG. 5 is a view showing a configuration example of terminal installation location information.

FIG. 6 is a flowchart of a player management process.

FIG. 7 is a view showing a configuration example of a player management DB.

FIG. 8 is a view showing a configuration example of matching acceptance information.

FIG. 9 is a view showing an example of a desired condition input screen displayed on a player terminal.

FIG. 10 is a view showing a configuration of choices of a team type and a position.

FIG. 11 is a flowchart of a team formation process.

FIG. 12 is a flowchart of a candidate team addition process.

FIG. 13 is a view showing a configuration example of candidate team information.

FIG. 14 is a flowchart of a cancellation time completion process.

FIG. 15 is a flowchart of a priority index calculation process.

FIG. 16 is a view showing an example of the relationship between a terminal installation location and a location coefficient.

FIG. 17 is a view showing an example of the relationship between a longest elapsed time and an elapsed time coefficient.

FIG. 18 is a view showing an example of the relationship between the number of players whose desired conditions are satisfied and a degree of satisfaction coefficient.

FIG. 19 is a flowchart of an opponent team selection process.

FIG. 20 is a view showing an example of an team determination notification screen.

FIG. 21 is a view showing an example of a hardware configuration.

DETAILED DESCRIPTION OF THE EMBODIMENT

The invention has been achieved in view of the above-described technical problems. According to one embodiment of the invention, there is provided a server system for a network game which is connected with a plurality of player terminals via a communication channel, the server system comprising:

a play level value storage section which stores a play level value for each player which is changed depending on game results;

a request acceptance section which accepts a matching request from the player terminal; and

a team formation section which forms a team of players whose matching request has been accepted by the request acceptance section and whose play level values satisfy a specific almost equal condition based on the stored play level values.

According to another embodiment of the invention, there is provided a method comprising causing a server system for a network game which is connected with a plurality of player terminals via a communication channel to:

store a play level value of each player which is changed depending on game results;

accept a matching request from the player terminal; and

form a team of players whose matching request has been accepted by the request acceptance section and whose play level values satisfy a specific almost equal condition based on the stored play level values.

Therefore, the teams are formed so that the total play level values of the opposing teams satisfy the almost equal condition. Therefore, the opposing teams compete in terms of the level, whereby an exciting competition can be expected.

In the server system according to this embodiment, the network game may be a game in which the player terminals belonging to a single team can communicate during the game using a specific communication method;

the server system further may include a location storage section which stores location information of each of the player terminals; and

the team formation section may include a single region team formation section which forms a team of players of player terminals of which the matching request has been accepted by the request acceptance section and which satisfy a specific single region condition.

Therefore, the players belonging to a single team can communicate during the game using a specific communication method. A team is formed of players of player terminals which satisfy the single region condition. Therefore, since a team is formed of players who tend to feel a regional affinity, the players relatively easily unite even if the players do not know one another. Specifically, if the players use the same regional dialect during communication, the players acknowledge that all players are in the same region, whereby affinity is increased, for example.

In the server system according to this embodiment, hierarchical location areas with different areas may be defined in advance; and

the single region team formation section may form a team of players of player terminals in a single location area while giving priority to a narrower location area.

Therefore, the locality of the team can be further increased, whereby the effects of the second invention can be more remarkably achieved.

In the server system according to this embodiment, the single region team formation section may form opposing teams so that the player terminals of the opposing teams are located in different location areas.

Therefore, since the player's team and the opponent team are formed of players located in different location areas, the game becomes a match between different regions, whereby a more exciting game can be expected.

The server system according to this embodiment may further comprise:

an acceptance time storage section which stores an acceptance time for each of the player terminals of which the matching request has been accepted by the request acceptance section;

wherein the team formation section may include an acceptance time priority team formation section which forms a team while giving priority to a player terminal of which the acceptance time stored in the acceptance time storage section is earlier.

When adding various conditions to formation of opposing teams, participation of a larger number of players may be required to form a team which satisfies the conditions, whereby the time required to form a team may be increased. This point is described below taking a specific example. For example, when a number of players have not yet been matched, the number of combinations of candidate teams which can be formed is increased corresponding to the number of players. The matching method may be considered in which a larger number of teams are formed. However, since a player who rarely satisfies the team formation conditions tends to be excluded from the matching target, this player is not matched for a long time. According to this embodiment, since a player terminal which has waited for a longer time after the matching request has been accepted is given priority, the above problem can be resolved.

In the server system according to this embodiment, the request acceptance section may include a level distribution request acceptance section which accepts a level distribution request for the play level values of member players belonging to a player's team; and

the team formation section may include a requested level distribution team formation section which forms a team to satisfy a requested level distribution of each player belonging to a single team which has been accepted by the level distribution request acceptance section.

Therefore, the player can request the level distribution of the players belonging to the team to be formed, such as a team formed of players with the same level or a team formed of players with hierarchically different levels.

In the server system according to this embodiment, the request acceptance section may include a team relative level request acceptance section which accepts a relative level request for the play level values of member players belonging to a player's team; and

the team formation section may include a requested relative level team formation section which forms a team to satisfy a requested relative level of each player belonging to a single team which has been accepted by the relative level request acceptance section.

Therefore, the player can request that the player have the highest level in the team or request that the player have an average level in the team, for example.

According to a further embodiment of the invention, there is provided a server system for a network game which is connected with a plurality of player terminals via a communication channel, the server system comprising:

a play level value storage section which stores a play level value of each player which is changed depending on game results;

a candidate calculation section which calculates candidate teams formed of combinations of players;

a team level value calculation section which calculates a total play level value of each of the calculated candidate teams; and

an opposing team determination section which determines candidate teams of which the play level values satisfy a specific almost equal condition as opposing teams.

According to a further embodiment of the invention, there is provided a method comprising causing a server system for a network game which is connected with a plurality of player terminals via a communication channel to:

store a play level value of each player which is changed depending on game results; calculate candidate teams formed of combinations of the players;

calculate a total play level value of each of the calculated candidate teams; and

determine candidate teams of which the calculated play level values satisfy a specific almost equal condition as opposing teams.

Therefore, candidate teams of which the total play level values satisfy the almost equal condition are selected as the opposing teams. Therefore, the opposing teams compete in terms of the level, whereby an exciting competition can be expected.

The server system according to this embodiment may further comprise:

a priority index calculation section which calculates a priority index for each of the calculated candidate teams;

wherein the opposing team determination section may include a priority determination section which determines the opposing teams while giving priority to candidate teams of which the calculated priority indices are higher.

Therefore, the priority index of each of the candidate teams is calculated, and the opposing teams are determined while giving priority to candidate teams of which the calculated priority indices are higher. Since a candidate team which should be preferentially selected as the opponent team and a candidate team having a low degree of priority are included in a number of candidate teams in combination, the priority index is calculated as the determination standard.

The server system according to this embodiment may further comprise:

a location storage section which stores location information of each of the player terminals;

wherein the priority index calculation section may calculate the priority index of a candidate team formed of players of player terminals satisfying a specific single region condition to be higher than that of a candidate team which does not satisfy the single region condition referring to the content stored in the location storage section.

Therefore, since the priority index of a candidate team formed of players of player terminals satisfying the single region condition is calculated to be higher than that of a candidate team which does not satisfy the single region condition, the candidate team satisfying the single region condition is preferentially selected as the opponent team. Since the players satisfying the single region condition tend to feel a regional affinity, a team is formed in which the players easily unite. Specifically, if the players use the same regional dialect during communication, the players acknowledge that the players are in the same region, whereby affinity is increased. This method is an effective mean for a network game in which unacquainted players are formed into a team.

The best mode for carrying out the invention is described below with reference to the drawings. The following description illustrates the case where the invention is applied to a network match type gun shooting game in which a plurality of players share a single game space at the same time. Note that the embodiment to which the invention can be applied is not limited thereto.

As examples of the configuration of a game system which realizes a network game, (A) a configuration in which a personal computer, a home game machine, or the like is used as a player terminal and connected with a game server through a cable/wireless communication line such as the Internet or a dedicated line, (B) a configuration in which a plurality of player terminals are connected through a communication line without using a game server, (C) a configuration in which a plurality of player terminals are connected through a communication line and one of the player terminals has a game server function, (D) a configuration in which a plurality of player terminals are physically connected to form one system (e.g. arcade game machine), and the like can be given. The invention can be applied to any of these system configurations. The following description is given taking a game system having the configuration (A) as an example. In more detail, the game system according to this embodiment is a nationwide system which connects arcades, amusement facilities, and the like in various places through communication lines, in which a server system including a management server and a game server is provided on the game service provider side.

1. Outline of System

FIG. 1 shows an example of an installation state of player terminals 20 installed in one area of a shop. As shown in FIG. 1, the player terminals 20, each of which includes a keyboard, a mouse, a display, and a main body, are arranged in the area. A player enjoys a gun shooting game by operating the player terminal 20.

FIG. 2 is a view showing a schematic configuration of a game system 5. As shown in FIG. 2, the game system 5 has a configuration in which the player terminals 20 are connected with a server system 1 through a network N such as a LAN or WAN via a communication line such as a wireless communication channel, a dedicated line, a twisted-pair cable, or an optical communication cable.

The server system l includes one or more server computers, and simultaneously and parallelly executes a player information management process, a team formation process by player matching, and a game progress control process of controlling the progress of a network match game. The term “player information management process” includes player registration, login authentication, a process of inputting conditions desired for a match between teams, and the like.

The term “team formation process” refers to a matching process which forms each team by combining players who have logged in. The term “game progress control process” refers to a process of controlling the progress of a match game performed between teams created by the team formation process. The game play of a player participating in a match game is evaluated based on game results, and a play level value is changed. A particular feature of this embodiment is the team formation process.

The player terminal 20 is implemented by a computing system. The player terminal 20 logs into the game system 5 by accessing the server system 1, acquires game data according to game play of a network game from another player terminal 20 or the server system 1 by appropriately executing a client game program of the network game, and generates and displays a game image based on the acquired game data.

The player terminals 20 are installed in amusement facilities in various places. As shown in FIG. 2, the player terminals 20 are installed on the first floor and the second floor in a Shinjuku branch in Tokyo and the first floor in a Sakae branch in Nagoya, for example. The installation location (e.g. region, shop, and floor) of each player terminal 20 is registered in the server system 1. FIG. 5 is a view showing a configuration example of terminal installation location information 148 which indicates the relationship between the terminal ID of each player terminal 20 and the installation location of the player terminal 20. As shown in FIG. 5, the installation location is classified into three areas including the region (e.g. Tokyo, Osaka, and Nagoya) which is the largest area, the shop (e.g. Shinjuku branch and Shibuya branch) which is the intermediate area, and the floor (e.g. first floor and second floor) which is the smallest. area.

2. Outline of Game

The network match game according to this embodiment is a gun shooting game viewed from a first-person view point, in which three players form one team and the player teams play a match. Each player operates one soldier character provided with a gun. When the soldier character is shot to death, the player is withdrawn from the game. The degree of damage differs depending on the shot region. For example, when the soldier character is shot at the forehead, the soldier character is determined to be killed by one shot. This ensures tense game playability.

The game according to this embodiment is a game in which an offense-side team and a defense-side team play a match. The offense-side team wins the game when the offense-side team can set a time bomb at a predetermined bomb setting point and the time bomb explodes within a predetermined time, and the defense-side team wins the game when the defense-side team can prevent the time bomb from exploding within the predetermined time. After the offense-side team has set the time bomb, the defense-side team can cancel the bomb before explosion occurs. Therefore, when the time bomb has been cancelled, the offense-side team must again set a time bomb in order to win the game.

On the other hand, since the soldier character which has been shot and determined to be killed is withdrawn from the game, the number of soldier characters participating in the game decreases. Therefore, it is important for the offense-side/defense-side team to establish offense/defense strategy, and teamwork is an important element which decides victory or defeat. Each player can enjoy an exciting and tense game as if the player takes part in a battle in a battlefield.

FIG. 3A is a view showing a game space map. FIG. 3A is a schematic view of the entire game space viewed from the top. FIG. 3B is a view showing an example of the game screen shown in FIG. 3A, in which an image of the game space viewed from the view point (first-person view point) of a soldier character AC1 is displayed.

In FIG. 3A and FIG. 3B, the game space is a closed space. Containers CT1 to CT5, characters AC1 to AC3 (offense-side soldier characters), and characters DC1 to DC3 (defense-side soldier characters) are disposed in the game space. The soldier characters AC1 to AC3 and DC1 to DC3 are respectively operated by individual players using the player terminals 20. A bomb setting point BSP is set and specified in advance in the game space. The offense-side team wins the game when the offense-side team can set a time bomb at the bomb setting point BSP and the time bomb explodes within a predetermined time, and the defense-side team wins the game when the defense-side team can prevent the time bomb from exploding within the predetermined time.

The characters AC1 to AC3 and DC1 to DC3 are disposed at specific positions (e.g. ST1 and ST2 in FIG. 3A) when starting the game. After starting the game, the characters AC1 to AC3 and DC1 to DC3 are moved to given positions according to player's operations.

FIG. 3B shows a game screen displayed in the player terminal of the player who operates the soldier character AC1. The player terminal 20 of another player displays an image of the game space viewed from the view point of the soldier character operated by the other player. Specifically, the player terminal of each player displays only an image of the game space viewed from the view point of the soldier character operated by each player. Therefore, while the game progresses using a single game space, each player can view the state of the game space from only the view point of the soldier character operated by each player. Specifically, each player must conjecture the state of the game space viewed from other soldier characters and whether or not the player's soldier character is seen from other soldier characters. As a result, a battle similar to an actual battle is simulated.

As shown in the game screen in FIG. 3B, a chat window CHW is displayed on the game screen of each player so that the players can communicate through chatting as if the players were communicating through wireless communication in a battlefield. When a soldier character is determined to have been killed, chatting with the player terminal of the player who operates the dead soldier character becomes impossible. This also provides simulation of a battle similar to an actual battle.

In this embodiment, chatting is performed using characters. Note that the players may communicate by conversation using a head set or the like instead of using characters.

3. Functional Configuration

A functional configuration of the server system 1 according to this embodiment is described below. FIG. 4 is a block diagram showing an example of the functional configuration of the server system 1. As shown in FIG. 4, the server system includes an operation section 110, a processing section 120, a storage section 130, a display section 150, a communication section 160, and the like, and executes the player information management process, the team formation process by matching between the players, the game progress control process of controlling the progress of the network match game, and the like through data communication with the player terminals 20.

The operation section 110 receives operation instructions from the administrator of the server system 1 or the like, and outputs an operation signal corresponding to the operation to the processing section 120. This function is implemented by a button, an operation stick, a dial, a mouse, a keyboard, various sensors, and the like.

The processing section 120 performs various calculations such as controlling the entire server system 1, proceeding with the game, and generating an image. This function is implemented by a processing device such as a CPU (CISC or RISC) or an ASIC (e.g. gate array) and its control-program, for example.

The processing section 120 includes a player management section 124, a team formation section 126, and a game progress control section 128 as the main functional sections.

The player management section 124 executes a player management process according to a player management program 138. FIG. 6 is a flowchart showing a flow of the player management process. The player management section 124 monitors whether or not a player registration request has been sent from the player terminal 20 (step A1). When the registration request has been sent from the player terminal 20 (step A1: YES), the player management section 124 executes a registration process including creating player data for a new player and registering the created player data in a player management DB 141 (step A3). The registration process is a process of registering a new player and is similar to a known process. FIG. 7 shows a configuration example of the player management DB 141. As shown in FIG. 7, the player management DB 141 contains player data 141-1, 141-2, . . . of each player. A player name 141a, a player ID141b, a player authentication password 141c, a level value 141d indicating the play level of the player, and the like are recorded in the player data. Identification information of the character used by the player, game money acquired in the game, a flag indicating whether or not the player has logged in, the terminal ID of the player terminal when the player has logged in, and the like (not shown) are also recorded in the player management DB 141.

The player management section 124 monitors whether or not a login request has been sent from the player terminal 20 (step A5). When the login request has been sent from the player terminal 20 (step A5: YES), the player management section 124 executes a player authentication process to identify the player (step A7). The authentication process is a process of checking the player name 141a, the player ID141b, and the password 141c registered in the player management DB 141 and is similar to a known process. When the player has been determined to be the registered player as a result of authentication (step A9: YES), the player management section 124 registers the effect that the player has logged in and registers the terminal ID of the player terminal 20 of the player in the player management DB 141, and waits for a request from the player terminal 20.

The player management section 124 determines whether or not a match game start request signal has been transmitted from the player terminal 20 of the authenticated player (step A11). When the player management section 124 has received another request signal from the player terminal 20 instead of the match game start request signal (step A11: NO), the player management section 124 executes a process corresponding to the received signal (step A17).

When the player management section 124 has received the match game start request signal (step A11: YES), the player management section 124 associates the player with the terminal ID of the player terminal 20 which has transmitted the signal to create new acceptance data, and registers the acceptance data in matching acceptance information 142 (step A13). The player management section 124 executes a desired condition input process for inputting conditions desired for team formation (step A15), and registers the desired conditions in the matching acceptance information 142 for the player who requests that a match game be started.

FIG. 8 is a view showing a configuration example of the matching acceptance information 142. The matching acceptance information 142 contains acceptance data 142-1, 142-2, . . . for each player whose match game start request has been accepted. A player name 142a, a player ID142b, a level value 142c, an acceptance time 142, desired conditions 142h, a terminal ID 142p, and a terminal installation location 142q are recorded in the acceptance data while being associated with one another.

A desired condition input process is a process of querying the player whose request to start a match game has been accepted about a request concerning a team to be formed. In more detail, the player management section 124 transmits a request inquiry signal to cause the player terminal 20 to display a desired condition input screen for querying the player about desired conditions. FIG. 9 shows an example of the desired condition input screen displayed on the player terminal 20.

In FIG. 9, a radio buttons RB1B and RB2B for inputting the presence or absence of a request, and entry fields for inputting a team type RW3, a position RW4, and a desired condition cancellation time limit RW5 are disposed on a desired condition input screen RW. The term “team type” refers to the distribution of the play level values of the players forming the team, that is, a systematic configuration of the play level values. In more detail, the team type is classified into an average type, a series type, and a pyramid type. One team is formed of three players. The term “average type” refers to a team type in which the level value of each player is within a specific range (e.g. the differences between the maximum level value and the minimum level value is 1.0 or less), the term “series type” refers to a team type in which the level values of the three players are classified into high, medium, and low and the difference in level value is not within the specific range, and the term “pyramid type” refers to a team type in which the level values of two players are within the specific range and the level value of the remaining player is not within the specific range and is higher than the level values of the other two players.

The term “position” refers to the position of the player in the team. In more detail, the term “position” refers to the position of the level value of the player in the team. When the team type is the “average type”, the position is “equal”. When the team type is the “series type”, the position is classified as “high”, “middle”, and “low”. When the team type is the “pyramid type”, the position is classified as “high” and “low”.

FIG. 10 shows a configuration of options which can be input as the team type RW3 and the position RW4. When the team type has been selected, the type of position which can be selected is determined, as described above. Note that “no request” may be selected when the player does not request a specific position. In more detail, when the player requests the “pyramid type” as the team type but does not mind whether the position is “high” or “low”, the player may select “no request” regarding the position.

The term “desired condition cancellation time limit” refers to the time from the acceptance of a matching request to cancellation of the desired conditions. The server system 1 attempts to form a team which coincides with the desired conditions. However, It may take a long time until matching satisfying the conditions is achieved after the matching request has been accepted depending on the number of players whose matching request has been accepted and the desired conditions of each player. When the player desires to promptly play a match game even if the desired conditions are not satisfied, the player may input a short time (e.g. one minute) as the desired condition cancellation time limit. On the other hand, when the player desires to play a match game in a team satisfying the desired conditions even if the player waits for a long time, the player may input a long time (e.g. 120 minutes) as the desired condition cancellation time limit. In other words, the desired condition cancellation time limit is the time in which player can wait for a team satisfying the desired conditions to be formed.

Again referring to FIG. 4, the team formation section 126 executes the team formation process according to a team formation process program 131. The team formation section 126 executes a candidate team addition/update process according to a candidate team addition/update program 132, a cancellation time completion process according to a cancellation time completion program 133, a priority index calculation process according to a priority index calculation program 134, and an opponent team selection process according to an opponent team selection program 135 as a subroutine process during execution of the team formation process.

The operation of each process is described below in detail. FIG. 11 is a flowchart showing a flow-of the team formation process. The team formation section 126 monitors whether or not the match game start request signal has been received and the matching request has been accepted by the player management section 124 (step B1). When the matching request from a new player has been accepted (step B1: YES), the team formation section 126 reads the candidate team addition/update process program 132 and executes the candidate team addition/update process (step B3).

FIG. 12 is a flowchart showing a flow of the candidate team addition/update process. In the candidate team addition/update process, the team formation section 126 calculates all combinations of candidate teams including the new player whose matching request has been accepted (step C1). For example, when players A, B, and C have been registered in the matching acceptance information 142 as player whose matching request has been accepted, and a matching request from a player D has been additionally accepted, the team formation section 126 calculates three candidate teams (A, B, D), (A, C, D), and (B, C, D) including the player D.

The team formation section 126 executes a process in a loop A for each of the calculated candidate teams (steps C3 to C21). The candidate team processed in the loop A is hereinafter simply called a “candidate team”.

The team formation section 126 calculates the average value of the level values 142c of the players belonging to the candidate team as an average level value based on the acceptance data of the players (step C5). The team formation section 126 determines the team type based on the distribution of the level values of the players (step C7). Specifically, the team formation section 126 determines whether the team type is the “average type”, the “series type”, or the “pyramid type” depending on whether or not the difference between the level values of the players is within a specific range. When the team type does not fall under the three types, the team type is determined to be “none”.

The team formation section 126 determines the location of the candidate team based on the terminal installation location 142q of the terminals operated by the players included in the candidate team (step C9). In more detail, the location of the candidate team is determined as follows. The installation location of the terminal is. roughly classified into areas in three stages, as described with reference to FIG. 5. an area (in the order from a wider area) common to the terminal installation locations 142q of three players belonging to the candidate team is determined as the location of the candidate team. For example, when the terminal installation location 142q of the player A is “Tokyo”, “Shinjuku branch”, and “1F”, the terminal installation location 142q of the player B is “Tokyo”, “Shinjuku branch”, and “2F”, and the terminal installation location 142q of the player D is “Tokyo”, “Shinjuku branch”, and “2F”, the region “Tokyo” and the shop “Shinjuku branch” are common to the three players. Therefore, the location of the candidate team is determined to be “Tokyo”, “Shinjuku branch”.

When the terminal installation location 142q of the player A is “Tokyo”, “Shinjuku branch”, and “1F”, the terminal installation location 142q of the player B is “Tokyo”, “Shibuya branch”, and “1F”, and the terminal installation location 142q of the player D is “Tokyo”, “Shinjuku branch”, and “1F”, the floor “1F” is common to the three players, but the shop differs. Therefore, the location of the candidate team is determined to be “Tokyo”, since only the region “Tokyo” (wider area) is common to the three players. When the region is not common to the three players, the location of the candidate team is determined to be “none”.

The team formation section 126 determines the earliest acceptance time (step C11). The term “earliest acceptance time” refers to the earliest of the acceptance time 142d of each player belonging to the candidate team.

The team formation section 126 provides the candidate team with an ID and registers the information of the candidate team in candidate team information 144 (step C13). FIG. 13 is a view showing an example of the configuration of the candidate team information 144. The candidate team information 144 is information in which the information of each candidate team is collectively registered. A player name 144a, a player ID 144b, a level value 144c, an acceptance time 144d, a team type 144e (desired condition), a position 144f (desired condition), a cancellation time limit 144g (desired condition), a terminal ID 144p, and a terminal installation location 144q are registered in the candidate team information 144 as the same data as the acceptance data of the player belonging to the candidate team. An average level value 144v determined in the step C5, a team type 144w determined in the step C7, a team location 144s determined in the step C9, an earliest acceptance time 144u determined in the step C11, a longest elapsed time 144t calculated in the cancellation time completion process or the priority index calculation process, and a priority index 144x calculated in the priority index calculation process are also registered in the candidate team information 144.

Since the longest elapsed time 144t and the priority indexes 144x have not been calculated in the step C13, these values are not registered.

After registering the candidate team information, the team formation section 126 determines whether or not the candidate team satisfies the desired conditions of all the players belonging to the candidate team (step C15). In more detail, when the candidate team is formed of the players A, B, and D, the team formation section 126 determines whether or not the candidate team satisfies the team type 144e and the position 144f as the desired conditions of each of the players A, B, and D.

When the team formation section 126 has determined that the candidate team does not satisfy the desired conditions of all the players (step C15: NO), the team formation section 126 registers the candidate team in a candidate standby list 146 (step C15). When the team formation section 126 has determined that the candidate team satisfies the desired conditions of all the players (step C15: YES), the team formation section 126 registers the candidate team in a candidate list 145 (step C17).

When the process in the steps C5 to C19 has been performed for all the candidate teams calculated in the step C1, the team formation section 126 finishes the candidate team addition/update process (step C21).

Again referring to FIG. 11, after the candidate team addition/update process has been completed, the team formation section 126 reads the cancellation time completion program 133 and executes the cancellation time completion process (step B5).

FIG. 14 is a flowchart showing a flow of the cancellation time completion process. In the cancellation time completion process, the team formation section 126 executes a process in a loop B for each candidate team registered in the candidate standby list 146 (steps D1 to D9). The candidate team processed in the loop B is hereinafter simply called a “candidate team”.

The team formation section 126 calculates the longest elapsed time 144t of the candidate team (step D3), and updates the candidate team information 144. The longest elapsed time is the time elapsed from the earliest acceptance time 144u of the candidate team to the current time.

The team formation section 126 determines whether or not the calculated longest elapsed time 144t is equal to or greater than the cancellation time limit 144g (desired condition) of all the players of the candidate team to determine whether or not the cancellation time limits 144g of all the players have been exceeded (step D5). When the team formation section 126 has determined that the cancellation time limits 144g of all the players have been exceeded (step D5: YES), the team formation section 126 deletes the candidate team from the candidate standby list 146 and registers the candidate team in the candidate list 145 (step D7). When the team formation section 126 has determined that the cancellation time limits 144g of all the players have not been exceeded. (step D5: NO), the team formation section 126 does not delete the candidate team from the candidate standby list 146.

When the process in the steps D3 to D7 has been performed for all the candidate teams registered in the candidate standby list 146, the team formation section 126 finishes the cancellation-time completion process (step D9).

Again referring to FIG. 11, after the cancellation time completion process has been completed, the team formation. section 126 reads the priority index calculation program 134 and executes the priority index calculation process (step B7).

FIG. 15 is a flowchart showing a flow of the priority index calculation process. In the priority index calculation process, the team formation section 126 executes a process in a loop C for each candidate team registered in the candidate list 145 (steps E1 to E7). The candidate team processed in the loop C is hereinafter simply called a “candidate team”.

The team formation section 126 calculates the longest elapsed time 144t of the candidate team (step E3), and updates the candidate team information 144.

The team formation section 126 calculates the priority index 144x of the candidate team (step E5). The priority index is calculated from the following expression (1).
Priority index=location coefficient×elapsed time coefficient×degree of satisfaction coefficient  (1)

The term “location coefficient” refers to a coefficient based on the team location. As the area of the location of the candidate team becomes smaller, a larger coefficient is set. FIG. 16 shows an example of the relationship between the terminal installation location of each player belonging to the candidate team and the location coefficient. In FIG. 16, when the terminal installation location of each player belonging to the candidate team is the same in terms of the “region”, the “shop”, and the “floor”, it is determined that the players are located in the narrowest area so that the location determination level is determined to be the highest level “A” and the maximum value “2.0” is set as the location coefficient. This applies to the case where “Tokyo”, “Shinjuku branch”, and “1F” are registered as the team location 144s, for example. When only “region” is the same and the “shop” and the “floor” differ, “0.5” is set as the location coefficient. This applies to the case where “Tokyo” is registered as the team location 144s, for example.

Therefore, the priority index increases as the players belonging to the candidate team are located in a narrower area.

The term “elapsed time coefficient” refers to a coefficient corresponding to the value of the longest elapsed time 144t. FIG. 17 is a graph showing the relationship between the longest elapsed time 144t and the elapsed time coefficient. The elapsed time coefficient is “1.0” when the longest elapsed time 144t is “10 minutes” or less. The elapsed time coefficient increases in proportion to the elapsed time toward “2.0” when the longest elapsed time 144t is more than “10 minutes” and “30 minutes” or less. The elapsed time coefficient rapidly increases when the longest elapsed time 144t exceeds “30 minutes” and reaches “5.0” at a longest elapsed time 144t of “50 minutes”.

Therefore, the priority index of the candidate team increases as the longest elapsed time increases, taking the long matching wait time into consideration.

The term “degree of satisfaction coefficient” refers to a coefficient indicating the degree that the desired conditions of each player belonging to the candidate team are satisfied. The degree of satisfaction coefficient increases as the number of players whose desired conditions are satisfied increases. FIG. 18 shows an example of the relationship between the number of players whose desired conditions are satisfied and the degree of satisfaction coefficient. For example, when the desired conditions of all the players belonging to the candidate team are satisfied, the degree of satisfaction coefficient is set at “10”. When the desired conditions of all the players are not satisfied, the degree of satisfaction coefficient is set at “0.5”.

Therefore, the priority index of the candidate team increases as the number of players whose desired conditions are satisfied increases.

The candidate team which does not satisfy the desired conditions of all the players belonging to the candidate team is registered. in the candidate list 145 because the candidate team in which the cancellation time limits of the desired conditions of all the players belonging to the candidate team have been exceeded is registered in the candidate list 145 as “matching timeout” in the cancellation time completion process (see FIG. 14).

After calculating the location coefficient, the elapsed time coefficient, and the degree of satisfaction coefficient of the candidate team, the team formation section 126 calculates the priority index 144x using the expression (1), and updates the candidate team information 144 (step E5).

When the team formation section 126 has executed the process in the steps E3 to E5 for all the candidate teams registered in the candidate list 145, the team formation section 126 sorts the candidate teams registered in the candidate list 145 in the order of the priority index calculated in the step E5 (step E9). This ensures that the candidate teams are registered in the candidate list 145 in order from the candidate team with a higher priority index.

The priority index calculation process is thus completed.

Again referring to FIG. 11, after the priority index calculation process has been completed, the team formation section 126 reads the opponent team selection program 135 and executes the opponent team selection process (step B9).

FIG. 19 is a flowchart showing a flow of the opponent team selection process. In the opponent team selection process, the team formation section 126 selects the candidate team with the highest priority index 144x from the candidate teams registered in the candidate list 145 as the first team (step F1).

The team formation section 126 then extracts the candidate teams which have the average level value 144v almost equal to that of the first team and to which players completely differing from the players of the first team belong from the candidate list 145 (step F3).

When the team formation section 126 has successfully extracted the candidate teams (step F3), the team formation section 126 selects the candidate team with the highest priority index 144x. from the extracted candidate teams as the second team (step F5). The team formation section 126 determines that the first team and the second team play the game (step F7).

The team formation section 126 sends an team determination notification to the player terminal 20 of each player belonging to the first team and the second team (step F8). FIG. 20 shows an example of a screen displayed on the player terminal as a result of the team determination notification. When the player belongs to the first team, the player name and the level value of each player belonging to the first team, the team location of the first team, and the team type of the first team are read from the candidate team information 144 and indicated. The team location of the second team (opponent team) is also indicated.

The team formation section 126 deletes the candidate team to which at least one of the players belonging to the first team and the second team belongs from the candidate list 145, the candidate standby list 146, and the matching acceptance information 142 (step F9), and registers the effect that the first team and the second team play a match game and the candidate team information of the first team, and the second team in opponent team information 149 (step F10).

After the process in the step F9 has been completed or when the candidate team has not been extracted in the step F3 (step F3: none), when the candidate team with the priority index 144x ranking next to the priority index of the first team is registered in the candidate list 145 (step F11: YES), the team formation section 126 selects that candidate team as the first team (step F13), and repeatedly executes the process in the steps F3 to F11. When the candidate team with the priority index 144x ranking next to the priority index of the first team is not registered in the candidate list 145 (step F11: NO), the team formation section 126 determines that the process in the steps F3 to F11 has been performed for all the candidate teams, and finishes the opponent team selection process.

Again referring to FIG. 11, after the opponent team selection process has been completed, the team formation section 126 transitions to the step B1, and repeatedly executes the process in the steps B1 to B9.

Again referring to FIG. 4, the game progress control section 128 is a functional section which controls the progress of the network match game according to a game progress control program 139. The game progress control section 128 causes the teams determined in the opponent team selection process of the team formation section 126 (step F7 in FIG. 19) to play the game based on the opponent team information 149. In more detail, the game progress control section 128 establishes communication between the player terminals 20 of the players belonging to each team determined in the opponent team selection process, and starts executing the network match game. The game progress control section 128 determines victory or defeat when the network match game has ended, and changes the play level value of each player belonging to each team registered in the player management DB 141 based on a specific standard.

The display section 150 is a means for displaying characters and an image. The display section 150 displays the screen based on a display signal output from the processing section 120. This function is implemented by hardware such as a CRT, LCD, ELD, PDP, or HMD.

The communication section 160 is connected with a specific communication line (e.g. wireless communication channel or LAN) and performs data communication with the game terminal 20. This function is implemented by a wireless communication module such as a wireless LAN, a modem, a TA, a jack for a communication cable, a control circuit, or the like.

The storage section 130 stores a system program for implementing each function for causing the processing section 120 to control the entire server system 1 and a program and data necessary for causing the processing section 120 to execute various processes. The storage section 130 is used as a work area for the processing section 120, and temporarily stores results of calculations performed by the processing section 120 according to various programs, data input using the operation section 110, and the like. This function is implemented by various IC memories, hard disk, CD-ROM, DVD, MO, RAM, VRAM, or the like.

The storage section 130 stores a program and data for causing the processing section 120 to function as the player management section 124, the team formation section 126, and the game progress control section 128. In more detail, the storage section 130 stores the player management program 138, the team formation process program 131, and the game progress control program 139. The storage section 130 stores the player management DB 141, the matching acceptance information 142, the candidate team information 144, the candidate list 145, the candidate standby list 146, the terminal installation location information 148, and the opponent team information 149.

4. Hardware Configuration

An example of a hardware configuration for implementing the server system 1 according to this embodiment is described below with reference to FIG. 21. In the device shown in FIG. 21, a CPU 1000, a ROM 1002, a RAM 1004, an information storage medium 1006, an image generation IC 1010, a sound generation IC 1008, and I/O ports 1012 and 1014 are connected so that data can be input and output through a system bus 1016. An input device 1022 is connected with the I/O port 1012, and a communication device 1024 is connected with the I/O port 1014.

The CPU 1000 controls the entire device and performs various types of data processing according to a program stored in the information storage medium 1006, a system program (e.g. initialization information of the main body) stored in the ROM 1002, a signal input from the input device 1022, and the like.

The RAM 1004 is a storage means used as a work area for the CPU 1000, and stores a given content of the information storage medium 1006 and the ROM 1002, -the calculation results of the CPU 1000, and the like.

The information storage medium 1006 stores a program and data. As the information storage medium, a memory such as a ROM, a hard disk, a CD-ROM, a DVD, a magnetic disk, an optical disk, or the like is used. The information storage medium 1006 corresponds to the storage section 130 shown in FIG. 4.

Sound and an image can be suitably output using the image generation IC 1010 and the sound generation IC 1008 provided in the device.

The mage generation IC 1010 is an integrated circuit which generates pixel information according to instructions from the CPU 1000 based on information transmitted from the ROM 1002, the RAM 1004, the information storage medium 1006, and the like. A display signal generated by the mage generation IC 1010 is output to a display device 1018. The display device 1018 is implemented by a CRT, an LCD, a TV, a plasma display, a projector, or the like. The display device 1018 corresponds to the display section 150 shown in FIG. 4.

The sound generation IC 1008 is an integrated circuit which generates a sound signal corresponding to the information stored in the information storage medium 1006 and the ROM 1002 and sound data stored in the RAM 1004 according to instructions from the CPU 1000. The sound signal generated by the sound generation IC 1008 is output from a speaker 1020.

The input device 1022 is a device for allowing the administrator who utilizes the server system 1 to input various operations. The function of the input device 1022 is implemented by hardware such as a keyboard, a mouse, and a touch panel. The input device 1022 corresponds to the operation section 110 shown in FIG. 4.

A communication device 1024 exchanges information utilized in the device with the outside. The communication device 1024 is connected with another device through a communication line and utilized to transfer given information corresponding to a program. The communication device 1024 corresponds to the communication section 160 shown in FIG. 4.

5. Effects

As described above, the server system 1 according to this embodiment executes the matching process so that teams having almost equal total play level values compete. Specifically, teams of which the average values of the play level values of the players are almost equal compete (step F3 in FIG. 19). Therefore, the opposing teams compete in terms of the level, whereby an exciting competition can be expected.

A team is formed taking into consideration the terminal installation locations of the player terminals of the players belonging to the team. Specifically, a team is formed so that the area (terminal installation location) common to the player terminals becomes smaller. As a result, a team is formed of players who tend to feel a regional affinity, whereby the players easily unite even if the players do not know one another. Specifically, when a team is formed of players on the floor “1F” at the shop “Shinjuku branch” in the region “Tokyo”, the players easily unite because the players play the game in the same place. Moreover, it is likely that the players talk and become friends after completion of the game play.

The player can set his request for the team to be formed as a condition before the matching process. Specifically, the player can set the “series type”, “pyramid type”, or the like as the team type determined from the distribution of the play level values of the players, and can set his desired position in the team.

Moreover, since the player can input the cancellation time limit of the desired conditions, the player can set the maximum wait time until a team which satisfies the desired conditions is formed.

A candidate team including a player who has waited for a longer time after the matching request has been accepted has a larger elapsed time coefficient and a larger priority index. As a result, a player who has waited for a longer time after the matching request has been accepted is preferentially enjoys team formation (matching).

6. Modification

An example of the preferred embodiment of the invention has been described above. Note that the invention is not limited to the above-described embodiment. The invention may be appropriately applied to other embodiments without departing the scope of the invention. The following description illustrates modifications of the invention.

6.1. Locations of Opposing Teams

The teams which compete may have different locations. In more detail, a candidate team which has an average level value almost equal to that of the first team, is formed of players completely differing from the players of the first team, and has a location differing from the location of the first team may be extracted in the step F3 of the opponent team selection process shown in FIG. 19.

In this case, since the teams differing in location compete, the match game becomes a match between different regions, whereby a more exciting game can be expected. As indicated by the team determination notification screen shown in FIG. 20, the location of the opponent team is displayed in addition to the location of the player's team. Therefore, a match between “Shinjuku branch” and “Shibuya branch” or a match between “Tokyo” and “Osaka” occurs, for example.

6.2. Formation of Team with Location

As described with reference to FIG. 16, since the minimum value is set for the candidate team without the location as the location coefficient, a team without a location may be formed. Therefore, only a team with a location maybe formed by calculating the combinations of candidate teams formed of players having at least a common “region” which is the largest area in the step C1 of the candidate team addition/update process shown in FIG. 12.

In this case, the player may be allowed to input a condition such as “Tokyo” or “Shinjuku branch” as the team location condition (single regional condition), and only a team which satisfies this condition may be formed.

6.3. Desired Condition

Only a team which satisfies the desired conditions of all players may be formed. In more detail, an “indefinite” option may be added as the time which can be input as the cancellation time limit so that the players can wait until a team which satisfies the desired conditions is formed.

6.4. System Configuration

The game system 5 according to this embodiment is illustrated to have a system configuration in shop and floor units. Note that the system configuration to which the invention can be applied is not limited thereto. For example, the player terminal 20 may be a personal computer (PC) or a consumer game device provided in the player's house. In this case, the installation location of each player terminal may be registered in advance in the server system 1. For example, an area such as a “province”, “prefecture”, or “city, town, and village” is registered as the installation location instead of the “region”, “shop”, and “floor”.

6.5. Application of Other Games

The game according to this embodiment has been described above as a gun shooting game. Note that the game to which the invention may be applied is not limited thereto. For example, the invention may also be applied to team sports games such as a baseball game and a soccer game.

Although only some embodiments of the invention have been described above in detail, those skilled in the art would readily appreciate that many modifications are possible in the embodiments without materially departing from the novel teachings and advantages of the invention. Accordingly, such modifications are intended to be included within the scope of the invention.

Claims

1. A server system for a network game which is connected with a plurality of player terminals via a communication channel, the server system comprising:

a play level value storage section which stores a play level value for each player which is changed depending on game results;

a request acceptance section which accepts a matching request from the player terminal; and

a team formation section which forms a team of players whose matching request has been accepted by the request acceptance section and whose play level values satisfy a specific almost equal condition based on the stored play level values.

2. The server system as defined in claim 1, wherein the network game is a game in which the player terminals belonging to a single team can communicate during the game using a specific communication method;

wherein the server system further includes a location storage section which stores location information of each of the player terminals; and

wherein the team formation section includes a single region team formation section which forms a team of players of player terminals of which the matching request has been accepted by the request acceptance section and which satisfy a specific single region condition.

3. The server system as defined in claim 2,

wherein hierarchical location areas with different areas are defined in advance; and

wherein the single region team formation section forms a team of players of player terminals in a single location area while giving priority to a narrower location area.

4. The server system as defined in claim 3,

wherein the single region team formation section forms opposing teams so that the player terminals of the opposing teams are located in different location areas.

5. The server system as defined in claim 1, further comprising:

an acceptance time storage section which stores an acceptance time for each of the player terminals of which the matching request has been accepted by the request acceptance section;

wherein the team formation section includes an acceptance time priority team formation section which forms a team while giving priority to a player terminal of which the acceptance time stored in the acceptance time storage section is earlier.

6. The server system as defined in claim 1,

wherein the request acceptance section includes a level distribution request acceptance section which accepts a level distribution request for the play level values of member players belonging to a player's team; and

wherein the team formation section includes a requested level distribution team formation section which forms a team to satisfy a requested level distribution of each player belonging to a single team which has been accepted by the level distribution request acceptance section.

7. The server system as defined in claim 1,

wherein the request acceptance section includes a team relative level request acceptance section which accepts a relative level request for the play level values of member players belonging to a player's team; and

wherein the team formation section includes a requested relative level team formation section which forms a team to satisfy a requested relative level of each player belonging to a single team which has been accepted by the relative level request acceptance section.

8. A server system for a network game which is connected with a plurality of player terminals via a communication channel, the server system comprising:

a play level value storage section which stores a play level value of each player which is changed depending on game results;

a candidate calculation section which calculates candidate teams formed of combinations of players;

a team level value calculation section which calculates a total play level value of each of the calculated candidate teams; and

an opposing team determination section which determines candidate teams of which the play level values satisfy a specific almost equal condition as opposing teams.

9. The server system as defined in claim 8, further comprising:

a priority index calculation section which calculates a priority index for each of the calculated candidate teams;

wherein the opposing team determination section includes a priority determination section which determines the opposing teams while giving priority to candidate teams of which the calculated priority indices are higher.

10. The server system as defined in claim 9, further comprising:

a location storage section which stores location information of each of the player terminals;

wherein the priority index calculation section calculates the priority index of a candidate team formed of players of player terminals satisfying a specific single region condition to be higher than that of a candidate team which does not satisfy the single region condition referring to the content stored in the location storage section.

11. A method comprising causing a server system for a network game which is connected with a plurality of player terminals via a communication channel to:

store a play level value of each player which is changed depending on game results;

accept a matching request from the player terminal; and

form a team of players whose matching request has been accepted by the request acceptance section and whose play level values satisfy a specific almost equal condition based on the stored play level values.

12. The method as defined in claim 11,

wherein the network game is a game in which the player terminals belonging to a single team can communicate during the game using a specific communication method; and

wherein a team is formed of players of player terminals of which the matching request has been accepted and which satisfy a specific single region condition.

13. The method as defined in claim 12,

wherein hierarchical location areas with different areas are defined in advance; and

wherein a team is formed of players of player terminals in a single location area while giving priority to a smaller location area.

14. The method as defined in claim 13,

wherein opposing teams are formed so that the player terminals of the opposing teams are located in different location areas.

15. The method as defined in claim 11,

wherein a team is formed while giving priority to a player terminal of which acceptance time of the matching request is earlier.

16. The method as defined in claim 1,

wherein a level distribution request for the play level values of member players belonging to a player's team is accepted when accepting the matching request; and

wherein a team is formed to satisfy the accepted level distribution request of each player belonging a single team.

17. The method as defined in claim 1,

wherein a relative level request for the play level values of member players belonging to a player's team is accepted when accepting the matching request; and

wherein a team is formed to satisfy the accepted relative level request of each player belonging a single team.

18. A method comprising causing a server system for a network game which is connected with a plurality of player terminals via a communication channel to:

store a play level value of each player which is changed depending on game results; calculate candidate teams formed of combinations of the players;

calculate a total play level value of each of the calculated candidate teams; and

determine candidate teams of which the calculated play level values satisfy a specific almost equal condition as opposing teams.

19. The method as defined in claim 18, causing the server system to calculate a priority index for each of the calculated candidate teams;

wherein the opposing teams are determined while giving priority to candidate teams of which the calculated priority indices are higher.

20. The method as defined in claim 19,

wherein the priority index of a candidate team formed of players of player terminals satisfying a specific single region condition is calculated to be higher than that of a candidate team which does not satisfy the single region condition referring to location information of each of the player terminals.

21. A computer-readable information storage medium having a program stored thereon for causing a computer to execute the method as defined in claim 11.

22. A computer-readable information storage medium having a program stored thereon for causing a computer to execute the method as defined in claim 18.