Game control program, game device, game server and method for controlling game

The present invention relates to a game control technique, and more particularly to a game control program, a game device, a game server, and a game control method for controlling a game executed by a plurality of players.

Competitive games using networks are gaining popularity. The player can find an opponent by using the matching function provided by the server and enjoy the battle game.

<p> In network-based games, you can get external stimuli, which is fun that you cannot get by playing alone, but on the other hand, there is also the problem that you may not be able to proceed with the game at your own pace.</p><p> The present invention has been made in view of these circumstances, and an object of the present invention is to provide a more entertaining game control technique.</p>

<p> One aspect of the present invention relates to a game control program. This game control program has a function of requesting the game server that manages the multiplayer to select a player who is an opponent of the multiplayer that executes a game together with another player's game device, and as a mode of the multiplayer. The game server selects one of the first mode in which multiplayer is performed with a player who has requested multiplayer and the second mode in which multiplayer is forcibly performed with a selected player. It is characterized in that a computer realizes a function of notifying a player and a function of receiving a notification of a player who is an opponent of the multiplayer from the game server and controlling multiplayer with the game device of the player. ..</p><p> Another aspect of the invention also relates to a game control program. This game control program has a function of accepting a multiplayer request for executing a game together with another player's game device from a player's game device, and a player who responds to the multiplayer request as the multiplayer mode. Refer to the player database that stores player information and the function to select one of the first mode that multiplayers between players and the second mode that forces multiplayers between selected players. Then, the computer is provided with a function of selecting a player to be the opponent of the multiplayer and a function of requesting the start of the multiplayer while notifying the game device of the selected player of the selected mode. And.</p><p> It should be noted that any combination of the above components and the conversion of the expression of the present invention between methods, devices, systems and the like are also effective as aspects of the present invention.</p>

<p> According to the present invention, it is possible to provide a more entertaining game control technique.</p>

In the embodiment, a technique for providing a function of directly or indirectly influencing each other with other players when each player executes a game in parallel will be described. In the present embodiment, a player operates a player's character, advances through a game field composed of a plurality of areas, fights against an enemy character, picks up an item, and clears various events. Let's take a role-playing game that aims to achieve the purpose of.

If the player's character dies by being defeated by an enemy character before achieving the specified purpose, the acquired item will be lost and the game will be played again from the specified point in the area with the physical strength value halved. To be started. At this time, the game server provides a means for restarting the game without losing items or the like. That is, the player can request the game server for relief to revive the player's character. The game server prepares two methods as a remedy method. One is a method in which the player's character is revived by advancing the game in cooperation with the player who is the rescue partner, achieving a predetermined purpose, and clearing the area. This method is hereinafter referred to as "friendship mode". The other is a method in which the player's character is revived by fighting and defeating the player's character of the player who is the rescue opponent. This method is hereinafter referred to as "hostile mode".

In the friendship mode, when the player requests the rescue of the player's character, the game server recruits the player of the opponent to be rescued, and if the rescue opponent is found, the rescue opponent's game field is displayed in the game field of the player who requested the rescue. Place the player's character of the player. In hostile mode, the game server automatically selects a rescue opponent and intrudes the player's character of the player who requested the rescue into the game field of the selected player. When the player's character dies, the player can choose one of the methods to challenge the player's character to revive.

Players can run the game independently without connecting to the game server, but when playing the game while connected to the game server, they are given the opportunity to enjoy multiplayer with other players as described above. Be done. Multiplayer in friendship mode does not occur unless you ask for relief or accept the relief of others, so you can enjoy multiplayer at your own pace. Also, from time to time, other player's characters may unexpectedly intrude in the hostile mode, so you can enjoy a tense fun.

In the present embodiment, various functions for indirectly communicating between players are further provided. For example, while the game is in progress, you can play the play data of another player, display the position where the other player is game over, leave a message to the other player on the field, or other player. Provides a function to display the message left by. As a result, each player can acquire information that is a hint for the progress of the game, so that the convenience of the player can be improved. Also, by checking the situation of other players and seeing the message, a sense of solidarity is created between the players, and it is possible to provide fresh fun.

FIG. 1 shows the configuration of the game system 1 according to the embodiment. In the game system 1, the game device 100 in which the player executes the game and the game server 10 that controls the games executed in the plurality of game devices 100 are connected by the Internet 20 which is an example of the network, and the Internet 20 is connected. Send and receive data via.

The game server 10 includes a communication unit 30, a control unit 40, a player database 60, a message database 62, and a play data holding unit 64. Speaking of hardware components, these configurations are realized by the CPU, memory, programs loaded in the memory, etc. of any computer, but here, the functional blocks realized by their cooperation are drawn. Therefore, it will be understood by those skilled in the art that these functional blocks can be realized in various ways by hardware only, software only, or a combination thereof.

The player database 60 stores information on players who use the service provided by the game server 10. FIG. 2 shows an example of the internal data of the player database 60. The player database 60 is provided with a player ID column 70, an authentication data column 71, an IP address column 72, a level column 73, an area ID column 74, a play data column 75, a game over position column 76, and a status column 77. .. The player ID field 70 stores the player's ID. The authentication data field 71 stores data for authenticating the corresponding player. The IP address field 72 stores the IP address of the game device of the corresponding player. The level column 73 stores the level of the player's character of the corresponding player. The area ID column 74 stores the ID of the area of the game field that the corresponding player is playing. The play data field 75 stores a data file name in which the play data of the corresponding player is stored. The game over position column 76 stores the dead position when the player's character of the corresponding player dies. The status column 77 stores the game status of the corresponding player. The status includes, for example, "normal mode is being executed", "friendship mode is being requested", "friendship mode is being executed", "hostile mode is being requested", and "hostile mode is being executed".

The message database 62 stores messages registered by the player. FIG. 3 shows an example of the internal data of the message database 62. The message database 62 is provided with a message ID column 80, an area ID column 81, a position column 82, a player ID column 83, a message column 84, and an evaluation column 85. The message ID field stores the ID of the message. The area ID column 81 stores the ID of the area of the game field in which the corresponding message is registered. The position field 82 stores the position in the area where the corresponding message is registered. The player ID column 83 stores the ID of the player who registered the corresponding message. The message field 84 stores the content of the corresponding message. The evaluation column 85 stores the evaluations given by other players for the corresponding message.

The authentication unit 41 authenticates the player connected to the game server 10. When the connection is requested from the player's game device 100, the authentication unit 41 requests the player's ID and authentication data, refers to the player database 60, and authenticates the acquired player ID and authentication data. If the player ID is not registered in the player database 60, the authentication unit 41 accepts the new registration of the player and registers the player ID and the authentication data in the player database 60. When the authentication unit 41 succeeds in authenticating the player, the authentication unit 41 acquires the IP address of the game device 100 and registers it in the player database 60. In addition, the player's level and the ID of the area being played are acquired and registered in the player database 60.

The multiplayer request receiving unit 42 receives a multiplayer execution request from the player's game device 100. As described above, in the present embodiment, multiplayer is prepared as a remedy when the player's character dies. The multiplayer request reception unit 42 receives a request for multiplayer in the friendship mode or the hostile mode from the game device 100 of the player who desires the revival of the dead player's character.

The friendship mode matching unit 43 selects a player to be the opponent of the multiplayer when the multiplayer request reception unit 42 receives the multiplayer request in the friendship mode. The friendship mode matching unit 43 acquires the level and area ID of the player who requested the multiplayer in the friendship mode from the player database 60, and searches the player database 60 for players who are playing the same area and have the same level. The friendship mode matching unit 43 selects a player from the searched players under predetermined conditions or at random, and transmits data for convening to the game device 100 of the selected player for multiplayer in the friendship mode. The friendship mode matching unit 43 determines a multiplayer opponent from among the game devices 100 convened for multiplayer, and among the game devices 100 that have accepted the convocation for multiplayer. The friendship mode matching unit 43 notifies each of the determined player's game device 100 and the requesting player's game device 100 of the IP address of the opponent's game device 100.

In order to improve the success rate of the rescue of the player's character in the friendship mode, a player whose level is higher than the level of the player who requested the rescue may be selected as the rescue opponent. As a result, the convenience of the player can be improved. Conversely, a player whose level is lower than the level of the player who requested the relief may be selected as the relief opponent. As a result, the difficulty level of the game can be kept high and the entertainment can be improved.

The hostile mode matching unit 44 selects a player to be the opponent of the multiplayer when the multiplayer request receiving unit 42 receives the multiplayer request in the hostile mode. The hostile mode matching unit 44 acquires the level and area ID of the player who requested the multiplayer in the hostile mode from the player database 60, and searches the player database 60 for players who are playing the same area and have the same level. The hostile mode matching unit 44 selects a player from the searched players under predetermined conditions or at random, and notifies the game device 100 of the selected player of the start of multiplayer in the hostile mode. That is, in the hostile mode, the requesting player's character forcibly breaks into the requesting game field regardless of the opponent's intention, and multiplayer is started. The hostile mode matching unit 44 notifies each of the requesting player's game device 100 and the requesting player's game device 100 of the IP address of the opponent's game device 100.

In order to improve the success rate of rescue of a player's character in hostile mode, a player whose level is lower than the level of the player who requested the rescue may be selected as an opponent. As a result, the convenience of the player can be improved. Conversely, a player with a level higher than the level of the player who requested the relief may be selected as an opponent. As a result, the difficulty level of the game can be kept high and the entertainment can be improved.

The friendship mode matching unit 43 and the hostile mode matching unit 44 may select a plurality of players as multiplayer opponents. In this case, in order to reduce the processing load of the game device 100 and the congestion of communication, an upper limit value of the players who can participate in the multiplayer may be set.

After the opponent of the multiplayer is decided, the transmission / reception of data between the game devices 100 participating in the multiplayer may be mediated by the game server 10, or may be performed between the game devices 100 using P2P communication or the like. Good. In the latter case, data may be sent and received directly between the participating game devices 100, or one game device 100, for example, the requesting game device 100 may be the host and the other game devices 100. You may mediate the transmission and reception of data.

The play data acquisition unit 45 acquires data indicating the status of the game being executed from the player's game device 100 and stores it in the play data holding unit 64. The play data to be acquired may be video data that captures the screen and sound of the game being executed, data that indicates the history of player operations, or game control parameters. Good. Further, it may be so-called replay data in which coordinate data indicating the position of the player's character and data indicating the posture of the player's character are recorded for each frame or for each predetermined number of frames. In short, it suffices if the acquired play data can be played back by the game device 100 of another player. The play data also includes data when the player's character dies due to being defeated by an enemy.

The play data distribution unit 46 distributes the play data held in the play data holding unit 64 to the player's game device 100 at a predetermined timing. The play data distribution unit 46 may read the play data held in the play data holding unit 64, select and distribute the game device 100 to which the play data should be distributed, or first distribute the play data. The game device 100 may be determined, and the play data to be distributed to the game device 100 may be selected and distributed.

In the former case, first, the play data distribution unit 46 selects and reads the play data held in the play data holding unit 64 under predetermined conditions or at random. Subsequently, the play data distribution unit 46 refers to the player database 60, acquires the level and area ID of the player who transmitted the read play data, and is playing the same area, and the players having the same level are selected. Search from player database 60. The play data distribution unit 46 selects a distribution destination player from the searched players under predetermined conditions or at random, acquires the IP address of the game device 100 of the selected player from the player database 60, and plays. Send data.

In the latter case, first, the play data distribution unit 46 selects the game device 100 to which the play data should be distributed under predetermined conditions or at random. Subsequently, the play data distribution unit 46 refers to the player database 60, acquires the level and area ID of the player of the selected game device 100, and is playing the same area, and the player of the same level is played. Search from database 60. The play data distribution unit 46 selects a player from the searched players under predetermined conditions or at random, reads the play data of the selected player from the play data holding unit 64, and transmits the player.

The play data distribution unit 46 may periodically distribute the play data to the game device 100, or may distribute the play data to the game device 100 of another player when the play data acquisition unit 45 acquires the play data. However, when the player starts playing in an area, the play data in that area may be distributed in a batch. The play data distribution unit 46 may set an upper limit of the number of game devices 100 that distribute play data at one time in order to reduce the load on the game server 10.

The message registration reception unit 47 receives a message registration request from the game device 100, and registers the received message in the message database 62. The message registration reception unit 47 acquires the ID and position of the area for registering the message from the game device 100 in addition to the content of the message, and registers the message in the message database 62.

The message distribution unit 48 distributes the message registered in the message database 62 to the player's game device 100. When the player starts playing in a certain area, the message distribution unit 48 reads the message registered in the area from the message database 62, and outputs the data indicating the content of the message and the registered position to the game of the distribution destination. Deliver to device 100. As a result, the game device 100 can display a message on the game field. The message distribution unit may further read the ID of the player who registered the message and the evaluation of the message from the message database 62 and distribute it to the game device 100. As a result, the player can objectively judge the authenticity of the registered message.

In consideration of the load of the game device 100, an upper limit of the number of messages to be delivered may be set. The message delivery unit 48 may select the message to be delivered in consideration of the level of the player who registered the message and the level of the player who delivers the message. For example, a message registered by a player whose difference from the level of the player who delivers the message is equal to or less than a predetermined value may be preferentially selected. As a result, it is possible to provide the player with a message such as a hint left by a player of the same level, so that the convenience of the player can be improved.

The message evaluation unit 49 evaluates the messages registered in the message database 62. The message evaluation unit 49 may acquire an evaluation for the message from the game device 100 when the registered message is delivered to the game device 100. The message evaluation unit 49 quantifies the evaluation of the message and registers it in the message database 62.

FIG. 4 shows the configuration of the game device 100 according to the embodiment. The game device 100 includes a controller 120, an input reception unit 122, a communication unit 130, a control unit 140, a parameter holding unit 160, a screen generation unit 166, and a display device 168. These configurations can also be realized in various forms by hardware only, software only, or a combination thereof.

The input receiving unit 122 receives a control signal input from the controller 120 operated by the player. The control unit 140 moves the player's character within the area constituting the game field based on the operation input from the player received by the input reception unit 122, and advances the game. The parameter holding unit 160 holds various parameters necessary for the progress of the game, such as the position of the player's character and the event flag. The screen generation unit 166 generates a screen of the game controlled by the control unit 140 and displays it on the display device 168. The communication unit 130 controls communication with the game server 10 via the Internet 20.

The single-player control unit 141 executes a game program and controls a game in a normal mode by a single player. The single play control unit 141 moves the player's character in the area and controls the battle with the enemy character and the execution of the event. In addition, the single play control unit 141 manages the sorting and use of items and the increase / decrease in the physical strength value of the player's character, and when the physical strength value of the player's character becomes zero, the acquired item is deleted and the physical strength value is maximized. Set it to half of the value, move the player's character to the specified location in the area you were playing, and restart the game.

The multiplayer request transmission unit 142 transmits to the game server 10 data requesting that multiplayer be performed with another player. As described above, in the present embodiment, multiplayer is required for the purpose of reviving the dead player's character. The multiplayer request transmission unit 142 may request the game server 10 to execute the multiplayer when the player's character dies during the execution of the single play by the single play control unit 141, or request the multiplayer after restarting the game. When a player requests multiplayer, such as by using an item to do so, the game server 10 may be requested to execute multiplayer. The multiplayer request transmission unit 142 receives an instruction from the player whether to request multiplayer in the friendship mode or multiplayer in the hostile mode, and notifies the game server 10 of the multiplayer mode.

The multiplayer control unit 143 controls the execution of multiplayer with the game device 100 of the player who is the opponent of the multiplayer. The multiplayer control unit 143 executes multiplayer with the game device 100 notified from the game server 10. Multiplayer is used when the player requests the game server 10 to play multiplayer in friendly mode or hostile mode by the multiplayer request transmitter 142, when another player convenes multiplayer in friendly mode, or when another player convenes multiplayer. It starts when another player's character intrudes due to multiplayer in hostile mode by the player.

When the own device requests the start of multiplayer by the multiplayer request transmission unit 142, in the friendship mode, the multiplayer control unit 143 ends the multiplayer when the player's character achieves a predetermined purpose in the area. At this time, the dead player's character is revived and returns to single play. In the hostile mode, the multiplayer control unit 143 ends the multiplayer when the player's character wins the match against the player's character of the opponent's player in the multiplayer. At this time, the dead player's character is revived and returns to single play. If the player's character dies again during multiplayer, it is the same as when the player's character dies in single play.

The play data transmission unit 144 transmits the game play data to the game server 10 at a predetermined timing during the execution of the game. The play data transmission unit 144 may periodically transmit play data at predetermined time intervals, or may transmit play data when a predetermined trigger such as an event occurrence or clear occurs.

The play data receiving unit 145 receives the play data of another game device 100 from the game server 10. The play data reproduction unit 146 reproduces the play data of another game device 100 received by the play data reception unit 145. For example, when the play data receiving unit 145 receives replay data in which coordinate data indicating the position of the player's character of another game device 100 and data indicating the posture of the player's character are recorded for each frame, the play data is reproduced. The unit 146 reads the shape data of the player's character based on the data indicating the posture, generates an image of the player's character, and arranges it on the game field based on the coordinate data.

When the play data receiving unit 145 receives the play data, the play data reproducing unit 146 may reproduce the received play data, or temporarily holds the received play data in the parameter holding unit 160 and plays. When the player's character passes the position where the data is recorded, it may be read from the parameter holding unit 160 and reproduced. As a result, the player can feel that other players are playing the game in parallel and have a sense of solidarity, so that the entertainment of the game can be improved. In addition, by playing back the play of another player, it is possible to obtain a guideline for advancing the game, so that the convenience of the player can be improved.

When the play data reproduction unit 146 receives the data of the position where the player's character of another player has died, the play data reproduction unit 146 displays a mark such as a blood stain at the corresponding position on the game field. When the player's character approaches the mark, the play data reproduction unit 146 inquires the player whether or not to reproduce the play data corresponding to the blood stain, and when it receives an instruction to reproduce the play data, the parameter holding unit 160 corresponds to the play data reproduction unit 146. Read the play data and play it. As a result, it is possible to grasp the position where the game is over by another player, and it is possible to know under what circumstances the game is over, so that the convenience of the player can be improved.

The message registration unit 147 receives the message registration request from the player and requests the game server 10 to register the message. When the message registration unit 147 receives a message registration request from the player while the game is in progress, the message registration unit 147 presents a message input screen. The message template may be stored in the parameter holding unit 160, and the template may be presented to accept the input of the message, or the free sentence may be accepted. The message registration unit 147 transmits the received message, the ID of the area in the game field in which the message is displayed, and the information indicating the position in the area to the game server 10.

The message receiving unit 148 receives the message registered in the game server 10 from the game server 10. The message receiving unit 148 may receive the message registered in the area from the game server 10 before entering the area, or may receive the message registered in the area at a predetermined timing during the progress of the game. The message receiving unit 148 stores the received message in the parameter holding unit 160.

The message display unit 149 displays the message received by the message reception unit 148. When the screen generation unit 166 generates a screen, the message display unit 149 reads the position where the message is registered from the parameter holding unit 160 and notifies the message display unit 149. If the screen generated by the screen generation unit 166 includes a position where the message is registered, an icon or the like indicating that the message is registered is displayed on the screen in the vicinity of the position. When the message display unit 149 receives a message display request from the player, the message display unit 149 reads the corresponding message from the parameter holding unit 160 and displays it. As a result, the messages left by other players can be read, so that a guideline for advancing the game can be obtained, and the convenience of the player can be improved. In the past, information was exchanged between players on a dedicated bulletin board system, but by providing a function for exchanging messages in the game, messages can be read without having to open the bulletin board system while the game is in progress. In addition to being able to read the message related to the position in the game, it is possible to improve the convenience. The message display unit 149 may display only messages having an evaluation higher than a predetermined value. This can improve the reliability of the message.

After presenting the message to the player, the message display unit 149 receives the evaluation of the message from the player and sends it to the game server 10. The displayed message often relates to the game field beyond the point where the message was displayed, in which case the player cannot assess the authenticity of the message at the time the message is displayed. Therefore, the message display unit 149 may receive an evaluation from the player for the messages displayed up to that point when the player reaches a predetermined point on the game field or clears the area, for example. As a result, the credibility of the message can be accurately reflected in the evaluation.

FIG. 5 shows an example of a screen displayed on the display device 168. On the display screen, in addition to the player's character 90 and the enemy character, the player's character 91 of another player, the bloodstain 92 indicating the position where the other player's character died, the icon 93 indicating the message left by the other player, etc. A bloodstain 94 or the like indicating that the player's character is requesting multiplayer in friendship mode is displayed.

When playing back the play data of another player, the play data playback unit 146 uses a display mode such as translucency so that the player's character 91 of the other player can be visually distinguished from the player's character 90 of the own device. indicate.

When the player's character 91 approaches the blood stain 92, the play data reproduction unit 146 asks the player whether to reproduce the play data when the player's character corresponding to the blood stain 92 dies. When the player instructs playback, the play data playback unit 146 reads the play data from the parameter holding unit 160 and plays it.

When the player's character 91 approaches the icon 93 of the message, the message display unit 149 asks the player whether to display the message corresponding to the icon 93. When the player instructs the display, the message display unit 149 reads a message from the parameter holding unit 160 and displays it. At this time, the player may be asked to evaluate the message. The evaluation of the message by the player is transmitted to the game server 10 by the message registration unit 147.

When the player's character 91 approaches the bloodstain 94, the multiplayer control unit 143 asks the player whether or not to accept the invitation to multiplayer in the friendship mode. When the player instructs the execution of multiplayer, the multiplayer control unit 143 notifies the game server 10 that the multiplayer is accepted. When the game server 10 notifies the IP address of the opponent's game device 100, the multiplayer control unit 143 starts multiplayer.

The present invention has been described above based on examples. This embodiment is an example, and it is understood by those skilled in the art that various modifications can be made to the combination of each component and each processing process, and such modifications are also within the scope of the present invention.

<figref num="1">It is a figure which shows the structure of the game system which concerns on embodiment.</figref><figref num="2">It is a figure which shows the example of the internal data of a player database.</figref><figref num="3">It is a figure which shows the example of the internal data of a message database.</figref><figref num="4">It is a figure which shows the structure of the game apparatus which concerns on embodiment.</figref><figref num="5">It is a figure which shows the example of the screen displayed on the display device.</figref>

Code description

10 Game server, 20 Internet, 30 Communication unit, 40 Control unit, 41 Authentication unit, 42 Multiplayer request reception unit, 43 Friendship mode matching unit, 44 Hostile mode matching unit, 45 Play data acquisition unit, 46 Play data distribution unit, 47 Message registration reception unit, 48 message distribution unit, 49 message evaluation unit, 60 player database, 62 message database, 64 play data holding unit, 100 game device, 140 control unit, 141 single play control unit, 142 multiplayer request transmission unit, 143 Multi-play control unit, 144 play data transmission unit, 145 play data reception unit, 146 play data playback unit, 147 message registration unit, 148 message reception unit, 149 message display unit, 160 parameter holding unit, 166 screen generation unit, 168 display device ..