JP2023123697A - Game control method, game control device and program - Google Patents

Abstract

To provide a specification in which plural users cooperate in a game and play.SOLUTION: A game control part 54 applies to each of plural users, a constitution item which constitutes a single item. The game control part 54 stores acquisition constitution item information which indicates the constitution item applied to each of the plural users in a storage part 42. The game control part 54 determines whether or not, all plural constitution items required for constituting the single item, are applied to the plural users forming a group, based on the acquisition constitution item information stored in the storage part 42. The storage part 42 also stores level management information indicating a level of each of the plural users. The game control part 54 determines whether or not, each of the plural constitution items is applied to each of the plural users, based on the level management information. A group to which each of the plural users belongs, can be designated by each user.SELECTED DRAWING: Figure 2

Description

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

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

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

Native applications can be used on smartphones such as iPhone (registered trademark) terminals and A
It is an application that depends on the OS of a communication terminal such as an ndroid (registered trademark) terminal. For example, the server device distributes a native application such as an iPhone application loaded with Objective-C or an Android application loaded with Java (registered trademark) from the platform to each communication terminal.

In addition, the native application is a programming language "Objective-C" corresponding to the iPhone terminal and a programming language corresponding to the Android terminal "
It is necessary to develop in two types, "Java". For this reason, native applications need to be published through an official marketplace after going through a coding process using a language specific to the platform of the communication terminal.

Web applications, on the other hand, are HTML5 (Hype
r Text Markup Language 5), Javascript (registered trademark)
, CSS3 (Cascading Style Sheets 3), etc., and cross-development is possible. Also, the web application does not depend on the OS of the terminal.

By the way, some of the social games described above can form a group called a guild with a plurality of users (players) who play the social game. In such social games, a plurality of users (guild members) forming the same guild can share information or communicate with each other.

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

JP-A-11-244533

In a social game in which a guild cooperates and battles against enemy characters, it is possible to obtain benefits that cannot be obtained by a single user by forming the guild. is beneficial to users.

However, since the purpose of the guild in such a case is to win the battle, it tends to be composed of high-level social game users (advanced players). Also, in many cases, the number of guild members is limited.

Therefore, a user with a low level (beginner) can form a guild only with users of the same level as the user, and as a result, there is a possibility that the user will not be able to obtain the benefits that the user desires. There is Such a situation causes a low-level user's motivation to play the game to decrease.

In other words, in social games, for example, there is a need for a new mechanism that allows a plurality of users (guilds) to play cooperatively regardless of their level.

SUMMARY OF THE INVENTION Accordingly, 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 cooperative play by a plurality of users.

According to one aspect of the present invention, a group management system that is communicably connected to a plurality of communication terminals used by each of a plurality of game-playing users and indicates a group composed of a plurality of game-playing users. A game control method executed by a game control device having storage means for storing information and configuration item information indicating a plurality of configuration items that configure one item is provided. This game control method includes the steps of giving a configuration item to each of a plurality of users, storing acquired configuration item information indicating the configuration item given to each of the plurality of users in a storage means, and storing means. , based on the obtained configuration item information stored in the the storage means further stores level management information indicating the level of each of the plurality of users; It is characterized in that it is possible for the user to determine whether or not each of the plurality of constituent items indicated by the item information is given to each of the plurality of users, and to specify the group to which each of the plurality of users belongs.

INDUSTRIAL APPLICABILITY The present invention makes it possible to provide a mechanism for cooperative play by a plurality of users.

1 is a block diagram showing the hardware configuration of a network system including a game control device according to an embodiment of the present invention; FIG. 2 is a block diagram mainly showing a functional configuration of a game control device 50 shown in FIG. 1; FIG. 3 is a diagram showing an example of the data structure of card parameter management information stored in a storage unit 42 shown in FIG. 2; FIG. 3 is a diagram showing an example of the data structure of robot parameter management information stored in a storage unit 42 shown in FIG. 2; FIG. 4 is a flow chart for schematically explaining the flow of the card battle game in this embodiment. 4 is a flow chart showing a processing procedure of the game control device 50 when a quest is started in the card battle game in this embodiment. 4 is a flow chart showing a processing procedure of the game control device 50 when card characters are evolved and synthesized in the card battle game of the present embodiment. 4 is a flow chart showing a processing procedure of the game control device 50 when a robot battle occurs in the card battle game in this embodiment. 10 is a flowchart showing a processing procedure of battle parameter setting processing executed by a parameter setting unit 53. FIG. FIG. 10 is a flowchart showing a processing procedure of robot battle effect image generation processing executed by a game control unit 54; FIG. FIG. 10 is a flowchart showing a processing procedure of robot battle effect image generation processing executed by a game control unit 54; FIG. 4 is a diagram showing an example of the data structure of guild management information stored in the storage unit 42. FIG. 4 is a diagram showing an example of the data structure of configuration item information stored in a storage unit 42; FIG. 4 is a diagram showing an example of the data structure of obtained configuration item information stored in a storage unit 42; FIG. 4 is a diagram showing an example of the data structure of level management information stored in a storage unit 42; FIG. 5 is a flow chart showing a processing procedure of guild event occurrence processing executed by the game control device 50 according to the present embodiment. 4 is a flow chart showing the procedure of guild event management processing executed by the game control device 50 according to the present embodiment.

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

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

The network system shown in FIG. 1 mainly consists of computers (server computers)
10 and a plurality of communication terminals 20 used by each of a plurality of users who play social games, for example. In addition, in FIG. 1, for convenience, one communication terminal 2
Only 0 is shown.

A 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.
It is assumed that a wide variety of application programs and the like are installed.

The computer 10 has a hard disk drive (HDD: Hard Disk Dri
ve) is connected to an external storage device 40 such as . This 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 user with a card battle game (social game) using card characters as game elements such as various characters via the communication terminal 20 . In the card battle game according to the present embodiment, a user can combine a plurality of card characters owned by the user to battle against enemy characters such as non-player characters (NPCs) via the communication terminal 20. can. In addition, in the card battle game according to the present embodiment, a mechanism is provided in which a plurality of users cooperate and play, as will be described later.

Note that the card battle game in this embodiment is executed by the game control device (web server) 5
0 and realized by a web application used by the web browser of the communication terminal 20 .

FIG. 2 is a block diagram mainly showing the 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 section 51, a deck building section 52, a parameter setting section 53 and a game control section . In this embodiment, these parts are
It is assumed that the computer 10 shown in FIG. 1 executes the program 41 stored in the external storage device 40 . This program 41 can be stored in advance in a computer-readable storage medium and distributed. Also, this program 41 may be downloaded to the computer 10 via the network 30 .

The game control device 50 also includes a storage section 42 . In this embodiment, the storage unit 42 is stored in the external storage device 40, for example.

The card management unit 51 has a function of providing various card characters and items used in the card battle game to the user who plays the card battle game according to the progress of the card battle game. It is assumed that parameters are set in advance for the card character provided by the card management unit 51 (that is, the card character owned by the user). The card management unit 51 also has a function of managing (information about) card characters and items 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 for the user who plays the card battle game, using the selected card characters and a robot character (second character owned by the user) different from the selected card characters. . In other words, the deck constructed by the deck construction section 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 a card battle game, for example. It is also assumed that parameters are set in advance for the robot character in the same manner as for the card character described above.

The parameter setting unit 53 determines the parameters of the robot character based on the parameters set for the robot character and the card 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 characters.

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

In addition, the game control unit 54 controls the parameters for the robot battle and the parameters for the enemy character during a battle between the robot character and the enemy character for which the parameters for the robot battle have been set (hereinafter referred to as robot battle). 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 effect of the robot battle and the result of the robot battle (hereinafter referred to as a robot battle effect image). This game control unit 54
The robot battle effect image generated by the communication terminal 20 via the network 30
to be displayed.

The game control unit 54 also generates an event (hereinafter referred to as a guild event) for a group called a guild consisting of a plurality of users to play cooperatively. When this guild event occurs, a plurality of users who form the guild can obtain various benefits (for example, card characters, items, etc.) by satisfying predetermined conditions in the guild event.

The storage unit 42 stores various information necessary for controlling (progressing) the card battle game. Specifically, the storage unit 42 stores parameter management information (
hereinafter referred to as card parameter management information) and parameter management information including parameters preset for the robot character (hereinafter referred to as robot parameter management information) are 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 and the like stored in the storage section 42 are updated.

The storage unit 42 also stores guild management information (group management information) indicating a guild composed of a plurality of users, information about guild events, information about card characters and items owned by users who play the card battle game, and so on. Information and information about the user are stored.

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

As shown in FIG. 3, the card parameter management information includes (parameters of) HP (hit points), attack power, speed, and skill in association with the card ID. Card ID is an identifier for identifying a card character. HP is a numerical representation of damage that a card character identified by a card ID can withstand against an attack by an enemy character. When HP becomes 0, for example, the character becomes incapable of fighting and loses the battle. The attack power is a numerical value representing the ability to attack an enemy character, and affects the damage inflicted on the enemy character. The speed is a numerical value that affects, for example, the order of attacks during a battle with an enemy character. A skill produces a predetermined effect in a battle with an enemy character, and includes, for example, an attack skill, a defense skill, a pre-battle skill, and the like, as will be described later.

In the example shown in FIG. 3, in the card parameter management information, H is associated with card ID "1".
P "100", attack power "10", speed "12" and skill "skill 1" are included. According to this, the HP of the card character identified by the card ID "1" is 10.
0, attack power is 10, speed is 12, and the card character has skill 1.

Similarly, in the card parameter management information, HP "120" is associated with card ID "2".
”, attack power “15”, speed “8” and skill “skill 2”. According to this, the card character identified by the card ID "2" has HP of 120, attack power of 15, and speed of 8, indicating that the card character has skill 2. It is

Here, the card parameter management information includes HP, attack power, speed, and skill parameters, but may include other parameters.

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

As shown in FIG. 4, in the robot parameter management information, HP is associated with the robot ID.
, attack power, speed and attributes (parameters of) are included. A robot ID is an identifier for identifying a robot character. Note that HP, attack power, and speed are the same as those included in the above-described card parameter management information, so 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, long-distance type, medium-distance type, and short-distance type.

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 robot ID "1".
According to this, the HP of the robot character identified by the robot ID "1" is 30.
0, the attack power is 30, and the speed is 40, indicating that (attributes of) the robot character is a medium-range type.

Also, in the robot parameter management information, HP "29" is associated with the robot ID "2".
0”, attack power “25”, speed “50” and attribute “far”. According to this, the robot character identified by the robot ID "2" has HP of 290, attack power of 25, speed of 50, and (attributes of) the robot character is a long-distance type. It is shown.

Also, in the robot parameter management information, HP "32" is associated with the robot ID "3".
0", attack power "35", speed "30" and attribute "near". According to this, the robot character identified by the robot ID "3" has HP of 320, attack power of 35, speed of 30, and (attributes of) the robot character is a close-range type. It is shown.

In addition, in the card battle game in this embodiment, as shown in FIG.
Types of robot characters (robot characters identified by robot IDs "1" to "3") are prepared in advance, and a robot character selected by the user at the time of initial registration for the card battle game is used by the user. shall be granted to This will
The user can perform the above-described robot battle in the card battle game of this embodiment. It should be noted that each of the three types of robot characters shown in FIG. may have properties such as being disadvantageous.

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

Hereinafter, the flow (main cycle) of the card battle game in this embodiment will be schematically described with reference to the flowchart of FIG. In the card battle game according to the present embodiment, for example, a user (player) can search objects called chapters (for example, planets, etc.).
The purpose is to obtain cards (characters and items) with high rarity value by searching for. It is assumed that quests are set in advance in the chapters.

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

A 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, a search image of the selected chapter is displayed on the communication terminal 20, and the quest set for 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, etc.) on the communication terminal 20 (step S3). It is assumed that the conditions for clearing this quest are set in advance.

In addition, when a plurality of quests are set in the chapter selected by the user, the above-described 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 participates in a robot battle will be referred to as an enemy robot character for the sake of convenience, and other enemy characters will simply be referred to as enemy characters.

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 the user can explore (that is, the new chapter is released).

Here, if the user does not give an instruction to end the card battle game (step S6
No), returning to the above step S1, the user searches (selects) a new chapter
It can be performed.

On the other hand, if the user gives an instruction to end the card battle game (Y in step S6
ES), the card battle game is terminated.

According to the card battle game of the present embodiment, the game progresses by clearing each of the chapters described above, and cards with a higher rarity value can be obtained.

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

When a 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 for improving the user's (card character, etc. owned by) level by exploring chapters, in-game currency that can be used in the card battle game, and various cards (characters and items) ), etc., and a battle event in which the enemy character in the quest is fought. Experience points, in-game currency, and various cards can be obtained even when defeating an enemy character in a battle event.

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

When an event occurs and the quest progresses as described above, a battle with an enemy character (quest boss) set for the quest occurs (step S12). This quest boss has more abilities (for example, H
It is a character with high parameters such as P and attack power.

It should be noted that, unlike the robot battle described above, the battle with the enemy character and the battle with the quest boss in the battle event described above is different from, for example, one of a plurality of card characters owned by the user (hereinafter referred to as a leader card character). and notation). Specifically, the game control unit 54 controls the parameters based on the parameters set for the leader card character and the parameters set for the enemy character or quest boss included in the parameter management information stored in the storage unit 42. , controls 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).

If the quest boss is defeated here, the quest will be cleared and a new quest will occur. When multiple quests are cleared in this manner, a robot battle occurs as described above.

In the card battle game according to the present embodiment, one of the plurality of card characters owned by the user (hereinafter referred to as a base card character) is assigned a card character other than the base card character (hereinafter referred to as a synthetic card character). ), the base 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 evolving and synthesizing the card characters in the card battle game according to 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 multiple card characters owned by the user on the communication terminal 20 . Thereby, the user can select a base 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 a base card character according to the user's operation (step S21).

Furthermore, 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 a synthetic card character according to the user's operation (step S22).

The game control unit 54 increases the points related to the evolution of the base card character (hereinafter referred to as "evolution points") according to the parameters set for the composite card character, for example (step S23). It is assumed that the evolution points of this base card character are stored and managed in the storage unit 42, for example. 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 that the evolution point of the base card character has reached a predetermined value (hereinafter referred to as a specified value) for the base card character (that is, MAX
(step S24).

When it is determined that the evolution points of the base card character have reached the specified value (YES in step S24), the game control section 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 evolution.

In other words, in the card battle game of the present embodiment, by evolving and synthesizing various card characters in this way, the game can be advantageously progressed in robot battles with enemy robot characters, battles with enemy characters, and the like.

On the other hand, if it is determined that the evolution points of the base card character have 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 used in the next evolution synthesis of the base card character.

In step S23 described above, for example, if the composite 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 a card character with a high rarity value, so that a card character with a high rarity value can be easily given to the user (that is, a rare card character) You can increase the ejection probability of high-value cards). In addition, a card character (base card character) whose evolution points are difficult to reach a specified value is set, and the card character can be acquired only when a specific enemy character (for example, a raid boss, etc., which will be described later) is defeated. By making it possible, it is possible to prompt the user to repeatedly fight with the specific enemy character, thereby expanding the playing range 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 according to the present embodiment will be described with reference to the flowchart of FIG.

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

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

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

Next, the parameter setting unit 53 executes battle parameter setting processing 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 battle parameters include the deck robot character's HP, attack power, speed, skill, attributes, and the like. Details of the battle parameter setting process will be described later.

The game control unit 54 determines whether or not the user has given an instruction to start a robot battle according to the user's operation on the communication terminal 20 (step S34). Note that the user can instruct the robot battle to start by performing a tap operation on a robot battle start button or the like displayed on the screen of the communication terminal 20 .

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

On the other hand, if it is determined that an instruction to start a robot battle has been given (YES in step S34)
), the game control unit 54 executes the above-described robot battle effect image generation processing (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 characters in step S33 and the parameters preset for the enemy robot characters in the robot battle. A robot battle effect image corresponding to the control is generated. The parameters set in advance for the enemy robot character include the HP, attack power, speed, skill, attributes, etc. of the enemy robot character in the same manner as 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 sequentially displays images representing the offense and defense between the deck robot character and the enemy robot character, and finally the result of the robot battle ( That is, an image representing victory or defeat is displayed. It is also possible to shorten the display time of the robot battle effect image and display only the image representing the result of the robot battle according to the user's instruction.

Next, referring to the flowchart of FIG. 9, the above-described battle parameter setting process (
3) will be described. This 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 sets parameter management information (robot parameter management information) is acquired (step S41). The robot parameter management information (parameters contained therein) includes HP, attack power, speed, and attributes as described above.

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

Although detailed description is omitted, the storage unit 42 stores, for example, a robot ID for identifying a robot character owned by the user and a card character for identifying a card character in association with a user ID for identifying the user. is stored (managed), and in steps S41 and S42, the robot ID included in this information is stored (managed).
And based on the card ID, robot parameter management information and card parameter management information can be obtained.

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

In this case, the parameter setting unit 53 adds (the parameter value of) HP included in the robot parameter management information and (the parameter value of) HP included in each of the card parameter management information to obtain 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.

It should be noted that, here, the HP included in the battle parameters is calculated as the sum of the HP included in the robot parameter management information and the HP included in each of the card parameter management information. The configuration may be such that attribute correction is performed for each HP included. 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. The HP included in the card parameter management information may be multiplied by an attribute correction value depending on whether or not it matches the attribute (attribute of the deck robot character) included in the robot parameter management information. In this case, the HP included in the battle parameters is calculated by "the sum of HP included in the robot parameter management information+(HP included in the card parameter management information*attribute correction value)". Note that the attribute correction value when the attribute of the card character matches the attribute of the deck robot character is a predetermined value of 1.
The attribute correction value is assumed to be 1 when the attribute of the card character does not match the attribute of the deck robot character, which is a larger value. Accordingly, when building a deck, the user selects a card character having the same attributes as the robot character owned by the user (deck robot character), thereby increasing the HP included in the battle parameters (
) can be higher.

Next, the parameter setting unit 53 determines 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 the card parameter management information acquired in step S42. The attack power (parameters of) included in the battle parameters set for the attack is calculated (step S44)
.

In this case, the parameter setting unit 53 uses the attack power (
By adding the attack power (parameter value of) included in each of the card parameter management information and the attack power (parameter value of) included in each of the card parameter management information, 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.

It should be noted that, here, it was explained that 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, but the above-mentioned HP As in the case of (1) above, for example, the configuration may be such that attribute correction is performed for the attack power included in each piece of card parameter management information.
Specifically, the card parameter management information includes the attributes of the card character identified by the card ID included in the card parameter management information, and the attributes of the card character are included in the robot parameter management information (the attributes of the deck robot character). attribute), the attack power included in the card parameter management information may be multiplied by an attribute correction value. In this case, the attack power of the battle parameters is calculated by "sum of attack power included in robot parameter management information + (attack power included in card parameter management information*attribute correction value)". The attribute correction value when the card character's attributes match the deck robot character's attributes is a predetermined value larger than 1, and the attribute correction value when the card character's attributes do not match the deck robot character's attributes. shall be 1. Accordingly, when constructing a deck, the user selects a card character having the same attribute as the robot character (deck robot character) owned by the user, thereby increasing the attack power included in the battle parameters. 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 the card parameter management information acquired in step S42. Calculate the speed (parameters of) included in the battle parameters (step S
45).

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 to obtain the robot parameter management information. and the speeds included in each of the card parameter management information are calculated as the speeds included in the battle parameters.

It should be noted that although the sum of the speeds contained in the robot parameter management information and the speeds contained in each of the card parameter management information is calculated as the speed contained in the battle parameters here, the HP and attack power described above are assumed to be calculated. As in the case of (1), for example, the configuration may be such that attribute correction is performed for the speed included in each piece of card parameter management information. Specifically, the card parameter management information includes the attributes of the card character identified by the card ID included in the card parameter management information, and the attributes of the card character are included in the robot parameter management information (the attributes of the deck robot character). attribute), the speed included in the card parameter management information may be multiplied by an attribute correction value. In this case, the speed included in the battle parameters is calculated by "sum of speed included in robot parameter management information + (speed included in card parameter management information*attribute correction value)".
The attribute correction value when the card character's attributes match the deck robot character's attributes is a predetermined value larger than 1, and the attribute correction value when the card character's attributes do not match the deck robot character's attributes. shall be 1. This will
When constructing a deck, the user selects a card character having the same attributes as the robot character (deck robot character) owned by the user, thereby increasing the speed (value) included in the battle parameters. can be done.

Next, the parameter setting unit 53 specifies skills included in the battle parameters set for the deck robot character based on each piece of card parameter management information acquired in step S42 (step S46). In this case, the parameter setting unit 5
3 specifies all skills included in each piece of card parameter management information as skills included in 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 to the deck robot character. (step S47).

As described above, in the case where attributes are corrected for the HP, attack power, and speed contained in each of the card parameter management information, for example, the attributes of all card characters match those 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 it is possible to improve the combination of the deck robot character and the card character. It is also possible to adopt a configuration in which a special skill (for example, combo type skill) is imparted accordingly.

In the robot battle according to the present embodiment, the above-described robot battle effect image generation processing is executed based on the battle parameters set for the deck robot characters and the parameters set for the enemy robot characters. be.

Next, the processing procedure of the robot battle effect image generation processing (the processing of step S35 shown in FIG. 8) will be described with reference to the flowcharts of FIGS. 10 and 11. FIG. In this robot battle effect image generation process, a robot battle between a deck robot character and an 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 section 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 controls the speed included in the battle parameters set for the deck robot character (hereinafter simply referred to as battle parameters for the deck robot character) and the speed set for the enemy robot character. The speeds included in the parameters (hereinafter simply referred to as parameters of the enemy robot character) are 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 offensive skills, defensive skills, and pre-battle skills.

An attack skill is activated when a robot character (a deck robot character or an enemy robot character) having the attack skill attacks, and within a predetermined period after the attack skill is activated, for example, the attack power (parameter It is a skill that produces an effect that increases the value). A defensive skill is activated when a robot character (a deck robot character or an enemy robot character) having the defensive skill defends (that is, when receiving an opponent's attack), and a predetermined period after the defensive skill is activated. For example, it is a skill that produces an effect such as lowering the opponent's attack power (parameter value) in a robot battle. Pre-battle skills, like attack and defense skills, are skills that increase your own attack power or reduce the opponent's attack power, but unlike attack and defense skills, they are used in robot battles. It is activated before the start of offense and defense (battle) in , and the effect continues during the period of the robot battle. It is assumed that activation timings and activation probabilities are set in advance for each of these skills.

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

If it is determined that the first attacking pre-battle skill is to be activated (YES in step S51), the game control unit 54 generates an image representing the activation of the first attacking pre-battle skill (first attacking pre-battle skill activation image) (step S52). In addition, the game control unit 54 reflects the effect produced by the pre-battle skill of the first attack determined to be activated in the battle parameters of the deck robot character or the parameters of the enemy robot character.

On the other hand, if it is determined not to activate the first pre-battle skill (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 for the pre-battle skill (hereinafter referred to as the second-attack 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-battle skill (step S52). Note that when there are a plurality of pre-battle skills of the second attack, it is determined whether or not to activate each pre-battle skill of the second attack.

When it is determined that the second attack pre-battle skill is to be activated (YES in step S53), the game control unit 54 generates an image representing the activation of the second attack pre-battle skill (second attack pre-battle skill activation image). (step S54). In addition, the game control unit 54 reflects the effect caused by the second-attack pre-battle skill determined to be activated in the battle parameters of the deck robot character or the parameters of the enemy robot character.

On the other hand, if it is determined not to activate the second attack pre-battle skill (NO in step S53),
The process of step S54 is not executed.

Next, the game control unit 54 determines the first attack based on the activation probability set for 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).
Note that if there are a plurality of attack skills that attack first, it is determined whether or not to activate each of the attack skills that attack first.

When it is determined to activate the first attack skill (YES in step S55), the game control unit 54 generates an image representing activation of the first attack skill (first attack skill activation image) (step S56). In addition, the game control unit 54 reflects the effect caused by the first attack skill determined to be activated in (the attack power included in) the battle parameters of the deck robot character.

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

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

Next, the game control unit 54 determines the second attack defense based on the activation probability set for 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 a plurality of defensive skills for the second attack, it is determined whether or not to activate each of the defensive skills for the second attack.

If it is determined that the second attack defense skill is to be activated (YES in step S58), the game control unit 54 generates an image representing the activation of the second attack defense skill (second attack defense skill activation image) (step S59). In addition, the game control unit 54 reflects the effect caused by the second-attack defensive skill determined to be activated in (attack power included in) the battle parameter of the deck robot character.

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

The game control unit 54 generates an image representing the effect of the damage received by the enemy robot character (second attack damage effect image) (step S60). In the process of step S60, an image showing that the deck robot character's attack has been avoided may be generated based on the probability corresponding to the speed included in the parameters 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, the damage inflicted on the enemy 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 parameter value of) the HP included in the parameters of the enemy robot character. Note that as described above, step S6
If an image representing that the attack of the deck robot character has been avoided is generated at 0, the damage inflicted on 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 section .

Next, the game control unit 54 determines the second-attack attack based on the activation probability set for the attack skill (hereinafter referred to as the second-attack 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). Note that if there are a plurality of second-attack attack skills, it is determined whether or not to activate each second-attack skill.

If it is determined to activate the second attack skill (YES in step S62), the game control unit 54 generates an image representing activation of the second attack skill (second attack skill activation image) (step S63). In addition, the game control unit 54 sets the effect caused by the second-attack attack skill determined to be activated as a parameter (attack power included in) of the enemy robot character.
be reflected in

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

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

Next, the game control unit 54 determines the first-attack defense based on the activation probability set for the defense skill (hereinafter referred to as the first-attack 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 a plurality of defensive skills to attack first, it is determined whether or not to activate each of the defensive skills to attack first.

When it is determined to activate the first defense skill (YES in step S65), the game control unit 54 generates an image representing activation of the first defense skill (first defense skill activation image) (step S66). In addition, the game control unit 54 sets the effect caused by the defensive skill of the first attack determined to be activated as a parameter (attack power included in) of the enemy robot character.
be reflected in

On the other hand, if it is determined not to activate the first defensive skill (NO in step S65), the process of step S66 is not executed.

The game control unit 54 displays an image (
A damage effect image for the first attack) is generated (step S67). In the process of step S67, an image showing that the enemy robot character's attack has been avoided may be generated based on the probability corresponding to the speed included in the parameters 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 parameter of the enemy robot character. In this case, as described above, the damage inflicted on 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 parameter value of) the HP included in the battle parameters of the deck robot character. As described above, when an image representing that the attack of the enemy robot character has been avoided is generated in step S67, the damage inflicted on the deck robot character is assumed to be zero.

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

If it is determined that the remaining HP of the deck robot character is not 0 or less (step S6
If NO at 8), 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 to repeat the process. The damage calculated by the game control unit 54 in 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 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 the remaining H of the deck robot character is determined in step S68
If it is determined that P is 0 or less, the game control unit 54 determines the result of the robot battle (
An image (win/lose image) representing the win/lose is generated (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 representing that the deck robot character has been defeated is generated.

Next, the game control unit 54 generates each image (first attack pre-battle skill activation image, second attack pre-battle skill activation image, first attack skill activation image, first attack effect image, second attack effect image, Attack defense skill activation image, second attack damage effect image, second attack attack skill activation image, second attack attack effect image, first attack defense skill activation image, first attack damage effect image, and win/loss image) in chronological order. A robot battle effect image for displaying the effect and result of the robot battle is generated by combining so as to transition (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 main cycle of) the card battle game in this embodiment, various cards (characters and items) can be obtained by clearing chapters (quests) and the like.
, and use the obtained cards to clear more difficult chapters to advance the story.

On the other hand, in the card battle game in this embodiment, apart from the main cycle described in FIG. A sub-cycle is provided that includes It is assumed that this guild event occurs (is held) periodically.

Guild events are explained below. The purpose of the guild event is for a plurality of users (guild members) forming the guild to cooperate to collect a plurality of constituent items that constitute one item appearing in the card battle game. In this guild event, if the guild satisfies a predetermined condition, a plurality of users forming the guild can obtain various benefits. The benefits that can be obtained in the guild event include, for example, various card characters and items.

Here, in the storage unit 42 included in the game control device 50, guild management information (group management information) and information on guild events (hereinafter referred to as guild event information) are stored as information related to guild events.
configuration item information), information related to card characters, items, etc. possessed by the user who plays the card battle game, and information related to the user. Information on card characters, items, etc. owned by the user who plays the card battle game includes information on card characters, items, etc. owned by the user.
Information on configuration items obtained by the user in the guild event (hereinafter referred to as acquisition configuration item information) and the like are included. The information about the user also 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. As shown in FIG. The guild management information is information indicating a guild (a group composed of a plurality of users who play the game) formed in the card battle game.

As shown in FIG. 12, the guild management information includes user IDs and guild IDs associated with each other. A user ID is an identifier for identifying a user who plays the 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" is associated with it. The guild management information also includes a user ID "user 2" and a guild ID "guild 1" in association with each other. According to this, the user ID
It is shown that the users identified by "user 1" and "user 2" belong to the guild identified by the guild ID "guild 1".

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

In the card battle game of this embodiment, it is assumed that all users who play the card battle game belong to (join) one of the guilds. Specifically, when playing the card battle game for the first time, after the tutorial (explanation of how to play, etc.), the user is prompted to join an existing guild, and the user can join the specified guild. . It is also possible for a user to create a new guild and recruit other users. Furthermore, it is possible to adopt a configuration in which 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 configuration item information stored in the storage unit 42. As shown in FIG.
Configuration item information is information indicating configuration items collected in a guild event. A guild event in the present embodiment is such that, for example, the guild cooperates to collect a plurality of pieces (components) that make up one jewel, thereby obtaining a privilege. It is assumed that a plurality of types of gems to be collected in the guild event are prepared.

In this case, as shown in FIG. 13, the configuration item information includes the gem type, fragment ID, and appearance probability in association with each other. Fragment ID is an identifier for identifying each of a plurality of fragments forming each gem. The appearance probability indicates the probability that the fragment identified by the associated fragment ID will appear in the card battle game.

In the example shown in FIG. 13, the configuration item information includes the type of jewel "Jewel A" and the fragment ID "A".
1 to A6" and the appearance probability "Probability 1" are included in correspondence. According to this, jewel A consists of six fragments identified by fragment IDs "A1 to A6" (hereafter referred to as fragments A1 to A6
), and the fragments A1 to A6 are "probability 1" in the card battle game
It is shown to appear in For example, gem A targets low-level users, and fragments A1 to A6 are common to low-level users (when playing)
The probability is set so that it is likely to appear in Here, a low-level user is a user with a low level in the card battle game. Although the range of low-level users can be changed as appropriate, it is assumed that the users are users with levels of about 1 to 20, for example. In addition, fragments A1 to A
6 may appear with a low appearance probability to users other than low-level users, or may not appear to users other than the low-level users.

In addition, the configuration item information includes the type of gem "jewel B", fragment IDs "B1 to B6", and appearance probability "probability 2" in association with each other. According to this, jewel B has a fragment ID "
B1 to B6" (hereinafter referred to as fragments B1 to B6), and it is indicated that the said fragments B1 to B6 will appear in the card battle game with a "probability of 2". It should be noted that gem B targets, for example, middle-level users, and fragments B1 to B6 are all common and probabilities are set so that middle-level users (while playing) are more likely to appear. Here, a middle-level user is a user whose level in the card battle game is higher than the low-level user described above and lower than the high-level user described later. Although the range of middle-level users can be changed as appropriate, it is assumed that the users are users with levels of about 21 to 50, for example. In addition, the pieces B1 to B6 may appear with a low appearance probability even for users other than middle-level users, or may not appear for users other than the middle-level users.

Further, the configuration item information includes the type of gem "jewel C", fragment IDs "C1 to C6", and appearance probability "probability 3" in association with each other. According to this, jewel C has a fragment ID "
C1-C6" (hereinafter referred to as fragments C1-C6), and it is indicated that the fragments C1-C6 appear in the card battle game with a "probability of 3". Note that the jewel C targets, for example, high-level users, and the fragments C1 to C6 are all common, and the probabilities are set so that high-level users (when playing) tend to appear. Here, a high-level user is a user with a high level in the card battle game. Although the range of high-level users can be changed as appropriate, it is assumed that the users are users whose level is about 51 or higher, for example. In addition, the pieces C1 to C6 may appear with a low appearance probability to users other than the high-level users, or may not appear to users other than the high-level users.

Furthermore, the configuration item information corresponds to the type of jewel "Jewel D", the fragment IDs "D1 to D6", and the appearance probability "D1, D2: probability 1, D3, D4: probability 2, D5, D6: probability 3". included with According to this, the gem D is composed of six pieces (hereinafter referred to as pieces D1 to D6) identified by the piece IDs "D1 to D6". D4 appears with "probability 2", and pieces D5 and D6 appear with "probability 3". Gem D targets all users (that is, the above-described low-level users, middle-level users, and high-level users). Specifically, the fragments D1 and D2 are set with probabilities such that they are likely to appear to low-level users. Fragments D3 and D4 are set with probabilities that are likely to appear for middle-level users.
Fragments D5 and D6 are set with probabilities that are likely to appear for high-level users. In this way, in the case of gem D, unlike other gems, each of the plurality of pieces (fragments D1 to D6) forming gem D is given to users of different levels. is set.

FIG. 14 shows an example of the data structure of obtained configuration item information stored in the storage unit 42. As shown in FIG. Acquisition configuration item information is information indicating configuration items acquired by the user (that is, given to the user) in the guild event.

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

In the example shown in FIG. 14, the obtained configuration item information includes a user ID "user 1" and a piece 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”.

The obtained configuration item information also includes a user ID “user 2” and a fragment ID “D4” in association with each other. This shows that the fragment identified by the fragment ID “D4” is given to the user identified by the user ID “user 2”.

Here, for the sake of convenience, only the users identified by the user IDs "user 1" and "user 2" have been described, but the storage unit 42 also includes other users to whom pieces of configuration items are assigned. contains the acquired configuration item information.

FIG. 15 shows an example of the data structure of level management information stored in the storage unit 42. As shown in FIG. 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 a user ID and level information in association with each other. A user ID is an identifier for identifying a user who plays the 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 a user ID "user 1" and level information "
5” is associated with it. This shows that the level of the user identified by the user ID "user 1" is 5.

The level management information also includes the user ID "user 2" and the level information "25" in association with each other. This shows that the level of the user identified by the user ID "user 2" is 25.

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

It should be noted that the user's level in the card battle game increases according to the progress of the card battle game, victory in the battle, and the like. When the user's level in the card battle game improves in this way, the level management information (level information contained therein) 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 this embodiment will be described. In this case, the game control device 50 executes guild event generation processing and guild event management processing.

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

First, the game control unit 54 included in the game control device 50 generates a guild event for giving configuration items (step S81). This guild event occurs, for example, periodically. More specifically, the guild event occurs, for example, at 7:00 in the morning, at 12:00 in the afternoon, and at 22:00 in the evening. In addition, the user who is playing the card battle game is notified via the communication terminal 20 of the period during which the guild event is occurring.
A user playing the card battle game is hereinafter referred to as a target user.

When a guild event is generated, the game control unit 54 selects constituent items (pieces that make up each jewel) according to the target user's play contents of the card battle game (that is, the target user's operation on the communication terminal 20). It is determined whether or not to appear (step S82). At this time, the game control unit 54 executes determination processing based on the level of the target user indicated by the appearance probability and level management information included in the configuration item information stored in the storage unit 42 .

It should be noted that the constituent items appear in various scenes while playing the card battle game. Specifically, the constituent items appear during quests in the card battle game or when defeating various enemy characters (quest bosses and enemy robot characters).

In other words, the game control unit 54 causes the constituent items to appear based on the appearance probability according to the target user's level when the target user's card battle game play situation allows the constituent items to appear. determine whether or not to allow

If it is determined that the configuration item is to appear (YES in step S82), the game control unit 54 generates an effect image (configuration item appearance image) that causes the configuration item to appear,
The configuration item appearance image is displayed on the communication terminal 20 used by the target user.

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

As described above, in the configuration item information, users (levels) to whom the configuration item is likely to be granted are set for each configuration item. will be

In this case, the game control unit 54 obtains configuration item information including a user ID for identifying the target user and a fragment ID for identifying a 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 of time (predetermined period of time) has elapsed after the guild event was generated in step S81 (step S8).
5). For example, one hour or the like is set as the predetermined period.

If it is determined that the predetermined period has passed (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 continues, and the process returns to step S82 to repeat the process. In other words, in the guild event in this embodiment, it is possible to collect a plurality of configuration items during the period in which the guild event is occurring (that is, during the period from the occurrence of the guild event until the end). It is possible.

Also, if it is determined in step S82 that the configuration item should not appear, the configuration item is not given to the target user, and the process of step S85 is executed.

It should be noted that, in step S82, if it is determined, for example, to make a plurality of constituent items appear based on the appearance probabilities, the effect image for making one of the plurality of constituent items appear is displayed on the communication terminal 20. Alternatively, an effect image that makes a plurality of configuration items appear may be displayed on the communication terminal 20 . The communication terminal 2 is a production image that causes a plurality of configuration items to appear.
0, all of the plurality of configuration items may be given to the target user, or only one selected from the plurality of configuration items may be given to the target user. good.

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

First, the game control unit 54 included in the game control device 50 is indicated by the 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. A configuration item given to each of a plurality of users (guild members) constituting a guild (group) is specified (step S91).

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

The game control unit 54 identifies all user IDs associated with the same guild ID in the acquired guild management information. Users identified by the user IDs specified here are users who form the same guild. Below, the user ID specified here
A guild composed of users identified by is called a target guild.

The game control unit 54 stores the obtained configuration item information including the specified user ID in the storage unit 42 .
Get from

The game control unit 54 identifies the piece identified by the piece ID included in the acquired piece of configuration item information as a piece of configuration item given to each of the plurality of users forming the target guild.

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

Next, the game control unit 54 determines whether or not all of the configuration items have been granted to (a plurality of users constituting the target guild) based on the obtained configuration items and the configuration item information stored in the storage unit 42. It is determined whether or not (step S92).

The process of step S92 will be specifically described with reference to FIG. 13 described above.
are included, it is determined that all of the configuration items have been granted. In addition, if all of the fragments identified by each of the fragment IDs "B1 to B6" (the six fragments that make up jewel B) are included in the obtained configuration items, all of the configuration items are given. It is determined that Similarly, if all of the fragments identified by each of the fragment IDs "C1 to C6" (the six fragments that make up jewel C) are included in the obtained configuration items, all of the configuration items determined to have been granted. In addition, if all of the fragments identified by each of the fragment IDs "D1 to D6" (the six fragments that make up the gem D) are included in the obtained configuration items, all of the configuration items are granted. It is determined that

That is, in step S92, if all of the pieces (that is, a set of six pieces) that constitute at least one (type) of jewels are present in the acquisition configuration item,
It is determined that all of the configuration items have been granted.

When it is determined that all of the configuration items have been granted (YES in step S92), the game control unit 54 provides a privilege corresponding to the configuration items to which all of the configuration items have been granted (that is, the types of gems from which all fragments have been collected). , to a plurality of users (guild members) forming the target guild (step S93). In addition, multiple sets of configuration items are given (for example, all the pieces identified by the piece IDs "A1 to A6" and the pieces identified by the piece IDs "D1 to D
6" are given), the configuration item (
types) are granted.

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 and the process is repeated.

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

Here, when the target guild collects all of the constituent items, it is possible to assign ranking points to the target guild in addition to the benefits described above. The ranking points given to the target guild in this way are aggregated for each predetermined period,
It can be configured such that various benefits are given to a plurality of users forming the target guild according to the total value of the ranking points. It should be noted that ranking points are also given for robot battles other than guild events. This will
Even during a period in which no guild event is occurring, it can be expected that each of the plurality of users forming the target guild will actively play the card battle game in order to obtain ranking points. Note that 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 in FIG. 17 is executed for all guilds existing (created) in the card battle game.

As described above, in the present embodiment, each of a plurality of users forming a guild (group) is provided with a configuration item according to the operation of the user on the communication terminal 20 used by the user. Acquisition configuration item information indicating a configuration item given to each of a plurality of users is stored in the storage unit 42, and based on the acquisition configuration item information stored in the storage unit 42, guild management information (group management information) is used. It is determined whether or not all of the plurality of configuration items (a set of configuration items) have been granted to the 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.

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

In addition, in the present embodiment, a privilege is granted when all of the plurality of configuration items are granted within the period during which the guild event is occurring, and when the period has passed, the acquired configuration item information is deleted. 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 obtain the privilege. , can encourage more users to play cooperatively. In addition, in this embodiment, the characteristics of the guild (
It is also possible to configure the communication terminal 20 to display a screen for explaining the main play time periods of the users who make up the guild. By adopting such a configuration, the user can join a more appropriate guild, so that it becomes possible to obtain more privileges in the guild, and continuous play of the card battle game can be expected.

In addition, in the card battle game of the present embodiment, the main cycle described with reference to FIG. 5 and the sub-cycle including the guild event are provided. A mechanism for having a robot battle with other users (hereinafter referred to as PvP) may be further included. Also in this PvP, the above-described ranking points and various benefits can be given according to the results. It is also possible to adopt a configuration in which configuration items in this embodiment can be obtained from other users according to the results of this PvP.

In addition, for example, in normal quests and dedicated quests, there are raid boss events in which other users' leader card characters are borrowed to fight enemy characters called raid bosses, and for example, enemies called raid robot characters (raid NPCs) cooperate in the guild. It is also possible to have a configuration in which a raid NPC event or the like in which a robot character and a robot battle (raid robot battle) are 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 give motivation to increase friends in the card battle game and encourage continuous play. In addition, by generating a raid boss event, it is possible to recognize the strength (that is, parameters) of card characters (leader card characters) of other users, as well as to learn the existence of new card characters and their parameters. . Also, a user who lends a leader card character to another user through a raid boss event is given special benefits such as points used for acquiring card characters, items, etc. in a card battle game, for example.

In the case of a raid NPC event, each user who constitutes a guild individually performs a robot battle using their own deck robot character, and according to the result of the robot battle, the above ranking points are awarded to the guild. It is also possible to set it as the structure which gives. Also, if you lose the raid robot battle at the raid NPC event,
It is also possible to have a configuration that allows requesting assistance from other guilds.

Also, although the card battle game in the present embodiment has been described as being implemented by a web application, it is implemented by a native application that is downloaded to the communication terminal (terminal device) 20, installed in the communication terminal 20, and used. I don't mind.

It should be noted that the present invention is not limited to the above-described embodiments as they are, and can be embodied by modifying constituent elements without departing from the scope of the present invention at the implementation stage. Also, various inventions can be formed by appropriate combinations of a plurality of constituent elements disclosed in the above embodiments. For example, some components may be omitted from all components shown in the embodiments.

10 Computer 20 Communication Terminal 30 Network 40 External Storage Device 41 Program 42 Storage Section 50 Game Control Device 51 Card Management Section 52 Deck Building Section 53 Parameter Setting Section 54 Game Control Section

Claims (10)

to the computer connected to the terminal device,
A step of providing a user of the terminal device with a first component corresponding to the first item with a predetermined appearance probability, wherein there are a plurality of the first components, and all of the first components have appearance probabilities at the level of the user. a step, which is a constant value according to
A step of providing a user of the terminal device with a second component corresponding to the second item with a predetermined appearance probability, wherein there are a plurality of the second components, and the appearance probability of some of them is different from that of the other a step different from some occurrence probabilities;
a step of giving the first item to the group when all the first constituent elements are included in all the constituent elements given to each user belonging to the group to which the user belongs;
If all of the second components are included in all of the components given to each user belonging to the group to which the user belongs, giving the second item to the group. , a game control program. to the computer;
A step of providing a user of the terminal device with a third component corresponding to the third item with a predetermined appearance probability, wherein there are a plurality of the third components, and all of the appearance probabilities are at the level of the user. a step, which is a constant value according to
giving the third item to the group when all the third constituent elements are included in all of the constituent elements given to each user belonging to the group to which the user belongs. ,
if the user is at the first level, the occurrence probability of the first component is higher than the occurrence probability of the third component;
2. The game control program according to claim 1, wherein the appearance probability of the first component is lower than the appearance probability of the third component when the user is of a second level higher than the first level. 3. The game control program according to claim 2, wherein the probability of occurrence of the third component is zero if the user is of the first level. if the user is at the first level, the appearance probability of some of the second components is higher than the appearance probability of other parts of the second components;
2. The method of claim 1, wherein when the user is at a second level higher than the first level, the probability of occurrence of some of the second components is lower than the probability of occurrence of other parts of the second components. game control program. 2. The game control program according to claim 1, wherein the appearance probability of any of said plurality of second components is not zero regardless of said user's level. A game control device connected to a terminal device,
A step of providing a user of the terminal device with a first component corresponding to the first item with a predetermined appearance probability, wherein there are a plurality of the first components, and all of the first components have appearance probabilities at the level of the user. means, which is a constant value according to
A step of providing a user of the terminal device with a second component corresponding to the second item with a predetermined appearance probability, wherein there are a plurality of the second components, and the appearance probability of some of them is different from that of the other A means different from some appearance probability,
means for imparting the first item to the group when all the first constituent elements are included in all the constituent elements imparted to each user belonging to the group to which the user belongs;
means for giving the second item to the group when all the second constituent elements are included in all the constituent elements given to each user belonging to the group to which the user belongs. Control device. A first means is a step of providing a user of a terminal device with a first component corresponding to a first item with a predetermined appearance probability, wherein there are a plurality of the first components, and all of the first components have the appearance probabilities described above. A step, which is a constant value according to the user's level;
A second means is a step of providing a user of the terminal device with a second component corresponding to the second item with a predetermined appearance probability, wherein there are a plurality of the second components, and some of them appear. the probability is different from some other probability of occurrence, a step;
a step of giving the first item to the group when the first component is all included in all of the components given to each user belonging to the group to which the user belongs; and,
a step of giving the second item to the group when the second component is all included in all of the components given to each user belonging to the group to which the user belongs, wherein the fourth means includes and game control methods including; to the terminal device,
A step of receiving a first component corresponding to a first item with a predetermined probability, wherein there are a plurality of first components, and the probability of receiving the first component is a constant value according to the level of the user. , step and
A step of receiving a second component corresponding to a second item with a predetermined probability, wherein there are a plurality of second components, and the probability of receiving a part of them is determined by the probability of receiving a part of the second component. a step, different from the probability received, and
a step of receiving the first item if all of the first components are included in all of the components given to each user belonging to the group to which the user belongs;
a step of receiving the second item if all of the second components are included in all of the components given to each user belonging to the group to which the user belongs. control program. A means for receiving a first component corresponding to a first item with a predetermined probability, wherein there are a plurality of first components, and the probability of receiving the first component is a constant value according to the level of the user. , means and
Means for receiving a second component corresponding to a second item with a predetermined probability, wherein there are a plurality of second components, and the probability of receiving a part of them is determined by the probability of receiving a part of the second component. Means, different from the probability of receiving,
means for receiving the grant of the first item when all of the first components are included in all of the components granted to each user belonging to the group to which the user belongs;
means for receiving the second item when all of the second components are included in all of the components given to each user belonging to the group to which the user belongs. . The first means is a step of receiving a first component corresponding to the first item with a predetermined probability, wherein there are a plurality of first components, and the probability of receiving any of the first components depends on the level of the user. a step, which is a constant value
The second means is a step of receiving a second component corresponding to the second item with a predetermined probability, wherein there are a plurality of second components, and the probability of receiving a part of them is different from the other a step, different from the probability of receiving some grants;
a step of receiving the first item if all of the first components are included in all of the components given to each user belonging to the group to which the user belongs;
a step of receiving the second item if all of the second components are included in all of the components given to each user belonging to the group to which the user belongs; game control methods, including;

Images