JP6203035B2 - GAME CONTROL METHOD, GAME CONTROL DEVICE, AND PROGRAM - Google Patents

Description

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

  In recent years, a social game that is provided on a social networking service (SNS) and plays while communicating with other users is known.

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

  The native application is an application that depends on the OS of a communication terminal such as an iPhone (registered trademark) terminal or an Android (registered trademark) terminal of a smartphone. For example, the server device distributes native applications 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.

  The native application needs to be developed in two types: a programming language “Objective-C” corresponding to the iPhone terminal and a programming language “Java” corresponding to the Android terminal. For this reason, the native application needs to be published through an official marketplace after the coding process using the language specific to the platform of the communication terminal.

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

  By the way, in the above-described social games, there is a game in which a plurality of users (players) who play the social game can form a group called a guild. In such a social game, information can be shared or communicated between a plurality of users (guild members) constituting the same guild.

  For example, in a social game where a user battles with an enemy character using various characters owned by the user, for example, a battle with an enemy character called a raid boss can be performed in cooperation with the guild. In this way, when a guild cooperates to battle with an enemy character and wins as a result of the battle, the guild member can obtain various privileges (for example, a character, an item, etc.).

JP 11-244533 A

  In a social game in which a battle with an enemy character is carried out in cooperation with the guild described above, a guild can be obtained by configuring the guild, so that a privilege that cannot be obtained by one user can be obtained. Is beneficial to the user.

  However, since the guild in such a case aims at winning a battle, it tends to be composed of users (advanced users) with high levels in social games. In many cases, there is an upper limit on the number of guild members.

  For this reason, a low-level user (beginner) can only form a guild with a user at the same level as the user, and as a result, there is a possibility that a privilege that the user desires cannot be obtained. There is. Such a situation causes a low level of user's willingness to play a game.

  In other words, in the social game, for example, a new mechanism that can be played cooperatively by a plurality of users (guilds) regardless of the level or the like is necessary.

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

  According to one aspect of the present invention, group management that indicates a group that is configured to be communicably connected to a plurality of communication terminals that are used by each of a plurality of users who play a game and is configured by a plurality of users who play the game There is provided 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 constituting one item. The game control method includes a step of assigning a configuration item to each of a plurality of users, a step of storing acquired configuration item information indicating a configuration item assigned to each of a plurality of users in a storage unit, and a storage unit A plurality of configuration items necessary for configuring one item indicated by the configuration item information for a plurality of users configuring the group indicated by the group management information based on the obtained configuration item information stored in The storage means further stores level management information indicating the level of each of the plurality of users, and assigns configuration items based on the level management information in the step of assigning configuration items. Whether to give each of a plurality of configuration items indicated by the item information to each of a plurality of users Disconnection, and characterized by a group in which a plurality of users each belong users can be specified.

  The present invention makes it possible to provide a mechanism for playing in cooperation with a plurality of users.

It is a block diagram which shows the hardware constitutions of the network system containing the game control apparatus which concerns on embodiment of this invention. It is a block diagram which mainly shows a function structure of the game control apparatus 50 shown in FIG. It is a figure which shows an example of the data structure of the card parameter management information stored in the storage part 42 shown in FIG. It is a figure which shows an example of the data structure of the robot parameter management information stored in the storage part shown in FIG. It is a flowchart for demonstrating schematically the flow of the card battle game in this embodiment. It is a flowchart which shows the process sequence of the game control apparatus 50 when the quest is started in the card battle game in this embodiment. It is a flowchart which shows the process sequence of the game control apparatus 50 at the time of carrying out the evolution synthesis | combination of the card character in the card battle game in this embodiment. It is a flowchart which shows the process sequence of the game control apparatus 50 when a robot battle generate | occur | produces in the card battle game in this embodiment. 5 is a flowchart illustrating a processing procedure of battle parameter setting processing executed by a parameter setting unit 53. It is a flowchart which shows the process sequence of the robot battle effect image generation process performed by the game control part. It is a flowchart which shows the process sequence of the robot battle effect image generation process performed by the game control part. It is a figure which shows an example of the data structure of the guild management information stored in the storage part. It is a figure which shows an example of the data structure of the configuration item information stored in the storage part. It is a figure which shows an example of the data structure of the acquisition structure item information stored in the storage part. 4 is a diagram illustrating an example of a data structure of level management information stored in a storage unit 42. FIG. It is a flowchart which shows the process sequence of the guild event generation process performed by the game control apparatus 50 which concerns on this embodiment. It is a flowchart which shows the process sequence of the guild event management process performed by the game control apparatus 50 which concerns on this embodiment.

  Embodiments of the present invention will be described below with reference to the drawings.

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

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

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

  For example, a smartphone, a feature phone, a tablet terminal, or the like can be used as the communication terminal 20, and the model-specific hardware configuration, the OS that is used, the installed application programs, and the like are diverse. To do.

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

  The game control apparatus 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 in the present embodiment, the user can perform a battle (battle) with an enemy character such as a non-player character (NPC) by combining a plurality of card characters owned by the user via the communication terminal 20. it can. Moreover, in the card battle game in the present embodiment, a mechanism for playing in cooperation with a plurality of users is provided as will be described later.

  In addition, the card battle game in this embodiment shall be implement | achieved by the web application which operate | moves on the game control apparatus (web server) 50, and is utilized for the web browser of the communication terminal 20. FIG.

FIG. 2 is a block diagram mainly showing a functional configuration of the game control device 50 shown in FIG.
As shown in FIG. 2, the game control device 50 includes a card management unit 51, a deck construction unit 52, a parameter setting unit 53, and a game control unit 54. In the present embodiment, each of these units is realized by the computer 10 illustrated in FIG. 1 executing a 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. The program 41 may be downloaded to the computer 10 via the network 30.

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

  The card management unit 51 has a function of giving various card characters and items used in the card battle game to a user playing the card battle game in accordance with the progress of the card battle game. It is assumed that a parameter is set in advance for the card character given by the card management unit 51 (that is, the card character owned by the user). The card management unit 51 has a function of managing card characters and items (information related to) owned by the user.

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

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

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

  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 and the like. .

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

  Further, the game control unit 54 generates an event (hereinafter referred to as a guild event) for playing in cooperation with a group called a guild composed of a plurality of users. When this guild event occurs, a plurality of users constituting the guild can obtain various benefits (for example, card characters, 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 performs parameter management information (hereinafter referred to as card parameter management information) including parameters set in advance for various card characters used in the card battle game described above and robot characters. Parameter management information including parameters set in advance (hereinafter referred to as robot parameter management information) is stored in advance. When a new card character, robot character, or the like is added as a new game element of the card battle game, the parameter management information stored in the storage unit 42 is updated.

  Further, the storage unit 42 relates to guild management information (group management information) indicating a guild composed of a plurality of users as described above, information related to a guild event, card characters and items owned by a user playing a card battle game, and the like. Information and information about the user are stored.

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

  As shown in FIG. 3, the card parameter management information includes HP (hit points), attack power, speed, and skill (parameters) in association with the card ID. The card ID is an identifier for identifying a card character. The HP is a numerical value of damage that the card character identified by the card ID can withstand the attack of the enemy character. In addition, when HP becomes 0, it becomes impossible to fight, for example, and it is defeated in a battle. The attack power is a numerical value of the ability related to the attack on the enemy character, and affects the damage given to the enemy character. The speed is a numerical value that affects, for example, the order of attack in the battle with the enemy character. The skill generates a predetermined effect in the battle with the enemy character, and includes, for example, an attack skill, a defense skill, a pre-battle skill, and the like as described later.

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

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

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

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

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

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

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

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

  In the card battle game in the present embodiment, as shown in FIG. 4, for example, three types of robot characters (robot characters identified by robot IDs “1” to “3”) are prepared in advance, and the card It is assumed that the robot character selected by the user at the time of initial registration to the battle game is given to the user. Thereby, the user can perform the robot battle described above in the card battle game in the present embodiment. Note that each of the three types of robot characters shown in FIG. 4 is advantageous for one of the other two attributes, for example, depending on the attribute of the robot character. May have characteristics 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 described. Details of other information will be described later.

  Hereinafter, with reference to the flowchart of FIG. 5, the flow (main cycle) of the card battle game in this embodiment will be schematically described. In the card battle game according to the present embodiment, for example, a user (player) seeks to obtain a rare card (character and item) or the like by searching for a search target (such as a planet) called a chapter. . Note that quests are set in advance in 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.

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

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

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

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

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

  If the user does not give an instruction to end the card battle game (NO in step S6), the process returns to step S1 described above, and the user can search (select) a new chapter.

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

  According to the card battle game in the present embodiment, by clearing each chapter described above, the game is progressed, and a card having a higher rarity value can be obtained.

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

  When the quest is started as described above, the game control unit 54 included in the game control device 50 generates an event corresponding to the quest (step S11). Events that occur in the quest include, for example, experience values for improving the level of the user (card characters owned by the user, etc.) by searching for chapters, in-game currency and various cards (characters and items that can be used in the card battle game) ) And the like, and battle events for performing battles with enemy characters in the quest are included. It is assumed that experience points, in-game currency, and various cards can be obtained even when an enemy character is won in a battle event.

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

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

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

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

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

  In the card battle game according to the present embodiment, one of a plurality of card characters owned by the user (hereinafter referred to as a base card character) is used as a card character other than the base card character (hereinafter referred to as a composite card character). ), The base card character can be evolved (strengthened).

  Here, with reference to the flowchart of FIG. 7, the process procedure of the game control apparatus 50 at the time of carrying out the evolution | combination synthesis | combination of a card character in the card battle game in this embodiment is demonstrated.

  In this case, the game control unit 54 included in the game control device 50 displays a list of a plurality of card characters owned by the user on the communication terminal 20. 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 in accordance with a user operation (step S21).

  Furthermore, the user can select a composite 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 points related to the evolution of the base card character (hereinafter referred to as evolution point) in accordance with, for example, parameters set for the synthetic card character (step S23). It is assumed that the evolution points of the 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 whether or not the evolution point of the base card character has reached a predetermined value (hereinafter referred to as a prescribed value) for the base card character (that is, MAX). (Step S24).

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

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

  On the other hand, when it is determined that the evolution point of the base card character has not reached the specified value (NO in step S24), the process in step S25 is not executed. In this case, the increased evolution point of the base card character is 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. Thus, for example, it is possible to prompt the user to consume the same card character in order to evolve a card character with a high rare value, so that a card character with a high rare value can be easily given to a user (that is, a rare character character). Can increase the probability of discharging high value cards). In addition, a card character (base card character) in which the above-described evolution point is difficult to reach a predetermined value is set, and the card character can be acquired only when winning a specific enemy character (for example, a raid boss described later). By being able to do so, it is possible to encourage the player to fight with the specific enemy character over and over, thereby expanding the play range of the card battle game.

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

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

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

  The deck constructing unit 52 constructs the user's deck using the selected five card characters and the robot character owned by the user (step S32). Hereinafter, the robot character included in the deck constructed by the deck construction unit 52 is referred to as a deck robot character 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 a robot battle start instruction is given by the user in response to a user operation on the communication terminal 20 (step S34). Note that the user can issue a robot battle start instruction 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 the above-described step S31 and is repeated.

  On the other hand, when it is determined that a robot battle start instruction has been issued (YES in step S34), the game control unit 54 executes the robot battle effect image generation process described above (step S35). In this robot battle effect image generation process, the robot battle is controlled based on the battle parameters set for the deck robot character in step S33 and the parameters set in advance for the enemy robot character in the robot battle. Then, 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, and the like of the enemy robot character as in the case of 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 a robot battle effect image is displayed in the card battle game, the communication terminal 20 automatically displays images representing the battle between the deck robot character and the enemy robot character in sequence, and finally the result of the robot battle ( That is, an image representing win / loss is displayed. In addition, it is 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, with reference to the flowchart of FIG. 9, the process sequence of the battle parameter setting process (the process of step S33 shown in FIG. 8) will be described. The battle parameter setting process is executed by the parameter setting unit 53 as described above.

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

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

  Although detailed description is omitted, the storage unit 42 identifies, for example, a robot ID and a card character for identifying a robot character owned by the user in association with a user ID for identifying the user. The information including the card ID and the like is stored (managed). In steps S41 and S42, the robot parameter management information and the card parameter management information can be acquired based on the robot ID and the card ID included in the information. it can.

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

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

  Here, the total value of the HP included in the robot parameter management information and the HP included in each of the card parameter management information has been described as being calculated as the HP included in the battle parameter. The configuration may be such that attribute correction is performed on the HP included in each. Specifically, although omitted in FIG. 3 described above, the card parameter management information includes an attribute of the card character identified by the card ID included in the card parameter management information, and the attribute of the card character is the deck. Depending on whether or not the attribute (the attribute of the deck robot character) included in the robot parameter management information matches, the HP included in the card parameter management information may be multiplied by the attribute correction value. 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 * attribute correction value included in the card parameter management information)”. The attribute correction value when the attribute of the card character matches the attribute of the deck robot character is a value larger than 1, and the attribute correction value when the attribute of the card character does not match the attribute of the deck robot character. Is 1. Thereby, when the user constructs the deck, the user selects the card character having the same attribute as the attribute of the robot character (deck robot character) possessed by the user, so that the HP (value) included in the battle parameter is increased. Can be high.

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

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

Here, although it has been described 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 parameter, the above-described HP As in the case of, for example, a configuration may be adopted in which attribute correction is performed for the attack power included in each of the card parameter management information.
Specifically, the card parameter management information includes an attribute of the card character identified by the card ID included in the card parameter management information, and the attribute of the card character includes an attribute (the deck robot character of the deck robot character). It is possible to adopt a configuration in which the attribute correction value is multiplied by the attack power included in the card parameter management information in accordance with whether or not the attribute matches. In this case, the attack power of the battle parameter is calculated by “the sum of attack power included in the robot parameter management information + (attack power included in the card parameter management information * attribute correction value)”. The attribute correction value when the attribute of the card character matches the attribute of the deck robot character is a value larger than 1, and the attribute correction value when the attribute of the card character does not match the attribute of the deck robot character. Is 1. Accordingly, the user can increase the attack power included in the battle parameter by selecting a card character having the same attribute as that of the robot character (deck robot character) owned by the user when the deck is constructed. Can do.

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

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

Here, the total value of the speed included in the robot parameter management information and the speed included in each of the card parameter management information has been described as being calculated as the speed included in the battle parameter. As in the case of, for example, a configuration may be adopted in which attribute correction is performed for the speed included in each of the card parameter management information. Specifically, the card parameter management information includes an attribute of the card character identified by the card ID included in the card parameter management information, and the attribute of the card character includes an attribute (the deck robot character of the deck robot character). It is possible to adopt a configuration in which an attribute correction value is multiplied by the speed included in the card parameter management information depending on whether or not the attribute matches. In this case, the speed included in the battle parameter is calculated by “the sum of the speed included in the robot parameter management information + (speed included in the card parameter management information * attribute correction value)”.
The attribute correction value when the attribute of the card character matches the attribute of the deck robot character is a value larger than 1, and the attribute correction value when the attribute of the card character does not match the attribute of the deck robot character. Is 1. As a result, the user can select a card character having the same attribute as that of the robot character (deck robot character) owned by the user when constructing the deck, thereby increasing the speed (value) included in the battle parameter. Can be high.

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

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

  Note that, as described above, when attribute correction is performed on HP, attack power, and speed included in each of the card parameter management information, for example, the attributes of all the card characters match the attributes of the deck robot character. In special cases, it is possible to further improve the battle parameters (HP, attack power and speed) set for the deck robot character, and to combine the deck robot character with the card character. Accordingly, a special skill (for example, a combo skill) may be provided.

  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 character and the parameters set for the enemy robot character. The

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

  In the robot battle effect image generation process, the game control unit 54 determines the first attack and the second attack in the robot battle. In this case, the game control unit 54 is set for the speed and enemy robot character included in the battle parameters set for the deck robot character (hereinafter simply referred to as the deck robot character battle parameter). The speed included in the parameter (hereinafter simply referred to as the parameter of the enemy robot character) is compared, and the higher speed (parameter value) is determined as the first attack, and the lower one is determined as the second attack. Here, description will be made assuming 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 deck robot character battle parameters and the enemy robot character parameters include attack skills, defense skills, and pre-battle skills.

  The attack skill is activated when a robot character (deck robot character or enemy robot character) having the attack skill attacks, and within a predetermined period after the attack skill is activated, for example, its attack power This skill produces an effect that increases the value. The defensive skill is activated when a robot character (deck robot character or enemy robot character) having the defensive skill is defended (that is, when receiving an attack by the opponent), and a predetermined period after the defensive skill is activated. Among them, for example, it is a skill that produces an effect of reducing the attack power (parameter value) of the opponent in the robot battle. Pre-battle skills, like attack skills and defensive skills, have the effect of increasing their own attack power or lowering their opponent's attack power, but unlike attack skills and defensive skills, robot battles It is activated before the start of the battle (combat) in, and continues to produce the effect during the robot battle period. It is assumed that the activation timing and the activation probability are set in advance for each of these skills.

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

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

  On the other hand, when it is determined not to activate the first pre-battle skill (NO in step S51), the process in step S52 is not executed.

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

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

  On the other hand, when it is determined that the next pre-battle skill is not activated (NO in step S53), the process in step S54 is not executed.

Next, the game control unit 54 determines the attack of the first attack based on the activation probability set in the attack skill (hereinafter referred to as the first attack skill) of the skills included in the battle parameters of the deck robot character. It is determined whether or not the skill is activated (step S55).
When there are a plurality of first attack skills, it is determined whether or not the first attack skill is activated.

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

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

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

  Next, the game control unit 54 determines the defense of the subsequent attack based on the activation probability set in the defense skill (hereinafter referred to as the defense skill of the subsequent attack) among the skills included in the parameters of the enemy robot character. It is determined whether or not the skill is activated (step S58). In addition, when there are a plurality of defense skills for the subsequent attack, it is determined whether or not the defense skill is activated for each of the defense skills for the subsequent attack.

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

  On the other hand, when it is determined not to activate the defensive defense skill (NO in step S58), the process in step S59 is not executed.

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

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

  The damage calculated by the game control unit 54 is subtracted from the HP (parameter value) included in the parameter of the enemy robot character. As described above, when the image indicating that the attack of the deck robot character is avoided in step S60, the damage given to the enemy robot character is set to zero.

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

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

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

  If it is determined that the attack skill for the subsequent attack is to be activated (YES in step S62), the game control unit 54 generates an image (the attack skill activation image for the subsequent attack) representing the activation of the attack skill for the subsequent attack (step S62). S63). Further, the game control unit 54 reflects the effect caused by the attacking skill of the subsequent attack determined to be activated in the parameter (the attacking power included) of the enemy robot character.

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

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

Next, the game control unit 54 determines the defense of the first attack based on the activation probability set in the defense skill (hereinafter referred to as the first defense skill) of the skills included in the battle parameters of the deck robot character. It is determined whether or not the skill is activated (step S65).
When there are a plurality of first defense skills, it is determined whether or not the first defense skills are activated.

  If it is determined that the first defense skill is to be activated (YES in step S65), the game control unit 54 generates an image (first defense skill activation image) representing the activation of the first defense skill (step S66). In addition, the game control unit 54 reflects the effect produced by the first defense skill determined to be activated in the parameter (the attack power included) of the enemy robot character.

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

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

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

  The damage calculated by the game control unit 54 is subtracted from the HP (parameter value) included in the battle parameter of the deck robot character. As described above, when the image indicating that the attack of the enemy robot character is avoided is generated in step S67, the damage given to the deck robot character is set to zero.

  Next, the game control unit 54 determines whether or not the HP from which the damage is 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 equal to or less than 0 (NO in step S68), the remaining HP of the deck robot character is held in the game control unit 54, and the process returns to step S55 described above to repeat the process. It is. It should be noted that the damage calculated by the game control unit 54 in the subsequent processing is subtracted from the remaining HP of the deck robot character or enemy robot character held in the game control unit 54 as described above. That is, in the robot battle, the above-described processing from step S55 is 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 described above that the remaining HP of the enemy robot character is 0 or less, or if it is determined in step S68 that the remaining HP of the deck robot character is 0 or less, the game control unit 54 generates an image (win / loss image) representing the result (win / loss) of the robot battle (step S69). When 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 when the remaining HP of the deck robot character is determined to be 0 or less. An image indicating that the deck robot character has been defeated is generated.

  Next, the game control unit 54 generates each image generated in the above processing (first-stage pre-battle skill activation image, second-stage pre-battle skill activation image, first-stage attack skill activation image, first-stage attack effect image, Attack attack skill activation image, attack attack effect image, attack attack skill image of attack, attack attack image of attack next attack, attack skill activation image of attack, attack effect display image of win and loss image) By combining them so as to transition, a robot battle effect image for displaying the effect and result of the robot battle is generated (step S70).

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

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

  On the other hand, in the card battle game in the present embodiment, a mechanism (guild event) for playing cooperatively in a group (guild) composed of a plurality of users described above separately from the main cycle described in FIG. 5 described above. A sub-cycle including is provided. This guild event is assumed to occur (held) regularly.

  The guild event will be described below. The purpose of the guild event is to collect a plurality of constituent items constituting one item appearing in a card battle game by a plurality of users (guild members) constituting the guild in cooperation. When the guild satisfies a predetermined condition in this guild event, a plurality of users constituting 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, as information related to the guild event, guild management information (group management information), information about the guild event (hereinafter referred to as configuration item information), a card battle game The information regarding the card character, the item, etc. which the user who plays is stored, and the information regarding the user are stored. The information related to the card characters and items owned by the user who plays the card battle game includes the information related to the configuration items obtained by the user in the guild event (hereinafter referred to as “acquired”) together with the information related to the card characters and items owned by the user. And configuration item information). Further, the information about the user includes level management information for managing the level of the user in the card battle game.

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

  As shown in FIG. 12, the guild management information includes a user ID and a guild ID in association with each other. The user ID is an identifier for identifying a user who plays 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 illustrated in FIG. 12, the guild management information includes a user ID “user 1” and a guild ID “guild 1” in association with each other. The guild management information includes a user ID “user 2” and a guild ID “guild 1” in association with each other. This indicates that the user identified by the user IDs “user 1” and “user 2” belongs to the guild identified by the guild ID “guild 1”.

  Here, for 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 similarly manages guild management for other users who play card battle games. Information is stored.

  In the card battle game in the present embodiment, it is assumed that all users who play the card battle game belong to (join) any guild. Specifically, after a tutorial (explaining how to play) performed when playing a card battle game for the first time, the user is prompted to join an existing guild, and the user can join a designated 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 that requires the approval of the creator (leader) of the guild 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.
The configuration item information is information indicating configuration items collected in the guild event. The guild event in the present embodiment is such that, for example, a privilege can be obtained by collecting a plurality of pieces (configuration items) constituting one jewel in cooperation with the guild. It should be noted that a plurality of types of jewels to be collected at the guild event are prepared.

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

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

  In addition, the configuration item information includes a gem type “jewel B”, a piece ID “B1 to B6”, and an appearance probability “probability 2” in association with each other. According to this, the jewel B is composed of six pieces (hereinafter, referred to as pieces B1 to B6) identified by the piece ID “B1 to B6”, and the pieces B1 to B6 are “probability 2” in the card battle game. "Is shown to appear. For example, the jewel B is targeted to a medium level user (target), and the fragrances B1 to B6 are all in common and have a probability of being likely to appear in the medium level user (when playing). Here, the 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. The range of the intermediate level user can be changed as appropriate, but it is assumed that the user has a level of about 21 to 50, for example. In addition, the fragrances B1 to B6 may be made to appear with a low appearance probability to users other than the intermediate level user, or may not appear to users other than the intermediate level user.

  The configuration item information includes a gem type “jewel C”, a piece ID “C1 to C6”, and an appearance probability “probability 3” in association with each other. According to this, the jewel C is composed of six pieces of pieces identified by the piece ID “C1 to C6” (hereinafter referred to as pieces of pieces C1 to C6), and the pieces of pieces C1 to C6 are “probability 3” in the card battle game. "Is shown to appear. For example, the jewel C is intended for a high-level user (target), and the fragrances C1 to C6 are all common and have a probability of being likely to appear in a high-level user (when playing). Here, a high level user is a user with a high level in a card battle game. The range of high-level users can be changed as appropriate. For example, it is assumed that the level is about 51 or more. Further, the fragrances C1 to C6 may appear with a low appearance probability to users other than the high-level user, or may not appear to users other than the high-level user.

Furthermore, the type of jewel “Gem D”, the fragrance ID “D1 to D6”, and the appearance probability “D1, D2: probability 1, D3, D4: probability 2, D5, D6: probability 3” correspond to the configuration item information. It is included. According to this, the jewel D is composed of six pieces (hereinafter referred to as pieces D1 to D6) identified by piece ID “D1 to D6”, and pieces D1 and D2 have “probability 1”, pieces D3 and It is shown that D4 appears with “probability 2” and fragrances D5 and D6 appear with “probability 3”. The jewelry D is targeted for all users (that is, the above-described low-level user, medium-level user, and high-level user). Specifically, the probabilities that the fragrances D1 and D2 are likely to appear to a low-level user are set. The probabilities that the cutlery D3 and D4 are likely to appear in the middle level user are set.
The probabilities that the high-level users are likely to appear in the cutlery D5 and D6 are set. As described above, in the case of the jewel D, unlike other jewels, each of the plurality of pieces (fragrances D1 to D6) constituting the jewel D is given to a user in a different range of levels. Is set.

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

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

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

  Further, the obtained configuration item information includes the user ID “user 2” and the fragment ID “D4” in association with each other. According to this, it is indicated 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. However, the storage unit 42 also applies to other users to which the component item “Kakera” is assigned. Stores the obtained configuration item information.

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

  As shown in FIG. 15, the level management information includes a user ID and level information in association with each other. The 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 illustrated in FIG. 15, the level management information includes a user ID “user 1” and level information “5” in association with each other. This indicates that the level of the user identified by the user ID “user 1” is 5.

  The level management information includes a user ID “user 2” and level information “25” in association with each other. This indicates 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 similarly manages level management for other users who play card battle games. Information is stored.

  Note that the level of the user in the card battle game is improved according to the progress of the card battle game, the battle victory, and the like. As described above, when the level of the user in the card battle game is improved, the level management information (level information included 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 the present embodiment will be described. In this case, the game control device 50 executes guild event generation processing and guild event management processing.

  First, with reference to the flowchart of FIG. 16, the process procedure of the guild event generation process performed by the game control apparatus 50 according to the present embodiment will be described. This guild event generation process is a process for generating a guild event and providing a configuration item in the guild event to a user (player).

First, the game control unit 54 included in the game control device 50 generates a guild event for granting a configuration item (step S81). This guild event is generated periodically, for example. Specifically, the guild event is generated, for example, at 7 o'clock as a morning part, 12:00 as a day part, and 22:00 as a night part. In addition, the period during which the guild event occurs is notified to the user who is playing the card battle game via the communication terminal 20.
Hereinafter, a user who is playing a card battle game is referred to as a target user.

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

  In addition, a component item shall appear in various scenes at the time of playing the card battle game. Specifically, the constituent item appears during a quest in a card battle game or when various enemy characters (quest boss or enemy robot character) are won.

  That is, the game control unit 54, when the play situation of the target user's card battle game is a situation in which the configuration item can appear, causes the configuration item to appear based on the appearance probability according to the level of the target user described above. It is determined whether or not to make it.

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

  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, a user (level) to which the configuration item is likely to be assigned is set for each configuration item, and thus each configuration item is assigned to a user in a different range of levels. Will be.

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

  Here, the game control unit 54 determines whether or not a predetermined period (predetermined period) has elapsed after the occurrence of the guild event in step S81 (step S85). For example, one hour is set as the predetermined period.

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

  On the other hand, when it is determined that the predetermined period has not elapsed (NO in step S85), the guild event is continued, and the process returns to the above-described step S82 and is repeated. In other words, in the guild event in the present embodiment, a plurality of configuration items can be collected during the period in which the guild event occurs (that is, during the period after the guild event occurs and until it ends). Is possible.

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

  If it is determined in step S82 that, for example, a plurality of configuration items are caused to appear based on the appearance probability, an effect image that causes one of the plurality of configuration items to appear is displayed on the communication terminal 20. Alternatively, an effect image that causes a plurality of configuration items to appear may be displayed on the communication terminal 20. When an effect image that causes a plurality of configuration items to appear is displayed on the communication terminal 20, all of the plurality of configuration items may be given to the target user, or the target user is selected from among the plurality of configuration items. Only one of them may be given.

  Next, with reference to the flowchart of FIG. 17, the process sequence of the guild event management process performed by the game control apparatus 50 which concerns on this embodiment is demonstrated. This guild event management process is a process for managing configuration items given to a user during a period in which the guild event is generated, and granting a privilege in the guild event to the user.

  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 obtained configuration item information stored in the storage unit 42. A configuration item assigned to each of a plurality of users (guild members) constituting the guild (group) is specified (step S91).

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

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

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

  The game control unit 54 identifies the fragment identified by the fragment ID included in the acquired obtained configuration item information as the configuration item assigned to each of the plurality of users configuring the target guild.

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

  Next, the game control unit 54 has given all of the configuration items to the target guild based on the configuration item information obtained 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 described in detail with reference to FIG. 13 described above. For example, the pieces identified by the pieces ID “A1 to A6” in the obtained configuration item (six pieces constituting the jewel A). Is included, it is determined that all of the configuration items have been assigned. Further, when all of the pieces identified by each of the piece IDs “B1 to B6” (the six pieces constituting the jewel B) are included in the obtained component items, all of the component items are given. It is determined that Similarly, in the case where all of the pieces identified by each of the piece IDs “C1 to C6” (six pieces of pieces constituting the gem C) are included in the obtained constitution items, It is determined that it has been granted. Moreover, when all of the fragiles identified by each of the fragile IDs “D1 to D6” (six fragrances constituting the jewel D) are included in the obtained configuration items, all of the configuration items are given. It is determined that

  That is, in step S92, if all of the pieces constituting at least one (type) gem (that is, one set of six pieces) are present in the obtained configuration item, all of the configuration items are given. It is determined that

  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 according to the configuration item to which all of the configuration items have been granted (that is, the type of gemstone from which all the pieces are collected). And given to a plurality of users (guild members) constituting the target guild (step S93). A plurality of sets of configuration items are assigned (for example, all of the pieces identified by the piece ID “A1 to A6” and all pieces of the piece identified by the piece ID “D1 to D6” are assigned. ), A privilege is granted for each (configuration type) of the configuration item.

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

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

  Here, when the target guild collects all of the configuration items, a ranking point can be given to the target guild separately from the above-described benefits. Thus, the ranking points assigned to the target guild are aggregated for each predetermined period, and various privileges are given to a plurality of users constituting the target guild according to the total value of the ranking points. It can be configured. The ranking points are also given by robot battles other than during guild events. Thereby, even if it is a period when the guild event is not generated, it can be expected that each of the plurality of users constituting the target guild actively plays the card battle game in order to obtain the ranking points. The ranking points may be managed in the storage unit 42 for each guild, for example.

  Note that 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, a configuration item is assigned to each of a plurality of users constituting the guild (group) according to the operation of the user with respect to the communication terminal 20 used by the user. The obtained configuration item information indicating the configuration item assigned to each of the plurality of users is stored in the storage unit 42, and is indicated by the guild management information (group management information) based on the obtained configuration item information stored in the storage unit 42. If it is determined that all of a plurality of configuration items (one set of configuration items) have been granted to a plurality of users constituting the guild, and it is determined that all of the plurality of configuration items have been granted, the guild In a social game, a plurality of users cooperate to play by providing a privilege to a plurality of users constituting It is possible to provide a mechanism.

  Further, in the present embodiment, a guild is configured only by high-level users or low-level users, for example, by a configuration in which each of a plurality of configuration items indicated by configuration item information is given to users in different ranges of levels. Instead, it is possible to promote the construction of the guild regardless of the level or the like, and it is possible to provide a mechanism that can give all users an opportunity to obtain a privilege.

  In the present embodiment, a configuration is provided in which a privilege is granted when all of a plurality of configuration items are granted within a period in which the guild event is generated, and the obtained configuration item information is deleted when the period has elapsed. Because, if you do not collect all the configuration items during the period when the guild event is occurring, you can not get the benefits, for example, you configure the guild with users who have the same time period to play the card battle game It is possible to promote playing with more users in cooperation with each other. In the present embodiment, it is also possible to adopt a configuration in which a screen for explaining the characteristics of the guild (such as the main play time zones of the users who make up the guild) is displayed on the communication terminal 20. With such a configuration, since the user can join a more appropriate guild, it becomes possible to obtain more benefits in the guild, and continuous play of the card battle game can be expected.

  In the card battle game according to the present embodiment, the main cycle described in FIG. 5 and the sub cycle including the guild event are described. However, for example, one sub-cycle is included in the sub cycle. A mechanism for performing a robot battle with another user (hereinafter referred to as PvP) may be further included. Even in this PvP, the above-described ranking points and various benefits can be provided according to the result. Further, it is possible to adopt a configuration in which the configuration item in the present embodiment can be acquired from another user according to the result of this PvP.

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

  According to the raid boss event, for example, by making it easy to borrow a leader card of a user registered as a friend, motivation to increase friends in a card battle game can be given, and continuous play can be encouraged. In addition, by generating a raid boss event, it is possible to recognize the strength (that is, parameter) of another user's card character (leader card character) and to know the presence of a new card character, its parameters, and the like. . In addition, for a user who lent a leader card character to another user by a raid boss event, for example, a privilege such as a point used for acquiring a card character or an item in a card battle game is given.

  Also, in the case of a raid NPC event, each user constituting the guild individually performs a robot battle using his / her deck robot character, and the ranking points described above for the guild are determined according to the result of the robot battle. It is also possible to adopt a configuration to give. Moreover, when a raid robot battle is defeated in a raid NPC event, it can also be set as the structure which can make a rescue request with respect to another guild.

  Moreover, although the card battle game in this embodiment was demonstrated as what is implement | achieved by a web application, it was implement | achieved by the native application downloaded to the communication terminal (terminal device) 20, installed in the said communication terminal 20, and utilized. It doesn't matter.

  Note that the present invention is not limited to the above-described embodiment as it is, and can be embodied by modifying the constituent elements without departing from the scope of the invention in the implementation stage. Moreover, various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the embodiment. For example, some components may be deleted from all the components shown in the embodiment.

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

Claims (7)

A game control method that is executed by a game control device that is communicably connected to a plurality of communication terminals used by each of a plurality of users who play a game and has a storage unit that stores parameter values of the plurality of users. ,
Configuring a plurality of groups from the plurality of users and storing a first correspondence between the users and groups in the storage means;
In the game, for each group, proceeding with a first event that a plurality of users of the group cooperate to play;
For each of the plurality of users, updating the parameter value of the user to a larger value in response to the user progressing the game independently of other users;
In the first event, for each of the plurality of users, a different configuration item is given depending on which of the parameter values of the user is included in a plurality of different parameter ranges set in advance , Storing a second correspondence between the user and the configuration item in the storage means;
Advancing a second event in which the users battle each other independently of the group;
Causing one user who has played against each other in the second event to acquire the configuration item of the other user and updating the second correspondence relationship for the one user and the other user;
Determining whether or not a plurality of users configuring the group for each group possess a plurality of specific configuration items based on the second correspondence relationship;
Granting ranking points to a group determined to possess the plurality of specific configuration items;
A game control method comprising:   2. The game control method according to claim 1, wherein the game control device further executes a step of creating a new group to which the user belongs, in accordance with an instruction from the user's communication terminal, with the user as a group creator. .   The game control method according to claim 2, wherein the game control device further executes a step of joining a user approved by the creator of the group among the plurality of users to the new group. The game control device further executes a step of giving a privilege different from the ranking points to a plurality of users constituting a group determined to possess the plurality of specific configuration items. The game control method according to any one of claims 1 to 3 . In the step of proceeding with the first event, the game control device periodically generates the first event,
Each time the first event ends, the game control device further executes a step of updating the second correspondence relationship so that the plurality of users do not have the configuration item. Item 5. The game control method according to any one of Items 1 to 4 . In a game control device that is communicably connected to a plurality of communication terminals used by each of a plurality of users who play a game,
Storage means for storing a first correspondence between a user and a group to which the user belongs, a second correspondence between a user and a configuration item assigned to the user, and parameter values of the plurality of users;
Group forming means for forming a plurality of groups from the plurality of users;
A first advancing means for advancing a first event in which a plurality of users of the group cooperate to play in the game;
For each of the plurality of users, a first updating unit that updates the parameter value of the user to a larger value in response to the user progressing the game independently of other users;
Wherein a first event, for each of the plurality of users, first to impart different configuration item in accordance with either the parameter value of the user of the plurality of different parameter ranges from each other preset is included Means for providing
A second advancing means for advancing a second event in which the users battle each other independently of the group;
A second updating means for causing one user who competed with each other in the second event to acquire the configuration item of the other user and updating the second correspondence relationship for the one user and the other user;
A determination means for determining whether or not a plurality of users configuring the group for each group possess a plurality of specific configuration items based on the second correspondence relationship;
Second granting means for granting ranking points to the group determined to possess the plurality of specific configuration items;
A game control device comprising: It is a program executed by a computer of a game control device that is communicably connected to a plurality of communication terminals used by each of a plurality of users who play a game and has a storage unit that stores parameter values of the plurality of users. And the computer
Configuring a plurality of groups from the plurality of users and storing a first correspondence between the users and groups in the storage means;
In the game, for each group, proceeding with a first event that a plurality of users of the group cooperate to play;
For each of the plurality of users, updating the parameter value of the user to a larger value in response to the user progressing the game independently of other users;
In the first event, for each of the plurality of users, a different configuration item is given depending on which of the parameter values of the user is included in a plurality of different parameter ranges set in advance , Storing a second correspondence between the user and the configuration item in the storage means;
Advancing a second event in which the users battle each other independently of the group;
Causing one user who has played against each other in the second event to acquire the configuration item of the other user and updating the second correspondence relationship for the one user and the other user;
Determining whether or not a plurality of users configuring the group for each group possess a plurality of specific configuration items based on the second correspondence relationship;
Granting ranking points to a group determined to possess the plurality of specific configuration items;
A program characterized by having executed.

Images