JP6854787B2 - Terminal devices, computers, control methods, and control programs - Google Patents

Description

The present invention relates to a game control method, a game control device and a program.

In recent years, social games provided on social networking services (SNS) and played while communicating with other users are known.

The application program for playing this social game is a native application that is downloaded to the communication terminal and installed and used on the communication terminal, and a web application that runs on the web server and is used by the web browser of the communication terminal. It can be roughly divided into (Web application).

A native application is an application that depends on the OS of a communication terminal such as an iPhone (registered trademark) terminal or an Android (registered trademark) terminal of a smartphone. For example, the server device distributes a native application such as an iPhone application equipped with Objective-C or an Android application equipped with Java (registered trademark) from the platform to each communication terminal.

The native application needs to be developed in two types, the programming language "Objective-C" compatible with the iPhone terminal and the programming language "Java" compatible with the Android terminal. Therefore, the native application needs to be published through the official marketplace after the coding process using the platform-specific language of the communication terminal.

On the other hand, the web application can be cross-developed for both platforms based on languages such as HTML5 (Hyper Text Markup Language 5), Javascript (registered trademark), and CSS3 (Cascading Style Sheets 3). No need to go through the marketplace. In addition, the web application does not depend on the OS of the terminal.

By the way, in some of the above-mentioned social games, a group called a guild can be formed by a plurality of users (players) who play the social game. In such a social game, information can be shared or communicated among a plurality of users (guild members) constituting the same guild.

Further, in a social game in which, for example, various characters owned by the user are used to battle with an enemy character, the guild can cooperate to battle with an enemy character called, for example, a raid boss. In this way, if the guild cooperates in a battle with an enemy character and wins as a result of the battle, the guild member can obtain various benefits (for example, characters and items).

Japanese Unexamined Patent Publication No. 11-244533

Therefore, an object of the present invention is to provide a game control method, a game control device, and a program capable of providing a mechanism for a plurality of users to play cooperatively.

According to one aspect of the present invention, group management indicating a group composed of a plurality of users who play a game and is communicably connected to a plurality of communication terminals used by each of the plurality of users who play the game. A game control method executed by a game control device having a storage means for storing information and component item information indicating a plurality of component items constituting one item is provided. This game control method includes a step of assigning a configuration item to each of a plurality of users, a step of storing acquisition configuration item information indicating the configuration item assigned to each of the plurality of users in a storage means, and a storage means. Based on the obtained configuration item information stored in, for a plurality of users who compose the group indicated by the group management information, a plurality of configuration items required to configure one item indicated by the configuration item information. The storage means further stores the level management information indicating the level of each of the plurality of users, and in the step of assigning the configuration item, the storage means is configured based on the level management information. It is characterized in that it is determined whether or not to give each of the plurality of constituent items indicated by the item information to each of the plurality of users, and the user can specify the group to which each of the plurality of users belongs.

The present invention makes it possible to provide a mechanism for a plurality of users to play cooperatively.

It is a block diagram which shows the hardware configuration of the network system including the game control device which concerns on embodiment of this invention. It is a block diagram which mainly shows the functional structure of the game control device 50 shown in FIG. It is a figure which shows an example of the data structure of the card parameter management information stored in the storage part 42 shown in FIG. It is a figure which shows an example of the data structure of the robot parameter management information stored in the storage part 42 shown in FIG. It is a flowchart for demonstrating the flow of the card battle game in this embodiment. It is a flowchart which shows the processing procedure of the game control device 50 when a quest is started in the card battle game of this embodiment. It is a flowchart which shows the processing procedure of the game control device 50 when evolution-synthesizing a card character in the card battle game of this embodiment. It is a flowchart which shows the processing procedure of the game control device 50 when the robot battle occurs in the card battle game of this embodiment. It is a flowchart which shows the processing procedure of the parameter setting process for battle executed by the parameter setting unit 53. It is a flowchart which shows the processing procedure of the robot battle effect image generation processing executed by the game control unit 54. It is a flowchart which shows the processing procedure of the robot battle effect image generation processing executed by the game control unit 54. It is a figure which shows an example of the data structure of the guild management information stored in the storage part 42. It is a figure which shows an example of the data structure of the component item information stored in the storage part 42. It is a figure which shows an example of the data structure of the acquisition composition item information stored in the storage part 42. It is a figure which shows an example of the data structure of the level management information stored in the storage part 42. It is a flowchart which shows the processing procedure of the guild event generation processing executed by the game control device 50 which concerns on this embodiment. It is a flowchart which shows the processing procedure of the guild event management processing executed by the game control device 50 which concerns on this embodiment.

Hereinafter, embodiments of the present invention will be described with reference to the drawings.

FIG. 1 is a block diagram showing a hardware configuration of a network system (game control system) including a game control device according to the present embodiment.

The network system shown in FIG. 1 is mainly composed of a computer (server computer) 10 and a plurality of communication terminals 20 used by each of a plurality of users who play, for example, a social game. Note that in FIG. 1, for convenience, only one communication terminal 20 is shown.

The plurality of communication terminals 20 are communicably connected to the computer 10 via a network 30 such as the Internet.

As the communication terminal 20, for example, a smartphone, a feature phone, a tablet terminal, or the like can be used, and the hardware configuration specific to the model, the OS adopted, the installed application program, and the like are diverse. To do.

The computer 10 is connected to an external storage device 40 such as a hard disk drive (HDD: Hard Disk Drive). The external storage device 40 stores a program 41 executed by the computer 10. The computer 10 and the external storage device 40 constitute a game control device 50.

The game control device 50 according to the present embodiment has a function of providing a card battle game (social game) using a card character as a game element such as various characters to a user via a communication terminal 20. In the card battle game of the present embodiment, the user may perform a battle (battle) with an enemy character such as a non-player character (NPC) by combining a plurality of card characters owned by the user via the communication terminal 20. it can. Further, in the card battle game of the present embodiment, a mechanism for cooperatively playing by a plurality of users is provided as described later.

The card battle game in the present embodiment operates on the game control device (web server) 50 and is realized by a web application used by the web browser of the communication terminal 20.

FIG. 2 is a block diagram showing mainly a functional configuration of the game control device 50 shown in FIG.
As shown in FIG. 2, the game control device 50 includes a card management unit 51, a deck construction unit 52, a parameter setting unit 53, and a game control unit 54. In the present embodiment, each of these parts is realized by the computer 10 shown in FIG. 1 executing the program 41 stored in the external storage device 40. This program 41 can be stored and distributed in advance in a computer-readable storage medium. Further, the program 41 may be downloaded to the computer 10 via the network 30.

Further, the game control device 50 includes a storage unit 42. In the present embodiment, the storage unit 42 is stored in, for example, the external storage device 40.

The card management unit 51 has a function of giving various card characters and items used in the card battle game to a user who plays the card battle game according to the progress of the card battle game described above. It is assumed that parameters are set in advance for the card character given by the card management unit 51 (that is, the card character owned by the user). In addition, the card management unit 51 has a function of managing card characters and items (information about) owned by the user.

The deck construction unit 52 selects a plurality of card characters (first characters) owned by the user according to the user's operation on the communication terminal 20. The deck construction unit 52 constructs a deck of a user who plays a card battle game by using a plurality of selected card characters and a robot character (a second character owned by the user) different from the card character. .. In other words, the deck constructed by the deck construction unit 52 includes a plurality of card characters and robot characters.

The robot character is a game element given to the user in advance when playing, for example, a card battle game. Further, it is assumed that parameters are set in advance for the robot character as in the case of the card character described above.

The parameter setting unit 53 determines the parameters of the robot character based on the parameters set for the plurality of card characters and the robot characters included in the deck constructed by the deck construction unit 52. The parameters determined by the parameter setting unit 53 are set as parameters for the robot battle of the robot character.

The game control unit 54 has, for example, a function of receiving operation information indicating various operations of the user with respect to the communication terminal 20 from the communication terminal 20 and controlling the overall progress of the card battle game based on the operation information and the like. ..

Further, in the case of a battle between a robot character and an enemy character in which the above-mentioned parameters for robot battle are set (hereinafter referred to as robot battle), the game control unit 54 sets the parameters for the robot battle and the enemy character. The battle between the robot character and the enemy character is controlled based on the parameters set for. In this case, the game control unit 54 generates an image for displaying the robot battle effect and the result of the robot battle (hereinafter, referred to as a robot battle effect image). The robot battle effect image generated by the game control unit 54 is displayed on the communication terminal 20 via the network 30.

In addition, the game control unit 54 generates an event (hereinafter, referred to as a guild event) for cooperatively playing in a group called a guild composed of a plurality of users. When this guild event occurs, a plurality of users constituting the guild can obtain various benefits (for example, card characters and items) by satisfying predetermined conditions in the guild event.

Various information necessary for controlling (progressing) the card battle game is stored in the storage unit 42. Specifically, the storage unit 42 refers to parameter management information (hereinafter referred to as card parameter management information) including parameters preset for various card characters used in the above-mentioned card battle game and robot characters. Parameter management information (hereinafter referred to as robot parameter management information) including preset parameters is stored in advance. When a new card character, robot character, or the like is added as a new game element of the card battle game, the parameter management information or the like stored in the storage unit 42 is updated.

Further, the storage unit 42 relates to guild management information (group management information) indicating a guild composed of the above-mentioned plurality of users, information on guild events, card characters and items owned by users who play card battle games, and the like. Information and information about the user are stored.

FIG. 3 shows an example of the data structure of the card parameter management information stored in the storage unit 42 shown in FIG.

As shown in FIG. 3, the card parameter management information includes HP (hit points), attack power, speed, and skill (parameters) in association with the card ID. The card ID is an identifier for identifying the card character. The HP is a numerical value of the damage that the card character identified by the card ID can withstand the attack of the enemy character. When the HP becomes 0, for example, the battle becomes impossible, and the battle is defeated. The attack power is a numerical value of the ability to attack the enemy character, and affects the damage given to the enemy character. The speed is a numerical value that affects, for example, the order of attacks in a battle with an enemy character. Skills generate predetermined effects in battles with enemy characters, and include, for example, offensive skills, defensive skills, pre-combat skills, and the like, as will be described later.

In the example shown in FIG. 3, the card parameter management information includes HP “100”, attack power “10”, speed “12”, and skill “skill 1” in association with the card ID “1”. According to this, the HP of the card character identified by the card ID "1" is 100, the attack power is 10, the speed is 12, and it is shown that the card character has skill 1. Has been done.

Similarly, the card parameter management information includes HP "120", attack power "15", speed "8", and skill "skill 2" in association with the card ID "2". According to this, the HP of the card character identified by the card ID "2" is 120, the attack power is 15, the speed is 8, and it is shown that the card character has skill 2. Has been done.

Here, the card parameter management information has been described as including parameters of HP, attack power, speed, and skill, but other parameters may be included.

FIG. 4 shows an example of a data structure of robot parameter management information stored in the storage unit 42 shown in FIG.

As shown in FIG. 4, the robot parameter management information includes HP, attack power, speed, and (parameters) of attributes in association with the robot ID. The robot ID is an identifier for identifying the robot character. Since the HP, attack power, and speed are the same as those included in the above-mentioned card parameter management information, detailed description thereof will be omitted here. The attribute indicates an attribute assigned to the robot character identified by the robot ID, and includes, for example, a long-distance type, a medium-distance type, a short-distance type, and the like.

In the example shown in FIG. 4, the robot parameter management information includes HP “300”, attack power “30”, speed “40”, and attribute “medium” in association with the robot ID “1”.
According to this, the HP of the robot character identified by the robot ID "1" is 300, the attack power is 30, the speed is 40, and the robot character (attribute) is a medium-range type. It is shown.

Further, the robot parameter management information includes HP "290", attack power "25", speed "50", and attribute "far" in association with the robot ID "2". According to this, the HP of the robot character identified by the robot ID "2" is 290, the attack power is 25, the speed is 50, and the robot character (attribute) is a long-distance type. It is shown.

Further, the robot parameter management information includes HP "320", attack power "35", speed "30", and attribute "near" in association with the robot ID "3". According to this, the HP of the robot character identified by the robot ID "3" is 320, the attack power is 35, the speed is 30, and the robot character (attribute) is a short-range type. It is shown.

In the card battle game of the present embodiment, for example, three types of robot characters (robot characters identified by robot IDs "1" to "3") are prepared in advance as shown in FIG. The robot character selected by the user at the time of initial registration to the battle game shall be given to the user. As a result, the user can perform the above-mentioned robot battle in the card battle game according to the present embodiment. It should be noted that each of the three types of robot characters shown in FIG. 4 is advantageous for one of the other two attributes, for example, with respect to the other attribute, depending on the attributes of the robot character. Can have characteristics such as being disadvantageous.

In FIGS. 3 and 4, among the information stored in the storage unit 42, the card parameter management information and the robot parameter management information have been described, but details of other information will be described later.

Hereinafter, the flow (main cycle) of the card battle game in the present embodiment will be schematically described with reference to the flowchart of FIG. The purpose of the card battle game in the present embodiment is to obtain cards (characters and items) having high rare value by, for example, a user (player) searching for a search target (for example, a planet) called a chapter. .. In addition, it is assumed that a quest is set in advance in the chapter.

When the card battle game of the present embodiment is started, the communication terminal 20 displays a list of chapters that can be searched by the user.

The user can select a chapter by operating the communication terminal 20 used by the user (step S1).

When a chapter is selected by the user, the search image of the selected chapter is displayed on the communication terminal 20, and the quest set in the chapter is started (step S2).

When the quest is started, the user can clear the quest by performing an operation (for example, a tap operation) on the communication terminal 20 (step S3). The conditions for clearing this quest shall be set in advance.

If a plurality of quests are set in the chapter selected by the user, the above steps S2 and S3 are repeated for each quest.

When all the quests set in the chapter selected by the user are cleared, a robot battle with the enemy character (NPC) set in the chapter is generated (step S4). In the following description, an enemy character (NPC) that performs a robot battle is referred to as an enemy robot character for convenience, and another enemy character is simply referred to as an enemy character.

If the robot battle is won, the user can clear the chapter selected by the user (step S5). In this case, a new chapter is generated that can be searched by the user (that is, the new chapter is released).

Here, if the user does not instruct the end of the card battle game (NO in step S6), the user can search (select) a new chapter by returning to step S1 described above.

On the other hand, when the user gives an instruction to end the card battle game (YES in step S6), the card battle game is ended.

According to the card battle game in the present embodiment, the game progresses by clearing each of the above chapters, and a card or the like having a higher rare value can be obtained.

Next, the processing procedure of the game control device 50 when the quest is started in the card battle game of the present embodiment will be described with reference to the flowchart of FIG.

When the quest is started as described above, the game control unit 54 included in the game control device 50 generates an event corresponding to the quest (step S11). Events that occur in quests include, for example, experience points to improve the level of users (such as card characters owned by them) by searching for chapters, in-game currencies that can be used in card battle games, and various cards (characters and items). ) Etc. are included, and battle events that fight with enemy characters in the quest are included. Experience points, in-game currency, and various cards can be obtained even if the enemy character is defeated in a battle event.

Depending on the event that has occurred, a simple user operation (for example, tap operation) on the communication terminal 20 is required. The game control unit 54 advances the card battle game (quest) when the requested operation is performed by the user.

When the event is generated and the quest progresses as described above, a battle with the enemy character (quest boss) set for the quest occurs (step S12). This quest boss is a character whose ability (for example, parameters such as HP and attack power) is higher than that of the enemy character in the above-mentioned battle event.

The battle with the enemy character and the battle with the quest boss in the above-mentioned battle event are different from the above-mentioned robot battle, for example, one of a plurality of card characters owned by the user (hereinafter, leader card character). (Notation) shall be used. Specifically, the game control unit 54 is based on the parameters set for the leader card character and the parameters set for the enemy character or the quest boss included in the parameter management information stored in the storage unit 42. , Control the battle between the leader card character and the enemy character or quest boss.

The game control unit 54 displays the result of the battle with the quest boss (that is, victory or defeat) on the communication terminal 20 (step S13).

Here, if you win the quest boss, the quest will be cleared and a new quest will occur. When a plurality of quests are cleared in this way, a robot battle occurs as described above.

In the card battle game of the present embodiment, one of a plurality of card characters owned by the user (hereinafter referred to as a base card character) is a card character other than the base card character (hereinafter referred to as a synthetic card character). ) Can be evolved and synthesized (enhanced).

Here, with reference to the flowchart of FIG. 7, the processing procedure of the game control device 50 when the card characters are evolved and synthesized in the card battle game of the present embodiment will be described.

In this case, the game control unit 54 included in the game control device 50 displays a list of a plurality of card characters owned by the user on the communication terminal 20. As a result, the user can select the base card from the list of a plurality of card characters owned by the user by operating the communication terminal 20. The game control unit 54 determines the base card character according to the operation of the user (step S21).

Further, the user can select a synthetic card from a list of a plurality of card characters owned by the user by operating the communication terminal 20. The game control unit 54 determines the composite card character according to the operation of the user (step S22).

The game control unit 54 increases points related to the evolution of the base card character (hereinafter referred to as evolution points) according to, for example, parameters set in the synthetic card character (step S23). It is assumed that the evolution points of this base card character are stored and managed in, for example, the storage unit 42. At this time, the increase in evolution points is notified to the user by a gauge or the like displayed on the communication terminal 20.

The game control unit 54 determines whether or not the evolution point of the base card character has reached a predetermined value (hereinafter referred to as a predetermined value) for the base card character (that is, MAX). (Step S24).

When it is determined that the evolution point of the base card character has reached the specified value (YES in step S24), the game control unit 54 evolves the base card character (step S25). The parameters of the base card character evolved in this way are set higher than the parameters of the base card character before the evolution.

That is, in the card battle game of the present embodiment, by evolving and synthesizing various card characters in this way, the game can be advanced advantageously in a robot battle with an enemy robot character, a battle with an enemy character, and the like.

On the other hand, if it is determined that the evolution point of the base card character has not reached the specified value (NO in step S24), the process of step S25 is not executed. In this case, the increased evolution points of the base card character are stored and managed in the storage unit 42 or the like, and are used in the next evolution synthesis of the base card character.

In step S23 described above, for example, when the synthetic card character is the same as the base card character, the number of evolution points to be increased is increased. As a result, for example, it is possible to encourage the user to consume the same card character in order to evolve the card character having a high rare value, so that the card character having a high rare value can be easily given to the user (that is, the rare card character). You can increase the probability of ejecting high-value cards). In addition, a card character (base card character) whose evolution points are difficult to reach the specified value can be set, and the card character can be acquired only when a specific enemy character (for example, a raid boss described later) is defeated. By making it possible, it is possible to encourage the player to fight the specific enemy character many times and expand the range of play of the card battle game.

Next, the processing procedure of the game control device 50 when a robot battle occurs in the card battle game of the present embodiment will be described with reference to the flowchart of FIG.

When the above-mentioned robot battle occurs, the communication terminal 20 displays a screen for constructing a deck (hereinafter, referred to as a deck construction screen). The deck is constructed from a plurality of card characters (for example, five card characters) and a robot character. Therefore, the user performs an operation of designating five card characters from the card characters owned by the user on the deck construction screen displayed on the communication terminal 20. The operation information indicating the operation performed by this user is transmitted from the communication terminal 20 to the game control device 50.

The deck construction unit 52 included in the game control device 50 selects five card characters in response to such user operations (operation information transmitted from the communication terminal 20).

The deck construction unit 52 constructs the deck of the user by using the five selected card characters and the robot character owned by the user (step S32). Hereinafter, the robot character included in the deck constructed by the deck construction unit 52 will be referred to as a deck robot character for convenience.

Next, the parameter setting unit 53 executes a battle parameter setting process for the constructed deck (deck robot character) (step S33). In this battle parameter setting process, robot battle parameters (hereinafter referred to as battle parameters) are set for the deck robot character. The parameters for this battle include the HP, attack power, speed, skill, attributes, and the like of the deck robot character. The details of the battle parameter setting process will be described later.

The game control unit 54 determines whether or not the user has instructed the start of the robot battle in response to the user's operation on the communication terminal 20 (step S34). The user can instruct the start of the robot battle by tapping the robot battle start button or the like displayed on the screen of the communication terminal 20.

If it is determined that the robot battle start instruction has not been given (NO in step S34), the process returns to step S31 described above and the process is repeated.

On the other hand, when it is determined that the robot battle start instruction has been given (YES in step S34), the game control unit 54 executes the robot battle effect image generation process described above (step S35). In this robot battle effect image generation process, the robot battle is controlled based on the battle parameters set for the deck robot character in step S33 and the parameters preset for the enemy robot character in the robot battle. Then, a robot battle effect image corresponding to the control is generated. The parameters preset for the enemy robot character include the HP, attack power, speed, skill, attributes, etc. of the enemy robot character, as in the battle parameters set for the deck robot character. included.

The game control unit 54 displays the generated robot battle effect image on the communication terminal 20 (step S36).

When the robot battle effect image is displayed in the card battle game, the communication terminal 20 automatically displays images showing the offense and defense between the deck robot character and the enemy robot character in sequence, and finally the result of the robot battle ( That is, an image showing the victory or defeat) is displayed. In addition, it is also possible to shorten the display time of the robot battle effect image according to the instruction of the user and display only the image showing the result of the robot battle.

Next, the processing procedure of the above-mentioned battle parameter setting process (process of step S33 shown in FIG. 8) will be described with reference to the flowchart of FIG. The battle parameter setting process is executed by the parameter setting unit 53 as described above.

In the battle parameter setting process, the parameter setting unit 53 uses parameter management information (robot parameter management) including parameters preset for the deck robot character (robot character included in the deck constructed by the deck construction unit 52). Information) is acquired (step S41). The robot parameter management information (parameters included in) includes HP, attack power, speed, and attributes as described above.

Next, the parameter setting unit 53 for each of the plurality of card characters (that is, the plurality of card characters selected when constructing the deck) included in the deck constructed by the deck construction unit 52 as described above. The parameter management information (card parameter management information) including the preset parameters is acquired (step S42). The card parameter management information (parameters included in) includes HP, attack power, speed, and skill as described above.

Although detailed description will be omitted, in order to identify the robot ID and the card character for identifying the robot character owned by the user, for example, in the storage unit 42 in association with the user ID for identifying the user. Information including the card ID and the like of the above is stored (managed), and in steps S41 and S42, the robot parameter management information and the card parameter management information can be acquired based on the robot ID and the card ID included in this information. it can.

The parameter setting unit 53 is set for the deck robot character based on the HP included in the robot parameter management information acquired in step S41 and the HP included in each of the card parameter management information acquired in step S42. The HP (parameter) included in the battle parameter is calculated (step S43).

In this case, the parameter setting unit 53 adds the HP (parameter value) included in the robot parameter management information and the HP (parameter value) included in each of the card parameter management information, thereby causing the robot parameter management information. The total value of the HP included in the HP and the HP included in each of the card parameter management information is calculated as the HP included in the battle parameter.

Although the total value of the HP included in the robot parameter management information and the HP included in each of the card parameter management information is calculated as the HP included in the battle parameters, for example, the card parameter management information A configuration may be used in which attribute correction is performed for the HP included in each. Specifically, although omitted in FIG. 3 described above, the card parameter management information includes the attribute of the card character identified by the card ID included in the card parameter management information, and the attribute of the card character is the deck. Depending on whether or not the attributes (attributes of the deck robot character) included in the robot parameter management information match, the HP included in the card parameter management information can be multiplied by the attribute correction value. In this case, the HP included in the battle parameters is calculated by "the sum of the HP + (HP * attribute correction value included in the card parameter management information) included in the robot parameter management information". The attribute correction value when the attribute of the card character matches the attribute of the deck robot character is a value larger than a predetermined value of 1, and the attribute correction value when the attribute of the card character does not match the attribute of the deck robot character. Is assumed to be 1. As a result, the user can increase the HP (value) included in the battle parameters by selecting a card character with the same attributes as the robot character (deck robot character) owned by the user when constructing the deck. Can be high.

Next, the parameter setting unit 53 sets the deck robot character based on the attack power included in the robot parameter management information acquired in step S41 and the attack power included in each of the card parameter management information acquired in step S42. The attack power (parameter) included in the battle parameters set for the battle is calculated (step S44).

In this case, the parameter setting unit 53 adds the attack power (parameter value) included in the robot parameter management information and the attack power (parameter value) included in each of the card parameter management information to obtain the robot parameter. The total value of the attack power included in the management information and the attack power included in each of the card parameter management information is calculated as the attack power included in the battle parameters.

In this section, the total value of the attack power included in the robot parameter management information and the attack power included in each of the card parameter management information is calculated as the attack power included in the battle parameters. Similar to the case of, for example, the configuration may be such that the attribute is corrected for the attack power included in each of the card parameter management information.
Specifically, the card parameter management information includes the attribute of the card character identified by the card ID included in the card parameter management information, and the attribute of the card character is included in the robot parameter management information (deck robot character). Depending on whether or not it matches the attribute), the attack power included in the card parameter management information can be multiplied by the attribute correction value. In this case, the attack power of the battle parameter is calculated by "the sum of the attack power included in the robot parameter management information + (attack power included in the card parameter management information * attribute correction value)". The attribute correction value when the attribute of the card character matches the attribute of the deck robot character is a value larger than a predetermined value of 1, and the attribute correction value when the attribute of the card character does not match the attribute of the deck robot character. Is assumed to be 1. As a result, the user can increase the attack power included in the battle parameters by selecting a card character with the same attributes as the robot character (deck robot character) owned by the user when constructing the deck. Can be done.

Further, the parameter setting unit 53 sets the deck robot character based on the speed included in the robot parameter management information acquired in step S41 and the speed included in each of the card parameter management information acquired in step S42. The speed (parameter) included in the battle parameter to be performed is calculated (step S45).

In this case, the parameter setting unit 53 adds the speed (parameter value) included in the robot parameter management information and the speed (parameter value) included in each of the card parameter management information, thereby causing the robot parameter management information. The total value of the speed included in and the speed included in each of the card parameter management information is calculated as the speed included in the battle parameter.

Although the total value of the speed included in the robot parameter management information and the speed included in each of the card parameter management information is calculated as the speed included in the battle parameters, the above-mentioned HP and attack power have been described here. Similar to the case of, for example, the configuration may be such that the attribute correction is performed for the speed included in each of the card parameter management information. Specifically, the card parameter management information includes the attribute of the card character identified by the card ID included in the card parameter management information, and the attribute of the card character is included in the robot parameter management information (deck robot character). Depending on whether or not it matches the attribute), the speed included in the card parameter management information can be multiplied by the attribute correction value. In this case, the speed included in the battle parameter is calculated by "the sum of the speed included in the robot parameter management information + (speed included in the card parameter management information * attribute correction value)".
The attribute correction value when the attribute of the card character matches the attribute of the deck robot character is a value larger than a predetermined value of 1, and the attribute correction value when the attribute of the card character does not match the attribute of the deck robot character. Is assumed to be 1. As a result, the user can increase the speed (value) included in the battle parameters by selecting a card character with the same attributes as the robot character (deck robot character) owned by the user when constructing the deck. Can be high.

Next, the parameter setting unit 53 identifies the skill included in the battle parameter set for the deck robot character based on each of the card parameter management information acquired in step S42 (step S46). In this case, the parameter setting unit 53 specifies all the skills included in each of the card parameter management information as the skills included in the battle parameters.

The parameter setting unit 53 sets the battle parameters including the HP calculated in step S43, the attack power calculated in step S44, the speed calculated in step S45, and the skill specified in step S46 as the deck robot character. (Step S47).

In addition, as described above, in the case of performing attribute correction for HP, attack power and speed included in each of the card parameter management information, for example, the attributes of all the card characters match the attributes of the deck robot character. In special cases, it is possible to further improve the battle parameters (HP, attack power and speed) set for the deck robot character, and for the combination of the deck robot character and the card character. It is also possible to configure it so that special skills (for example, combo skills) are given accordingly.

In the robot battle in the present embodiment, the above-mentioned robot battle effect image generation process is executed based on the battle parameters set for the deck robot character and the parameters set for the enemy robot character in this way. To.

Next, the processing procedure of the robot battle effect image generation process (process of step S35 shown in FIG. 8) will be described with reference to the flowcharts of FIGS. 10 and 11. In this robot battle effect image generation process, the robot battle between the deck robot character and the enemy robot character is controlled, and an image for displaying the effect and result of the robot battle is generated. The robot battle effect image generation process is executed by the game control unit 54 as described above.

In the robot battle effect image generation process, the game control unit 54 determines the first attack and the second attack in the robot battle. In this case, the game control unit 54 is set for the speed and the enemy robot character included in the battle parameters set for the deck robot character (hereinafter, simply referred to as the battle parameters for the deck robot character). The speed included in the parameters (hereinafter simply referred to as the parameters of the enemy robot character) is compared, and the one with the higher speed (parameter value) is determined as the first attack, and the one with the lower speed is determined as the second attack. Here, it is assumed that the deck robot character is determined as the first attack and the enemy robot character is determined as the second attack.

Here, the skills included in the battle parameters of the deck robot character and the parameters of the enemy robot character include attack skills, defense skills, and pre-battle skills.

The attack skill is activated when a robot character (deck robot character or enemy robot character) having the attack skill attacks, and within a predetermined period after the attack skill is activated, for example, its own attack power (parameter). It is a skill that produces an effect that raises the value). The defense skill is activated when the robot character (deck robot character or enemy robot character) having the defense skill is defending (that is, when the opponent is attacked), and a predetermined period after the defense skill is activated. Within, for example, a skill that produces an effect that reduces the attack power (parameter value) of the opponent in a robot battle. Pre-combat skills, like attack and defense skills, are skills that have the effect of increasing one's own attack power or decreasing the opponent's attack power, but unlike attack and defense skills, robot battles It is activated before the start of offense and defense (battle) in, and continues to produce the effect during the robot battle. It is assumed that the activation timing and activation probability are set in advance for each of these skills.

In this case, the game control unit 54 determines the first attack based on the activation probability set in the pre-battle skill (hereinafter referred to as the first pre-battle skill) among the skills included in the battle parameters of the deck robot character. It is determined whether or not to activate the pre-combat skill of (step S51). If there are multiple pre-combat skills for the first attack, it is determined whether or not to activate each pre-combat skill for the first attack.

When it is determined to activate the pre-combat skill of the first attack (YES in step S51), the game control unit 54 generates an image (image of activating the pre-combat skill of the first attack) showing the activation of the pre-combat skill of the first attack (step). S52). Further, the game control unit 54 reflects the effect generated by the pre-battle skill of the first attack determined to be activated in the battle parameter of the deck robot character or the parameter of the enemy robot character.

On the other hand, if it is determined that the pre-combat skill of the first attack is not activated (NO in step S51), the process of step S52 is not executed.

Next, the game control unit 54 determines the second attack based on the activation probability set in the pre-battle skill (hereinafter referred to as the second pre-battle skill) among the skills included in the parameters of the enemy robot character. It is determined whether or not to activate the pre-combat skill of (step S52). If there are multiple pre-combat skills for the second attack, it is determined whether or not to activate each pre-combat skill for the second attack.

When it is determined to activate the pre-combat skill of the second attack (YES in step S53), the game control unit 54 generates an image (image of activating the pre-combat skill of the second attack) showing the activation of the pre-combat skill of the second attack. (Step S54). Further, the game control unit 54 reflects the effect generated by the pre-battle skill of the second attack determined to be activated in the battle parameter of the deck robot character or the parameter of the enemy robot character.

On the other hand, if it is determined that the pre-combat skill of the second attack is not activated (NO in step S53), the process of step S54 is not executed.

Next, the game control unit 54 attacks the first attack based on the activation probability set in the attack skill (hereinafter referred to as the first attack skill) among the skills included in the battle parameters of the deck robot character. It is determined whether or not to activate the skill (step S55).
If there are multiple attack skills for the first attack, it is determined whether or not to activate each attack skill for the first attack.

When it is determined that the attack skill of the first attack is activated (YES in step S55), the game control unit 54 generates an image (image of activating the attack skill of the first attack) showing the activation of the attack skill of the first attack (step S56). Further, the game control unit 54 reflects the effect generated by the first attack skill determined to be activated in the battle parameter (included in the attack power) of the deck robot character.

On the other hand, if it is determined that the attack skill of the first attack is not activated (NO in step S55), the process of step S56 is not executed.

The game control unit 54 generates an image (first attack effect image) showing the attack effect of the deck robot character (step S57).

Next, the game control unit 54 defends the second attack based on the activation probability set in the defense skill (hereinafter referred to as the second attack defense skill) among the skills included in the parameters of the enemy robot character. It is determined whether or not to activate the skill (step S58). If there are multiple defense skills for the second attack, it is determined whether or not to activate each defense skill for the second attack.

When it is determined to activate the defense skill of the second attack (YES in step S58), the game control unit 54 generates an image (image of activating the defense skill of the second attack) showing the activation of the defense skill of the second attack (step). S59). Further, the game control unit 54 reflects the effect generated by the defense skill of the second attack determined to be activated in the battle parameter (included in the attack power) of the deck robot character.

On the other hand, if it is determined that the defense skill of the second attack is not activated (NO in step S58), the process of step S59 is not executed.

The game control unit 54 generates an image (damage effect image of the second attack) showing the effect of the damage received by the enemy robot character (step S60). In the process of step S60, an image indicating that the attack of the deck robot character has been avoided may be generated based on the probability according to the speed included in the parameter of the enemy robot character.

Here, the game control unit 54 calculates the damage (value) given to the enemy robot character based on the attack power included in the battle parameters of the deck robot character.
In this case, for example, the damage given to the enemy robot character may be appropriately changed according to the attributes included in the battle parameters of the deck robot character and the attributes included in the parameters of the enemy robot character.

The damage calculated by the game control unit 54 is subtracted from the HP (parameter value) included in the parameters of the enemy robot character. When an image showing that the attack of the deck robot character is avoided is generated in step S60 as described above, the damage given to the enemy robot character is set to 0.

Next, the game control unit 54 determines whether or not the HP from which the damage has been subtracted (hereinafter, simply referred to as the remaining HP of the enemy robot character) is 0 or less (step S61).

When it is determined that the remaining HP of the enemy robot character is not 0 or less (NO in step S61), the remaining HP of the enemy robot character is held in the game control unit 54.

Next, the game control unit 54 attacks the second attack based on the activation probability set in the attack skill (hereinafter referred to as the second attack skill) among the skills included in the parameters of the enemy robot character. It is determined whether or not to activate the skill (step S62). If there are multiple attack skills for the second attack, it is determined whether or not to activate each attack skill for the second attack.

When it is determined to activate the attack skill of the second attack (YES in step S62), the game control unit 54 generates an image (image of activating the attack skill of the second attack) showing the activation of the attack skill of the second attack (step). S63). Further, the game control unit 54 reflects the effect generated by the attack skill of the second attack determined to be activated in the parameter (attack power included in) of the enemy robot character.

On the other hand, if it is determined that the attack skill of the second attack is not activated (NO in step S62), the process of step S63 is not executed.

The game control unit 54 generates an image (attack effect effect image of the second attack) showing the attack effect of the enemy robot character (step S64).

Next, the game control unit 54 defends the first attack based on the activation probability set in the defense skill (hereinafter referred to as the first defense skill) among the skills included in the battle parameters of the deck robot character. It is determined whether or not to activate the skill (step S65).
If there are multiple first-attack defense skills, it is determined whether or not to activate each first-attack defense skill.

When it is determined to activate the first defense skill (YES in step S65), the game control unit 54 generates an image (image of activating the first defense skill) showing the activation of the first defense skill (step S66). Further, the game control unit 54 reflects the effect generated by the first defense skill determined to be activated in the parameter (attack power included in) of the enemy robot character.

On the other hand, if it is determined that the first defense skill is not activated (NO in step S65), the process of step S66 is not executed.

The game control unit 54 generates an image (first-attack damage effect image) showing the effect of the damage received by the deck robot character (step S67). In the process of step S67, an image showing that the attack of the enemy robot character has been avoided may be generated based on the probability according to the speed included in the parameter of the deck robot character.

Here, the game control unit 54 calculates the damage (value) given to the deck robot character based on the attack power included in the parameters of the enemy robot character. In this case, as described above, the damage given to the deck robot character may be appropriately changed according to, for example, the attributes included in the battle parameters of the deck robot character and the attributes included in the parameters of the enemy robot character.

The damage calculated by the game control unit 54 is subtracted from the HP (parameter value) included in the battle parameters of the deck robot character. When an image showing that the attack of the enemy robot character is avoided is generated in step S67 as described above, the damage given to the deck robot character is set to 0.

Next, the game control unit 54 determines whether or not the HP from which the damage has been subtracted (hereinafter, simply referred to as the remaining HP of the deck robot character) is 0 or less (step S68).

When it is determined that the remaining HP of the deck robot character is not 0 or less (NO in step S68), the remaining HP of the deck robot character is held in the game control unit 54, and the process returns to step S55 described above and the process is repeated. Is done. The damage calculated by the game control unit 54 in the subsequent processing is subtracted from the remaining HP of the deck robot character or the enemy robot character held in the game control unit 54 as described above. That is, in the robot battle, the above-mentioned processes after step S55 are repeated until either the remaining HP of the deck robot character or the remaining HP of the enemy robot character becomes 0 or less.

On the other hand, if it is determined in step S61 that the remaining HP of the enemy robot character is 0 or less, or if it is determined in step S68 that the remaining HP of the deck robot character is 0 or less, the game control unit 54 generates an image (win / loss image) showing the result (win / loss) of the robot battle (step S69). If it is determined that the remaining HP of the enemy robot character is 0 or less, an image indicating that the deck robot character has won is generated, and if it is determined that the remaining HP of the deck robot character is 0 or less. An image showing that the deck robot character has been defeated is generated in.

Next, the game control unit 54 generates each image (first pre-combat skill activation image, second pre-combat skill activation image, first attack skill activation image, first attack production image, rear) generated in the above process. Attack defense skill activation image, second attack damage production image, second attack skill activation image, second attack attack production image, first attack defense skill activation image, first attack damage production image and victory / defeat image) in chronological order By combining them so as to transition, a robot battle effect image for displaying the effect and result of the robot battle is generated (step S70).

By displaying the robot battle effect image generated in this way on the communication terminal 20, the user can appreciate each effect of the robot battle and confirm the result of the robot battle.

As described above, in the card battle game (main cycle) of the present embodiment, various cards (characters and items) are obtained by clearing chapters (quests), etc., and the obtained cards are used to further increase the difficulty level. By clearing high chapters, you will advance the story.

On the other hand, in the card battle game of the present embodiment, a mechanism (guild event) for cooperatively playing in a group (guild) composed of a plurality of users described above, in addition to the main cycle described in FIG. 5 described above. There are subcycles that include. This guild event shall occur (held) on a regular basis.

The guild event will be described below. The purpose of the guild event is to collect a plurality of constituent items that compose one item that appears in the card battle game in cooperation with a plurality of users (guild members) that compose the guild. If a guild meets a predetermined condition in this guild event, a plurality of users constituting the guild can obtain various benefits. The benefits that can be obtained at the guild event include, for example, various card characters and items.

Here, in the storage unit 42 included in the game control device 50, as information related to the guild event, guild management information (group management information), information about the guild event (hereinafter referred to as component item information), and a card battle game Information about card characters, items, etc. owned by the user who plays the game and information about the user are stored. In addition, the information about the card characters and items owned by the user who plays the card battle game includes the information about the card characters and items owned by the user and the information about the constituent items obtained by the user at the guild event (hereinafter, obtained). Configuration item information and notation) etc. are included. In addition, the information about the user includes level management information for managing the level of the user in the card battle game.

FIG. 12 shows an example of the data structure of the guild management information stored in the storage unit 42. The guild management information is information indicating a guild (a group composed of a plurality of users who play the game) configured in the card battle game.

As shown in FIG. 12, the guild management information includes a user ID and a guild ID in association with each other. The user ID is an identifier for identifying a user who plays a card battle game. The guild ID is an identifier for identifying the guild (group) to which the user identified by the associated user ID belongs.

In the example shown in FIG. 12, the guild management information includes the user ID "user 1" and the guild ID "guild 1" in association with each other. Further, the guild management information includes the user ID "user 2" and the guild ID "guild 1" in association with each other. According to this, it is shown that the user identified by the user IDs "user 1" and "user 2" belongs to the guild identified by the guild ID "guild 1".

Here, for convenience, only the user identified by the user IDs "user 1" and "user 2" has been described, but the storage unit 42 also manages the guild for other users who play the card battle game. Information is stored.

In the card battle game of the present embodiment, it is assumed that all users who play the card battle game belong to (join) any guild. Specifically, after the tutorial (explanation of how to play, etc.) performed when playing the card battle game for the first time, joining an existing guild is prompted, and the user can join the specified guild. .. It is also possible for users to create new guilds themselves and recruit other users. Furthermore, it is possible to configure the structure so that the approval of the creator (leader) of the guild is required as a condition for joining the guild.

FIG. 13 shows an example of the data structure of the component item information stored in the storage unit 42.
The component item information is information indicating the component items collected in the guild event. The guild event in the present embodiment is such that a privilege can be obtained by collecting a plurality of pieces (constituent items) constituting one jewel in cooperation with each other in the guild. In addition, it is assumed that multiple types of jewels to be collected at the guild event are prepared.

In this case, as shown in FIG. 13, the component item information includes the type of jewel, the piece ID, and the appearance probability in association with each other. The piece ID is an identifier for identifying each of the plurality of pieces that make up each jewel. The appearance probability indicates the probability that a piece identified by the associated piece ID will appear in the card battle game.

In the example shown in FIG. 13, the component item information includes the jewel type “jewel A”, the piece IDs “A1 to A6”, and the appearance probability “probability 1” in association with each other. According to this, the jewel A is composed of six pieces (hereinafter referred to as pieces A1 to A6) identified by the pieces ID "A1 to A6", and the pieces A1 to A6 have a "probability 1" in the card battle game. It is shown to appear in. It should be noted that the jewel A is targeted at, for example, a low-level user (target), and the pieces A1 to A6 are all common, and the probability that they are likely to appear in the low-level user (when playing) is set. Here, the low-level user is a user with a low level in the card battle game. The range of low-level users can be changed as appropriate, but it is assumed that the range of users is, for example, about 1 to 20 levels. Further, the pieces A1 to A6 may appear in users other than the low-level users with a low appearance probability, or may not appear in users other than the low-level users.

In addition, the constituent item information includes the jewel type "jewel B", the piece IDs "B1 to B6", and the appearance probability "probability 2" in association with each other. According to this, the jewel B is composed of six pieces (hereinafter referred to as pieces B1 to B6) identified by the pieces ID "B1 to B6", and the pieces B1 to B6 have a "probability 2" in the card battle game. It is shown to appear in. Note that the jewel B is targeted at, for example, a middle-level user (target), and the pieces B1 to B6 are all common, and a probability is set so that they are likely to appear in the middle-level user (when playing). Here, the medium-level user is a user whose level in the card battle game is higher than the above-mentioned low-level user and lower than the high-level user described later. The range of medium-level users can be changed as appropriate, but it is assumed that the range of users is, for example, about 21 to 50. Further, the pieces B1 to B6 may be made to appear in users other than the middle level users with a low appearance probability, or may not appear in the users other than the middle level users.

In addition, the constituent item information includes the jewel type "jewel C", the piece IDs "C1 to C6", and the appearance probability "probability 3" in association with each other. According to this, the jewel C is composed of six pieces (hereinafter referred to as pieces C1 to C6) identified by the pieces ID "C1 to C6", and the pieces C1 to C6 have a "probability 3" in the card battle game. It is shown to appear in. It should be noted that the jewel C is targeted at, for example, a high-level user (target), and the pieces C1 to C6 are all common, and the probability that they are likely to appear in the high-level user (when playing) is set. Here, the high-level user is a high-level user in the card battle game. The range of high-level users can be changed as appropriate, but for example, it is assumed that the user has a level of about 51 or higher. Further, the pieces C1 to C6 may appear to users other than the high-level users with a low appearance probability, or may not appear to users other than the high-level users.

Further, the component item information corresponds to the jewel type "jewel D", the fragment ID "D1 to D6", and the appearance probability "D1, D2: probability 1, D3, D4: probability 2, D5, D6: probability 3". It is included. According to this, the jewel D is composed of six pieces (hereinafter referred to as pieces D1 to D6) identified by the pieces ID "D1 to D6", and the pieces D1 and D2 have a "probability 1", the pieces D3 and It is shown that D4 appears with "probability 2" and pieces D5 and D6 appear with "probability 3". The jewel D targets (targets) all users (that is, the above-mentioned low-level users, medium-level users, and high-level users). Specifically, the fragments D1 and D2 are set with a probability that they are likely to appear in low-level users. Fragments D3 and D4 are set with probabilities that are likely to appear in middle-level users.
Fragments D5 and D6 are set with probabilities that are likely to appear to high-level users. Thus, in the case of jewel D, unlike other jewels, each of the plurality of pieces (pieces D1 to D6) constituting the jewel D is given to users at different levels. It is set.

FIG. 14 shows an example of the data structure of the acquisition configuration item information stored in the storage unit 42. The acquisition configuration item information is information indicating the configuration item acquired (that is, given to the user) by the user at the guild event.

As shown in FIG. 14, the acquisition configuration item information includes the user ID and the fragment ID in association with each other. The user ID is an identifier for identifying a user who plays a card battle game. The fragment ID is an identifier for identifying the fragment (constituent item) obtained (assigned to the user) by the user identified by the associated user ID.

In the example shown in FIG. 14, the acquisition configuration item information includes the user ID “user 1” and the fragment ID “D1” in association with each other. According to this, it is shown that the fragment identified by the fragment ID "D1" is given to the user identified by the user ID "user 1".

Further, the acquisition configuration item information includes the user ID "user 2" and the fragment ID "D4" in association with each other. According to this, it is shown that the piece identified by the piece ID "D4" is given to the user identified by the user ID "user 2".

Here, for the sake of convenience, only the user identified by the user IDs "user 1" and "user 2" has been described, but the same applies to other users to which the storage unit 42 is given the fragment which is a component item. Obtained configuration item information is stored in.

FIG. 15 shows an example of the data structure of the level management information stored in the storage unit 42. The level management information is information indicating the level of the user who plays the card battle game.

As shown in FIG. 15, the level management information includes the user ID and the level information in association with each other. The user ID is an identifier for identifying a user who plays a card battle game. The level information indicates the level in the card battle game of the user identified by the associated user ID.

In the example shown in FIG. 15, the level management information includes the user ID “user 1” and the level information “5” in association with each other. According to this, it is shown that the level of the user identified by the user ID "user 1" is 5.

Further, the level management information includes the user ID "user 2" and the level information "25" in association with each other. According to this, it is shown that the level of the user identified by the user ID "user 2" is 25.

Here, for convenience, only the users identified by the user IDs "user 1" and "user 2" have been described, but the storage unit 42 also manages the levels of other users who play the card battle game. Information is stored.

The level of the user in the card battle game is improved according to the progress of the card battle game, the victory in the battle, and the like. When the level of the user in the card battle game is improved in this way, the level management information (the level information included in the storage unit 42) stored in the storage unit 42 is updated each time.

Next, the operation of the game control device 50 when a guild event is generated in the present embodiment will be described. In this case, the game control device 50 executes the guild event generation process and the guild event management process.

First, the processing procedure of the guild event generation processing executed by the game control device 50 according to the present embodiment will be described with reference to the flowchart of FIG. This guild event generation process is a process for generating a guild event and granting a component item in the guild event to a user (player).

First, the game control unit 54 included in the game control device 50 generates a guild event for granting a constituent item (step S81). This guild event occurs, for example, on a regular basis. Specifically, the guild event occurs, for example, at 7:00 in the morning section, 12:00 in the day section, and 22:00 in the evening section. Further, the period during which the guild event is occurring is notified to the user playing the card battle game via the communication terminal 20.
Hereinafter, the user who is playing the card battle game is referred to as a target user.

When a guild event occurs, the game control unit 54 sets a component item (fragment that constitutes each jewel) according to the play content of the card battle game of the target user (that is, the operation of the target user on the communication terminal 20). It is determined whether or not to make it appear (step S82). At this time, the game control unit 54 executes the determination process based on the appearance probability included in the configuration item information stored in the storage unit 42 and the level of the target user indicated by the level management information.

The constituent items shall appear in various scenes while playing the card battle game. Specifically, the constituent items appear during a quest in a card battle game or when winning various enemy characters (quest boss or enemy robot character).

That is, when the play status of the card battle game of the target user is a situation in which the constituent items can be made to appear, the game control unit 54 causes the constituent items to appear based on the appearance probability according to the level of the target user described above. Determine whether or not to allow.

When it is determined that the constituent item appears (YES in step S82), the game control unit 54 generates an effect image (configured item appearance image) that causes the constituent item to appear, and the communication terminal 20 used by the target user. The image of the appearance of the component item is displayed in.

When the configuration item appearance image is displayed on the communication terminal 20 in this way, the game control unit 54 grants the configuration item to the target user (step S83).

As described above, in the configuration item information, since the user (level) to which the configuration item is likely to be assigned is set for each configuration item, each configuration item is assigned to users of different ranges. Will be.

In this case, the game control unit 54 includes the acquisition configuration item information including the user ID for identifying the target user and the fragment ID for identifying the configuration item (fragment) given to the target user in association with each other. Generate. The game control unit 54 stores the generated acquisition configuration item information in the storage unit 42 (step S84).

Here, the game control unit 54 determines whether or not a predetermined period (predetermined period) has elapsed after the guild event was generated in step S81 described above (step S85). As the predetermined period, for example, one hour or the like is set.

When it is determined that the predetermined period has elapsed (YES in step S85), the guild event ends (step S86).

On the other hand, if it is determined that the predetermined period has not elapsed (NO in step S85), the guild event is continued, and the process returns to step S82 described above and the process is repeated. That is, in the guild event in the present embodiment, a plurality of component items can be collected during the period during which the guild event occurs (that is, during the period from the occurrence of the guild event to the end). It is possible.

If it is determined in step S82 that the constituent item is not to appear, the constituent item is not given to the target user, and the process of step S85 is executed.

In step S82, when it is determined that, for example, a plurality of constituent items appear based on the appearance probability, an effect image for causing one of the plurality of constituent items to appear is displayed on the communication terminal 20. Alternatively, the effect image that causes a plurality of constituent items to appear may be displayed on the communication terminal 20. When an effect image that causes a plurality of configuration items to appear is displayed on the communication terminal 20, all of the plurality of configuration items may be given to the target user, or the target user may be selected from the plurality of configuration items. Only one of the above may be given.

Next, the processing procedure of the guild event management process executed by the game control device 50 according to the present embodiment will be described with reference to the flowchart of FIG. This guild event management process is a process for managing the configuration items given to the user during the period in which the guild event is occurring, and giving the privilege in the guild event to the user.

First, the game control unit 54 included in the game control device 50 is indicated by guild management information (group management information) stored in the storage unit 42 based on the acquisition configuration item information stored in the storage unit 42. The configuration items given to each of the plurality of users (guild members) constituting the guild (group) are specified (step S91).

In this case, the game control unit 54 acquires the guild management information (group management information) stored in the storage unit 42.

The game control unit 54 identifies all user IDs associated with the same guild ID in the acquired guild management information. The user identified by the user ID specified here is a user who constitutes the same guild. Hereinafter, a guild composed of users identified by the user ID specified here will be referred to as a target guild.

The game control unit 54 acquires the acquisition configuration item information including the specified user ID from the storage unit 42.

The game control unit 54 identifies the pieces identified by the pieces ID included in the acquired acquisition configuration item information as the configuration items given to each of the plurality of users constituting the target guild.

Hereinafter, the configuration item specified by the game control unit 54 in step S91 will be referred to as an acquisition configuration item.

Next, the game control unit 54 has given all of the configuration items to the target guild (a plurality of users constituting the guild) based on the acquisition configuration item and the configuration item information stored in the storage unit 42. Whether or not it is determined (step S92).

The processing of this step S92 will be specifically described with reference to FIG. 13 described above. Among the obtained constituent items, for example, the pieces identified by each of the pieces IDs "A1 to A6" (six pieces constituting the jewel A). If all of the above are included, it is determined that all of the constituent items have been granted. In addition, if all of the pieces (six pieces that make up the jewel B) identified by each of the piece IDs "B1 to B6" are included in the obtained component items, all of the component items are given. It is determined that it has been done. Similarly, if the obtained component items include, for example, all of the pieces (six pieces that make up the jewel C) identified by each of the piece IDs "C1 to C6", all of the component items are included. It is determined that it has been granted. In addition, if all of the pieces (six pieces that make up the jewel D) identified by each of the piece IDs "D1 to D6" are included in the obtained component items, all of the component items are given. It is determined that it has been done.

That is, in step S92, if all of the pieces (that is, one set of six pieces) that make up at least one (kind) gem are present in the obtained constituent items, all of the constituent items are granted. It is determined that it has been done.

When it is determined that all of the constituent items have been granted (YES in step S92), the game control unit 54 gives a privilege according to the all-given constituent items (that is, the type of jewel that has collected all the pieces). , Granted to a plurality of users (guild members) constituting the target guild (step S93). It should be noted that a plurality of sets of constituent items are given (for example, all the pieces identified by the pieces ID "A1 to A6" and all the pieces identified by the pieces ID "D1 to D6" are given. ) In that case, a privilege is given for each (type of) the constituent item.

Next, it is determined whether or not the guild event has ended (step S94). If it is determined that the guild event has not ended (NO in step S94), the process returns to step S91 described above and the process is repeated.

On the other hand, when it is determined that the guild event has ended (YES in step S94), the component items given to the user in the guild event are invalidated (step S95). In this case, the game control unit 54 deletes the acquisition configuration item information stored in the storage unit 42.

Here, when the target guild collects all of the constituent items, it is possible to give ranking points to the target guild in addition to the above-mentioned benefits. The ranking points given to the target guild in this way are totaled for each predetermined period, and various benefits are given to a plurality of users constituting the target guild according to the total value of the ranking points. It can be configured. Ranking points shall also be awarded by robot battles, etc. other than during guild events. As a result, even during the period when the guild event is not occurring, it can be expected that each of the plurality of users constituting the target guild actively plays the card battle game in order to obtain ranking points. The ranking points may be managed in the storage unit 42 or the like for each guild, for example.

The guild event management process described with reference to FIG. 17 is executed for all guilds existing (created) in the card battle game.

As described above, in the present embodiment, each of the plurality of users constituting the guild (group) is given a configuration item according to the operation of the user with respect to the communication terminal 20 used by the user. The acquisition configuration item information indicating the configuration items given to each of the plurality of users is stored in the storage unit 42, and is indicated by the guild management information (group management information) based on the acquisition configuration item information stored in the storage unit 42. It is determined whether all of the plurality of configuration items (a set of configuration items) have been granted to a plurality of users who constitute the guild, and if it is determined that all of the plurality of configuration items have been granted, the guild It is possible to provide a mechanism for a plurality of users to cooperate and play in a social game by a configuration in which a privilege is given to a plurality of users constituting the above.

Further, in the present embodiment, the guild is configured only by high-level users or low-level users, for example, by assigning each of the plurality of configuration items indicated by the configuration item information to users of different ranges. Instead of doing so, it is possible to promote the formation of a guild regardless of the level, etc., and it is possible to provide a mechanism that gives all users the opportunity to obtain benefits.

Further, in the present embodiment, a privilege is given when all of the plurality of constituent items are granted within the period in which the guild event is generated, and the acquired configuration item information is deleted when the period has elapsed. Therefore, if you do not collect all the constituent items during the period when the guild event is occurring, you will not be able to get the benefits. , It is possible to promote cooperative play by more than one user. In the present embodiment, it is also possible to configure the communication terminal 20 to display a screen for explaining the characteristics of the guild (main play time zones of users constituting the guild, etc.). With such a configuration, the user can join a more appropriate guild, so that more benefits can be obtained in the guild, and continuous play of the card battle game can be expected.

In the card battle game of the present embodiment, it has been described that the main cycle and the sub cycle including the guild event described in FIG. 5 described above are provided. However, in the sub cycle, for example, one person A mechanism for performing a robot battle with another user (hereinafter referred to as PvP) and the like may be further included. Also in this PvP, the above-mentioned ranking points and various benefits can be given according to the result. Further, depending on the result of this PvP, it is also possible to configure the configuration so that the configuration items in the present embodiment can be acquired from other users.

Also, for example, in a normal quest or a dedicated quest, a raid boss event that borrows another user's leader card character and fights with an enemy character called a raid boss, or an enemy called a raid robot character (raid NPC) in cooperation with a guild, for example. It is also possible to have a configuration in which a raid NPC event or the like in which a robot battle (raid robot battle) is performed with a robot character is randomly generated.

According to the raid boss event, for example, by making it easier to borrow the leader card of a user registered as a friend, it is possible to motivate the user to make more friends in the card battle game and promote continuous play. In addition, by generating a raid boss event, the strength (that is, parameters) of another user's card character (leader card character) can be recognized, and the existence of a new card character and its parameters can be known. .. In addition, a user who lent a leader card character to another user by a raid boss event is given a privilege such as points used for acquiring a card character, an item, or the like in a card battle game, for example.

In addition, in the case of a raid NPC event, each user who constitutes a guild individually conducts a robot battle using his or her own deck robot character, and according to the result of the robot battle, the above ranking points are given to the guild. It is also possible to give a configuration. In addition, if a raid robot battle is defeated in a raid NPC event, it is possible to make a configuration so that a rescue request can be made to another guild.

Further, although the card battle game in the present embodiment has been described as being realized by a web application, it is realized by a native application that is downloaded to the communication terminal (terminal device) 20 and installed and used in the communication terminal 20. It doesn't matter.

The invention of the present application is not limited to the above-described embodiment as it is, and at the implementation stage, the components can be modified and embodied within a range that does not deviate from the gist thereof. In addition, various inventions can be formed by an appropriate combination of the plurality of components disclosed in the above-described embodiment. For example, some components may be removed from all the components shown in the embodiments.

10 Computer 20 Communication terminal 30 Network 40 External storage device 41 Program 42 Storage unit 50 Game control unit 51 Card management unit 52 Deck construction unit 53 Parameter setting unit 54 Game control unit

Claims (8)

A terminal device that communicates with a server
Control the progress of the game based on the operations of users belonging to a specific group during the progressable period of a predetermined event.
In response to the user's operation, the user is given the component based on the level of the user and the level corresponding to the component that is invalidated after the runnable period of the predetermined event has expired. it displays the image showing the that,
Wherein in all the components assigned to each user belonging to a specific group, when it is determined by the server that a particular kind of components are included all Ru obtain benefits, control unit A terminal device characterized by having. The terminal device according to claim 1, wherein the component given to the user is given according to the play content of the user's battle game. The terminal device according to claim 2, wherein the component given to the user is given during a quest in the battle game or when a battle with an enemy character in the battle game is won. A server that can communicate with terminal equipment
During the progressable period of a predetermined event, the progress of the game is controlled based on the information transmitted from the terminal device regarding the operation of the user belonging to a specific group.
Based on the level of the user and the level corresponding to the component according to the information regarding the operation of the user, it is determined whether or not the component is given to the user.
When all the components of a specific type are included in all the components given to each user belonging to the specific group, a privilege is given to each user belonging to the specific group. ,
A computer having a control unit that invalidates information indicating the components given to the user after the progressable period of the predetermined event has expired. It is a control method of the terminal device that communicates with the server.
In progress period of the predetermined event, and that on the basis of the operation of the users belonging to a specific group, controls the progress of the game,
In response to the user's operation, the user is given the component based on the level of the user and the level corresponding to the component that is invalidated after the runnable period of the predetermined event has expired. and displaying an image indicating that that,
And that in all of the components that are assigned to each user belonging to the specific group, when it is determined by the server that a particular kind of components are included all the Ru resulting benefits,
A control method comprising. It is a control method in a server that can communicate with a terminal device.
In progress period of the predetermined event, and that the terminal device is transmitted from, based on the information about the operation of the users belonging to a specific group, controls the progress of the game,
And that in response to information about the operation of the user, based on the level corresponding to the level as a component of the user, the component to determine whether applied to the user,
When all the components of a specific type are included in all the components given to each user belonging to the specific group, a privilege is given to each user belonging to the specific group. That and
And the information indicating the component assigned to the user, disabling after traveling period of the predetermined event is completed,
A control method comprising. A control program for a terminal device that communicates with a server.
In progress period of the predetermined event, and that on the basis of the operation of the users belonging to a specific group, controls the progress of the game,
In response to the user's operation, the user is given the component based on the level of the user and the level corresponding to the component that is invalidated after the runnable period of the predetermined event has expired. and displaying an image indicating that that,
And that in all of the components that are assigned to each user belonging to the specific group, when it is determined by the server that a particular kind of components are included all the Ru resulting benefits,
A control program for executing. For servers that can communicate with terminal equipment
In progress period of the predetermined event, and that the terminal device is transmitted from, based on the information about the operation of the users belonging to a specific group, controls the progress of the game,
And that in response to information about the operation of the user, based on the level corresponding to the level as a component of the user, the component to determine whether applied to the user,
When all the components of a specific type are included in all the components given to each user belonging to the specific group, a privilege is given to each user belonging to the specific group. That and
And the information indicating the component assigned to the user, disabling after traveling period of the predetermined event is completed,
A control program for executing.

Images