JP4007397B2 - Server device, network game system, computer-readable recording medium storing player selection program, and player selection method - Google Patents

Description

  The present invention relates to a network game system for performing indoor games such as shogi, go, chess, othello, mahjong, and video games, a network game server device, a computer-readable recording medium storing a player selection program, and a player More particularly, the present invention relates to a network game system, a network game server device, a computer-readable recording medium in which a player selection program is recorded, and a player selection method for selecting a player from an unspecified number of participants.

  In general, indoor games such as shogi, go, chess, othello, and competitive video games are played by players at the same time and at the same place. However, with recent advances in information and communication technology, a tool has been developed that allows computers to be connected to each other via a communication line so that players can play remotely. This makes it possible to play games while at home. However, in this case, since a person who wants to play is in an individual place, it is difficult to select the other party.

  Therefore, in order to make it easier to use, a player display system for registering personal information that can be played and displaying the content on the screen of the terminal device of the player who wants to play has been considered (Japanese Patent Laid-Open No. 7-95321). ). If this system is used, the game candidate can specify a game opponent by selecting an arbitrary game player on the screen, and can play with the specified game opponent. The invention disclosed in the above publication uses a telephone network, but functions similar to the above system are realized by listing users on the Internet using a homepage.

However, in such a player display system, the user himself / herself has to find a partner who is suitable for himself and keep in touch with himself / herself. This is difficult in the following points.
1) The opponent you want to play may not want to play.
2) The opponent you want to play with may be unable to play immediately while playing.
3) It is necessary to monitor until the opponent's game to be played ends.
4) Until the other party can be selected, it is necessary to perform work other than the original purpose game, and it takes time.

  In view of this, a player selection system is also considered in which a host computer is used to automatically select a partner and, when found, notifies the requesting user when it is found. In this system, a user who desires to play sends a game request to the host. At this time, when a player who does not designate a specific opponent is desired, the strength of the opponent is designated.

On the host side, a person who meets the desired condition is selected as the opponent. In other words, a person having the designated strength is selected as the opponent. Then, the other party's information is notified to both players. Here, if the opponent does not return a signal indicating that the player is OK, another opponent is searched. (For example, see Patent Document 1)
Thereby, the person of the designated strength is automatically selected from those who can play. As a result, it is convenient for the user to save the trouble of selecting the opponent.
Japanese Patent Publication No. 7-63546

  However, in the player selection system described in Japanese Examined Patent Publication No. 7-63546, the user designates the strength of the opponent, so that there is a problem that if there is no person with the designated strength, the player enters a standby state. Still remains.

  Moreover, since each user designates the strength of the opponent, the opponent is not selected unless both designations match. For example, it is assumed that a person with strength “5” designates a person with strength “6” as an opponent. At this time, even if a person with strength “6” is in a standby state, if the person wishes to play against a person with strength “7”, these persons are selected as opponents. There is nothing. In this way, it is natural psychology that wants to play with a partner whose level is slightly higher than that of himself. Therefore, there may be a case where the opponent is not selected indefinitely.

  The present invention has been made in view of the above point, a server device, a network game system, and a game in which a user saves time and effort to select a game partner himself / herself and automatically automatically selects an optimum game partner. It is an object of the present invention to provide a computer-readable recording medium in which a player selection program is recorded and a player selection method.

In the present invention, in order to solve the above problems, in the server device to perform the game of an opposite station to multiple participants over a communication network, is set with the identification number to each stage of the multiple, belongs to one of the stages When a game request is received from user information storage means for storing stage information indicating the identification number of the stage to which each user belongs in association with identification information of a plurality of users, and a client device of a user who wishes to play A game request registration unit for registering status information indicating waiting for a game in association with identification information of a user who has transmitted the game request in the user information storage unit, and a use in which status information for waiting for a game is registered interest to select a plurality of users belonging to the same stage from the user information storage unit, determines the remote station by the selected user, the remote station decides among persons Who notifies the identification information of the user to be the opponent for each client device, remote station's selection means for updating the user information users each status information the remote station decides in the storage means during remote station And, when receiving the game result from the client device of the user who played , the stage management for updating the stage information of the winning user in the user information storage means to the identification number of the stage to which the winning user belongs And a server device.

According to this game device, when the game request is received, the user who has transmitted the game request is registered by the game request registration means. Next, by the player selection means, a combination to be selected from the users belonging to the same stage among the registered users is selected from the user information storage means, and the game by the selected user is selected for each stage. It is determined. When the game result is received, the stage management means changes the stage information of the winning user in the user information storage means to the stage to which the winning user belongs .

  As described above, since the combination of the games is determined to be optimal according to the conditions specified in advance in the server device, the user automatically selects the most suitable game partner without selecting the game partner himself. Can be selected reliably.

In the network game system of the present invention, in the server device, the opponent is not selected indefinitely by selecting the game between users at the same stage . In addition, it is not necessary to set time in advance, and each user can connect to the server at a desired time and execute the remaining game.

Hereinafter, embodiments of the present invention will be described with reference to the drawings.
FIG. 1 is a principle configuration diagram of a related technique of the present invention. The network game system includes a server device 10 and a client device 20. The server device 10 and the client device 20 are connected via a network 31.

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

  When receiving the game request from the client device 20, the player selection unit 12 distinguishes the user who has transmitted the game request as waiting for a game. Then, when a pre-designated player selection process start condition is satisfied, a combination of the games identified as waiting for the game is determined according to the pre-designated condition so that a more suitable combination is obtained. .

  The game partner notification means 13 extracts the information of the user whose game partner is determined by the player selection means 12 from the user information storage means 11, and extracts the extracted information and the game identifier from the client device 20 of the game partner. Notify against.

  The game management means 14 relays the progress of the game between the players selected by the player selection means 12. Specifically, the client device 20 of one player is notified of the pointer sent from the client device 20 of one player. Here, each game is distinguished by a game identifier.

  The client device 20 includes a game request unit 21 and a game unit 22. The game request means 21 outputs a game request to the server device 10 and receives player information regarding the game partner from the server device 10. The game means 22 uses the game identifier to play a game with the game opponent specified by the player information via the communication network.

  In such a network game system, a user who uses the client device 20 first inputs an instruction to play. 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 unit 12 waits for the user who has transmitted the game request. When the player selection processing start condition specified in advance is satisfied, the player selection means 12 determines the combination of the users who are waiting for the game according to the predetermined selection conditions. . When the combination is determined, the game partner notification means 13 responds to the client device 20 of each party with the player information (including the game identifier) of the game partner. The responded player information is received by the game request means 21 of the client device 20. The user of the client device 20 transmits a pointer together with the game identifier received by the game request means 21 to play the network game using the game means 23.

By the way, the selection condition predetermined for the player selection processing means means one or a combination of the following conditions.
1) Every time a request for a game request is received, a player selection process is performed for that requester. At this time, a user waiting for a game with a long waiting time may be preferentially selected.
2) When the time specified in advance is reached, the player selection process is performed.
3) If the number of users waiting for a game exceeds the number specified in advance, a player selection process is performed.
4) When the number of received game request requests exceeds a predetermined number, player selection processing 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 in the score indicating the strength of the player.
7) The selection range of the opponent is changed according to the waiting time of the user waiting for the game.

  In this way, the selection is made based on the conditions specified in advance so that the server device has a more suitable combination without being based on the specified conditions from the user (for example, specifying the strength of the opponent). This eliminates the fact that the opponent is not selected indefinitely. In addition, the possibility of finding the best partner is increased.

Embodiments embodying the present invention will be described below.
FIG. 2 is a schematic configuration diagram of the entire network game system according to the first related technique of the present invention.

  The network game system of the present invention can be divided into a server device 100 and client devices 200, 200a to 200f. These are connected by a network 40 such as a normal public network or a private network. Although the type of the network 40 is not particularly defined, the following description will be based on the Internet in view of its popularity and ease of use.

  Normally, one server device 100 may be provided, but a plurality of servers may be installed for each subsystem device or for each divided user database (DB) in consideration of processing capability. There are as many client devices 200, 200a to 200f as the number of connected users. The user interfaces of the client devices 200, 200a to 200f can be realized by a web browser. Various accesses to the server apparatus 100 are made possible by browsing a home page in the server apparatus 100 with a web browser and operating on the home page.

  Communication between the server and client uses HTTP (Hyper Text Transfer Protocol) running on TCP / IP (Transmission Control Protocol / Internet Protocol) as the base protocol, and the application protocol specified in this system is placed on top. realizable. Of course, it is possible to use a protocol other than TCP / IP, for example, OSI (Open System Interconnection).

  There are two possible methods for playing between client devices. One is a method of directly communicating between the client devices to be played, and the other is a method of playing via the server device. Either method can be played, but in this embodiment, the latter method is adopted, and the game is played via the server device.

  Table 1 shows application protocols defined in this system.

この表には、本実施の形態を実現するために必要な構成（基本構成）で使用するプロトコルが示されており、それは「対局要求」、「対局者選択通知」、「指し手発信」、「指し手通知」の４つである。「対局要求」と「対局者選択通知」とは、必要なパラメタ情報を含めて、クライアント装置２００，２００ａ〜２００ｆからサーバ装置１００に送られ、その要求にサーバ装置１００が応答する。

This table shows the protocol used in the configuration (basic configuration) necessary to realize the present embodiment, which is “game request”, “player selection notification”, “pointer call”, “ There are four types of notifications. The “game request” and “player selection notification” including necessary parameter information are sent from the client devices 200, 200a to 200f to the server device 100, and the server device 100 responds to the request.

  The game request is activated by clicking a predetermined button on the home page when the user desires to play, and is issued to the server device 100. As parameter information, a user identifier N, a password P, and an IP address A are sent to the server side. Of course, the password P may be encrypted by a predetermined encryption method. Receiving the game request, the server device 100 authenticates the request, and if it is a valid identifier / password pair, it is determined as a registered valid user. If it is a legitimate user, the user is registered to wait for a game, and a player automatic selection process is performed under predetermined conditions.

  The server device 100 issues the player selection notification to the client devices 200, 200a to 200f. As the parameter information, the opponent's information Zm selected by the player automatic selection processing, the opponent's strength Rm, and the player identifier B for managing the player in the server device 100 or the opponent's IP address Am are notified. To do. Here, it is not necessary to notify the user of the IP address Am as the notification parameter when the server device 100 mediates the game. Conversely, when the server does not perform mediation, the game identifier B is unnecessary.

  Pointer transmission is issued to the server apparatus 100 by the client apparatuses 200 and 200a to 200f. The parameter information includes a user identifier N, a game pointer C designated by the user, and a game identifier B.

The notification of pointing is issued by the server apparatus 100 to the client apparatuses 200 and 200a to 200f. The parameter information of the pointer notification is the same as that of the pointer transmission.
FIG. 3 is a diagram illustrating a configuration in the server apparatus. A network OS (Operating System) 110 is a device on which TCP / IP and the protocols shown in Table 1 operate. Thereby, communication with the client apparatuses 200 and 200a to 200f can be realized. The functions of the network OS 110 are usually implemented by firmware or software. Of course, it is assumed that a network interface (I / F) card that transmits and receives 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 system. This can be realized by comparing (CP) the user identifier Ni and password Pi sent as request protocol parameters from the client devices 200, 200a to 200f with the data in the user DB 130. However, this function can be used for other authentication services such as X. An authentication service using 500 (International Recommendation on Directories defined by ITU-T (International Telecommunication Union-Telecommunication Sector)) may be used. If the user is not an authorized user, the authentication unit 120 returns an error message (Error) to the client devices 200 and 200a to 200. If it is a legitimate user, the request is transmitted to an appropriate processing function unit by the received request protocol.

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

識別子Ｎは、利用者を唯一識別する符号である。これは、利用者登録時にシステムが自動的に割り振るようにしてもよいし、利用者が決めるようなしくみにしてもよい。名前Ｚ１は、利用者の本名である。住所Ｚ２は、利用者が実際に住んでいる場所を示す。ただし、Ｚ２はオプションであるので、なくてもよい。パスワードＰは、認証の時に必要なデータであり、利用者が付与する。もちろんパスワード変更は後からでも可能である。顔写真Ｚ３は、利用者の写真イメージである。このＺ３もオプションであるので、なくてもよい。アドレスＡは、利用者が使用しているクライアント装置のＩＰアドレスである。通常、インターネットでは、ＩＰアドレスはインターネットアクセスの毎に変わる場合が多い。そのため、このフィールドは利用者が本システムにアクセスするたびに、書き換わる可能性がある。強さＲは、利用者のそのゲームの強さを示す点数である。利用者登録時の申請がベースになっている。状態Ｓは、システムで使用する状態変数であり、０あるいは１の値をとる。それぞれ、０は「対局待ちでない」ことを、１は「対局待ちである」ことを意味している。対局要求時刻Ｗは、利用者が、対局要求をサーバ装置に送った時刻である。これにより、その利用者がどのくらい待っているかの時間がわかる。対局識別子Ｂは、利用者が対局する、あるいは、現在対局している対局の識別子であり、サーバが対局を中継する場合に用いる。この識別子を使用することで、一人の利用者が同時に複数の相手と対局することも可能であり、かつ他の利用者が所望の対局を観戦することも可能となる。対局者Ｍは、利用者が、現在対局している、あるいは、次に対局予定の相手の識別子である。対局者履歴Ｌは、ある過去の一定期間あるいは一定対局数の間に、対局した相手の識別子が入る。

The identifier N is a code that uniquely identifies the 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 real name of the user. The address Z2 indicates a place where the user actually lives. However, since Z2 is an option, it is not necessary. The password P is data necessary for authentication and is assigned by the user. Of course, you can change your password later. The face photograph Z3 is a photograph image of the user. Since Z3 is also an option, it may not be necessary. Address A is the IP address of the client device used by the user. Usually, on the Internet, the IP address often changes every time the Internet is accessed. Therefore, this field may be rewritten every time the user accesses the system. The strength R is a score indicating the strength of the user's game. 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 when the user sends the game request to the server device. This tells you how long the user is waiting. The game identifier B is an identifier of a game that the user plays or is currently playing, and is used when the server relays the game. By using this identifier, it is possible for one user to play with a plurality of opponents at the same time, and other users can watch a desired game. The player M is an identifier of a partner that the user is currently playing or is scheduled to play next. In the player history L, the identifier of the opponent who entered 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 each time a game request is sent from the user. When the automatic selection processing unit 141 is activated under a predetermined condition, the user DB is referred to, information on all the users waiting for the game S = 1 is read, and a player is selected by a predetermined algorithm. As a result, the identifier of the opponent is registered in the player M and the player 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. Furthermore, the game identification number for the determined game is set and registered in the game identifier B of each player.

  At the same time, the player selection result is notified to the user who has output the game request. This notification means that the opponent's information Zm and its strength Rm and the identifier B of the player to be played are sent to each client device.

  In the selection condition holding unit 150, a selection start condition for starting the automatic selection processing unit 141 is set in advance. In this related technique, the following four selection start conditions can be set.

First condition: Each time a request for a game request is received, a player selection process is performed for that requester.
Second condition: When a time designated in advance is reached, a player selection process is performed.

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

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

FIG. 4 is a diagram illustrating the configuration of the client device.
The user interface 210 is responsible for information input from the user and information display to the user. Here, the details of the user interface will be described by taking the case of applying to a shogi game as an example.

  FIG. 5 is a diagram illustrating an example of the user interface 210. The user interface 210 is provided with a game request button 211, and when the game request button 211 is clicked with the mouse, a game request instruction is transmitted to the game request unit 220. Below the game request button 211 is a message display unit 212. The message display unit 212 displays various messages to be notified to the user. For example, when an error message is returned as a response from the server apparatus 100, the error message is displayed. If it is a legitimate user, that fact may be displayed. In the center of the screen, there is a shogi board display section 213 that displays the state of the game. There are player display units 214 and 215 above and below the shogi board display unit 213. The upper player display section 214 displays the name and strength of the opponent. On the other hand, the lower player display section 215 displays the user's own name and strength. The player display unit 214 can also display the other party's IP address. In this case, it is also possible to establish a communication state with the opponent on the basis of the displayed address and to play. On the right side of the shogi board display portion 213, there are holding piece display portions 216 and 217, which display the holding pieces of the opponent and own holding pieces, respectively.

  Returning to FIG. 4, when receiving a game request from the user interface 210, the game request unit 220 adds a user identifier Ni, a password Pi, and an address Ai as a game request protocol, and sends it to the server device 100. If an error message is returned as a response, it is displayed on the user interface 210. Further, when the player selection is completed in the server device 100 and the information on the other party is notified, it is displayed on the user interface 210. The game identifier B sent simultaneously with the game selection notification is transmitted to the game unit 230 and becomes game identification information when it is sent to the server device 100.

  The game unit 230 sends the pointer transmitted from the user interface 210 to the server device 100 together with the game identifier transmitted from the game request unit 220. In addition, after waiting for pointing information from the opponent, the game identifier B sent via the server and the sent pointer are displayed on the user interface 210.

Similar to the network OS 110 of the server apparatus 100, the network OS 240 is an apparatus that operates TCP / IP, HTTP, and each protocol of this system.
In the network game system configured as described above, the following processing is performed. In order to explain the operation of this system, flowcharts in the server device 100 and the client device 200 are shown in FIGS. In the description using the flowchart, description will be made along the step numbers in the drawing.

  First, processing performed by the server apparatus 100 will be described. In the server apparatus 100 that has received the player request from the client apparatus 200, the network OS 110 and the authentication unit 120 perform reception processing.

FIG. 6 is a flowchart showing the reception process of the server device.
[S1] The network OS 110 constantly determines whether or not any signal is received. If signal reception has occurred, the process proceeds to step S2. If signal reception has not occurred, 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 checking a pair of a user identifier and a password in the user DB 130. If it is an unauthorized user, the process proceeds to step S3, and if it is an authorized 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 an error. Then, it progresses to step S1 and prepares 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 player selection processing. Then, it progresses to step S1 and prepares for the next reception. Details of this processing will be described later.
[S6] The game management unit 160 performs game management processing. Then, it progresses to step S1 and prepares for the next reception. Details of this processing will be described later.

  Here, when relaying a player's hand, it is not a single information communication, but a plurality of information exchanges. Therefore, in normal TCP / IP, for example, not a telegram but a telephone call between the client device 200 and the server device 100. Such a logical connection is established, and information is exchanged on the connection. If this is used, the authentication process may be omitted when exchanging information with the game.

Here, the details of the selection process will be described. Note that 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 is generated.
[S11] It is determined whether the first condition is included in the selection start condition. If the first condition is included, the process proceeds to step S12. If not included, the process proceeds to step S13.
[S12] When the first condition is set (the case where only the first condition is set or the combination of the condition includes the first condition), the processing content is changed to “ As the “first selection process”, the automatic selection processing unit 141 is activated. Details of the first selection process are shown in FIG.
[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 wait for game (S ← 1), and the current time is set to the game request time W.

Note that packetization when a response is made 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 is generated under the first selection condition.
[S21] User information waiting for a game is read from the user DB 130.
[S22] The "selection routine a" is called to search for the opponent of the user who requested the game. From the selection routine a, information on whether or not a partner has been found is returned by a variable p. When the partner is found, the value of the variable p is true, and when the partner is not found, the value of the variable p is false.
[S23] Based on the value of the variable p, it is determined whether or not an opponent is found. If the opponent is found, the process proceeds to step S24. If not found, the process proceeds to step S26.
[S24] When the opponent is found (if the variable p in the selection routine a is true), the client identifier B and the opponent information are responded and notified to both client devices (here, the response) It is a reply to the request, and the notification is to notify the waiting user as an event).
[S25] The user DBs 130 of both players who play are updated. That is, the state S is set to 0.
[S26] On the other hand, when the partner is not found, a standby response is sent to the client apparatus 200 that has output the game request.
[S27] At the same time, the state S in the user DB 130 of this user is set to 1.

The above is the processing performed with the input of the game request from the client device 200 as a trigger.
On the other hand, the player selection unit 140 continuously performs the following second selection process from the time when any of the second selection start condition to the fourth selection start condition described above is set in the selection condition holding unit 150. To do.

FIG. 9 is a flowchart of the second selection process. This is a process that is always moving as long as any one of the second to fourth selection start conditions is set.
[S31] It is determined whether any one of the set conditions in the second to fourth selection start conditions is satisfied. If one of the selection start conditions is satisfied, the process proceeds to step S32, and if not satisfied, this step is repeated.
[S32] When at least one of the selection start conditions is satisfied, user information waiting for a game is read from the user DB.
[S33] The “selection routine b” is called to combine the games. Details of this processing are shown in FIG.
[S34] The client identifier 200 and the opponent information Zm are notified to the client device 200 of the user who has completed selection of the opponent.
[S35] The status S of these users in the user DB 130 is set to 1.

The above process is repeated.
In this way, the player selection process is started when any one of the selection start conditions is satisfied, and the game identifier B and the game partner information Zm are notified to the user determined by the player.

Further, when the pointing information is sent from the client device 200 to the server device 100, the following game management processing is performed.
FIG. 10 is a flowchart of the game management process. This is processing performed by the game management unit 160 when the pointer C is sent from the client device 200.
[S41] Using the game identifier B sent simultaneously with the pointer C as a key, the corresponding DB address is searched from the user DB 130.
[S42] The pointer C sent from the client device 200 is transmitted together with the game identifier B to the client device corresponding to the address.

The above is the overall processing of the server apparatus 100. Details of the selection routine will be described below.
There are several possible selection routines. Here, the example by the selection method by the simplest comparison is shown. Note that 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 reference for a difference in strength that can be selected as a player. If the difference in strength between both users falls within this range, the reference value Rx is selected as a player. . The variable p is a logical variable indicating whether or not the opponent is found, and is “true” when the opponent is found, and “false” when the opponent is not found.

  The variables used in this process will be described using the table in Table 3.

表３のテーブルにおいて、項目番号は「１」から振られた番号であり、対局待ちの利用者数Ｕまで存在する。以下この項目番号をサフィックスとして使用する。つまり項目番号「２」の利用者識別子は「Ｎ２」である。識別子Ｎ、強さＲ、対局者Ｍ、対局者履歴Ｌは利用者ＤＢ１３０で使用しているものと同じ意味である。なお、処理ルーチンａを実行している段階では、対局要求を出力した利用者の状態Ｓは０のままである。また、Ｎｉ、Ｒｉ、Ｍｉ、Ｌｉは、対局要求を出力した利用者であり、ここでは固定である。
［Ｓ５２］項目番号「ｋ」に０をセットする。
［Ｓ５３］項目番号「ｋ」の値に１を加算する。
［Ｓ５４］識別子「Ｎｋ」が、対局要求を出力した利用者の対局者履歴「Ｌｉ」に含まれていないことを確認する。含まれていればステップＳ５３に進み、含まれていなければステップＳ５５に進む。
［Ｓ５５］対局要求を出力した利用者の強さ「Ｒｉ」と、識別子「Ｎｋ」の利用者の強さ「Ｒｋ」との差が、基準値「Ｒｘ」より小さいか否かを判断する。基準値「Ｒｘ」より小さければステップＳ５６に進み、そうでなければステップＳ５７に進む。
［Ｓ５６］識別子「Ｎｋ」の利用者を、対局要求を出力した利用者の対局相手として決定し、利用者ＤＢ１３０の内容を更新する。具体的には、対局要求を出力した利用者（識別子「Ｎｉ」）の対局者「Ｍｉ」に項目番号「ｋ」の識別子「Ｎｋ」を登録すると共に、項目番号「ｋ」の対局者「Ｍｋ」に項目番号「ｉ」の識別子「Ｎｉ」を登録する。さらに、項目番号「ｉ」の対局者履歴「Ｌｉ」に項目番号「ｋ」の識別子「Ｎｋ」を登録すると共に、項目番号「ｋ」の対局者履歴「Ｌｋ」に項目番号「ｉ」の識別子「Ｎｉ」を登録する。また、対局者が見つかったため、論理変数「ｐ」を「true」に設定する。これらの設定が完了したら、処理を終了する。
［Ｓ５７］項目番号「ｋ」が、対局待ちの利用者数Ｕ以上になったか否かを判断する。Ｕ以上であればステップＳ５８に進み、そうでなければステップＳ５３に進む。
［Ｓ５８］対局相手が見つからなかったため、論理変数「ｐ」を「false 」に設定し、処理を終了する。

In the table of Table 3, the item number is a number assigned from “1”, and there are up to the number U of users waiting for a game. Hereinafter, this item number is used as a suffix. That is, the user identifier of the item number “2” is “N2”. The identifier N, strength R, player M, and 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 0. Ni, Ri, Mi, and Li are users who output a game request, and are fixed here.
[S52] 0 is set to the item number “k”.
[S53] Add 1 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 it is not included, the process proceeds to step S55.
[S55] It is determined whether the difference between the strength “Ri” of the user who has output the game request and the strength “Rk” of the user with the identifier “Nk” is smaller than the reference value “Rx”. If it is smaller than the reference value “Rx”, the process proceeds to step S56; otherwise, 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 contents of the user DB 130 are updated. 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. ”Is registered with the identifier“ Ni ”of the item number“ 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 registered in the player history “Lk” of the item number “k”. Register “Ni”. Since the 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” is equal to or greater than the number U of users waiting for the game. If it is U or more, the process proceeds to step S58, and if not, the process proceeds to step S53.
[S58] Since the opponent is not 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 within a predetermined period or 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, the variables shown in Table 3 are used.
[S61] The sets S and P are initialized (empty set), and the reference value Rx is initialized (set). A set S is a set of item numbers for which processing has been completed, and a 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 0.
[S63] 1 is added to the value of "i".
[S64] It is determined whether “i” is included in the set S. If it 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 it is 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 0.
[S66] 1 is added to the value of "k".
[S67] It is determined whether or not the user of the item number “k” satisfies the basic condition as the opponent of the game. As a basic condition, first, oneself is excluded (i ≠ k). The item numbers already processed (those in the set S) and users who have already played within a predetermined period or 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 with the item number “i” and the user with the item number “k” is greater than Rx (| Ri−Rk |> Rx). If the difference in strength is less than or equal to Rx, the process proceeds to step S69, and if the difference in intensity is greater 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 processed. Also, 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”. ". 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 registered 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 or not the item number “k” being compared is equal to or greater than the maximum value “U” of item numbers indicating users waiting to play. If “k” is equal to or greater than “U”, the process proceeds to step S71; otherwise, the process returns to step S66.
[S71] The item number “i” is included in the set P. That is, an appropriate player of the user having the item number “i” has not been found.
[S72] It is determined whether the selected item number “i” is greater than or equal to the maximum item number “U”. If “i” is equal to or greater than “U”, the process is terminated; otherwise, the process returns to step S63.

  As a result, a user whose strength difference is within Rx is selected for each user from item numbers “1” to “U”. It is also possible to change the order of the users as described above and select a combination having the smallest average of | Ri−Rk |. Further, Rx may be increased so that the set P becomes empty.

The above is the process performed by the server apparatus 100. Next, the operation in the client device will be described.
First, the processing function of the user interface will be described.

FIG. 13 is a flowchart of processing 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, the items that can be input by the user include one game desire button 211 and an operation panel of the pointing device (pointing to the area of the shogi board display unit 213 and the holding piece display units 216 and 217). These are monitored, and requests from the game request unit 220 and the game unit 230 are 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 is clicked with the mouse and a game request is input, the process proceeds to step S104. If the pointing operation panel is operated, and the hand is input, the process proceeds to step S105.
[S104] The game request unit 220 is instructed to issue a game request. As a result, the game request processing is started in the game request unit 220. After this process, the process proceeds to step S101.
[S105] The move is transmitted to the game unit 230, and the process proceeds to step S101.
[S106] It is determined whether the input is from the game request unit 220 or not. If the input is from the game request unit 220, 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 a game partner input from the game request unit 220 is displayed. In the case of an opponent, the opponent information Zn and the opponent strength Rn are displayed on the player display unit 214 (shown in FIG. 5). Further, in the case of a display request for waiting or a display request indicating that an error has occurred, the content is displayed on the message display unit 212 (shown in FIG. 5). Then, it progresses to step S101.
[S108] The arrangement of the pieces on the operation panel of the pointer is updated according to the pointer input from the game unit 230, and the process proceeds to step S101.

Next, processing executed by the game request unit will be described.
FIG. 14 is a flowchart of the game request process. This process is a process executed by the game request unit 220 when a game request is output from the user interface 210 to the game request unit 220.
[S111] Using the game request protocol, the user identifier Ni including the password Pi and the address Ai is transmitted to the server apparatus 100. Here, since the address is set in advance in the client device 200, it can be automatically detected and put on the protocol without being input by the user.
[S112] It is determined whether or not there is a response to the game request. If there is a response from the server apparatus 100 to the game request, the process proceeds to step S113, and if there is no response, the process of step S112 is repeated.
[S113] It is determined whether the response is returned normally without 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 is 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 opponent information Zn and the opponent strength Rn) is transmitted to the user interface 210 for display, and the game identifier B is transmitted to the game unit 230, and the process is terminated.
[S116] Information to the effect of waiting is transmitted to the user interface 210 for display, 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, processing executed by the game unit 230 will be described.
FIG. 15 is a diagram illustrating a flowchart of the game process. This is a process that is always executed in the game unit 230 when the game is started.
[S121] It is determined whether or not there is an input from the user interface 210 or the server device 100. If there is an input, the process proceeds to step S122. If there is no input, this process is repeated to wait until there is an input.
[S122] It is determined whether the input is from the user interface 210 or the server apparatus 100. If the input is from the user interface 210, the process proceeds to step S123. If the input is from the server apparatus 100, the process proceeds to step S124.
[S123] If the input is from the user interface 210, the game identifier B, the pointer C, and the user identifier Ni are transmitted to the server apparatus 100.
[S124] If the input is from the server device 100, the received hand 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 device 100 can automatically determine the user of the user who wants to play, and can notify the client device used by the user of information related to the player. As a result, the user himself / herself does not need to find an opponent.

  In addition, since the server apparatus 100 performs the player selection process when the selection start condition is satisfied, if an appropriate selection start condition is set in advance, the selection range of the opponent is expanded and the user constantly selects. No need to monitor for results

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

Applications include entry / exit, strength evaluation, and various information displays, as well as the following extended functions that enhance automatic selection.
1) A fifth selection start condition, for a user whose player has not been determined within a predetermined time, a player is selected from another player DB (hereinafter referred to as a first extended function). ).
2) A user waiting for a game with a long waiting time is preferentially selected (hereinafter referred to as a second extended function).
3) The selection range of the opponent is determined by the differential value of the increase / decrease in the score indicating the strength of the player (hereinafter referred to as the third extended function).
4) The selection range of the opponent is changed according to the waiting time of the user waiting for the game (hereinafter referred to as a fourth extended function).

  Here, the server-client protocol used in the second related technology is shown in Table 4.

この関連技術ではプロトコルを、「基本」と「応用」とに分類している。第１の関連技術でも使用したプロトコルが「基本」であり、本関連技術を実現するために新たに規定したプロトコルが「応用」である。応用のプロトコルは、基本以外に４種類のプロトコルがある。

In this related technology, protocols are classified into “basic” and “application”. The protocol used in the first related technology is “basic”, and the protocol newly defined for realizing this related technology is “application”. There are four types of applied protocols other than the basic protocol.

  “Admission” is a protocol that the user first issues to the server device to enter the system. As a result, the server device returns a service menu provided by this system. As a result, only authorized users can access the services of this system.

  “Exit” is a protocol for the user to leave the system. In combination with the admission protocol, the security of the system can be increased by allowing the user to access only during the time period from admission to exit.

“End” is a protocol indicating that the game has ended. As a result, the result of the game can be immediately used for calculating the player's strength on the server side.
“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 is a diagram showing a configuration of a server device according to the second related technology of the present invention. The server device 300 is connected to the client device 400 via a network.

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

  The visitor reception unit 330 receives the entrance protocol from the client device 400, initializes the state of the requested user Ni (S = 0), and returns the service menu of this system to the client device 400. In the basic configuration shown in the first related technique, even an unauthorized user can only access, but by using this function, only authorized users are allowed to access. As a result, it is possible to reduce the load on the server side.

The exit reception part 340 is used in pairs with the attendant reception part 330. When an exit request is received, the state of the user is initialized (S = 0), and the service menu is closed.
The player selection unit 350 includes a function of finding a player using the spare player DB 362 for a user whose opponent is not found in the user DB 361 in addition to the basic configuration function.

The user DB 361 stores user data registered in advance as in the first related technology. The contents of the data are as shown in Table 2.
The spare player DB 362 is a DB of a user who is registered in advance and is waiting in preparation for a player re-request. The contents of the data stored in the backup player DB 362 are the same as the user DB 361.

  When the game is completed, the strength evaluation unit 370 calculates the strength of each player according to a predetermined rule from the result of the game and the strength between the players, and uses each of the usages that the user DB 361 has played. Rewrite the strength of the person. First, the player Mi of the user Ni who issued the end is obtained from the user DB 361, and the respective strengths of the user and the player are read from the user DB 361. Based on these, the strength is recalculated and written in the user DB 361.

As an example of the rule for calculating the strength, there is a rating method used as a strength judgment method in the following shogi. In this rating system, a goal is obtained by the following formula, and added or subtracted to the original score of the winner or loser.
(1) If the higher score wins,
Goal loss = 16-(point difference x 4%)
(2) If the lower score wins,
Goal loss = 16 + (point difference x 4%)
In the case where the higher score wins, if the difference in points exceeds 400 points, the score becomes negative, but in that case, the strength is not changed. However, in the automatic selection process of the player, if the difference in strength is equal to or greater than a certain threshold, it is not selected as the opponent, so if the threshold is set to 400 or less, the score difference exceeds 400 points There is nothing.

  The display information providing unit 380 has a function of responding to the client device 400 with information in the user DB 361. That is, it receives a display request item from the client device 400 and responds to the corresponding item. However, the password cannot be responded.

  In addition to the selection start condition (first condition to fourth condition) shown in the first related technique, the selection condition holding unit 390 has a fifth selection start condition that is the first extended function of the related technique. It can be set.

The game management unit 300a has the same function as the basic configuration (game management unit 160 in FIG. 3).
Next, a configuration of a client device corresponding to the server device 300 will be described.
FIG. 17 is a diagram illustrating a configuration of a client device according to the second related technology.

The network OS 410 can transmit and receive all the protocols shown in Table 4 above.
The user interface 420 performs information input from the user and information display to the user. This user interface 420 is an extension of the function of the user interface in the first related technology.

  FIG. 18 is a diagram illustrating an example of an extended user interface 420. In addition, regarding the game desired button 421, the message display unit 422, the shogi board display unit 423, the player display units 424 and 425, and the holding piece display units 426 and 427 in the figure, the first related technology shown in FIG. It is the same as the component of the same name of the user interface 210.

  As input switches added in this related technology, there are a closing button 420a and a leaving button 420b. The termination button 420a is a button to be clicked when losing is recognized, and an end command is output when this button is clicked. The exit button 420b is a button to be clicked when the use of the service of the server device 300 is terminated, and an exit command is output when the button is clicked.

  As a display function, remaining time display sections 420c and 420d are added. The remaining time display sections 420c and 420d display the remaining amount of time each player has in the game where the time limit is provided.

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

  Returning to FIG. 17, the admission request unit 430 transmits the admission request from the user interface 420 to the server device 300 and displays the response on the user interface 420. The entrance request transmitted to the server apparatus 300 includes the user identifier Ni and the password Pi.

The game request unit 440 basically has the same function as the game request unit 220 (shown in FIG. 4) of the first related technology.
When termination information (indication of losing intention) is transmitted from the user interface 420, the termination request unit 450 transmits it to the server apparatus 300 using a termination protocol. Then, it waits for a response from the server device 300, and when it is processed normally, displays a message indicating that the game has ended on the user interface 420.

Of course, the termination information is also transmitted to the game unit 480 so that it can be recognized by the other party.
The exit request unit 460 performs processing for the user to leave the system. The exit protocol is transmitted to the server apparatus 300, and when a response is received, a process completion message is displayed on the user interface 420.

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

  The image embedding unit 490 is combined with the game unit 480 and the camera 50, and simultaneously transmits its own still image at the moment when the finger is pointed at when transmitting the hand to the opponent. Also, the side receiving the same image displays the still image on the screen together with the pointer. By doing so, the sense of reality of the game can be increased.

  Hereinafter, the operation of this system will be described together with a flowchart of basic functions. Note that flowcharts of characteristic processing functions of the server apparatus 300 and the client apparatus 400 of this system are shown in FIGS.

FIG. 19 is a flowchart showing a reception process in the server device.
[S201] The network OS 310 determines the presence or absence of reception. If various requests are received, the process proceeds to step S202, and if not received, this process is repeated.
[S202] When any reception occurs, the authentication unit 320 authenticates whether it is a valid user. If it is an authorized user, the process proceeds to step S204, and if it is an unauthorized user, the process proceeds to step S203.
[S203] If authentication of the received request fails, the authentication unit 320 notifies the client device 400 of an error message.
[S204] If it is a legitimate user, the authentication unit 320 determines the type of the received request and causes each process to be executed.
[S205] In the case of an admission request, the admission reception unit 330 executes admission reception processing (details are shown in FIG. 20).
[S206] In the case of an end request, the strength evaluation unit 370 executes an end process (details are shown in FIG. 21).
[S207] In the case of an exit request, the exit person accepting unit 340 executes exit processing (details are shown in FIG. 22).
[S208] In the case of a game request, the player selection unit 350 executes a selection process. The details of this processing are the same as the processing of the first related technology shown in FIGS. However, the contents of the process performed in step S22 of the first selection process in FIG. 8 are different (the selection routine a ′ is executed instead of the selection routine a).
[S209] In the case of a move request, the game management unit 300a performs a game process. The details are the same as the processing of the first related technology shown in FIG.
[S210] In the case of a display request, the display information providing unit 380 acquires the requested data from the user DB 361.

  When the processes of step S203 and steps S205 to S210 are completed, the apparatus that performed the respective processes returns the processing result to the requested client apparatus. Note that the actual packetization is performed by the network OS 310. Thereafter, the process returns to step S201 to prepare for the next reception.

FIG. 20 is a flowchart of the admission reception subroutine. This is a process performed by the visitor reception unit 330 when an admission request is generated.
[S221] The state of the requesting user Ni is initialized (S ← 0).
[S222] The service menu of this system is returned to the user Ni. Specifically, the service menu includes a game request and an exit.

FIG. 21 is a flowchart of an end subroutine. This is a process performed by the strength evaluation unit 370 when an end request is generated.
[S231] The strength of the user Ni who requested termination and the strength of the player Mi is 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, the process completion is returned to the user Ni, and this process is terminated.

FIG. 22 is a flowchart of the exit subroutine. This is performed by the leaver accepting unit 340 when an exit request is generated.
[S241] The state of the user who has requested exit is changed (S ← 0).
[S242] A response is given to the user Ni to confirm the exit, 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 process realizing the first extended function is referred to as a “third selection process”.

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 waiting time of the game waiting user has exceeded a predetermined waiting time. If the waiting time has not been exceeded, this step is repeated, and if the waiting time has been exceeded, the process proceeds to step S252.
[S252] The waiting user information is read from the user DB 361, and the information of the standby player is read from the standby player DB 362.
[S253] The selection routine c is read.
[S254] If the other party is determined for the user whose waiting time has been exceeded, the client apparatus is notified of it.
[S255] Finally, the user DB 361 is updated.

In this flowchart, it is assumed that there are always enough standby players registered in the backup player DB 362.
FIG. 24 is a flowchart of a selection routine c called in the third selection process.
[S261] The reference value Rx is initialized (set). Rx is a reference value for the difference in strength.
[S262] 0 is set to the item number “k”. The variable k to be used in this processing is a number assigned from 1 and exists up to the number V of registrants in the standby 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 whose game waiting time has exceeded, and are fixed here.
[S263] Add 1 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, and if it is not included, the process proceeds to step S265.
[S265] Whether or not the difference between the strength “Ri” of the user who has output the game request and the strength “Rk” of the user with the identifier “Nk” is greater than the strength reference value “Rx”. to decide. If it is larger than the reference value “Rx”, the process proceeds to step S267, and if not, 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 contents of the user DB 361 and 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 item number “i” of the player “Mk” of the item number “k” is registered. 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 registered in the player history “Lk” of the item number “k”. Register “Ni”. When these settings are completed, the process ends.
[S267] It is determined whether or not the item number “k” is equal to or greater than the number V of registrants in the standby player DB 362. If it is V or higher, the process proceeds to step S268; otherwise, the process proceeds to step S263.
[S268] α (preset value smaller than Rx) is added to the value of Rx, and the process proceeds to step S262 as a new value of Rx.

  Thus, from the standby player DB 362, a standby player whose strength difference with the user Ni is within Rx is found, and if not found, by gradually increasing the selection range Rx, I always try to find my opponent.

  Next, selection processing including the second extended function to the fourth extended function will be described. This is implemented by calling the selection routine a ′ instead of the selection routine a in step S22 when the first selection process (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 for the difference in strength, and the variable p is a logical variable indicating whether or not the opponent is found. The following Ni, Ri, Mi, and Li are users who output a game request, and are fixed here.
[S272] The selection target table (item numbers 1 to U) is sorted in descending order of waiting time.
[S273] The strength Ri of the user to be selected is corrected based on the recent competition results. 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 selected by changing only in the selection routine a ′.
[S274] 0 is set to the item number “k”.
[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 it is not included, the process proceeds to step S277.
[S277] The strength Rk of the user who is going to be selected is corrected based on the recent competition results. The correction method is the same as that performed for Ri in step S273.
[S278] The difference value reference value Rx is changed according to the length of the waiting time. If Rxi is changed according to the waiting time of Ni and Rxk is changed according to the waiting time of Nk, the smaller one is selected at the time of selection, and this is a reference value for the difference in strength of selection. Let Rx.
[S279] Whether the difference between the strength “Ri” of the user who has output the game request and the strength “Rk” of the user with the identifier “Nk” is smaller than the strength reference value “Rx”. to decide. 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 contents of the user DB 130 are updated. Specifically, the identifier “Nk” of the item number “k” is registered in the player “Mi” of the item number “i” and the item number “i” of the player “Mk” of the item number “k” is registered. 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 registered in the player history “Lk” of the item number “k”. Register “Ni”. Since the player is found, the logical variable “p” is set to “true”. When these settings are completed, the process ends.
[S281] It is determined whether or not the item number “k” is equal to or greater than the number U of users waiting for a game. If it is greater than or equal to U, the process proceeds to step S282; otherwise, the process proceeds to step S275.
[S282] Since the opponent is not found, the logical variable “p” is set to “false”, and the process ends.

Next, the operation in the client device 400 will be described.
FIG. 26 is a flowchart of user input processing at the client. This is a process performed by the user interface 420.
[S301] The presence or absence of input from the user is monitored. If there is an input, the process proceeds to step S302. 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 apparatus that executes the process accordingly.
[S303] In the case of an admission request, the admission request unit 430 performs admission processing (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 (the details are the same as the process of the first related technology shown in FIG. 14).
[S307] In the case of a pointing, the pointing 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 any of the processes in steps S303 to S308 is completed, the process returns to step S301.
FIG. 27 is a flowchart of the entrance subroutine. This process is a process performed by the admission request unit 430.
[S311] Using the admission request protocol, Ni and Pi are transmitted as parameters to the server apparatus 300.
[S312] The server apparatus 300 waits for the response.
[S313] The response result from the server apparatus 300 is displayed.

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

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

  As described above, the system automatically selects the opponent to be played and shows it to each user, so that the user himself / herself does not need to find the opponent. In addition, it is not necessary for the user to constantly monitor whether the selection result has been obtained.

Of course, the user DB contains the user's network address (or a telephone number), so the user does not need to check the contact information of the other party.
Moreover, when selecting, there are the following effects.
1) It will not happen that the opponent is not selected forever.
2) The possibility of finding the best partner increases.
3) The game strength at that time is automatically reflected, and the opponent is also selected accordingly.
4) System entrance and exit systems improve system security, and at the same time, the waiting time for selecting a player can be changed according to the status of access to the system, so you can always start playing with the shortest waiting time. It becomes like this.
5) When playing a game, you can see the still image of the game partner, so the sense of reality of the game increases.

  Next, an embodiment of the present invention will be described. Up to now, the related technology that has been described only selects a user from one selection range (hereinafter referred to as a stage) and plays, but in the embodiment of the present invention, it is possible to have a plurality of stages. It is a thing. This will be described by taking an example of applying this to a tournament battle.

For simplicity, we will have 8 tournament participants. The following situation is assumed.
1) At the start of the tournament, 8 players are registered in the first stage. However, these eight people are not connected to the server at the same time.
2) Consider a case in which only 5 out of 8 people are connected to the server. These five are in the first stage, where they are selected. This selection may be performed automatically as described in the present invention, or the user may select himself / herself from the user list in the first stage.
3) In this way, the game is played, and winning or losing is determined. The winning user then proceeds to the second stage. The losing user may delete the registration from the tournament game as it is, or may move to the 0th stage, which is a lower stage of the first stage, as a loser revival game.
4) In this way, up to four players are played, one person remains in the first stage, and two persons enter the second stage.
5) One person remaining in the first stage waits until another tournament participant connects to the server and joins the first stage, or disconnects the server and waits for the next opportunity.
6) If two people are connected to the server as they are, the two players in the second stage further play, and the winning one goes to the third stage.

  As described above, a tournament battle can be carried out even if all the tournament participants are not connected to the server at the same time. This eliminates the need for negotiations such as prior connection times between participants.

The system configuration with the stage management function added will be described below.
FIG. 30 is a diagram illustrating a configuration of the server device according to the embodiment of this invention. The server device 500 is connected to the client device 600 via a network. The server device 500 includes a network OS 510, an authentication unit 520, a user DB 530, a player selection unit 540, a selection condition holding unit 550, a game management unit 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 similar component of the first related technology shown in FIG. Hereinafter, the added functions will be described.

  In the user DB 530, information related to the stage state of each user is registered. The registered items in the user DB 530 are shown in Table 5 below.

このように、ステージ情報（ＳＴ）が設けられており、その利用者が属しているステージの番号が登録されている。値が「ｎｕｌｌ」の場合は、どのステージにも属していないことを示している。

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

  When receiving a game request, the player selection unit 540 sets the user who issued the request to wait for a game (Si = 1) and reads the stage information (STn) of the user. 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 selection processing. In the case of the tournament battle in the above example, there is usually only one waiting for a game, and since there is always a condition for playing, if there is a user waiting for a game, it is assigned immediately.

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

  The stage management unit 570 receives an 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 example of the tournament battle, 1 is added to the stage information of the winning player (STn = STn + 1), and the losing player is deleted from this tournament battle (STn = null).

  FIG. 31 is a diagram illustrating a configuration of the client device according to the embodiment of this invention. The client device 600 according to the present embodiment includes a user interface 610, a game request unit 620, a network OS 640, a game unit 630, and an end request unit 640. Each component has the same function as that of the similar component of the second related technology shown in FIG.

Hereinafter, processing characteristic of the present embodiment will be described with reference to the flowcharts of FIGS.
FIG. 32 is a flowchart of the server device reception process.
[S401] The network OS 510 constantly determines whether or not any signal is received. If signal reception has occurred, the process proceeds to step S402. If signal reception has not occurred, the process of step S401 is repeated.
[S402] The authentication unit 520 authenticates whether the signal sender is a valid user. If it is an unauthorized user, the process proceeds to step S403, and if it is an authorized user, the process proceeds to step S404.
[S403] If the received signal is from an unauthorized user, the authentication unit 520 notifies the client device 600 that it is an error. Then, it progresses to step S401 and prepares 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 it is an end request, the process proceeds to step S405, if it is a game request, the process proceeds to step S406, and if it is a pointer, the process proceeds to step S407.
[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 game management processing. Thereafter, the process proceeds to step S401 to prepare for the next reception. This process is the same as the process of the first related technique shown in FIG.

FIG. 33 is a flowchart of an 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, the winning user stage information is incremented by 1, and the losing person enters null.
[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] User information waiting for a game in the same stage as the user who issued the game request is read from the user DB 530.
[S422] It is determined whether a partner has been found. If found, the process proceeds to step S423, and if not found, the process proceeds to step S425.
[S423] When a partner is found, the player is introduced to the client device of each user (response and notification of game information).
[S424] The user statuses of both user DBs 530 are updated from waiting for playing to playing (S = 0), and this process ends.
[S425] If no opponent 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.

In this way, it is possible to perform a tournament battle via the network by changing the stage of each user each time the game is completed.
FIG. 35 is an explanatory diagram of the stage of the tournament battle. Eight tournament participants have entered the first stage 51, and five are currently connected to the server device 500. Among them, 2 pairs of 4 players play, and 2 people win and go to the second stage 52. In the second stage, the game is played immediately, and one person has advanced to the third stage 53. After that, I will wait for another to win.

  Traditionally, tournament battles require prior negotiations between users, such as “starts at 22:00”. However, by performing stage management as described above, it is not necessary to set time in advance. Users can connect to the server and run tournament battles at any time.

  As described above, each embodiment performs a game in a server-client form via a server. This can also be done between the client and the client. This reduces the load on the server and improves the communication speed.

In addition, here, a database (DB) is used as a means for information retrieval and accumulation by the user, but this can also 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. However, the present invention is not limited to two players. To select 3 or more games, such as mahjong, select the 3 opponents by repeating the selection routine of the automatic selection process 3 times for one user. It is possible to arrange four members of mahjong.

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

  Further, in the present invention, the designation condition from the user is not taken into account. Of course, the designation condition from the user can be included in the selection condition as the first hope, and by doing so, Further optimization is possible.

  The above processing functions can be realized by a computer. In this case, the processing contents of the functions that the server device and the client device should have are described in a program recorded in a computer-readable recording medium. By executing this program on the computer, the above processing is performed. Realized by computer. Examples of the computer-readable recording medium include a magnetic recording device and a semiconductor memory. When distributing the market, store the program in a portable recording medium such as a CD-ROM (Compact Disk Read Only Memory) or a flexible disk, or store it in a storage device of a computer connected via a network. In addition, it can be transferred to another computer through the network. When executed by a computer, the program is stored in a hard disk device or the like in the computer, loaded into the main memory and executed.

It is a principle block diagram of the related technology of this invention. 1 is an overall schematic configuration diagram of a network game system according to a first related technology of the present invention. It is a figure which shows the structure in a server apparatus. It is a figure which shows the structure of a client apparatus. It is a figure which shows the example of a user interface. It is a flowchart which shows the reception process of a server apparatus. It is a flowchart of a selection subroutine. It is a flowchart of a 1st selection process. It is a flowchart of the 2nd selection processing. It is a flowchart of a game management process. It is a flowchart of the selection routine a called by the 1st selection process. It is a flowchart of the selection routine b called in the second selection process. It is a flowchart of the process which a user interface performs. It is a flowchart of a game request process. It is a figure which shows the flowchart of a game process. It is a figure which shows the structure of the server apparatus of the 2nd related technology of this invention. It is a figure which shows the structure of the client apparatus of a 2nd related technique. It is a figure which shows the example of the extended user interface. It is a flowchart which shows the reception process in a server apparatus. It is a flowchart of an admission reception subroutine. It is a flowchart of an end subroutine. It is a flowchart of a leaving subroutine. It is a flowchart of a 3rd selection process. It is a flowchart of the selection routine c called by the 3rd selection process. It is a flowchart of selection routine a 'called by the 1st selection processing. It is a flowchart of the user input process in a client. It is a flowchart of an entrance subroutine. It is a flowchart of an end subroutine. It is a flowchart of a leaving subroutine. It is a figure which shows the structure of the server apparatus of embodiment of this invention. It is a figure which shows the structure of the client apparatus of embodiment of this invention. It is a flowchart of a server apparatus reception process. It is a flowchart of an end subroutine. It is a flowchart of the 4th selection processing. It is explanatory drawing of the stage of a tournament game.

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 apparatus 21 Game request means 22 Game means 31 Network

Claims (6)

In a server device that allows a plurality of participants on a communication network to play a game,
The identification number each multiple stages is set, the user in association with the plurality of user identification information belonging to one of the stages, stores stage information indicating the identification number of the stage that each user belongs Information storage means;
When a game request is received from a client device of a user who desires to play , the game information is registered in association with the identification information of the user who sent the game request in the user information storage means Request registration means;
Utilization state information of the remote station waiting selects a plurality of users belonging to the same stage of the users registered from the user information storage unit, determines the remote station by the selected user, the remote station decides The player selection means for notifying the client device of each user of the identification information of the user who is the opponent and updating the status information of each user determined by the player in the user information storage means during the game When,
Stage management means for updating the stage information of the winning user in the user information storage means to the identification number of the stage to which the winning user belongs when receiving a game result from the client device of the user who played the game ,
The server apparatus characterized by having.   The server apparatus according to claim 1, wherein the stage management unit deletes the stage information of the losing user in the user information storage unit. In a server device that allows a plurality of participants on a communication network to play a game,
Identification information to each multiple stages is set, the user in association with the plurality of user identification information belonging to one of the stages, stores stage information indicating the identification number of the stage that each user belongs Information storage means;
When a game request is received from a client device of a user who desires to play , the game information is registered in association with the identification information of the user who sent the game request in the user information storage means Request registration means;
Utilization state information of the remote station waiting selects a plurality of users belonging to the same stage of the users registered from the user information storage unit, determines the remote station by the selected user, the remote station decides The player selection means for notifying the client device of each user of the identification information of the user who is the opponent and updating the status information of each user determined by the player in the user information storage means during the game When,
Upon receiving the remote station results from the user of the client apparatus that has performed the opposite station, the stage information of losing user of said user information storage means, stage management means losing user to update the identification number of the stages belonging and ,
The server apparatus characterized by having.   In a network game system that allows a plurality of participants on a communication network to play a game,
  User information in which an identification number is set for each of the plurality of stages, and stage information indicating the identification number of the stage to which each user belongs is stored in association with the identification information of the plurality of users belonging to any of the stages. Storage means;
  When a game request is received from a client device of a user who desires to play, the game information is registered in association with the identification information of the user who sent the game request in the user information storage means Request registration means;
  A user who has selected a plurality of users belonging to the same stage from among the users whose status information waiting for a game is registered is selected from the user information storage means, determines a game by the selected user, and the user determined by the game A player selection means for notifying each client device of the identification information of the user who is the opponent of the game and updating the status information of each user determined by the game in the user information storage means during the game; ,
  Stage management means for updating the stage information of the winning user in the user information storage means to the identification number of the stage to which the winning user belongs when receiving a game result from the client device of the user who played the game ,
  A server device comprising:
  A client device comprising game request means for outputting the game request to the server device;
  A network game system comprising:   In a computer-readable recording medium recording a player selection program for allowing a plurality of participants on a communication network to play a game,
  Computer
  User information in which an identification number is set for each of a plurality of stages, and stage information indicating the identification number of the stage to which each user belongs is stored in association with the identification information of a plurality of users belonging to any of the stages. Storage means,
  When a game request is received from a client device of a user who desires to play, the game information is registered in association with the identification information of the user who sent the game request in the user information storage means Request registration means,
  A user who has selected a plurality of users belonging to the same stage from among the users whose status information waiting for a game is registered is selected from the user information storage means, determines a game by the selected user, and the user determined by the game Notifying each client device of the identification information of the user who is the opponent, the player selection means for updating the status information of each user determined by the game in the user information storage means during the game,
  Stage management means for updating the stage information of the winning user in the user information storage means to the identification number of the stage to which the winning user belongs, when receiving the game result from the client device of the user who played the game,
  A computer-readable recording medium on which a player selection program for functioning as a computer is recorded.   In a player selection method for allowing a plurality of participants on a communication network to play a game,
  When the game request registration means receives a game request from the client device of the user who wants to play, an identification number is set for each of the multiple stages, and it corresponds to the identification information of the multiple users belonging to one of the stages In addition, status information indicating waiting for a game is registered in association with the identification information of the user who has transmitted the game request in the user information storage means for storing stage information indicating the identification number of the stage to which each user belongs. And
  The player selection means selects a plurality of users belonging to the same stage from the user information storage means among the users whose status information waiting for the game is registered, determines a game by the selected user, Notifying each client device of the user determined by the game of the identification information of the user who is the opponent of the game, and updating the status information of each of the users determined by the game in the user information storage means during the game And
  When the stage management means receives the game result from the client device of the user who played, the stage information of the winning user in the user information storage means is updated to the identification number of the stage to which the winning user belongs To
  A player selection method characterized by this.

Images