JP5918703B2 - 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 can become friends with other users who use the game service, and the users can interact with each other, such as exchanging gifts with each other. .

  Also, there are usually various game modes in the game, and the user sells items obtained in the game to earn points, or uses the points to strengthen items (for example, uniting items together) ).

JP 2001-129240 A JP 2011-110139 A

  As described above, it is possible to execute a plurality of processes such as gifts, sales, reinforcements, etc. on items acquired in the game, but the user selects a process to be executed and performs an operation according to the process. It takes time and effort.

  The present invention has been made in view of the above, and an object thereof is to reduce a user's operation burden on a plurality of processes in a game.

  1) A game management device (1, 2, 102, 302) according to one aspect of the present invention includes an automatic processing means (71) for executing predetermined automatic processing on an object obtained by a user, and a plurality of the automatic processing. For each process, the condition correlation means (72) for relating information related to the execution condition, and when the user obtains the object, the automatic process satisfying the execution condition is determined and determined from among the plurality of automatic processes. Control means (73) for executing automatic processing.

  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.

  The game management device includes automatic processing means for executing predetermined automatic processing on an object obtained by a user. Here, examples of the automatic process include an automatic sale process, an automatic merge process, an automatic present process, and the like described below. As described above, there are a plurality of automatic processes, and information regarding execution conditions is associated with each automatic process. That is, the condition relating means associates the automatic processing with the execution condition, and if the object obtained by the user is under what condition, the association information about which automatic processing is executed is stored. Stored in the device. And when a user acquires an object, a control means determines the automatic process which satisfy | fills execution conditions among several automatic processes, and performs the determined automatic process.

  Below, the automatic process about the baseball digital card game using a player card is illustrated. Each player card is assumed to have one of five levels of rarity (minimum 1 to maximum 5). In addition, it is assumed that each player card has an assigned team (for example, any one of 12 professional baseball teams in Japan). Each user also has his own team (any one of the 12 teams).

  (A) Automatic sale process: The sale process is a process in which an object owned by a user is virtually sold in a game and converted into in-game points, in-game currency, and the like. As an example of the automatic sale process, if the player card obtained by the user is “rare degree 1”, “regardless of the team (all team targets)” is sold and converted into in-game points.

  (B) Automatic merging process: The merging process is to change a parameter of another object by combining a specific object held by the user with the other object (enhancing the ability or the like). It is processing. Execution of the merge process may require in-game points obtained by the sale process. As an example of the automatic coalescence process, the user sets a player card to be strengthened in advance. If the player card obtained by the user is “same team” as the player card to be strengthened and “rare degree is 2 or less”, the uniting process between the player card to be strengthened and the obtained player card is automatically performed. Run.

  (C) Automatic present process: The present process is a process of changing the owner of an object when the user presents a specific object held by the user to another user. As an example of the automatic present process, another user (for example, a friend B) that the user wants to present is set. And if the player card which the user acquired is "same team" with the friend B and "rare degree 3", the player card will be automatically presented to the friend B.

  As described above, information related to execution conditions corresponding to each process is associated with each automatic process. The execution condition related to each automatic process can be arbitrarily set by the user, or an initial setting (default) condition can be used. For example, the conditions in parentheses “...” In the descriptions of the processes (A) to (C) can be initial setting (default) conditions. Further, the user may arbitrarily set and change the conditions as needed. In the above, three automatic processes are exemplified, but there may be two or four or more automatic processes.

  An object obtained by the user may satisfy a plurality of automatic processing conditions. In this case, the control means may determine an automatic process to be executed at random, or may determine an automatic process to be executed based on a preset priority as will be described later.

  If the object obtained by the user does not satisfy any of the conditions for automatic processing, the automatic processing is not executed, and the object becomes possessed by the user. Further, for any automatic processing, the user may arbitrarily select whether or not to adopt it.

  As described above, in this configuration, there are a plurality of automatic processes, and information regarding execution conditions is related to each automatic process, so that appropriate execution conditions according to each automatic process can be arbitrarily set. When the user obtains an object, an automatic process that satisfies the execution condition is determined from a plurality of automatic processes and executed, so that the operation burden on the user for the plurality of processes is reduced.

  2) In the above-described configuration, it is preferable to further include priority setting means (74) for presetting a priority indicating a processing priority for the plurality of automatic processes.

  According to this configuration, a priority is determined for each automatic process. Then, for example, the control unit determines whether or not the object obtained by the user is a target of each automatic processing in order of priority. As an example, when priorities are set in this order for the automatic processing of (A), (B), and (C) described above, (A) → (B) → (C ) In the order of). If there is a corresponding automatic process, the process is executed. Depending on the object obtained by the user, the automatic processing execution conditions of both (A) and (B) may be satisfied. However, the automatic processing execution conditions of (A) having a higher priority are selected. If the condition is satisfied, the automatic process (A) is executed at that stage. If none of the conditions for automatic processing is satisfied, the automatic processing is not executed, and the object obtained by the user becomes possessed by the user. Note that the priority can be set according to a request from the user, or the initial setting (default) priority can be used.

  With this configuration, the user can arbitrarily give priority to a plurality of automatic processes. Therefore, for example, when the number of in-game points is reduced, (A) automatic selling process can be given top priority, and when a present is received from another user, (C) automatic present process can be given top priority.

  3) In the configuration of 2), it is preferable to further include priority changing means (75) for automatically changing the priority according to the game situation of the user.

  Here, the user's game situation refers to the situation of increase / decrease of possessions such as in-game points held by the user, the situation of whether or not a reward was given after receiving a present from another user.

  For example, even if the user sets the priority as (B) automatic coalescence process → (A) automatic sale process → (C) automatic present process, if the in-game point falls below the threshold value, the priority changing means has priority. The degree is automatically changed, for example, (A) automatic sale processing → (B) automatic coalescence processing → (C) automatic present processing. After that, if the in-game points become equal to or higher than a predetermined value due to (A) automatic sale processing being preferentially executed, the priority is automatically returned to the original user setting. An example of automatic priority change will also be described in configurations 4) to 6) described later.

  With this configuration, the game management device automatically changes the priority for a plurality of automatic processes according to the user's game situation, so that the user does not have to perform an operation to change the priority each time the game situation changes. Thus, the operation burden on the user can be reduced.

  4) In the configuration of 3) above, the automatic process includes a first automatic process for consuming a user's possession, and the priority changing means (75) is configured to execute when the amount of the possession is less than a threshold value. It is preferable that the priority of the first automatic processing is made lower than a preset priority.

  Here, the user's possession means in-game points, items, etc. possessed by the user. In addition, the first automatic process includes the above-described (B) automatic coalescence process, but is not limited thereto (the form of coalescence may not be taken). For example, an automatic process for improving the ability parameter of a player character to be strengthened by using the player character obtained by the user as a practice partner, consuming practice ticket items owned by the user, and practicing with the player character to be strengthened Is also included in the first automatic processing.

  The priority changing means of this configuration is the first automatic function when the game situation is such that the amount of possession of the user is less than the threshold value (threshold value = insufficient point when the minimum point required for processing is set). The priority of processing is lowered from a preset priority. For example, when the priority set in advance is (B) automatic coalescence process → (A) automatic sale process → (C) automatic present process, the priority of (B) automatic coalescence process is second or lowest. (A) The automatic sale process is shifted to the first priority. In addition, it is good also as a structure which returns to the preset priority, if the quantity of a user's possession becomes more than predetermined value.

  With this configuration, when there is a first automatic process that involves the consumption of possessions, in the situation where the possession falls below the threshold, the priority of the process automatically decreases, for example, automatically increases the possession. A situation in which processing is given priority can be automatically constructed. This eliminates the need for the user to grasp the decrease in possession and change the priority of automatic processing, thereby reducing the operation burden on the user.

  5) In the configuration of 3), the automatic process includes a first automatic process for consuming a user's possession and a second automatic process for converting an object obtained by the user into the possession, The priority changing means (75) sets the priority of the second automatic processing to be higher than the priority of the first automatic processing until the amount of the holding becomes equal to or higher than a first threshold, and the holding The priority of the first automatic processing is made higher than the priority of the second automatic processing until the amount of the first automatic processing becomes equal to or higher than the first threshold and then becomes smaller than the second threshold equal to or lower than the first threshold. Is preferred.

  Here, the second automatic process includes the above-described (A) automatic sale process, but it does not necessarily have to take the form of sale. According to this configuration, in order to execute the first automatic processing (automatic coalescence processing, etc.), possession such as points is necessary, and this possession is acquired by the second automatic processing (automatic sale processing, etc.). Can do. Therefore, the priority changing means makes the priority of the second automatic processing higher than the priority of the first automatic processing until the amount of the possession becomes equal to or higher than the first threshold (for example, 10,000 points). And after the amount of possession becomes more than the 1st threshold because the 2nd automatic processing was performed preferentially etc., it becomes smaller than the 2nd threshold below the 1st threshold (for example, less than 1000 points) The priority of the first automatic processing is set higher than the priority of the second automatic processing (until the point becomes smaller or the point is insufficient). And if the possession becomes less than the second threshold, the priority of the second automatic process is set higher than the priority of the first automatic process again until the amount of the possession becomes equal to or greater than the first threshold.

  Here, the first threshold value and the second threshold value can be set to the same value, or the second threshold value can be made smaller than the first threshold value to perform hysteresis control.

  With this configuration, it is possible to automatically switch the priority between the first automatic process for consuming the possession and the second automatic process for acquiring the possession by increasing or decreasing the possession. This eliminates the need for the user to grasp the increase / decrease in possessions and change the priority of automatic processing, thereby reducing the user's operation burden.

  6) In the configuration of any one of 3) to 5), the automatic process includes an automatic present process for presenting a second user preset with an object obtained by the first user, and the priority When the second user gives a present to the first user and the first user does not give a present to the second user, the degree changing means (75) It is preferable that the processing priority is higher than a preset priority.

  Here, “present” refers to virtually giving (or giving) what the user owns in the game to another user. “Present” may be expressed as “gift (give)”, “gift (give)”, “transfer”, or the like.

  For example, the first user who received the present from the second user may try to return later because the appropriate item to return to the other party is not at hand. Therefore, when a present is given from the second user to the first user, and a situation occurs in which a return gift is not given from the first user to the second user, priority is given. The changing means sets the priority of the automatic present process for presenting the object acquired by the first user to the second user set in advance higher than the preset priority, and the return is executed early. To be. In addition, it is good also as a structure which returns to the preset priority, after the return present to a 2nd user is performed.

  With this configuration, when the user does not give a gift of return, the priority of the automatic present process is automatically increased without performing the operation of changing the priority, so that the operation burden on the user can be reduced. it can.

  7) In the configuration of 2), when the number of executions of the same automatic process reaches a predetermined number, priority changing means (75) for lowering the priority of the automatic process from a preset priority Is preferably further provided.

  According to this configuration, basically, automatic processing is executed according to a preset priority. However, when the number of executions of the same automatic processing reaches a predetermined number (for example, 10 times), the automatic processing is executed. The processing priority is lowered by one step or two or more steps. Here, when the number of times that the same automatic process is continuously executed reaches a predetermined number, the priority may be lowered, or when the cumulative number of executions of the same automatic process reaches a predetermined number The priority may be lowered.

  For example, the preset priority is (A) automatic selling process → (B) automatic coalescence process → (C) automatic present process. Here, when the number of executions of (A) reaches a predetermined number of 10, the priority of (A) is changed to, for example, the lowest order. Therefore, at the next object acquisition, the second priority (B) is regarded as the first priority, and it is first determined whether the execution condition of (B) is satisfied. Here, if the execution condition of (B) is not satisfied, it is determined whether the execution condition of (C) is satisfied next. If the condition is not satisfied, the process returns to (A) to determine whether the execution condition is satisfied. The

  With this configuration, it is possible to perform a plurality of automatic processes evenly while giving priority.

  8) A game system according to another aspect of the present invention includes a server (1,2,102) and a terminal device (3,302) that communicates with the server (1,2,102). Automatic processing means (71) for executing predetermined automatic processing on an object obtained by a user, a plurality of said automatic processing, and condition relating means (72) for relating information on execution conditions for each automatic processing; When the user obtains an object, control means (73) for determining an automatic process that satisfies the execution condition from among the plurality of automatic processes and executing the determined automatic process, the server (1, 2, 102) or Any one of the terminal devices (3, 302) is provided.

  9) A game management method according to another aspect of the present invention is a game management method in a computer that manages a game, wherein the computer executes a predetermined automatic process on an object obtained by a user. There are a plurality of automatic processes, and when the computer obtains an object for each automatic process, the computer associates a condition correlating step for associating information about execution conditions with the automatic process. And a control step of determining an automatic process that satisfies the execution condition and executing the determined automatic process.

  10) 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, 102, 302) for managing a game, the computer being used for an object obtained by a user. Automatic processing means (71) for executing predetermined automatic processing, there are a plurality of the automatic processing, condition relating means (72) for relating information on execution conditions for each automatic processing, and when the user obtains an object A program for determining an automatic process satisfying the execution condition from among the plurality of automatic processes and causing it to function as a control means (73) for executing the determined automatic process.

  According to the present invention, it is possible to reduce a user's operation burden on a plurality of processes in a game.

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 card | curd which the user acquired. It is explanatory drawing which shows an example of a present screen. It is explanatory drawing which shows an example of an automatic present condition setting screen. It is explanatory drawing which shows the example of a display of the pull-down menu in the screen of the said FIG. It is explanatory drawing which shows the other example of an automatic present condition setting screen. It is explanatory drawing which shows the other example of an automatic present condition setting screen. It is explanatory drawing which shows the other example of an automatic present condition setting screen. It is explanatory drawing which shows the other example of an automatic present condition setting screen. It is explanatory drawing which shows the example of a setting in the screen of the said FIG. It is explanatory drawing which shows an example of a buddy list screen. 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 a user's game information. It is explanatory drawing which shows an example of a player database. It is a functional block diagram which shows an example of main functional structures of a game management apparatus. It is a functional block diagram which shows the other example of main structures of a game management apparatus. It is explanatory drawing which shows an example of the automatic present conditions which set the range of the friend based on the familiarity. It is explanatory drawing which shows an example of the automatic present conditions which set the range of the friend based on the game level. It is explanatory drawing which shows an example of the automatic present conditions which set the range of the friend based on the access frequency to a game. It is explanatory drawing which shows an example of the automatic present conditions which set the range of the friend by combining intimacy, a game level, and the access frequency to a game. It is explanatory drawing which shows an example of the automatic present conditions which set the range of the companion based on the information which specifies an individual. It is a functional block diagram which shows the other example of main structures of a game management apparatus. It is a flowchart which shows the operation example of the game server which performs an automatic present process. It is explanatory drawing which shows an example of the alerting | reporting screen at the time of automatic present process execution. It is explanatory drawing which shows the other example of an automatic present condition setting screen. It is a functional block diagram which shows the other example of main structures of a game management apparatus. It is explanatory drawing which shows an example of the screen for setting an automatic present condition automatically. It is explanatory drawing which shows the example of a screen displayed when automatic present conditions are set automatically. 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 which alert | reports the candidate of a present object. It is a functional block diagram which shows the other example of main structures of a game management apparatus. It is explanatory drawing which shows an example of the screen displayed before sale processing. It is explanatory drawing which shows an example of an automatic sale condition setting screen. 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 an automatic synthetic | combination condition setting screen. It is explanatory drawing which shows an example of the execution condition linked | related with the some automatic process. It is a flowchart which shows the operation example of the game server which performs an automatic process. It is explanatory drawing which shows an example of the alerting | reporting screen at the time of automatic sale processing execution. It is explanatory drawing which shows an example of the alerting | reporting screen at the time of automatic coalescence process execution. It is a functional block diagram which shows the other example of main structures of a game management apparatus. It is explanatory drawing which shows an example of a priority setting screen. It is a flowchart which shows the operation example of the game server which performs an automatic process based on a priority. It is a functional block diagram which shows the other example of main structures of a game management apparatus. It is a flowchart which shows an example of the priority change process according to a user's game condition. It is a flowchart which shows the other example of the priority change process according to a user's game condition. It is a flowchart which shows the other example of the priority change process according to a user's game condition. It is a flowchart which shows an example of the priority change process according to the execution frequency of an automatic process. 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. 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.

  In the game management device of the present embodiment, when an object (character, item, etc.) of a gift candidate set in advance by the user is obtained in the game, the object is automatically presented to a friend. Furthermore, in this game management apparatus, the range of the friend who becomes the object of an automatic present can be defined. In other words, if the user sets in advance the range of the fellow and the conditions of the object to be presented to the fellow of the range, the object will automatically be surely taken without any hassle when acquiring the object that satisfies the condition. Presented to a friend within the above range. 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 characters displayed on the cards by combining (synthesizing) the collected cards (that is, nurturing the characters), and aim for a stronger team. have fun.

  In the present embodiment, each card is set to one of five levels of rarity (minimum 1 to maximum 5). Each card is set with a team to which the player belongs (for example, any of 12 professional baseball teams in Japan). Further, as will be described later, each user selects any one of the twelve teams as desired to make his own team.

  FIG. 4 shows an example of the main screen (my page) of the game. On this main screen, the player's card 201 selected as a leader among the cards owned by the user, the user's game information 202 (user level, various in-game points, the number of owned player characters, the number of friends, etc.) Is displayed. In the card 201, the form of the player character, the rare degree of the card (the value of the scarcity value is indicated by the number of stars), and the like are written.

  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. For example, action points and operating costs that are consumed and reduced during the game can be recovered over time (for example, 1 point is recovered every 3 minutes), or at a stretch by using a recovery item or level up It can be made to recover.

  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. This strengthening point can be obtained by selling a card held by the user. The lottery point is a point used in the “lottery mode” in which a card can be obtained by lottery. This lottery point 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”, “merging processing”, and the like can be executed for the cards possessed by the user. Each of these processes will be described later.

  Further, in this game, “present processing” can be executed for a card or the like possessed by the user. “Present” refers to virtually giving (or giving) what the user owns in the game to another user. “Present” may be expressed as “gift (give)”, “gift (give)”, “transfer”, or the like. Moreover, the virtual relationship in the game between the users who give presents is not particularly questioned. For example, the relationship between users may be friends, colleagues, families, bosses and servants, superiors and subordinates, seniors and juniors, etc. Giving is included in the “present”. In the present embodiment, the user can manually give a present to a friend or the like, or can automatically give a present by setting a present condition in advance.

  An example of an operation when a user manually presents a card to a friend will be described below. When the user obtains a card by executing “lottery mode” or the like, the screen transitions to the screen illustrated in FIG. 5, and the obtained card 210 and the card information 211 are displayed. The card information 211 includes a player name, team, position, ability value, and the like. Alternatively, if the player management button 203a is pressed on the main screen of FIG. 4, the player transitions to a player management screen (not shown), and a list of player cards held by the user is displayed. Here, if the user designates (selects) a specific card, the screen transitions to the screen of FIG. 5, and the designated card 210 and card information 211 are displayed. On the screen of FIG. 5, a sale button 212, a present button 213, and the like are also displayed. The sale button 212 is a button for selling the card 210 displayed on the screen. The present button 213 is a button for presenting the card 210 displayed on the screen 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, the screen transitions to the present screen shown in FIG. This screen is provided with a display area 218 for the object to be presented and a display area 219 for the party to be presented. In the display area 218, a present target card 210, information 211 of the card, information 214 of the number of users of the card, and the like are displayed. Further, in the display area 219, information 215 (friend avatar, name, level, team, etc.) of a friend selected as a partner to be sent, an input area 216 for a message sent to the friend, a gift button 217, and the like are displayed. Here, if the user presses a button 217 to be presented, the displayed card 210 can be presented to a friend. When an arbitrary message is input in the message input area 216, the message is delivered to the other party together with the present. In this case, the game server 1 notifies the fellow terminal device 3 that a present has arrived from the user.

  Thus, a troublesome work is required for a user to manually give a present to a friend. On the other hand, in the automatic present described below, the game server 1 automatically executes the present process simply by setting the range of the target friend and the condition of the object to be present to the fellow. Therefore, the operation burden on the user can be greatly reduced.

  The “companies range” to be presented can be determined based on “game information about friends” such as “intimacy with users”, “in-game level of friends”, “frequency of access to friends games”, etc. . Alternatively, the “companion range” can be determined based on “information for identifying an individual” such as a fellow user ID or a user name.

  First, an example in which the “companion range” is determined based on the “intimacy with the user” will be described. 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, message transmission, presents, battle cooperation, chat, and the like, but are not limited thereto, 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 is expressed in five levels from 1 to 5 at the minimum. Details of the intimacy application processing will be described later.

  FIG. 7 shows an example of an automatic present condition setting screen for arbitrarily setting a condition of an object to be present after the user specifies a range of friends by closeness. In this screen, a friend designation area 221 and a condition setting area 222 are provided.

  In the friend designation area 221, input units 223 and 224 for designating a familiarity range are displayed, and an example in which a friendship value can be selected from a pull-down menu and a fellow range can be designated is shown. For example, when “3” is selected by the input unit 223 and the input unit 224 is blank (not selected), “intimacy 3 or more” can be set. Further, for example, when the input unit 223 is left blank and “3” is selected by the input unit 224, “intimacy 3 or less” can be set. Further, for example, when “2” is selected by the input unit 223 and “4” is selected by the input unit 224, “intimacy 2-4” can be set.

  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.

  In the condition setting area 222, conditions for cards to be presented to friends of closeness specified in the friend specifying area 221 can be set. For example, in the condition setting area 222, conditions such as “player cards other than own team (rare degree 3 or less)”, “all player cards with a rarity level 2 or lower”, “all player cards with a rarity level 3”, etc. Items are displayed in advance. The user can easily set the condition simply by selecting a condition item using a check box or the like.

  In addition, the condition setting area 222 may be provided with input units 225 to 227 (pull-down menus) for setting conditions for teams and rareness. FIG. 8 shows a display example of the pull-down menu of the input units 225 to 227. The input unit 225 for setting the card team conditions includes “other than my team”, “other team”, “all teams”, “se league”, “pa league”, and a specific team (professional baseball Any one of 12 teams) can be specified. In addition, choices of rareness 1 to 5 are displayed on the input unit 226 for setting the rareness condition of the card. Also, the input unit 227 displays options that can specify “above” or “below”. For example, if “3” is selected by the input unit 226 and “below” is selected by the input unit 227, the rare degree “3 or less” is set. In this case, when neither “above” nor “below” is selected (blank), the rarity “3” is set.

  In addition, a setting button 228 is provided on the automatic present condition setting screen of FIG. 7, and setting information is transmitted from the user terminal device 3 to the game server 1 by pressing this button. In the game server 1, the setting information is received, associated with the user ID, and stored in the database server 2, the range of friends to be presented and the conditions for cards to be presented to the friends.

  As described above, if the user sets conditions for automatic presents (a range of friends and a card condition) in advance, when the user obtains a card that satisfies the conditions, the game server 1 will make a friend within the range. Present the card automatically. When there are a plurality of relevant friends, gifts may be given to friends randomly selected from them, or gifts may be sequentially given from friends with high intimacy.

  In the above, an example is shown in which the team condition and the rare degree condition can be applied as the automatic present card condition, but the present invention is not limited to this. For example, the position (pitcher, fielder, first base, second base,...) Condition may be applied alone or in combination with conditions such as team and rarity. For example, if a pitcher's position is set as a card condition, when a user obtains a pitcher's card, the card is automatically presented to friends in a range associated with the card condition.

  Further, the condition “automatically present only when the card obtained by the user is a card that is not owned by the other party” may be applied alone or in combination with other conditions. This is to allow the user to arbitrarily set the conditions because the partner may not be pleased even if the same card as the card already held by the partner is given. In addition, the condition “automatic gift is given only when the card obtained by the user is the same card as the card possessed by the opponent” may be applied alone or in combination with other conditions. . This allows the user to arbitrarily set the conditions, considering that the card held by the opponent without letting it go is the favorite card of the opponent. With this condition setting, it is possible to switch whether or not the automatic present process is executed depending on what kind of card the other party owns.

  In addition, the condition “automatic gift is given only when the card obtained by the user is the same card as the card owned by the user” may be applied alone or in combination with other conditions. . This is to allow the user to set the conditions arbitrarily if he / she obtains a duplicate of the card he / she already holds, considering that the card is unnecessary (or not so important) by himself / herself. . In addition, a condition that “automatically presents only when the card obtained by the user is a card that the user does not have” may be applicable. This allows the user collecting the same card to arbitrarily set the condition. With this condition setting, it is possible to switch whether or not the automatic present process is executed depending on what kind of card the user owns.

  By the operation on the automatic present condition setting screen described above, different card conditions can be set for different friend ranges. For example, it is possible to vary the conditions of a card to be given to a friend as follows between a friend whose intimacy is a predetermined level or higher and a friend who is lower than that. That is, a better (rare degree) card can be automatically presented to a friend with a higher intimacy than a friend with a lower intimacy. For example, for a range of friends whose intimacy is 3 or more, the condition of a card to be given to a friend is set to “all player cards with a rarity degree 3”. On the other hand, for a range of friends whose intimacy is 2 or less, the condition of the card to be given to the friend is set to “all player cards with a rarity 2 or less”. Thereby, the appropriate automatic present according to the intimacy of the friend becomes possible.

  Next, an example in which the “companion range” is determined based on the “in-game level” will be described. 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 In this baseball game, experience values are accumulated when the user advances the game (for example, executes the scout mode), and the game level of the user is increased when the experience value reaches a certain amount. . Note that in a game in which the game level is determined by winning or losing in-game competition, the user's game level is improved or decreased.

  In the baseball game, there are multiple levels of in-game leagues. For example, there are 10 in-game leagues from the first league at the lowest level to the tenth league at the highest level, and each user's team belongs to one of the in-game leagues and other users in the same league A match is automatically played against this team (this is referred to as an “automatic match”). Moreover, according to the result of this automatic battle | competition, the replacement game of the teams of the user who belongs to a different league is performed automatically, and the level of the in-game league to which a user's team belongs changes. Therefore, the level of the in-game league to which the fellow team belongs can also be used as the “in-game team level”. In-game levels may also be referred to as ranks, grades, ranks, etc.

  FIG. 9 shows an example of an automatic present condition setting screen for arbitrarily setting the condition of a card to be presented after the user specifies a range of friends according to the game level. On this screen, input units 231 and 232 for specifying the range of the friends according to the game level are displayed in the friend specifying area 221, and the game level value can be directly input by key input, voice input, or the like on the terminal device 3. As in FIG. 7, the range may be specified by selecting a game level value from a pull-down menu. At that time, the value of the game level may be 1 unit, but may be 10 units (10, 20, 30, etc.) so that the judgment at the time of input can be made easily. The condition setting area 222 is the same as the screen in FIG.

  By the operation on the automatic present condition setting screen of FIG. 9, different card conditions can be set for different friend ranges. For example, it is possible to make different conditions for cards to be given to friends by a friend whose game level is equal to or higher than a predetermined level and a friend whose level is lower than that. For friends with low game levels (such as friends who have just started the game), you can be happy to present a card that is not too rare, but for friends with a high game level, the degree of rareness is high. There is a high probability that you will not be very pleased if you give a card that you don't have. This is because many high-level friends already have multiple cards with a high degree of rarity. This is because it is not considered. Therefore, for example, for a range of friends whose game level is 30 or more, the condition of the card to be given to the friend is set to “all player cards with a rare degree 3”. On the other hand, for a range of friends whose game level is 29 or less, the condition of cards to be presented to the friends is set to “all player cards with a rarity level of 2 or less”. Thereby, an appropriate automatic present according to a friend's game level is attained.

  Next, an example in which the “companion range” is determined based on “the access frequency of the companion game” will be described. 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. Therefore, the game server 1 can acquire the access frequency based on the access log of each user.

  FIG. 10 shows an example of an automatic present condition setting screen for arbitrarily setting the conditions of cards to be presented after the user specifies the range of friends according to the access frequency to the game. On this screen, input units 233 and 234 for specifying the range of friends according to the access frequency to the game are displayed in the friend specifying area 221, and the access frequency value is directly input by key input, voice input, or the like in the terminal device 3. it can. As in FIG. 7, the range may be specified by selecting a game level value from a pull-down menu. The condition setting area 222 is the same as the screen in FIG.

  By the operation on the automatic present condition setting screen of FIG. 10, different card conditions can be set for different friend ranges. For example, it is possible to make different conditions for cards to be given to a friend between a friend whose access frequency to the game is equal to or higher than a predetermined level and a friend who is lower than that. 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. Therefore, for example, for a range of friends who access the game for four days or more in one week, the condition of the card to be given to the friend is set to “all player cards of rare degree 3”. On the other hand, for the range of friends who have access to the game for 3 days or less per week, the condition of cards to be presented to the friends is set to “all player cards with a rarity of 2 or less”.

  In addition, for example, for a range of friends having a predetermined access frequency or less (for example, one day or less per week), it is possible to prevent an automatic present from being executed by not setting an automatic present condition. Or you may set the conditions that an automatic present is not performed about the range of the friend below predetermined access frequency.

  With this configuration, an appropriate automatic present according to the access frequency of a friend's game can be made.

  7, 9, and 10 show examples in which friend ranges can be specified based on intimacy, game level, and game access frequency, respectively, but these can be combined to specify friend ranges. May be. For example, as shown in FIG. 11, in the friend designation area 221, input units 223 and 224 for designating a range of closeness, input units 231 and 232 for designating a range of game levels, and access to a game Input units 233 and 234 for specifying the frequency range are provided. In this case, for example, if the user specifies only the range of intimacy with the input units 223 and 224 and leaves the other input units blank, the range of friends can be specified only with the intimacy. For example, if the user specifies the familiarity range with the input units 223 and 224 and the game level range with the input units 231 and 232, the friendship range can be specified by combining the familiarity and the game level. This combination can be either an AND condition or an OR condition. In addition, the designation of the range of friends by the access frequency to the game is the same.

  Next, an example will be described in which “companion range” is determined based on “information for identifying an individual” such as a fellow user ID or user name. In this case, the game server 1 sets the range of the mate based on the user ID of the mate in response to a request from the user who specified the specific mate.

  FIG. 12 and FIG. 13 show an example of an automatic present condition setting screen for arbitrarily setting a condition of a card to be presented after the user designates a specific friend included in the fellow range. FIG. 12 is a screen example in an initial state where the automatic present condition setting screen is opened, and FIG. 13 is a screen example after an input for designating a specific friend is performed by the user.

  In the friend designation area 221 of the screen of FIG. 12, one or more arbitrary friends can be selected from all the friends of the user. A friend list button 235 is provided in the friend designation area 221, and when the button 235 is pressed, a friend list request is transmitted from the terminal device 3 to the game server 1. The game server 1 receives this request from the user's terminal device 3 and transmits information for displaying the user's buddy list to the terminal device 3. Thereby, for example, a friend list screen as shown in FIG. 14 is displayed on the terminal device 3, and an arbitrary friend can be selected. On this friend list screen, a list of friends including information such as avatars, names, levels, teams, cards set as leaders of the user's friends is displayed. In addition, about the information of the friend who cannot be displayed on a screen, the screen can be scrolled or the 2nd page or more of a friend list can be requested to the game server 1 and displayed as another screen. If an arbitrary mate is selected on this mate list screen (for example, by clicking the mate's avatar or name portion), the screen returns to the automatic present condition setting screen as shown in FIG. , Name, level, team, etc.) are displayed on the screen. In the example of FIG. 13, an example is shown in which the user has selected a friend B and a friend C. Note that only one friend may be set as the range of the friends, or three or more friends may be selected to set the range of the friends (conditional group).

  In addition, the area | region which inputs user ID in the associate designation | designated area | region 221 may be provided, and a user may designate a specific associate by inputting the associate's user ID directly. 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.

  In addition, as described later, when a user intends to designate a specific friend as a friend range, the user who is a candidate for the present is notified to the user based on the game information of the user's friend. Also good.

  The condition setting area 222 is the same as the screen in FIG. By operating on the automatic present condition setting screens of FIGS. 12 and 13, it is possible to specify a specific friend as a range of friends and set different card conditions for each range of friends. For example, in the case of a special friend who presents a player card of a partner team with a high degree of rarity to each other, for the user A, the friend B and the friend C may be, for example, “a friend team rare Set to 4th degree player card. In addition, when a card with a rarity level 3 is always given from the companion D, the companion D is designated as the range of the companion, and for example, “all player cards with a rarity level 3” is set as a condition of the card to be presented. . With this configuration, it is possible to set an appropriate object condition for a specific friend and automatically present it.

  As will be described later, when a specific friend is set as the range of the friend, the game server 1 automatically sets the condition of the object to be given to the friend based on the game information of the friend. Also good.

[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. 15 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. 16 shows an example of a user information database (information for one person with 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 the user ID with basic information of the user, desired team, level information, possession card, possession point, possession item, fellow information, access log, exchange history, desired information, etc. And stored in a predetermined storage area of the database server 2.

  Basic user information includes a login ID, a password, a user name (such as a nickname used in the game), and the like. 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 is a nickname used in the game.

  The desired team is information on favorite teams set by the user himself / herself when the user registers to receive the game service or when the game is executed for the first time. In the present embodiment, each user can register any one desired team among a plurality of teams (for example, 12 professional baseball teams in the real world).

  The level information includes the above-described game level of the user, in-game league level, and the like.

  The possessed card information is information (player ID, ability value, etc.) of a player character's card possessed by the user in the game. Moreover, as illustrated in FIG. 17, the database server 2 is associated with the player ID, and the player character's name, spine number, position, team, initial ability value (unstrengthened value), rarity, There is a player database (player DB) in which image data and the like are stored. Therefore, the game server 1 can acquire various information regarding the card (player character) corresponding to the player ID from the player DB based on the player ID stored by the user information storage control means 60. .

  The information on possession points is information on various points (including values corresponding to points) possessed by the user in the game and items. In the present embodiment, the aforementioned experience points, strengthening points, lottery points, action points, operating costs, and the like are included in the information on possession points. In addition, the items include the above-mentioned recovery items, reinforcement items for strengthening player characters, and the like. Each item is assigned an item ID that uniquely identifies them, and is managed by the item ID.

  Further, the fellow information is fellow information associated with the user, and the fellow user ID is stored in the database server 2 in association with the user ID. The access log is time information such as the date and time when the user terminal device 3 accesses (logs in) the game server 1. In addition, the exchange history is information on a history of a user's exchange with other users (such as friends) in the game. This AC history includes information on the type of AC, partner, and time. The types of exchange include greetings, message transmission, gifts, battle cooperation, and chat. As the information of the exchange partner, the user ID of the partner is stored.

  Also, in this game, cards and items that each user wants can be registered as desired. Information (a player ID or the like) of a desired item registered by the user is also stored 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. 15 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. 18A. The game server 1 as a game management device mainly includes a fellow management means 51 (management means), a setting means 52, and an automatic present means 53. 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 (other users) associated with 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. 16, 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 setting means 52 has a function of presetting the range of the present target fellows and the conditions of objects to be presented to the fellows within the range in response to a request from the user. As described above, the range of friends can be set based on intimacy, in-game level, access frequency to the game, information for identifying an individual (such as a friend's user ID). That is, on the automatic present condition setting screen shown in FIGS. 7, 9 to 12, etc. displayed on the user terminal device 3, the user inputs the range of the fellow and the condition of the card to be presented and presses the setting button 228. For example, a condition setting request is transmitted from the terminal device 3 to the game server 1. This is a request from the user. The setting means 52 of the game server 1 receives the condition setting request from the user, and sets (registers) the friend range and card conditions input by the user. In other words, in association with the user ID, the database range is stored in the database server 2 for the fellow range and the card conditions to be presented to the fellow within the range.

  FIG. 19 to FIG. 23 show an example of the automatic present conditions (friend range and card conditions) set by the user A with user ID = 000001. FIG. 19 is an example in which automatic present conditions are set by determining the range of friends based on intimacy. Here, a configuration in which the game server 1 provides intimacy will be described below.

  As shown in FIG. 24, the game server 1 includes a closeness giving means 54. This intimacy giving means 54 has a function of giving intimacy to two users who are in a peer relationship. The game server 1 stores and manages the closeness of two people in a friendship relationship in the database server 2. Below, the specific example of intimacy provision is given.

  For example, the intimacy giving means 54 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 addition, when the exchange of one or both of the friends is interrupted for a predetermined period (for example, one week), the intimacy points of the two persons may be decreased by a predetermined point (for example, three points). 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).

  As described above, in this game, the user can acquire lottery points by exchanging (greeting, present, etc.) with other users in the game. Then, as the intimacy with the opponent increases, the advantage that the lottery points (in-game points) that can be acquired by the exchange with the opponent increases. That is, if a user gives a present to a friend, the intimacy increases and the lottery points that can be acquired also increase. Therefore, stronger motivation for giving a present should be given. However, in the past, even if it was known that there was the above-mentioned merit, the operation of presents (determining an unnecessary card from one's own card or each time a new card is obtained, and further wanting it There was also a tendency that presents themselves were not actively carried out because it was time-consuming to assume unnecessary friends and give them unnecessary cards). In this regard, according to the present embodiment, the user only has to make a pre-set to give a present, and then the present is automatically performed and points are automatically acquired. A very useful function can be provided.

  And in this Embodiment, the range of a friend can be defined based on familiarity etc., and an automatic present condition can be set to the thing suitable for the range. Below, the specific example which sets the range of a friend based on closeness is shown.

  Generally, a user wants to make a partner happy by presenting a card (for example, a card with a high degree of rarity) that the partner wants as the friend with the higher intimacy. Therefore, in FIG. 19, the condition of “all player cards with a rarity level 3” is associated with a range of friends whose intimacy is 3 or more, and “all rarity level 2 or less” is assigned to a range of friends with a familiarity of 2 or less. The example of the setting of the automatic present condition in which the condition of “player card” is associated is shown.

  In the example of FIG. 19, an example in which the range of friends is divided into two stages of intimacy of 3 or more and 2 or less is shown, but is not limited thereto. 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. Alternatively, the automatic present condition may be set only for a friend with a closeness of 5, and the automatic present condition may not be set for other close friends (that is, the automatic present is not executed).

  FIG. 20 is an example in which automatic present conditions are set by determining the range of friends based on the game level. As described above, there is a high possibility that a friend who has a high game level will not be very happy even if he presents a card with a low rarity. Therefore, in FIG. 20, the condition of “all player cards with a rarity level 3” is associated with a range of friends whose game level is 30 or higher, and all the players with a game level of 29 or lower are assigned with “all rarity level 2 or lower”. The example of the setting of the automatic present condition in which the condition of “player card” is associated is shown.

  In the example of FIG. 20, an example in which the range of 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. For example, a friend with a level of 9 or less has a rare degree of 1, a friend with a level of 10 to 29 has a rare degree of 2, a friend with a level of 30 to 49 has a rare degree of 3, a friend with a level of 50 or higher has a rare degree of 4. Conditions for automatically presenting each card can be set.

  FIG. 21 is an example in which automatic present conditions are set by determining the range of friends based on the access frequency to the game. Even if a gift is given to a friend who has low access frequency to the game, the friend does not play the game so much, so it is unlikely that a gift will be returned from the opponent. On the other hand, if you give a gift to a friend who has a high frequency of access to the game, the chance of returning a gift from the opponent will be higher than in the above case, and you can expect to build a good relationship through the exchange of gifts. . Therefore, in FIG. 21, the condition of “all player cards with rare degree 3” is associated with the range of friends whose access frequency to the game is 4 days / week or more, and the access frequency is 2 days to 3 days / week. An example is shown in which the condition of “all player cards with a rarity of 2 or less” is associated with the range of friends, and the automatic present condition is not set for the range of friends with an access frequency of 1 day / week or less. This is an example, and the user can arbitrarily set the range of friends.

  Further, FIG. 22 shows an example in which a friend's range is set by combining three of intimacy, game level, and game access frequency according to an AND condition. In this example, a condition of “player card with a rarity of 4 in the opponent's team” is associated with a friend who satisfies the conditions of closeness 4 or higher, game level 100 or higher, and access frequency 5 days / week. ing. For users, the cards of their team (especially those with a high degree of rarity) are precious, so they often don't want to let go. Therefore, even when the condition of “card of the opponent's team” is set as the condition of the gift card, the user can arbitrarily set the card so that the user's own team card is excluded from the conditions of the automatic present. Also good.

  Thus, if game information such as intimacy, game level, and game access frequency is used, the range of friends can be set without specifying an individual.

  On the other hand, FIG. 23 shows an example in which an automatic present condition is set by determining a range of a friend based on information for identifying an individual (a friend's user ID). In this example, the range of friends is defined by the user ID of the friend B = 000002 and the user ID of the friend C = 000005, and the condition of “a player card with a rarity of 4 in the opponent's team” is associated with the range of the friends. ing. Further, a condition of “all player cards with a rarity level 3” is associated with the friend D of the user ID = 000010. In this way, a user can automatically specify a specific friend who wants to give a present and set arbitrary card conditions.

  The automatic present setting made as described above can be canceled at any time by the user. That is, when the user performs a predetermined release operation on the terminal device 3, a release request from the user is transmitted to the game server 1. In response to the cancellation request, the game server 1 deletes the automatic present setting information stored in association with the user ID or sets a setting cancellation flag. In this embodiment, you can specify multiple friends' ranges and set multiple automatic gifts with different card conditions, but you can also cancel all automatic gift settings at once, or only some settings Can also be canceled.

  Moreover, the automatic present means 53 has a function of automatically presenting an object to a friend within the range when the user obtains an object that satisfies the automatic present condition set as described above. Here, an example of the automatic present process by the game server 1 will be described below with reference to the flowchart of FIG.

  For example, when the user executes a game such as the scout mode or the lottery mode and obtains a new card (YES in S1), the game server 1 changes the automatic present conditions set in advance by the user from the database server 2. Obtain (S2). Thereafter, the game server 1 determines whether or not the card obtained by the user satisfies the automatic present condition (S3).

  As illustrated in FIG. 19 to FIG. 23, as an automatic present condition set in association with a user ID, a range of friends and a condition of a card to be presented to friends within the range are defined. Here, the case where the automatic present condition of FIG. 19 is applied is illustrated.

  For example, when the card obtained by the user is a card with a rarity level 3, the condition for presenting to a friend whose intimacy is 3 or more is satisfied (YES in S3). Therefore, in this case, the game server 1 executes an automatic present process for presenting the card obtained by the user to any of the friends having a closeness of 3 or more without accompanying the present operation by the user (S4). If there are a plurality of friends having a closeness of 3 or more, the game server 1 automatically gives a gift to a friend selected at random. Alternatively, every time the user obtains a card with a rarity level 3, gifts are automatically given sequentially from the friends with higher intimacy within the range of friends with intimacy 3 or higher. That is, when a card with a rarity level of 3 is first obtained, it is presented to a friend with the highest intimacy, and when the card is subsequently obtained, it is presented to a friend with the second highest intimacy. As described above, gifts are sequentially given from friends with high intimacy, and when gifts have been given to all of the friends with intimacy of 3 or more, the gift is returned to the friend with the highest intimacy again.

  Further, for example, if the card obtained by the user is a card with a rarity level 1 or 2, according to the automatic present condition in FIG. 19, the condition for presenting to a friend whose intimacy is 2 or less is satisfied (YES in S3). Therefore, in this case as well, the game server 1 executes the automatic present process for presenting the card obtained by the user to any of the friends having a closeness of 2 or less (S4). In this case, the game server 1 notifies the friend of the present destination that the present has arrived from the user.

  When the automatic present process is executed, the game server 1 notifies the user to that effect (S5). For example, the game server 1 generates a notification screen illustrated in FIG. 26 and transmits the notification screen to the user terminal device 3. This notification screen is provided with a region 240 for displaying the notification content, a region 241 for displaying the present object, a region 242 for displaying the present partner, a message transmission region 243, and the like. In the area 240, for example, a text “You have automatically given a card you have obtained to a friend” is displayed. In the area 241, the present card 246 and card information 247 (player name, affiliation team, position, ability value, etc.) are displayed. In the area 242, the avatar, name, level, team, card set for the leader, etc. of the friend of the present destination are displayed.

  In the message transmission area 243, a message input unit 244 and a transmission button 245 for automatically sending to a friend who has presented a gift are displayed. Here, when the user inputs an arbitrary message into the message input unit 244 and presses the send button 245, the game server 1 automatically delivers the message to the friend who presented it. The message transmission area 243 can be omitted. Further, if the close button 248 in the screen is pressed, the notification screen can be closed and the original game screen can be returned.

  On the other hand, if the card obtained by the user does not satisfy the automatic present condition in step S3 of FIG. 25 (NO in S3), the process of FIG. 25 is terminated without executing the automatic present process. In this case, the card obtained by the user becomes the property of the user himself / herself.

  As described above, the game management device according to the present embodiment is configured to include the friend management means 51, the setting means 52, the automatic present means 53, and the like shown in FIG. It is possible to set automatic present conditions that are suitable for other friends. Thereby, if the user presets an appropriate card (object) according to the range of the friend as a present candidate, when presenting the card, the user is surely presented to the friend in the range without taking time and effort. be able to. With this configuration, exchanges between friends can be deepened through presents.

  By the way, in the screen of FIG. 26, the configuration has been described in which a user can send a message to an associate after an automatic present has been executed. However, the user can set an arbitrary message to be transmitted simultaneously with the automatic present. You may do it. For example, as shown in FIG. 27, a message input unit 229 is provided on the automatic present condition setting screen. The user presses the setting button 228 after designating an automatic present condition (a condition of a friend and a condition of a card to be presented to a friend in the range) and inputting an arbitrary message in the message input unit 229. Accordingly, a condition setting request including the input message is transmitted from the user terminal device 3 to the game server 1. The setting means 52 of the game server 1 receives a condition setting request from the user, and sets (registers) a friend range, a card condition, and a message input by the user. That is, in association with the user ID, the database range is stored in the database server 2 in association with the friend range, conditions for cards to be presented to friends within the range, and a message that is automatically transmitted during automatic gifts. Thereby, when the game server 1 executes an automatic present, the game server 1 automatically transmits a preset message to the partner of the present destination. With this configuration, if a user sets a message in advance, the user can send a message to the other party at the same time as the automatic present without taking time and effort.

  Note that the user may be able to set a plurality of messages in advance in order to avoid sending the same message every time an automatic present is made. In this case, every time the game server 1 executes an automatic present, the game server 1 transmits a message randomly selected from a plurality of set messages to the opponent. Alternatively, the game server 1 assigns a predetermined order to a plurality of set messages, and each time an automatic present is executed, the messages to be transmitted are sequentially changed according to the order.

  By the way, even if the user determines the range of friends who are eligible for gifts and sets automatic gifts, some of the friends included in the range will have very little interest in the game or stop the game. There are also people who hate it. Alternatively, there is a possibility that a person who has already stopped the game at the time when the automatic present is set is included in the range of the friend. Therefore, a configuration will be described below in which, even if a friend who has been set with an automatic present is interested in the game, the friend who is very sparse or who has stopped the game is excluded from the target of the automatic present. As shown in FIG. 18B, the game server 1 having this configuration includes an exclusion unit 50.

  Even if the exclusion means 50 is a person who is included in the range of a friend who is the subject of an automatic present, a person whose access frequency to the game is a predetermined value or less, or a non-access period to the game is a predetermined period or more, It has a function of automatically excluding from automatic gift setting targets. Here, “the access frequency of a friend's game is equal to or less than a predetermined value” means that the number of days of access to a friend's game in a predetermined period (for example, one month last month or one month retroactive from the present) is a predetermined number of days (for example, 3 Day) and the following cases. When the access frequency of a friend's game is less than or equal to a predetermined value (3 days / month), it can be determined that the friend has a very little interest in the game or has stopped the game. The predetermined value related to the access frequency is not limited to “3 days / month”, and may be “7 days / 2 months”, for example, and an arbitrary value can be set.

  In addition, it can be determined that a friend whose “non-access period to the game has reached a predetermined period (for example, 30 days) or longer” has a very little interest in the game or has stopped the game. The predetermined period related to the non-access period to the game is not limited to 30 days, and may be two weeks, for example, and an arbitrary period can be set.

  When determining whether the “game access frequency is less than a predetermined value” or “the game non-access period is greater than or equal to a predetermined period”, access to a friend's game after the point when the automatic present is set Although it may be a target, it is also possible to target access to previous games. This is because there is a possibility that the interest in the game has already become very sparse or the game has been stopped when the automatic present is set.

  For example, the game server 1 determines the range of friends that are targets of automatic presents set by the user A every day (or may be once a week, etc.) at a fixed time (for example, midnight) (FIGS. 19 to FIG. 19). 23), the following processing is executed for the friends included. That is, the game server 1 is based on the fellow access log (see FIG. 16), and is an exclusion target fellow whose access frequency to the game is equal to or lower than a predetermined value or whose non-access period to the game is equal to or longer than a predetermined period. It is determined whether or not exists. Here, when there is a friend to be excluded, the excluding unit 50 automatically excludes the friend from the setting target of the automatic present. For example, the excluding unit 50 automatically cancels the setting of the automatic present for the fellow to be excluded. A specific example will be described below.

  First, the case where the automatic present condition shown in FIG. 23 is set will be described as an example. When it is determined that user ID = 000010 (companion D) is an exclusion target, the exclusion unit 50 automatically cancels the automatic present condition set for the fellow (deletes the setting information or deletes the deletion flag). Stand up). Moreover, when only the friend C is judged to be an exclusion target among the user ID = 000002 (friend B) and user ID = 000005 (friend C) included in the friend's range, the exclusion means 50 determines the user ID from the friend's range. = Only erase 000005 (or set an erase flag).

Next, the case where the automatic present condition shown in FIG. 19 is set will be described as an example.
For example, when it is determined that the user ID = 000010 (mate D) included in the range of friends whose intimacy is 3 or more is excluded, the exclusion unit 50 excludes the user ID = 000010 from the range of the friends. In this case, since the range of the friend is determined by the intimacy, in order to exclude the friend D from the range of the friend, the excluding unit 50 sets the user ID = 000010 as the information on the non-target person of the automatic present, for example. 2 and manage the friend D as a non-target person of the automatic present. The same applies to the case where the range of friends is determined by the game level, the access frequency to the game, and the like as shown in FIGS.

  According to this configuration, it is possible to avoid the automatic present from being executed for a friend who is not very interested in the game or who has stopped the game, that is, a friend who is not worth (or does not give) a present. In addition, it is not necessary for the user to perform an operation for canceling the automatic present for such a friend, and the user's operation can be saved.

  In addition, when the exclusion means 50 automatically excludes the above-mentioned exclusion target friends from the automatic present setting target, it is preferable to notify the user together with the reason. For example, when the terminal device 3 of the user A accesses the game, the game server 1 notifies the user that the message “Buddy D has not accessed the game for 30 days or more and has been excluded from automatic gifts.” A screen is generated and transmitted to the terminal device 3 of the user A.

  In addition, for a friend who is the target of automatic gift setting, the game information (intimacy, game level, game access frequency, etc.) of the fellow fluctuates, so that the target of automatic gift setting changes (the friend automatically There is a case where the present condition is not set or the range of the friend including the friend changes and the automatic present condition changes). In this case, it is preferable that the game server 1 is provided with an informing means for informing the user to that effect (alert). By this notification, it is possible to allow the user to recognize that the target of the automatic present that has been set once has changed along with the variation of the game information of the friend, and to give an opportunity to review the conditions of the automatic present for the friend. A specific example will be described below.

  For example, as illustrated in FIG. 19, it is assumed that the user A sets an automatic present condition in which a card condition of “all player cards with a rarity degree 3” is associated with a range of friends with “intimacy ≧ 3”. At the beginning of this automatic present condition being set, the friend C of “intimacy 3” was the target of the automatic present setting, but the friendship C was reduced to 2 due to the fact that the friend C did not interact much with the user A. Assume a decline. In this case, the companion C is out of the range of the companions of “intimacy ≧ 3”. If the automatic present condition is not set for the friend range of “intimacy ≦ 2”, the friend C will be excluded from the automatic present setting target. Further, as shown in FIG. 19, even when the automatic present condition “all player cards with a rarity level of 2 or less” is set for the range of friends of “intimacy ≦ 2”, the range of friends is changed. Along with this, the automatic gift conditions change. In this case, the notification means of the game server 1 is, for example, “Because the intimacy with the fellow C has decreased to 2, the fellow C has been excluded from the target of the automatic present (or the present conditions for the fellow C have changed) A notification screen that displays a message “is generated” is generated and transmitted to the terminal device 3 of the user A.

  Moreover, at the time of the notification, the game server 1 applies (a) the original automatic present condition to the fellow C, (b) resets the automatic present condition for the fellow C, (c) automatic for the fellow C. The user A may be presented with an option such as canceling the present. When the user A selects the above-mentioned option (a), the game server 1 returns the original automatic present condition “rare degree” to the friend C, even though the game server 1 is out of the friend range of “intimacy ≧ 3”. Set all three player cards as they are. In this way, the reason why the original automatic present condition can be applied as it is is that when the intimacy with a friend (or a friend's game level, etc.) becomes low, the present is stopped or the content of the present is lowered. It is because it may be difficult to do. Further, when the user A selects the option (b), for example, on the automatic present condition setting screen of FIG. 13, the screen changes to a screen in which only the friend C is specified as the friend range, and the user A becomes the friend C. On the other hand, any automatic present conditions can be reset.

  In the above description, an example has been shown in which the friend's intimacy is lowered and the target of the automatic present setting is changed, but the same is true when the friend's intimacy is improved and the target of the automatic present setting is changed. The same applies to the case where the target of the automatic present setting changes due to fluctuations in game information such as the game level of the friend who is the target of the automatic present setting and the access frequency to the game.

  Next, a configuration in which the game server 1 automatically sets an automatic present condition for a friend when the user designates a specific friend as a friend range will be described. The game server 1 having this configuration includes automatic setting means 55 as shown in FIG. This automatic setting means 55 presents the specific friend as a present based on the game information of the specific friend when the specific friend is set as the range of the friend based on the information specifying the individual specified by the user. A function for automatically setting the condition of the object to be executed.

  Here, an example will be described in which the automatic setting means 55 automatically sets the conditions for a card to be presented by the user simply selecting a specific friend on the automatic setting screen for automatic present conditions shown in FIG. A friend designation area 251 is provided on the screen of FIG. If the buddy list button 235 of this buddy designation area 251 is pressed, the screen changes to the buddy list screen of FIG. 14. If a specific buddy is designated here, the operation information (of the designated buddy is displayed from the user's terminal device 3. (Including the user ID) is transmitted to the game server 1. In accordance with this operation information, the automatic setting means 55 acquires the game information of the designated friend from the database server 2, and automatically sets the automatic present condition based on the game information of the friend.

  For example, the automatic setting means 55 automatically sets a card condition to present as a predetermined rare degree (rare degree 3, rare degree 4, etc.) with a player of a designated fellow team. In this case, the automatic setting means 55 can set an appropriate notification condition based on the game information of the friend such as the game level of the friend, the friendship of the friend, and the access frequency to the friend's game. For example, if the in-game level, familiarity, or game access frequency of the friend is greater than or equal to a threshold value, the condition of the gift card is set to a rare degree of 4, and if it is less than the threshold value, the rare degree is set to 3.

  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 guard condition of a predetermined rare degree (for example, rare degree 4) is automatically set on the card. For example, if the pitcher character included in the fellow team order does not have a rarity level of 4 or higher, the card condition of a rarity level of 4 or higher is automatically set with the pitcher card of the fellow team.

  The automatic setting unit 55 stores information on the automatically set automatic present condition in the database server 2 in association with the user ID.

  When the automatic present condition is automatically set, the game server 1 preferably transmits, for example, a screen illustrated in FIG. 30 to the terminal device 3 to notify the user of the automatically set condition. In the friend designation area 251 of the screen of FIG. 30, information 252 (avatar, name, level, team, etc.) of the friend designated by the user is displayed. 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 253 for information related to automatically set card conditions is provided on the screen. In this display area 253, automatically set card conditions 254, an OK button 255, a condition change button 256, and the like are displayed. FIG. 30 shows an example in which the card condition 254 “the pitcher card of the fellow team (rare degree 4)” is automatically set by designating the friend B. If the OK button 275 is pressed here, the screen of FIG. 30 is closed and the screen is changed to the main screen of FIG. 4 or returned to the screen of 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 256.

  With the configuration provided with the automatic setting means 55, the user simply designates a specific friend, and the automatic setting means 55 analyzes the game information of the fellow and automatically sets an appropriate present target card condition. The operation burden on the user can be reduced.

  Next, the structure which the game server 1 alert | reports the friend who becomes a candidate of a present object is demonstrated. As shown in FIG. 31, the game server 1 having this configuration includes candidate notification means 56. The candidate notifying means 56 has a function of extracting a friend who is a candidate for a present and notifying the user based on the game information (for example, present history, exchange history, etc.) of the friend related to the user. Have.

  As an example, associates who frequently give presents to users or send greetings or messages are extracted as candidates for presents and displayed on the user's game screen. Among them, it is preferable that a friend who frequently accesses (presents, greetings, etc.) frequently (for example, the last two weeks) is preferentially extracted as a gift candidate. This is because there used to be gifts that used to be a gift, but now there are few friends who have given away gifts, or who stopped the game on the way.

  An example of a process for extracting present target candidates is shown below. The game server 1 extracts a friend who has given a present to the user a predetermined number of times (for example, three times) or more as a present candidate for a predetermined time period (for example, two weeks) retroactive from the present. Alternatively, the game server 1 extracts a friend who has exchanged with the user a predetermined number of times (for example, 10 times) or more as a present candidate for a predetermined period (for example, two weeks) retroactive from the present. Here, the exchange can include greetings, message transmission, gifts, battle cooperation, chat, and the like. Moreover, not only this but various exchanges can be applied according to the kind and content of a game. As shown in FIG. 16, the exchange history as game information of each user is stored in the database server 2 in association with the user ID. Therefore, based on the exchange history of the user's associates, it can be seen how many times the associates exchanged presents and the like to the user within a predetermined period dating from the present.

  FIG. 32 shows an example of a screen for notifying a gift candidate. This screen is, for example, a screen for setting automatic present conditions in FIG. 13 or FIG. 29, and is a buddy list screen displayed after the buddy list button 235 is pressed. Note that the buddy list of FIG. 32 may be displayed not only when the automatic present condition is set, but also when the user manually performs a present operation for a buddy.

  In the buddy list of FIG. 32, a “gift target candidate” label 261 is displayed and notified to the user for the gift target candidates extracted by the game server 1. In this example, the label 261 is displayed for a friend who gave a present three times or more within two weeks retroactively from the present. Further, information 262 of the number of times that the friend has presented (or exchanged) to the user during a predetermined period (for example, two weeks) retroactive from the present is displayed in the friend list. The display of the number of times information 262 may be omitted.

  In addition, regarding the priority of displaying the buddy list, it is preferable to increase the priority (displayed at the top) as the buddy who has given the user a greater number of times.

  Even if there is a friend who often gives presents to the user, the user may not be able to remember the name of the friend even if he / she tries to designate the friend as a specific friend who is the target of the automatic present. However, according to this configuration, a friend who frequently gives presents is notified as a candidate for a present, so that the user can specify a specific friend smoothly.

  Next, the structure which can limit the period when an automatic present is performed is demonstrated. As described above, even if a companion that has been set with an automatic present can be configured to exclude a companion who is not very interested in the game or stopped the game from the target of the automatic present, In addition, the following configuration can also be adopted. That is, after an automatic present condition is set based on a request from a user, a predetermined period (for example, one week, one month, etc.) after the automatic present condition is set, instead of automatically presenting a present indefinitely. Only when the target card satisfying the condition is obtained, the automatic present is limited. This can eliminate the feeling of rut. The game server 1 having this configuration automatically cancels the setting of the automatic present condition when a predetermined period (automatic present period) elapses after the automatic present condition is set. Here, the automatic present period may allow the user to specify an arbitrary period, or a default period that is initially set in advance in the game server 1 may be used. For example, when the user sets an automatic present condition, if the user performs an operation for limiting the automatic present period to one week or the like, the game server 1 responds to the operation by setting the automatic present present date and time, the automatic present period (or automatic present period). Information such as the scheduled release date of the present) is stored in a storage device (such as the database server 2) in association with the user ID, and the automatic present period is managed. Alternatively, even if the user does not perform an operation for limiting the automatic present period, the game server 1 automatically sets the automatic present period, and automatically cancels the automatic present condition setting after the period has elapsed. Also good.

  When the user can arbitrarily set whether or not to limit the period during which the automatic present is performed, the following can also be performed. That is, it is possible to limit the period during which an automatic present is performed for an automatic present condition for a range of a fellow, and not to limit the period for which an automatic present is performed for an automatic present condition for a range of another fellow. Moreover, it is also possible to limit the automatic present period to one week for the automatic present condition for a range of a fellow, and to limit the automatic present period to one month for the automatic present condition for a range of another fellow.

  In addition, when the setting of the automatic present condition is canceled due to the elapse of the automatic present period, the game server 1 notifies the user to that effect and resets the automatic present period (substantial extension of the automatic present period) to the user. You may inquire whether to do it. In addition, you may use together said structure with the structure which cancel | releases an automatic present based on the friend access days and access frequency mentioned above. That is, as in this configuration, the automatic present is basically canceled when one month elapses, but until one month elapses, access to a friend's game for the present target For example, if there is no two weeks, the automatic present may be canceled without waiting for one month. In other words, while providing a fixed cancellation period of the automatic gift (the automatic gift period), the cancellation frequency is determined by giving priority to the access frequency of the friends.

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

  First, a schematic configuration of the game management device according to the present embodiment will be described. In the above-described embodiment, the automatic present process has been mainly described. However, in the present embodiment, there are a plurality of automatic processes for the object obtained by the user. For example, in addition to the “automatic gift process” described above, there are an “automatic sale process”, an “automatic merge process”, and the like described later. Various automatic processing can be applied depending on the type and content of the game. In this embodiment, the user can arbitrarily set the execution conditions for each automatic process independently. Accordingly, it is possible to set an appropriate execution condition according to each automatic process. It should be noted that an initial setting (default) condition may be used as an execution condition for each automatic process. For each automatic process, information related to the execution condition is related, and when the user obtains an object, an automatic process that satisfies the execution condition is determined from a plurality of automatic processes and executed. As a result, it is possible to reduce a user's operation burden for a plurality of processes. 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.

  As shown in FIG. 33, the game server 1 mainly includes automatic processing means 71, condition relation means 72, and control means 73. Each of these means is realized by the CPU 11 of the game server 1 executing the program according to the present embodiment.

  The automatic processing means 71 has a function of executing predetermined automatic processing on an object (such as a card) obtained by the user. As described above, there are a plurality of automatic processes, and in the present embodiment, a case will be described in which three automatic processes of “automatic sale process”, “automatic merge process”, and “automatic gift process” exist. The automatic processing means 71 includes an automatic selling means 71a for executing an automatic selling process, an automatic combining means 71b for executing an automatic combining process, and an automatic present means 71c for executing an automatic present process.

  As the automatic present means 71c, the automatic present means 53 described above can be applied. Therefore, the detailed description of the automatic present means 71c is omitted.

  In the above-described automatic present means 53, the configuration in which the automatic present condition can be varied depending on the range of the friends has been described. However, the automatic present means 71c of the present embodiment does not define the range of the friends, You may set automatic present conditions (execution conditions) common to friends. For example, the automatic present condition “all player cards with a rarity of 2 or less” may be a condition common to all the users' friends. About the automatic present process in this case, you may give to the friend selected at random from all the friends, and you may give a gift one by one from a friend with high intimacy.

  Next, the “automatic sale process” will be described. The sale process is a process of virtually selling a user-owned object (card, item, etc.) in a game and converting it into in-game points, in-game currency, and the like. In this game, the user can manually execute the selling process on the card obtained by the user, or can automatically execute the selling process by setting an execution condition (card condition to be sold) in advance.

  An example of an operation in which the user manually sells the card is shown below. When the user obtains a card by executing “lottery mode” or the like, the screen transitions to the screen illustrated in FIG. 5, and the obtained card 210 and the card information 211 are displayed. Here, if the user presses the sale button 212, a transition is made to the screen illustrated in FIG. The screen of FIG. 34 is a screen that is displayed before the sale process is executed. The strengthening point information 263 that can be obtained when the displayed card 210 is sold and the sale execution button 264 for executing the sale process are displayed. Is displayed. Here, if the user presses the sale execution button 264, the game server 1 executes the sale process of the card 210 displayed on the screen. When this sale process is executed, the displayed card 210 is excluded from the card owned by the user, and the strengthening points as the consideration are added as the user's owned points. In addition, the strengthening points as consideration vary depending on the rareness and ability value of the cards to be sold.

  As described above, it is necessary for the user to manually sell the card. On the other hand, in the automatic selling process described below, the game server 1 automatically executes the selling process simply by setting the execution condition for the selling process in advance, so that the operation burden on the user is greatly reduced. it can.

  FIG. 35 shows an example of an automatic sale condition setting screen for arbitrarily setting conditions for objects to be sold by the user. On this screen, for example, condition items such as “all player cards with a rarity level 1” and “all player cards with a rarity level 2 or less” are displayed in advance. The user can easily set the conditions for the card to be sold simply by selecting a condition item using a check box or the like. In addition, as in FIG. 8, input sections 225 to 227 (pull-down menu) for setting team and rareness conditions may be provided on the screen. The options displayed in the pull-down menu can be appropriately changed according to the condition to be set. The input method is not limited to this. For example, the team and the rare condition may be directly input by key input, voice input, or the like in the terminal device 3.

  In addition, a setting button 228 is provided on the automatic sale condition setting screen, and setting information is transmitted from the user terminal device 3 to the game server 1 by pressing this button. In the game server 1, the setting information is received, and the execution condition of the automatic sale process is stored in the database server 2 in association with the user ID.

  If the user sets execution conditions (card conditions for sale) in advance as described above, when the user obtains a card that satisfies the condition, the automatic selling means 71a automatically sells the card. .

  Next, the “automatic merge process” will be described. The coalescing process is a process of changing a parameter of another object (aiming to enhance the ability or the like) by merging a specific object held by the user with the other object. Execution of the merge process may require in-game points obtained by the sale process. In the game of the present embodiment, one strengthening target card is designated from among the cards possessed by the user, one or more strengthening material cards to be merged with the strengthening target card are designated, and the union processing is executed. . By combining processing, the capability of the reinforcement target card is improved according to the capability of the reinforcement material card, and the possession of the reinforcement material card held by the user is released. 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.

  In this game, the user can manually execute the merge process on the card obtained by the user, or can automatically execute the merge process by setting an execution condition (reinforcing material card condition, etc.) in advance. .

  An example of an operation in which the user manually combines the cards will be described 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. 36 shows an example of the strengthening mode screen when one strengthening target card 271 and one strengthening material card 272 are designated by the user. In this screen, when the user presses the merge execution button 273, the merge processing of the reinforcement target card 271 and the reinforcement material card 272 is executed, and instead of losing the reinforcement material card 272, according to the ability of the reinforcement material card 272. As a result, the ability of the reinforcement target card 271 is improved.

  Thus, a troublesome work is required for the user to manually combine the cards. On the other hand, in the automatic coalescing process described below, the game server 1 automatically executes the coalescing process only by setting the execution conditions for the coalescing process in advance, so that the operation burden on the user is greatly reduced. it can.

  FIG. 37 shows an example of an automatic coalescence condition setting screen for the user to arbitrarily set execution conditions for the automatic coalescence process. This screen is provided with an area 281 for designating the reinforcement target card and an area 282 for setting the conditions for the reinforcement material card. For example, if the area 281 is tapped (or clicked), a list of cards held by the user is displayed, and the user can designate an arbitrary card as a card to be strengthened. The reinforcement target card 271 specified by the user is displayed in the area 281. If there is a card that has already been strengthened, the card may be displayed in the area 281. If a card change button 283 provided in the area 281 is pressed, a list of cards held by the user is displayed, and the card to be strengthened can be set again.

  In the area 282 for setting the conditions of the reinforcement material card, for example, condition items such as “the same team as the reinforcement target and the rarity level 3 or less”, “all the player cards having the rarity level 2 or less” are displayed in advance. . The user can easily set the conditions for the reinforcing material card simply by selecting a condition item using a check box or the like. In addition, as in FIG. 8, input sections 225 to 227 (pull-down menu) for setting team and rareness conditions may be provided on the screen. The options displayed in the pull-down menu can be appropriately changed according to the condition to be set. The input method is not limited to this. For example, the team and the rare condition may be directly input by key input, voice input, or the like in the terminal device 3.

  In addition, when the card to be reinforced and the card with the reinforced material satisfy the predetermined conditions such as the same team, the same position, the same player, etc., the ability improvement rate (parameter change rate) of the reinforced object card compared to the case where the predetermined condition is not satisfied May be increased. In this case, in addition to the team and the rarity, conditions such as “the same position as the reinforcement target” and “the same player as the enhancement target” may be set as conditions for the reinforcement material card.

  Further, a setting button 228 is provided on the automatic coalescence condition setting screen, and setting information is transmitted from the user terminal device 3 to the game server 1 by pressing this button. In the game server 1, the setting information is received, and the execution condition of the automatic coalescence process is stored in the database server 2 in association with the user ID.

  As described above, if the user sets the execution condition (the card condition of the reinforcing material) in advance as described above, when the user obtains a card that satisfies the condition, the automatic coalescing means 71b specifies the card in advance. It automatically merges with the card that is being enhanced.

  Next, the condition associating means 72 in FIG. 33 will be described. The condition relating means 72 has a function of relating information related to execution conditions for each of a plurality of automatic processes. That is, when an execution condition for a certain automatic process is set in response to a request from the user, the condition relation unit 72 stores information related to the execution condition in the database server 2 in relation to the automatic process. Alternatively, the user can select to apply default execution conditions that are initially set for each automatic process. When a default execution condition is applied to a certain automatic process, the condition relation unit 72 stores information on the default execution condition in the database server 2 in relation to the automatic process.

  FIG. 38 shows an example of execution conditions for each automatic process set by user A with user ID = 000001. In this example, an execution condition of “all player cards with a rarity level of 3 or less” is associated with the automatic sale process. Further, execution conditions such as “reinforcement target card = 0007” and reinforcement material card condition “same team as reinforcement target and rare degree 3 or less” are associated with the automatic coalescence process. The automatic present process is associated with an execution condition of a range of friends to be presented “user ID = 000002” and a condition of a card to be presented “an opponent team and rare degree 3”. Furthermore, the automatic present process is also associated with an execution condition of a range of friends to be presented “user ID = 000010” and a condition of a card to be presented “all player cards with a rarity of 2 or less”.

  In the example of FIG. 38, a preferred form in which priorities are set for each automatic process is shown, but setting of priorities is not essential and can be omitted. The priority will be described later.

  As described above, the database server 2 stores information in which a plurality of automatic processes and respective execution conditions are associated with each other in association with the user ID. The user can set arbitrary conditions for each automatic process. In addition, whether or not to adopt any automatic processing can be arbitrarily selected by the user. For example, the automatic sale process and the automatic merge process may be executed, but the automatic present process may not be executed. When a certain automatic process is not adopted, the execution condition is not related to the automatic process (for example, the execution condition column may be blank or a flag for switching the execution condition between valid / invalid may be set invalid).

  Next, the control means 73 in FIG. 33 will be described. The control unit 73 has a function of determining a specific automatic process that satisfies the execution condition among a plurality of automatic processes and executing the determined automatic process when the user obtains the card. The card obtained by the user may satisfy a plurality of automatic processing conditions. In this case, the control means 73 may determine an automatic process to be executed at random or an automatic process to be executed based on a preset priority.

  Here, an example of automatic processing by the game server 1 will be described below with reference to the flowchart of FIG. For example, when the user A executes a game such as the scout mode or the lottery mode and obtains a new card (YES in S11), the game server 1 executes the automatic processing execution conditions (see FIG. 38) is acquired from the database server 2 (S12). Thereafter, the game server 1 determines whether or not the card obtained by the user A satisfies any of a plurality of automatic processing execution conditions (S13).

  For example, it is assumed that the card obtained by the user A is a “team T” and “rare degree 3” card. Further, it is assumed that the execution conditions of the automatic processing shown in FIG. 38 are applied. In this case, the automatic sale process satisfies the execution condition “all player cards with a rare degree of 3 or less”. As for the automatic coalescence process, the execution condition “same team as the reinforcement target and rare degree 3 or less” is satisfied only when the team to which the reinforcement target card “player ID = 0007” belongs is “team T”. The team to which “player ID = 0007” belongs can be acquired from the player database (see FIG. 17). As for the automatic present process, the execution condition “other team and rareness degree 3” is satisfied only when the desired team of the friend “user ID = 000002” to be presented is “team T”. The desired team of “user ID = 000002” can be acquired from the user information database (see FIG. 16).

  In step S13, when any of the execution conditions for a plurality of automatic processes is satisfied (YES in S13), the game server 1 determines an automatic process to be executed (S14). Here, when only one automatic processing execution condition is satisfied, it is determined as an automatic processing to be executed. Further, when a plurality of automatic processing execution conditions are satisfied, the game server 1 randomly determines one automatic processing among them, for example. Alternatively, the game server 1 may determine an automatic process having a higher priority as an execution target based on a preset priority of each automatic process.

  Thereafter, the game server 1 executes the automatic process determined in step S14 (S15). If the executed automatic process is an automatic sale process, the game server 1 sells the card obtained by the user and converts it into a strengthening point. In this case, the user information database is updated so that the card obtained by the user does not become the user's possessed card and the reinforcement points are added. When the executed automatic process is an automatic coalescence process, the game server 1 combines the card (enhancement material) obtained by the user with a preset reinforcement target card to improve the ability value of the reinforcement target card. . In this case, a predetermined effect display (moving image display or the like) may be performed. When the automatic coalescence process is executed, the card obtained by the user does not become the possessed card of the user, and the ability value of the strengthening target card is updated to the value after the coalescence. Moreover, when the automatic process performed is an automatic present process, the game server 1 presents the card which the user acquired to the friend of the present object set beforehand. In this case, the user information database is updated so that the card obtained by the user does not become the possession card of the user but becomes the possession card of the friend of the present destination. In addition, you may make it the friend's card | curd be the card which was presented by the friend's reception operation of a present.

  When the automatic process is executed, the game server 1 notifies the user to that effect (S16). For example, when the automatic present process is executed, the game server 1 generates the notification screen illustrated in FIG. 26 and transmits it to the user terminal device 3 as described above. Further, when the automatic sale process is executed, the game server 1 transmits a notification screen illustrated in FIG. 40 to the user terminal device 3. On the notification screen, sold cards 285, possessed point information 286 increased by sale, and the like are displayed. When the automatic composition process is executed, the game server 1 transmits a notification screen illustrated in FIG. 41 to the user terminal device 3. On this notification screen, a card 287 obtained by the user and used as a strengthening material, information 289 of the strengthening points consumed by the automatic coalescing process, information 290 for improving the ability of the card to be strengthened, and the like are displayed.

  On the other hand, in step S13 of FIG. 39, when the card obtained by the user does not satisfy any of the automatic processing execution conditions (NO in S13), the processing of FIG. 39 is terminated without executing the automatic processing. In this case, the card obtained by the user becomes the property of the user himself / herself.

  As described above, the game management apparatus according to the present embodiment is configured to include the automatic processing means 71, the condition relation means 72, the control means 73, and the like shown in FIG. Since execution conditions are related, it is possible to arbitrarily set appropriate execution conditions according to each automatic process. And when a user acquires an object, since the specific automatic process which satisfy | fills an execution condition is determined and performed among several automatic processes, the user's operation burden with respect to several processes is reduced.

  Next, a configuration for setting a priority for each automatic process will be described. The game server 1 having this configuration includes priority setting means 74 as shown in FIG. The priority setting unit 74 has a function of setting in advance a priority indicating a processing priority order for the plurality of automatic processes. Here, the priority of each automatic process can be set according to a request from the user, or an initial setting (default) priority can be used.

  FIG. 43 shows an example of a priority setting screen for the user to arbitrarily set the priority. On this screen, a priority setting area 291 and a setting button 292 are displayed. In the priority setting area 291, the priority can be set by arranging “automatic sale process”, “automatic coalescence process”, and “automatic gift process” in descending order of priority. For example, the order of arrangement can be changed by dragging and dropping the display of each automatic process. Further, for example, if the display of each automatic process is double-clicked (double-tap), the current execution condition set for the automatic process may be confirmed and changed. When the setting button 292 is pressed on this screen, setting information is transmitted from the user terminal device 3 to the game server 1. The game server 1 receives the setting information and stores the priority of each automatic process in the database server 2 in association with the user ID (see FIG. 38). Thus, in this embodiment, the user can arbitrarily give priority to a plurality of automatic processes.

  The control means 73 of this embodiment determines in order of priority whether or not the card obtained by the user is the target of each automatic process. As an example, assume that (A) automatic sale processing, (B) automatic coalescence processing, and (C) automatic present processing, and priorities are set in this order in advance. In this case, it is determined whether or not the card obtained by the user is subject to automatic processing in the order of (A) → (B) → (C). If there is a corresponding automatic process, the process is executed. Depending on the card obtained by the user, the automatic processing execution conditions of both (A) and (B) may be satisfied, but the automatic processing execution conditions of (A) having a higher priority are set. If the condition is satisfied, the automatic process (A) is executed at that stage. When none of the conditions for automatic processing is satisfied, the automatic processing is not executed, and the card obtained by the user becomes the possession of the user.

  The flowchart in FIG. 44 shows an operation example of the game server that executes automatic processing based on priority. Here, a processing flow in which the priority is a variable n is illustrated.

  When the user obtains the card (YES in S21), the variable n is initialized to “1” (S22). Then, the game server 1 acquires the execution condition of the first priority automatic process from the plurality of automatic process execution conditions (see FIG. 38) associated with the user ID (S23). Then, the game server 1 determines whether or not the card obtained by the user satisfies the execution condition (S24). If the execution condition is satisfied (YES in S24), the first priority automatic process is executed (S25), and a notification to that effect is given to the user (S26).

  On the other hand, if the execution condition is not satisfied in step S24 (NO in S24), the variable n is incremented to n = 2 (S27). Thereafter, it is determined whether or not the variable n is larger than 3 (S28). This step S28 is a step for determining whether or not all three automatic processes have been determined. If n = 2 (NO in S28), the process returns to step S23, and the game server 1 acquires the execution condition of the second priority automatic process. Then, the game server 1 determines whether or not the card obtained by the user satisfies the execution condition (S24). If the execution condition is satisfied (YES in S24), the second priority automatic process is executed (S25), and the fact is notified to the user (S26).

  On the other hand, if the execution condition of the second-priority automatic process is not satisfied (NO in S24), the variable n is incremented to n = 3 (S27). If n = 3 (NO in S28), the process returns to step S23, and the game server 1 acquires the execution condition of the third priority automatic process. Then, the game server 1 determines whether or not the card obtained by the user satisfies the execution condition (S24). Here, if the execution condition is satisfied (YES in S24), the third priority automatic process is executed (S25), and the fact is notified to the user (S26).

  On the other hand, if the execution condition of the third-priority automatic processing is not satisfied (NO in S24), the variable n is incremented to n = 4 (S27). If n = 4 (YES in S28), the process in FIG. 44 is terminated without executing the automatic process. In this case, the card obtained by the user becomes the property of the user himself / herself.

  In this example, the case where there are three automatic processes is illustrated, but there may be two or four or more automatic processes.

  Next, a configuration for automatically changing the priority set for each automatic process will be described. As shown in FIG. 45, the game server 1 having this configuration includes priority changing means 75. The priority changing means 75 has a function of automatically changing the priority according to the game situation of the user. Here, the user's game situation refers to the situation of increase / decrease of possessions such as in-game points held by the user, the situation of whether or not a reward was given after receiving a present from another user.

  With this configuration, the priority for a plurality of automatic processes is automatically changed according to the user's game situation, so that it is not necessary for the user to change the priority each time the game situation changes. The operation burden can be reduced. Below, the specific example which changes a priority automatically is demonstrated.

  First, the case where the 1st automatic process which consumes a user's possession (points in a game, an item, etc.) is included in a plurality of automatic processes is explained. In the present embodiment, the automatic merge process that consumes the reinforcement points and merges the cards corresponds to the first automatic process.

  The first automatic process is not limited to the automatic coalescence process (it may not take the form of coalescence). For example, an automatic process for improving the ability parameter of a player character to be strengthened by using the player character obtained by the user as a practice partner, consuming practice ticket items owned by the user, and practicing with the player character to be strengthened Is also included in the first automatic processing. The first automatic process includes various automatic processes that consume the user's possessions. Here, the first automatic process will be described as an automatic coalescence process.

  The priority changing means 75 of the present embodiment lowers the priority of the automatic coalescence process from a preset priority when the amount of strengthening points held by the user is less than the threshold. Here, the threshold value can be set to a minimum value necessary for the automatic coalescence process. In this case, if the amount of strengthening points is less than the threshold value, the game situation is such that the automatic coalescence process cannot be executed due to insufficient points. Note that the threshold may be set larger than the minimum value, and the priority of the automatic coalescence process may be lowered from a preset priority before the point becomes insufficient.

  The flowchart of FIG. 46 shows an example of the priority change process according to the user's game situation (increase / decrease of possession points). For example, it is assumed that the user has set the priority to automatic coalescence processing → automatic sale processing → automatic gift processing. Here, if the strengthening point possessed by the user falls below the threshold value of 1000 points (YES in S31), the priority changing means 75 changes the priority of the automatic coalescence process to the lowest order (S32), for example. That is, the priority is automatic sale processing → automatic gift processing → automatic merge processing. Note that the priority of the automatic coalescence process may be lowered by one level, and automatic sale processing → automatic coalescence processing → automatic gift processing.

  The priority changing unit 75 stores the information on the priority of the original user setting in the storage device so that the priority can be restored later when the priority is automatically changed.

  After that, when the strengthening points possessed by the user become, for example, 10,000 points or more (YES in S33) and the automatic coalescence process that consumes the strengthening points can be executed with a margin, the priority changing means 75 automatically To the original user setting priority (S34).

  With this configuration, when there is an automatic coalescence process that involves the consumption of possession points (holdings), the priority of the automatic coalescence process automatically drops when the possession points are below the threshold. It is possible to automatically construct a situation where priority is given to the increased automatic sales process. As a result, it is not necessary for the user to grasp the decrease in possession points and to change the priority of automatic processing, and the operation burden on the user can be reduced.

  Next, in a plurality of automatic processes, a first automatic process that consumes a user's possessions (points, etc.) and a second automatic that converts an object obtained by the user into possessions used in the first automatic process A case including processing will be described. In the present embodiment, the automatic merge process that consumes the reinforcement points and merges the cards corresponds to the first automatic process. Moreover, the automatic sale process which sells the card | curd which the user acquired and converts into a reinforcement | strengthening point corresponds to a 2nd automatic process. Note that the second automatic process is not limited to the automatic sale process (it may not take the form of sale). Here, the first automatic process is described as an automatic coalescence process, and the second automatic process is described as an automatic sale process.

  The priority changing unit 75 of the present embodiment automatically performs the priority changing process illustrated in the flowchart of FIG. 47 according to the amount of strengthening points held by the user. That is, the priority changing unit 75 sets the priority of the automatic sale process higher than the priority of the automatic coalescence process until the amount of strengthening points held by the user becomes equal to or higher than the first threshold (for example, 10,000 points) ( S41). As a result, as long as the user has only a small number of strengthening points, priority is given to the automatic sale process, and the strengthening points are easily accumulated.

  Furthermore, after the amount of enhancement points held by the user becomes equal to or greater than the first threshold (10000 points) (YES in S42), the priority changing means 75 starts from the second threshold (eg, 1000 points) that is equal to or less than the first threshold. The priority of the automatic merging process is made higher than the priority of the automatic selling process until it becomes smaller (S43). Thus, after the strengthening points are accumulated to some extent, the automatic coalescence process that consumes them is prioritized and the player card is easily strengthened.

  Further, when the amount of strengthening points held by the user becomes smaller than the second threshold value (1000 points) (YES in S44), the priority changing means 75 returns to step S41 and again sets the priority of the automatic selling process. Make it higher than the priority of the automatic coalescence process.

  The second threshold value may be a minimum value necessary for the automatic coalescence process, or may be a larger value. In the example of FIG. 47, the second threshold value is made smaller than the first threshold value and hysteresis control is performed. However, the first threshold value and the second threshold value can be set to the same value.

  With this configuration, it is possible to automatically switch the priority between the automatic coalescence process that involves the consumption of possession points (holdings) and the automatic sale process that can earn points by increasing or decreasing the possession points. As a result, it is not necessary for the user to grasp the increase / decrease in possession points and to change the priority of automatic processing, and the operation burden on the user can be reduced.

  Next, the case where an automatic present process is included in a plurality of automatic processes will be described. For example, the first user who received the present from the second user may try to return later because the appropriate card to return to the other party is not available. Here, a 1st user is demonstrated as the user A and a 2nd user is demonstrated as the friend B of the user A. When the user A has set the execution condition of the automatic present process which makes the friend B the range of the friend of a present object (refer FIG. 38), the priority change means 75 of this Embodiment operates as follows. To do. That is, the priority changing means 75 is set in advance when the present is given to the user A from the friend B and the present is not given to the friend B from the user A. Set higher than priority. As a result, a gift of return is given to the friend B from the user A at an early stage.

  The flowchart of FIG. 48 shows an example of the priority changing process according to the game situation of user A (present exchange). Here, a case where user A receives a present from friend B is taken as an example.

  After the user A receives a present such as a card from the companion B (YES in S51), the game server 1 determines whether or not a reward for the companion B is given (S52). Examples of determining that “user A did not give a gift of return to fellow B” are shown in (a) to (c) below.

  (A) When a present is given to the user A from the friend B, the present in the form in which the present item is owned by the user A (form of the receiving operation is required) is performed only when the user A performs the receiving operation. Is determined based on the fact that the user A did not operate the gift of return when performing the receiving operation.

  (B) When a present is given from user B to user A, user A receives the present for a present in which the present item is immediately owned by user A (a form requiring no receiving operation). When the fact is confirmed on the screen, the determination is made based on the end of the screen (or transition to another screen) without operating the gift of return.

  (C) Judgment is made based on the fact that a return gift was not given from the user A to the friend B within a predetermined time (for example, 24 hours) from when the friend B gave the present to the user A (reception operation required and unnecessary) Applicable to any form).

  In step S52, when the game server 1 determines that the user A did not give a gift of return to the companion B (NO in S52), whether or not the execution condition of the automatic present process for the companion B as a present is set. Is determined (S53). This determination can be made by confirming the automatic processing execution condition setting information of FIG. 38 stored in association with the user ID of user A. In the example of FIG. 38, since the execution condition which makes the friend B (user ID = 000002) the range of the friend of present object is set, step S53 becomes YES.

  If YES in step S53, the priority of the automatic present process is changed to the highest level (S54). Note that the priority of the automatic present process need only be higher than a preset priority, and does not necessarily have to be the highest priority. However, since it is better to give a return gift as soon as possible, it is preferable to set the priority of the automatic gift process to the highest priority.

  By the way, as an execution condition of the automatic present process in FIG. 38, a condition of “partner team and rare degree 3” for a companion B (user ID = 000002) and a companion C (user ID = 000010) are presented. A plurality of different conditions such as “all player cards with a rarity of 2 or less” are set. In this case, only the companion B is the object of return. Therefore, it is also possible to make only the priority of the automatic present process that targets the companion B higher than the preset priority and not increase the priority of the automatic present process that does not target the companion B as a present. is there. For example, the priority set in advance is set as automatic sale processing → automatic merge processing → automatic gift processing. After changing the priority, automatic present processing (targeting the companion B) → automatic sale processing → automatic coalescence processing → automatic presenting processing (targeting the companion C).

  After step S54, when a present from the user A to the friend B is executed (YES in S55), the game server 1 automatically returns the priority to the original user setting (S56). Here, the present from the user A to the friend B may be an automatic present process, or may be a manual operation of the user.

  On the other hand, when the user A gives a gift of return to the friend B in step S52 (YES in S52), or the execution condition of the automatic present process for the friend B as a gift target is not set in step S53 (in S53). NO), the process is terminated without changing the priority.

  According to the configuration of the present embodiment, when the user does not give a gift of return, the priority of the automatic present process is automatically increased without performing the operation of changing the priority, thereby reducing the operation burden on the user. Can be achieved.

  Next, a description will be given of a configuration in which each automatic process is performed uniformly while giving priority to a plurality of automatic processes. The priority changing means 75 having this configuration has a function of lowering the priority of the automatic processing from a preset priority when the number of executions of the same automatic processing reaches a predetermined number. An example is described below.

  For example, it is assumed that priorities are set in advance in the order of (A) automatic sale processing → (B) automatic coalescence processing → (C) automatic present processing. When the user obtains the card, basically, based on the processing flow of FIG. 44, it is determined whether or not the execution conditions of the automatic processing are satisfied in the order of preset priority, and the automatic processing that satisfies the conditions is determined. Executed. Here, for example, when the number of executions of (A) reaches a predetermined number (for example, 10 times), the priority of (A) is lowered by one or more stages. For example, the priority of (A) is the lowest. Therefore, when the user obtains the card next time, the second priority (B) is regarded as the first priority, and it is first determined whether or not the execution condition of (B) is satisfied. Here, if the execution condition of (B) is not satisfied, it is determined whether the execution condition of (C) is satisfied next. If the condition is not satisfied, the process returns to (A) to determine whether the execution condition is satisfied. The

  The flowchart in FIG. 49 shows an example of priority change processing according to the number of times automatic processing is executed.

  The game server 1 associates information on the number of executions of each automatic process (automatic sale process, automatic coalescence process, automatic present process, etc.) executed during the user's game with the user ID, and stores it in a storage device (database server 2 Etc.) are stored and managed. First, the game server 1 initializes the number of executions of each automatic process (S71). With this initialization, the number of executions of each automatic process is set to “0”.

  Thereafter, when any automatic processing is executed on the card obtained by the user (YES in S72), the game server 1 increments the number of times the automatic processing has been executed (S73). Then, the game server 1 determines whether or not the number of executions of the automatic processing has reached 10 (S74). If the number of executions of the automatic process has not reached 10 (NO in S74), the process returns to step S72 and waits until any automatic process is executed next.

  On the other hand, when the number of executions of the automatic process reaches 10 (YES in S74), the game server 1 changes the priority of the automatic process to the lowest level (S75). In addition, the game server 1 initializes the number of executions of the automatic process (S76), returns to step S72, and waits until any of the automatic processes is executed next.

  With this processing flow, the priority of the automatic processing that has reached the number of executions of 10 is changed to the lowest level, and the priority of other automatic processing is increased. By repeating this, the priority of each automatic process is sequentially changed, and a plurality of automatic processes are easily performed uniformly.

  In the above description, the configuration has been described in which, when the number of executions of the same automatic process reaches a predetermined number, the priority of the automatic process is automatically reduced. That is, when the number of executions of the same automatic process reaches a predetermined number, the game server 1 notifies the user to that effect. For example, the game server 1 generates a notification screen and transmits it to the user terminal device 3. Further, at the time of this notification, the game server 1 may inquire the user whether or not to continue the automatic processing priority and / or the automatic processing execution condition.

  That is, when the number of executions of a certain automatic process reaches a predetermined number, the user is given an opportunity to review the setting of the automatic process by notifying the user of that fact. The user can continue the automatic processing as it is, change the execution condition of the automatic processing, change the priority of each automatic processing, or cancel the future automatic processing.

[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. 18A, the game server 1 includes the friend management unit 51, the setting unit 52, and the automatic present unit 53. However, as illustrated in FIG. 50, the function of each unit is set to either the server or the terminal device. It is possible to have it. Here, the hardware configuration of the server shown in FIG. 50 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. 50 shows a configuration example in which the friend management unit 51 is provided in the server 101 and the setting unit 52 and the automatic present unit 53 are provided in the terminal device 301. FIG. 50 shows an example of the configuration of the game system, and other configurations are possible.

  In addition, as shown in FIG. 51, the terminal device 301 may include a friend management unit 51, a setting unit 52, and an automatic present unit 53. That is, the game management device can be mounted on the terminal device 301 itself, which is a game terminal, and in this case, the same effects as those of the above-described embodiment can be obtained. In this case, the server 101 manages game information of each user and provides services such as greetings and message transmission / reception between the terminal devices 301, but all other processing is performed on the terminal device 301 side. Can be executed in Alternatively, management of game information of each user can also be performed on the terminal device 301 side of each user.

  Similarly, in FIG. 33, the game server 1 is provided with the automatic processing means 71, the condition relation means 72, and the control means 73. As illustrated in FIG. It is possible to have it. FIG. 52 shows a configuration example in which the condition association unit 72 and the control unit 73 are provided in the server 102 and the automatic processing unit 71 is provided in the terminal device 302. FIG. 52 shows an example of the configuration of the game system, and other configurations are possible. Further, as shown in FIG. 53, the terminal device 302 may include an automatic processing means 71, a condition relation means 72, and a control means 73. In this case, the same effects as those of the above-described embodiment can be obtained.

  In addition, the above-described intimacy providing means 54, automatic setting means 55, candidate notifying means 56, priority setting means 74, priority changing means 75, etc. are not only on the server side but also on the terminal device (game terminal) side. It can also be provided.

[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.

  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 50 Exclusion means 51 Associate management means (management means)
52 setting means 53 automatic presenting means 54 familiarity giving means 55 automatic setting means 56 candidate notifying means 71 automatic processing means 71a automatic selling means 71b automatic merging means 71c automatic presenting means 72 condition relating means 73 control means 74 priority setting means 75 Priority change means 101, 102 Server (game management device, game system)
301, 302 Terminal device (game management device, game system)

Claims (8)

Automatic processing means for executing predetermined automatic processing on the object obtained by the user;
There are a plurality of the automatic processes, and for each automatic process, a condition correlation means for relating information related to execution conditions,
Control means for determining an automatic process that satisfies the execution condition among the plurality of automatic processes and executing the determined automatic process when the user obtains an object;
Priority setting means for setting in advance a priority indicating the priority of processing for the plurality of automatic processes;
Priority changing means for automatically changing the priority according to the game situation of the user ,
The automatic process includes a first automatic process for consuming a user's possession, and a second automatic process for converting an object obtained by the user into the possession,
The priority changing means sets the priority of the second automatic processing to be higher than the priority of the first automatic processing until the amount of the possession becomes a first threshold value or more, and the amount of the possession. A game management device that sets the priority of the first automatic process higher than the priority of the second automatic process until the first threshold is smaller than the second threshold equal to or less than the first threshold after the value becomes equal to or greater than the first threshold . Before SL priority changing unit, when the amount of the holding is less than the threshold value, the first priority of automatic processing, game management device according to claim 1 to lower than the priority which is set in advance . The automatic process includes an automatic present process for presenting a second user preset with an object obtained by the first user,
The priority changing means is the automatic present process when a present is given from the second user to the first user and no present is given from the first user to the second user. game management device according to claim 1 or 2 priority, higher than the priority that is set in advance. Automatic processing means for executing predetermined automatic processing on the object obtained by the user;
There are a plurality of the automatic processes, and for each automatic process, a condition correlation means for relating information related to execution conditions,
Control means for determining an automatic process that satisfies the execution condition among the plurality of automatic processes and executing the determined automatic process when the user obtains an object;
Priority setting means for setting in advance a priority indicating the priority of processing for the plurality of automatic processes;
If the number of executions of the same automatic processing has reached a predetermined number, the priority of the automatic processing, though Ruge over-management apparatus and a priority changing means for reducing than the priority that is set in advance. The game management device according to claim 1, wherein the game management device is configured as a server capable of communicating with a game terminal device operated by a user. The game management device according to claim 1, wherein the game management device is configured as a game terminal device operated by a user. The game management device according to any one of claims 1 to 4, 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 4 , wherein the program causes the computer to function as each unit included in the game management device .

Images