JP2013146475A - Game management device, game management method and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a player with an environment allowing the player to easily and speedily return a present given from another player without requiring labors.SOLUTION: A game management device includes: an extraction means 56 for extracting a return candidate to be given to a first player in return from items owned by a second player automatically or according to the manual operation by the second player if a present is given by the first player to the second player as another player; and a return candidate transmitting means 57 for transmitting screen data for displaying the return candidate extracted by the extraction means 56 to a terminal device of the second player.

Description

  The present invention relates to a game management device, a game management method, and a program for managing game information of each player.

  Conventionally, a game system in which a player can receive various game services provided from the game server by connecting the terminal device (personal computer, mobile phone terminal, etc.) of the player to a game server installed on the Internet. There is.

  There has also been proposed a game system in which players who play a common game via the Internet or the like can present items or the like as opponents (see Patent Documents 1 and 2).

  In recent years, the game system has been incorporated into a social networking service (SNS) system, which is a community-type service that promotes and supports connections between people, and is provided as one of the SNS services. Games are prevalent. In such a social game, each player becomes a friend with another player who uses the game service, and the players can interact with each other, such as exchanging presents with each other. .

JP 2001-129240 A JP 2011-110139 A

  In a conventional game system, when a player who received a gift such as an item from a game mate who is playing the same game gives a reward for the game mate, It is necessary to search for things that the other party wants, and decide what to give, and then operate the present. Thus, in order to give a gift of return to the other party who received the present, the player needs a lot of trouble and is troublesome. In addition, since the operation is troublesome, it may happen that a gift of return is not given to the other party. That is, the situation where the return to the opponent is troublesome can be a factor that hinders the close relationship between the players.

  The present invention has been made in view of the above problems, and its purpose is to give a return gift to a partner who has received a present simply and quickly, without the need for conventional labor. To realize a game management device, a game management method, and a program capable of providing an environment to a player.

  (1) A game management device according to one aspect of the present invention communicates with a terminal device of each player, and manages a game in which the player can present what the player owns in the game to other players. An ownership information storage means for storing devices owned by each player, and stored in the ownership information storage means when a present is given from the first player to the second player Extraction means for extracting a return candidate for presenting to the first player from information owned by the second player, and information for displaying the return candidate extracted by the extraction means, A return candidate transmitting means for transmitting to the terminal device of the second player.

  The game management device having this configuration can be configured by an information processing device such as a server that can communicate with the terminal device of each player. And this game management apparatus is a game in which the player can present what the player owns in the game to other players, for example, a social game in which the players can become friends and enjoy exchanges such as presents Manage.

  Here, “present” refers to virtually giving (or giving) what the player owns in the game to another player. “Present” may be expressed as “gift (give)”, “gift (give)”, “transfer”, or the like. Moreover, the virtual relationship in the game between the players who give presents is not particularly limited. For example, the relationship between the players may be friends, colleagues, family members, bosses and subordinates, superiors and subordinates, seniors and juniors, etc. Giving is included in the “present”.

  The game management device includes ownership information storage means for storing what each player owns in the game. Here, “the player owns in the game” includes a character (including a character in a card form), an item (a treasure item, equipment for a character such as a weapon or armor, a recovery item). , Magic items, special items, various other items), various points, in-game currency, etc., that can be included in various things that a player can obtain and own in the game.

  The present game management device is owned by the second player stored in the possession information storage means when a present is given from the first player to the second player, which is another player. Extraction means for extracting a return candidate for presenting to the first player is provided. The extraction means may automatically perform return candidate extraction processing. Alternatively, as in the configuration of (11) described later, the second player performs an operation for confirming a return candidate on the terminal device, thereby responding to a return candidate request transmitted from the terminal device of the second player. Thus, the extraction means may execute a return candidate extraction process.

  The reference that the extraction means extracts as a return candidate can be arbitrarily determined. For example, as in the configuration of (4) described later, a character or the like registered in advance as what the first player who is a return target desires is extracted as a return candidate, or (5) described later. As in the configuration, a character having the same attribute as the desired returnee can be extracted as a return candidate.

  Then, the information for displaying the return candidate extracted by the extraction means is transmitted to the terminal device of the second player by the return candidate transmission means. In the terminal device of the second player that has received the information transmitted by the return candidate transmission means, the return candidate for the first player who presented the present to the second player is displayed.

  As described above, in this configuration, when a present is given from the first player to the second player, the game management device extracts the return reward candidates from those owned by the second player, and the second player The second player does not need to perform the troublesome and troublesome task of searching for a character or item to be presented as a return to the first player. . Therefore, it is possible to provide the player with an environment in which a return gift can be given to the other party who has received the present easily and quickly without the need for conventional labor.

  (2) In the above-described configuration, the game management device receives the information transmitted to the return candidate transmission means and displays the return candidate on the second player terminal device displaying the return candidate. When a return operation for presenting to one player is performed, information about the operation is received from the terminal device, and a return process for presenting the return candidate owned by the second player to the first player It is preferable to further include a return means for executing

  According to this configuration, when a return operation is performed on the terminal device of the second player that displays the return candidates, the return means selects the return candidates owned by the second player as the first. The return process for presenting to the player is executed. That is, when a present is given from the first player to the second player, the second player receives the present by confirming the return candidate displayed on the terminal device and performing a return operation. A return gift for one player can be easily and quickly performed.

  (3) In the configuration of (2) above, the game management device is presented until the second player receives a present when a process of presenting from the first player to the second player is performed. It is preferable to further comprise an unreceived present storage means for storing. Then, when the number of possessions of what each player can own in the game has an upper limit, and the possession number of the second player has reached the upper limit, the return means receives from the return candidate transmission means When a return operation for presenting the return candidate to the first player is performed on the terminal device of the second player receiving the transmitted information and displaying the return candidate, the operation information Is received from the terminal device, the return candidate is deleted from those owned by the second player and presented to the first player, and the first unstored present storage means stores the first candidate It is preferable to update the storage content of the possession information storage means so that the second player receives and owns the gift presented by the player.

  According to this configuration, when the process of presenting from the first player to the second player is performed, the present is not immediately owned by the second player, but the second player presents. (For example, the second player performs a present receiving operation), the first player who has received the present becomes the possession of the second player. Then, until the second player receives the present, the present is stored in the unreceived present storage means.

  In this configuration, there is an upper limit on the number of characters and the like that each player can own in the game, and even if the number of possessions of the second player has already reached the upper limit, The player can give a present to the second player. However, when the number of possessions has already reached the upper limit, the second player cannot receive a gift.

  Therefore, conventionally, prior to receiving the present, the character etc. possessed by the second player is first reduced by a predetermined operation (operation such as sale), so that there is a margin up to the upper limit of the possession number. It was necessary to provide. Furthermore, when giving a present for return in response to the received present, there is an operation of searching for a gift to be given to the opponent from those owned by the second player, and then operating the present after determining it. Occur. That is, conventionally, when a present is given from the first player to the second player, the number of possessed characters, etc. of the second player is reduced (when the number possessed by the second player reaches the upper limit). Since it is necessary to perform a series of operations such as receiving a present, searching and determining a present to return to the other party, and presenting the present to the other party, it takes a lot of trouble and is troublesome. In addition, since the operation is troublesome, it may happen that a gift of return to the other party is not given. The situation where the return to the opponent is troublesome can be a factor that hinders the close relationship between the players.

  On the other hand, in the present configuration, as described below, presents can be received and returned easily and quickly without requiring much time and effort.

  That is, when the return operation is performed at the terminal device of the second player displaying the return candidates, the return means of this configuration deletes the return candidates from those owned by the second player. Then, the present information is given to the first player, and at the same time, the second player receives and owns the present given from the first player stored in the unreceived present memorizing means. The memory content of is updated. In other words, the return means of the present configuration reduces the number of possessed characters of the second player, the receipt of the present from the first player, and the present of the return to the first player almost simultaneously at the same time. It has the function to do.

  Therefore, when the number of characters held by the second player has reached the upper limit, the second player simply performs a return operation (for example, presses the return button) on the terminal device displaying the return candidates. Just) and can receive and return gifts easily and quickly. In addition, as described above, the game management device also presents return candidates, so that the second player does not need a troublesome operation of searching for a character or the like to be presented as a return to the first player. In this case, the player only has to select a predetermined candidate from the return candidates and press the return button. As described above, in the present configuration, when a present is given from the first player to the second player, the operation to be performed by the second player is greatly simplified as compared with the prior art, and it is easy and quick. An environment in which a present can be received and returned can be provided to the player.

  (4) In any one of the configurations (1) to (3), the game management device wants to store what each player wants in response to a desired registration request from the terminal device operated by each player. It is preferable to further comprise a storage means. When the presenter gives a present to the second player from the first player, the extraction means is the one desired by the second player stored in the possession information storage means. When it is detected that there is what the first player wants stored in the storage means, it is preferable to extract what the first player wants as the return candidate.

  According to this configuration, each player can register what he / she wants (a character or item he / she can own) by operating the terminal device. The desired storage means of the game management device stores the desired items of each player in response to a desired item registration request from the terminal device operated by each player.

  The extraction means has a function of extracting what the returnee wants to register as a return candidate. That is, when the presenter gives a present to the second player from the first player, the extraction means stores the desired storage means among the possessions of the second player stored in the possession information storage means. It is confirmed whether or not there is what the first player wants to memorize. Then, when the extracting means detects that what the first player wants exists among the things owned by the second player, the extracting means extracts what the first player wants as a return candidate.

  Thus, by extracting what the return target person wants to register as a return candidate, the return candidate preferred by the return target person can be accurately presented on the terminal device of the player.

  (5) In any one of the configurations (1) to (3), at least a part of what each player can own in the game has one of a plurality of attributes set. In response to an attribute registration request from a terminal device operated by each player, the game management device includes player attribute storage means for storing any one of the plurality of attributes and the attribute desired by each player. It is preferable to further provide. Then, when a present is given from the first player to the second player, the extraction means includes the player attribute among those owned by the second player stored in the possession information storage means. When it is detected that there is an object having the same attribute as the attribute desired by the first player stored in the storage means, it is preferable to extract an object having the same attribute as the return candidate.

  According to this configuration, any one of a plurality of attributes is set in at least a part of what each player can possess in the game (such as a character or an item). For example, each player character in a baseball game based on baseball has a plurality of team attributes (for example, 12 types of team attributes corresponding to 12 professional Japanese baseball teams in the real world). The attribute of any one of these is set. Also, for example, the A attribute (A attribute is compatible with the B attribute but not compatible with the C attribute), the B attribute (B attribute is compatible with the C attribute but not compatible with the A attribute), the C attribute (C There are three types of attributes, which have good compatibility with the A attribute but poor compatibility with the B attribute, and any one of the three types of attributes is set for a character, item, or the like.

  Each player can register the desired attribute of any one of the plurality of attributes by operating the terminal device. The player attribute storage means of the game management device stores an attribute desired by each player in response to an attribute registration request from a terminal device operated by each player.

  Further, the extraction means has a function of extracting, as candidates for return, those having the same attribute as the desired returnee. That is, when a present is given from the first player to the second player, the extraction means stores the player attribute storage means in the possession of the second player stored in the ownership information storage means. It is confirmed whether or not there is an object having the same attribute as the desired attribute of the stored first player. When the extraction means detects that the second player has the same attribute as the attribute desired by the first player, the extraction means returns the candidate having the same attribute as the return candidate. Extract as

  In this way, by extracting, as return candidates, those having the same attributes as those desired by the returnee at the time of attribute registration, the return candidates considered to be preferred by the returnee are accurately presented to the terminal device of the player. Can do.

  (6) In any one of the configurations (1) to (3), at least a part of what each player can own in the game has one of a plurality of attributes set. The game management device includes player attribute storage means for storing any one of the plurality of attributes and the attribute desired by each player in response to an attribute registration request from a terminal device operated by each player. It is preferable to further comprise a desired storage means for storing a desired item of each player in response to a desired item registration request from a terminal device operated by each player. Then, the extraction means sets the priority to be extracted as the return reward candidate in the descending order of what the first player wants stored in the desired storage means, and the first stored in the player attribute storage means. The player has the same attribute as that desired by the player, and has an attribute different from the attribute desired by the first player, and the return candidate transmission means sends a candidate change request from the terminal device of the second player. Each time it is received, it is preferable that information for displaying the return candidates in order from the higher priority return candidates is sequentially transmitted to the terminal device of the second player.

  According to this configuration, the priority is set for those extracted as the return candidates by the extraction means. The priority is, in order from the highest, what the first player wants stored in the desired storage means, and what has the same attribute as that desired by the first player stored in the player attribute storage means, The first player has an attribute different from the desired attribute. In other words, the higher the priority is set, the more the player who wants to receive the first player who is a returnee. And it is extracted as a return favor candidate from a thing with a high priority, and is shown to the terminal device of a 2nd player.

  By the way, even if what is desired for the first player who is a returnee, what is not desired for the second player to return may be extracted as a return candidate. Thus, the second player can operate the terminal device to change the return reward candidates displayed on the terminal device as appropriate. That is, when the second player performs a candidate change operation on the terminal device, a candidate change request is transmitted from the terminal device to the game management device. Whenever a candidate change request is received, the return candidate transmission means of the game management device displays information for displaying return candidates in order from the highest priority return candidates extracted by the extraction means. Send to. As a result, the return candidates displayed on the terminal device of the second player are changed in order from the highest priority to the lowest.

  As described above, since the priority of extraction is higher for those who would like the first player to be presented preferentially as return candidates, the first player will be pleased if they return. What is likely to be received can be easily selected by the second player and is easily returned. On the other hand, if what is presented as a return candidate is something that the second player does not want to give up, the return candidate can be changed in order from the highest priority to the lowest return. This makes it easier for the first player to think as much as possible and what the second player thinks he or she can let go. As a result, an appropriate return object can be easily determined without requiring time and effort as in the case where the second player selects and determines the return object himself.

  (7) In any one of the above configurations (1) to (3) and (5), a rarity value level indicating a high rarity value is set for at least a part of what each player can own in the game. And when the present is given from the first player to the second player, the extraction means includes the first player that is stored in the possession information storage means and that is owned by the second player. When it is detected that there is a thing with the same rare value as that presented by the player or a rare value with a predetermined range based on the rare value, the detected value is extracted as the return candidate. Is preferred.

  According to this configuration, a rarity value level indicating a high rarity value is set in at least a part of what each player can own in the game (such as a character or an item). This rare value degree is also called a so-called rare degree. The extraction means has a function of extracting a gift that is given by the partner as a return reward candidate that matches the rarity value. That is, when the presenter gives a present to the second player from the first player, the extraction means includes the ones owned by the second player stored in the possession information storage means from the first player. It is confirmed whether or not there is a rare value having the same value as the rare value of the gift or a predetermined range of rare values based on the rare value. Then, when the extraction means detects that the scarce value exists among those owned by the second player, it extracts it as a return reward candidate.

  Here, an example of “a rarity value within a predetermined range based on the rarity value of what was presented by the first player” will be described. For example, it is assumed that characters, items, and the like are provided with five levels of rare value from “1 (lowest)” to “5 (highest)”. And when the rare value degree of what was presented from the 1st player is set to R1, the rare value degree of a predetermined range can be set to (R1-1)-(R1 + 1), for example.

  In this way, by extracting as a return candidate a gift that has been given by the opponent and corresponding to the rarity value, both the return side and the return side can accurately present the return candidate that is satisfactory to the player's terminal device. Can do.

  (8) In any one of the configurations (1) to (7) described above, the game management device selects one selected from those owned by the player in response to a holding request from the terminal device of the player. It is preferable that the information processing apparatus further includes holding information storage means for storing it as a holding object without being a return object. And it is preferable that the said extraction means extracts the said return favor candidate except the thing memorize | stored in the said holding | maintenance information storage means.

  According to this configuration, if there is a character or the like that the player wants to hold without wanting to return (does not want to let go) in the possession of the player, the player performs an operation of selecting it on the terminal device and registers it in advance. be able to. The holding information storage means of the game management device stores, in response to a holding request from the terminal device operated by each player, what is selected from those possessed by the player is held as a return object. . Then, the extraction unit extracts the return favor candidates by excluding those stored in the retained information storage unit. Thereby, it is possible to avoid in advance that a character or the like that the player does not want to give up is repeatedly presented as a return candidate.

  (9) In the configuration of any one of (1) to (8), the game management device is a case where a present is given from the first player to the second player, and the terminal of the second player When a return hold operation is performed on the device, information on the operation is received and an unreturned history is stored that indicates that the second player has not returned the present from the first player. In response to an unrepayment confirmation request from the history storage means and the terminal device of the second player, the unreturned history of the second player stored in the unreturned history storage means is read, and the unreturned history is It is preferable that the information processing apparatus further includes an unreturned history transmission unit that transmits information to be displayed to the terminal device.

  According to this configuration, when the second player who has received a present from the first player does not return to the first player immediately because he / she does not own an appropriate return target, the terminal device holds a return hold. The operation can be performed. When a return hold operation is performed on the terminal device of the second player, the unreturned history storage means of the game management device that has received the information on the operation causes the second player to receive a present from the first player. An unreturned history indicating that no return has been made is stored.

  After that, the second player who has performed the return hold operation can confirm the held information (unreturned history). That is, if the second player operates the terminal device when he / she wants to confirm the information of unreturned, in response to the unreturned confirmation request transmitted from the terminal device of the second player, the unreturned history transmission means The unrepayed history of the second player stored in the unrepayed history storage means is read out. Then, the unreturned history transmission means transmits information for displaying the read-out unreturned history of the second player to the terminal device of the second player. The unreturned history is displayed on the terminal device of the second player that has received the information transmitted by the unreturned history transmitting means.

  In this way, the second player who has made the return hold operation can check the hold information (unreturned history) with his / her terminal device at any time. As a result, it is possible to avoid a situation where the return to the partner who received the present is forgotten. That is, it is often the case that when a gift is received, the user does not return immediately, but forgets to return to the other party who received the gift if time passes. However, with this configuration, if the unreturned history can be confirmed at any time, the situation of forgetting to return can be effectively avoided. Therefore, the present is less likely to be left unreturned, which can contribute to intimate communication between players.

  (10) In any one of the configurations (1) to (9), the game management device is a case where a present is given from the first player to the second player, and the terminal of the second player When an operation for setting a reminder is performed on the device, information on the operation is received, history information on the present from the first player to the second player is stored, and the second player is stored. Reminder setting means for setting a reminder with the first player as a returnee, and a second player for which the second player has been set by the reminder setting means to return to the first player who is the returnee When a game that satisfies the above condition is obtained in the game, information for notifying that the obtained product is a return object for the first player is transmitted to the terminal device of the second player. It is preferable to further comprises a command means.

  According to this configuration, when the second player who has received a present from the first player does not return to the first player immediately because he / she does not own an appropriate return object, the reminder is set on the terminal device. The operation can be performed. When the reminder setting operation is performed on the terminal device of the second player, the reminder setting means of the game management device that has received the operation information has given a present from the first player to the second player. The history information is stored, and a remind setting is performed on the second player with the first player as a returnee.

  After that, when the second player for which the remind setting has been performed obtains in the game what satisfies the return criteria for the first player who is the return target, the acquired reminder means that the first player The information for notifying that it is a return object is transmitted to the terminal device of the second player. Here, with respect to “what satisfies the return criteria for the first player who is the return target”, for example, an arbitrary reference such as what the return target person wants can be set. The terminal device of the second player that has received the information transmitted by the reminding means is notified by display, voice, or the like that the acquired one is the object of return to the first player.

  In this way, when the second player who has performed the remind setting operation obtains in the game what satisfies the return criteria for the first player who is the return target, game management is performed on the terminal device of the second player. A notification (remind) of a return object is performed from the device. As a result, it is possible to avoid a situation where the return to the partner who received the present is forgotten. That is, it is often the case that when a gift is received, the user does not return immediately, but forgets to return to the other party who received the gift if time passes. However, with this configuration, since a notification that the return target has been obtained is given to the return target person, it is possible to effectively avoid a situation where the return is forgotten. In addition, in this configuration, the notification of the return object eliminates the need for the second player to perform the troublesome and troublesome task of searching for the character or item to be presented as a return to the first player. Therefore, it is possible to give a return gift to the other party who has received the present easily and quickly, without the need for conventional labor.

  As described above, with this configuration, the present is less likely to be left unreturned and contributes to intimate communication between players.

  (11) In any one of the constitutions (1) to (9), the extraction means is stored in the possession information storage means in response to a return candidate request from the terminal device of the second player. It is preferable to extract a return candidate for presenting to the first player from those owned by the second player.

  According to this configuration, when the second player wants to confirm the return candidate, the extraction unit performs a predetermined operation on the terminal device, so that the extraction unit can respond to the return candidate request transmitted from the terminal device of the second player. Perform return candidate extraction processing. Then, the extracted return reward candidates are transmitted to the terminal device of the second player by the return candidate transmission means. As a result, if the player wants to return to the other party who received the present, and operates the terminal device, the candidate for return will be presented on the terminal device. Can give presents.

  (12) A game management method according to another aspect of the present invention communicates with a terminal device of each player, and manages a game that allows the player to present what the player owns in the game to other players. A game management method in a game management device, in which the game management device stores a possession information storage step for storing what each player owns, and presents a first player to a second player who is another player When the game management device is performed, the game management device extracts a return reward candidate for presenting to the first player as a return from among those owned by the second player stored in the ownership information storage step. And extracting information for causing the game management device to display the return reward candidates extracted in the extraction step. And in return candidate transmission step of transmitting to the Ya of the terminal device, an Configurations which comprises a.

  (13) A program according to still another aspect of the present invention is a program for causing a computer to operate as the game management device having any one of the above-described configurations (1) to (11). It is a program for making it function as each means with which a management device is provided.

  According to the present invention, it is possible to provide a player with an environment in which a return gift can be given to a partner who has received a present simply and quickly without requiring a conventional effort.

It is explanatory drawing which shows the structural example of the game system which concerns on one embodiment of this invention. It is a block diagram which shows an example of the hardware constitutions of a game management apparatus. It is a block diagram which shows an example of the hardware constitutions of a terminal device. It is a functional block diagram which shows an example of a functional structure of a game management apparatus. It is a functional block diagram which shows an example of a functional structure of a game information management means. It is a functional block diagram which shows an example of a functional structure of an alternating current means. It is explanatory drawing which shows an example of the game information which a game information management means preserve | saves and manages in a database server. It is explanatory drawing which shows an example of the fellow information which a fellow information storage means memorize | stores. It is explanatory drawing which shows an example of the information regarding the friend of each player which a friend information storage part memorize | stores. It is explanatory drawing which shows the other example of the information regarding the friend of each player which a friend information storage part memorize | stores. It is explanatory drawing which shows an example of the received message information which a message memory | storage part memorize | stores. It is explanatory drawing which shows an example of a main screen. It is explanatory drawing which shows an example of a buddy list screen. It is explanatory drawing which shows an example of a message input screen. It is explanatory drawing which shows an example of a present selection screen. It is explanatory drawing explaining an example of the change of the information of the side which gave a gift memorize | stored in an owned player card memory | storage means. It is explanatory drawing explaining an example of the change of the information by the side of the present which a possession player card memory | storage means memorize | stores. It is explanatory drawing which shows an example of the unreceived present information which an unreceived present storage means memorize | stores. It is explanatory drawing which shows an example of a present list screen. It is explanatory drawing which shows an example of the game screen in battle | competition mode. It is explanatory drawing which shows an example of a helper selection screen. It is explanatory drawing which shows the other example of the game screen in battle | competition mode. It is explanatory drawing which shows an example of the screen after gift reception. It is explanatory drawing which shows an example of a return gift operation screen. It is explanatory drawing which shows an example of the present list screen in case the possession number of a player card has reached the upper limit. It is explanatory drawing which shows an example of the present list screen when the number of possession of a player card has not reached the upper limit. It is a flowchart which shows an example of operation | movement of a game system. It is a flowchart which shows an example of a game progress process. It is a flowchart which shows an example of the process which presents a return candidate. It is a flowchart which shows an example of the process which presents a return candidate. It is a flowchart which shows an example of the process which presents a return candidate. It is a flowchart which shows an example of a return candidate extraction process. It is a functional block diagram which shows the other example of a functional structure of a game management apparatus. It is explanatory drawing which shows an example of the information which a holding | maintenance information storage means memorize | stores. It is explanatory drawing which shows an example of the unreturned history which a non-returned history storage means memorize | stores. It is a functional block diagram which shows the other example of a functional structure of a game management apparatus. It is explanatory drawing which shows an example of the history information which a history information storage means memorize | stores. It is explanatory drawing which shows an example of a remind screen. It is a flowchart which shows an example of a remind process. It is a flowchart which shows an example of a remind determination process. It is a flowchart which shows an example of the cancellation | release process of a remind setting. It is explanatory drawing which shows an example of the present history memorize | stored by a present history memory | storage means. It is a flowchart which shows an example of a return determination process. It is explanatory drawing which shows the other example of the present history memorize | stored by a present history memory | storage means. It is a flowchart which shows the other example of a return determination process. It is explanatory drawing which shows an example of the memory information which integrated the present history which a present history memory | storage means memorize | stores, and the history information which a history information memory | storage means memorize | stores. It is explanatory drawing which shows an example of the information which a closeness memory | storage means memorize | stores. It is explanatory drawing which shows an example of the reminding screen in case there are a plurality of returnees. It is a functional block diagram which shows the other example of a functional structure of a game management apparatus. It is explanatory drawing which shows the other example of a remind screen. It is a flowchart which shows the other example of a remind process. It is explanatory drawing which shows an example of an unreturned list screen. It is explanatory drawing which shows the other example of a remind screen. It is explanatory drawing which shows an example of the remind process which shows a return candidate to a player simultaneously with a remind.

  Hereinafter, a game management device, a game management method, and a program according to an embodiment of the present invention will be described with reference to the drawings.

[Outline of the game system]
FIG. 1 shows a configuration example of a game system in which a game management device according to an embodiment of the present invention is incorporated. As shown in the figure, this game system includes a game server 1 installed on a network 4 such as the Internet, a database server 2 connected to be communicable with the game server 1, and a game server via the network 4. 1 and the terminal device 3 of each player that can be communicably connected.

  The network 4 of the present embodiment is not limited to the Internet. For example, a dedicated line, a public network, or the like can be used as long as the game server 1 and the terminal device 3 of each player can be connected to each other. It may be a line (telephone line, mobile communication line, etc.), wired LAN (Local Area Network), wireless LAN, or the like, or a combination of the Internet and these.

  In this example of the game system, a game management device according to an embodiment of the present invention includes a game server 1 and a database server 2. The game server 1 receives access from the terminal device 3 of each player who receives the game service via the network 4 and stores and manages game information of each player in the database server 2 (storage device). A game service is provided via the network 4.

  In the present embodiment, an example of providing a so-called browser game in which a game can be played by a web browser installed in the terminal device 3 of each player will be described as one form of game service provided by the game server 1. In the service form for providing the browser game, it is not necessary to download or install software dedicated to the game to the terminal device 3 of the player, and the player can easily play the game server anywhere as long as the terminal device 3 can be connected to the network 4. The game service provided from 1 can be enjoyed.

  In this game system, a program (application software) for a browser game is installed in the game server 1, and the game server 1 performs arithmetic processing and data for progressing the game in accordance with an input operation on the terminal device 3 of each player. Execute the process. Then, the game server 1 updates the game information of each player in the database server 2 based on the execution result of the arithmetic processing and the like, and web page information for displaying the execution result on the screen of the terminal device 3 of the player. (Game screen data) is transmitted to the terminal device 3 of each player.

  The terminal device 3 of each player is equipped with a web browser having a website browsing function as a player agent so that the web page information transmitted from the game server 1 can be displayed on the screen of the terminal device 3. It has become. Examples of the terminal device 3 include a mobile phone terminal, a PHS (Personal Handy-phone System) terminal, a personal digital assistant (PDA), and a smartphone that is a mobile terminal in which a mobile phone and a mobile information terminal are integrated. Various terminals that can be connected to the game server 1 via the network 4 and receive a game service, such as a personal computer or a tablet computer, can be applied.

  In addition, the game provided in this embodiment has a so-called social game element that allows a player to play while interacting with other players who are receiving game services. For example, by incorporating the game server 1 and the database server 2 of the present embodiment into a social networking service (SNS) system, a game system that provides a social game service as one of the SNS services can be obtained. As described above, the game service can be provided to the player by the game system operating on the SNS platform, but the game server 1 and the database server 2 can be constructed as independent game systems without being incorporated in the SNS system. Good.

  In this game system, each player can establish a special relationship of “friends” with one or more other players who are receiving game services. As one form for a certain player to establish a friendship relationship with another player, either one of the two players makes a friend application to the other player via the game server 1, and the friend application is made. A friend application made between the two players and an operation of the approval for approving that the received player becomes a friend through the game server 1 can be mentioned.

  Each player can enjoy various exchanges with fellow players, including exchange of presents in the game. The game server 1 according to the present embodiment allows the second player to automatically or in response to a manual operation of the second player when a present is given from the first player to the second player. It has a characteristic configuration in which return candidates are extracted from owned characters and items and presented to the terminal device 3 of the second player.

  This characteristic configuration of the present embodiment eliminates the need for the second player to perform a laborious and troublesome task of searching for a character or item to be presented as a return to the first player. Accordingly, it is possible to provide the player with an environment in which a return gift can be given to a partner who has received a present easily and quickly without requiring a conventional effort. Below, the detail of a structure of the game management apparatus (game server 1 grade | etc.,) Which concerns on this Embodiment which can provide such a game environment is demonstrated. In addition, although all the players can be either the side which gives a present or the side which is given, in the following description, the side which gave the present is the first player and the side which is given the present (the first player) (Returned to the side) is conceptually distinguished as the second player. In addition, when a player having a specific player ID is indicated, a symbol for specifying the player, such as player A and player B, is attached.

[Configuration of game management device]
As described above, in the present embodiment, the game management device includes the game server 1 and the database server 2. FIG. 2 shows an example of the hardware configuration of the game server 1. As shown in the figure, the game server 1 mainly includes a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12 and a RAM (Random Access Memory) 13 as a main storage device, and an auxiliary storage device 14. The communication control unit 15 and the input / output control unit 16 are connected to each other via a bus line 17 including an address bus, a data bus, a control bus, and the like. Note that an interface circuit is interposed between the bus line 17 and each component as necessary, but the illustration of the interface circuit is omitted here.

  The CPU 11 interprets and executes instructions of application software such as system software and game programs, and controls the game server 1 as a whole. The ROM 12 stores a program and the like necessary for basic operation control of the game management device 1. The RAM 13 stores various programs and data, and secures a work area for the CPU 11.

  The auxiliary storage device 14 is a storage device that stores application software such as a game program, various data, and the like. For example, a hard disk drive can be used as the auxiliary storage device 14. The program according to the present embodiment for causing the game server 1 (computer) to operate as a game management device is also stored in the auxiliary storage device 14, and the program is transferred from the auxiliary storage device 14 to the bus line when the game server 1 is started. 17 is loaded into the RAM 13 via the CPU 17 and executed by the CPU 11.

  The communication control unit 15 includes a communication interface 15 a connected to the network 4, and controls communication with each player's terminal device 3 via the network 4. The communication control unit 15 also controls communication with a server (not shown) connected to the network 4. For example, when it is set as the system configuration which incorporated the game server 1 in SNS, the communication control part 15 of the game server 1 controls communication between SNS servers.

  The input / output control unit 16 is connected to the database server 2 in a communicable manner, and is a database interface that performs input / output control when the CPU 11 executes reading / writing of data (records) with respect to the database server 2.

  The database server 2 includes a large-capacity hard disk device having a RAID (Redundant Arrays of Inexpensive Disks) configuration, for example, as a storage device having an area for storing game information of each player managed by the game server 1. The database server 2 stores, for example, various game information (player name, level, in-game points, possessed items, etc.) of each player in association with identification information (player ID) that uniquely identifies each player. It can be constructed as a database, an object database, an object relational database, or the like.

  In the present embodiment, an example in which the game management device is configured by the game server 1 and the database server 2 is shown, but the present invention is not limited to this. For example, the game server 1 can have the function of the database server 2 and the game management device can be configured only by the game server 1. Further, the game server 1 can be configured as a plurality of servers by distributing the functions of the game server 1 to a plurality of servers. For example, when a player operates the terminal device 3 to access the game server 1, an authentication server having an authentication function for determining whether the player is a regular player is provided separately from the main server of the game server 1, The game server 1 may be composed of a main server and an authentication server. As another configuration example, a billing management server that performs billing management when a player purchases an item to be billed in a game is provided separately from the main server of the game server 1, and the main server, authentication server, and billing management The game server 1 may be configured by a server.

  In addition, when the number of players using this game service reaches several hundred thousand, millions, or more, it is required to construct a server system that can withstand huge accesses from the terminal device 3 of many players. Therefore, by providing a plurality of game servers 1 on the network 4 for redundancy (multiplexing), a load distribution type system configuration may be adopted. In this case, it is desirable to provide a load balancer for adjusting the load among the plurality of game servers 1.

  Next, the configuration of the terminal device 3 of the player who accesses the game server 1 according to the present embodiment and receives a game service will be described.

[Configuration of terminal device]
As the terminal device 3 operated by the player, various terminals having a website browsing function such as a mobile phone terminal and a smartphone can be applied as described above. In the present embodiment, a mobile phone terminal is exemplified. The configuration will be described. Note that the terminal device 3 other than the mobile phone terminal is also basically required for playing a game such as displaying a game screen using a website browsing function or performing an input operation for executing the game. The configuration is the same as that of the mobile phone terminal.

  A mobile phone terminal having a website browsing function or the like is also called a feature phone or a smart phone, and FIG. 3 shows an example of its configuration. As shown in the figure, the terminal device 3 mainly includes a CPU 31, a ROM 32 and a RAM 33 as main storage devices, an image processing unit 34, a display unit 35, a sound processing unit 36, and an audio input unit 37. , An audio output unit 38, an auxiliary storage device 39, an operation input unit 40, and a communication control unit 41. The components 31 to 34, 36 and 39 to 41 are connected to each other via a bus line 42. Has been. An interface circuit is interposed between the bus line 42 and each component as necessary, but the interface circuit is not shown here.

  The CPU 31 interprets and executes instructions of various programs including the web browser, and controls the entire terminal device 3. The ROM 32 stores a program and the like necessary for basic operation control of the terminal device 3. The RAM 33 stores various programs and data loaded from the ROM 32 or the auxiliary storage device 39, and secures a work area for the CPU 31. A web browser that displays game screen data described in HTML or the like is stored in the ROM 32 or the auxiliary storage device 39, loaded into the RAM 33, and executed by the CPU 31. Various plug-in software for extending the browser function of the web browser may be stored in the ROM 32 or the auxiliary storage device 39 together with the web browser.

  The image processing unit 34 drives the display unit 35 based on an image display command from the CPU 31 and displays an image on the screen of the display unit 35. Various known display devices such as a liquid crystal display organic LE (Electro-Luminescence) display can be applied to the display unit 35.

  The sound processing unit 36 converts an analog audio signal into a digital audio signal when audio is input from the audio input unit 37, generates an analog audio signal based on a sound generation instruction from the CPU 31, and outputs it to the audio output unit 38. Output. The voice input unit 37 includes a microphone built in the terminal device 3 and is used for telephone communication or recording. The voice output unit 38 is composed of a speaker that outputs a reception speaker at the time of telephone communication and a telephone ringtone or a sound effect at the time of game execution.

  The auxiliary storage device 39 is a storage device that stores various programs and data. As the auxiliary storage device 39, for example, a flash memory drive or a hard disk drive can be used as the internal memory of the mobile phone terminal, and a memory card reader / writer or the like can be used as the external memory of the mobile phone terminal. .

  The operation input unit 40 receives an operation input from the player and outputs an input signal corresponding to the operation input to the CPU 31 via the bus line 42. Examples of the operation input unit 40 include physical buttons such as a direction instruction button, a determination button, and an alphanumeric character input button provided on the main body of the terminal device 3. Further, in the case of the terminal device 3 in which the display unit 35 is configured as a so-called touch screen by mounting a touch panel (contact input type interface) on the screen of the display unit 35, the touch panel also becomes the operation input unit 40.

  The communication control unit 41 includes a communication interface 41a, and has a communication control function for performing data communication during game operation and the like, a communication control function for transmitting and receiving voice data as a mobile phone terminal, and the like. Here, for the communication control function for data communication, for example, a wireless LAN connection function, an Internet connection function via a wireless LAN or a cellular phone network, a predetermined frequency band (for example, a 2.4 GHz frequency band) is used. Includes short-range wireless communication functions. The communication control unit 41 transmits a connection signal for connecting the game apparatus 1 to a wireless LAN, the Internet, or the like based on a command from the CPU 31 and receives information transmitted from the communication partner side and supplies it to the CPU 31. To do.

  In addition, the terminal device 3 may include a GPS (Global Positioning System) signal receiving circuit, an imaging device (camera) such as a CCD (Charge Coupled Device) image sensor, a triaxial acceleration sensor, and the like. For example, GPS position information may be used in the game.

  In the terminal device 3 configured as described above, a player who wants to receive a game service performs an operation of starting a web browser and accessing a game site managed by the game server 1. When this access is authenticated by the game server 1, the communication control unit 41 of the terminal device 3 receives game screen data described in HTML or the like transmitted from the game server 1, and the CPU 31 executes the web browser. A game screen is displayed on the display unit 35. Here, the player selects and inputs selectable button objects and hyperlinks displayed on the game screen by operating the operation input unit 40. In response to this selection input, the game server 1 advances the game and transmits new game screen data to the terminal device 3. Then, this new game screen is displayed on the display unit 35 of the terminal device 3, and hereinafter, similarly, the player can select a button object or the like that can be selected on the game screen displayed on the display unit 35 by an operation. A game provided by the game server 1 can be played.

[Functional configuration of game management device]
Next, main functions of the game management device (game server 1 and database server 2) configured as described above will be described. FIG. 4 is a main functional block diagram of the game management device.

  The game management apparatus mainly includes game information management means 51, game progress means 52, authentication means 53, friend management means 54, AC means 55, extraction means 56, and return candidate transmission means 57. Each of these means 51 to 57 is realized by the CPU 11 of the game server 1 executing the program according to the present embodiment.

  The game information management means 51 accumulates and manages game information of each player in the database server 2. The item of game information managed by the game information management means 51 differs depending on the content of the game service that the game server 1 provides to the player.

  Examples of games provided by the game server 1 include sports games based on various sports such as baseball, soccer, and golf, battle games based on battles, music simulation games, and other various role-playing games and training. Various games such as games and simulation games can be listed regardless of the game format and genre. As an example, in the present embodiment, the case where the game server 1 provides a baseball game as a game service will be described below.

  In the present embodiment, a baseball game in which a player owns a player character in the game and can play a game (match) with another player in the game using the player character is taken as an example. The player character possessed by the player can be in a card format in which the form of the player character is visible on the screen of the terminal device 3. That is, the player character is managed as a digital player card by the game server 1 and displayed on the screen of the terminal device 3 of the player. FIG. 12 illustrates a player card 71 displayed on the screen of the terminal device 3 of the player. The player card 71 is displayed on the screen as a digital player card in which the form of the player character and the rare degree (rare value) of the card are written. Is displayed. In the example of FIG. 12, the degree of rareness is shown in a visually easy-to-understand manner with a large number of ☆ (for example, the number of ☆ is increased as the degree of rareness is higher). Players can collect player cards while advancing the game, form their own original team, and compete against other players for ranking. In addition, the player can improve the ability of the player card (character) by synthesizing the collected player cards (that is, nurture the character), and can enjoy the game with the aim of creating a stronger team. It is like that.

  In such a baseball game, the game information management means 51 for managing game information of each player includes possession information storage means 511 for storing what each player owns. FIG. 5 shows a detailed configuration example of the game information management means 51. As shown in FIG. 5, the game information management means 51 includes player information storage means 51a, level information storage means 51b, ownership information storage means 511 (owned player card storage means 51c, possession point storage means 51d, owned coin storage means 51e. Possessed item storage means 51f), game result storage means 51g, ranking storage means 51h, desired storage means 51i, player attribute storage means 51j, and the like. FIG. 7 shows an example of the game information of each player (in this example, one player ID = “000001”) stored and managed in the database server 2 by the storage means 51a to 51j of the game information management means 51. Game information).

  The player information storage unit 51a associates a player ID uniquely identifying each player with player information relating to each player such as a login ID, password, player name (nickname used in the game, etc.), team name, and the like. Each ID is stored in a predetermined storage area of the database server 2. Here, the login ID and the password are used for login authentication when each player accesses the game server 1 by operating the terminal device 3. The player name and the team name are arbitrary information set by the player when the player registers as a member for receiving the game service or when the game is executed for the first time. The player name and team name are displayed on the game screen as necessary.

  The level information storage unit 51b stores the level information such as the player level as the game level and the affiliation league level in a predetermined storage area of the database server 2 for each player ID in association with the player ID. In the baseball game, for example, experience values are accumulated as the player advances the game, and the level of the player is increased when the experience value reaches a certain amount. In this baseball game, for example, there are a plurality of different levels of leagues, and each player's team belongs to one of the leagues, and a game (league battle) is automatically played with another player's team in the league. To do. Further, according to the result of this league game, a replacement game between teams of players belonging to different leagues is automatically executed, and the league level to which the team of players belongs is changed. The level information storage means 51b stores the player level and the league level in association with the player ID.

  The owned player card storage means 51c stores information on player cards (characters) acquired and owned by the player in the game in a predetermined storage area of the database server 2 for each player ID in association with the player ID. To do. Examples of the player card information include identification information (player card ID) for uniquely identifying the player card, an ability value indicating the height of the ability of the player, and a regular player flag.

  In FIG. 7, the example which can set a player's ability value with respect to three ability items (abilities 1-3) is shown. As an example of the ability item, when the player card is a fielder, the abilities 1 to 3 can be “blow”, “running power”, “defense”, etc., and when the player card is a pitcher, ability 1 ˜3 can be set as “sphere force”, “ball control”, “change”, and the like. The capability item is not limited to this example, and can be increased or decreased. The regular player flag is a regular player (player included in the team order) who participates in a match with another player's team among the player cards owned by the player, or a non-regular player other than the regular player This flag is “1”, indicating that it is registered as a player card for a regular player. By operating the terminal device 3, the player can select a regular player from an owned player card or set a team order.

  Further, the database server 2 is associated with the player card ID, and the player card image data, player name, position, team (team attribute), ability value (initial value not strengthened by synthesis), and There is a player card database in which rareness is stored. And the game information management means 51 can acquire the image data etc. of the player card corresponding to the said player card ID from the player card database based on the player card ID stored in the owned player card storage means 51c. ing.

  In this embodiment, there is an upper limit on the number of player cards that each player can own in the game, and the game information management means 51 has an upper limit on the number of player cards held by each player. It is managed not to exceed. The upper limit of the number of player cards held can be arbitrarily set, such as 30, 60, 100, for example. In the present embodiment, the upper limit of the number of player cards held is set to 60.

  The owned point storage unit 51d stores various points (including values corresponding to points) acquired and owned by the player in the game in association with the player ID for each player ID. Store in the area. In this game, there are various game modes, and various points can be acquired and the acquired points can be used according to the game mode.

  As shown in FIG. 7, examples of points include behavioral power points, operating costs, reinforcement points, and exchange points in addition to the above experience values. The action power point is used in a “scout mode” in which the player card is searched and the player is scouted while consuming the action power point. The management cost is used in a “match mode” in which another player is designated to play an individual match, and the individual match is performed at a cost (point) necessary for managing the match. It is consumed by. For example, behavioral power points and operating costs consumed and reduced during the game are recovered over time (for example, 1 point is recovered every 3 minutes), or the experience value is set to a certain amount. And the player's level can be increased to recover.

  The strengthening points are used in the “strengthening mode” in which the ability of the player cards is improved by combining the player cards owned by the players, and is consumed by performing the combining. This strengthening point can be acquired, for example, by executing a scout mode or a match mode.

  Further, the exchange points are points that can be obtained when the player exchanges greetings with other players (particularly fellow players), and is given by the point granting unit 56. Details of specific examples of AC will be described later. This exchange point can be used in, for example, “lottery mode” in which a predetermined number (for example, one) of player cards can be obtained by lottery based on random numbers or the like from all player cards managed by the game server 1. A player card lottery can be received once for a predetermined exchange point.

  The owned coin storage means 51e associates coins owned by the player in the game (in-game currency different from the points) in a predetermined storage area of the database server 2 for each player ID in association with the player ID. Remember. This coin is necessary, for example, when acquiring an item to be charged.

  The owned item storage means 51f stores the item obtained by the player in the game in a predetermined storage area of the database server 2 for each player ID in association with the player ID. As shown in FIG. 7, examples of items include recovery items, puzzle card pieces, fake cards, and the like. The recovery item is an item that recovers the above-described action power points and / or operation costs consumed and reduced during the game to the maximum value in an instant without waiting for the passage of time. For example, the recovery item can be acquired by consuming and purchasing the coin or satisfying a predetermined bonus condition in the game.

  The pieces of the puzzle card are items that can obtain a powerful (high ability value) player card by collecting a predetermined number of pieces (for example, six pieces P1 to P6) and completing the puzzle card. . For example, a piece of a puzzle card can be obtained when winning in a lottery based on a random number or the like during the execution of the scout mode, and when winning by fighting against a piece owned by another player in the game mode In addition, it can be taken from the opponent player.

  A fake card is an item that can be set to a piece of the puzzle card so that even if it is defeated by another player in a match in the match mode, the targeted piece cannot be taken once. For example, a fake card can be obtained by consuming and purchasing the coin or satisfying a predetermined bonus condition in the game.

  Note that the items that the player can acquire and possess in the game are not limited to these, for example, treasure items that can be acquired when winning a battle, equipment for characters such as weapons and armor, It may be possible to own magic items, special items, and various other items that generate various effects and effects.

  The game result storage means 51g associates a player ID with a game ID for uniquely identifying a game in which a player's team has played against another player's team, and a predetermined storage area of the database server 2 for each player ID. To remember. Here, the game uniquely specified by the game ID includes a game of an individual game performed by the player specifying an opponent and a game of a league game automatically performed by the game server 1.

  In addition, the database server 2 is associated with the game ID, the game date and time (the time when the real world game starts or ends), the player ID of the winning team, the player ID of the defeated team, the battle score, the winning pitcher character, A game database is stored in which information about game results such as a loser pitcher character, a player character who has made a home run, and game critical information is stored. And the game information management means 51 can acquire the information regarding the game result corresponding to the said game ID from a game database based on the game ID which the game result storage means 51g has memorize | stored.

  The ranking storage means 51h associates the player ID with ranking information such as the number of wins and losses of the team of the player in the league game or the exchange game, and the ranking within the league to which the player belongs based on the number of wins and losses. Each ID is stored in a predetermined storage area of the database server 2. For example, a league game is automatically performed at a predetermined time on each day from Monday to Friday in the real world (for example, 12 games per day), and a replacement game is performed at a predetermined time on Saturday and Sunday in the real world. It is assumed that a predetermined number of games (for example, 12 games each day) are automatically played. In this case, as shown in FIG. 7, the ranking storage unit 51h stores the ranking information for each day from Monday to Sunday in the real world, and updates the ranking information to the latest information every week.

  Next, the desired storage means 51i shown in FIG. 5 will be described. Each player can register what he / she wants (what he / she wants with a character or item that the player can own) by operating his / her terminal device 3. The desired storage means 51i stores what the player wants in the database server 2 (storage device) in response to a desired registration request from a terminal device operated by each player. That is, as shown in FIG. 7, the desired storage means 51i associates with the player ID of the player and stores the player card ID and character ID requested to be registered as desired by the player in the database server 2. Store in the area. What a player wants to register can be confirmed by another player by browsing a page displaying information about the player. The information stored in the desired storage means 51i is used in extraction processing of return candidates by the extraction means 56 described later.

  Next, the player attribute storage unit 51j shown in FIG. 5 will be described. Each player can register a desired attribute, which is any one of a plurality of attributes, by operating his / her terminal device 3. In the present embodiment, each player has a desired one of a plurality of team attributes (for example, attributes of 12 types of teams corresponding to 12 professional Japanese baseball teams in the real world). You can register attributes. For example, when the player plays a game for the first time, the attributes of the team he desires can be registered. In response to an attribute registration request from the terminal device 3 operated by each player, the player attribute storage unit 51j stores the attribute desired by each player in the database server 2 (storage device). That is, as shown in FIG. 7, the player attribute storage unit 51j stores the team attribute desired by the player in a predetermined storage area of the database server 2 in association with the player ID of the player.

  Also, any one of the attributes of the plurality of teams is set in the player card that each player can own in the game. And the information memorize | stored in the player attribute memory | storage means 51j is used in the case of the extraction process of the return candidate by the extraction means 56 mentioned later.

  In this embodiment, since it is a baseball game based on baseball, an example is shown in which team attributes are set for each player and each player card. However, other attributes are set. It may be. For example, the A attribute (A attribute is compatible with the B attribute but not compatible with the C attribute), the B attribute (B attribute is compatible with the C attribute but not compatible with the A attribute), the C attribute (C attribute is There are three types of attributes, which are compatible with the A attribute but not compatible with the B attribute), and any one of the three types of attributes is set for each player and each character (or item, etc.). You may do it.

  Next, the game progress means 52 shown in FIG. 4 will be described. The game progress means 52 executes a game in response to an operation on the terminal device 3 by the player, generates game screen data corresponding to the execution result, and transmits the game screen data to the terminal device 3. It has a function to advance the game by displaying a game screen according to the game. As shown in FIG. 4, the game progress means 52 includes a game execution means 52a, a game screen generation means 52b, and a game screen transmission means 52c.

  When the game screen is displayed by the web browser of the terminal device 3 of the player, when the player performs an operation of selecting a selectable button object, a character string set with a hyperlink, or the like on the game screen, the operation A game screen request corresponding to the request is transmitted to the game server 1 by the web browser of the terminal device 3. In the game server 1 that has received this request, the game execution means 52a reads the game information of the player in response to the request and executes the game by performing calculations and data processing.

  For example, taking as an example a case where the player has performed an operation of playing against a team of another player in the battle mode, the game execution means 52a has the player cards of both teams corresponding to the player IDs of both players in the battle. Information (player card information of regular players participating in the game) is read from the database server 2. And the game execution means 52a performs the calculation which determines a win / loss based on the ability value etc. of the player card of both teams. As an example of the calculation of this win / loss decision, the player with the highest total ability value of both teams may be the winning team, or the team with the higher total ability value will have a higher probability of winning. The winning team may be obtained by probability calculation. In addition, the game execution means 52a decides whether or not to generate various effect effects that affect the win / loss based on the combination of the player cards constituting the team before the calculation for determining the win / loss. You may perform the operation to do.

  The game screen generation unit 52b generates game screen data composed of, for example, HTML data in accordance with the execution result by the game execution unit 52a. The HTML data may include image data such as a player card read from the database server 2. Moreover, the script (program) which operate | moves by the plug-in of the web browser of the terminal device 3 may be embedded in HTML data. When the script provided from the game server 1 is executed by the terminal device 3, the game screen displayed on the terminal device 3 can be a moving image.

  The game screen transmission unit 52c transmits the game screen data (HTML data or the like) generated by the game screen generation unit 52b to the terminal device 3 of the player as a response to the game screen request. In the terminal device 3 of the player that has received the game screen data, the game screen is displayed on the display unit 35 by the web browser.

  Next, the authentication unit 53 will be described. When a player who wants to receive a game service operates the terminal device 3 to access (log in) the game server 1, the authentication means 53 determines whether or not the player has a game participation qualification and performs login authentication. . As an example of this authentication, there is authentication based on a login ID and a password associated with a player ID. For example, when a player uses the game service for the first time, a login ID (any alphanumeric character, mail address, etc.) and a password are registered in the game server 1 as member information. Then, at the next login to the game server 1, the player operates the terminal device 3 to transmit the login ID and password to the game server 1. At this time, the authentication means 53 of the game server 1 determines whether or not the combination of the login ID and password received from the terminal device 3 of the player has been registered, and performs login authentication.

  When the game system is incorporated into the SNS system, the SNS member registration information (login ID and password) may be used as the registration information for receiving the game service of the game system. For example, when the player's terminal device 3 is logged in to the SNS server, when the game site managed by the game server 1 is first accessed, the player's login ID and password are automatically input from the SNS server to the game server 1. The game service may be registered for use without registering the login ID and password again.

  In addition, an individual identification number of a mobile phone or a smartphone that is the terminal device 3 (a terminal different from the telephone number is uniquely assigned so that the trouble of inputting the login ID and password each time the player accesses the game server 1 can be omitted. Identification information) or contractor's unique ID (information that uniquely identifies the contractor of the terminal and does not change as long as the contractor is the same even if the model is changed) Authentication may be performed. That is, when the player operates the terminal device 3 to register as a member, the game server 1 acquires the individual identification number or the contractor unique ID included in the data transmitted from the terminal device 3, and the login ID and password At the same time, the individual identification number or the contractor unique ID is also stored in the database server 2 in association with the player ID. When receiving the access request from the terminal device 3, the authentication unit 53 determines whether the individual identification number or the contractor unique ID has been registered, and performs login authentication. Thereby, when accessing the game server 1, the player can log in without inputting the login ID and password.

  In addition, as another method that can omit the trouble of inputting the login ID and the password each time the player accesses the game server 1, there is a method of using HTTP cookie information (hereinafter referred to as cookie). That is, when the player operates the terminal device 3 to register as a member, the game server 1 issues individual identification information corresponding to the login ID and password and registers it in the database server 2, and the individual identification information is used as a cookie. It transmits to the terminal device 3. At this time, the browser of the terminal device 3 stores the received cookie in the terminal device 3. When accessing the game server 1 from the next time, the browser of the terminal device 3 transmits a Cookie to the game server 1 together with the page browsing request, so that the authentication unit 53 receives the access request from the terminal device 3. Can perform login authentication by determining whether or not the individual identification information of the cookie has been registered.

  Next, the fellow management means 54 will be described. The fellow management means 54 is provided with fellow information storage means 54a for storing fellow information related to two players in which fellow relations are established in the database server 2 (storage device). FIG. 8 shows an example of friend information stored in the database server 2 by the friend information storage means 54a.

  As shown in FIG. 8, when the fellowship relationship is established between two players, the fellow information storage means 54a obtains the player ID of the player who applied for fellowship and the player ID of the player who approved the fellowship application. The related friend information is stored in the database server 2. And the fellow management means 54 adds fellow information ID for identifying these uniquely to each fellow information, and performs fellow management based on fellow information ID.

  In the example of FIG. 8, the fellow information relating the two players, the player A with the player ID = “000001” who applied for the fellow and the player B with the player ID = “000002” who approved it, is the fellow information ID. = Registered in the database server 2 as friend information of “1”. Thus, for player A, player B is a fellow player who has a fellow relationship, and for player B, player A is a fellow player.

  In addition, each player can create a plurality of friends, and a friend group centered on each player can be formed. In the example of FIG. 8, the player A with the player ID = “000001” has established a fellowship relationship with the players with the player IDs = “000005” and “000003”. And the fellow management means 54 memorize | stores in the database server 2 the information of the fellow player in the fellow relation which belongs to the fellow group centering on each player, and performs the fellow management for every player.

  FIG. 9A shows an example of information related to the friends of each player, which is managed by the friend management means 54 based on the friend information stored in the database server 2. The associate information storage means 54a of the associate management means 54 is associated with the player ID, information on the upper limit of the number of associates, the player ID of the associate player who is already in the associate relationship, the player ID of the player who is applying for the associate, and Information relating to a friend such as a player ID of an unapproved player who has received a friend application is stored in a predetermined storage area of the database server 2 for each player ID. In the example of FIG. 9A, information on a friend for one player with player ID = “000001” is shown, the upper limit of the number of friends is 45, the number of fellow players of the player is 10, and friends are being applied for. One player has received a friend application, but there are no unapproved players.

  In the baseball game of the present embodiment, bonus points are awarded to both players who have become friends by creating friends (for example, the maximum value of the action power points and the operating cost may be increased by a predetermined point). it can). Moreover, it is the game specification which can advance a game advantageously by playing a game in cooperation with a fellow player, or performing a present or cheering of a player card between friends. Thus, by giving the player the advantage of creating a friend in the game, the creation of the friend is promoted.

  However, an upper limit can be set for the number of friends that each player can establish a friendship with other players. As the upper limit of the number of friends, one upper limit (for example, 50 people) common to each player can be provided. Alternatively, the upper limit of the number of friends may vary within a predetermined range (for example, a range of 10 to 99 people) according to the degree of progress of each player's game. In the present embodiment, the upper limit of the number of friends varies in the range of 10 to 99, and the upper limit of the number of friends increases as the level of the player increases. Thereby, in order to make more friends and make the game advantageous, the player is given a motivation to continuously advance the game and improve the level. The fellow information storage means 54a stores the upper limit of the number of friends of each player in association with the player ID, and the fellow management means 54 manages the upper limit of the number of friends of each player.

  In the present embodiment, in order for two players to become friends, either one of both players makes a friend application to the other player via the game server 1. As an operation example of this friend application, first, a player who wants to make a friend performs an operation of listing target candidates of friend candidates on the screen of the terminal device 3. At this time, the player can specify the player level of the fellow candidate. In response to the operation by the player, the game server 1 transmits screen data listing the candidates for the fellow candidates, so that a screen on which a plurality of fellow candidates are listed is displayed on the terminal device 3 of the player. Here, the player confirms the player level, the league level, and the like of the target person listed on the screen, selects a player who wants to be a friend, and performs a friend application operation.

  For example, consider a case where a player A with a player ID = “000001” performs a friend application operation on a player B with a player ID = “000002”. As shown in FIG. 9A, in response to this operation, the fellow information storage means 54a of the game server 1 corresponds to the player ID = “000001” of the player A as the game information of the player A who has made the fellow application. In addition, the player ID = “000002” of the player B who is the applicant is stored as the “player ID being applied”.

  Further, as shown in FIG. 10 (a), the fellow information storage unit 54a makes a fellow application in association with the player ID of the player B = “000002” as the game information of the player B who is the applicant. The player ID of player A = “000001” is stored as “unapproved player ID”. Then, the game server 1 notifies the player A that a friend application has been made when the terminal device 3 of the player B logs in to the game server 1.

  Then, the player B who has received the friend application confirms the information such as the player level and the league level of the player A received from the game server 1 on the screen of the terminal device 3 and decides whether to approve or reject as a friend. Perform the operation to select. Here, when the player B performs an operation of approving as a friend, the friend management means 54 of the game server 1 establishes a friendship relationship between the player A and the player B in response to this operation, as shown in FIG. The friend information relating the player IDs of both players A and B is registered in the database server 2. Then, as shown in FIG. 9B, the fellow information storage unit 54a associates the player ID of the player A with “player ID =“ 000001 ”as the game information of the player A, and the player ID of the player B =“ 000002 ”. Is stored as “friend player ID”, and the player ID of player B is deleted from “player ID being applied”.

  Further, as shown in FIG. 10B, the fellow information storage unit 54a associates the player ID of the player B = “000002” with the player ID = “000001” of the player A as the “companion player ID”. The player ID of the player A is deleted from the “unapproved player ID”. Then, when the terminal device 3 of the player A logs in to the game server 1, the game server 1 notifies the player B that the friend has been approved.

  Next, the AC unit 55 will be described. The alternating current means 55 receives information for performing predetermined alternating current with other players (particularly fellow players) from the terminal device 3 of the player, and from the player to the other player based on the received information. It has a function to execute all AC processing. As shown in FIG. 6, the AC unit 55 of the present embodiment includes a greeting unit 55a, a message transmission unit 55b, a message storage unit 55c, a present unit 55d, a battle cooperation unit 55e, and the like.

  The greeting means 55a has a function of receiving greeting information addressed to another player transmitted from the terminal device 3 of each player and transmitting the greeting information to the other player. The message transmission means 55b has a function of receiving a message addressed to another player transmitted from the terminal device 3 of each player and transmitting the message to the other player. The message transmission unit 55b includes a message storage unit 55c.

  FIG. 11 shows an example of information related to a received message that is stored and managed in the database server 2 by the message storage unit 55c. The message storage unit 55c associates with the player ID of the receiving player who has received the message, information about the message such as the sending player ID, the message content, and the transmission date and time for each player ID of the receiving player. The data is stored in a predetermined storage area of the database server 2. Further, a message ID for uniquely identifying each message is added to the information regarding each message. In the example of FIG. 11, information about a received message for one receiving player with player ID = “000002” is shown, and the player receives “Thank you for the present!” From the player with player ID = “000001”, and the player ID. The message “Good morning! Let's do our best this week's event!” Is received from the player with “000038”, and the message “Thank you for this week!” From the player with the player ID = “000145”.

  Here, an example of an operation in which a player greets or sends a message to his / her fellow player will be described. For example, if the player operates the terminal device 3 and selects the “friend list” button in the main screen, the friend list request is transmitted from the terminal device 3 to the game server 1. The game server 1 receives this request from the terminal device 3 of the player and transmits information for displaying the buddy list of the player to the terminal device 3. Thereby, for example, a friend list screen as shown in FIG. On this buddy list screen, information of buddy players who are in a buddy relationship with the player is listed and displayed. Note that information about fellow players that cannot be displayed on the screen can be displayed as a separate screen by scrolling the screen or requesting the game server 1 for the second and subsequent pages of the peer list.

  In this friend list screen, an information display area for each friend player listed is provided. In each information display area, game information 81 of the friend player (player name, team name, player level, friend's level). The number of people, the league level, etc.), an avatar 82 which is a separate character of the player, a player card 83 of the leader owned by the player, and an object called a greeting button 84 are also displayed. Then, the player can virtually greet his fellow player in the game by selecting and operating this greeting button 84. For example, when the player A selects and operates the greeting button 84 of the fellow player B, greeting information is transmitted from the terminal device 3, and the greeting means 55 a that receives this greeting information is sent from the player A to the terminal device 3 of the fellow player B. Communicate that there was a greeting.

  The various buttons in the screen displayed on the terminal device 3 may be a character string or the like in which a hyperlink that enables the same operation as the button is set (the same applies in the following description).

  Here, greeting is a general term for simple exchanges that can be performed virtually in the game as described above. Sending ale (cheering), sending guts, winking, smiling, hands This includes simple exchanges using other expressions such as waving. The player can only greet the fellow player, but can also send a message at the same time as the greeting, as described below.

  When the greeting button 84 is selected by the player's operation on the terminal device 3, the operation is transmitted from the terminal device 3 to the game server 1. Thereafter, from the game server 1, for example, data on a message input screen illustrated in FIG. 14 is transmitted to the terminal device 3, and the message input screen is displayed on the terminal device 3. On this message input screen, for example, a text indicating that a greeting is given to a fellow player (player B in the example of FIG. 14) is displayed, and objects such as a message input area 85 and a send button 86 are also displayed. . Then, the player operates the terminal device 3 to input an arbitrary message in the message input area 85 and selects a transmission button 86, whereby a message addressed to the fellow player B is transmitted from the terminal device 3 to the game server 1. Is done. FIG. 14 shows an example in which the player inputs the message “Thank you for the present”. In consideration of the storage capacity in the database server 2, there may be a restriction (for example, within 30 full-width characters) on characters that can be input in the message input area 85.

  The message input screen displays a hyperlink 87 for transitioning to the page of the fellow player (player B in this example), and the details of the game information of the fellow player are described by selecting this link. Displayed pages. In addition, a hyperlink 88 for transitioning to the buddy list and a hyperlink 89 for transitioning to the main screen are also displayed on the message input screen. By selecting these links, a buddy list or main screen is displayed. You can come back.

  When a message is transmitted from the terminal device 3 by the player's operation on this message input screen, in the game server 1, the message storage unit 55 c of the message transmission means 55 b receives the message addressed to the fellow player received from the terminal device 3. The data is stored in the database server 2 in association with the player ID of the fellow player (see FIG. 11). When the friend player's terminal device 3 accesses the game server 1, the message transmission means 55 b of the game server 1 transmits screen data for displaying a message, a player name of the transmission source, a transmission date and time, and the like to the terminal device 3. To do. Thus, a message or the like is displayed on the terminal device 3 of the player who has received this screen data, and the message received from another friend can be confirmed on the screen.

  As described above, in the game system according to the present embodiment, the friends can communicate with each other at any time using the communication tool illustrated in FIG. 13 and FIG.

  In the example of FIG. 13 and FIG. 14, the example in which the message is sent to the friend of the player has been described. However, it is also possible to greet or send a message to other players who are not in a friendship relationship. For example, it is also possible to send a greeting or message to other players who are not friends listed in the friend candidate list by the same operation as that of the friends.

  The present means 55d has a function of receiving present information addressed to other players transmitted from the terminal device 3 of each player and executing present processing for delivering presents to the other players. Examples of presents include player cards and various items owned by the player in the game.

  Here, an example of an operation in which a player gives a present to his / her fellow player will be described. For example, if the player A performs an operation for giving a present to his fellow player B on the terminal device 3, the game server 1 that has received the operation information displays a present selection screen as shown in FIG. Information to be displayed is sent. On this screen, player cards and items owned by the player A that can be presented to other players are listed and displayed.

  In the present selection screen, buttons (player card button 101 and item button 102) for selecting the type of present are displayed. FIG. 15 shows an example in which the player card button 101 is selected and the player card 103 is listed. In addition, an information display area 104 for each listed player card 103 is provided in this screen, and each information display area 104 includes a player name, a team attribute (team name), an ability value, and a player's value. The number of holdings is displayed. In addition, about the information of the player card 103 which cannot be displayed on the screen, the game server 1 can be requested to scroll the screen or request the second and subsequent pages of the present selection screen to be displayed as a separate screen. In addition, present buttons 105 corresponding to each player card 103 are also displayed in this screen. Then, by selecting and operating the present button 105 of the player card 103 that the player wants to present, the player card 103 can be virtually presented in the game to the fellow player B.

  There are two types of presents. One of them is a form in which a player card etc. that is presented is immediately owned by Player B when a process of presenting from Player A to Player B is performed (a form in which a present receiving operation is unnecessary). The other is that the player B receives the player card and the like when the process of giving a gift from the player A to the player B is performed. Is the main form).

  In the former form in which the present receiving operation is not required, for example, when the player A performs an operation of presenting the player card A to the player B, the present means 55d receives the present information and is stored by the owned player card storage means 51c. Update the information as follows. That is, as shown in FIG. 16, the presenting means 55d is a player card A (player card ID = “0010”) that presents the player B from player cards owned by the player A (player ID = “000001”). )) Is deleted. At substantially the same time, as shown in FIG. 17, the present means 55 d adds the player card A presented by the player A to the player card owned by the player B (player ID = “000002”). In this case, the present means 55d notifies the player A of the terminal device 3 that the present has been completed to the player B. Also, the present means 55d notifies the player B's terminal device 3 that the player card A has been presented by the player A.

  Next, the form of the latter present receipt operation essential is demonstrated. As shown in FIG. 6, the present means 55d includes an unreceived present storage means 551. This unaccepted present storage means 551 is a storage device (database server 2 or the like) that is presented until the second player receives a present when the process of presenting from the first player to the second player is performed. ). FIG. 18 shows an example of unreceived present information stored in the unreceived present storage unit 551. As shown in FIG. 18, the unreceived present storage means 551 associates information such as a present ID, a presenter, a type, a present, and a time with the database server 2 in association with the player ID of the present player. Store in a predetermined storage area. Here, the present ID is a management ID for uniquely identifying each present. As the presenter information, the player ID of the player who gave the present is stored. As the type information, the type of present such as a player card or item is stored. As information of what was presented, information for identifying a present such as a player card ID is stored. As time information, the time (date etc.) when the presenter gave the present is stored. In FIG. 18, the player A with the player ID = “000001” and the player card A with the player card ID = “0010” at 18:30 on January 10, 2011, the player with the player ID = “000002”. An example when presenting to B is shown. In this way, in the form of present receipt operation, the present is temporarily stored in the unreceived present storage means 551.

  In the form of present receipt operation required, for example, when the player A performs an operation of presenting the player card A to the player B, the present means 55d receives the present information and is stored in the owned player card storage means 51c. Update the information as follows: That is, as shown in FIG. 16, the player card A (player card ID = “0010”) that has been presented to the player B is deleted from the player cards owned by the player A. At substantially the same time, as shown in FIG. 18, the unreceived present storage means 551 stores the present of the player card A from the player A as the unreceived present of the player B. In this case, the present means 55d notifies the player A of the terminal device 3 that the present has been completed to the player B. Also, the present means 55d notifies the terminal device 3 of the player B that the present has arrived.

  When an operation for confirming a received present (unreceived present) is performed on the terminal device 3 of the player B, the unreceived present storage unit 551 stores the information on the operation in the game server 1 that has received the operation information. Information on the unacknowledged present of player B is transmitted to terminal device 3 of player B. For example, if there are two unreceived presents that have arrived at the player B, a present message 74 such as “Two presents are coming” is displayed on the main screen shown in FIG. A hyperlink is set in the present message 74, and the player B performs an operation of selecting the link display of the message 74, so that the terminal device 3 of the player B has an operation as illustrated in FIG. 19. An unreceived gift list screen is displayed. In addition, as illustrated in FIG. 19, presents may be given not only from other players but also from an operator who operates the game server 1.

  In the present display area listed in the present list screen of FIG. 19, the information 113 (player name) of the presenter's avatar 111, the present item (player card 112, etc.), the present player card 112, etc. , Team attributes, ability values, etc.), present time 114, a “receive” button 115, a “returned candidate display” button 116 described later, and the like.

  Here, if the player B performs a receiving operation of pressing the “receive” button 115, the player B can receive a present from the player A. When this receiving operation is performed, the present means 55d of the game server 1 that has received the information of the receiving operation updates the information stored in the owned player card storage means 51c and the unreceived present storage means 551 as follows. To do. That is, as shown in FIG. 17, the present means 55d adds the player card A (player card ID = “0010”) presented by the player A to the player card owned by the player B. At substantially the same time, the present means 55d deletes the present information received by the player B from the unreceived present information shown in FIG. 18 stored by the unreceived present storage means 551.

  Note that the present list screen of FIG. 19 includes a “main screen” button 110 for returning to the main screen, and after confirming an unreceived present, returning to the main screen without performing a present receiving operation. You can also.

  As described above, there are a form that does not require a present reception operation and a form that requires a present reception operation, and either form may be applied.

  As shown in FIG. 6, the present means 55d executes a return process described later when the second player presented by the first player gives a return gift to the first player. A return means 552 is provided. Details of the return means 552 will be described later.

  Next, the battle cooperation means 55e will be described. The battle cooperation means 55e receives information requesting a battle cooperation from a friend player from the terminal device 3 of the player (player A), and the character of the player A (may be a group or team consisting of a plurality of characters). Has a function of causing a friend player's character (for example, a leader's player card) to be added to the player A side as a "helper" and performing a battle cooperation when playing against other characters. In this way, the player A side's fighting power is improved as a result of the fellow player's character taking part in the player A side as an assistant, so that the player A's battle is advantageous compared to the case where there is no such battle cooperation. become.

  The “other character” when the player character battles with another character is a character of another player (may be a group or team of a plurality of characters) or a character prepared by the CPU of the game server 1 ( For example, it may be any boss character that appears at the end of each stage.

  When the player operates the terminal device 3 and selects a character (or fellow player) of a fellow player who wants to be an assistant, the terminal device 3 plays a battle including information on the selected fellow player character (or fellow player). Cooperation request information is transmitted to the game server 1. Then, the battle cooperation means 55e of the game server 1 receives the battle cooperation request information transmitted from the terminal device 3 of the player, and accepts the fellow player character selected by the player as an assistant.

  FIG. 20A shows an example of the game screen in the battle mode. On this game screen, information 91 of the opponent team (enemy army) designated by the player and information 92 of the player team (own army) are displayed. As the opponent's team (enemy army) information 91, for example, the opponent's player name, avatar, player card, information on strength, and the like are displayed. Further, as the player's team (self-army) information 92, the player's player name, avatar, player card, information on strength, and the like are displayed. Further, in the assistant display area 93 of the game screen, information such as characters cooperating with the army as assistants is displayed. This game screen is generated by the game screen generation means 52b of the game server 1 and is transmitted to the player's terminal device 3 by the game screen transmission means 52c, and is displayed on the display unit 35 of the terminal device 3. .

  Further, in the assistant display area 93, a “call assistant” button 93a (or a character string with a hyperlink set) is displayed so that an arbitrary fellow character can be requested as an assistant. When the player selects the “call helper” button 93a, for example, a transition is made to a helper selection screen shown in FIG. 15B. On this assistant selection screen, a fellow player who has a fellow relationship with the player and characters (player cards) possessed by the fellow player are listed and displayed. Note that information that cannot be displayed on the screen can be displayed as a separate screen by scrolling the screen or requesting the second or subsequent page of the assistant selection screen from the game server 1.

  In the assistant selection screen, an information display area for each listed player is provided, and in each information display area, the name 94a of the fellow player, the avatar 94b of the fellow player, and the player card 94c possessed by the fellow player. The player name 94d, information of the player card (level and attack power set on the player card, etc.) 94e, etc. are displayed. FIG. 20B shows an example in which a player card set as a leader among a plurality of player cards possessed by a fellow player can be selected as a helper character. For example, a representative character such as an ace pitcher or a player card set as a fourth batter may be selectable as a fellow assistant. Then, when the player operates the terminal device 3 and selects, for example, a hyperlink display portion set in the name 94a of the fellow player, the fellow character that is desired to be an assistant can be selected.

  For example, in the assistant selection screen of FIG. 20B, when the player A operates the terminal device 3 and selects the character of the fellow player B as an assistant, the game screen illustrated in FIG. Player B's player card 95 is displayed as an assistant. In addition, in the assistant display area 93, avatars of fellow players who cooperate in the battle, information on strength improvement by the battle cooperation, and the like are also displayed. In the screen example of FIG. 20C, “attack power + 200” is displayed as the strength-up information by battle cooperation.

  If the player selects a fellow assistant, the game server 1 stores the fellow assistant information in the database server 2 (storage device) in association with the player ID of the player. Therefore, if the player performs an operation of selecting a fellow assistant, the fellow character selected last time can be set as the assistant in the next battle. In addition, when the fellow character is set as a helper, a “change helper” button 96 (or a character string set with a hyperlink, etc.) is displayed in the helper display area 93. . When the player selects this button 96, the screen shifts to the assistant selection screen shown in FIG. 20B, and the friend character to be the assistant can be selected again.

  In the battle mode screen of FIG. 20A or 20C, when the player performs an operation of selecting the “start battle” button 97, a battle command is transmitted to the game server 1 from the terminal device 3 of the player. The battle process is executed. Then, when the fellow character is displayed as an assistant in the assistant display area 93, an operation for selecting the “start battle” button 97 is performed, thereby requesting the partner player to cooperate with the battle command. Information is transmitted from the terminal device 3 to the game server 1. In this case, battle cooperation is performed in which the player's character is companion to the player side as an assistant.

  Note that the exchanges that are the targets of the exchange process performed by the exchange means 55 are not limited to the above greetings, message transmissions, presents, and support requests for cooperative battles, but various exchanges performed between fellow players. Can be included. Other examples of exchange include joint practice. The joint practice is a kind of exchange, and is a practice that a player virtually performs with a fellow player in the game. A player who desires joint practice applies for joint practice by designating a fellow player, and the joint practice is performed when the fellow player accesses (logs in) the game within a predetermined period (for example, on the day when the application is made). Is established. As another example of the exchange, there is an exchange such as chat that can be performed between players in real time. In the case of chat, the terminal device 3 of two or more players can exchange character information (chat messages) and the like to communicate in real time.

  Next, the extraction means 56 will be described. When the presenter gives a present to the second player from the first player, the extracting unit 56 returns the first as a return from those possessed by the second player stored in the possession information storage unit 511. It has a function of extracting a return candidate for presenting to the player. This extraction means 56 can automatically perform a return candidate extraction process. Further, when the player performs a manual operation for confirming the return candidate on the terminal device 3, the extraction means 56 executes the return candidate extraction process in response to the return candidate request transmitted from the terminal device 3 of the player. It can also be done. The standard by which the extraction means 56 extracts return reward candidates can be arbitrarily determined. In the following, a preferable mode in which the extraction means 56 extracts return reward candidates based on a predetermined criterion will be described.

  When the presenter gives a present to the second player from the first player, the extracting unit 56 wants to store what he wants among the items owned by the second player stored in the possession information storage unit 511. When it is detected that there is what the first player wants to be stored in, it is preferable to extract what the first player wants as a return candidate.

  For example, when a present is given from the player A to the player B, as shown in FIG. 7, as the player A wants, the player card P with the player card ID = “0100” and the item ID = “0008”. A case where item Q is registered will be described as an example. In this case, the extraction means 56 includes the player card of the player A among the player cards and items owned by the player B stored in the possession information storage means 511 (owned player card storage means 51c and owned item storage means 51f). It is confirmed whether or not the player card P or the item Q that is desired is present (condition search is performed in the database server 2). And when the extraction means 56 detects that the player card P or the item Q exists in what the player B owns, the extraction means 56 extracts the player card P or the item Q as a return reward candidate. Here, when both the player card P and the item Q are detected as being owned by the player B, any of them may be extracted as a return reward candidate. In addition, a plurality of return reward candidates may be presented to the player. In this case, both the player card P and the item Q are extracted as return candidates.

  Thus, by extracting what the return target person wants to register as a return candidate, the return candidate that the return target person wants can be accurately presented to the terminal device 3 of the player.

  In addition, when the presenter gives a present to the second player from the first player, the extracting unit 56 stores the player attribute among the items possessed by the second player stored in the possession information storing unit 511. When it is detected that there is an object having the same attribute as the attribute desired by the first player stored in the means 51j, it is preferable to extract an object having the same attribute as a return reward candidate.

  For example, when a present is given from player A to player B, as shown in FIG. 7, “team 1” is registered as an attribute of the team that player A desires as his team when playing the game. An example will be described. In this case, the extraction unit 56 determines whether the player card of “Team 1” exists in the player cards owned by the player B stored in the ownership information storage unit 511 (owned player card storage unit 51c). (Condition search in the database server 2 is performed). Then, when the extraction means 56 detects that the player card of “Team 1” exists in what the player B owns, the extraction means 56 extracts the player card of “Team 1” as a return reward candidate. Here, when the player B possesses a plurality of player cards of “Team 1”, any of them may be extracted as a return reward candidate. Alternatively, all player cards of “Team 1” may be extracted as return candidates.

  In this way, by extracting those having the same attribute as the desired returnee (team attribute) as returnable candidates, the returnable candidates that the returnable person wants to return are accurately presented to the terminal device 3 of the player. be able to.

  As described above, when a present is given from the first player to the second player, the extracting unit 56 registers the thing that the first player wants from among those owned by the second player. Or a player card having the same attribute as that of the first player's team is extracted as a return candidate. If the return candidate cannot be extracted by these extraction criteria, the first player's team's attribute is extracted. A player card having an attribute different from the attribute may be extracted as a return reward candidate.

  As described above, a plurality of return candidates can be extracted and presented to the terminal device 3 of the player. However, on mobile phone terminals and smartphones where the display unit 35 is not so large, only one return candidate is presented. It is desirable to do. The priority extracted as the return candidate is the same attribute as the attribute of the return target person stored in the desired storage means 51i and the return target team attribute stored in the player attribute storage means 51j in descending order. It is preferable to have an attribute different from that of the team of the person to be returned. This order usually coincides with the order of those who want the returnee. Then, the extraction means 56 extracts the one with the highest priority among those owned by the second player when narrowing the number of return candidates to one.

  The criterion for extracting the return candidates described above is to extract the return candidates that the return target person wants as much as possible. On the other hand, the criterion for extracting the return candidates described below is to extract return candidates that match the gift given by the partner as much as possible.

  When the presenter gives a gift to the second player from the first player, the extracting unit 56 includes the ones owned by the second player stored in the possession information storage unit 511 from the first player. When it is detected that the same player card rarity is present, it is preferable to extract the detected one as a return candidate. Alternatively, the extracting means 56 detects that a thing with a rare degree within a predetermined range based on the rare degree of the player card presented by the first player is present among those owned by the second player. Then, the detected one may be extracted as a return candidate. Here, an example of “a rare degree in a predetermined range based on the rare degree of a gift given by the first player” will be described. For example, it is assumed that the player card has five levels of rarity “1 (lowest)” to “5 (highest)”. And when the rare degree of what was presented from the 1st player is set to R1, the rare degree of a predetermined range can be set to (R1-1)-(R1 + 1), for example.

  For example, in the case where a present is given from player A to player B, a case where the present of player A is a player card with a rarity level 3 will be described as an example. In this case, the extraction means 56 determines whether or not a player card with a rarity level 3 exists in the player cards owned by the player B stored in the possession information storage means 511 (owned player card storage means 51c). (Condition search in the database server 2 is performed). And when the extraction means 56 detects that the player card of the rare degree 3 exists in what the player B owns, the said player card is extracted as a return reward candidate. In addition, when a player card with a rarity level 3 does not exist in what player B owns, the rarity level to be extracted is expanded to a predetermined range of 2 to 4, and a rarity level of 2 to 4 A player card may be extracted as a return reward candidate. Or you may make it extract the player card of the rare degree 2-4 of the predetermined range from the beginning as a return reward candidate. Here, when the player B owns a plurality of player cards with a rare degree 3 (or rare degree 2 to 4), any of them may be extracted as a return candidate. Moreover, you may extract all the player cards of the rare degree 3 (or rare degree 2-4) as a return reward candidate.

  There may be cases where the player does not have a thing with the same rarity level as that presented by the opponent (or a rarity degree within the above-mentioned predetermined range), but in that case, other rares are present. The one of the degree will be extracted as a return candidate. Here, the priority of what the extraction means 56 extracts as a return candidate is given in the descending order of the same rarity as that given by the opponent (or the rarity in the predetermined range described above) A thing with a higher degree of rareness than that of the thing (or a thing higher than the degree of rareness in the predetermined range), a thing with a degree of rareness lower than that given by the opponent (or a thing with a degree of rarity lower than the predetermined range) it can.

  In the following explanation, regarding the extraction process based on the rarity level, a description will be given centering on the process of preferentially extracting the same rarity level as the gift given by the opponent as a return candidate. It can be replaced with a process that preferentially extracts rare items in a predetermined range based on the rare degree of the present as a return candidate.

  Configuration in which, when a present is given from the first player to the second player, what is registered as what the first player wants is returned as a return candidate from among those owned by the second player And a configuration in which a player card having the same rarity as the player card presented by the first player is extracted as a return reward candidate. For example, when a present is given from the player A to the player B, first, it is confirmed whether there are those registered as what the player A wants among those owned by the player B. Here, when there are a plurality of player cards registered as what the player A wants in the player cards possessed by the player B, the rarity of the player card presented by the player A therein If there is a thing with the same degree of rarity, it is preferentially extracted as a return candidate.

  Similarly, when a present is given from the first player to the second player, a player card having the same attribute as the team attribute desired by the first player is selected from those possessed by the second player. A configuration for extracting as a return candidate, and a configuration for extracting a player card having the same rarity (or a predetermined range of rarity as a reference) based on the player card presented by the first player as a return candidate. You may combine. For example, when a present is given from the player A to the player B, first, it is confirmed whether or not a player card having the team attribute desired by the player A exists in what the player B owns. Here, when there are a plurality of cards with the team attribute desired by the player A in the player cards owned by the player B, the same rare as the rare degree of the player card presented by the player A. If there is a thing of a certain degree, if it exists, it will be extracted preferentially as a return candidate. Alternatively, when a present is given from player A to player B, first, among those possessed by player B, is there a thing with the same rarity as the rarity of the player card presented by player A? Confirm. Here, when there are a plurality of player cards possessed by player B that have the same rarity level as the player card presented by player A, the team that player A wishes to have It is confirmed whether there is an attribute player card, and if it exists, it is preferentially extracted as a return candidate.

  The return candidate transmission means 57 has a function of transmitting information for displaying the return return candidates extracted by the extraction means 56 to the terminal device 3 of the second player who has been given a present. In the terminal device 3 of the second player that has received the information transmitted by the return candidate transmission means 57, the return candidates for the first player who presented the present to the second player are displayed.

  As described above, the game server 1 according to the present embodiment makes a request for a return candidate automatically or when a present is given from the first player to the second player or based on a manual operation of the second player. In response, the return candidates are extracted, and the return candidates are presented to the terminal device 3 of the second player. The form of presenting the return candidate by the game server 1 includes a form in which the second player presents the return candidate after receiving a present from the first player, and a present from the first player by the second player. There is a form in which a candidate for return is presented before receiving. Below, these forms are explained. In the following description, screen data is transmitted from the game server 1 to the terminal device 3 in response to a screen request from the terminal device 3 of the player. The explanation of the exchange is omitted as appropriate.

  First, an example of a mode in which the game server 1 presents a return reward candidate after the second player receives a present from the first player is shown. For example, when a present is given from the player A to the player B, a present message 74 as illustrated in FIG. 12 is displayed on the main screen of the terminal device 3 of the player B. Here, when the player B performs an operation of selecting the present message 74, an unreceived present list screen is displayed on the terminal device 3 of the player B as illustrated in FIG. If the number of player cards held by player B has not reached the upper limit, player B can receive a present from player A by selecting button 115 that player B receives. In this case, the screen transitions to the screen after receiving the present illustrated in FIG.

  For example, a message “A gift from player A has been received” is displayed on the screen of FIG. 21, a “main screen” button 110, an avatar 111 of player A, a “greeting” button 117, and “return” Present "button 118 and the like are displayed. In addition, when unreceived gifts remain, an unreceived gift list is also displayed on the screen of FIG. If the player B selects the “greeting” button 117 on the screen of FIG. 21, the player A can be greeted and the screen transitions to the screen shown in FIG. Further, if the player B selects the “main screen” button 110, the screen transitions to the main screen without returning. On the other hand, when the player B selects the “Give present in return” button 118, the screen returns to the return gift present operation screen shown in FIG. On the return gift operation screen, the return candidate 121 is automatically displayed together with the present information 119 received from the player A. That is, in the case where a present is given from player A to player B, when a return gift screen is displayed on the terminal device 3 of player B, the extraction means 56 automatically executes return candidate extraction processing, and the player The return candidate 121 is presented to the terminal device 3 of B.

  It is not always necessary to display the present information 119 received from the player A on the return gift operation screen of FIG. 22, but by displaying this information 119, the player B presents the return candidate 121 to the player A. It becomes easy to judge the validity of this.

  The return gift operation screen also displays player card information 122 (player name, team attribute, ability value, etc.) as a return candidate 121.

  Further, it is desirable to display status information 123 indicating what the return candidate 121 is. For example, when an item registered as desired by the player A is extracted as a return candidate, the status information 123 “desired by the player A” is displayed. Further, for example, when a player card having the same attribute as the team attribute desired by the player A is extracted as a return reward candidate, the status information 123 “Player A team card” is displayed. The status information 123 is useful for determining the validity of the player B presenting the return candidate 121 to the player A. The return candidate sending means 57 that realizes this is based on information used as a reference for extraction when the extraction means 56 extracts the return candidate 121 (what the player A wants, what the player A wants, etc.). The status information 123 is generated, and the status information 123 is transmitted to the player's terminal device 3 together with the return candidate 121.

  Further, information 124 regarding the number of players B possessed about the return reward 121 may be displayed. In this way, if the number of possessions is displayed, even if the number of possessions is two, even a card with a slightly higher degree of rarity can be considered as a gift target, and the degree of rarity If the player has only one high card, it may be determined that the present is suspended. In addition, the information 125 of the number of possessed by the player A regarding the return reward 121 may be displayed. In this way, by displaying whether or not the player A possesses the card, if the player A does not possess the card, it can be considered as a gift target, and conversely, the player A If you already have the same card, especially if you have two cards, you can make a decision to remove it from the gift because it only increases the number of duplicate cards for the opponent. . As described above, the information on the number of possessions 124 and 125 is also useful for determining the validity of the player B giving the return candidate 121 to the player A.

  Further, it is desirable to provide a “candidate change” button 126 in the screen of the terminal device 3 of the player B on which the return candidate 121 is displayed. Player B may not want to present player A with the return candidate 121 currently displayed. In this case, the player B can change the return reward candidate 121 by selecting the “candidate change” button 126. That is, when the player B selects the “candidate change” button 126, a candidate change request is transmitted from the terminal device 3 of the player B to the game server 1. In response to this candidate change request, the extraction means 56 of the game server 1 extracts another player card as a return candidate, and the return candidate transmission means 57 transmits the newly extracted return reward candidate to the terminal device 3 of the player B. To do.

  For example, the extraction means 56 desires the player A stored in the player attribute storage means 51j for the priority to be extracted as a return candidate in order from the player A stored in the desired storage means 51i. It is assumed that the player has the same attribute as the attribute and has an attribute different from the attribute desired by the player A. In other words, the higher the priority is set, the more likely the player A who is the returnee will want. Then, each time a candidate change request from the terminal device 3 of the player B is received, the return candidate sending means 57 sequentially displays information for displaying the return candidate in order from the highest priority return candidate. To the terminal device 3 of B. Thus, each time the player B selects the “candidate change” button 126 in FIG.

  In this manner, the priority of extraction is increased as the player A thinks that he / she wants to be presented as the return candidate 121, so that the player A may be pleased if the return is made. Things are easy to be selected by the player B. On the other hand, if what is presented as the return candidate 121 is something that the player B does not want to give up, the return candidate 121 can be changed in order from the highest priority to the lowest. This makes it easier for the player A to determine what the player A wants and the player B thinks he or she can let go. It is time-consuming and time-consuming for the player B to select and determine such a return object 121 by himself / herself, which cannot be easily performed.

  In addition, a “return gift” button 127 for performing a return operation is displayed in the screen of the terminal device 3 of the player B on which the return candidate 121 is displayed. The player B can give (return) the return candidate 121 displayed on the screen to the player A by performing an operation of selecting the “return gift” button 127. The return process in this case is executed by the return means 552 shown in FIG. Here, the return means 552 will be described.

  The return means 552 receives the information transmitted from the return candidate transmission means 57 and performs a return operation for presenting the return candidate 121 to the player A on the terminal device 3 of the player B displaying the return candidate 121. In the case where the information is received, information on the operation is received from the terminal device 3, and a return process is performed for presenting the return candidate 121 owned by the first player B to the player A. That is, the return means 552 deletes the player card of the return candidate 121 from the player cards owned by the player B stored by the owned player card storage means 51c. Further, the return means 552 stores the player card of the return candidate 121 in the unreceived gift storage means 551 as an unreceived gift of the player B. Further, the return means 552 notifies the player B's terminal device 3 that the player A has completed the return gift. The return means 552 notifies the terminal device 3 of the player A that the present has arrived.

  22 may be provided with an “select a present by yourself” button 128 on the return gift operation screen so that the player himself can select a player card or the like to be presented without using the return candidate 121. . When the “select a gift by yourself” button 128 is selected, the screen transits to a gift selection screen shown in FIG.

  Next, an example of a mode in which the game server 1 presents a return reward candidate before the second player receives a present from the first player will be described.

  In the present receipt operation required form, for example, when a present is given from the player A to the player B, the player card etc. that is presented is not immediately owned by the player B. Even when the number reaches the upper limit of 60, the player A can give a present to the player B. However, when the number of player cards held by player B has reached the upper limit, player B receives a present from player A even if player B selects button 115 on the present list screen shown in FIG. Can not do it.

  In such a situation, prior to the player B receiving the gift, a player card owned by the player B is first subjected to a predetermined operation (such as a player card sale or a combination operation in the combination mode). Therefore, it was necessary to provide a margin up to the upper limit of the number owned. In addition, when giving a present for return in response to the received present, an operation of searching for a gift to be given to the opponent from among those owned by Player B and operating the present after the determination is made occurs. . In other words, conventionally, when a present is given from player A to player B, and the number of player cards held by player B has reached the upper limit, the number of player cards held by player B is reduced, Since it is necessary to perform a series of operations such as receiving a present, searching for and determining a present to be returned to the other party, and presenting the present to the other party, it took a lot of trouble and was troublesome. In addition, since the operation is troublesome, it may happen that a gift of return to the other party is not given. The situation where the return to the opponent is troublesome can be a factor that hinders the close relationship between the players.

  Therefore, in the game server 1 according to the present embodiment, when the present is given from the player A to the player B and the number of player cards held by the player B reaches the upper limit, the player B Before receiving the present from A, the game server 1 presents the return candidate to the terminal device 3 of the player B. Further, when a return operation is performed on the terminal device 3 of the player B displaying the return candidate, the game server 1 receives information on the operation from the terminal device 3, and the player B receives the return candidate. It deletes from what it possesses and presents it to player A, and makes player B receive what was presented by player A. As described above, by allowing presents to be given to the returnee partner and receiving the presents from the other party only by the return operation, the operation to be performed by the player is greatly simplified as compared with the conventional case. The game server 1 that realizes this will be described below.

  For example, when a present is given from the player A to the player B, a present message 74 as illustrated in FIG. 12 is displayed on the main screen of the terminal device 3 of the player B. Here, when the player B performs an operation of selecting the present message 74, the game server 1, when the number of player cards held by the player B has reached the upper limit, has not been received as illustrated in FIG. 23. Data of the present list screen is generated and transmitted to the terminal device 3 of the player B. Return gift candidates 121 are automatically displayed on the present list screen. That is, when the number of player cards possessed by player B has reached the upper limit, the extraction means 56 automatically extracts the return candidate when the unreceived present list screen is displayed on the terminal device 3 of player B. , And the return candidate 121 is presented to the terminal device 3 of the player B.

  In the present list screen of FIG. 23, in the present display area from the player A, as in FIG. 19, the presenter's avatar 111, the present player card 112 and its information 113, the present time 114, and the like are displayed. The In the present display area from the player A, as in FIG. 22, the player card as the return candidate 121 for the player A and its information 122, status information 123, possession number information 124 and 125, “change candidate” ”Button 126 is displayed (these display information and buttons have already been described, and description thereof is omitted here). Further, a “return gift (return & receipt)” button 131 is also displayed in the present display area from the player A.

  Player B presents (returns) the return candidate 121 displayed on the screen to Player A by performing a return operation for selecting the “Return Gift (Return & Receipt)” button 131 and presents it from Player A. Received player card 112 can be received. That is, when the number of players B has reached the upper limit, the return means 552 receives the information transmitted from the return candidate transmission means 57 and displays the return candidate 121 on the player B's terminal device 3. When a return operation for presenting the return candidate 121 to the player A is performed, information on the operation is received from the terminal device 3 and the return candidate 121 is deleted from what the player B owns. The player A updates the stored contents of the possession information storage unit 511 so that the player B receives and owns the present from the player A stored in the unreceived present storage unit 551. That is, the return means 511 has a function of reducing the number of player cards held by the player B, receiving a gift from the player A, and giving a reward to the player A at the same time.

  Therefore, in the case where the number of player cards held by the player has reached the upper limit, the player B can simply and quickly receive presents by simply performing a return operation on the terminal device 3 displaying the return candidates 121. Can give a return. In addition, since the game server 1 also presents the return candidate 121, the player B does not need a troublesome operation for himself to search for a player card or the like to be presented as a return to the player A. In this way, when the number of player cards held by the player has reached the upper limit, the operations to be performed by the player are greatly simplified as compared to the conventional case, and presents can be received and returned easily and quickly. The environment can be provided to the player.

  Even if the number of player cards held by player B has not reached the upper limit, game server 1 sends a return candidate to terminal device 3 of player B before player B receives the present from player A. May be presented. For example, when the player B performs an operation of selecting the present message 74 shown in FIG. 12, the extraction means 56 automatically extracts a return reward candidate, and the unreceived present list screen data illustrated in FIG. It transmits to the terminal device 3 of the player B. As in FIG. 23, the present list screen in FIG. 24 is the giver's avatar 111, the present player card 112 and its information 113, the present time 114, the player card as the return candidate 121 and its information 122, and status information. 123, information 124/125 of the number of possessions, a “candidate change” button 126, a “return gift (return & receipt)” button 131, and the like are displayed. Therefore, even if the number of players B has not reached the upper limit, if player B performs a return operation to select the “return gift (return & receipt)” button 131, the return candidate 121 will be given as a present to player A. The player card 112 presented by the player A can be received at a time.

  In addition, a “receive only” button 132 is displayed on the present list screen of FIG. This “reception only” button 132 is a button for receiving the player card 112 presented by the player A without the player B giving the gift of return.

  In the above, an example is shown in which when the present is given from the player A to the player B, when the present list screen or the like is displayed on the terminal device 3 of the player B, the extraction means 56 automatically extracts the return reward candidates. However, an example in which the extraction means 56 extracts return reward candidates in response to the return candidate request transmitted from the terminal device 3 of the player B based on the manual operation of the player B will be described.

  For example, when a present is given from player A to player B, when player B performs an operation of selecting a present message 74 shown in FIG. 12, the unreceived present list screen shown in FIG. Displayed on the terminal device 3. On this screen, a “returned candidate display” button 116 is displayed. When the player B selects the button 116, a return candidate request is transmitted from the terminal device 3 to the game server 1. The extraction unit 56 of the game server 1 extracts a return candidate in response to the return candidate request, and transmits information for the return candidate transmission unit 57 to display the return candidate to the terminal device of the player B. Thereby, as shown in FIG. 24, the present list screen including the return candidate 121 is displayed on the terminal device 3 of the player B.

[Game system operation]
In the above configuration, an example of the operation of the game system according to the embodiment of the present invention will be described below with reference to the flowchart of FIG. FIG. 25 shows a processing flow of the terminal device 3 and the game server 1 when the player operates the terminal device 3 to access the game server 1 and receive a game service.

  When the player receives the game service, first, the web browser is activated by operating the operation input unit 40 of the terminal device 3 (S11). Thereafter, the player performs an operation of accessing a game site managed by the game server 1, and thereby an access request is transmitted from the terminal device 3 to the game server 1 (S12). At this time, the game server 1 performs login authentication for access from the terminal device 3 (S21), and confirms that the access is from a player who is registered for use of the game service. Thereafter, the game server 1 transmits main screen data described in HTML or the like to the terminal device 3 (S22). If there is a top screen different from the main screen, the top screen may be transmitted first. In the terminal device 3 that has received the main screen data, the web browser interprets the data and displays the main screen on the display unit 35 (S13).

  As illustrated in FIG. 12, the main screen includes a player team name 70, an image of a player card 71 selected as a leader among player cards owned by the player, player game information 72 (player level, action Strength points, operating costs, reinforcement points, exchange points, number of player cards owned, number of friends, etc.) are displayed. In addition, a button group 73 for selecting each mode of scout, order, reinforcement, lottery, and game is also displayed. Furthermore, on this main screen, various objects such as various menu buttons (not shown), movement information of friends, messages from other players, etc. are displayed by scrolling the screen by operating the direction keys or touch panel of the terminal device 3. And information are displayed.

  Here, when the player performs an operation of selecting an object such as a selectable button or a hyperlink displayed on the screen, a screen request corresponding to the operation is transmitted from the terminal device 3 to the game server 1 (S14). ). Receiving this request, the game server 1 executes arithmetic processing and data processing according to the player's operation to execute the game (S23), and transmits game screen data reflecting the execution result to the terminal device 3 (S24). ). And in the terminal device 3 which received screen data, a web browser interprets the said data and displays a game screen on the display part 35 (S15).

  Thereafter, the above-described S14 and S15 are repeated in the terminal device 3 of the player, and the above-described S23 and S24 are repeated in the game server 1, whereby the selectable buttons displayed on the screen of the terminal device 3 Etc., the game screen of the terminal device 3 is switched one after another and the game can be advanced.

  Thereafter, when the player operates the terminal device 3 to close the game screen (S16), the game server 1 performs logout processing (S25). For example, when the player closes the web browser, the game server 1 performs logout processing after a session timeout.

  By the way, in this game system, even when the player logs out from the game server 1, the game server 1 side can read the game information of the player and advance the game. For example, another logged-in player may start a battle (individual battle) against a team of players who are logged out. Also in this case, the game progress means 52 of the game server 1 reads out the game information of each player from the database server 2 and executes a battle regardless of whether or not the player is logged in, and reflects the execution result. The game information of each player is updated. In the league battle mode, the game progress means 52 of the game server 1 reads the game information of each player from the database server 2 and automatically executes the league game without the player operating the terminal device 3. Thus, the result of the battle executed when the player is logged out from the game server 1 can be confirmed on the screen when the player accesses the game server 1 thereafter.

[Operation of game management device]
Next, a more detailed operation example of the game management device according to the embodiment of the present invention will be described with reference to a flowchart of FIG. FIG. 26 shows the flow of processing of the game server 1 targeting one player, and the same processing is performed for each player managed by the game server 1.

  As shown in FIG. 26, when the authentication means 53 of the game server 1 receives an access request from the terminal device 3 of the player (YES in S31), the login ID / password transmitted from the terminal device 3 or the mobile phone Based on the individual identification number of the terminal or the like, login authentication is performed to determine whether or not to permit access (S32). Here, when access is not permitted (NO in S32), the game server 1 transmits screen data for prompting registration of use of the game service to the terminal device 3 (S33). On the other hand, when access is permitted (YES in S32), access information (log) is stored (S34).

  Then, the game server 1 transmits main screen data (or top screen data) to the terminal device 3 of the player who has permitted access (S35). Thereafter, when a screen request corresponding to the game operation of the player transmitted from the terminal device 3 of the player is received (YES in S36), the game executing means 52a performs arithmetic processing and data processing corresponding to the screen request. The game is executed (S37).

  Thereafter, the game server 1 determines whether or not the game information of the player needs to be updated by executing the game (S38). If the game server 1 needs to be updated (YES in S38), it is stored in the database server 2. The game information of the player is updated (S39). For example, when the player's game operation is an operation for performing an individual battle with another player, the game information of the player such as information on the game result, operation cost, reinforcement points, items, etc. is updated as a result of the battle being executed. Will be. On the other hand, for example, when the game operation of the player is an operation for confirming the result of the league game, the game execution process corresponding to the operation is only a data process for reading out the result information of the league game from the database server 2, There is no change in the player's game information before and after the process, and therefore there is no need to update the player's game information (NO in S38).

  Thereafter, the game screen generation means 52b generates game screen data reflecting the game execution result (S40), and the game screen transmission means 52c transmits the game screen data to the terminal device 3 of the player (S41). Thereafter, it is determined whether or not the terminal device 3 of the player has logged out (S42), and the game proceeds by repeating the processes of S36 to S41 until the terminal device 3 logs out.

  Next, an example of a process in which the game server 1 presents return reward candidates to the terminal device 3 of the player will be described with reference to FIGS. Note that the flowcharts of FIGS. 27 to 30 show the flow of processing taking as an example a case where a player card is presented from player A to player B.

  As shown in FIG. 27, when an operation for selecting the present message 74 in the main screen illustrated in FIG. 12 is performed on the terminal device 3 of the player B (YES in S51), the game server 1 It is determined whether the number of possessed player cards has reached the upper limit (S52). Here, when the number of possessions has reached the upper limit (YES in S52), the extraction means 56 executes an extraction process for extracting return reward candidates from the player cards owned by the player B (S53). The flow of this extraction process will be described later. Thereafter, the return candidate transmission means 57 transmits the data of the present list screen including the extracted return candidates to the terminal device 3 of the player B (S54). Thereby, the present list screen illustrated in FIG. 23 is displayed on the terminal device 3 of the player B.

  Here, when the “candidate change” button 126 in FIG. 23 is selected by the player B, the game server 1 receives a candidate change request from the terminal device 3 of the player B (YES in S55), and returns to step S53 to return to the process. The player card extraction process is executed. Each time the “change candidate” button 126 is selected by the player B, the player card of the return candidate 121 of FIG. 23 is changed by executing steps S53 and S54.

  Then, when a return operation for selecting the “return gift (return & receipt)” button 131 is performed by the player B while a certain player card is displayed as the return candidate 121 (YES in S56), the return means 552. Updates the stored contents of the possession information storage means 511 as follows. That is, the return reward candidate 121 is deleted from those owned by the player B (S57), the return reward candidate 121 is presented to the player A (S58), and the player card 112 received from the player A is received by the player B. (S59) Thereby, even when the number of player cards held reaches the upper limit, the player B can simply and quickly receive and return a present by simply performing a return operation without performing a time-consuming operation. It can be performed.

  23, if the “main screen” button 110 is selected without the “return gift (return & receipt)” button 131 being selected by the player B (YES in S60), the game server 1 is The screen data is transmitted to the terminal device 3 of the player B (S61).

  If the number of player cards held by player B has not reached the upper limit in the determination in step S52 (NO in S52), the process proceeds to step S62 in the flowchart of FIG. In this step S62, the game server 1 transmits the data of the present list screen illustrated in FIG. 19 to the terminal device 3 of the player B.

  In the present list screen of FIG. 19, when the “return-candidate display” button 116 is selected by the player B (YES in S63), the extraction means 56 extracts return-reward candidates from the player cards owned by the player B. The extraction process is executed (S53). Thereafter, the return candidate transmission means 57 transmits the data of the present list screen including the extracted return candidates to the terminal device 3 of the player B (S54). Thereby, the present list screen illustrated in FIG. 24 is displayed on the terminal device 3 of the player B. The processing (S55 to S59) when the “candidate change” button 126 or the “return gift (return & receipt)” button 131 is selected on this present list screen is the same as the flowchart of FIG. Omitted. 24, when the “receive only” button 132 is selected by the player B (YES in S64), the game server 1 proceeds to step 59 and the player card presented by the player A The content stored in the ownership information storage unit 511 is updated so that the player B receives and owns 112.

  For the sake of convenience, although not shown in the flowchart of FIG. 28, when other operations are performed such as the “main screen” button 110 being selected on the present list screen of FIG. A corresponding process is performed.

  On the other hand, in the present list screen of FIG. 19, when the receiving operation for selecting the “receive” button 115 is performed by the player B without selecting the “returned candidate display” button 116 (NO in S63) (in S66). YES), the process proceeds to step S67 in the flowchart of FIG. In this step S67, the game server 1 updates the stored content of the ownership information storage means 511 so that the player B receives and owns the player card 112 presented by the player A (S67). Thereafter, the game server 1 transmits the screen data after receiving the present to the terminal device 3 of the player B. Thereby, the screen after the present reception illustrated in FIG. 21 is displayed on the terminal device 3 of the player B.

  In the screen illustrated in FIG. 21, when the “present in return” button 118 is selected by the player B (YES in S <b> 69), the extracting unit 56 selects a return candidate from the player cards owned by the player B. The extraction process to extract is performed (S53). After that, the return candidate transmission means 57 transmits the return gift operation screen data including the extracted return candidates to the terminal device 3 of the player B (S70). Thereby, the return gift present operation screen illustrated in FIG. 22 is displayed on the terminal device 3 of the player B.

  Here, when the “candidate change” button 126 is selected by the player B, the game server 1 receives a candidate change request from the terminal device 3 of the player B (YES in S55), and returns to step S53 to return another player card. Execute the extraction process. Then, each time the “change candidate” button 126 is selected by the player B, the player card of the return candidate 121 of FIG. 22 is changed by executing steps S53 and S70.

  Then, when a return operation for selecting the “return gift” button 127 is performed by the player B while a certain player card is displayed as the return reward candidate 121 (YES in S71), the return means 552 is displayed by the player B. A return process for presenting the returned return candidate 121 to the player A is executed (S72).

  When other operations are performed on the screen shown in FIG. 21 or FIG. 22, such as when the “main screen” button 110 is selected (YES in S73), processing corresponding to the operation is performed ( S74).

  Next, an example of the return candidate extraction process in step S53 executed by the extraction unit 56 will be described with reference to FIG. First, the extracting unit 56 determines whether or not the desired item of the player A stored in the desired item storage unit 51i exists among the items owned by the player B stored in the possession information storage unit 511. Search is performed (S81). Here, when the extracting means 56 detects that there is what the player A wants (YES in S81), the player A extracts what he wants as a return reward candidate (S82).

  On the other hand, when there is no desired item for player A in step S81 (NO in S81), the extraction means 56 stores the player attribute in the contents owned by player B stored in the ownership information storage means 511. It is searched whether there is a player card having the same attribute as the team attribute desired by the player A stored in the means 51j (hereinafter referred to as “team card of player A”) (S83). Here, when the extraction means 56 detects that the team card of the player A exists (YES in S83), it extracts it as a return reward candidate (S84). On the other hand, when the team card of player A does not exist (NO in S83), the extraction means 56 selects the one other than the team card of player A from those owned by player B stored in the ownership information storage means 511. A player card is extracted as a return candidate (S85).

  When there are a plurality of player cards extracted in step S82, S84 or S85 (YES in S86), the exit means 56 has the same rarity as the player card present from player A. Is searched for (S87). Here, when the extraction means 56 detects that a thing with the same rarity level exists (YES in S87), it extracts it as a return candidate (S88). In addition, when there are a plurality of player cards having the same rarity, any one card may be extracted as a return candidate. On the other hand, when the same rare degree does not exist (NO in S87), the extraction means 56 extracts an arbitrary one with a rare degree different from the rare degree of the player card presented by the player A as a return candidate (S89). ).

  When the return candidate extraction process subroutine shown in FIG. 30 is executed with a candidate change (YES in step S55 in FIG. 28, etc.), the player cards that have already been extracted as return candidates are naturally excluded. After that, the extraction process is executed.

  In the above description, the number of player cards to be extracted as return candidates is described as one. However, the number may be set to a plurality instead of one. For example, as described above, all player cards that satisfy the extraction condition may be extracted. Alternatively, an upper limit (for example, three) of extraction numbers may be set, and player cards within the upper limit may be extracted and presented to the player terminal device 3 as return reward candidates.

  FIG. 30 shows an example of the return candidate extraction process. The various extraction conditions described above can be appropriately discarded and combined to set arbitrary extraction conditions. Furthermore, various other extraction conditions or conditions for exclusion from the extraction target, as shown below, may be employed as appropriate.

  That is, the extraction means 56 determines whether the first player who is the return partner possesses what is extracted as a return candidate, and the return candidate extraction target for what the first player has. Remove from. Alternatively, the priority of extraction is lower than what the return partner has, rather than what the return partner does not have. Thereby, what is considered to be preferred by the first player who is the person to be repaid (what the first player does not have) can be preferentially presented to the player as a return candidate.

  Also, for the second player who wants to return, he / she does not want to let go of a player card that he / she has only one player card and a player card he / she has only one if possible. It is normal to think. Therefore, the extraction means 56 lowers the priority of extraction of what the second player has only one than that possessed by a plurality. Alternatively, the higher the number owned by the second player, the higher the priority of extraction, and the higher priority is extracted. This makes it difficult for the second player to think that he / she does not want to let go (only one is owned), and presents a more appropriate return candidate for the second player. Can do.

  Also, it is normal for the second player not to want to let go of his team card. Therefore, the extracting means 56 excludes those having the same attribute as the attribute desired by the first player stored in the player attribute storing means 51j from the return candidate candidates. Alternatively, the priority of extraction of the same attribute as the attribute desired by the first player is made lower than that of the different attribute. As a result, what the second player would not want to give up (having the attribute he / she wanted) is not presented as a return candidate or difficult to be presented, and a more appropriate return candidate is presented to the second player can do. However, if the own team and the team of the return party are the same, the player card that wants the first player of the return party is not presented. Therefore, the above condition may be applied only when the attributes desired by the first player and the second player are different.

  In the case of a configuration in which a regular player card that contributes to a game progress such as a battle and a non-contributing player card can be set in a player card owned by the player as in this embodiment, the return is as follows. Candidate extraction conditions may be set. In other words, it is normal for the second player not to let go of the regular player card if possible. Therefore, the extraction means 56 excludes those that are contributed to the game progress such as the battle among those owned by the second player from the extraction targets of the return candidates. Alternatively, the priority of extraction of those that do not contribute to the game progress such as the battle is increased. As a result, what the second player would not want to let go (regular player card or the like) is not presented as a return candidate or difficult to be presented, and a more appropriate return candidate for the second player may be presented. it can.

  In addition, each player wants to keep his / her favorite player card, a player card that is extremely rare even if he / she is not his / her team, etc. Some do not want to let go. In order to avoid such a player card and the like being repeatedly presented as a return candidate, it is desirable to be able to register in advance a player card or the like that each player wants to hold. A configuration for realizing this will be described below.

  As shown in FIG. 31, the game server 1 stores, in response to a holding request from the terminal device 3 of the player, what is selected from those owned by the player as a holding object without being returned. Information storage means 512 is provided. As shown in FIG. 32, the holding information storage means 512 stores information on a holding flag set in association with the player card ID owned by the player in a storage device (database server 2 or the like). FIG. 32 shows an example in which a 1-bit holding flag is added to the player card ID (information stored in the owned player card storage means 51c) owned by the player B with the player ID = “000002”. Yes. The holding flag = “1” is set in the player card ID registered as the player card to be held. In the example of FIG. 32, the player card ID = “0003” and “0008” are player cards registered as player cards that the player B wants to hold.

  Next, an example of registering a player card to be held is shown below. For example, as shown in FIGS. 22 to 24, when the return reward candidate 121 is displayed on the screen of the terminal device 3 of the player B, the “keep” button 133 is also displayed. When a player card that the player B does not want to release is displayed on the screen as the return reward 121, the player B performs an operation of selecting the “keep” button 133. With this operation, a holding request is transmitted from the terminal device 3 of the player B to the game server 1. In response to the holding request, the holding information storage unit 512 registers the selected player card (player card displayed as the return reward 121) as a player card that the player B wants to hold (as described above, the holding flag). = "1" is set). Thereby, in the future, the registered player card will not be presented to the terminal device 3 of the player B as a return reward candidate.

  Further, on a screen (not shown) for displaying a list of player cards owned by the player, the “keep” button 133 is provided corresponding to each player card displayed in the list, and the player selects an arbitrary player card and selects “ By pressing the “keep” button 133, the player card may be registered as a card that the user wants to hold.

  By the way, when the player B receives a present from the player A, the player B may not give a return gift. For example, when the player B confirms the return candidate 121 displayed on the return gift operation screen of FIG. 22, at this point, the player B does not own an appropriate player card or the like as a return object. A player card or the like that he / she wants to return may not be presented as the return candidate 121. Therefore, as shown in FIG. 22, a “return hold” button 154 is displayed on the return present operation screen, and a return return hold is made by the return hold operation for selecting the button 154 so that an unreturned history can be recorded. Good. As shown in FIG. 31, the game server 1 that realizes this includes unreturned history storage means 58 and unreturned history transmission means 59.

  The unreturned history storage means 58 is a case where a present is given from the first player to the second player, and the operation for holding the return is performed in the terminal device 3 of the second player. Is received, and the database server 2 has a function of storing an unreturned history indicating that the second player has not returned the present from the first player. An example of the unreturned history stored in the unreturned history storage means 58 is shown in FIG.

  As shown in FIG. 33, the unreturned history storage means 58 stores information such as an unreturned ID, a present player ID, a present player ID, a type, a present, a present time, etc. Store in the storage area. Here, the present player ID is the player ID of the first player on the side that presented the present. The given player ID is the player ID of the second player on the side that received the present. As the type information, the type of present such as a player card or item is stored. As information of what was presented, information for identifying a present such as a player card ID is stored. The present time is information on the time when the process of presenting from the first player to the second player is performed.

  When the second player wants to confirm the information that the return has been put on hold (unreturned information), for example, if the second player performs an operation of selecting the “unreturned list” button 75 on the main screen shown in FIG. A non-repayment confirmation request is transmitted from the terminal device 3 of the player to the game server 1. The unreturned history transmission means 59 reads the unreturned history of the second player stored in the unreturned history storage means 58 in response to the unreturned confirmation confirmation request from the terminal device 3 of the second player, It has a function of transmitting information (unreturned list screen data) for displaying the unreturned history to the terminal device 3. FIG. 50 shows an example of the unreturned list screen that the unreturned history transmission means 59 transmits to the terminal device 3 of the second player.

  In the unreturned list screen of FIG. 50, information of presents received from the unreturned partner as unreturned history 160 (information that indicates when and what presents were received from who) is displayed. In addition, when the second player has put a return on hold multiple times, a plurality of areas for displaying the unreturned history 160 are provided. FIG. 50 illustrates a case where there are three unrefunded histories 160. In addition, the “Return to Present” button 118 corresponding to each unreturned history 160 is displayed on the unreturned list screen, and by selecting the button 118, transition to the return present operation screen shown in FIG. Can do.

  In this way, the second player who has performed the return hold operation can check the hold information (unreturned history) with his / her terminal device 3 at any time. As a result, it is possible to avoid a situation where the return to the partner who received the present is forgotten. That is, it is often the case that when a gift is received, the user does not return immediately, but forgets to return to the other party who received the gift if time passes. However, with this configuration, if the unreturned history can be confirmed at any time, the situation of forgetting to return can be effectively avoided. Therefore, the present is less likely to be left unreturned, which can contribute to intimate communication between players.

  Further, as shown in FIG. 22, a “remind” button 155 is displayed on the return gift operation screen, and a remind setting operation for selecting the button 155 allows the return to be put on hold and the remind setting can be performed. Good. When this reminder is set, when the player acquires a player card or the like that satisfies the return criteria for the opponent in the game, the player's terminal device 3 is notified to that effect and the player card or the like that can return to the opponent. (It is announced on the screen of the terminal device 3 when a player card or the like is acquired). Details of the remind setting will be described later.

  As described above, in the configuration of the present embodiment, when a present is given from the first player to the second player, the game server 1 extracts the return reward candidates from those owned by the second player. Since the second player presents it to the terminal device 3 of the second player, the second player performs the troublesome work of searching for a player card or the like to be presented as a return to the first player. There is no need to do it. Therefore, it is possible to provide the player with an environment in which a return gift can be given to the other party who has received the present easily and quickly without the need for conventional labor.

  In particular, when the number of player cards held by the second player has reached the upper limit, the second player simply performs a return operation on the terminal device displaying the return return candidates. The reduction in the number of player cards held, the receipt of a gift from the first player, and the gift of return to the first player can be performed at substantially the same time. Therefore, the operation to be performed by the second player is greatly simplified as compared to the conventional case, and it is possible to provide the player with an environment where the present can be received and returned easily and quickly.

[Another configuration example of the game management device]
Another configuration example of the game management device will be described with reference to the functional block diagram of FIG. In addition, the same member number is attached | subjected about the structure similar to the structure shown in previous drawing, The description is abbreviate | omitted suitably.

  First, a schematic configuration of the game server 1 of the present embodiment will be described. When a present is given from the first player to the second player, there is no appropriate player card or item for returning to the hand of the second player, and there may be no return on the spot. In this case, the second player may forget to return. Therefore, the game server 1 according to the present embodiment is a case where a present is given from the first player to the second player, and a present is not given from the second player to the first player. The remind setting is performed on the second player with the first player as a returnee. After that, when the second player acquires what satisfies the return criteria for the first player in the game, the game server 1 performs a notification (remind) to the terminal device of the second player. It has a configuration. With this characteristic configuration, it is possible to effectively avoid a situation in which the player forgets to return, and to provide a game environment that can contribute to intimate communication between the players. Below, the detail of a structure of the game management apparatus (game server 1 grade | etc.,) Which concerns on this Embodiment which can provide such a game environment is demonstrated.

  As shown in FIG. 34, the game server 1 (game management device) of the present embodiment has a game information management means 51, a game progress means 52, an authentication means 53, a fellow management means 54, and an AC means 55 in addition to the above-mentioned game information management means 51. , A remind setting unit 201, a history information storage unit 202, a remind unit 203, a release unit 204, a present history storage unit 205, a return determination unit 206, a closeness grant unit 207, and the like. These means 201-207 are implement | achieved when CPU11 of the game server 1 runs the program which concerns on this Embodiment.

  Note that the game server 1 according to the present embodiment shown in FIG. 34 may or may not include the extraction means 56 and the return candidate transmission means 57 described above.

The remind setting means 201 is a case where a present is given from the first player to the second player, which is another player, and when the present is not given from the second player to the first player, It has a function of storing history information of gifts given from the first player to the second player and performing a remind setting for the second player as a returnee for the second player. The remind setting means 201 automatically performs the remind setting when it is detected that a present has not been given from the second player to the first player. Alternatively, when the second player performs a remind setting operation on the terminal device 3, the remind setting unit 201 performs the remind setting in response to the remind setting request transmitted from the terminal device 3 of the second player. You may make it perform.
First, a configuration in which the remind setting unit 201 automatically performs remind setting will be described.

  With respect to the determination of “when a present is made from the first player to the second player and no present is made from the second player to the first player”, there are various types of determination as described below. A determination method can be considered.

  For example, in the above-described form of present receiving operation required, the screen is displayed without operating the “Give present in return” button 118 on the screen of FIG. 21 displayed after the second player performs the receiving operation. Judgment is made upon completion or transition to another screen such as the main screen.

  Further, in the above-described form in which the present receiving operation is not required, when the fact that the second player has received the present is confirmed on the screen, the screen is terminated without operating the present for return or another screen is displayed. Judged by having transitioned to.

  Further, the determination is made based on the fact that the second player did not give a return gift from the second player to the first player within a predetermined time (for example, 24 hours) after the first player gave the second player. (Applicable to any form of gift receiving operation required and unnecessary).

  The remind setting means 201 also includes history information storage means 202 that stores history information on the present from the first player to the second player as the remind setting information in the database server 2 (storage device). . The history information stored in the history information storage unit 202 is a case where a present is given from the first player to a second player, which is another player, and a present is given from the second player to the first player. This is information stored in the case of not being performed, in other words, an unreturned history indicating that the second player has not returned the present from the first player. An example of the history information stored in the history information storage unit 202 is shown in FIG.

  As shown in FIG. 35, the history information storage unit 202 stores information such as a remind ID, a present player ID, a present player ID, a type, a present, a present time, a remind setting time, etc. Store in a predetermined storage area. Here, the present player ID is the player ID of the first player on the side that presented the present. The given player ID is the player ID of the second player on the side that received the present. As the type information, the type of present such as a player card or item is stored. As information of what was presented, information for identifying a present such as a player card ID is stored. The present time is information on the time when the process of presenting from the first player to the second player is performed. The remind setting time is information of the time when each piece of history information is stored, that is, the reminding time is set. As information on the present time and the remind setting time, time such as year, month, day, hour, minute, second is stored, but the unit of time can be arbitrarily set.

  In the example of the remind ID = “1” in FIG. 35, the player A with the player ID = “000001” receives the player card with the player card ID = “0010” at 18:30 on January 10, 2011. History information that the player B with ID = “000002” has been presented is stored at 19:20 on January 10, 2011. As a result, a reminder is set for the player B (presented player ID) as the return target of the player A (presented player ID).

  Next, the reminding means 203 will be described. If the second player for which the remind setting is performed by the remind setting unit 201 acquires in the game what meets the return criteria for the first player who is the return target, It has a remind function to transmit information for notifying that it is an object of return to the first player to the terminal device 3 of the second player. Here, with respect to “what satisfies the return criteria for the first player who is the return target”, for example, an arbitrary reference such as what the return target person wants can be set. In the following, preferred return criteria will be described.

  It is preferable that “what satisfies the return criteria for the first player who is a return target” is the same as the desired one of the first player stored in the desired storage means 51i. For example, as shown in FIG. 35, it is assumed that a remind setting is performed on the player B with the player A as a returnee. Further, as shown in FIG. 7, it is assumed that a player card P with player card ID = “0100” and an item Q with item ID = “0008” are registered as what player A wants. Then, when the player B acquires a player card or item in the game, the reminding means 203 confirms whether the acquired item is the player card P or the item Q that the player A wants. Then, when the reminder 203 detects that the player B has acquired the player card P or the item Q, the reminder 203 informs the terminal device 3 of the player B that the acquired is a return object for the player A. Thus, the player B can easily and quickly return what he / she wants to return.

  Further, “what satisfies the return criteria for the first player who is the returnee” has the same attribute as the team attribute desired by the first player stored in the player attribute storage means 51j. It is preferable. For example, as shown in FIG. 35, it is assumed that a remind setting is performed on the player B with the player A as a returnee. Further, as shown in FIG. 7, it is assumed that “team 1” is registered as the attribute of the team desired by the player A. When the player B acquires a player card in the game, the reminder 203 checks whether or not the acquired player card is a “team 1” player card. Then, when the reminder 203 detects that the player B has acquired the player card of “Team 1”, the reminder 203 informs the terminal device 3 of the player B that the acquired player is a return object for the player A. . As a result, the player B can easily and quickly return the team attribute desired by the returnee.

  In addition, “what satisfies the return criteria for the first player who is the returnee” is the same as the rareness of the gift given by the first player (or the rareness within a predetermined range based on the rareness) Preferably). Here, the rare degree in the predetermined range is as described above. For example, as shown in FIG. 35, it is assumed that a remind setting is performed on the player B with the player A as a returnee. Further, it is assumed that the rare degree of the player card ID = “0010” presented by the player A is “3”. Then, when the player B has acquired a player card in the game, the reminding means 203 checks whether or not the acquired card is a player card with a rare degree of 3. Then, the reminding means 203 informs the terminal device 3 of the player B that the acquired one is a return object for the player A when detecting that the player B has acquired a player card with a rare degree of 3. As a result, the player B can easily and quickly return the rarity corresponding to the gift presented by the opponent.

  Next, an example of notification to the terminal device 3 of the player by the remind means 203 will be shown. Remind means 203 generates, for example, information (screen data) for displaying a remind screen shown in FIG. 36 when player B obtains what satisfies the return criteria for player A in the game. Transmit to device 3. On this remind screen, for example, a message “The card you have acquired is a card to be returned to Player A” and the acquired card 141 are displayed. In addition, information 142 (player name, team attribute, ability value, etc.) of the acquired card 141 is also displayed.

  Further, it is desirable that status information 143 indicating what kind of acquired card 141 is displayed on the remind screen. For example, if the acquired card 141 is registered as what the player A wants, the status information 143 “What the player A wants” is displayed. Further, for example, when the acquired card 141 is a team card of the player A, status information 143 “Player A team card” is displayed. This status information 123 is useful in determining the validity of the player B presenting the acquired card 141 to the player A. When executing the remind process, the remind means 203 that realizes this generates status information 143 based on information used as a return criterion (what the player A wants, the team attribute that the player A desires, etc.) The status information 143 is included in the notification screen and transmitted to the terminal device 3 of the player.

  Furthermore, information 144 regarding the number of possessed players B and information 145 regarding the number of possessed players A may be displayed on the remind screen. Such possessed number information 124 and 125 is also useful in determining the validity of the player B presenting the acquired card 141 to the player A.

  In addition, the remind screen is provided with an information area 146 for displaying “when and what kind of presents were received from whom”. That is, in this information area 146, the present date and time 147, the avatar 148 of the player A who gave the present in the past, the player card 149 presented and the information 150 (player name, team attribute, ability value, etc.), etc. are displayed. The By displaying these pieces of information, it becomes easy for the player B to determine the validity of presenting the acquired card 141 to the player A.

  In addition, a “return gift” button 151 is displayed on the remind screen. When the player B performs a return operation for selecting the “return gift” button 151, in response to the return operation, the return means 552 receives the acquired card 141 displayed on the remind screen as a return target person. A return process for presenting to a player A is executed. Thereby, the player can complete the present of return immediately on the remind screen.

  As described above, when the player B gives a reward for giving a notification when the reminding means 203 is notified (when the returning means 552 executes a return process), the releasing means 204 sets the remind setting corresponding to the return. Is released. That is, the canceling unit 204 deletes information that is no longer required to be reminded by the player B returning to the player A from the history information stored in the history information storage unit 202 that is the remind setting information.

  Alternatively, the “return gift” button 151 in the remind screen is set with a hyperlink for transition to the return gift operation screen. By selecting the button 151, for example, the return gift operation screen shown in FIG. You may make it transition to. When transitioning to the return gift operation screen via this remind screen, the player card displayed as the return candidate 121 in FIG. 22 is the same as the acquired card 141 in the remind screen in FIG.

  In addition, a “remind setting cancel” button 152 is displayed on the remind screen of FIG. Player B can manually cancel the remind setting without giving back by performing a cancel operation for selecting the “remind setting cancel” button 152. In response to the release operation of the player B on the terminal device 3, the release unit 204 releases the remind setting for the player B whose return target is the player A displayed on the remind screen.

  The remind screen of FIG. 36 also displays buttons for moving to other screens such as a “close” button 153 and a “main screen” button 110 for closing the screen and returning to the original game screen. Therefore, the player B can close the remind screen or move to another screen without returning or canceling the remind setting. In this case, the remind setting is not canceled. Therefore, when the player acquires what satisfies the return criteria at a later date, the reminder 203 notifies again, so that it is possible to prevent the present from being left unreturned.

  Here, a basic flow of the remind process of the game server 1 of the present embodiment will be described below with reference to FIGS. 37 and 38. Note that the flowcharts of FIGS. 37 and 38 show the flow of processing taking as an example a case where a present is given from player A as the first player to player B as the second player.

  As shown in FIG. 37, after the player B receives a present from the player A (YES in S91), if the player B does not give a present for return (NO in S92), the remind setting means 201 As shown in FIG. 35, the history information on the presents given to the player B from the player A is stored, and the remind setting is performed on the player B so that the player A is a returnee (S93).

  After that, if the reminder setting is not canceled (NO in S94) and the player B for whom the reminder setting has been made acquires a player card or item in the game (YES in S95), the acquired player is the returnee. A remind determination process is performed by the remind means 203 to determine whether or not a remittance criterion for a certain player A is satisfied and to determine whether or not a remind is necessary (S96).

  Here, an example of the remind determination process in step S96 will be described with reference to FIG. The reminder 203 determines whether the player B has acquired the same thing as the player A wants to be stored in the desired storage 51i (S101). If YES in step S101, what the player B has acquired satisfies the return criteria for the player A, so the remind setting means 201 determines that the remind is necessary (S102).

  In the case of NO in step S101, the reminding means 203 determines whether what the player B has acquired has the same attribute as the team attribute desired by the player A stored in the player attribute storage means 51j. (S103). In the case of YES in step S103, the reminder setting means 201 determines that the reminder is necessary because what the player B has acquired satisfies the return criteria for the player A (S102).

  In the case of NO in step S103, the reminding means 203 determines whether or not the rare degree of the thing acquired by the player B is the same as the rare degree of the gift given by the player A (S104). In the case of YES in step S104, the reminder setting means 201 determines that the reminder is necessary because what the player B has acquired satisfies the return criteria for the player A (S102).

  On the other hand, if the answer is NO in step S104, the reminder setting means 201 determines that the reminder is not necessary because what the player B has acquired does not satisfy the criteria for returning to the player A (S105).

  Returning to FIG. 37, the description is continued. When the remind means 203 determines that the remind is required in the remind determination process in step S96 (YES in S97), the remind means 203 notifies the player A that the acquired is a return object. The remind process for transmitting the information for the player B to the terminal device 3 is executed (S98). In the terminal device 3 of the player B that has received the information transmitted by the remind means 203, for example, a remind screen shown in FIG. 36 is displayed. Note that the reminding unit 203 may perform notification using voice.

  On the other hand, if it is determined in the remind determination process in step S96 that the remind is unnecessary (NO in S97), the process returns to step S94.

  Note that the remind determination process shown in FIG. 38 is an “OR condition” determination process that determines that a remind is required if any of S101, S103, and S104 is YES. Arbitrary remind determination conditions can be set by appropriately discarding the criteria and combining them with the “OR condition” or “AND condition”. For example, when the player B has acquired the “AND condition” of “same as the team attribute desired by the player A” and “same as the rareness of the gift given by the player A”, the reminder is necessary. If it does not meet the requirement, it is possible to eliminate the need for reminding.

  Furthermore, the following conditions similar to the above-described return candidate extraction conditions can be appropriately employed in the remind determination. For example, when what the player B has acquired is what the player A possesses, the reminder is not required. Further, when the player B has acquired a card having the team attribute desired by the player B, the reminder is not required. Further, when the player B has acquired what is stored by the holding information storage unit 512 and registered as the player B wants to hold, no reminding is required.

  Next, a configuration in which the canceling unit 204 automatically cancels the remind setting will be described. When the release unit 204 detects that the second player for which the remind setting has been performed by the remind setting unit 201 has made a return gift to the first player who is the return target, the cancel unit 204 selects the first player. It has a function of canceling the remind setting for the second player who is a returnee. This release means 204 is not limited to the case where the second player gives a return gift when the reminder means 203 is notified, but before the notification is given, the second player voluntarily Even when a return gift is given, if the release means 204 detects it, the remind setting is released. The release process of the release means 204 that realizes this will be described below with reference to the flowchart of FIG.

  When a player gives a present to another player (when the present means 55d executes a present process) (YES in S111), the release means 204 is set so that the player who made the present sets the remind setting by the remind setting means 201. It is determined whether the player is being performed (S112). This determination is performed by searching the database server 2 for the presence of the player ID of the present side present as “present player ID” in the history information of FIG. 35 stored in the history information storage unit 202. Can be executed. For example, in the case where player B presents to player A as an example, player ID = “000002” of player B is stored as “present player ID” with remind ID = “1” shown in FIG. Therefore, the determination in step S112 is YES.

  Further, in the case of YES in step S112, the canceling means 204 determines whether or not the player who has been presented this time is a returnee (S113). Taking the case where the player B presents to the player A as an example this time, this determination is made with the player ID of the player A on the side present this time as “present player ID” with the remind ID = “200” shown in FIG. This can be executed by checking whether the ID is stored. In this example, player ID = “000001” of player A is stored as “present player ID” with remind ID = “1”, so the determination in step S113 is YES.

  If it is determined YES in step S113, it is detected that the player who has set the reminder has given the returnee a return gift. In this example, the remind setting is canceled by deleting the history information (remind ID = “1”) (or processing that produces the same effect as the deletion, such as setting a cancel flag) (S114).

  On the other hand, when the player who has given the present time is not the player for which the remind setting means 201 has set the reminder (NO in S112), or the player who has given this time is not a returnee (NO in S113), the canceling unit 204 ends the process without canceling the remind setting.

  In this way, the canceling means 204 detects the return of each player and automatically cancels the remind setting, so that an unnecessary notification (remind) is issued even when the return has already been completed. The notification is made only when the player obtains an item that satisfies the return criteria for the unreturned opponent in the game. Even if the reminder 203 notifies, the reminder setting is not canceled unless the player returns (except when the player manually cancels). Therefore, when the player acquires what satisfies the return criteria at a later date, the reminder 203 notifies again, so that it is possible to prevent the present from being left unreturned.

  Next, in a configuration in which the remind setting is automatically performed, a preferable form in which the remind setting is determined only when a return gift and a normal gift that is not a return gift are determined and determined as a return gift will be described. If Player A gives a present to Player B instead of receiving a present from the other party, it is a normal present that is not a return. On the other hand, the player B who received a present from the player A presents the player A with a return gift. And, for the player A who receives the present of the return from the player B, the return for the return of the player B is not necessarily required.

  If the player manually sets the remind (for example, the player presses the remind button) (described later), the remind can be set only when he / she wants to return later. On the other hand, in the case of a configuration in which the remind setting is automatically performed, if the remind setting is made for all the presents from the opponent, the remind setting is also performed for the return gift, and the reminder (notification that is unnecessary for the player) is performed. ) May be performed. Therefore, in the case of a configuration in which the remind setting is automatically performed, it is preferable to determine whether the present from the other party is a normal present or a return gift and to perform the remind setting only in the case of a normal present.

  As shown in FIG. 34, the game server 1 that realizes this includes a present history storage unit 205 and a return determination unit 206. The present history storage unit 205 has a function of storing a present history in which a present player is associated with a present player when a present is performed between players. An example of the present history stored in the present history storage unit 205 is shown in FIG.

  As shown in FIG. 40, the present history storage unit 205 displays a present history including a present history ID, a present player ID, a present player ID, a present time, a return flag, etc. every time a present is given between players. And stored in a predetermined storage area of the database server 2. The present history may include information on the type of present and what was presented. Here, the return flag is information indicating whether or not it is a gift for return, and when the return flag is “1”, it is not a gift for return (ie, normal) Present). This return flag reflects the determination result by the return determination means 206 described below.

  The return determination means 206 is a return by the player on the side that the present has been given in the past based on the present history between the players stored in the present history storage means 205 when a present is given between the players. It has the function to determine whether it is. FIG. 41 shows an example of a return determination process by the return determination means 206.

  When a player gives a present to another player (YES in S121), the return determination unit 206 determines whether the present history between the two players exists in the information stored in the present history storage unit 205. Judgment is made (S122).

  Here, a case where player A gives a present to player B is taken as an example. If the present between the players A and B (that is, the present from the players A to B or the players B to A) is the first time, the present history between the players A and B does not exist, and NO in step S122. It is judged. In this case, the return determination means 206 determines that the present from player A to B is not return (S123). In this case, the present history storage unit 205 stores the present present history (S124) and sets the return flag to “0” (S125). Thereby, for example, the present history of present history ID = “10” in FIG. 40 is stored.

  On the other hand, when the present between the players A and B is not the first, and there are one or more present histories between the players A and B (YES in S122), the return determination unit 206 determines whether the present between the players A and B is the previous one. It is determined whether the return flag of the present history is “0” (S126). Here, when the previous return flag is “0” (YES in S126), since the previous present is not a return, the present present may be returned. Therefore, the return determination unit 206 determines whether or not the player who is present this time is the player who was presented last time (S127). If YES in step S127, the return determination unit 206 determines that the present gift is a return (S128). In this case, the present history storage unit 205 stores the present present history (S129) and sets the return flag to “1” (S130). Thereby, for example, the present history with present history ID = “20” in FIG. 40 is stored.

  On the other hand, when the return flag of the previous present history is “1” (NO in S126), since the previous present was a return, the return determination means 206 determines that the present is not a return (S123). . Also in this case, the present history storage unit 205 stores the present present history (S124) and sets the return flag to “0” (S125). Thereby, for example, the present history with present history ID = “30” in FIG. 40 is stored.

  Also, in step S127, if the player who has presented this time is the player who has also presented the previous time (NO in S127), the return determination unit 206 determines that the present gift is not a return ((S127)). S123). In this case, the present history storage unit 205 stores the present present history (S124) and sets the return flag to “0” (S125). Thereby, for example, the present history with present history ID = “40” in FIG. 40 is stored.

  Even if the return flag is not stored as described above, it can be determined whether or not the present gift is returned by checking all present histories between the players. However, as described above, when the present history is stored, the determination result (return flag) by the return determination unit 206 is also stored, so that it is possible to check all the present histories between the players. By confirming only the previous present history, it can be quickly determined whether or not the present present is a return.

  By the way, in the return determination process of FIG. 41, if the player B who received a present from the same player A gives a return to the player A once, the return of the player B is treated as being completed. On the other hand, it is possible that the return of the player B is not completed until the player B who has received the present from the player A a plurality of times returns the same number of times. Below, the structural example which implement | achieves the latter is demonstrated.

  As shown in FIG. 42, the present history storage unit 205 stores information on the unreturned person and the number of unreturned N (N is 0 or a positive integer) instead of the return flag. The unreturned person is information indicating which of the two players has not completed the return. FIG. 42 shows an example in which the player ID is stored as information about the unreturned person. The number N of unreturned is information reflecting the determination result by the return determination unit 206, and indicates the number of unreturned by the unreturned person. An example of the return determination process by the return determination unit 206 using the present history shown in FIG. 42 will be described below with reference to FIG.

  As shown in FIG. 43, when a player gives a present to another player (YES in S121), the return determination unit 206 includes the information stored in the present history storage unit 205 between the two players. It is determined whether a present history exists (S122).

  Here, a case where player A gives a present to player B is taken as an example. When there is no present history between the players A and B (NO in S122), the number N of unreturned rewards is initialized to “0” (S131), and the return determination means 206 determines that the present present is not a return. (S132). Then, the present history storage means 205 stores the present present history (S133), increments the unreturned number N (S134), and further stores the player ID of the player B as an unreturned person (S135). Thereby, for example, the present history of present history ID = “10” in FIG. 42 is stored.

  On the other hand, when one or more present histories exist between the players A and B (YES in S122), the return determination means 206 indicates that the number N of unreturned previous return histories between the players A and B is one or more. It is determined whether it exists (S136). Here, when the number N of unreturned is 1 or more (YES in S136), there is a possibility that the present gift is returned. Therefore, the return determination unit 206 determines whether or not the player on the present side is a player stored as an unreturned person in the previous present history (S137). If YES in step S137, the return determination unit 206 determines that the present gift is a return (S138). The present history storage unit 205 stores the present present history (S139) and decrements the number N of unreturned rewards (S140). If the number N of unreturned replies after decrement is “0” (YES in S141), the process ends without storing the information of unreturned persons. Thereby, for example, the present history of present history ID = “20” in FIG. 42 is stored.

  If the number N of unreturned replies after decrement is not “0” (NO in S141), all repayments by unreturned persons have not been completed, so the present history storage means 205 is the same again. The player ID is stored as an unreturned person (S135). For example, the present history with present history ID = “50” in FIG. 42 corresponds to this.

  In step S136, if the number N of unreturned gifts in the previous present history is “0” (NO in S136), the return determination unit 206 determines that the present gift is not returned (S132). Then, the present history storage means 205 stores the present present history (S133), increments the number N of unreturned rewards (S134), and further stores the player ID of the unreturned person (S135). Thereby, for example, the present history of present history ID = “30” in FIG. 42 is stored.

  Also, in step S137, if the player who presents this time is not a player who has been stored as an unreturned person in the previous present history (NO in S137), the return determination means 206 determines that the present present is It is determined that it is not a return (S132). Then, the present history storage means 205 stores the present present history (S133), increments the number N of unreturned rewards (S134), and further stores the player ID of the unreturned person (S135). Thereby, for example, the present history of present history ID = “40” in FIG. 42 is stored.

  Based on the determination result of the return determination unit 206, the remind setting unit 201 automatically performs the remind setting. That is, the remind setting unit 201 does not perform the remind setting when the present determination is made by the return determination unit 206 when a present is given from the first player to the second player. When the determination means 206 determines that the present is not a return, and the second player does not give a present to the first player, the remind setting is automatically performed. As a result, it is possible to avoid a remind setting (notification) that is unnecessary for the player because the remind setting is also made for the gift of return. Then, since the necessary remind setting is automatically performed only for the present which is not a return, only the necessary remind for the player can be surely performed.

  As shown in FIG. 40 or FIG. 42, when the present history storage unit 205 stores the present history every time a present is made between players, the remind setting unit 201 uses the present history to set the remind setting. It can be performed. That is, the history information storage unit 202 of the remind setting unit 201 sets a remind flag in the present history stored by the present history storage unit 205, instead of storing the history information shown in FIG. History information as information may be stored. An example is shown below.

  FIG. 44 is an example of storage information obtained by integrating the present history stored by the present history storage unit 205 and the history information stored by the history information storage unit 202. The present history storage unit 205 stores a present history including a present history ID, a present player ID, a present player ID, a type, a present, a present time, and a return flag every time a present is performed between players. The data is stored in a predetermined storage area of the database server 2. The history information storage unit 202 of the remind setting unit 201 sets the corresponding present history remind flag to “1” when it is detected that the normal gift that is not a return is not returned. . At this time, the remind setting time may be stored together. In this case, the remind setting can be canceled by changing the remind flag to “0”.

  By the way, in the case of a player having a large number of friends, if the reminder increases while exchanging presents with many friends, there is a possibility that the game will be troublesome. Therefore, a configuration in which the remind system is applied only to players having a predetermined familiarity or higher will be described below.

  As shown in FIG. 34, the game server 1 includes intimacy providing means 207. This closeness imparting means 207 is intimate with the two players when the exchange is performed between the two players (when the exchange process is executed between the two players by the exchange means 55). It has a function of giving intimacy indicating the thickness. Here, the intimacy indicates the intimacy of the two players, and can also be expressed as the degree of friendship between the two players, the depth of friendship, the depth of bonds, and the like. In addition, the exchanges to which intimacy is given can include various exchanges performed between friends, such as the aforementioned greetings, message transmissions, gifts, requests for assistants in cooperative battles, and chats. In addition, even when one invites the other to the game, it can be included in the exchange for which intimacy is given. Here, the invitation means that a player registered in the game service invites a person who is not registered in the game service to the game. When the invited person newly registers in the game service, the two players on the invited side are regarded as having strong connections, and given intimacy is given.

  For example, the closeness imparting means 207 of the present embodiment provides a closeness of a predetermined value (for example, 1 point) every time an AC process is executed between two players. In addition, you may change the value of the intimacy given according to the contents of exchange. For example, the greeting may be 1 point, the message transmission may be 2 points, the present and the battle cooperation may be 3 points, and the like. In addition, when there is no exchange between two players for a predetermined period (for example, one week or more), the intimacy decreases (for example, three points decrease every week) according to the length of the period without the exchange. It may be.

  Alternatively, at least one of the two players (or both of them) exchanges with the other party a predetermined number of times (for example, one week or more) within a predetermined period (for example, one week). In this case, closeness may be given to two players.

  Further, as described above, in addition to giving intimacy according to the number and frequency of exchanges between two players, in the case of an invitation, it is only one time, but the side that has been invited These two players may be regarded as having a strong connection and may be given a predetermined familiarity (for example, 50 points).

  In the present embodiment, for example, five ranks are provided according to the value of the closeness of the two persons. For example, the friendship rank is 0 to 24 points, the friendship rank is 25 to 49 points, the friend rank is 50 to 74 points, the friend rank is 75 to 99 points, the partner rank is 75 to 99 points, and the friend rank is 100 points or more.

  The intimacy imparting means 207 includes an intimacy storage means 207a. For example, as shown in FIG. 45, the closeness storage unit 207a stores the closeness value assigned to the two players in the database server 2 in association with the fellow information ID that uniquely identifies the fellow information. ing. The rank of intimacy may also be stored.

  The remind setting means 201 is a case where a present is given between two players, and the familiarity of the two players is lower than a predetermined familiarity (for example, an acquaintance rank lower than 25 points). ) Does not automatically set reminders. It should be noted that the predetermined familiarity for which the remind setting is not performed may be arbitrarily set by the player himself / herself by operating the terminal device 3.

  With the configuration of the present embodiment, reminding is applied only between players having a predetermined familiarity or higher. Therefore, it is possible to construct a remind system that can contribute to the maintenance of intimate communication with a player having a predetermined familiarity or higher while suppressing the troublesome reminder in the progress of the game.

  In the above description, an example in which intimacy is set for two friends is described. However, even players who are not in a fellow relationship can interact with each other. Density may be imparted.

  Next, a case where a player card or item acquired by the player for which the remind setting is performed during the game is a return object for a plurality of return target persons will be described below.

  Remind means 203 is obtained when a player who has been set for remind by means of remind setting means 201 acquires in the game a return object for a plurality of returnees. Notify that you are eligible for a return. In this case, it is preferable that the remind means 203 transmits information (remind screen) for displaying a higher return order to the return target person with a higher familiarity with the informing player to the terminal device 3 of the player. . Specific examples are shown below.

  For example, as shown in remind ID = “1”, “10”, “20”, “30” in FIG. 35, for player B with player ID = “000002”, player ID = “000001” (player A ), “000032” (player C), and “000038” (player D) are assumed to be set as a reminder. Further, as shown in the fellow information ID = “1”, “4”, “5” in FIG. 45, the closeness with the player B is 150 points for the player A (friend level) and 35 points for the player C. It is assumed that the player D is 70 points (best friend level). Then, when the player B acquires a player card that satisfies the return criteria for any of the three returnees in the game, the reminder means 203 obtains the player card as illustrated in FIG. Is sent to the terminal device 3 of the player B as a reminder screen that informs that it is a return object for the three players. In this remind screen, the display order of the three returnees is the order of player A, player D, player C, and the closeness.

  If the remind screen in FIG. 46 is larger than the physical screen area of the terminal device 3, all of the remind screen can be viewed by performing a scrolling operation or the like on the terminal device 3. The information area 146 for each player A, player D, and player C who is a returnee is displayed in order of the player with the highest intimacy, so the information area 146 of the player with the higher intimacy is confirmed without scrolling or the like. It is displayed at a position with good operability.

  As described above, regarding the display of the remind screen in the case where there are a plurality of returnees, the return order is higher for returnees who are more familiar with the informing player. This makes it easier for the player to give a return gift preferentially to a partner with higher intimacy, and a remind system that can contribute to maintaining intimate communication with the player with higher intimacy can be constructed.

  Alternatively, regarding the display of the remind screen when there are a plurality of returnees, the reminder 203 may increase the emphasis of the display for returnees who have a higher familiarity with the informing player. For example, the display order of the remind screen is the order of the returnees who gave presents earlier (in order of the present time), but the returnees who have a relatively high intimacy return a return of lower intimacy. Make the display stand out more than the target person. Specific examples of increasing the display emphasis include changing the color of characters and information area 146 of players A, D, and C, who are returnees, changing the brightness, making the light shine, adding a conspicuous mark, and making the character thicker. Various highlighting such as to do is conceivable. This makes it easier to give a return gift preferentially to a partner with a higher degree of intimacy, as well as maintaining a close communication with a player with a higher degree of intimacy, as in the case where the display order is higher for a returnee with a higher degree of familiarity. Remind system that can contribute to

  Further, when a player card or item acquired during the game by a player who has been set as a reminder is a target of return to a plurality of returnees, the reminder means 203 gives a return with a high number of reminders. It is preferable to transmit information (remind screen) for display with a higher display rank or higher display emphasis to the target person to the terminal device 3 of the player. The “number of times remind setting is performed” is the current number of remind settings, and does not include remind settings that have been set in the past but have already been released. A return target person with a large number of remind settings is a return target person with a high number of times that the player has received a present but has not returned. It would be rude to not give back to the person who gave you many gifts, so such an opponent is displayed with priority and highlighted so that it stands out on the remind screen. Specific examples are shown below.

  For example, as shown in remind ID = “1” and “30” in FIG. 35, the remind setting is performed twice with the player ID = “000001” (player A) as the person to be returned. In addition, as shown in the remind ID = “10” and “20”, the remind setting for each of 000032 ”(player C) and“ 000038 ”(player D) as a person to be returned is once. When B obtains a player card that satisfies the return criteria for any of the three returnees in the game, the remind means 203 sets the display order of the player A higher than that of the players CD. A screen is generated and transmitted to the terminal device 3 of the player B (see the remind screen in Fig. 46) In this case, since the remind setting for the players C and D as the person to be returned is one time, both players The display order of may be raised.

  Alternatively, for example, the reminding unit 203 may highlight the player A more prominently than the players C and D in the order of display of the remind screen in the order of the returnee who gave the present earlier. .

  This makes it possible to construct a remind system that makes it easier to give a return gift preferentially to a partner with a higher number of remind settings.

  In addition, you may combine the structure which raises a display order, and the structure which raises a display rank as a return object person with many frequency | counts of a reminder setting mentioned above. When combining both configurations, any configuration may be preferentially applied. For example, in the case where the latter configuration is preferentially applied, for example, the display order is higher for a returnee who has a higher number of remind settings, and the return order is higher for a returnee who has a higher degree of familiarity. To do.

  Next, a configuration in which the remind setting unit 201 performs the remind setting according to the manual operation of the player will be described. For example, as shown in FIG. 21, a “remind” button 155 is displayed on the screen displayed on the terminal device 3 after the player B receives the present from the player A. Player B does not immediately give a present of return to Player A, but performs an operation of selecting a “Remind” button 155 when setting a reminder. Thereby, a remind setting request is transmitted from the terminal device 3 of the player B to the game server 1. The remind setting unit 201 of the game server 1 stores the history information illustrated in FIG. 35 in response to the remind setting request, and performs a remind setting for the player B as a return target for the player B. As described above, the remind setting unit 201 may perform the remind setting based on a manual operation by the player, not automatically.

  Further, on the screen of FIG. 21, if the player B selects the “Give present in return” button 118, the screen returns to the return gift present operation screen shown in FIG. At the time when this return gift operation screen is displayed, the player B does not have an appropriate player card or the like as a return object, and therefore the player card that the player B wants to return is not presented as the above return candidate 121. There is also. Therefore, as shown in FIG. 22, a “remind” button 155 may be displayed on the return gift operation screen, and the remind setting may be performed by selecting the button 155.

  In the case where the remind setting unit 201 performs the remind setting based only on the manual operation by the player, the remind is set only when the player manually operates the remind setting (the operation of pressing the “Remind” button 155). Therefore, the player may perform a manual operation for setting a reminder only for an opponent who wants to return later, and if the manual operation is not performed, the player cannot return.

  Further, the remind setting means 201 has both a function for automatically setting a remind and a function for performing a remind setting based on a manual operation by the player, and the player sets the remind setting to “automatic” or “manual”. You may enable it to switch arbitrarily. For example, on a screen on which various settings relating to the game can be made, the player can operate the terminal device 3 to select whether the remind setting is “automatic” or “manual”. The game server 1 that has received the “automatic” or “manual” information selected by the player stores the information in the database server 2 in association with the player ID, and performs automatic or manual remind setting for each player.

  As described above, in the configuration of the present embodiment, a gift is given from the first player to the second player, which is another player, and the second player gives a return to the first player. Remind setting is performed automatically when a present is not performed or in response to a remind setting request from the terminal device 3 of the second player. Then, when the second player for which the remind setting has been performed acquires in the game what satisfies the return criteria for the first player who is the return target, the game server 1 is connected to the terminal device 3 of the second player. Announcement (remind) of the object of return. As a result, even if the player forgets to return to the other party who received the present, or who forgets what to return, the user can be reminded by the notification from the game server 1. it can. Therefore, it is possible to effectively avoid a situation in which the player forgets to return to the other party who received the present. Accordingly, it is possible to provide a game environment that can contribute to intimate communication between players because the presents are less likely to be left unreturned.

  Moreover, in this configuration, when the player obtains the return object in the game, the return object is immediately notified, so that a quick return is possible. Further, the notification of the return object does not require the player to perform a laborious and troublesome task of searching for a character or item to be presented to the opponent. Therefore, it is possible to give a return gift to the other party who has received the present easily and quickly, without the need for conventional labor.

[Another configuration example of the game management device]
Still another configuration example of the game management device will be described with reference to a functional block diagram of FIG. In addition, the same member number is attached | subjected about the structure similar to the structure shown in previous drawing, The description is abbreviate | omitted suitably.

  First, a schematic configuration of the game server 1 of the present embodiment will be described. In the above description, the configuration for notifying (reminding) a player when a player card or item to be paid back is acquired in the game has been described. However, the configuration for performing a reminder on the terminal device 3 of the player based on the elapsed time will be described below. explain.

  The game server 1 of the present embodiment is a case where a present is given from the first player to the second player, which is another player, and a return gift is given from the second player to the first player. If not, the remind setting is performed automatically or according to the manual operation of the second player. Then, the game server 1 performs notification (remind) of unreturned to the terminal device of the second player after a predetermined time elapses from the setting of the reminder or after a predetermined time elapses after being presented by the first player. It has a typical configuration. With this characteristic configuration, it is possible to effectively avoid a situation in which the player forgets to return, and to provide a game environment that can contribute to intimate communication between the players. Below, the detail of a structure of the game management apparatus (game server 1 grade | etc.,) Which concerns on this Embodiment which can provide such a game environment is demonstrated.

  As shown in FIG. 47, the game server 1 (game management apparatus) according to the present embodiment includes the game information management means 51, the game progress means 52, the authentication means 53, the fellow management means 54, the AC means 55, and the remind setting. In addition to means 201, history information storage means 202, release means 204, present history storage means 205, return determination means 206, intimacy giving means 207, remind means 303 (second remind means), unreturned history transmission means 304 , Extraction means 356 (second extraction means), return candidate transmission means 357 (second return candidate transmission means), and the like. Remind means 303, unreturned history transmission means 304, extraction means 356, and return candidate transmission means 357 are realized by CPU 11 of game server 1 executing the program according to the present embodiment.

  Note that the game server 1 of the present embodiment shown in FIG. 47 may or may not include the reminding means 203, the extracting means 56, and the return candidate sending means 57 described above.

  The game server 1 according to the present embodiment performs the remind setting for the second player who has not returned, using the remind setting means 201 described above, with the first player as the person to be returned. As shown in FIG. 35, the history information stored in the history information storage unit 202 of the remind setting unit 201 as the remind setting information includes at least one information of a remind setting time or a present time. Then, the reminder 303 notifies that the first player has not been repaid when a predetermined time (for example, one week) has elapsed since the reminder was set for the second player by the reminder setting unit 202. For transmitting information to the terminal device 3 of the second player. That is, the reminding means 203 performs a reminding process to the terminal device 3 of the second player (present player ID) on the condition that a predetermined time has elapsed from the reminding set time included in the history information shown in FIG. Notification process).

  Alternatively, the reminding means 303 returns a return to the first player when a predetermined time has elapsed since the second player for which the remind setting was made by the remind setting means 202 was presented to the first player who is the returnee. It has the function to transmit the information for notifying that it is not doing to the terminal device 3 of a 2nd player. That is, the reminding means 203 executes the reminding process to the terminal device 3 of the second player (presented player ID) on condition that a predetermined time has elapsed from the present time included in the history information shown in FIG. To do.

  In many cases, there is no great difference between the case where the remind process is executed after a predetermined time has elapsed with the remind time set as the reference time and the case where the remind process is executed after the predetermined time has passed with the present time as the reference time. However, after the process in which the first player gives a present to the second player, it may take several days for the second player to perform an operation to receive the present (for example, a present is received after 2 to 3 days). Sometimes). In such a case, since the remind setting is delayed several days with respect to the present time, the timing for executing the remind process is also several days depending on the remind setting time and the present time. Different. However, in order to avoid a situation where the player forgets to return, either the remind setting time or the present time may be used as the reference time. Hereinafter, the description will be continued with an example in which the remind setting time is used as a reference time.

  Here, the “predetermined time” that is the time until notification can be set to an arbitrary time such as 5 days, 1 week, 10 days, 2 weeks, or the like. Further, a plurality of “predetermined times” may be set for each remind setting, and a plurality of notifications may be performed if the remind setting is not canceled. For example, if “predetermined time” is set to two stages of 1 week and 2 weeks, the remind process is executed after 1 week from the reference time, and if the remind setting is not canceled after that, 2 weeks after the reference time The remind process is executed again. Further, the reminding process may be executed repeatedly every predetermined time until the reminding setting is canceled. For example, when “predetermined time” is set to n weeks (n is a positive integer), the remind process is executed many times every week if the remind setting is not cancelled.

  Further, the “predetermined time” may be arbitrarily set (changed) by the player himself / herself by operating the terminal device 3. The remind means 203 of the game server 1 stores a default value (for example, one week) of “predetermined time”, which is a time until notification, in a storage device (RAM 13, auxiliary storage device 14 or the like). Then, the reminding unit 203 normally executes a reminding process with “predetermined time” as a default value. On the other hand, when the player performs an operation of setting (changing) the “predetermined time” independently, the reminder 203 associates the “predetermined time” with the player ID in the predetermined area of the database server 2 in accordance with the operation. Remember. In this case, the reminding means 203 executes the reminding process by applying the “predetermined time” set by the player himself.

  Next, an example of notification to the terminal device 3 of the player by the remind means 303 will be shown. Here, it is assumed that a remind setting is performed on the player B with the player A as a returnee. Remind means 303 generates, for example, information (screen data) for displaying a remind screen shown in FIG. 48 and transmits the information to terminal device 3 of player B after a predetermined time has elapsed since the remind setting was performed. If the terminal device 3 of the player B is not accessing the game server 1 after a predetermined time has elapsed since the remind setting is performed, the terminal device 3 of the player B accesses the game server 1 for the first time thereafter. At this time, the reminding means 303 transmits the data of the remind screen to the terminal device 3 of the player B.

  For example, a message “Return to Player A has not been completed yet” is displayed on the remind screen shown in FIG. In addition, the remind screen is provided with an information area 146 for displaying “when and what kind of presents were received from whom”. That is, in this information area 146, the present date and time 147, the avatar 148 of the player A who gave the present in the past, the player card 149 presented and the information 150 (player name, team attribute, ability value, etc.), etc. are displayed. The

  48, a “main screen” button 110, a “returned candidate display” button 116, a “greeting” button 117, a “gift in return” button 118, and the like are displayed.

  For example, after setting the reminder, it may take time until the player card or the like to be returned is acquired in the game. Therefore, when a notification is made on the remind screen, there are cases where a character to be returned cannot be obtained yet. However, it is not good to leave without returning for a long period of time, even if you cannot get a player card for return. In such a case, the player B can greet the player A by selecting the “greet” button 117 and send a message to the player A on the message input screen shown in FIG. it can. For example, the player B can respond to the player A by sending a message to the effect that he / she has not yet acquired what he / she will return but will give it later.

  Further, if the player B selects the “present in return” button 118 on the remind screen, for example, the player B transitions to the above-mentioned return gift operation screen of FIG.

  Further, in a configuration in which the remind process is repeatedly executed every predetermined time until the remind setting is canceled, a “remind setting cancel” button 152 may be displayed on the remind screen. Player B can manually cancel the remind setting without giving back by performing a cancel operation for selecting the “remind setting cancel” button 152. In response to the release operation of the player B on the terminal device 3, the release unit 204 releases the remind setting for the player B whose return target is the player A displayed on the remind screen.

  The remind screen also displays buttons for moving to other screens such as a “close” button 153 and a “main screen” button 110 for closing the screen and returning to the original game screen. Therefore, the player B can close the remind screen or move to another screen without returning or canceling the remind setting.

  Here, a basic flow of the remind process of the game server 1 of the present embodiment will be described below with reference to FIG. Note that the flowchart of FIG. 49 shows the flow of processing taking as an example a case where a present is given from player A as the first player to player B as the second player.

  As shown in FIG. 49, after the player B receives a present from the player A (YES in S91), if the player B does not give a present for return (NO in S92), the remind setting means 201 As shown in FIG. 35, the history information on the presents given to the player B from the player A is stored, and the remind setting is performed on the player B so that the player A is a returnee (S93).

  Thereafter, the reminding means 303 determines whether or not a predetermined time (for example, one week) has elapsed since the reminding setting was performed for the player B without releasing the reminding setting (NO in S94) (S151). . That is, as shown in FIG. 35, since the history information stored at the time of the remind setting includes the remind setting time, the reminding unit 303 determines that the predetermined time (for example, one week) from the remind setting time. Judge that it has passed.

  If YES in step S151, the reminding means 303 determines whether the terminal device 3 of the player B is accessing (logging in) the game server 1 (S152). Here, if the terminal device 3 of the player B is accessing the game server 1 (YES in S152), the reminding means 303 provides information for notifying the player A who is a returnee that he / she has not returned. Then, a remind process to be transmitted to the terminal device 3 of the player B is executed (S158). On the other hand, if the terminal device 3 of the player B does not access the game server 1 when a predetermined time has elapsed from the remind setting time, then when the game server 1 is accessed for the first time (YES in S152), the remind is performed. The means 303 executes a remind process (S158). On the terminal device 3 of the player B that has received the information transmitted by the remind means 303, for example, a remind screen shown in FIG. 48 is displayed. Note that the reminding unit 303 may perform notification using sound.

  With this configuration, since the reminder is set (or after being presented by the other party), a notification is given to the terminal device 3 of the player after a predetermined time has elapsed, so that a situation in which the player forgets to return can be effectively avoided. . Therefore, with this configuration, it is possible to provide a game environment in which presents are less likely to be left unreturned and contribute to intimate communication between players.

  Further, when the game server 1 according to the present embodiment detects that the second player, for which the remind setting unit 201 has performed the remind setting, has given a return gift to the first player who is the return target. It is desirable to include the above-described canceling means 204 for canceling the remind setting for the second player who makes the first player the returnee. As described above, the release means 204 is not limited to the case where the second player gives a return gift when the notification is made, but the second player voluntarily returns the notification before the notification is made. Even when the present is made, if the release means 204 detects it, the remind setting is automatically released. Therefore, it is possible to avoid an inconvenient situation in which unnecessary notification (remind) is performed even if the return has already been completed, and to accurately notify the unreturned only when the player has not returned. Become.

  By the way, it is desirable that the second player can confirm unreturned information on which the reminder is set even before the reminder 303 performs the reminder. For example, if the second player performs an operation of selecting the “unreturned list” button 75 on the main screen shown in FIG. 12, an unreturned confirmation request is transmitted from the terminal device 3 of the second player to the game server 1. The The unreturned history transmission unit 304 reads the history information of the second player stored in the history information storage unit 202 of the remind setting unit 201 in response to the unreturned confirmation request from the terminal device 3 of the second player. , And a function of transmitting information (unreturned list screen data) for displaying the history information to the terminal device 3.

  FIG. 50 shows an example of an unreturned list screen that the unreturned history transmission unit 304 transmits to the terminal device 3 of the second player. This unreturned list screen is the same as the screen transmitted by the unreturned history transmitting means 59 (see FIG. 31). On the unreturned list screen, present information received from the unreturned partner as unreturned history 160 (information that can be used to identify when and what presents were received from) is displayed in a list. When the second player confirms each unreturned history 160 and wants to return, he selects the “Giveaway in return” button 118 corresponding to each unreturned history 160 to give a return present as shown in FIG. You can transition to the operation screen.

  As a result, the second player for which the remind setting is performed can always display his / her unreturned history of his / her terminal device even before the predetermined time has elapsed or after the predetermined time has elapsed. 3 can be confirmed. In this way, by allowing the second player to check the unreturned history at any time regardless of the occurrence timing of the reminder, the present is less likely to be left unreturned.

  Note that the second player may check each unreturned history 160 and decide to cancel the reminder. Therefore, a “remind setting cancel” button (not shown) corresponding to each unrefunded history 160 is displayed on the unreturned list screen of FIG. 50, and the player can manually cancel the remind setting on the screen. You may do it.

  By the way, in the case where a notification (remind) is generated when a player obtains a player card or item to be returned in the game, the return target is presented to the player at the same time as the notification. You can return quickly without searching from scratch. On the other hand, in a configuration in which a notification is generated after a predetermined time has elapsed from the remind setting, the return object is not presented at the time of notification, and the player needs to search for the return object. Therefore, in a configuration in which a notification is generated after a predetermined time has elapsed from the remind setting, a preferred embodiment in which return candidates at the time of notification are extracted and the return candidates are also presented to the terminal device 3 of the player at the same time as the notification is described below. To do.

  The game server 1 according to the present embodiment includes an extracting unit 356 and a return candidate sending unit 357. The extraction means 356 presents the first player as a reward when information for notifying the first player that he / she has not returned is sent to the terminal device 3 of the second player. Therefore, the return reward candidate is extracted from those possessed by the second player stored in the possession information storage unit 511. The extraction unit 356 performs the same extraction process as the extraction unit 56 shown in FIG. The extraction unit 356 differs from the extraction unit 56 in that the extraction unit 356 performs the extraction process when information for notifying the first player that the first player is not returned is transmitted to the terminal device 3 of the second player. This is only the timing of the extraction process to be executed. Therefore, a detailed description of the extracting unit 356 is omitted.

  The return candidate transmission unit 357 has a function of transmitting information for displaying the return candidate extracted by the extraction unit 356 to the terminal device 3 of the second player together with the notification information transmitted by the remind unit 303. That is, the return candidate transmission unit 357 transmits the return candidate data simultaneously with the transmission of the remind screen data by the remind unit 303. Thereby, as illustrated in FIG. 51, the player screen of the return candidate 121 and the like are displayed on the remind screen together with information notifying the player A that he / she has not returned.

  51, the player card information 122 (player name, team attribute, ability value, etc.) as the return candidate 121, status information 123, possession number information 124/125, and a “candidate change” button 126 are displayed. , A “return gift” button 127, a “keep” button 133, and the like are also displayed. Details of these information and buttons have already been described, and a description thereof will be omitted here.

  The flowchart in FIG. 52 shows the flow of the remind process for presenting the return candidate to the player simultaneously with the remind. This flowchart also shows the flow of processing in which a gift is given from player A as the first player to player B as the second player.

  As shown in FIG. 52, after the player B receives the present from the player A (YES in S91), if the player B does not give a reward for the return (NO in S92), the remind setting means 201 As shown in FIG. 35, the history information on the presents given to the player B from the player A is stored, and the remind setting is performed on the player B so that the player A is a returnee (S93). Thereafter, the reminder setting is not canceled (NO in S94), and a predetermined time (for example, one week) has elapsed since the reminder setting was performed for the player B (YES in S151). When the terminal device 3 accesses the game server 1 (YES in SS152), the extraction means 356 executes an extraction process for extracting a return reward candidate from the player cards etc. owned by the player B (S53). An example of the return candidate extraction process in step S53 is as shown in FIG. 30, and a detailed description thereof is omitted here.

  Thereafter, the remind means 203 and the return candidate transmission means 357 cooperate to generate a remind screen (see FIG. 51) including the return candidates extracted in step S53 and transmit it to the terminal device 3 of the player B (S153). Thereby, the reminder screen illustrated in FIG. 51 is displayed on the terminal device 3 of the player B.

  Here, when the “candidate change” button 126 on the remind screen is selected by the player B, the game server 1 receives a candidate change request from the terminal device 3 of the player B (YES in S154), and returns to step S53 to return to another. The player card extraction process is executed. Each time the “change candidate” button 126 is selected by the player B, steps S53 and S153 are executed, whereby the player card of the return candidate 121 of FIG. 51 is changed.

  Then, when a return operation for selecting the “return gift” button 127 is performed by the player B while a player card is displayed as the return candidate 121 (YES in S155), the return means 552 is displayed by the player B. A return process for presenting the return candidate 121 owned to the player A is executed (S156).

  In the screen of FIG. 51, when other operation is performed without the “return gift” button 127 being selected by the player B (YES in S157), the game server 1 executes processing according to the operation. (S158).

  As described above, since a return candidate is also automatically presented to the terminal device 3 of the player at the same time as the notification of unreturned, the player gives a player card or the like to return to the opponent when the notification of unreturned is received. Eliminates the need for the laborious and troublesome task of finding out. Therefore, it is possible to provide the player with an environment in which a return gift can be easily and quickly given to an unreturned partner when an unreturned notification is made.

  In addition to the configuration in which the return candidates are automatically presented to the terminal device 3 of the player simultaneously with the notification of the unreturned, only when the player who has received the notification of the unreturned performs an operation for requesting the return response. It may be configured to present a return candidate. For example, as shown in FIG. 48, the return candidate is not initially displayed on the remind screen displayed on the terminal device 3 by the notification of unreturned. Then, by performing an operation of selecting the “returned candidate display” button 116 on the remind screen shown in FIG. 48 (an operation for requesting a returned candidate), the screen changes to the screen shown in FIG. 51 so that the returned candidate 121 is displayed. To. Alternatively, by performing an operation of selecting the “Give back in return” button 118 on the remind screen shown in FIG. 48 (this may be an operation requesting a return candidate), the screen returns to the return gift operation screen shown in FIG. The return candidate 121 is displayed. The extraction means 356 that realizes the request requests a return candidate at the terminal device 3 of the second player that has received the information transmitted from the remind means 303 to notify that the first player has not returned. The second information stored in the possession information storage means 511 is received as a return candidate for receiving the operation information from the terminal device 3 and presenting it as a return to the first player. From those owned by the player. The difference between the extracting unit 356 and the extracting unit 56 described above is only the timing of the extraction process.

  As described above, in the case of a configuration in which a return candidate is requested only when the player wants to return, the return candidate extraction process in the game server 1 is performed more than the configuration in which the return candidate is automatically displayed simultaneously with the notification of unreturned. The burden is reduced.

[Other Embodiments]
In the above-described embodiment, the game execution program is installed on the game server 1 side, and the game server 1 executes arithmetic processing and data processing for progressing the game in response to an input operation on the terminal device 3 of each player. Then, the application example to the game system in which the game progresses by transmitting the screen data reflecting the execution result to the terminal device 3 has been described. This is a so-called client-server game system, but is not limited to this. For example, the game server 1 manages game information including possession information such as items of the player and provides game services such as present management within the game to the player, while the game execution process for advancing the game is basically Specifically, the game management device, the game management method, and the program according to the embodiment of the present invention can also be applied to a game system performed on the terminal device side of the player.

  In other words, the present invention can also be applied to a game system in which a part or all of the game execution program is downloaded or installed on the terminal device side of the player and the game execution process is also performed on the terminal device. For example, a player terminal device communicates with other player terminal devices by Internet communication, wireless LAN communication, short-range wireless communication using a predetermined frequency band (for example, 2.4 GHz frequency band), or wired LAN communication. It is also possible to execute a peer-to-peer game by connecting two to peers.

  Therefore, various devices that can be connected to a game server (game management device) and receive a game service such as present management can be applied as the terminal device of the player. In addition to terminals, personal digital assistants (PDAs), personal computers, and tablet computers, home video game devices having a network connection function (constituted by connecting home video game machines to home televisions) Game devices) and portable game-dedicated devices are also applicable.

  The computer-readable program according to the present embodiment is recorded on various computer-readable recording media such as a hard disk, an optical disk (CD-ROM, DVD-ROM, etc.), a flexible disk, a semiconductor memory, and the like. Is executed by the CPU 11 of the game server 1. The means for providing the program to the game server 1 is not limited to the recording medium described above, and can be performed via a communication network such as the Internet.

1 Game server (game management device)
2 Database server (game management device)
3 Terminal device 4 Network 11 CPU
12 ROM
13 RAM
14 Auxiliary storage device 51 Game information management means 52 Game progress means 54 Associate management means 55 Exchange means 55d Present means 56 Extraction means 57 Returned candidate transmission means 58 Unreturned history storage means 59 Unreturned history transmission means 201 Remind setting means 202 History information Storage means 203 Reminding means 204 Canceling means 205 Present history storing means 206 Refund determination means 207 Intimacy giving means 303 Reminding means 304 Unreturned history transmitting means 356 Extracting means 357 Returning candidate sending means 511 Owned information storing means 551 Unreceived present storing means 552 means of return

Claims (13)

A game management device that manages a game that communicates with a terminal device of each player and is capable of presenting what the player owns in the game to other players,
Ownership information storage means for storing what each player owns;
When a gift is given from the first player to the second player, a gift for giving to the first player from among those owned by the second player stored in the possession information storage means An extraction means for extracting return candidates,
A game management device comprising: a return candidate transmission unit that transmits information for displaying the return candidate extracted by the extraction unit to a terminal device of a second player.   When a return operation for presenting the return candidate to the first player is performed on the terminal device of the second player receiving the return candidate transmission means and displaying the return candidate. In addition, the information processing apparatus further comprises a return means for receiving the operation information from the terminal device and executing a return process for presenting the return candidate owned by the second player to the first player. The game management device described in 1. In the case where a process of giving a gift from the first player to the second player is performed, it further includes unreceived gift storage means for storing what was presented until the second player receives the gift,
When the number of possessions of what each player can own in the game has an upper limit, and the possession number of the second player has reached the upper limit, the return means is transmitted from the return candidate transmission means. When a return operation for presenting the return candidate to the first player is performed on the terminal device of the second player receiving the return information and displaying the return candidate, Received from the terminal device, deletes the return candidate from the possession of the second player, presents it to the first player, and from the first player stored in the unreceived present storage means The game management device according to claim 2, wherein the content stored in the possession information storage means is updated so that the second player receives and owns the gift. In response to a desired item registration request from a terminal device operated by each player, the player further includes desired item storage means for storing the desired item of each player,
In the case where a present is given from the first player to the second player, the extraction means stores the desired thing storage means among those owned by the second player stored in the possession information storage means. The game according to any one of claims 1 to 3, wherein when it is detected that there is a desired thing of the first player stored in the game, what the first player wants is extracted as the return candidate. Management device. Any one of a plurality of attributes is set in at least a part of what each player can own in the game,
In response to an attribute registration request from the terminal device operated by each player, the apparatus further comprises player attribute storage means for storing any one of the plurality of attributes and the attribute desired by each player,
In the case where a present is given from the first player to the second player, the extracting means includes the player attribute storage means among those owned by the second player stored in the possession information storage means. 4. When detecting that there is an object having the same attribute as the desired attribute, the one having the same attribute is extracted as the return candidate. The game management device according to item. Any one of a plurality of attributes is set in at least a part of what each player can own in the game,
In response to an attribute registration request from a terminal device operated by each player, player attribute storage means for storing any one of the plurality of attributes and the attribute desired by each player;
And a desired storage means for storing what each player wants in response to a desired registration request from a terminal device operated by each player,
The extracting means sets the priority to be extracted as the return favor candidate in descending order of what the first player wants stored in the want storage means and the first player stored in the player attribute storage means. Having the same attribute as the desired attribute, having an attribute different from the attribute desired by the first player,
Each time the return candidate transmission means receives a candidate change request from the terminal device of the second player, the information for displaying the return candidates in order from the high priority priority return candidates, The game management device according to claim 1, which is transmitted to a terminal device of the player. At least a part of what each player can own in the game has a rarity value indicating a high rarity value,
In the case where a present is given from the first player to the second player, the extracting means includes the ones owned by the second player stored in the possession information storage means from the first player. The detected object is extracted as the return candidate when it is detected that there is a rare value having the same value as the rare value of the present or a predetermined range of rare values based on the rare value. The game management device according to any one of 3 and 5. In response to a holding request from the terminal device of the player, the information processing device further includes holding information storage means for storing what is selected from those owned by the player as not to be returned,
The game management device according to claim 1, wherein the extraction unit extracts the return reward candidates by excluding those stored in the stored information storage unit. When a present is given from the first player to the second player and an operation for holding back is performed at the terminal device of the second player, the operation information is received and the first player Unreturned history storage means for storing an unreturned history indicating that the second player has not returned to the present from the player,
Information for reading the unreturned history of the second player stored in the unreturned history storage means and displaying the unreturned history in response to an unreturned confirmation request from the terminal device of the second player The game management device according to any one of claims 1 to 8, further comprising: an unreturned history transmission means for transmitting the message to the terminal device. When a present is given from the first player to the second player and a remind setting operation is performed at the terminal device of the second player, the operation information is received and the first player A history setting means for storing history information on presents from the first player to the second player and performing a remind setting for the second player as a returnee for the second player;
When the second player for which the remind setting is performed by the remind setting means obtains in the game a return criterion for the first player who is the return target, the acquired player is the first player. The game management device according to any one of claims 1 to 9, further comprising: a reminding unit that transmits information for notifying the user of the return to the terminal device of the second player. .   The extraction means presents to the first player out of those possessed by the second player stored in the possession information storage means in response to a return candidate request from the terminal device of the second player. The game management device according to claim 1, wherein a candidate for return is extracted. A game management method in a game management device that communicates with a terminal device of each player and manages a game in which the player can present what the player owns in the game to other players,
The game management device stores ownership information stored by each player;
In the case where a present is given from the first player to the second player, the game management device has a first one out of those possessed by the second player stored in the possession information storing step. An extraction step of extracting return reward candidates for giving to the player;
A game management method comprising: a return candidate transmission step in which the game management device transmits information for displaying the return candidate extracted in the extraction step to a terminal device of a second player. A program for causing a computer to operate as the game management device according to any one of claims 1 to 11, wherein the program causes the computer to function as each unit included in the game management device.

Images