JPH11253657A - Network game system, network game server device and computer-readable recording medium recording opponent selecting program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To automatically and surely select an optimum opponent. SOLUTION: At the time of receiving a game request from a client device 20, an opponent selecting means 12 differentiates a user originating the game request as a user waiting for a game. Then, according to a condition previously designated to make a more suitable combination, the combination of a game between users differentiated as users wating for a game is decided. An opponent informing means 13 extracts information on a user whose opponent is decided from a user information storing means 11 by the means 12 and informs the client device 2 of the opponent of extracted information and a game identifier. A game request means 21 of the device 20 outputs the game request to a server device 10 and receives opponent information concerning the opponent from the device 10. A playing means 22 plays a game through a communication network.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a network game system for playing indoor games such as shogi, go, chess, othello, mahjong, and video games, a network game server device, and a computer which records a player selection program. In particular, the present invention relates to a network game system, a network game server device, and a computer-readable recording medium for recording a player selection program for selecting an opponent from an unspecified number of participants.

[0002]

2. Description of the Related Art In indoor games such as shogi, go, chess, othello and competitive video games, it is common for players to play at the same time and at the same place. However, with the recent advance in information and communication technology, tools have been developed that allow computers to be connected via communication lines and play games at distant places. Thereby, it is possible to play a game while staying at home. However, in this case, it is difficult to select a game partner because the person who wants to play is at an individual place.

[0003] In order to make this easier to use, a player display system which registers personal information that can be played and displays the contents on a screen of a terminal device of a player who wants to play the game has been proposed (Japanese Patent Laid-Open No. 7-1995). 95321). By using this system, a player who wants to play can specify an opponent by selecting an arbitrary opponent on the screen, and play with the specified opponent. Although the invention disclosed in the above publication uses a telephone network, a function similar to that of the above-described system is realized by listing users using a homepage on the Internet.

[0004] However, in such a player display system, the user himself / herself must search for a partner who suits him / herself and communicate with him / herself. This is difficult in the following points. 1) The partner you want to play may not want to play. 2) There are cases where the other party you want to play is playing and cannot play immediately. 3) You need to monitor until the game you want to play ends. 4) Until the opponent can be selected, work other than the original purpose of the game must be done, and it takes time.

[0005] In view of this, a player selection system which automatically selects an opponent by a host computer and notifies the requesting user when found by using a mechanism utilizing a telephone network (Japanese Patent Publication No. Hei 7 (1995)) -63546). In this system, a user who wants to play sends a game request to a host. At this time, it is possible to designate a game with an unspecified partner in the game request. If you want to play against an unspecified opponent, specify the strength of the opponent.

On the host side, a person who satisfies desired conditions is selected as a game partner. That is, a person having the specified strength is selected as a game partner. And to both players,
Notify the other party's information. Here, the opponent is OK
If it doesn't return a signal, search for another player.

[0007] Thereby, a person having the specified strength is automatically selected from those who can play the game. As a result, the user does not have to select a game partner, which is convenient.

[0008]

[Problems to be solved by the invention]
In the player selection system described in Japanese Patent No. 3546,
Since the user specifies the strength of the opponent, there is still a problem that the apparatus enters a standby state if no one with the specified strength exists.

In addition, since each user specifies the strength of the opponent, the opponent is not selected unless both specifications match. For example, a player with a strength of "5"
Suppose that a person with strength “6” is specified. At this time, even if a person with strength “6” is in the standby state, the person with strength “7”
If the player wishes to play with these players, those players will not be selected as the opponents. Thus, it is natural psychology that wants to play with an opponent whose level is slightly higher than his own. Therefore, there is a possibility that the game partner is not selected forever.

[0010] The present invention has been made in view of the above points, and eliminates the need for a user to select a game partner by himself.
Another object of the present invention is to provide a network game system for automatically selecting an optimal game partner without fail.

Another object of the present invention is to provide a network server device that automatically and reliably selects an optimum game partner without requiring a user to perform a selection procedure. It is.

Another object of the present invention is to provide a player selection program for causing a computer to automatically and surely select an optimum player without requesting a user to perform a selection procedure. Is to provide a computer-readable recording medium on which is recorded.

[0013]

SUMMARY OF THE INVENTION In order to solve the above-mentioned problems, the present invention provides a network game system for playing a game with an unspecified number of participants on a communication network. User information storage means for storing the game request, and a game request response means for distinguishing the user who has transmitted the game request as a game waiting, and a selection condition specified in advance to be a more suitable combination. And a client device including a game requesting means for outputting the game request to the server device. And a network game system comprising:

According to this network game system, when a game request is output from the client device, the user who has transmitted the game request is identified as a game waiting by the player selection means. Then, the player selection means determines the combination of the games of the users identified as waiting for the game according to the selection condition specified in advance so as to be a more suitable combination.

As described above, the combination of the games is determined so as to be optimal according to the conditions specified in advance in the server device, so that the user automatically selects the optimal game without selecting the game partner. The opponent can be reliably selected.

According to another aspect of the present invention, there is provided a network game server device for managing information of a user playing a game via a communication network, wherein the user information storage means stores information of a plurality of users. When a game request is received, a game request responding means for distinguishing a user who has transmitted the game request as a game wait, and a game wait response according to a selection condition specified in advance so as to form a more suitable combination. And a player selection means for determining a combination of games played by the users.

According to such a network game server device, when the game request is received, the player who transmitted the game request is distinguished by the player selection means as waiting for the game. Then, the player selection means determines the combination of the games of the users identified as waiting for the game according to the selection condition specified in advance so as to be a more suitable combination.

As described above, according to the conditions specified in advance in the network game server device, the combination of the games is determined to be optimal. It is possible to reliably select an appropriate opponent.

Further, in order to solve the above-mentioned problem, a computer-readable program storing a player selection program for causing a computer to select a game partner of a user who wants to play a game via a communication network is recorded. In the recording medium, a user information storage unit for storing information of a plurality of users, a game request response unit for receiving the game request and distinguishing the user who transmitted the game request as a game wait, and a more suitable combination. A computer which records a player selection program characterized by causing a computer to function as player selection means for determining a combination of games between users identified as waiting for a game in accordance with a selection condition specified in advance as described above. A readable recording medium is provided.

By causing a computer to execute the player selection program recorded on this recording medium, the present invention can construct the network game server device of the present invention with the computer.

[0021]

Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 is a diagram illustrating the principle of the present invention. The network game system of the present invention includes a server device 10 and a client device 20. The server device 10 and the client device 20 are connected to the network 3
1 are connected.

The server device 10 includes a user information storage unit 1
1, a player selection unit 12, a game partner notification unit 13, and a game management unit 14. User information storage means 1
1 stores information of a plurality of users.

Upon receiving the game request from the client device 20, the player selection means 12 distinguishes the user who transmitted the game request as a game waiting. Then, according to a condition specified in advance so as to make a more suitable combination, a combination of games between users identified as waiting for a game is determined.

The game partner notifying means 13 extracts from the user information storage means 11 the information of the user whose game partner has been determined by the player selection means 12, and compares the extracted information and the game identifier with the game partner. Notify the client device 20.

The game management means 14 comprises the player selection means 12
Relays the progress of the game between the selected players. Specifically, the move sent from the client device 20 of one player is notified to the client device of the other party. Here, each game is distinguished by a game identifier.

The client device 20 is a game requesting means 2
1 and a game means 22. Game request means 21
Outputs a game request to the server device 10 and
Player information from 0 on the opponent is received. The game means 22 uses the game identifier to play the game with the game partner specified by the player information via the communication network.

In such a network game system, a user using the client device 20 first inputs a command to play a game. Then, the game request means 21 transmits a game request to the server device 10. In the server device 10 that has received the game request, the player selection means 12 waits for the user who has transmitted the game request. Then, according to predetermined selection conditions, the player selection means 12 determines a combination of games between the users waiting for the game. When the combination is determined, the game partner notifying means 13 sends the player information (including the game identifier) of the game partner to the client device 20 of each party. The responded player information is received by the game request unit 21 of the client device 20. The user of the client device 20 transmits a move together with the game identifier received by the game requesting means 21, thereby playing the network game by the game means 23.

By the way, the selection condition predetermined in the player selection processing means means one or a combination of the following conditions. 1) Every time a game request is received, a player selection process is performed for the game requester. At this time, the user waiting for the game with a long waiting time may be preferentially selected. 2) When the time specified in advance comes, player selection processing is performed. 3) If the number of users waiting for the game exceeds the number specified in advance, a player selection process is performed. 4) If the number of game request requests received exceeds a predetermined number, a player selection process is performed. 5) For a user whose player has not been determined within a predetermined time, a player is selected from another player DB. 6) The selection range of the opponent is determined based on the differential value of the increase / decrease of the score indicating the player's strength. 7) The selection range of the game partner is changed according to the game waiting time of the game waiting user.

As described above, the selection is made based on the conditions specified in advance so that a more suitable combination may be obtained in the server apparatus, based on the conditions specified by the user (for example, the specification of the strength of the opponent). By doing so, it is possible to prevent a game partner from being selected forever.
In addition, there is a high possibility that an optimal partner can be found.

An embodiment embodying the present invention will be described below. FIG. 2 is an overall schematic configuration diagram of the network game system according to the embodiment of the present invention.

The network game system according to the present invention comprises:
Server device 100 and client devices 200 and 200a
~ 200f. These are connected by a network 40 such as an ordinary public network or a private network. The type of the network 40 is not particularly specified, but in the following description, the Internet is used as a base in consideration of the degree of spread and ease of use.

Although the server device 100 may be usually one,
In consideration of processing capacity, a plurality of units may be installed for each subsystem device or for each divided user database (DB). Client devices 200, 200a to 200
f exists as many as the number of connected users. The user interfaces of the client devices 200, 200a to 200f can be realized by a web browser. Server device 1
Various accesses to 00 can be made by browsing a homepage in the server apparatus 100 with a web browser and operating on the homepage.

Communication between the server and the client is based on TCP / IP (Transmission Control) as a base protocol.
l Protocol / Internet Protocol) running on HTTP (Hyp
er Text Transfer Protocol), and can be realized by overlaying the application protocol specified in this system. Of course, protocols other than TCP / IP, such as OSI (Open System Interconnect
on) can also be used.

There are two possible ways to play a game between client devices. One is a method of direct communication between client devices playing the game, and the other is a method of playing the game via a server device. In either case, the game can be played by a method, but in the present embodiment, the latter method is adopted, and the game is played via a server device.

Table 1 shows application protocols defined by the present system.

[0036]

[Table 1]

This table shows the protocols used in the configuration (basic configuration) necessary to realize the present embodiment, which includes "game request", "player selection notification",
There are four types: "movement transmission" and "movement notification". The "game request" and the "player selection notification" include the client device 200, 200a-200 including necessary parameter information.
f to the server device 100, and the server device 100 responds to the request.

A game request is issued when a user desires a game.
It is activated by clicking a predetermined button on the homepage, and is issued to the server device 100. As the parameter information, the user identifier N, password P and IP address A are sent to the server side. Of course, the password P may be encrypted by a predetermined encryption method. Upon receiving the game request, the server device 100 authenticates the request, and if the pair is a valid identifier and password, determines that the user is a registered valid user. If the user is a legitimate user, the user is registered in the game waiting state, and the player automatic selection process is performed under predetermined conditions.

The player selection notification is sent by the server 100
It is issued to the client devices 200, 200a to 200f. As the parameter information, the information Zm of the opponent selected by performing the player automatic selection process, the strength Rm of the opponent, and the game identifier B for managing the game in the server apparatus 100 or the IP address Am of the opponent are notified. I do. Here, there is no need to notify the user of the IP address Am as the notification parameter when the server apparatus 100 mediates the game. Conversely, when the server does not perform game mediation, the game identifier B is unnecessary.

The originating call is sent to the client device 200,
200a to 200f are issued to the server device 100. The parameter information includes a user identifier N, a game move C specified by the user, and a game identifier B.

The move notice is issued by the server apparatus 100 to the client apparatuses 200 and 200a to 200f. The parameter information of the move notification is the same as the move transmission.

FIG. 3 is a diagram showing the configuration inside the server device. The network OS (Operating System) 110
This is an apparatus on which the CP / IP and the protocol shown in Table 1 operate. Thereby, the client devices 200, 2
Communication with 00a to 200f can be realized. The function of the network OS 110 is usually implemented by firmware or software. Of course, it is assumed that the network interface (I / F) card for transmitting and receiving physical signals is already incorporated in the server device (the same applies to the client devices 200 and 200a to 200f).

The authentication unit 120 determines whether the accessing user is a user registered in the present system. This corresponds to the client devices 200, 200a to 20a.
0f, the user identifier Ni and the password Pi sent as parameters of the request protocol from the user D
This can be realized by comparing (CP) with the data of B130. However, this function is not supported by other authentication services, for example, X.400. 500 (ITU-T (International Telecommunication
An authentication service using a directory (international recommendation on directories) defined by the Union Union-Telecommunication Sector) may be used. If the user is not a valid user, the authentication unit 120 returns an error message (Error) to the client devices 200, 200a to 200. If the user is a legitimate user, the request is transmitted to an appropriate processing function unit by the transmitted request protocol.

The user DB 130 stores user data registered in advance. Table 2 shows the contents of the data.

[0045]

[Table 2]

The identifier N is a code that uniquely identifies a user. This may be automatically assigned by the system at the time of user registration, or may be determined by the user. The name Z1 is the user's real name. The address Z2 indicates a place where the user actually lives. However, Z2 is optional and need not be present. The password P is data required at the time of authentication, and is given by the user. Of course, the password can be changed later. The face photograph Z3 is a photograph image of the user. This Z3 is also optional and need not be present. Address A is the IP address of the client device used by the user.
Address. Usually, on the Internet, the IP address often changes each time the Internet is accessed. Therefore, this field may be rewritten each time the user accesses the system. Strength R
Is a score indicating the strength of the game of the user. Application is based on user registration. The state S is a state variable used in the system, and takes a value of 0 or 1. In each case, 0 means “not waiting for game” and 1 means “waiting for game”. The game request time W is the time at which the user sent the game request to the server device. This tells how long the user has been waiting. The game identifier B is an identifier of a game played by the user or currently played,
Used when the server relays a game. By using this identifier, one user can play a plurality of opponents at the same time, and another user can watch a desired game. The player M is the identifier of the other party that the user is currently playing or will play next. In the player history L, the identifier of the partner who played the game is entered during a certain past period or a certain number of games.

When there is a game request from the user Ni, the player selection unit 140 records the address Ai and the state S = 1 in the item of Ni in the user DB 130. This operation is repeated every time a game request is sent from the user.
Automatic selection processing unit 14 under predetermined conditions
1 is started, the user DB is referred to, and the game waiting S =
1) Information of all users is read, and a player is selected by a predetermined algorithm. As a result, the identifier of the game partner is registered in the game partner M and the game history L of the items of all the users N who have selected the player in the user DB 130, and the state S is set to 0. Further, a game identification number for the determined game is set and registered in the game identifier B of each player.

At the same time, the user who has output the game request is notified of the player selection result. This notification is sent to the information Z of the opponent.
m, its strength Rm, and the identifier B of the game to be played
To each client device.

In the selection condition holding unit 150, selection start conditions for activating the automatic selection processing unit 141 are set in advance. In this embodiment, it is assumed that the following four selection start conditions can be set.

First condition: Each time a game request request is received, a player selection process for the game requester is performed. Second condition: When a predetermined time comes, a player selection process is performed.

Third condition: When the number of users waiting for a game exceeds a predetermined number, a player selection process is performed. Fourth condition: When the number of game request requests received exceeds a predetermined number, a player selection process is performed.

In the selection condition holding unit 150, at least one of such selection start conditions is set. The game management unit 160 performs a process of relaying a move of one player to the other party. In this case, the game identifier B is exchanged with the game move C at the same time in order to identify which game move the game move is. Which client device is to be transmitted can be specified by searching for a player from the user DB 130 using a game identifier and obtaining the IP address of the user.

FIG. 4 is a diagram showing the configuration of the client device. The user interface 210 is responsible for inputting information from a user and displaying information to the user. Here, the details of the user interface will be described by taking a case where it is applied to a game of shogi as an example.

FIG. 5 is a diagram showing an example of the user interface 210. The user interface 210 is provided with a game request button 211. When the game request button 211 is clicked on with a mouse, a game request instruction is transmitted to the game request unit 220. Game request button 21
Below 1 is a message display section 212. The message display unit 212 displays various messages to be notified to the user. For example, when an error message is returned by a response from the server device 100, the error message is displayed. If it is a legitimate user, this may be displayed. In the center of the screen, there is a shogi board display unit 213, which displays a game. Above and below the shogi board display unit 213, there are player display units 214 and 215. On the upper player display section 214, the name and strength of the opponent are displayed. Conversely, the lower player display section 215
Displays the user's own name and strength. The player display unit 214 can also display the IP address of the other party. In this case, it is also possible to establish a communication state with the opponent on the basis of the displayed address and play the game. On the right side of the shogi board display section 213, the possessed piece display section 2
16 and 217, and the opponent's own piece and the player's own piece are displayed, respectively.

Returning to FIG. 4, upon receiving the game request from the user interface 210, the game request unit 220 adds a user identifier Ni, a password Pii and an address Ai as a game request protocol, and
Send to When an error message is returned as a response, the error message is displayed on the user interface 210. When the player selection is completed in the server apparatus 100 and the information of the player is notified, the information is displayed on the user interface 210. The game identifier B transmitted at the same time in the game selection notification is transmitted to the game section 230 and becomes the game identification information when it is sent to the server apparatus 100.

The playing section 230 includes the user interface 2
The move transmitted from 10 is sent to the server device 100 together with the game identifier transmitted from the game request unit 220.
Also, it waits for move information from the game partner, and displays the game identifier B sent via the server and the sent move on the user interface 210.

The network OS 240 is connected to the server 1
00, the TCP / I
P, HTTP and a device on which each protocol of this system operates.

In the network game system configured as described above, the following processing is performed. FIGS. 6 to 15 show flowcharts of the server device 100 and the client 200 in order to explain the operation of the present system. In the description using the flowchart,
Description will be made along the step numbers in the figure.

First, the processing performed by the server device 100 will be described. In the server device 100 receiving the player request from the client device 200, the network OS 1
10 and the authentication unit 120 perform a receiving process.

FIG. 6 is a flowchart showing the receiving process of the server device. [S1] The network OS 110 constantly determines whether or not any signal has been received. If a signal has been received, the process proceeds to step S2. If a signal has not been received, the process of step S1 is repeated. [S2] The authentication unit 120 authenticates whether the signal sender is a valid user. This can be realized by comparing a pair of a user identifier and a password in the user DB 130. If the user is an unauthorized user, the process proceeds to step S3, and if the user is a valid user, the process proceeds to step S4. [S3] If the received signal is from an unauthorized user, the authentication unit 120 notifies the client device 200 that it is Error. Thereafter, the process proceeds to step S1 to prepare for the next reception. [S4] If the received signal is from a valid user, the authentication unit 120 determines the type of the received request.
If the player's request is a game request, the process proceeds to step S5,
If the request is a move, the process proceeds to step S6. [S5] The player selection unit 140 performs a player selection process. Thereafter, the process proceeds to step S1 to prepare for the next reception.
Details of this processing will be described later. [S6] The game management unit 160 performs a game management process. Thereafter, the process proceeds to step S1 to prepare for the next reception. Details of this processing will be described later.

Here, when relaying a move of a game, a plurality of pieces of information are exchanged instead of one-shot information communication. Therefore, in TCP / IP, between the client apparatus 200 and the server apparatus 100, for example, instead of a telegram, Establish a logical connection like a telephone, and exchange information on the connection. If this is used, the authentication process may be omitted at the time of information exchange of the game.

Here, the details of the selection process will be described. The following selection subroutine, selection process, and selection routine are all processes performed by the player selection unit 140. First, the player selection unit 140 that has received the game request
Performs the following processing according to the contents of the selection condition holding unit 150.

FIG. 7 is a flowchart of the selection subroutine. This is a process performed when a game request occurs. [S11] It is determined whether the selection start condition includes the first condition. If the first condition is included, the process proceeds to step S12; otherwise, the process proceeds to step S13. [S12] When the first condition is set (in some cases, only the first condition is set, or in some cases, the first condition is included in a combination of conditions), the processing content is set to " The automatic selection processing unit 141 is started as “first selection processing”. FIG. 8 shows the details of the first selection process. [S13] If the first condition is not set, a standby response is sent to the requesting user Ni. [S14] The state of the user Ni in the user DB 130 is set to game waiting (S ← 1), and the current time is set to the game request time W.

Note that packetization when making a response is a function performed by the network OS 110 (hereinafter, all packetization is performed by the network OS 110). FIG. 8 is a flowchart of the first selection process. This is performed when a game request occurs under the first selection condition. [S21] The user information waiting for the game is read from the user DB 130. [S22] The "selection routine a" is called to search for an opponent of the user who has requested the game. From the selection routine a, information on whether or not a partner has been found is returned by a variable p. If the partner is found, the value of the variable p is true, and if the partner is not found, the value of the variable p is fals.
e. [S23] Based on the value of the variable p, it is determined whether or not a game partner has been found. If an opponent is found, the process proceeds to step S24; otherwise, the process proceeds to step S26. [S24] If the opponent is found (if the variable p in the selection routine a is true), a response and notification of the game identifier B and the information of the opponent are sent to both of the client apparatuses to be played (here, "response"). A reply to the request,
Notification is to notify the waiting user as an event.) [S25] The user DBs 130 of both players are updated. That is, the state S is set to 0. [S26] On the other hand, if the other party is not found, a standby response is sent to the client device 200 that has output the game request. [S27] At the same time, the status S in the user DB 130 of this user is set to 1.

The above is the processing to be performed in response to the input of the game request from the client device 200. on the other hand,
The player selection unit 140 continuously performs the following second selection processing from the time when any of the above-described second selection start condition to fourth selection start condition is set in the selection condition holding unit 150. .

FIG. 9 is a flowchart of the second selection process. This is one of the second to fourth selection start conditions.
If at least one is set, the process is always running. [S31] It is determined whether any one of the conditions set in the second to fourth selection start conditions is satisfied. Step S if one of the selection start conditions is satisfied
Go to 32 and if not, repeat this step. [S32] If at least one of the selection start conditions is satisfied, the user information waiting for the game is read from the user DB 130. [S33] The "selection routine b" is called and the game is combined. Details of this processing are shown in FIG. [S34] The client device 200 of the user whose selection of the game partner is completed is notified of the game identifier B and the game partner information Zm. [S35] The state S of these users in the user DB 130 is set to 1.

The above processing is repeatedly performed. As described above, when any one of the selection start conditions is satisfied, the player selection process is started, and the user determined as the player is notified of the player identifier B and the player information Zm.

When the move information is sent from the client device 200 to the server device 100, the following game management process is performed. FIG. 10 is a flowchart of the game management process. This is a process performed by the game management unit 160 when the move C is sent from the client device 200. [S41] The game identifier B sent at the same time as the move C
Is used as a key, and the address of the corresponding game partner is
Search from B130. [S42] The move C sent from the client device 200 is transmitted to the client device corresponding to the address together with the game identifier B.

The above is the overall processing of the server device 100. The details of the selection routine will be described below. Several methods are conceivable for the selection routine. Here, an example of a selection method based on the simplest comparison will be described. In addition,
The selection routine is a process performed by the automatic selection processing unit 141.

FIG. 11 is a flowchart of the selection routine a called in the first selection process. [S51] The reference value Rx and the variable p are initialized (set).
Here, the reference value Rx is a value indicating a criterion of a difference in strength that can be selected as a player. If the difference in strength between the two users falls within this range, the player is selected as a player. . The variable p is a logical variable indicating whether or not a game partner has been found, and is “true” if a game partner has been found, and “false” if no game partner has been found.

The variables used in this processing will be described with reference to the table in Table 3.

[0072]

[Table 3]

In the table of Table 3, the item numbers are numbers assigned from “1”, and the number of users waiting for the game U
Exist up to. Hereinafter, this item number is used as a suffix. That is, the user identifier of item number "2" is "N
2 ". The identifier N, the strength R, the player M, and the player history L have the same meaning as those used in the user DB 130. At the stage where the processing routine a is being executed,
The state S of the user who has output the game request remains at 0.
Ni, Ri, Mi, and Li are users who output the game request, and are fixed here. [S52] The item number “k” is set to “0”. [S53] One is added to the value of the item number "k". [S54] It is confirmed that the identifier "Nk" is not included in the player history "Li" of the user who has output the game request. If it is included, the process proceeds to step S53, and if not, the process proceeds to step S55. [S55] Strength "Ri" of user who output game request
Is different from the strength “Rk” of the user of the identifier “Nk”,
It is determined whether the value is smaller than the reference value “Rx”. If it is smaller than the reference value "Rx", the process proceeds to step S56, and if not, the process proceeds to step S57. [S56] The user with the identifier "Nk" is determined as the opponent of the user who has output the game request, and the user DB 130
Update the contents of Specifically, the identifier “Nk” of the item number “k” is registered in the player “Mi” of the user (identifier “Ni”) that has output the game request, and the player “Mk” of the item number “k” is registered. "In the item number" i "
i ". Further, the identifier “Nk” of the item number “k” is registered in the player history “Li” of the item number “i”, and the identifier of the item number “i” is stored in the player history “Lk” of the item number “k”. Register “Ni”. Further, since a player is found, the logical variable “p” is set to “true”. When these settings are completed, the process ends. [S57] It is determined whether or not the item number "k" has become equal to or greater than the number U of users waiting for the game. If it is greater than or equal to U, the process proceeds to step S58; otherwise, the process proceeds to step S53. [S58] Since no opponent was found, the logical variable "p" is set to "false", and the process ends.

As a result of such processing, a user whose strength difference is within Rx and who has not played in a predetermined period or within the number of games is selected as a game partner.

FIG. 12 is a flowchart of the selection routine b called in the second selection process. In this process, variables as shown in Table 3 are used. [S61] The set S and the set P are initialized (empty set), and the reference value Rx is initialized (set). The set S is a set of item numbers for which processing has been completed, and the set P is a set of item numbers for which processing has been performed but no partner has been found. [S62] The value "i" of the selected item number is initialized to zero. [S63] One is added to the value of "i". [S64] It is determined whether or not “i” is included in the set S. If the user is included in the set S, the game partner of the user corresponding to the item number has already been determined, and the process returns to step S63. If not included in the set S, the process proceeds to step S65. [S65] The value "k" of the item number to be compared is initialized to zero. [S66] 1 is added to the value of “k”. [S67] It is determined whether or not the user of item number "k" satisfies the basic conditions as a game partner. As a basic condition, first, oneself is excluded (i ≠ k). Then, the already processed item numbers (those in the set S),
Also, users who have already played in a predetermined period or within the number of games (those in the set Li) are excluded from selection. If these conditions are satisfied, the process proceeds to step S68. If the condition is not satisfied, the process proceeds to step S66. [S68] It is determined whether or not the difference in strength between the user of item number "i" and the user of item number "k" is greater than Rx (| Ri-Rk |> Rx). If the difference in strength is equal to or smaller than Rx, the process proceeds to step S69, and if the difference in strength is larger than Rx, the process proceeds to step S70. [S69] The item number “i” and the item number “k” are included in the set S indicating that processing has been completed. The identifier “Nk” of the item number “k” is registered in the player “Mi” of the item number “i”, and the identifier “Ni” of the item number “i” is registered in the player “Mk” of the item number “k”. Is registered. Further, the identifier “Nk” of the item number “k” is registered in the player history “Li” of the item number “i”, and the identifier of the item number “i” is stored in the player history “Lk” of the item number “k”. Register “Ni”. When these settings are completed, the process proceeds to step S72. [S70] It is determined whether the item number "k" being compared is equal to or greater than the maximum item number "U" indicating the user waiting for the game. If "k" is equal to or greater than "U", step S
Proceed to 71, otherwise return to step S66. [S71] The set P includes the item number “i”. That is, an appropriate player of the user with the item number "i" was not found. [S72] It is determined whether the selected item number "i" is equal to or larger than the maximum item number "U". If "i" is greater than or equal to "U", the process ends; otherwise, the process returns to step S63.

As a result, for each user from the item numbers “1” to “U”, a user whose strength difference is within Rx is selected. It should be noted that the above may be replaced by the order of the users, and a combination having the minimum | Ri−Rk | may be selected. Further, Rx may be increased so that the set P becomes empty.

The processing performed by the server device 100 has been described above. Next, the operation of the client device will be described. First, the processing functions of the user interface will be described.

FIG. 13 is a flowchart of the process performed by the user interface. All this processing is performed by the user interface 210. [S101] The user interface 210 monitors whether there is an input from an input device such as a mouse. As shown in FIG. 5, as items that can be input by the user, one game request button 211 and the operation panel of the move (pointing to the area of the shogi board display section 213 and the possessed piece display sections 216 and 217).
In addition to monitoring these, the game request unit 22
0 and a request from the game unit 230 will be monitored. [S102] It is determined whether the input is from an input device. If the input is from the input device, the process proceeds to step S103; otherwise, the process proceeds to step S106. [S103] It is determined whether or not the input is a game request. If the game request button 211 has been clicked with a mouse and a game request has been input, the flow proceeds to step S104, and if the move operation panel has been operated and a hand has been input, the flow proceeds to step S105. [S104] The game request unit 220 is instructed to issue a game request. Thereby, the game request unit 220
Then, the game request processing is started. After this processing, the process proceeds to step S101. [S105] A move is transmitted to the game section 230, and the process proceeds to step S101. [S106] It is determined whether or not the input is from the game request unit 220. If the input is from the game request unit 220, step S
The process proceeds to step S107, otherwise, it is determined that the input is from the game unit 230, and the process proceeds to step S108. [S107] Information such as the game partner input from the game request unit 220 is displayed. In the case of a game partner, the information Zn of the game partner and the strength Rn of the game partner are displayed in the player display unit 2.
14 (shown in FIG. 5). In the case of a display request to wait, or a display request to indicate that an error has occurred, the content is displayed on the message display unit 212 (shown in FIG. 5). After that, it advances to step S101. [S108] The arrangement of the pieces on the operation panel of the move is updated according to the move input from the game unit 230, and step S is executed.
Go to 101.

Next, the processing executed by the game request unit will be described. FIG. 14 is a flowchart of the game request process.
This processing is performed when the game request is output from the user interface 210 to the game request unit 220.
0 is a process to be executed. [S111] Using the game request protocol, the user identifier Ni is transmitted to the server 100 including the password Pi and the address Ai. Here, since the address is set in the client device 200 in advance, it is possible to automatically detect the address even if the user does not input it and to put it on the protocol. [S112] It is determined whether there is a response to the game request. If there is a response from the server device 100 to the game request, the process proceeds to step S113. If there is no response, the process proceeds to step S11.
Step 2 is repeated. [S113] It is determined whether the response has been normally returned without an error. If there is an error, the process proceeds to step S117, and if there is no error, the process proceeds to step S114. [S114] It is determined whether a selection result has been received. If the selection result has been received, the process proceeds to step S115,
Otherwise, the process proceeds to step S116. [S115] The selection result (the information Zn of the opponent and the strength Rn of the opponent) is transmitted to the user interface 210 and displayed, and the game identifier B is transmitted to the player 230, and the process is terminated. [S116] Information indicating that the user should wait is transmitted to the user interface 210 and displayed, and the process proceeds to step S114. [S117] Information indicating that an error has occurred is transmitted to the user interface 210 for display, and the process ends.

Next, the processing executed by the game unit 230 will be described. FIG. 15 is a diagram showing a flowchart of the game processing. This is a process that is always executed by the game unit 230 when the game is started. [S121] It is determined whether there is an input from the user interface 210 or the server apparatus 100. If there is an input, the process proceeds to step S122, and if there is no input, the process is repeated to wait for an input. [S122] It is determined whether the input is from the user interface 210 or the server device 100. If the input is from the user interface 210, the process proceeds to step S123. If the input is from the server device 100, the process proceeds to step S124. [S123] If the input is from the user interface 210, the game identifier B, the move C, and the user identifier N
i is transmitted to the server device 100. [S124] If the input is from the server device 100, the received move C is transmitted to the user interface 210 together with the game identifier B.

The above is the processing in the client device 200. In this way, the server apparatus 100 can automatically determine the opponent of the user who wants to play, and notify the client apparatus used by the user of the information on the opponent. As a result, there is no need for the user to find a game partner.

Further, the server apparatus 100 performs the player selection process when the selection start condition is satisfied. Therefore, if an appropriate selection start condition is set in advance, the selection range of the opponent can be expanded and the user can be selected. Eliminates the need to constantly monitor the selection result.

Further, since the server apparatus 100 relays the move of the game, there is no need to connect a communication line between the players. Next, a second embodiment will be described. The second embodiment is obtained by adding various applied technologies to the basic configuration shown in the first embodiment.

As applications, there are entry / exit, strength evaluation, various information displays, and further, the following extended functions are provided for enhancing automatic selection. 1) A fifth selection start condition, in which a player whose player is not determined within a predetermined time is selected from another player DB (hereinafter referred to as a first extended function). ). 2) A user waiting for a game having a long waiting time is preferentially selected (hereinafter referred to as a second extended function). 3) The selection range of the opponent is determined based on the differential value of the increase / decrease of the score indicating the player's strength (hereinafter, referred to as a third extended function). 4) The selection range of the game partner is changed according to the game waiting time of the game waiting user (hereinafter, referred to as a fourth extended function).

Here, the protocol between the server and the client used in the second embodiment is shown in Table 4.

[0086]

[Table 4]

In this embodiment, the protocols are classified into “basic” and “applied”. The protocol used in the first embodiment is "basic", and a protocol newly defined to implement this embodiment is "application".
It is. There are four types of applied protocols besides the basic ones.

“Entry” is a protocol that is first issued to a server device by a user to enter the system.
The server device returns a service menu provided by the system as a result. As a result, only legitimate users can access the services of the present system.

"Exit" is a protocol for a user to exit the system. By combining this with an entrance protocol and allowing users to access only during the period from entry to exit, it is possible to increase the security of the system.

"End" is a protocol indicating that the game has ended. This makes it possible for the server to immediately use the result of the game for calculating the player's strength.

"Display" is a protocol that can request display of information in the user DB. The meanings of the parameters are the same as those shown in Table 1. FIG. 16 shows a second embodiment of the present invention.
It is a figure showing the composition of the server device of an embodiment. The server device 300 is connected to the client device 400 via a network.

The network OS 310 can recognize all the protocols shown in Table 4 above. The authentication unit 320 is the same as that already described in the basic configuration (the configuration shown in FIG. 3).

The visitor accepting section 330 receives the entrance protocol from the client device 400, initializes the requested state of the user Ni (S = 0), and returns the service menu of the present system to the client device 400. . First
In the basic configuration shown in the embodiment, only an unauthorized user can access, but by using this function, only a legitimate user is allowed to access. As a result, the load on the server can be reduced.

The exit receiving unit 340 is used as a pair with the above-mentioned entrance receiving unit 330. When a leaving request is received, the state of the user is initialized (S = 0), and the service menu is closed.

The player selection unit 350 has a function of finding a player using the backup player DB 362 for a user whose player is not found in the user DB 361, in addition to the function of the basic configuration. included.

The user DB 361 stores user data registered in advance, as in the first embodiment. The contents of the data are as shown in Table 2. The preliminary player DB 362 is a DB of users who are registered in advance and are waiting in response to a player re-request. The contents of the data stored in the backup player DB 362 are the same as those of the user DB 361.

When the game is over, the strength evaluation unit 370 calculates the strength of each player from the result of the game and the strength of the players according to a predetermined rule.
The strength of each user who played in the user DB 361 is rewritten. First, the player Mi of the user Ni who has issued the end is obtained from the user DB 361, and the strengths of the user and the player are read from the user DB 361. Based on these, the strength is recalculated and written to the user DB 361, respectively.

As an example of a rule for calculating the strength, there is a rating method used as a strength judgment method in shogi as follows. In this rating method, a goal is calculated by the following formula, and the score is added to or subtracted from the original score of the winner or the loser. (1) If the higher score wins, the score = 16-(point difference x 4%) (2) If the lower score wins, the score = 16 + (point difference x 4%) If the player with the higher score wins, the difference
If the score exceeds 00, the score will be a negative number. In this case, the strength is not changed. However, in the automatic player selection process, if the difference between the strengths is equal to or more than a certain threshold, the player is not selected as a game partner.
If it is set to 0 or less, the point difference will not exceed 400 points.

[0099] The display information providing unit 380 stores the user DB 36
1 has a function of responding to the client device 400. That is, it receives a display request item from the client device 400 and responds with a corresponding item. However, the password cannot be answered.

The selection condition holding unit 390 includes a selection start condition (first condition to fourth condition) shown in the first embodiment and a fifth extension function which is a first extension function of the present embodiment. Can be set.

The game management section 300a has the same function as the basic configuration (game management section 160 in FIG. 3). Next, the configuration of a client device corresponding to the server device 300 will be described.

FIG. 17 is a diagram showing the configuration of the client device according to the second embodiment. Network OS 410
Can transmit and receive all the protocols in Table 4 described above.

The user interface 420 inputs information from a user and displays information to the user. This user interface 420 is an extension of the functions of the user interface according to the first embodiment.

FIG. 18 is a diagram showing an example of the extended user interface 420. Note that the game request button 421, the message display unit 422, and the shogi board display unit 4
23, player display sections 424 and 425, and possessed piece display sections 426 and 427 are the same as those having the same names of the user interface 210 of the first embodiment shown in FIG.

As input switches added in the present embodiment, there are an exit button 420a and an exit button 420b. The exit button 420a is a button to be clicked when losing is recognized, and an end instruction is output by clicking this button. Exit button 420b
This button is a button to be clicked when ending use of the service of the server device 300. When this button is clicked, a leaving instruction is output.

As a display function, remaining time display section 420
c, 420d are added. This remaining time display part 4
Reference numerals 20c and 420d indicate the remaining remaining time of each player in the game provided with the time limit.

The user interface shown in FIG. 18 shows a screen after the user has already entered. Before entry, an entry button (not shown) is provided. When the entry button is clicked, an entry request is output.

Returning to FIG. 17, entrance request section 430 transmits an entrance request from user interface 420 to server device 300, and transmits a response to user interface 42.
Display at 0. The entry request transmitted to the server device 300 includes the user identifier Ni and the password Pi.

The game request unit 440 has basically the same function as the game request unit 220 (shown in FIG. 4) of the first embodiment. When the termination request (loss indication) is transmitted from the user interface 420, the termination request unit 450 transmits the termination information to the server 300 using the termination protocol. Then, it waits for a response from the server device 300, and if the process is normally performed, the user interface 420
Displays a message indicating the end of the game.

[0110] The above-mentioned withdrawal information is, of course, also transmitted to the game section 480, so that it is possible to recognize that of the game partner. The exit request unit 460 performs a process for a user to leave the system. The exit protocol is transmitted to the server device 300, and when a response is received, a message indicating the completion of the process is displayed on the user interface 420.

The display request section 470 selects an information item that the user wants to know, reads out the information from the server device, and displays it. The playing unit 480 has the same function as the playing unit 230 (shown in FIG. 4) shown in the first embodiment.

The image embedding section 490 is combined with the game section 480 and the camera 50 to simultaneously transmit a still image of the player at the moment when the move is pointed to when the move is transmitted to the opponent. The side receiving the similar image displays the still image on the screen together with the move. By doing so, the presence of the game can be increased.

Hereinafter, the operation of the present system will be described together with the flowchart of the basic function. 19 to 29 show flowcharts of characteristic processing functions of the server device 300 and the client device 400 of the present system.

FIG. 19 is a flowchart showing a receiving process in the server device. [S201] The network OS 310 determines the presence / absence of reception. If various requests are received, the process proceeds to step S202, and if not received, the process is repeated. [S202] If any reception occurs, the authentication unit 320 authenticates whether it is a valid user. If it is a valid user, the process proceeds to step S204, and if it is an unauthorized user, the process proceeds to step S203. [S203] If the authentication of the received request fails,
The authentication unit 320 notifies the client device 400 of an error message. [S204] If the authentication unit 320 is a valid user,
The type of the received request is determined, and each process is executed. [S205] In the case of an entrance request, the visitor reception unit 330
Executes an admission reception process (details are shown in FIG. 20). [S206] In the case of a termination request, the strength evaluation unit 370 executes termination processing (details are shown in FIG. 21). [S207] In the case of a leaving request, the leaving person receiving unit 340
Performs a leaving process (details are shown in FIG. 22). [S208] In the case of a game request, the player selection unit 350
Performs the selection process. Details of this processing are shown in FIGS.
Is the same as the processing of the first embodiment shown in FIG. However, the content of the processing performed in step S22 of the first selection processing in FIG. 8 is different (the selection routine a 'is executed instead of the selection routine a). [S209] In the case of a move request, the game management Part 300
a performs game processing. The details are the same as the processing of the first embodiment shown in FIG. . [S210] In the case of a display request, the display information providing unit 38
0 is requested from the user DB 361.

Step S203, steps S205 to S
When the process of 210 is completed, the device that has performed each process returns a result of the process to the requesting client device. The actual packetization is performed by the network OS 31
0 does. Thereafter, the flow returns to step S201 to prepare for the next reception.

FIG. 20 is a flowchart of the admission reception subroutine. This means that when an admission request occurs,
This is a process performed by the visitor reception unit 330. [S221] The state of the requesting user Ni is initialized (S ← 0). [S222] The service menu of the system is changed to the user N
Respond to i. The service menu specifically includes a game request and an exit.

FIG. 21 is a flowchart of the end subroutine. This is a process performed by the strength evaluation unit 370 when a termination request is issued. [S231] The strength of the user Ni who has requested termination and the strength of the player Mi are calculated based on the result of the win and loss and the original strength. This calculation method is as described above. [S232] The calculated result is recorded in the user DB 361. Then, a response to the completion of the process is sent to the user Ni, and the process is terminated.

FIG. 22 is a flowchart of the exit subroutine. This is performed by the exiting person reception unit 340 when an exit request is issued. [S241] Change the status of the user who has requested exit (S241)
← 0). [S242] A response to the exit confirmation is sent to the user Ni, and the process is completed.

Next, a flowchart of the selection process including the first extended function will be described, and then a flowchart including the second to fourth extended functions will be described. Here, the selection processing realizing the first extended function is referred to as “third selection processing”.

FIG. 23 is a flowchart of the third selection process. This is a process that is always performed by the player selection unit 350 when the fifth selection start condition is set. [S251] It is determined whether or not the game waiting time of the user has become equal to or longer than a predetermined waiting time. If the waiting time has not been exceeded, this step is repeated. If the waiting time has been exceeded, the process proceeds to step S252. [S252] The game waiting user information is read from the user DB 361, and the standby player information is read from the standby player DB 362. [S253] The selection routine c is read. [S254] If the opponent is determined for the user who has exceeded the waiting time, this is notified to the client device. [S255] Finally, the user DB 361 is updated.

In this flowchart, it is assumed that sufficient preliminary players have been registered in the preliminary player DB 362. FIG. 24 is a flowchart of the selection routine c called in the third selection process. [S261] The reference value Rx is initialized (set). Rx is a reference value of the difference in strength. [S262] The item number "k" is set to "0". The variable k used in this process is a number assigned from 1 and exists up to the number V of registrants in the preliminary player DB 362.
N, R, M, and L have the same meaning as the symbols used in the user DB 361. Ni, Ri, Mi, and Li are users who have exceeded the game waiting time, and are fixed here. [S263] 1 is added to the value of the item number "k". [S264] It is confirmed that the identifier "Nk" is not included in the player history "Li" of the user who has output the game request. If it is included, the process proceeds to step S263. If it is not included, the process proceeds to step S265. [S265] Strength "Ri" of user who output game request
Is different from the strength “Rk” of the user of the identifier “Nk”,
It is determined whether or not the strength is larger than the reference value “Rx”. If it is larger than the reference value "Rx", the process proceeds to step S267,
Otherwise, the process proceeds to step S266. [S266] The user with the identifier "Nk" is determined as the opponent of the user who has output the game request, and the user DB 36
1 and the contents of the backup player DB 362 are updated. Specifically, the identifier “Nk” of the item number “k” is registered in the player “Mi” of the item number “i”, and the player number “Mk” of the item number “k” is registered in the player “Mk” of the item number “k”. The identifier "N
i ". Further, the identifier “Nk” of the item number “k” is registered in the player history “Li” of the item number “i”, and the identifier of the item number “i” is stored in the player history “Lk” of the item number “k”. Register “Ni”. When these settings are completed, the process ends. [S267] The item number “k” is stored in the reserve player DB 362.
It is determined whether the number of registrants has reached V or more. If it is not less than V, the process proceeds to step S268; otherwise, the process proceeds to step S263. [S268] The value of Rx is added with α (a preset value smaller than Rx), and the process advances to step S262 as a new value of Rx.

In this way, a preliminary player whose strength difference from the user Ni is less than Rx is found from the preliminary player DB 362, and if not found, the selection range Rx
By gradually increasing, I always try to find the opponent.

Next, a selection process including the second to fourth extended functions will be described. This is performed by calling the selection routine a 'instead of the selection routine a in step S22 when the first selection processing (shown in FIG. 8) is performed.

FIG. 25 is a flowchart of the selection routine a ′ called in the first selection process. [S271] The reference value Rx and the variable p are initialized (set). Here, Rx is a reference value of the difference in strength, and the variable p
Is a logical variable indicating whether or not a game partner has been found. The following Ni, Ri, Mi, and Li are the users who output the game request, and are fixed here. [S272] The selection target tables (item numbers 1 to U) are sorted in descending order of waiting time. [S273] The strength Ri of the user who is going to be selected is corrected based on the latest battle result. For example, if Ri tends to increase, the current Ri is increased by ΔRi. Here, ΔRi is a value indicating an increase / decrease rate of Ri. However, R in the actual DB is not changed, but is changed and changed only in the selection routine a '. [S274] The item number "k" is set to "0". [S275] 1 is added to the value of the item number "k". [S276] It is confirmed that the identifier "Nk" is not included in the player history "Li" of the user who has output the game request. If it is included, the process proceeds to step S275, and if not, the process proceeds to step S277. [S277] The strength Rk of the user who is about to be selected is corrected based on the latest battle result. The correction method is the same as that performed on Ri in step S273. [S278] The reference value Rx of the difference between the respective intensities is changed according to the length of the waiting time. Assuming that Rxi changed according to the waiting time of Ni and Rxk changed according to the waiting time of Nk, the smaller one is selected at the time of selection, and it is used as the difference Rx of the strength of selection. . [S279] Strength "Ri" of user who output game request
Is different from the strength “Rk” of the user of the identifier “Nk”,
It is determined whether or not the strength is smaller than the reference value “Rx”. If it is smaller than the reference value “Rx”, the process proceeds to step S280,
Otherwise, the process proceeds to step S281. [S280] The user with the identifier "Nk" is determined as the opponent of the user who has output the game request, and the user DB 13
Update the contents of 0. Specifically, the identifier “Nk” of the item number “k” is registered in the player “Mi” of the item number “i”, and the player number “i” of the item number “k” is registered in the player “Mk” of the item number “k”. The identifier “Ni” is registered. Further, the identifier “Nk” of the item number “k” is registered in the player history “Li” of the item number “i”, and the identifier of the item number “i” is stored in the player history “Lk” of the item number “k”. Register “Ni”. Also, since the player was found, the logical variable "p"
Set to "true". When these settings are completed, the process ends. [S281] The item number “k” is the number of users waiting for the game U
It is determined whether or not the above has been achieved. If it is equal to or greater than U, the process proceeds to step S282; otherwise, the process proceeds to step S275. [S282] Since no opponent was found, the logical variable "p" is set to "false" and the process ends.

Next, the operation of the client device 400 will be described. FIG. 26 is a flowchart of a user input process on the client. This is a process performed by the user interface 420. [S301] The presence or absence of an input from the user is monitored. If there is an input, the process proceeds to step S302, and if there is no input, the monitoring process is continued. [S302] When there is a user input, the type of the request is determined, and the request is transmitted to the device that executes the process. [S303] In the case of an entry request, the entry request unit 430 performs an entry process (details are shown in FIG. 27). [S304] In the case of a termination request, the termination request unit 450 performs termination processing (details are shown in FIG. 28). [S305] In the case of an exit request, the exit request unit 460 performs exit processing (details are shown in FIG. 29). [S306] In the case of a game request, the game request unit 440 performs a game request process (details are the same as those of the first embodiment shown in FIG. 14). [S307] In the case of a move, the move is transmitted to the game unit 480. [S308] In the case of a display request, the display request unit 470 acquires necessary data from the server device 300 and displays it on the screen of the user interface 420.

When the processing in any of steps S303 to S308 is completed, the flow returns to step S301. FIG. 27 is a flowchart of the entrance subroutine. This processing is performed by the entrance requesting unit 430. [S311] Using the entrance request protocol, Ni and Pi are transmitted to the server 300 as parameters. [S312] Wait for a response from the server device 300. [S313] The response result from the server device 300 is displayed.

FIG. 28 is a flowchart of the end subroutine. This is executed when the user clicks the exit button 420a. This is a process performed by the request ending unit 450. [S321] The termination is notified to the game unit 480. [S322] Ni and Pi are transmitted to the server 300 as parameters using the termination request protocol. [S323] The server 300 waits for a response. [S324] The response result from the server device 300 is displayed.

FIG. 29 is a flowchart of the exit subroutine. This is a process performed by the exit request unit 460. [S331] Ni and Pi are transmitted to the server 300 as parameters using the exit processing protocol. [S332] Wait for a response from the server device 300. [S333] The response result from the server device 300 is displayed.

As described above, since the system automatically selects the opponent to play, and indicates to each user, there is no need for the user himself to find the opponent. Further, it is not necessary for the user to constantly monitor whether or not the selection result is obtained.

Of course, since the user DB includes the user's network address (a telephone number is also acceptable),
You do not need to look up the contact information of your opponent. In addition, the following effects can be obtained when selecting. 1) There is no case where the opponent is not selected forever. 2) The possibility of finding the best partner increases. 3) The strength of the game at that time is automatically reflected, and the opponent is selected accordingly. 4) The system of entering and leaving the system improves the security of the system, and at the same time, the waiting time for player selection can be changed according to the access status to the system, so that the game can always be started with the shortest waiting time. Become like 5) When playing a game, since the still image of the opponent can be seen, the presence of the game increases.

Next, a third embodiment will be described. Until now, the embodiments described above only select a user from a single selection range (hereinafter referred to as a stage) and play a game, but in this embodiment, it is possible to have a plurality of stages. Things. This will be described with reference to a case where it is applied to a tournament match.

For simplicity, the number of tournament participants is eight. Then, the following situation is assumed. 1) At the start of the tournament match, eight players have registered in the first stage. However, these eight people are not connected to the server at the same time. 2) At a certain point in time, consider a case where only five of the eight people are connected to the server. These five are in the first stage, where the selection is made. This selection may be made automatically as described in the present invention, or the user may himself select from a user list in the first stage. 3) In this way, a game is played, and a win or a loss is determined. Then, the winning user proceeds to the second stage. The losing user may delete the registration from the tournament battle as it is, or may move to the 0th stage, which is a lower stage of the first stage, as the loser resurrection battle. 4) In this way, up to four players are played, one player remains in the first stage, and two players enter the second stage. 5) The one remaining in the first stage waits until another tournament participant connects to the server and joins the first stage, or disconnects from the server and waits for the next opportunity. 6) The two players in the second stage, if they are still connected to the server, play further, and the winner goes to the third stage.

[0133] In this way, a tournament battle can be performed even when all tournament participants are not connected to the server at the same time. By doing so, it is not necessary to negotiate prior connection times between the participants.

The system configuration to which a stage management function is added will be described below. FIG. 30 is a diagram illustrating a configuration of a server device according to the third embodiment. This server device 500
Is connected to the client device 600 via a network. The server device 500 is a network OS
510, authentication section 520, user DB 530, player selection section 540, selection condition holding section 550, game management section 560,
And a stage management unit 570. Each component other than the stage management unit 570 has an additional function to the same function as the component of the alliance of the first embodiment shown in FIG. Hereinafter, the added functions will be described.

In the user DB 530, information on the stage state of each user is registered. User DB 530
Table 5 below shows the registered items.

[0136]

[Table 5]

As described above, the stage information (ST) is provided, and the number of the stage to which the user belongs is registered. When the value is “null”, it indicates that the stage does not belong to any stage.

When receiving the game request, the player selection unit 540 sets the user who issued the request to the game waiting state (S
i = 1) and the user's stage information (S
Read Tn). Next, the automatic selection processing unit 541 reads a user who has the same stage information (ST = STn) and is waiting for a game, and performs a selection process. In the case of the tournament battle in the above example, there is usually only one player waiting for the game, and the condition for always playing the game is provided.

In the above description, the players are assigned by the automatic selection processing unit 541. However, a list of users waiting for the game is displayed on the client side, and the client side selects the user list.
It is also possible to issue a game request to the user waiting for the game.

The stage management section 570 receives the end notification sent from the client device 600 when the game ends. Based on the notification, the player's stage information (STn) is read from the user DB 530, and the stage information of each player is updated. In the above example of the tournament match, one is added to the stage information of the winning player (S
Tn = STn + 1), and the loser is deleted from this tournament match (STn = null).

FIG. 31 is a diagram showing a configuration of a client device according to the third embodiment. The client device 600 according to the present embodiment includes a user interface 610, a game request unit 620, a network OS 640, and a game unit 63.
0 and an end request unit 640. Each component has the same function as the component of the alliance of the second embodiment shown in FIG.

Hereinafter, processing characteristic of the present embodiment will be described.
This will be described with reference to the flowcharts of FIGS. FIG.
2 is a flowchart of a server device reception process. [S401] The network OS 510 constantly determines whether or not any signal has been received. If a signal has been received, the process proceeds to step S402. If no signal has been received, the process of step S401 is repeated. [S402] The authentication unit 520 authenticates whether the sender of the signal is a valid user. If the user is an unauthorized user, the process proceeds to step S403. If the user is a valid user, step S4.
Go to 04. [S403] If the received signal is from an unauthorized user, the authentication unit 520 notifies the client device 600 that it is Error. Then, step S40
Proceed to 1 to prepare for the next reception. [S404] If the received signal is from a valid user, the authentication unit 520 determines the type of the received request. If the request is an end request, the process proceeds to step S405. If the game is required, the process proceeds to step S406.
Proceed to 07. [S405] The stage management unit 570 performs end processing. Thereafter, the process proceeds to step S401 to prepare for the next reception. Details of this processing are shown in FIG. [S406] The player selection unit 540 performs a fourth selection process. Thereafter, the process proceeds to step S401 to prepare for the next reception. Details of this processing are shown in FIG. [S407] The game management unit 560 performs a game management process. Thereafter, the process proceeds to step S401 to prepare for the next reception.
This processing is the same as the processing of the first embodiment shown in FIG.

FIG. 33 is a flowchart of the end subroutine. This is a process performed by the stage management unit 570. [S411] The stage information of the users Ni and Mi (both players) is updated. Specifically, 1 is added to the winning user stage information, and empty (null) is added to the losing user stage information. [S412] The user stage information updated in step S411 is recorded in the user DB 530.

FIG. 34 is a flowchart of the fourth selection process. This is a process performed by the player selection unit 540. [S421] The information of the user waiting for the game at the same stage as the stage of the user who issued the game request is stored in the user DB5.
Read from 30. [S422] It is determined whether a partner has been found. If found, the process proceeds to step S423; otherwise, the process proceeds to step S425. [S423] If a match is found, the match is introduced to each user's client device (response and notification of game information). [S424] The user statuses of both user DBs 530 are updated from game waiting to game playing (S = 0), and this process ends. [S425] If no game partner is found, a standby response is sent to the client device of the user who issued the game request. [S426] The user status of the user DB 530 that has output the game request is set to game waiting (S = 1), and the process ends.

As described above, by changing the stage of each user every time the game is completed, it becomes possible to conduct a tournament battle via the network. FIG.
It is explanatory drawing of the stage of a tournament battle. Eight tournament participants have entered the first stage 51, and five are currently connected to the server device 500. Two of the four players play a game, and the two win and advance to the second stage 52. In the second stage, the game is played immediately and 1
The person is proceeding to the third stage 53. All we have to do is wait for another to win.

Conventionally, in a tournament match, prior negotiations between users, such as “starting at 22:00”, have been required. However, by performing the above-described stage management, a time adjustment in advance is required. As a result, each user can connect to the server at any time and execute a tournament match.

As described above, in each embodiment, the game is played in a server-client mode via a server. This can be performed between the clients. This reduces the load on the server and improves the communication speed.

In this embodiment, a database (DB) is used as a means for retrieving and storing information of a user. However, this can be realized by using a normal file system. Of course, the network used here can be either wireless or wired.

In the above embodiment, the game for two players has been described, but the present invention is not limited to the game for two players. In order to select a game partner of three or more games, for example, mahjong, the selection routine of the automatic selection process is repeated three times for one user to select three game partners. It is possible to have four members of Mahjong.

In the present invention, the selection process is described to be performed by the server device. However, the server device may manage only the user DB, and the selection process may be performed by each client device. It is. In this case, information necessary for the selection process is sent from the server device to the client device before the selection process is performed. By doing so, especially when a large number of people connect to the server and play a network game, the processing is distributed to each client device, and the load on the server is reduced.

Although the present invention does not consider the conditions specified by the user, the conditions specified by the user can of course be included in the selection conditions as the first request. This allows further optimization.

Note that the above processing functions can be realized by a computer. In this case, the processing contents of the functions to be possessed by the server device and the client device are described in a program recorded on a computer-readable recording medium. Implemented by computer. Examples of the computer-readable recording medium include a magnetic recording device and a semiconductor memory. When distributing in the market, CD-ROM (Compact Disk Read Only)
The program may be stored and distributed in a portable recording medium such as a memory or a floppy disk, or stored in a storage device of a computer connected via a network, and transferred to another computer via the network. When the program is executed by the computer, the program is stored in a hard disk device or the like in the computer, and is loaded into the main memory and executed.

[0153]

As described above, in the network game system according to the present invention, the selection is made in the server device based on the condition specified in advance so as to obtain a more suitable combination, so that the opponent is not selected forever. Such a thing disappears. In addition, there is a high possibility that an optimal partner can be found.

Further, since the network game server device of the present invention makes a selection based on a condition specified in advance so as to make a more suitable combination, the network game server device requires a short waiting time for a user who has output a game request. , A more suitable game partner can be selected.

In the computer-readable recording medium on which the player selection program according to the present invention is recorded, the computer is made to perform a process of making a selection based on a condition specified in advance so as to obtain a more suitable combination. Therefore, the network game server device of the present invention can be realized on a computer.

[Brief description of the drawings]

FIG. 1 is a principle configuration diagram of the present invention.

FIG. 2 is an overall schematic configuration diagram of the network game system according to the embodiment of the present invention.

FIG. 3 is a diagram showing a configuration inside a server device.

FIG. 4 is a diagram illustrating a configuration of a client device.

FIG. 5 is a diagram illustrating an example of a user interface.

FIG. 6 is a flowchart illustrating a receiving process of the server device.

FIG. 7 is a flowchart of a selection subroutine.

FIG. 8 is a flowchart of a first selection process.

FIG. 9 is a flowchart of a second selection process.

FIG. 10 is a flowchart of a game management process.

FIG. 11 is a flowchart of a selection routine a called in the first selection process.

FIG. 12 is a flowchart of a selection routine b called in the second selection process.

FIG. 13 is a flowchart of a process performed by a user interface.

FIG. 14 is a flowchart of a game request process.

FIG. 15 is a diagram showing a flowchart of a game process.

FIG. 16 is a diagram illustrating a configuration of a server device according to a second embodiment of this invention.

FIG. 17 illustrates a configuration of a client device according to the second embodiment.

FIG. 18 is a diagram illustrating an example of an extended user interface.

FIG. 19 is a flowchart showing a receiving process in the server device.

FIG. 20 is a flowchart of an entrance reception subroutine.

FIG. 21 is a flowchart of an end subroutine.

FIG. 22 is a flowchart of a leaving subroutine.

FIG. 23 is a flowchart of a third selection process.

FIG. 24 is a flowchart of a selection routine c called in a third selection process.

FIG. 25 is a flowchart of a selection routine a ′ called in the first selection process.

FIG. 26 is a flowchart of a user input process on a client.

FIG. 27 is a flowchart of an entrance subroutine.

FIG. 28 is a flowchart of an end subroutine.

FIG. 29 is a flowchart of a leaving subroutine.

FIG. 30 is a diagram illustrating a configuration of a server device according to a third embodiment.

FIG. 31 is a diagram illustrating a configuration of a client device according to the third embodiment.

FIG. 32 is a flowchart of a server device reception process.

FIG. 33 is a flowchart of an end subroutine.

FIG. 34 is a flowchart of a fourth selection process.

FIG. 35 is an explanatory diagram of a tournament battle stage.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 10 Server apparatus 11 User information storage means 12 Player selection means 13 Game partner notification means 14 Game management means 20 Client device 21 Game request means 22 Game means 31 Network

Claims (18)

[Claims] 1. A network game system for playing a game between an unspecified number of participants on a communication network, a user information storage means for storing information of a plurality of users,
Upon receiving a game request, a game request responding means for distinguishing a user who has transmitted the game request as a game wait, and a use distinguished as a game wait according to a selection condition specified in advance so as to form a more suitable combination. A network device comprising: a server device comprising: player selection means for determining a combination of games played by players; and a client device comprising: game request means for outputting the game request to the server device. Game system. 2. The server apparatus according to claim 1, wherein said server apparatus further comprises a game partner notifying means for notifying each player selected by said player selecting means of information on a game partner. Network game system. 3. The network according to claim 1, wherein said server device further comprises a game management means for relaying information for advancing a game between the players selected by said player selection means. Game system. 4. The method according to claim 1, wherein the player selection means of the server device specifies, as the selection condition, that a user who has a long waiting time should be preferentially selected. The network game system as described. 5. The network game system according to claim 1, wherein the player selection means of the server device specifies a start condition of a player selection process as the selection condition. 6. The selection condition that the player selection means of the server device should perform a player selection process for a user who has output a game request every time a game request is received is specified as the selection condition. 6. The network game system according to claim 5, wherein 7. The method according to claim 5, wherein the player selection means of the server device specifies, as the selection condition, that a player selection process should be performed at a predetermined time. The network game system as described. 8. The player selection means of the server device, when the number of users waiting for the game exceeds a predetermined number, the player selection processing is to perform the player selection processing is specified as the selection condition. 6. The network game system according to claim 5, wherein: 9. The selection condition that the player selection means of the server device should perform a player selection process when the number of received game request requests exceeds a predetermined number. The network game system according to claim 5, wherein: 10. The network game system according to claim 1, wherein said player selection means of said server device specifies a condition relating to a selection range of a game partner as said selection condition. 11. The selection condition is such that the player selection means of the server device should determine the selection range of the opponent in accordance with the rate of increase / decrease of the score indicating the strength of the player. The network game system according to claim 10, wherein: 12. The selection condition that the player selection means of the server device should change a selection range of a game partner according to a game waiting time of a user waiting for the game is specified as the selection condition. The network game system according to claim 10, wherein: 13. The game player selecting means of the server device, for a user for whom no game partner was found by the game selection process, expands the selection range of the game partner and performs the game selection process again. 11. The network game system according to claim 10, wherein the designation is specified as the selection condition. 14. The server device further includes a spare player information storage unit in which a spare player candidate is registered, wherein the player selection unit is configured to store the user information storage unit within a predetermined time. 2. The network game system according to claim 1, wherein, for a user who cannot select an opponent from among the above, an opponent is selected from among the opponent candidates in the preliminary player storage means. 15. The server device further comprising strength evaluation means for changing the strength of the user in the user storage means according to the game result when receiving the game result information. The network game system according to claim 1, wherein 16. The user information holding means of the server device holds stage information of each user, and the player selection means performs player selection processing between users at the same stage. 2. The network game system according to claim 1, further comprising stage management means for updating a player's stage according to the result of the game. 17. A network game server device for managing information of a user playing a game via a communication network, wherein: a user information storage means for storing information of a plurality of users; A game request response means for distinguishing a user who has transmitted the game request as a game wait, and a combination of games between users distinguished as a game wait according to a selection condition specified in advance so as to be a more suitable combination. A server device comprising: a player selecting means for determining the game device. 18. A computer-readable recording medium in which a player selection program for causing a computer to select a game partner of a user who wants to play a game via a communication network is recorded. User information storage means for storing the information of the game request, game request response means for distinguishing the user who has transmitted the game request as a game waiting, a selection condition specified in advance to be a more suitable combination A computer-readable recording medium storing a player selection program, which causes a computer to function as a player selection means for determining a combination of games between users identified as waiting for a game in accordance with the following.