JP5789248B2 - GAME MANAGEMENT DEVICE AND PROGRAM - Google Patents

Description

  The present invention relates to a game management device, a game system, a game management method, and a program for managing a game.

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

  There has also been proposed a game system in which users 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 user becomes friends with other players who use the game service, and the users can interact with each other, such as exchanging gifts between the friends. .

JP 2001-129240 A JP 2011-110139 A

  In a conventional game system, when a user gives a present to a friend, it is not what he / she wants to keep but also wants the other party The work of searching for the item and operating the present occurs. Thus, in order for a user to give a present to a friend, since the troublesome work of searching for an item to be presented is necessary, some users do not actively give presents.

  The present invention has been made in view of the above problems, and its purpose is to provide a user with an environment where gifts can be easily given to other users such as friends and group members who have a predetermined association with the user. It is to promote presents.

  1) A game management device (1, 2, 101, 102, 301, 302) according to one aspect of the present invention has a management means (51) for managing other users related to a user and the user in response to a possession release request from the user. Release means (52) for executing possession release processing of the held object, and notification conditions for notifying the possession release processing of information relating to the benefit of the object to be released to the other user Whether or not the notification condition is satisfied based on the game information of the other user when the object for the possession release process is designated by the user. When the determination means (54) and the determination means (54) determine that the notification condition is satisfied, the specified object is executed before the holding release process is executed. And informing means for informing information related to the benefits to other users of transfected into user (55), and a.

  The game management device having this configuration can be configured by an information processing device (computer) such as a server capable of communicating with each user's game terminal (terminal device), for example. Or this game management apparatus can also be comprised by the information processing apparatus as a game terminal. Or this game management apparatus can also be comprised by the some information processing apparatus (a server, a game terminal) which mutually communicates.

  This game management device includes management means for managing other users such as friends and group members who have a predetermined association with the user. Here, friends are generic names for virtual relationships between users built in the game, such as acquaintances, friends, friends, classmates, fellows, relatives, families, brothers, sisters, colleagues of companies and organizations, etc. Including various in-game relationships. In addition, if it is the other user linked | related with the user, it may not be a relationship of a friend. However, in the following description, for the sake of convenience, “another user related to the user” is described as “a friend” as a representative.

  In addition, the game management device includes a release unit that executes a process for releasing the possession of an object held by the user in response to a possession release request from the user. Examples of possession release processing include “sale processing”, “mixer processing”, “combination processing”, and the like. The “sale process” is a process for selling an object (item or the like) owned by the user and converting it into an in-game point or the like. The “mixer process” is a process of exchanging a plurality of (for example, two) objects held by the user with another one or a plurality of objects. The “merging process” is a process in which a specific object (player card, etc.) possessed by the user is merged with another object, thereby changing the parameters of the other object (enhancing the ability, etc.). is there. In any of the “sale process”, “mixer process”, and “merging process”, the user's possession of the object to be processed is canceled. Note that the possession release process is not limited to these, and may be another process involving the release of the possession of the object owned by the user.

  And in this structure, when the object for a possession cancellation | release process is designated by the user, before execution of a possession cancellation | release process, the information regarding the benefit to the friend of the designated object is alert | reported to a user. For example, when an object (such as a player card) designated by the user for the sale process is an object desired for a friend, the user is notified of that. In order to realize this, the game management apparatus includes the following condition relation means, determination means, and notification means.

  The condition associating means relates information relating to the notification condition for notifying information relating to the benefit of the object to be retained to the fellow to the possession canceling process. For example, a condition that an object for “sale process” designated by the user is what the friend wants to register is related to “sale process”. For example, the condition that the object for “mixer processing” specified by the user is “a player card of a fellow team” and “rare degree 4 or higher” is related to “mixer processing”. As the notification condition, a condition as shown in the configuration of 8) to 10) described later, or any other condition can be set.

  When the object for the possession release process is designated by the user, the determination unit determines whether or not the notification condition related to the possession release process is satisfied based on the fellow game information. Here, as an example of the friend's game information, information on “desirable things” registered in advance by the user's friends can be cited. In addition, as another example of the game information of the friend, there is information on the team (for example, any one of 12 professional baseball teams in the case of a baseball game) set by the friend at the start of the game. In addition, in determining the notification condition, it is possible to refer to game information of various friends.

  Then, when the determination unit determines that the notification condition is satisfied by the determination unit, the notification unit notifies the user of information related to the benefit of the designated object to the companion before the execution of the possession release process. For example, if there is a friend who registered the object that the user wants to sell (if the notification condition related to the sale process is satisfied), that fact is displayed on the screen of the user's terminal device, Encourage gifts to the fellow. In addition, the prompt of the present is not essential, and it may be left to the user to determine whether or not to present.

  As described above, in this configuration, when the user tries to cancel the possession of the object, information regarding the benefit of the object to the companion such as that there is a companion who wants the object is timely To be notified. Thereby, it can be made to know before the execution of a holding release process that the object which it was going to release possession for a user is useful for a friend. Therefore, the user can be made interested in the friend and the sale of the object or the like can be changed to a gift for the friend. In other words, the user can get an opportunity to make the object he / she wants to give away to the friend without having to do the troublesome work of finding the object to give to the friend. Can do. By this structure, the environment which is easy to give a present to a friend can be provided to a user, a present can be promoted, and the communication of a friend can be activated.

  2) In the above configuration, it is desirable that there are a plurality of possession release processes, and the condition relating means (53) associates information on the notification condition for each possession release process.

  According to this configuration, the possession release process includes a plurality of processes such as “sale process”, “mixer process”, and “merging process”, and different notification conditions can be associated with each possession release process. An example in which different notification conditions are related depending on the type of possession release processing is shown below.

  For example, the “merging process” has an intention that the user wants to strengthen a specific object by merging (for that purpose, let go of the merged object). For this reason, even if the combined object is beneficial to the fellow, giving it to the fellow will also stop the reinforcement that he was trying to execute, so the present of the combined object will be given to the user It is assumed that hesitates.

  In addition, “mixer processing” is executed with the expectation that an object that is desirable for the user may be obtained by exchange, so although it is not as much as “coalescence processing”, the user still wants to refrain from presents. is assumed.

  On the other hand, “sales processing” is to convert an object that the user originally determined to be unnecessary into in-game points, and in-game points can also be obtained by selling other objects. The psychological barrier is considered to be low.

  Therefore, for those who have a particularly high expectation for acquisition, such as those registered as “desirable” by the fellow, any of “sale processing”, “mixer processing”, and “combining processing” is executed. The notification condition is related to each of these processes.

  Also, if you want to have friends, for example, “Player cards of fellow teams” with “rare degree 4 or higher”, before executing “sale process” and “mixer process” The user is notified, and the notification condition is related to each of these processes.

  In addition, what a friend may want, for example, “a player card of a fellow team” with a “rare degree of 3” is reported to the user only before the “sale process” is executed. And the notification condition is related to the process.

  As described above, by associating different notification conditions depending on the type of possession release processing, appropriate notification according to each possession release processing is performed, and an environment in which gifts can be easily given to friends can be provided to the user.

  3) In the above configuration 1) or 2), it is preferable that the information related to the notification condition is related to each range of other users determined based on the game information related to the other users.

  According to this configuration, different notification conditions can be associated with the same possession release process (for example, sale process) for each other user's range (hereinafter also referred to as a companion range). Here, the “companies range” is, for example, “friendship with the user” as shown in 4) described later, “in-game level of friends” as shown in 5), and “friends” as shown in 6). Can be determined on the basis of “game information about friends” such as “frequency of access to the game”. Alternatively, the “companion range” can also be determined based on a fellow user ID, a user name, or the like. For example, different notification conditions can be set for a friend whose intimacy is greater than or equal to a predetermined level (for example, greater than or equal to the best friend level) and a friend whose degree of friendship is lower (for example, a friendship level).

  This configuration allows not only to associate different notification conditions depending on the type of possession release process, but also to associate different notification conditions for each range of associates for the same possession release process. Appropriate notification according to the range is performed, and it is possible to provide the user with an environment in which it is easy to give presents to friends.

  4) In the configuration of 3) above, the information processing apparatus further includes intimacy providing means (58) for providing intimacy to the two related users, and the range of the other user is intimacy with the user. It is desirable to be determined based on

  Here, intimacy refers to the intimacy of two users who have established a friendship relationship, and can also be expressed as the degree of friendship between two people, the depth of friendship, the depth of bonds, etc. . For example, the closeness of the two people can be set based on the number and frequency of exchanges in the game.

  For the user, it is desirable to increase the opportunities for giving presents to friends with higher intimacy. According to this configuration, for example, different notification conditions can be set for a friend whose intimacy is greater than or equal to a predetermined level and for a friend who is lower than that. For example, in the range of 3 or more friends with 5 levels of intimacy, those that are registered as "desired" by the friends and "player cards of fellow teams" and "rare degree is 5 levels The notification condition is set so as to notify the user before the execution of the sale processing or the like for any of “3 or more”. On the other hand, in the range of friends whose degree of intimacy is 2 or less, a notification condition is set so that only information registered by the friend in “what is desired” is notified to the user before execution of the sale process or the like. With this configuration, it is possible to make appropriate notifications according to the intimacy of friends.

  5) In the configuration of 3) or 4) above, it is preferable that the range of the other user is determined based on the in-game level of the other user.

  Here, the in-game level is an index indicating the progress of the game and the proficiency level of the game, and is improved by progressing the game or by satisfying a predetermined victory condition in the battle game. Or

  For example, a friend who has a low in-game level (such as a friend who has just started the game) will be happy to present an object that is not rare, but for a friend who has a high in-game level, There is a high possibility that you will not be very pleased if you present an object that is not very rare. Therefore, the range of friends is determined based on the in-game level of the friends, and different notification conditions are associated with each range of friends.

  For example, in the range of friends with an in-game level of 30 or more, users who are “competitor team player cards” and whose “rare degree is 4 or more in 5 stages” before the execution of sale processing, etc. The notification condition is set so as to notify the user. On the other hand, in the range of friends who have an in-game level of 29 or less, the user will be informed about the “friends card of a fellow team” and “rare degree 3”, before the execution of the sale process or the like. Set the notification condition. With this configuration, appropriate notification according to the level of the friend in the game becomes possible.

  6) In any one of the above configurations 3) to 5), it is preferable that the range of the other user is determined based on an access frequency of the other user to the game.

  For friends who frequently access the game, communication can be activated by giving gifts to each other. On the other hand, it can be said that a friend who has a low access frequency to the game is less likely to give a present in the first place because the game is not often played. Then, the range of a friend is defined based on the access frequency to a friend's game, and different alerting | reporting conditions are related for every range of a friend.

  For example, in the range of friends who access the game for four days or more in one week, those that are registered in the “what you want” and “player cards of fellow teams” that have a “rare degree of 5” The notification condition is set so as to notify the user before the execution of the sale process or the like for any of “stage 3 or more”. On the other hand, in the range of friends with a lower access frequency than the above, a notification condition is set so that only information registered by the friend as “desired” is notified to the user before the sale process or the like. In addition, for example, a condition that notification is not performed may be set in a range of a friend who is below a predetermined access frequency (for example, one day or less per week). With this configuration, appropriate notification according to the access frequency of a friend's game can be performed.

  7) In the configuration of any one of 1) to 6) above, the information processing apparatus further includes a closeness giving means (58) for giving closeness to two related users, and the determining means (54) When the object for the possession release process is designated by the user, it is desirable to determine whether or not the notification condition is satisfied by limiting the game information of other users higher than a predetermined familiarity.

  According to this structure, the report | combination object friend is limited to a friend higher than a predetermined familiarity (for example, 2 of 5 steps). This is due to the following reason. That is, in the case of a user who has many friends, notification is frequently made when trying to let go of the object, which may be bothersome. Therefore, it is limited to the game information of friends higher than a predetermined familiarity, it is determined whether or not the notification condition is satisfied, the processing load is reduced, and the notification target friend is made a friend of a predetermined familiarity or higher. The frequency of notification is limited and limited, and the troublesomeness of notification is avoided.

  8) In the configuration of any one of 1) to 7) above, the information further includes a desired item registration means (56) for registering what each user desires in response to a request from each user. It is preferable that a condition that the object for the possession release process specified by the user is what the other user wants to register is included.

  According to this configuration, each user can register what he / she wants (what he / she wants with objects such as characters and items that the user can possess). And when the object for the possession cancellation | release process designated by the user is what a friend wants to register, that is notified to a user. Thereby, it can be made to know before the execution of the possession cancellation | release process that the object which it was going to cancel | release possession for a user wants a friend, and the present to a friend can be promoted.

  9) In the configuration of any one of 1) to 8) above, any one of a plurality of attributes is set in the object, and the plurality of attributes are set according to a request from each user. Attribute registration means (57) for registering the attribute desired by each user, and the notification condition includes an object for the possession release process specified by the user. It is desirable that a condition that the attribute registered by the attribute registration means (57) has the same attribute as the desired attribute is included.

  According to this configuration, any one of a plurality of attributes is set for an object (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 user can register a desired attribute of any one of the plurality of attributes. And when the object for the possession cancellation | release process designated by the user is what has the same attribute as the attribute which the associate wanted, that is notified to a user. Thereby, it can be made to recognize before the execution of the possession cancellation | release process that the object which was going to cancel | release possession for a user is useful for a friend, and the present to a friend can be promoted.

  10) In the configuration of 9) above, the object is set with a rarity value level indicating a high rarity value, and the notification condition includes an object for the possession release process specified by the user. It is desirable to include a condition that the scarcity value is a predetermined scarcity value.

  According to this configuration, a rare value level (the above-mentioned rare degree) indicating a high level of rare value is set for an object (a character, an item, or the like). Even if an object has an attribute that a friend wants, an object with a low degree of rarity is often not pleased by the other party and may not be suitable as a gift target. Therefore, in this configuration, the notification condition is set by combining the condition of the attribute desired by the friend described above and the condition of the rare degree. For example, a condition that the object for possession release processing specified by the user is “a player card of a fellow team (a team attribute desired by the fellow)” and “a rarity is 3 or more in 5 stages” The notification condition is used. As a result, appropriate notification in consideration of the rare degree can be performed.

  11) A game system according to another aspect of the present invention includes a server (1, 2, 101, 102) and a terminal device (3, 301, 302) that communicates with the server (1, 2, 101, 102). A management means (51) for managing other users related to the user, a release means (52) for executing a holding release process of an object held by the user in response to a holding release request from the user, A condition associating means (53) for associating information relating to notification conditions for notifying information relating to usefulness of the object to be released to the other user to the possession release process, When the object is designated by the user, based on the game information of the other user, determination means (54) for determining whether the notification condition is satisfied, and the notification condition by the determination means (54) A notification means (55) for notifying the user of information related to the benefit of the specified object to the other user before execution of the possession release processing when it is determined that the server (1, 1, 2, 101, 102) or the terminal device (3, 301, 302).

  12) A game management method according to another aspect of the present invention is a game management method in a computer that manages a game, in which the computer manages other users related to the user, A release step of executing a holding release process of the object held by the user in response to a holding release request from the user, and the computer performs the other release of the object to be held for the holding release process. When the user specifies a condition relating step for relating information relating to notification conditions for notifying information relating to benefit to the user, and an object for the possession release processing, the computer can play the game of the other user. A determination step of determining whether the notification condition is satisfied based on information; and A notification step of notifying the user of information relating to the benefit of the specified object to the other user before the execution of the possession release process when the notification step determines that the notification condition is satisfied. And including.

  13) A program according to another aspect of the present invention is a program for causing a computer to operate as a game management device (1, 2, 101, 102, 301, 302) for managing a game. Management means (51) for managing a user, release means (52) for executing a possession release process of an object held by the user in response to a possession release request from the user, Condition associating means (53) for associating information related to notification conditions for notifying information related to the benefit of the object to be released to the other user, when the object for the possession release processing is designated by the user Determining means (54) for determining whether or not the notification condition is satisfied based on the game information of the other user; (55) a notification means for notifying the user of information related to the benefit of the specified object to the other user before executing the possession release processing when it is determined that the notification condition is satisfied by (54) There is a program to make it function as.

  ADVANTAGE OF THE INVENTION According to this invention, the environment which is easy to give a present to other users, such as the associate linked | related with the user, can be provided to a user, and a present can be promoted.

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 explanatory drawing which shows an example of the main screen of a game. It is explanatory drawing which shows an example of the screen which displays the designated card | curd. It is explanatory drawing which shows an example of the screen displayed before sale processing. It is explanatory drawing which shows an example of the screen containing the alerting | reporting information displayed before a sales process. It is explanatory drawing which shows an example of the screen displayed before a mixer process. It is explanatory drawing which shows an example of the screen containing the alerting | reporting information displayed before a mixer process. It is explanatory drawing which shows the other example of the screen containing the alerting | reporting information displayed before a mixer process. It is explanatory drawing which shows an example of the screen displayed before a unification process. It is explanatory drawing which shows an example of the screen containing the alerting | reporting information displayed before a unification process. It is a functional block diagram which shows an example of the basic functional structure of a game management apparatus. It is explanatory drawing which shows an example of the information regarding a user's game. It is a functional block diagram which shows an example of main functional structures of a game management apparatus. It is explanatory drawing which shows an example of the information which linked | related holding cancellation | release process and alerting | reporting conditions. It is a functional block diagram which shows the other example of main functional structures of a game management apparatus. It is explanatory drawing which shows the other example of the screen containing the alerting | reporting information displayed before a sale process. It is a flowchart which shows the operation example of the game server when a user tries to perform possession cancellation | release processing. It is a functional block diagram which shows the other example of main functional structures of a game management apparatus. It is explanatory drawing which shows an example of the information which defined the range of the friend based on the familiarity, and related the possession cancellation | release process and alerting | reporting conditions. It is explanatory drawing which shows an example of the information which defined the range of the friend based on the game level, and linked | related the possession cancellation | release process and alerting | reporting conditions. It is explanatory drawing which shows an example of the information which defined the range of the friend based on the familiarity and the game level, and linked | related the possession cancellation | release process and alerting | reporting conditions. It is explanatory drawing which shows an example of the information which defined the range of the friend based on the access frequency to a game, and linked | related holding cancellation | release process and alerting | reporting conditions. It is explanatory drawing which shows an example of the information which defined the range of the fellow based on the information etc. which identify | isolate an individual, and linked | related holding cancellation | release process and alerting | reporting conditions. It is explanatory drawing which shows an example of the screen which a user sets arbitrarily alerting | reporting conditions. It is explanatory drawing which shows the example of a setting in the screen of the said FIG. It is explanatory drawing which shows the other example of the screen in which a user sets alerting | reporting conditions arbitrarily. It is explanatory drawing which shows the other example of the screen in which a user sets alerting | reporting conditions arbitrarily. It is a functional block diagram which shows the other example of main functional structures of a game management apparatus. It is explanatory drawing which shows an example of the screen for setting an alerting | reporting condition automatically. It is explanatory drawing which shows the example of a screen displayed when alerting | reporting conditions are set automatically. It is a block diagram which shows the other structural example of a game system. It is a block diagram which shows the other structural example of a game system.

  Hereinafter, a game management device, a game system, 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 user that can be communicably connected.

  The network 4 according to the present embodiment is not limited to the Internet. For example, as long as the game server 1 and the terminal device 3 of each user can be connected to each other so as to communicate with each other, for example, a dedicated line, a public line, etc. 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 can be configured from a game server 1 and a database server 2. The game server 1 receives access from the terminal device 3 of each user who receives the game service via the network 4 and stores and manages game information of each user in the database server 2 (storage device). A game service is provided via the network 4.

  As a form of providing a game service by the game server 1, a game program (application software) is installed in the game server 1, and a game operation is not performed on the terminal device 3 but on the terminal device 3. There is a form in which a game is executed on the game server 1 in response to an input, and the execution result is transmitted to the terminal device 3 of each user. For example, the game server 1 provides a so-called browser game in which a game can be played by a web browser installed in the terminal device 3 of each user. Alternatively, the game server 1 provides a so-called cloud gaming service in which a game video as a result of executing a game on the game server 1 is transmitted to the terminal device 3 in, for example, a streaming format.

  Alternatively, as will be described later, a game system in which part or all of the game execution program is installed on the user's terminal device 3 side and the game execution processing is also performed on the terminal device 3 can be provided.

  In the present embodiment, an example in which a browser game is provided 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 on the user's terminal device 3, and the user can easily connect to 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, 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 user. Then, the game server 1 updates the game information of each user 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 user terminal device 3 (Game screen data) is transmitted to the terminal device 3 of each user.

  Each user's terminal device 3 is equipped with a web browser having a website browsing function as a user 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. A personal computer (hereinafter referred to as “PC”), a tablet computer, a game device having a communication function (stationary or portable game device), or a multi-function television receiver having a bidirectional communication function ( Various terminals that can be connected to the game server 1 via the network 4 and receive a game service can be applied, such as a so-called smart TV.

  In addition, the game provided in the present embodiment can have a so-called social game element that allows the user to play while interacting with other users 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. In this way, a game service can be provided to the user by a 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 into the SNS system. Good.

  The game management device according to the present embodiment has a friend who wants the object (character, item, etc.) held by the user when the possession of the object (character, item, etc.) is to be canceled (sold). The information about the benefit of the object to the friend is notified to the user in a timely manner. Accordingly, the user tries to cancel the possession for the user, and notices that the object is beneficial for the friend before the possession release, and promotes the present to the friend. Below, the detail of a structure of the game management apparatus (game server 1 grade | etc.,) Which concerns on this Embodiment which implement | achieves this is demonstrated.

[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 programs and the like necessary for basic operation control of the game server 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 user 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 user managed by the game server 1. The database server 2 stores various game information (user name, level, in-game points, possessed items, etc.) of each user in association with identification information (user ID) for uniquely identifying each user, for example. 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 user operates the terminal device 3 to access the game server 1, an authentication server having an authentication function for determining whether the user is a legitimate user 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 user 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 users who use this game service reaches several hundred thousand, millions, or more, it is required to construct a server system that can withstand huge access from the terminal device 3 of many users. 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 user 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 user, various terminals having a website browsing function such as a mobile phone terminal and a smartphone can be applied as described above. In this embodiment, a mobile terminal is illustrated as an example. The configuration will be described. Note that the terminal device 3 other than the mobile terminal is also 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 terminal.

  A mobile terminal having a website browsing function or the like is also called a feature phone, a smart phone, or the like, and its configuration example is shown in FIG. 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 or an 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 the like 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 a user operation input 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.

  Moreover, it is good also as a structure which CPU31 analyzes the audio | voice input from the audio | voice input part 37 using general audio | voice recognition technology, and can perform various inputs with an audio | voice.

  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 terminal device 3 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 having the above-described configuration, a user who wants to receive a game service performs an input 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 user 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. Hereinafter, similarly, the user 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.

[Game description]
Examples of games provided by the game management device include sports / racing games, simulation games, training games, soccer, baseball, tennis, American football, basketball, volleyball, golf, boxing, horse racing, car racing, etc. Various games such as role-playing games and quiz games can be listed regardless of the game format and genre. As an example, in the present embodiment, an example in which a game management device mainly manages a baseball game will be described below.

  In the present embodiment, a baseball game in which a user owns a player character corresponding to a real player of professional baseball (or MLB) in the game and creates his / her team using the player character is taken as an example.

  The player character owned by the user 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 by the game server 1 as a digital player card and displayed on the screen of the user terminal device 3. Further, the player character may be drawn by three-dimensional computer graphics in a game or the like in the game. Further, a player character, a ball object, or the like may be displayed as a moving image in a streaming format or the like. The user can collect player cards (hereinafter simply referred to as “cards”) while proceeding with the game, form his own original team, and play against other users. The user can set the player's batting order and position in the “order mode” in the game. In addition, the user can improve the ability of the character displayed on the card by combining (synthesizing) the collected cards (i.e., nurturing the character), and aim for a stronger team. have fun.

  FIG. 4 shows an example of the main screen (my page) of the game. This main screen includes an image 201 of a character selected as a leader among cards owned by the user, game information 202 of the user (user level, various in-game points, the number of owned player characters, the number of friends, etc.) Is displayed.

  In-game points of the present embodiment include action points, operating costs, reinforcement points, lottery points, and the like. The action point is a game progress point used in a “scout mode” in which an in-game area (stage) is searched and a player is virtually scouted. The operation cost is a point used in “game mode” in which a game is played with other users in a game, which is a cost required for managing a game. The strengthening point is a point used in the “strengthening mode” in which the character is strengthened by combining (combining) a plurality of cards owned by the user. The lottery point is a point used in the “lottery mode” in which a card can be obtained by lottery. For example, the lottery points can be obtained when the user interacts with other users in the game.

  The main screen also displays a button group 203 for selecting each mode of scout, game, reinforcement, lottery, order, and player management. Furthermore, various information such as various menu buttons (not shown) and notifications from the system operator are displayed by scrolling the screen by operating the direction keys and the touch panel of the terminal device 3.

  In this game, the user can obtain a card (object) by executing the above-described “scout mode” or “lottery mode”. An upper limit (for example, 60) can be set for the number of cards (number of players) that the user can hold in the game.

  In this game, “sale processing”, “mixer processing”, “combination processing”, and the like can be executed on the cards possessed by the user. Each of these processes will be described below.

  The “sale process” is a process for selling an object owned by the user and converting it into in-game points. In this game, the user can sell the cards he / she holds and convert them into strengthening points. By the “sale process”, the object held by the user is released.

  An example of the sale operation by the user is shown below. When the player management button 203a is pressed on the main screen of FIG. 4, the player management screen is moved to a player management screen (not shown), and a card list of players held by the user is displayed. Here, if the user designates (selects) a specific card, the screen transits to the screen illustrated in FIG. 5, and the designated card 210 and card information 211 are displayed. The card information 211 includes a player name, team, position, ability value, and the like. In addition, a sale button 212, a present button 213, an exchange button 214, and the like are also displayed on the screen. The sale button 212 is a button for selling the card 210 designated by the user. The present button 213 is a button for presenting the card 210 designated by the user to another person.

  If the user presses the present button 213 on the screen of FIG. 5, a transition is made to a not-shown present screen, and a list of friends is displayed. If the user designates a partner to be given from among the friends and executes the present, the user can give the designated card 210 to the friend.

  Further, when the user presses the sale button 212 on the screen of FIG. 5, the screen transitions to the screen illustrated in FIG. The screen of FIG. 6 is a screen that is displayed before the sale process is executed. The strengthening point information 215 that can be obtained when the card 210 specified by the user is sold and the sale execution button 216 for executing the sale process are displayed. Is displayed. If the user presses the sale execution button 216, the game server 1 executes the sale process for the designated card 210. When this sale process is executed, the designated card 210 is excluded from the cards owned by the user, and the strengthening points as the consideration are added as the user's owned points.

  Here, in this game, when the sale button 212 is pressed on the screen of FIG. 5, the user's friend wants (or seems to want) the card 210 designated for sale by the user. The game server 1 determines whether it is a card or the like. This determination is based on whether or not a predetermined notification condition related to the sale process is satisfied (details will be described later). As a result of this determination, if it is a card or the like that the friend wants, the game server 1 notifies the user of information related to the benefit of the designated card 210 to the friend before executing the sale process. For example, the game server 1 displays the screen illustrated in FIG. 7 on the user terminal device 3 instead of the screen of FIG. For example, an imaginary character 220 appears on the screen shown in FIG. 7 displayed before the sale process is executed, and the effect is such that the user wants to sell the card that the friend wants to sell. I do. In addition, the user is encouraged to give a friend a card that is about to be sold. In FIG. 7, the text display area 221 displays a message “The card you are going to sell is a card that is registered for what you want to associate B. How about giving it to friend B without selling?” An example to be displayed is shown.

  In addition, information 222 related to the present target friend (avatar or photograph of the friend, name, game level, intimacy, etc.) extracted as satisfying the notification condition is displayed on the screen of FIG. In addition, a present button 223 for presenting the designated card 210 to the present target friend is displayed. When the user presses the present button 223, the game server 1 executes present processing for changing the ownership of the card 210 from the user to a friend to be presented. In this case, the sale process is not executed. In the present process, the user may be able to input a message, and the message may be delivered to the other party together with the present.

  Next, “mixer processing” will be described. The “mixer process” is a process of exchanging a plurality of (for example, two) objects held by the user with one (or a plurality of) other objects. By the “mixer process”, the possession of the plurality of objects possessed by the user is released. In this game, if the user specifies two cards that he / she owns and executes the mixer process, the user can exchange the cards for one card with the same rarity. In order to execute the mixer process, a predetermined amount of in-game points owned by the user may be required.

  FIG. 8 shows an example of a screen before execution of the mixer process. On the screen, two cards (first card 231 and second card 232) designated by the user and a mixer execution button 217 are displayed. If the user presses the mixer execution button 217 on this screen, one card is randomly extracted from all the cards in the game (however, only the cards having the same rarity level as the mixer processing target cards). Then, the two cards 231 and 232 to be processed by the mixer are not owned by the user, and the extracted one card is owned by the user.

  Here, in this game, when the screen of FIG. 8 is displayed, the two cards 231 and 232 designated by the user for the mixer process are desired (or desired) by the user's companion. The game server 1 determines whether it is a card or the like. This determination is based on whether or not a predetermined notification condition related to the mixer process is satisfied (details will be described later). As a result of this determination, if it is a card or the like that the friend wants, the game server 1 notifies the user of information regarding the benefit to the friend of the designated card 231 or 232 before executing the mixer process. . For example, the game server 1 displays the screen illustrated in FIG. 9 on the user terminal device 3 instead of the screen of FIG. In the example of the screen of FIG. 9, an imaginary character 220 appears, and an effect is given to talk to the user that the card that the mixer is trying to process is what the friend wants. Also, it is recommended that the user presents a card to be processed by the mixer to a friend. In FIG. 9, in the text display area 221, a message “The first card that is going to be processed by the mixer is a friend B's team card. How about giving it to the friend B without the mixer processing?” An example in which is displayed.

  Further, on the screen of FIG. 9, information 222 related to the present target companion extracted as satisfying the notification condition is displayed. Further, a present button 223 for presenting a designated card (first card 231 in the example of FIG. 9) to the present target friend is displayed. When the user presses the present button 223, the game server 1 executes present processing for changing the ownership of the first card 231 from the user to a friend to be presented. In this case, the mixer process is not executed.

  FIG. 9 shows an example in which only one card 231 of the two cards 231 and 232 specified by the user is notified to the user as a card that the friend B wants. If the condition is satisfied, the user may be notified of both cards 231 and 232 as cards that the friend B wants.

  Further, as illustrated in FIG. 10, one of the two cards 231 and 232 designated by the user is notified to the user as a card desired by the friend B, and the other card 232 is also displayed. May be reported to the user as a card that another friend C wants. FIG. 10 shows an example in which a button 224 for presenting the first card to the friend B and a button 225 for presenting the second card to the friend C are displayed on the screen. . In this case, the user can give two cards that were going to be mixed by the operation of the buttons 224 and / or 225 to the companion B and the companion C, respectively, or only one of the cards can be targeted. It can also be given to friends.

  Next, the “merging process” will be described. The “merging process” is a process of changing a parameter of another object B by combining the specific object A held by the user with the other object B. By the “merging process”, the possession of the object A possessed by the user is cancelled. In this game, the “merging process” is executed in the reinforcement mode. The user designates one or a plurality of cards owned by the user as the reinforcement material, and designates one card to be strengthened to execute the merge process. Thereby, according to the capability of the card | curd of reinforcement | strengthening material, the capability of the card | curd of reinforcement | strengthening object improves. The execution of this “joining process” requires a strengthening point possessed by the user. The required amount of reinforcement points may be constant, or may be variable according to the degree of rareness and ability of the reinforcement target and / or the reinforcement material.

  An example of the “coalescence process” operation by the user is shown below. In the main screen of FIG. 4, if the strengthen button 203b is pressed, the screen changes to the strengthen mode screen, and one card to be strengthened and one or a plurality of strengthen material cards are selected from the cards held by the user. Can be specified. FIG. 11 shows an example of the reinforcement mode screen when one reinforcement target card 241 and one reinforcement material card 242 are designated by the user. In this screen, when the user presses the merge execution button 245, the merge processing of the reinforcement target card 241 and the reinforcement material card 242 is executed, and instead of losing the reinforcement material card 242, it depends on the ability of the reinforcement material card 242. As a result, the ability of the reinforcement target card 241 is improved.

  Here, in this game, when the screen of FIG. 11 is displayed, the reinforcement material card 242 designated by the user for the coalescing process is desired (or likely to be desired) by the friend of the user. The game server 1 determines whether it is a card or the like. This determination is based on a determination as to whether or not a predetermined notification condition related to the coalescing process is satisfied (details will be described later). As a result of this determination, if it is a card or the like that a friend wants, the game server 1 notifies the user of information related to the benefit to the friend of the specified reinforcing material card 242 before the merge process is executed. For example, the game server 1 displays the screen illustrated in FIG. 12 on the user terminal device 3 instead of the screen of FIG. 11. In the example of the screen of FIG. 12, a fictitious character 220 appears, and the reinforcement material card 242 that is to be subjected to the coalescing process produces an effect such as talking to the user that the friend wants it. In addition, the user is encouraged to give the reinforcement material card 242 to a friend. In FIG. 12, a message “Reinforcement material card is a card registered for what Buddy B wants. How about giving it to Bmate without joining?” Is displayed in the text display area 221. An example is shown.

  Moreover, the information 222 regarding the friend of present object extracted as satisfy | filling alerting | reporting conditions is displayed on the screen of FIG. Furthermore, a present button 223 for presenting the reinforcement material card 242 to the present target friend is displayed. If the user presses the present button 223, the game server 1 executes present processing for changing the ownership of the reinforcement material card 242 from the user to a friend to be presented. In this case, the coalescing process is not executed.

[Functional configuration and operation of game management device]
Next, an example of a functional configuration of a game management device that realizes the above game will be described. FIG. 13 is a functional block diagram showing a basic configuration of a game management device (game server 1 and database server 2) that communicates with the terminal device 3.

  The game management apparatus according to the present embodiment includes user information storage control means 60, reception means 61, execution means 62, screen generation means 63, transmission means 64, access management means 65, AC control means 66, and the like. Each of these means is realized by the CPU 11 of the game server 1 executing the program according to the present embodiment.

  The user information storage control means 60 stores and manages information related to each user's game in the database server 2. FIG. 14 shows an example of a user information database (information for one user ID = 000001 in this example) stored in the database server 2 by the user information storage control means 60, which is information related to the user's game.

  The user information storage control means 60 associates basic information about each user such as a login ID, password, user name (nickname used in the game), team, etc. The data is stored in a predetermined storage area of the server 2. Here, the login ID and password are used for login authentication when each user operates the terminal device 3 to access the game server 1. The user name and the team are arbitrary information set by the user when the user registers to use the game service or when the game is executed for the first time. In this embodiment, each user can register any one desired team among a plurality of teams (for example, 12 types of team attributes corresponding to 12 professional baseball teams in the real world). . Details of team registration will be described later. The user name and team are displayed on the game screen as necessary.

  Further, the user information storage control means 60 stores information on the user's game level (in-game level) in the database server 2 in association with the user ID. In this baseball game, for example, experience values are accumulated as the user progresses the game, and the level of the user is increased when the experience value reaches a certain amount.

  Further, the user information storage control means 60 stores in the database server 2 information (player ID, ability value, etc.) of the player character card owned by the user in the game in association with the user ID. Further, the database server 2 has a player database (player DB) in which player character image data, player names, positions, teams, and the like are stored in association with player IDs. Based on the player ID stored by the information storage control means 60, the image data of the player character corresponding to the player ID can be acquired.

  Further, the user information storage control means 60 stores various points (including values corresponding to points) and items owned by the user in the game in the database server 2 in association with the user ID. Each item is assigned an item ID that uniquely identifies them, and is managed by the item ID.

  Further, the user information storage control means 60 stores the fellow user ID in the database server 2 in association with the user ID.

  Further, the user information storage control means 60 stores the user access log (the date and time information accessed to the game server 1) in the database server 2 in association with the user ID.

  Next, the reception means 61, execution means 62, screen generation means 63, and transmission means 64 shown in FIG. 13 will be described. The reception unit 61 and the transmission unit 64 are functions realized by the CPU 11 and the communication control unit 15 of the game server 1.

  When the game screen is displayed by the web browser of the user's terminal device 3, when the user performs an input operation to select a selectable button object or a character string with a hyperlink on the game screen, Information regarding the input (game screen request or the like) is transmitted to the game server 1 by the web browser of the terminal device 3. In the game server 1, when the receiving unit 61 receives the information related to the input, the executing unit 62 reads the information related to the user's game in accordance with the information and executes the game by performing calculations and data processing.

  For example, when the user performs an input operation for playing against another user's team in the match mode, the execution means 62 is a player character of both teams corresponding to the user IDs of both users who are playing the battle. Information on (characters participating in the game) is read from the database server 2. Then, the execution means 62 executes a baseball game simulation based on parameters such as the ability of the player characters of both teams by an AI (Artificial Intelligence) program or the like, and determines the outcome of the game.

  Next, the screen generation means 63 will be described. The screen generation unit 63 generates game screen data composed of, for example, HTML data in accordance with the execution result by the execution unit 62. The HTML data may include image data such as characters 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. Alternatively, the screen generation unit 63 may generate a video in a streaming format.

  Further, the transmission means 64 uses the screen data (HTML data, streaming format video data, etc.) generated by the screen generation means 63 as a response to the request for the game screen or as an execution result by the execution means 62, as a user terminal. Transmit to device 3. In the terminal device 3 of the user who has received the game screen data, the game screen is displayed on the display unit 35 by a web browser and its plug-in.

  Next, the access management means 65 will be described. When a user who wants to receive a game service operates the terminal device 3 to access (log in) the game server 1, the access management means 65 determines whether or not the user has a game participation qualification and performs login authentication. Do. An example of this authentication is authentication based on a login ID and password associated with a user ID. 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 user does not have to input a login ID and a password each time the user accesses the game server 1. 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.

  Next, the AC control means 66 will be described. The AC control means 66 implements user interaction and communication performed in the game. The AC control means 66 receives information for performing predetermined AC exchange with other users (particularly friends) from the user's terminal device 3, and from the user to the other users based on the received information. The execution means 62 that executes all AC processing is controlled. Examples of the AC processing include greetings, message transmission, presents, battle cooperation, and chat.

  Next, the main functional configuration of the game management device (game server 1 and database server 2) will be described with reference to the functional block diagram of FIG. The game server 1 as a game management device mainly includes a fellow management means 51 (management means), a release means 52, a condition association means 53, a determination means 54, and a notification means 55. Each of these means is realized by the CPU 11 of the game server 1 executing the program according to the present embodiment.

  The associate management means 51 has a function of managing associates related to the user. As one form for a user to establish a friendship relationship with another user, either one of the two users makes a friend application to the other user via the game server 1, and the friend application is made. The friend application made between both users and the operation of the approval that the received user approves becoming a friend via the game server 1 are mentioned. As another form, when a user who has already been registered in the game service invites an unregistered user to the game, and the user who has been invited registers in the game service, the user who has been invited is set to 2 There is also a form in which human users are friends. As illustrated in FIG. 14, the fellow management unit 51 associates user IDs of users who are in a fellow relation, stores them in the database server 2, and performs fellow management.

  The canceling means 52 has a function of executing a possession canceling process for an object held by the user in response to a possession canceling request from the user. In the present embodiment, as the holding release process, there are the above-mentioned “sale process”, “mixer process”, and “merging process”. The release unit 52 includes a sale processing unit 52a that executes “sale processing”, a mixer processing unit 52b that executes “mixer processing”, and a coalescence processing unit 52c that executes “merging processing”.

  The sale processing unit 52a will be described. If the user presses the sale execution button 216 on the screen of FIG. 6 or FIG. 7, a sale request (holding release request) for the designated card 210 is transmitted from the terminal device 3 to the game server 1. In response to the sale request, the sale processing unit 52a deletes the player ID of the designated card 210 from the information of the user's possessed card (or sets a deletion flag), and sets the strengthening points as consideration as the possession points of the user Add as That is, in the user information database illustrated in FIG. 14, the sale processing unit 52a updates the information on the possessed card and the information on the possessed points associated with the user ID to the information after the sale process.

  Next, the mixer processing unit 52b will be described. When the user presses the mixer execution button 217 on the screens of FIGS. 8 to 10, a mixer request (holding release request) for processing the designated first card 231 and second card 232 is processed from the terminal device 3 to the game server. 1 is transmitted. In response to this mixer request, the mixer processing unit 52b deletes the player IDs of the two specified cards 231 and 232 from the information of the user's possessed card, and other rareness with the same card 231 and 232. A card is randomly selected from all the cards to be a user-owned card. That is, in the user information database illustrated in FIG. 14, the sale processing unit 52a updates the information on the possessed card associated with the user ID to the information after the mixer process.

  Next, the coalescence processing unit 52c will be described. If the user presses the merge execution button 245 on the screen of FIG. 11 or FIG. 12, a merge request (holding release request) for processing the designated reinforcement target card 241 and reinforcement material card 242 is processed from the terminal device 3 to the game server. 1 is transmitted. In response to this coalescence request, the coalescence processing unit 52c deletes the player ID of the specified reinforcement material card 242 from the information of the user's possession card, and the ability of the reinforcement material card 242 according to the ability of the reinforcement material card 242 To improve. That is, the sale processing unit 52a updates the information on the possessed card associated with the user ID to the information after the coalescing process in the user information database illustrated in FIG.

  Next, the condition relating means 53 will be described. This condition associating means 53 notifies the information about the benefit to the companion of the object to be released to the holding release process such as the “sale process”, “mixer process”, “merge process”, etc. Has a function of relating information related to the notification conditions. The condition associating means 53 stores information relating the possession release process and the notification condition in a storage device (such as the database server 2).

  In the present embodiment, there are a plurality of possession release processes, and the condition associating means 53 associates information related to the notification condition for each possession release process. In this case, different notification conditions can be associated with each possession release process. FIG. 16 shows an example of information relating the possession release process and the notification condition. In FIG. 16, the notification conditions are changed in consideration of the nature and circumstances of each process of “sale process”, “mixer process”, and “combination process”, which will be described below.

  When the possession release process is the “merging process”, the user intends to strengthen a specific guard by synthesis (for that purpose, the reinforcement material card is released). For this reason, even if the reinforced material card is beneficial to a friend, giving a gift to the mate will also stop the reinforcement that the user himself wanted to perform. It is assumed that the user hesitates.

  In addition, when the possession release process is “mixer process”, it is executed with the expectation that a card that is desirable for the user may be obtained by exchange. It is assumed that you want to.

  On the other hand, when the possession release process is “sale process”, the card that the user originally determined to be unnecessary is converted into a strengthening point, and the strengthening point can be obtained by selling other cards. The psychological barrier to changing to a present is considered to be low.

  In consideration of the circumstances and the like for each holding release process as described above, notification conditions for “sale process”, “mixer process”, and “join process” are set in advance. In other words, for items that have a particularly high expectation for acquisition, for example, those that are registered as “desired” by the group, execute any of “sale processing”, “mixer processing”, or “joining processing”. The notification condition is related to each of these processes. The registration of “what you want” will be described later.

  In addition, what a friend wants, for example, a “team card of a friend” with a “rare degree of 4 or more”, is notified to the user before the “sale process” and “mixer process” are executed. The notification condition is related to each of these processes. Details of the “friend team card” and “rare degree” will be described later.

  In addition, what a friend may want, for example, a “team card of a friend” with a “rare degree of 3”, is to be notified to the user only before the “sale process” is executed. Is related to the notification condition.

  In this way, notification conditions can be set using registration information of “desirable”, team attributes (object attributes) set on the card, card rarity (rare value of the object), and the like. .

  Here, registration of “what you want” will be described. As shown in FIG. 17, the game management device preferably includes a desired registration means 56. This desired item registration means 56 has a function of registering what each user desires in response to a request from each user. Each user can register what he / she wants (what he / she wants with a card or item that the user can own) by operating his / her terminal device 3. When the user specifies what he wants and performs a registration operation, a registration request is transmitted from the user terminal device 3 to the game server 1. In response to this registration request, the desired item registration means 56 associates the player ID and item ID of the card requested to be registered as desired by the user with the database server 2 in association with the user ID, as shown in FIG. Stored in a predetermined storage area.

  What a user wants to register can be confirmed by another user by browsing a page displaying the user's information. That is, the user can know what he / she wants to register if he / she browses the page of the friend. However, in this embodiment, if the card specified for performing the “sale process” satisfies the condition that the friend wants to register, the game is executed before the “sale process” or the like is executed. The server 1 notifies the user accordingly. Therefore, even if the user does not remember what the friend wants, the user is aware that he is trying to let go of the friend's want before the “sale process” or the like.

  Next, a configuration in which notification conditions are set using information of attributes desired by the user (team attributes in the present embodiment) will be described.

  The game card of the present embodiment is a player character card that replicates a real player belonging to any of the 12 professional baseball teams in the real world. Therefore, any one of the plurality of team attributes is set for the cards that each user can own in the game.

  As shown in FIG. 17, the game management device preferably includes attribute registration means 57. The attribute registration unit 57 has a function of registering any one of a plurality of attributes and an attribute desired by each user in response to a request from each user. In this embodiment, each user can register any one desired team attribute among a plurality of team attributes (12 types of team attributes corresponding to 12 professional baseball teams). When the user designates a desired team and performs a registration operation at the start of the game, a registration request is transmitted from the user terminal device 3 to the game server 1. In response to this registration request, the attribute registration means 57 stores the team (team attribute) desired by the user in a predetermined storage area of the database server 2 in association with the user ID, as shown in FIG. .

  In the notification condition, the card for possession release processing designated by the user is a card of the same team as the team desired by the friend registered by the attribute registration means 57 (friend team). Can be included.

  A team registered by a certain user can be confirmed by other users by browsing a page displaying the user's information. That is, the user can know a team of friends by browsing a friend's page. However, in the present embodiment, when the card designated for performing the “sale process” or the like satisfies the condition that the card is a friend's team card, the game server 1 executes before the “sale process” or the like. Notify the user to that effect. Therefore, even if the user does not remember his / her team, he / she notices that he / she tries to give up his / her team card before “sale processing” or the like.

  In addition, although the notification condition of FIG. 16 shows an example in which the notification condition is set by combining the card of the fellow team and the rare degree, the notification condition may be only the card of the fellow team regardless of the rare degree. Good.

  Next, a description will be given of a configuration in which notification conditions are set using information on a card rare degree. For objects such as cards and items, a rarity (rare value) indicating a high rarity value is set. For example, the rare degree is expressed in five levels from 1 (lowest) to 5 (highest), and any rare degree is set for each card. A card with a higher degree of rarity even with the same player's card has a higher ability, and the probability that it can be acquired in the lottery mode is lower. As shown in FIG. 4, for example, a star is displayed on the card as rare degree information (the number of star marks represents the rare degree).

  In addition, you may attach | subject arbitrary names to each rare degree. For example, the rareness 1 to 5 can be referred to as normal, regular, great, star, and superstar.

  Even if it is a card of a fellow team, those with low rarity are often not pleased with the opponent, and may not be suitable as a gift target. Therefore, as illustrated in FIG. 16, the notification condition is set by combining the condition of the fellow team with the condition of the rare degree. For example, for the “sale process” and the “mixer process”, the notification condition that the card designated by the user is the “friend team card” and the “rare degree is 4 or more” is related. Further, the “sale process” is associated with a notification condition that the card designated by the user is the “friend team card” and the “rare degree is 3”. As a result, appropriate notification in consideration of the rare degree can be performed.

  In addition, although the structure which sets alerting | reporting conditions using the information of the team attribute which the user desired was demonstrated above, attributes other than a team attribute may be sufficient. 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 that are compatible with the A attribute but not compatible with the B attribute, and can be applied to a game in which any one of the three types of attributes is set for a character, an item, or the like. . That is, if the game allows the user to register any one of the desired attributes A, B, and C, the information about the attribute desired by the user is used in the same manner as the team attribute. Notification conditions can be set.

  In addition, as a notification condition related to each possession release process, a default notification condition that is preset in advance is basically used. However, the notification condition may be arbitrarily set / changed by each user operating the terminal device 3.

  Next, the determination unit 54 will be described. The determination unit 54 has a function of determining whether or not a notification condition related to the possession release process is satisfied based on the fellow game information when a card for the possession release process is designated by the user. Here, the friend game information includes various information stored in the user information database shown in FIG. In the determination of whether or not the notification condition illustrated in FIG. 16 is satisfied, the information on “what you want” and the information on the team of the friends registered in advance by the friends are referred to as the game information of the friends.

  When the user designates a card to be released by any one of the “sale process”, “mixer process”, and “merging process”, the determination means 54 is basically a game for all the friends of the user. The information is referred to, and it is determined whether or not there is a friend who satisfies the notification condition related to the process. However, as will be described later, the game information of friends whose intimacy is not more than a predetermined value may not be included in the determination target.

  Next, the notification means 55 will be described. The notification means 55 has a function of notifying the user of information related to the benefit of the designated card before executing the possession release process when the determination means 54 determines that the notification condition is satisfied. Here, the information about the usefulness of the specified card to the friend includes "the specified card is registered to what the friend wants", "the specified card is the card of the fellow team" Information. For example, when there is a friend who registers a card that the user wants to sell (when the notification condition related to the sale process is satisfied), the screen in FIG. 7 is used to notify the user to that effect. Is transmitted to the terminal device 3 of the user. This notification means 55 includes the functions of the screen generation means 63 and the transmission means 64 shown in FIG.

  In addition, when there are a plurality of friends who satisfy the notification condition, as illustrated in FIG. 18, the plurality of friends may be notified to the user as gift-targeted friends (candidates who give presents). FIG. 18 shows an example in which the card that the user is trying to sell is registered in what the friends B and C want. In this case, in the text display area 221 on the screen, for example, “The card that is going to be sold is a card that is registered for what the friends B and C want. "Why don't you give it to me?"

  In addition, a plurality of pieces of information 222 related to the present target friends (in this example, for two persons B and B) are displayed on the screen of FIG. Furthermore, two present buttons 223 corresponding to each of the companion B and the companion C to be presented are provided, and the card 210 that was about to be sold can be selectively presented to either the companion B or the companion C. ing. Here, an example in which there are two friends who satisfy the notification condition is shown, but the same applies to the case where there are three or more friends.

  Alternatively, when there are a plurality of friends who satisfy the notification condition, the game server 1 may select one of them, and notify only the selected friend as a candidate to give a present to the user. In this case, one friend may be selected at random, or the friend with the highest intimacy may be selected.

  Here, an operation example of the game server 1 when the user tries to perform the possession release process will be described below with reference to the flowchart of FIG.

  When a user's operation on the terminal device 3 designates a card (a card that the user is trying to release) as a target of “sale process”, “mixer process”, or “coalescence process” as the possession release process (S1) YES), the game server 1 acquires the notification condition related to the possession release process (S2).

  For example, if a specific card is specified from among the player cards held by the user, the screen illustrated in FIG. 5 is displayed. The screen shown in FIG. 5 is also displayed immediately after the user obtains a card in the scout mode or the lottery mode. When the user presses the sale button 212 on the screen of FIG. 5, the user designates the card 210 that is the target of “sale processing”. When this operation is performed, information on the operation relating to the card designation for the “sale process” is transmitted from the terminal device 3 of the user. In response to this operation information (YES in S1), the game server 1 changes the notification condition related to the “sale process” from the storage device (database server 2 or the like) storing the association information of FIG. get.

  Similarly, in the user's terminal device 3, two cards (the first card 231 and the second card on the screen of FIG. 8 or FIG. 9) that are the targets of “mixer processing” among the cards of the players held by the user. When an operation for selecting the card 232) is performed, according to the information of this operation (YES in S1), the game server 1 sets the notification condition related to the “mixer process” to the correlation information shown in FIG. Is obtained from the storage device in which is stored.

  Further, the user terminal device 3 performs an operation of selecting a card (reinforcement material card 242 on the screen of FIG. 11 or FIG. 12) to be subjected to the “merging process” from the player's cards held by the user. If it is determined that the game server 1 is informed (YES in S1), the game server 1 acquires the notification condition associated with the “merging process” from the storage device storing the association information in FIG. .

  In the present embodiment, as shown in the association information in FIG. 16, different notification conditions are set for “sale processing”, “mixer processing”, and “merging processing”, and appropriate conditions according to the processing are set. Applies.

  Moreover, in step S3, the game server 1 acquires the game information of the friend of the user who is going to perform the possession release process. This process acquires a user's fellow information (a fellow user ID) from the user information database illustrated in FIG. 14, and obtains the fellow's game information from the user information database based on the obtained fellow user ID. Can be realized.

  Thereafter, the game server 1 determines whether or not the notification condition acquired in step S2 is satisfied based on the friend game information acquired in step S3 (S4). For example, when the card specified for the sale process by the user is a card registered for what a fellow member wants, the notification condition is satisfied.

  Here, when it is determined that the notification condition is satisfied (YES in S4), the game server 1 notifies the user of information regarding the benefit to the friend of the designated card (S5) before executing the possession release process. ). For example, the screens of FIGS. 7, 9, 10, and 12 are generated and transmitted to the user terminal device 3. In the screen example of FIG. 7, the designated card is a card registered in what the friend wants, and notification information that recommends the present to the friend of the card is included in the screen.

  This makes it possible for the user to realize that the card that the user is trying to cancel possession is beneficial to his / her friends before executing the possession cancellation process. In this case, the user can select a possession release process such as “sale process”, or can stop the possession release process and select to give the target card to a friend.

  Here, when the user performs an operation of holding release processing (YES in S6), for example, when the sale execution button 216 is pressed on the screen of FIG. 7, the game server 1 performs the holding release processing according to the operation. Execute (S9).

  On the other hand, when the user stops the possession release process and performs a present operation (YES in S7), for example, when the present button 223 is pressed on the screen of FIG. 7, the game server 1 presents according to the operation. The process is executed (S9). That is, the game server 1 performs a process of presenting a card specified as a target of the possession release process to a friend extracted as satisfying the notification condition. In this case, the game server 1 notifies a friend that a present has arrived from the user.

  If it is determined in step S4 that the notification condition is not satisfied (NO in S4), the game server 1 does not notify the user of information regarding the benefit to the friend of the designated card, and releases the possession process. Display a screen that allows. Thereby, for example, the screen of FIG. 6 is displayed in the case of “sale processing”, the screen of FIG. 8 is displayed in the case of “mixer processing”, and the screen of FIG. Here, when the user performs an operation of holding release processing (YES in S10), for example, when the sale execution button 216 is pressed on the screen of FIG. 6, the game server 1 performs the holding release processing according to the operation. Execute (S9).

  As described above, as shown in FIG. 15, the game management apparatus of the present embodiment mainly includes the fellow management means 51, the release means 52, the condition association means 53, the determination means 54, and the notification means 55. In addition, when the notification condition is related to the possession release process and a card (object) for the possession release process is designated by the user, it is determined whether or not the notification condition is satisfied based on the game information of the friend. . And when notification conditions are satisfy | filled, it is the structure which alert | reports the information regarding the benefit to the friend of the designated card | curd to a user with sufficient timing before execution of a holding release process. As a result, the user is aware that the card that the user is willing to release is beneficial to his / her friends before the holding release process is executed. Therefore, it is possible to arouse the interest of the friend to the user, and to change the sale of the card or the like into a present for the friend. In other words, the user can get the opportunity to give the card he / she wanted to give away to the friend without having to do the troublesome work of searching for the card to give to the friend. Can do. By this structure, the environment which is easy to give a present to a friend can be provided to a user, a present can be promoted, and the communication of a friend can be activated.

  Further, in the present embodiment, there are a plurality of possession release processes such as “sale process”, “mixer process”, and “merging process”, and different notification conditions can be associated with each possession release process. Thereby, appropriate notification according to the nature and circumstances of each possession release process is performed, and it is possible to provide the user with an environment in which gifts can be easily given to friends.

  Next, a description will be given of a configuration in which, even in the same possession release process (for example, sale process), a range of friends can be determined based on game information about friends, and information regarding different notification conditions can be related to each range.

  The “friend range” can be determined based on “game information related to friends” such as “intimacy with users”, “game level of friends”, and “frequency of access to games of friends”. Alternatively, the “companion range” can also be determined based on a fellow user ID, a user name, or the like.

  First, an example in which the “companion range” is determined based on the “intimacy with the user” will be described. As shown in FIG. 20, the game management device includes intimacy providing means 58. This intimacy giving means 58 has a function of giving intimacy to two users who are in a fellow relationship. Here, intimacy refers to the intimacy of two users who have established a friendship relationship, and can also be expressed as the degree of friendship between two people, the depth of friendship, the depth of bonds, etc. .

  For example, the closeness of two people can be set based on the number and frequency of exchanges in the game, and the closer the user interacts with a friend, the higher the closeness with the friend. Examples of in-game exchanges include greetings, presents, battle cooperation, and chat, but are not limited to this, and various exchanges can be applied depending on the type and content of the game. Here, “greeting” is a general term for simple exchanges that can be performed virtually in the game with a simple operation such as pressing a button, sending an ale (support), sending a gut (motivation), Simple exchanges using other expressions such as winking, smiling, waving hands, etc. are also included. The game server 1 stores and manages the closeness of two people in a friendship relationship in the database server 2.

  For example, the intimacy giving means 58 gives an intimate point of a predetermined value (for example, 1 point) each time an alternating process is executed between two users of friends. The intimacy points to be given may be changed depending on the content of the exchange. For example, the greeting may be 1 point, the message transmission may be 2 points, the present and battle cooperation may be 3 points, the chat may be 4 points, and the like. In the present embodiment, for example, five levels of intimacy are provided according to the intimacy points of the two persons. For example, intimacy points are 0-24 points, familiarity = 1 (acquaintance), 25-49 points, familiarity = 2 (friends), 50-74 points, familiarity = 3 (best friends), 75-99 points Density = 4 (friend), 100 or more points, familiarity = 5 (allies).

  For the user, it is desirable to increase the opportunities for giving presents to friends with higher intimacy. Therefore, in this Embodiment, even if it is the same possession cancellation | release process, a different appropriate alerting | reporting condition is set with a friend whose intimacy is more than predetermined and a friend lower than that, for example. FIG. 21 shows an example of information in which the range of friends is determined based on the intimacy and the possession release process and the notification condition are related to each other.

  In the example of FIG. 21, the notification conditions related to “sale process”, “mixer process”, and “merging process” are as follows: a friend range with a closeness of 3 or more and a friend range with a closeness of 2 or less. It is different. That is, regarding “sale processing”, in the range of friends whose intimacy is 3 or more, those whose friends are registered as “desired” and “player cards of fellow teams” and whose “rare degree is 3 or more” In any case, the notification condition is set so that the user is notified before the sale process is executed. On the other hand, in the range of friends whose intimacy is 2 or less, the notification condition is set so that only the information registered by the friend as “desirable” is notified to the user before the sale process is executed.

  In addition, regarding “mixer processing”, in the range of friends whose intimacy is 3 or more, those who are registered as “what they want” and “player cards of fellow teams” and “rare degree is 4 or more” In any case, the notification condition is set so as to notify the user before the execution of the mixer. On the other hand, in the range of friends whose intimacy is 2 or less, the notification condition is set so that only what the friend has registered as “desired” is notified to the user before execution of the mixer process.

  In addition, regarding the “merging process”, in the range of a friend whose degree of intimacy is 3 or more, a notification condition is set so that only a member registered as “desirable” is notified to the user before the coalescing process is executed. doing. On the other hand, in the range of friends whose intimacy is 2 or less, the notification condition for the coalescence process is not set (that is, the notification is not performed).

  In addition, although the example of FIG. 21 showed the example which divided the range of the friend into two steps with familiarity of 3 or more and 2 or less, it is not limited to this. For example, the range of friends may be divided into three levels of familiarity 1, 2 to 4, 5 or may be divided into five levels of familiarity 1, 2, 3, 4, and 5.

  In addition, for “sale processing”, the companion range is divided into five stages, for “mixer processing”, the companion range is divided into three stages, and for “combination processing”, the companion range is divided into two stages. The method of dividing the range of friends may be varied depending on the type of possession release processing.

  As in the present embodiment, when a range of friends is defined based on game information about friends and different notification conditions are associated with each range, the determination unit 54 determines whether the notification conditions are satisfied for each range of friends. Determine whether. Here, when the notification condition of FIG. 21 is set, the case where the card for sale processing is designated by the user is mentioned as an example. In this case, whether or not the determination means 54 satisfies the notification condition of “what a friend wants” or “a friend's team card and a rarity of 3 or more” based on game information of a friend range of 3 or more. Determine. Furthermore, the determination means 54 determines whether or not the notification condition “what a friend wants” is satisfied based on the game information in the range of a friend whose intimacy is 2 or less. In this case, since the notification condition set in the range of the friend whose intimacy is 3 or higher is wider than the notification condition set in the range of the friend whose familiarity is 2 or less, the former is more likely to satisfy the notification condition. When it is determined that the notification condition is satisfied, the notification unit 55 notifies the user of information regarding the benefit to the friend of the designated card (see FIG. 7 and the like). Therefore, in the notification screen of FIG. 7 and the like, it becomes easier for the user to be notified of information related to the benefit to the friend whose intimacy is 3 or more. It is possible to increase the chances of giving presents.

  With this configuration, appropriate notification according to the intimacy between the user and the friend is possible.

  Next, an example in which the “companion range” is determined based on the “companion game level” will be described. The game level is an index indicating the progress of the game and the proficiency level of the game, and is improved by progressing the game or improved by satisfying a predetermined victory condition in the battle game.

  For example, a friend who has a low game level (such as a friend who has just started the game) can be happy to present a card that is not too rare. There is a high possibility that you will not be very pleased if you present a card that is not expensive. Therefore, the range of the friends is determined based on the game level of the friends, and an appropriate notification condition is related to each range of the friends.

  In the example of FIG. 22, the notification condition is not changed for the “merging process” based on the game level of the friend. In other words, the notification condition is set so as to notify the user of only what the friend has registered as “desired” regardless of the game level of the friend before executing the coalescing process. Thus, about a part of possession cancellation | release process, you may set a common alerting | reporting condition regardless of the range of a friend.

  In the example of FIG. 22, an example in which the range of the friends is divided into two stages of level 30 or higher and level 29 or lower is shown, but the present invention is not limited to this. For example, the range of friends can be arbitrarily set, for example, the range of friends is divided into four levels of level 9 or less, 10 to 29, 30 to 49, 50 or more.

  With this configuration, appropriate notification according to the game level of the friend can be performed.

  Further, as shown in FIG. 23, the range of friends may be determined by a combination of “intimacy with the user” and “game level of friends”. In the example of FIG. 23, regarding “sale process” and “mixer process”, the range of friends with “intimacy 3 or higher and level 30 or higher” and friends with “intimacy 2 or lower or level 29 or lower” In this example, the notification conditions suitable for each range are set independently.

  Next, an example in which the “companion range” is determined based on “the access frequency of the companion game” will be described. For friends who frequently access the game, communication can be activated by giving gifts to each other. On the other hand, it can be said that a friend who has a low access frequency to the game is less likely to give a present in the first place because the game is not often played. Then, the range of a friend is defined based on the access frequency to a friend's game, and appropriate alerting | reporting conditions are related for every range of a friend.

  The access frequency to the game can be represented by the number of access days or the number of accesses to the game during a predetermined period (for example, one week) that goes back from the present. Alternatively, the access frequency may be the number of access days or the number of accesses last week (last month). Some users have played games frequently before, but recently they have rarely played games. Therefore, the access frequency to the game is preferably set to, for example, the number of access days in one week or one week last week from the present so that the recent access frequency to the game is reflected.

  The number of access days is counted as the day when the game is accessed when the game server 1 is accessed (logged in) at least once a day. The user's access to the game is recorded as an access log as shown in FIG. Therefore, the game server 1 can acquire the access frequency based on the access log of each user.

  FIG. 24 shows an example of information in which the range of friends is determined based on the frequency of access to the games of the friends, and the possession release process is associated with the notification condition.

  In the example of FIG. 24, the notification conditions related to “sale process”, “mixer process”, and “combination process” are set for the range of friends whose access frequency is 4 days / week or more and the condition of friends who are 3 days / week or less. Different from the range. In other words, regarding “sale processing”, in the range of friends whose access frequency is 4 days / week or more, those that are registered in “what they want” and “player cards of fellow teams” and “rare degree” The notification condition is set so as to notify the user before the sale process is executed for any of “3 or more”. On the other hand, in the range of friends whose access frequency is 3 days / week or less, the notification condition is set so that only what the friend has registered in “Wanted” is notified to the user before the sale process is executed. Yes.

  In addition, regarding “mixer processing”, within the range of friends whose access frequency is 4 days / week or more, those that are registered as “desired things” by the friends and “player cards of fellow teams” In any case of “4 or more”, the notification condition is set to notify the user before the execution of the mixer. On the other hand, in the range of friends whose access frequency is 3 days / week or less, the notification condition is set so that only those registered by the friend as “desired” are notified to the user before the mixer process is executed. Yes.

  In addition, regarding “combination processing”, in the range of friends whose access frequency is 4 days / week or more, notification is made so that only those registered in “what you want” are reported to the user before the execution of the coalescence process. Conditions are set. On the other hand, in the range of friends whose access frequency is 3 days / week or less, the notification condition for the coalescence process is not set (not notified).

  It should be noted that in the range of peers with a predetermined access frequency or less (for example, 1 day / week or less), no notification condition is set (not notified) in any of the cases of “sale processing”, “mixer processing”, and “joining processing”. ) Good.

  In addition, in the example of FIG. 24, an example in which the range of friends is divided into two stages of access frequency of 4 days / week or more and 3 days / week or less is shown, but the present invention is not limited to this. For example, the range of friends can be arbitrarily set such as dividing the range of friends into three stages of 5 days / week or more, 4 days to 2 days / week, and 1 day / week or less. Further, the “friend range” may be set by combining “the access frequency to the game of the friend” with the above-mentioned “intimacy” and “game level”.

  With this configuration, appropriate notification according to the access frequency of a friend's game can be performed.

  Moreover, the range of a mate can be set based on the information (an associate's user ID, a user name, etc.) which specifies an individual. In this case, the game server 1 sets the range of the mate based on the user ID (user identification information) of the mate in response to a request from the user who specified the specific mate. Furthermore, you may enable it for a user to set arbitrarily the alerting | reporting conditions about the friend.

  FIG. 26 and FIG. 27 show an example of a notification condition setting screen for the user to arbitrarily set the notification condition. FIG. 26 shows a screen example in the initial state when the notification condition setting screen is opened, and FIG. 27 shows a screen example in which input is performed by the user.

  The notification condition setting screen includes a process selection area 251, a friend designation area 252, and a condition setting area 253. In the process selection area 251, one of the possession release processes ("sale process", "mixer process", "merging process") associated with the notification condition can be selected by a radio button (or a pull-down menu or the like). FIG. 27 shows an example in which the user selects “joining process”.

  In the friend designation area 252, one or more arbitrary friends can be selected from all the friends of the user. A friend list button 254 is provided in the friend specification area 252. When the button 254 is pressed, a friend list screen (not shown) is displayed, and an arbitrary friend can be selected. On the buddy list screen, a buddy list including information such as the user's buddy avatar, name, and level is displayed. If a friend is selected on this friend list screen, the screen returns to the notification condition setting screen as shown in FIG. 27, and information 256 of the selected friend (such as a friend's avatar, name, level, team, etc.) is displayed on the screen. In the example of FIG. 27, an example is shown in which the user has selected a friend B and a friend C.

  In addition, the area | region which inputs user ID in the associate designation | designated area | region 252 may be provided, and a user may designate a specific associate by directly inputting the associate's user ID. However, since the user generally does not remember the user ID of his / her friend, it is desirable that a specific friend can be selected from the friend list screen as described above. Even when the user selects a specific friend from the friend list screen, the game server 1 manages the game information based on the user ID of the friend, which is substantially equivalent to the user specifying the user ID of the friend. Is the same.

  Further, in the condition setting area 253, a card condition that the friend specified in the friend specifying area 252 is likely to want can be set as the “notification condition”. For example, in the condition setting area 253, condition items such as “what a friend wants”, “a friend team card”, and “rare degree” are displayed in advance, and the user selects the condition item using a check box or the like. The notification conditions can be set simply by simply. In the example of FIG. 27, an example is shown in which the user sets notification conditions of “what a fellow wants” and “a fellow team card and a rarity of 3 or more”. Also, a setting button 255 is provided on the screen, and setting information is transmitted from the user terminal device 3 to the game server 1 by pressing this button. The game server 1 receives the setting information and stores the notification condition in the database server 2 in association with the user ID.

  When the user sets a condition on the notification condition setting screen as described above, and the user tries to release a card that satisfies the notification condition set in the condition setting area 253 by the possession release process selected in the process selection area 251 Before the process is executed, the user is notified of information related to the benefit to the friend specified in the friend specifying area 252. That is, when the card for possession release processing selected in the process selection area 251 is designated by the user, the determination means 54 is a game in the range of friends designated in the friend designation area 252 (for example, friends B and C). Based on the information, it is determined whether or not the notification condition set in the condition setting area 253 is satisfied. As a result, when it is determined that the notification condition is satisfied, the notification unit 55 provides information about the benefit to the friend specified in the friend specification area 252 of the specified card before the execution of the holding release process. The user is notified (see the screen of FIG. 12).

  FIG. 25 shows an example of information in which the range of friends is determined based on information specifying an individual and the possession release process is associated with the notification condition. The association information in FIG. 25 includes a notification condition for “joining process” set by the user A with user ID = 000001 on the notification condition setting screen in FIG. That is, regarding the “combining process”, the range of the friends is determined by the user ID of the friend B = 000002 and the user ID of the friend C = 000005, and “what the fellow wants” and “the friend's team card and The condition “rare degree 3 or higher” is related.

  In the screen of FIG. 27, an example in which “merging” is selected in the process selection area 251 and a notification condition related to “merging process” is set is shown, but “sale” is selected in the process selection area 251. Then, the notification condition related to the “sale process” can be set, and if “mixer” is selected, the notification condition related to the “mixer process” can be set. For example, after setting the notification condition for the “merging process”, the notification condition setting screen of FIG. 26 is newly displayed, and this time by selecting “sale process”, the “sale process” It is possible to set conditions different from the “combination process”. That is, for each of “sale processing”, “mixer processing”, and “joining processing”, the user can individually select a friend (setting a friend's range) and setting notification conditions.

  In FIG. 25, the default notification conditions are preset in advance except for the notification conditions of the part where the range of the fellow is determined by the user ID = 000002 and 000005. The default notification condition can also be changed to an arbitrary condition by the user's operation on the terminal device 3. When the user himself / herself can set the notification condition, the notification condition is different for each user, so information related to the notification condition is stored in the database server 2 in association with the user ID.

  Also, the notification conditions exemplified in FIGS. 21 to 24 may be default notification conditions set in advance, and the user may be able to set arbitrary conditions when the user wants to change them.

  FIG. 28 shows an example of a notification condition setting screen for arbitrarily setting a notification condition after the user specifies a range of friends by familiarity. The difference between the screen of FIG. 28 and the screen of FIG. 27 is as follows. That is, in the screen of FIG. 27, a specific friend is selected in the friend specifying area 252, but in FIG. 28, the friend range can be specified in the friend specifying area 252 and the range of the friend can be specified. Yes. FIG. 28 shows an example in which pull-down menu sections 257 and 258 for designating the familiarity range are displayed, and the range can be designated by selecting the familiarity value from the pull-down menu. Note that the range designation input method is not limited to this. For example, the closeness value may be directly input by key input, voice input (input by voice recognition) or the like in the terminal device 3.

  Other screen configurations (processing selection area 251 and condition setting area 253) in FIG. 28 can be the same as those in the screen in FIG. Therefore, also on the screen of FIG. 28, it is possible to individually set the range of friends and the notification condition for each of “sale processing”, “mixer processing”, and “joining processing”.

  In addition, although the example which can designate the range of a friend by closeness was shown in FIG. 28, you may enable it to designate the range of a friend by the game level of a friend, the access frequency to a friend's game, etc. Or you may enable it to specify the range of a friend combining intimacy, a game level, the access frequency to a game, etc. For example, as shown in FIG. 29, not only pull-down menu parts 257 and 258 for specifying a familiarity range but also pull-down menu parts 261 and 262 for specifying a game level range in the friend specification area 252. In addition, pull-down menu units 263 and 264 for designating a range of access frequency to the game are also provided. In this case, for example, if the user specifies only the familiarity range in the pull-down menu sections 257 and 258 and leaves the other portions blank, the friend's range can be specified based on the familiarity alone. For example, if the user specifies the familiarity range in the pull-down menu part 257/258 and the game level range in the pull-down menu part 261/262, the friendship range is specified by combining the familiarity and the game level. it can. The same is true for specifying the range of friends based on the access frequency to the game.

  By the way, when a specific friend is set as a friend range based on information specifying an individual specified by the user, the game server 1 automatically sets an appropriate notification condition based on the game information of the specific friend. The automatic setting means 59 (FIG. 30) for setting to the above can be provided.

  Here, an example will be described in which the automatic setting unit 59 automatically sets the notification condition only by the user selecting the possession release process and the specific friend on the notification condition automatic setting screen shown in FIG. In the screen of FIG. 31, a process selection area 251 and a friend designation area 252 are provided. When any one of “sale processing”, “mixer processing”, and “merging process” is selected in the process selection area 251 and a specific friend is selected by pressing the friend list button 254 in the friend specifying area 252, the user terminal device 3, the operation information (including information on the selected process and the user ID of the designated friend) is transmitted to the game server 1. In response to this operation information, the automatic setting means 59 acquires the game information of the designated friend from the database server 2, and automatically sets the notification condition based on the game information of the friend.

  For example, the automatic setting means 59 automatically sets a notification condition of a predetermined rare degree (rare degree 3, rare degree 4, etc.) for the players of the designated fellow team. In this case, the automatic setting means 59 performs an appropriate notification based on the game information of the friend such as the game level of the friend, the friendship degree of the friend, the access frequency to the friend's game, etc., and by the selected possession release process. Conditions can be set. For example, the higher the game level, the higher the condition of the rare degree, so that it is not notified when trying to let go of a card with a low rare degree (for example, the notification condition shown in FIG. 22 is applied). This is because friends with a high game level often have multiple cards with a high degree of rarity. This is because it is thought that there is not. Further, for example, the notification condition shown in FIG. 21 or FIG. 24 is applied so that a friend with a higher degree of closeness or a friend with a higher access frequency to the game has more opportunities to give presents (that is, a notification opportunity). To do.

  Alternatively, if there is a weak position in the team order (card deck) set by the designated friend (there is no position that has a player with a certain degree of rarity or a certain ability value), the player in that position A notification condition of a predetermined rare degree (for example, a rare degree of 4 or more) is automatically set on the card. As an example, if there is no pitcher character of 4 or higher in the team pitch of the fellow team order, the notification condition of the rarity level 4 or higher is automatically set with the pitcher card of the fellow team.

  Information regarding the notification condition automatically set by the automatic setting means 59 is stored in the database server 2 in association with the user ID.

  When the notification condition is automatically set, the game server 1 preferably transmits, for example, the screen illustrated in FIG. 32 to the terminal device 3 and notifies the user of the automatically set condition. 32 displays information 271 (avatar, name, level, team, etc.) of the fellow designated by the user in the fellow designation area 252 of the screen of FIG. It should be noted that a friend change button (not shown) may be provided so that the specified friend can be changed. In addition, a display area 273 for information related to the automatically set notification condition is provided on the screen. In this display area 273, automatically set notification conditions 274, an OK button 275, a condition change button 276, and the like are displayed. FIG. 32 shows an example in which notification conditions 274 of “what a fellow wants” and “a pitcher card of a fellow team (rare degree 4 or more)” are automatically set. If the OK button 275 is pressed here, the screen shown in FIG. 32 is closed and the screen transitions to the main screen shown in FIG. 4, or the screen returns to the screen shown in FIG. On the other hand, when the user wants to change the automatically set condition, the user can set an arbitrary condition by pressing the condition change button 276.

  Note that, in the above, in the notification condition automatic setting screen shown in FIG. 31 and FIG. 32, an example in which any one process of “sale”, “mixer”, and “merging” is alternatively selected in the process selection area 251. Although shown, the user may be able to select a plurality of these possession release processes at a time. Even when a plurality of possession release processes are selected by the user (for example, when “sale”, “mixer”, and “union” are all selected), the automatic setting unit 59 cancels each possession release described above. In consideration of the nature and circumstances of the process, notification conditions can be individually set for each possession release process.

  With the configuration provided with the automatic setting means 59, the user only specifies a specific friend, and the automatic setting means 59 analyzes the game information of the friend and automatically sets an appropriate notification condition. The burden can be reduced.

  Next, the structure which limits the report | combination object friend based on closeness is demonstrated. In the case of a user with many friends, notification is frequently made when trying to let go of the card, which may be bothersome. Therefore, it is desirable to limit the friends to be notified to friends having a predetermined familiarity or higher.

  The determination means 54 of the game server 1 that realizes this is limited to the game information of a friend that is higher than a predetermined familiarity (for example, 2 in 5 stages) when a card for possession release processing is designated by the user. Then, it is determined whether or not the notification condition is satisfied.

  Thereby, the processing load in the determination process can be reduced. Furthermore, it is possible to limit the notification target friends to a friend having a predetermined familiarity or more, to optimize the frequency of notification, and to avoid the troublesomeness caused by the notification.

[Other configuration examples of the game system]
In each of the above-described embodiments, a game execution program is installed on the game server 1 side, and the game server 1 performs arithmetic processing and data processing for game progress in response to an input operation on the terminal device 3 of each user. 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, and is an example in which a game management device is configured by servers (game server 1 and database server 2). As described above, this configuration is suitable for providing users with services such as browser games, social games, and cloud gaming, but the configuration of the game management device is not limited to this.

  For example, the game server 1 manages game information of each user and provides game services such as exchange between users in the game to the user. The present invention can also be applied to a game system performed on the terminal device side.

  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 user terminal device side and the game execution process is also performed on the terminal device. For example, a user terminal device peers with another user terminal device 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.

  The server and the terminal device can communicate with each other to send and receive various data, and are information processing devices (computers) each including a CPU, ROM, RAM, auxiliary storage device, communication control unit, and the like. The hardware configuration is as follows. Therefore, in a game system including a server and a terminal device, each means included in the game management device described in each of the above embodiments may be provided in either the server or the terminal device. In other words, the game management device can be configured to be provided in a server and a terminal device that communicate with each other to send and receive various data, and achieve the same effects as the above-described embodiment.

  For example, in FIG. 15, the game server 1 includes the friend management unit 51, the release unit 52, the condition association unit 53, the determination unit 54, and the notification unit 55, but as illustrated in FIG. 33, the function of each unit Can be held in either the server or the terminal device. Here, the hardware configuration of the server shown in FIG. 33 is the same as that of the game server 1 shown in FIG. 2, and the hardware configuration of the terminal device is the same as that of the terminal device 3 shown in FIG. FIG. 33 shows a configuration example in which the server 101 is provided with the fellow management means 51 and the condition relation means 53, and the terminal device 301 is provided with the release means 52, the determination means 54, and the notification means 55. FIG. 33 shows an example of the configuration of the game system, and other configurations are possible.

  Also, as shown in FIG. 34, the terminal device 302 may include a friend management unit 51, a release unit 52, a condition relation unit 53, a determination unit 54, and a notification unit 55. That is, the game management device can be mounted on the terminal device 302 itself, which is a game terminal. In this case, the same effects as those of the above-described embodiment can be obtained. In this case, the server 102 manages the game information of each user and provides the user with services such as greetings and messages sent and received between the terminal devices 302, but all other processing is performed on the terminal device 302 side. Can be executed in Alternatively, management of game information of each user can also be performed on the terminal device 302 side of each user.

  Further, the desired registration unit 56, the attribute registration unit 57, and the intimacy providing unit 58 described above can be provided not only on the server side but also on the terminal device (game terminal) side.

[Other Embodiments]
In the above-described embodiment, an example has been shown in which another user associated with the user is a friend. However, the present invention is not limited to a friend if the user is associated with the user. Can be applied.

  In the embodiment described above, “sales process”, “mixer process”, and “merging process” have been described as examples of the holding release process. However, the holding release process is not limited to these. For example, “deletion processing” in which an unnecessary object is designated from objects (cards, items, etc.) held by the user and simply deleted is also included in the possession release processing. The possession release process includes various processes involving the release of the possession of the object possessed by the user.

  Further, regarding a configuration having a storage control function for storing various types of information in the storage device (such as the user information storage control means 60), the storage device itself is not included in the configuration, so that the inside and outside of the game management device (or game system) It may be installed anywhere. For example, the storage device is a RAM 13 or auxiliary storage device 14 that the game server 1 has, a database server 2, a RAM 33 or auxiliary storage device 39 that the terminal device 3 has, or a file server (online that is different from the game management device or terminal device). Storage) or the like.

  The configurations described in the above embodiments can be applied in appropriate combination.

  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. Are executed by the CPU of the server and terminal device (game terminal). The means for providing the program to the server or the like 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 Associate management means (management means)
52 Release means 53 Condition association means 54 Determination means 55 Notification means 56 Desired registration means 57 Attribute registration means 58 Intimacy provision means 59 Automatic setting means 101, 102 Server (game management device, game system)
301, 302 Terminal device (game management device, game system)

Claims (14)

It means for associating the information identifying the information with other users to identify the user,
Depending on holdings release request from the user, for the object to which the by information electronic object is associated with information for identifying the user the user is virtually held in an electronic game, wherein A release means for executing a holding release process for releasing the association ;
Condition relating means for relating in advance information including a notification condition for notifying information on the benefit to the other user of the object to be held and released with respect to the information indicating the holding release process;
A determination unit that determines whether or not the notification condition is satisfied based on the game information of the other user and information indicating the holding release process when an object for the holding release process is designated by a user;
Informing means for informing the user of information related to the benefit to the other user of the specified object before execution of the possession release process when the judging means determines that the notice condition is satisfied; A game management device comprising: The game management apparatus according to claim 1, wherein there are a plurality of possession release processes, and the condition association unit associates information including the notification condition for each piece of information indicating the possession release process. The game management device according to claim 1, wherein information including the notification condition is associated with each other user range determined based on the game information related to the other user. A degree of intimacy giving means for giving intimacy to the two related users;
The game management device according to claim 3, wherein the range of the other user is determined based on closeness with the user.   The game management device according to claim 3 or 4, wherein the range of the other user is determined based on an in-game level of the other user.   The game management device according to claim 3, wherein the range of the other user is determined based on an access frequency of the other user to the game. A degree of intimacy giving means for giving intimacy to the two related users;
The determination unit, when the object for the holdings release processing is specified by the user, limited to highly other users game information than a predetermined closeness to determine whether the notification condition is satisfied The game management device according to any one of claims 1 to 6. In response to a request from each user, it further comprises a desired item registration means for registering what each user wants,
8. The notification condition according to any one of claims 1 to 7, wherein the notification condition includes a condition that an object for the possession release process designated by a user is what the other user wants to register. The game management device described. Any one of a plurality of attributes is set for the object,
In response to a request from each user, it further includes attribute registration means for registering any one of the plurality of attributes and the attribute desired by each user,
The notification condition includes a condition that the object for the possession release process designated by the user has the same attribute as the attribute desired by the other user registered by the attribute registration unit. The game management device according to any one of claims 1 to 8. The object is set with a rarity value indicating the rarity value,
The game management device according to claim 9, wherein the notification condition includes a condition that a rare value degree of the object for the possession release process designated by the user is a predetermined rare value degree. The game management device according to claim 1, wherein the possession release process includes a sale process in which an object virtually owned by a user in a game is converted into points. The game management device according to claim 1, configured as a server capable of communicating with a game terminal device operated by a user. The game management device according to any one of claims 1 to 11, wherein the game management device is configured as a game system including a server and a terminal device that communicate with each other, and each of the means is provided in either the server or the terminal device. . 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