Abstract:
A non-transitory computer readable recording medium has stored thereon instructions to be executed on a computer providing terminal devices ( 12 ) with a battle game in which users each operate a unit. The instructions cause the computer to perform the steps of: determining a unit parameter of each of a plurality of units, group information being associated with each unit and indicating a group, among a plurality of groups, to which the unit belongs; deploying the units on a field ( 23 ), divided into regions, in the battle game; varying the unit parameter of a first unit on the field based on the group information associated with the first unit and the group information associated with a second unit on the field ( 23 ), the second unit having a predetermined positional relationship with the first unit; and conducting a battle between the first unit and other units using the varied unit parameter.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    This application claims priority to and the benefit of Japanese Patent Application No. 2013-273252 filed Dec. 27, 2013, the entire contents of which are incorporated herein by reference. 
       TECHNICAL FIELD 
       [0002]    The present invention relates to a non-transitory computer readable recording medium storing instructions to be executed on a computer, to a game control method, to a server device, and to an information processing system that provide a battle game to a terminal device. 
       BACKGROUND ART 
       [0003]    Conventionally, in a battle game server, each user&#39;s deck is formed by a plurality of battle cards or the like stored for each user, and the battle game server allows a plurality of users to compete with each other based on a total value or the like of parameters such as attack strength, defense strength, and the like of the cards in the deck (for example, see Patent Literature 1 and 2). 
       CITATION LIST 
     Patent Literature 
       [0000]    
       
         Patent Literature 1: JP2008-220984A 
         Patent Literature 2: JP2000-325528A 
       
     
       SUMMARY OF INVENTION 
     Technical Problem 
       [0006]    In a conventional battle game server, however, the strength of a deck depends greatly on the number of cards the user holds. For example, it is difficult for a user who does not hold cards having high parameters to win against a deck formed only by cards having high parameters. Therefore, the result of a battle ends up being largely decided at the time the deck is formed, causing the user to lose interest in the game. 
         [0007]    The present invention has been conceived in light of these circumstances and provides a non-transitory computer readable recording medium storing instructions to be executed on a computer, a game control method, a server device, and an information processing system that can provide a battle game that dynamically varies parameters in accordance with game progress. 
       Solution to Problem 
       [0008]    A non-transitory computer readable recording medium according to the present invention has stored thereon instructions to be executed on a computer providing a battle game to a plurality of terminal devices, a plurality of users each operating a unit to battle in the battle game, the instructions causing the computer to perform the steps of: determining a unit parameter of each of a plurality of units, group information being associated with each unit and indicating a group, among a plurality of groups, to which the unit belongs; deploying the plurality of units on a field in the battle game, the field being divided into a plurality of regions; varying the unit parameter of a first unit on the field based on the group information associated with the first unit and the group information associated with a second unit on the field, the second unit having a predetermined positional relationship with the first unit; and conducting a battle between the first unit and other units using the varied unit parameter. 
         [0009]    In the non-transitory computer readable recording medium according to the present invention, in the step of varying the unit parameter, when the first unit and the second unit belong to the same group, the unit parameter of the first unit is preferably varied by being increased. 
         [0010]    In the non-transitory computer readable recording medium according to the present invention, in the step of varying the unit parameter, when the first unit and the second unit belong to different groups, the unit parameter of the first unit is preferably varied by being decreased. 
         [0011]    In the non-transitory computer readable recording medium according to the present invention, in the step of varying the unit parameter, when the first unit, the second unit, and a third unit that has been established as a target of attack by the first unit or that has established the first unit as a target of attack belong to different groups, and the second unit comprises a plurality of units, the unit parameter of the first unit is preferably varied by being decreased. 
         [0012]    In the non-transitory computer readable recording medium according to the present invention, the instructions preferably further cause the computer to perform the step of: upon receiving, from the terminal device of a user, an accompaniment request that designates another unit belonging to the same group as the unit operated by the user, causing the unit to act automatically so that on the field, the unit has the predetermined positional relationship with the other unit. 
         [0013]    In the non-transitory computer readable recording medium according to the present invention, the instructions preferably further cause the computer to perform the step of: retrieving, from the terminal device, deck information including identifiers of a plurality of game media, wherein the unit preferably includes a plurality of unit parameters, and in the step of determining the unit parameter, the plurality of unit parameters are preferably each determined based on a portion of the plurality of game media. 
         [0014]    In the non-transitory computer readable recording medium according to the present invention, one of a plurality of game medium attributes is preferably associated with each of the game media, and the instructions preferably further cause the computer to perform the steps of: receiving unit type information indicating a type of the unit from the terminal device; and increasing the unit parameters when the game medium attribute of any of the game media held by the user matches a predetermined game medium attribute corresponding to the type of the unit. 
         [0015]    In the non-transitory computer readable recording medium according to the present invention, the instructions preferably further cause the computer to perform the steps of: upon receiving, from the terminal device of a user, an accompaniment request that designates another unit belonging to the same group as the unit operated by the user, causing the unit to act automatically so that on the field, the unit has the predetermined positional relationship with the other unit, wherein in the step of varying the unit parameter, when the first unit and the second unit belong to the same group, the unit parameter of the first unit is preferably varied by being increased. 
         [0016]    In the non-transitory computer readable recording medium according to the present invention, the predetermined positional relationship is preferably a positional relationship such that the first unit is included in an attack range of the second unit, and in the step of varying the unit parameter, when the first unit, the second unit, and a third unit that has been established as a target of attack by the first unit or that has established the first unit as a target of attack belong to different groups, and the second unit comprises a plurality of units, the unit parameter of the first unit is preferably varied by being decreased. 
         [0017]    A game control method according to the present invention is used in a computer providing a battle game to a plurality of terminal devices, a plurality of users each operating a unit to battle in the battle game, the game control method comprising the steps of: determining a unit parameter of each of a plurality of units, group information being associated with each unit and indicating a group, among a plurality of groups, to which the unit belongs; deploying the plurality of units on a field in the battle game, the field being divided into a plurality of regions; varying the unit parameter of a first unit on the field based on the group information associated with the first unit and the group information associated with a second unit on the field, the second unit having a predetermined positional relationship with the first unit; and conducting a battle between the first unit and other units using the varied unit parameter. 
         [0018]    A server device according to the present invention is for providing a battle game to a plurality of terminal devices, a plurality of users each operating a unit to battle in the battle game, the server device comprising: means for determining a unit parameter of each of a plurality of units, group information being associated with each unit and indicating a group, among a plurality of groups, to which the unit belongs; means for deploying the plurality of units on a field in the battle game, the field being divided into a plurality of regions; means for varying the unit parameter of a first unit on the field based on the group information associated with the first unit and the group information associated with a second unit on the field, the second unit having a predetermined positional relationship with the first unit; and means for conducting a battle between the first unit and other units using the varied unit parameter. 
         [0019]    An information processing system according to the present invention is for executing a game, the information processing system comprising: a server device; and at least one terminal device, the server device comprising: means for determining a unit parameter of each of a plurality of units, group information being associated with each unit and indicating a group, among a plurality of groups, to which the unit belongs; means for deploying the plurality of units on a field in the battle game, the field being divided into a plurality of regions; means for varying the unit parameter of a first unit on the field based on the group information associated with the first unit and the group information associated with a second unit on the field, the second unit having a predetermined positional relationship with the first unit; and means for conducting a battle between the first unit and other units using the varied unit parameter, and the terminal device comprising: means for displaying the field. 
       Advantageous Effect of Invention 
       [0020]    According to the non-transitory computer readable recording medium, game control method, server device, and information processing system of the present invention, it is possible to provide a battle game that dynamically varies parameters in accordance with game progress. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0021]    The present invention will be further described below with reference to the accompanying drawings, wherein: 
           [0022]      FIG. 1  is a block diagram of a game system according to an embodiment of the present invention; 
           [0023]      FIG. 2  illustrates an example of the user information in  FIG. 1 ; 
           [0024]      FIG. 3  illustrates an example of a field on which units are deployed within the game; 
           [0025]      FIG. 4  illustrates an example of the information on cards in possession in  FIG. 2 ; 
           [0026]      FIG. 5  illustrates an example of the deck information in  FIG. 2 ; 
           [0027]      FIG. 6  illustrates an example of information associated with the unit type information in  FIG. 2 ; 
           [0028]      FIG. 7  is a flowchart illustrating operations of the game system in  FIG. 1 ; 
           [0029]      FIG. 8  illustrates an example of a game screen displayed on the display module in  FIG. 1 ; 
           [0030]      FIG. 9  illustrates an example of a game screen displayed on the display module in  FIG. 1 ; 
           [0031]      FIG. 10  is a flowchart illustrating operations of the game system in  FIG. 1 ; 
           [0032]      FIG. 11  is a flowchart illustrating operations of the game system in  FIG. 1 ; 
           [0033]      FIG. 12  illustrates operations of the game system in  FIG. 1 ; 
           [0034]      FIG. 13  is a flowchart illustrating operations of the game system in  FIG. 1 ; 
           [0035]      FIG. 14  illustrates an example of a game screen displayed on the display module in  FIG. 1 ; and 
           [0036]      FIG. 15  illustrates an example of a game screen displayed on the display module in  FIG. 1 . 
       
    
    
     DESCRIPTION OF EMBODIMENTS 
       [0037]    The following describes an embodiment of the present invention. 
         [0038]    First, an outline of the battle game according to the present embodiment is provided. The battle game according to the present embodiment has two battle modes: regular battle and group battle. The regular battle is a battle mode for a user to acquire game media (cards), game items, and the like by using individual game media that the user holds in order to battle an opponent or complete a mission (quest) within the game. In a regular battle, a user can also cooperate with another user to battle an enemy boss. A group battle is a real-time battle mode for multiple users whereby a user deploys a unit on a field within the game, the unit being formed with a plurality of game media acquired in regular battles, and operates the unit by taking actions such as moving and attacking in order to battle other units operated by a plurality of users. The game media are described here as being game cards, yet any media within the game may be used, such as characters, weapons, armor, items, or the like. 
         [0039]    In the battle game, a group battle takes place as a limited-time event, for example. During this group battle, each unit belongs to one of three groups, and victory or defeat is determined by group. The user may select the group to which the unit belongs, or the server may automatically select the group based on the user&#39;s status or cards in possession. A group battle ends after a predetermined time has elapsed from the start of the battle (for example, 30 minutes). The user can cause the unit to act once every predetermined time period (for example, 5 seconds). Therefore, the number of times a unit can act in a group battle is limited. The timing for causing units to act may be the same for all units that are participating in the group battle. During one action, the unit can either move or attack, for example. The user obtains points by attacking units of other groups or by capturing strongholds on the field. A stronghold has, for example, parameters similar to a unit, such as stamina, and is captured by the group that reduces the stamina of the stronghold to zero by attacking with a unit. At the end of the battle, the group that has captured the stronghold can obtain additional points. A plurality of strongholds may be arranged on the field. 
         [0040]    Victory or defeat in the group battle, as well as the game media, items, or the like provided as a reward are determined in accordance with the number of points obtained by the end of the battle. The user can also obtain game media, items, or the like arranged on the field by, for example, causing the unit to pick them up. The game media, items, or the like that the user obtains in the group battle may be usable not only in a group battle but also in a regular battle. 
         [0041]    Next, a game system including a server device according to an embodiment of the present invention is described. As illustrated in  FIG. 1 , a game system  10  includes a server device  11  and a plurality of terminal devices  12 . The server device  11  and the terminal devices  12  can communicate with each other over a network  13 . 
         [0042]    The server device  11  includes a server communication module  14 , a memory module  15 , a unit type information retrieval module  16 , a deck information retrieval module  17 , a unit parameter determination module  18 , a unit deployment module  19 , a unit parameter variation module  20 , and a server control module  21 . 
         [0043]    The server communication module  14  exchanges information with the terminal devices  12 . 
         [0044]    The memory module  15  stores user information  22 . The user information  22  is information unique to a user and includes a variety of information used for progress of the game. For example as illustrated in  FIG. 2 , the user information  22  includes a plurality of unit parameters, information on cards in possession, deck information, unit type information, and group information, all associated with a user ID, which is the identifier of the user. 
         [0045]    The unit parameters are parameters indicating characteristics of the unit, such as HP, AT, DF, movement range, and attack range. HP, AT, and DF respectively indicate the stamina (hit points), attack strength, and defense strength of the unit. For a unit deployed on the game field, which is divided into a plurality of squares (regions), the movement range and attack range respectively indicate the range in which the unit can move during one action (movement) and the range in which the unit can attack during one action (attack). For example, the field  23  illustrated in  FIG. 3  is divided into 21 vertical squares by 21 horizontal squares and contains nine subfields that each include 7 vertical squares by 7 horizontal squares. 
         [0046]    The information on cards in possession in  FIG. 2  is information on all of the cards of which the user is in possession.  FIG. 4  illustrates the content of the information on cards in possession (for example, “information on cards in possession 001”). For example, the information on cards in possession includes a plurality of card parameters (game medium parameters) and card attribute information (game medium attribute information), all associated with a card ID, which is the identifier of a card the user has in possession. The card parameters are parameters indicating the strength of an individual card and for example include HP, AT, and DF. The card attribute information indicates the card attribute (game medium attribute) that a card has among a plurality of card attributes, such as “order”, “nothing”, “chaos”, “adjacent”, “distant”, and “flight”. The card attribute information is used in the below-described process to determine the unit parameters. In the present embodiment, there are six card attributes, “card attribute 1” through “card attribute 6”, yet two or more card attributes are sufficient. 
         [0047]    The deck information in  FIG. 2  is information including, among all of the cards held by the user, a plurality of cards that the user has selected or that have been automatically selected.  FIG. 5  illustrates the content of the deck information (for example, “deck information 001”). For example, the deck information includes card IDs, a plurality of card parameters, and card attribute information all associated with a unit parameter. 
         [0048]    In the deck information illustrated in  FIG. 5 , a portion of the plurality of cards included in the deck is associated with each unit parameter. For example, three cards (card IDs “card 01” through “card 03”) are associated with the HP of the unit. Three cards (card IDs “card 04” through “card 06”) are associated with the AT of the unit. Finally, three cards (card IDs “card 07” through “card 09”) are associated with the DF of the unit. 
         [0049]    The unit type information in  FIG. 2  is information indicating the unit type, such as “foot soldier”, “archer”, “cavalry”, or the like. The user selects the unit type at the start of the battle from among a plurality of unit types. In the present embodiment, there are three unit types, yet two or more unit types are sufficient. For example as illustrated in  FIG. 6 , the movement range, attack range, and specialty card attribute corresponding to each unit type are determined in advance. 
         [0050]    For a unit deployed on the field  23 , the movement range and attack range listed in  FIG. 6  respectively indicate the range in which the unit can move during one action (movement) and the range in which the unit can attack during one action (attack). During one action, the unit can either move or attack. For example, a unit that is of “unit type 1” can, during one action, move one square or attack a unit that is one square away. A unit that is of “unit type 2” can, during one action, move one square or attack a unit that is three squares away. A unit that is of “unit type 3” can, during one action, move two squares or attack a unit that is two squares away. 
         [0051]    Each specialty card attribute indicates a predetermined card attribute. For example, the specialty card attributes associated with “unit type 1” are “card attribute 1” and “card attribute 2”. The specialty card attributes associated with “unit type 2” are “card attribute 3” and “card attribute 4”. The specialty card attributes associated with “unit type 3” are “card attribute 5” and “card attribute 6”. The specialty card attributes are used in the below-described process to determine the unit parameters. 
         [0052]    The group information listed in  FIG. 2  is information indicating, for example, a group to which the user and the user&#39;s unit belong among a plurality of groups (types) in the game and is determined when the user begins the game. The group information is used in the process to vary the unit parameters described below. In the present embodiment, there are three groups, “group A”, “group B”, and “group C”, yet two or more groups are sufficient. 
         [0053]    The unit type information retrieval module  16  in  FIG. 1  retrieves the unit type information from the terminal device  12 . The unit type information retrieval module  16  stores the retrieved unit type information in the memory module  15  as a portion of the user information  22 . 
         [0054]    The deck information retrieval module  17  retrieves the deck information received from the terminal device  12 . The deck information retrieval module  17  stores the retrieved deck information in the memory module  15  as a portion of the user information  22 . 
         [0055]    Based on the retrieved unit type information and deck information, the unit parameter determination module  18  performs a process to determine the unit parameters of the unit. 
         [0056]    For example, the unit parameter determination module  18  determines the values of the movement range and the attack range of the unit listed in  FIG. 2  to be the values of the movement range and the attack range, listed in  FIG. 6 , that correspond to the unit type indicated by the retrieved unit type information. 
         [0057]    The unit parameter determination module  18  also determines the HP, AT, and DF of the unit listed in  FIG. 2  based on a portion of the cards, among the plurality of cards included in the deck information, associated with each of these parameters. 
         [0058]    In greater detail, based on the cards respectively associated with the plurality of unit parameters in the deck information, the unit parameter determination module  18  calculates the total of the card parameters corresponding to each of the plurality of unit parameters. For example, the unit parameter determination module  18  calculates the HP of the unit as the total HP of the three cards (card IDs “card 01” through “card 03”) associated with the HP of the unit in the deck information illustrated in  FIG. 5 . Similarly, the unit parameter determination module  18  calculates the AT and DF of the unit respectively as the total AT and total DF. 
         [0059]    Next, when the card attribute of a card included in the deck information matches a predetermined card attribute, i.e. the specialty card attribute, corresponding to the unit type indicated by the unit type information, the unit parameter determination module  18  increases the unit parameters. For example, when the retrieved unit type information is “unit type 1”, four cards included in the deck information illustrated in  FIG. 5  (card IDs “card 01”, “card 02”, “card 07”, and “card 08”) match the specialty card attributes corresponding to “unit type 1” in  FIG. 6  (“card attribute 1” or “card attribute 2”). In this case, the unit parameter determination module  18  increases the HP and DF of the unit associated with the four cards. The unit parameters are increased by, for example, adding a predetermined value or multiplying by a predetermined factor. 
         [0060]    The unit parameter determination module  18  determines the HP, AT, and DF of the unit to be the totals or increased totals calculated as described above. 
         [0061]    The unit deployment module  19  in  FIG. 1  deploys the unit for which the unit parameters have been determined on the field  23  in the game at the start of a group battle. The position, on the field  23  at which the unit is deployed at the start of the group battle may differ for each group to which units belong, or all units may be deployed in the same position. Alternatively, when a user logs out and then restarts the game, the unit may be redeployed at the same position as when the user logged out. 
         [0062]    During a battle, the unit parameter variation module  20  executes a process to vary the unit parameters of a first unit on the field  23  dynamically based on the group information associated with the first unit and the group information associated with a second unit on the field  23 , the second unit having a predetermined positional relationship with the first unit. For example, the unit parameter variation module  20  varies the unit parameters of the first unit on the field  23  by increasing or decreasing the unit parameters when the second unit is positioned in an adjacent square to the first unit on the field  23 . The increase or decrease in the unit parameters is determined based on the group information associated with each of a plurality of units. For example, when the second unit positioned in the adjacent square belongs to the same group as the first unit, the unit parameters of the first unit are increased. On the other hand, when the second unit positioned in the adjacent square belongs to a different group than the first unit, the unit parameters of the first unit are decreased. The unit parameters are increased or decreased by, for example, adding or subtracting a predetermined value or multiplying by a predetermined factor. Details on the process to vary the unit parameters are provided below. 
         [0063]    The server control module  21  controls the overall operations of the server device  11 . For example, when the number of users participating in the group battle reaches at least a predetermined number, i.e. when the number of units for which the unit parameters are determined reaches at least a predetermined number, the server control module  21  begins a process to conduct a group battle. The server control module  21  may also begin the process to conduct a group battle when the number of units of users belonging to each group reaches at least a predetermined number. During the process to conduct a battle, upon receiving an action request from a user via the terminal device  12 , the server control module  21  causes a user&#39;s unit to act based on the action request. Furthermore, during the process to conduct a battle, upon receiving an accompaniment request that designates a unit other than a user&#39;s unit from the user via the terminal device  12 , the server control module  21  causes the user&#39;s unit to act automatically by following the other unit so that the user&#39;s unit has a predetermined positional relationship with the other unit, for example by causing the user&#39;s unit to move to a square adjacent to the other unit. 
         [0064]    The terminal device  12  includes a terminal communication module  24 , a display module  25 , and a terminal control module  26 . 
         [0065]    The terminal communication module  24  exchanges information with the server device  11 . 
         [0066]    The display module  25  is, for example, configured using a touch panel, displays a variety of game screens, and functions as an interface to receive user input by user operation. 
         [0067]    The terminal control module  26  controls the overall operations of the terminal device  12 . For example, based on user input received by the display module  25 , the terminal control module  26  generates the unit type information, deck information, action requests, and accompaniment requests for the unit, transmitting these to the server device  11  via the terminal communication module  24 . The action request is a request for causing the unit to execute an action selected by the user during the battle. The accompaniment request is a request to cause the user&#39;s unit to act automatically during the battle by following another unit designated by the user so that the user&#39;s unit has a predetermined positional relationship with the other unit, for example by causing the user&#39;s unit to move to a square adjacent to the other unit. Based on screen display instructions received from the server device  11 , the terminal control module  26  displays a variety of game screens on the display module  25 . 
         [0068]    Process to Determine Unit Parameters 
         [0069]    Next, the process to determine the unit parameters in the game system  10  is described with reference to the flowchart in  FIG. 7 . 
         [0070]    First, the server control module  21  of the server device  11  transmits an instruction to display a screen to select the unit type to the terminal device  12  via the server communication module  14  (step S 100 ). 
         [0071]    Next, upon receiving the instruction in step S 100 , the terminal control module  26  of the terminal device  12  controls the display module  25  to display the screen to select the unit type (step S 101 ) and receives a user operation to select the unit type. For example, the screen to select the unit type illustrated in  FIG. 8  displays three unit types (“unit type 1” through “unit type 3”), unit type descriptions  27   a ,  27   b , and  27   c  that indicate the corresponding specialty card attributes, and select buttons  28   a ,  28   b , and  28   c  corresponding to the unit types. The user selects the user type by tapping one of the select buttons  28   a ,  28   b , and  28   c.    
         [0072]    Subsequently, the terminal control module  26  of the terminal device  12  transmits unit type information indicating the unit type that the user selected in step S 101  to the server device  11  via the terminal communication module  24  (step S 102 ). 
         [0073]    Next, the unit type information retrieval module  16  of the server device  11  retrieves the unit type information transmitted in step S 102  (step S 103 ) and stores the unit type information in the memory module  15  as a portion of the user information  22 . 
         [0074]    Subsequently, the server control module  21  of the server device  11  transmits an instruction to display a deck formation screen to the terminal device  12  via the server communication module  14  (step S 104 ). 
         [0075]    Next, upon receiving the instruction in step S 104 , the terminal control module  26  of the terminal device  12  controls the display module  25  to display the deck formation screen (step S 105 ) and receives a user operation to form the deck using a plurality of cards. For example, the deck formation to screen illustrated in  FIG. 9  displays a deck formation region  29  ( 29   a ,  29   b ,  29   c ), unit parameter information  30   a ,  30   b , and  30   c , and a participate button  31 . The user can place a maximum of nine cards in the deck formation region  29  and has placed “card 01” through “card 09” in  FIG. 9 . The unit parameter information  30   a ,  30   b , and  30   c  is displayed near the deck formation regions  29   a ,  29   b , and  29   c  and indicates the unit parameter (HP, AT, and DF) associated with the corresponding cards placed in the deck formation regions  29   a ,  29   b , and  29   c . After placing cards, the user completes deck formation by tapping the participate button  31 . 
         [0076]    Subsequently, the terminal control module  26  of the terminal device  12  transmits deck information indicating the plurality of cards deployed by the user in step S 105  to the server device  11  via the terminal communication module  24  (step S 106 ). 
         [0077]    Next, the deck information retrieval module  17  of the server device  11  retrieves the deck information transmitted in step S 106  (step S 107 ) and stores the deck information in the memory module  15  as a portion of the user information  22 . 
         [0078]    Subsequently, based on the unit type information retrieved in step S 103 , the unit parameter determination module  18  of the server device  11  determines the movement range and the attack range of the unit (step S 108 ). 
         [0079]    Subsequently, based on the cards respectively associated with the plurality of unit parameters in the deck information retrieved in step S 107 , the unit parameter determination module  18  of the server device  11  calculates the unit parameters by calculating the total of the card parameters corresponding to each of the plurality of unit parameters (step S 109 ). 
         [0080]    Subsequently, the unit parameter determination module  18  of the server device  11  judges whether the card attribute of any of the cards included in the deck information retrieved in step S 107  matches the specialty card attribute corresponding to the unit type indicated by the unit type information retrieved in step S 103  (step S 110 ). When the card attribute does not match for any of the cards included in the deck information (step S 110 : No), the process proceeds to step S 112 . 
         [0081]    Conversely, when the card attribute matches for at least one card (step S 110 : Yes), the unit parameter determination module  18  increases the unit parameters calculated in step S 109  (step S 111 ). The parameters are increased by, for example, an increase of 10 points or an increase of 10%. 
         [0082]    After step S 111 , or when the card attribute does not match for any of the cards included in the deck information in step S 110  (step S 110 : No), the unit parameter determination module  18  determines the unit parameters to be the total values calculated in step S 109  or the total values increased in step S 111  (step S 112 ). 
         [0083]    Process to Vary the Unit Parameters 
         [0084]    Next, the process to vary the unit parameters in the server device  11  is described. 
         [0085]    Referring to the flowchart in  FIG. 10 , the case of a first unit that is the target of unit parameter variation and a second unit differing from the first unit is described. 
         [0086]    First, the unit parameter variation module  20  judges whether the second unit is positioned in a square adjacent to the first unit (step S 200 ). When the second unit is not positioned in an adjacent square (step S 200 : No), the process terminates. 
         [0087]    Conversely, when the second unit is positioned in an adjacent square (step S 200 : Yes), the unit parameter variation module  20  judges whether the first unit and the second unit belong to the same group (step S 210 ). 
         [0088]    When the group is the same in step S 201  (step S 201 : Yes), the unit parameter variation module  20  varies the unit parameters of the first unit by increasing the unit parameters (step S 202 ). The parameters are increased by, for example, an increase of 10 points or an increase of 10%. 
         [0089]    Conversely, when the group is different in step S 201  (step S 201 : No), the unit parameter variation module  20  varies the unit parameters of the first unit by decreasing the unit parameters (step S 203 ). The parameters are decreased by, for example, a decrease of 10 points or a decrease of 10%. 
         [0090]    Next, referring to the flowchart in  FIG. 11 , the case of a first unit that is the target of unit parameter variation, a plurality of second units differing from the first unit, and a third unit that has been established as a target of attack by the first unit or that has established the first unit as a target of attack is described. 
         [0091]    First, the unit parameter variation module  20  judges whether the plurality of second units is positioned in squares adjacent to the first unit (step S 300 ). When the plurality of second units is not positioned in adjacent squares (step S 300 : No), the process terminates. 
         [0092]    Conversely, when the plurality of second units is positioned in adjacent squares (step S 300 : Yes), the unit parameter variation module  20  judges whether the first unit, the plurality of second units, and the third unit belong to different groups (step S 301 ). When the first through third units do not belong to different groups (step S 301 : No), the process terminates. 
         [0093]    Conversely, when the first through third units belong to different groups in step S 301  (step S 301 : Yes), the unit parameter variation module  20  varies the unit parameters of the first unit by decreasing the unit parameters (step S 302 ). The parameters are decreased by, for example, a decrease of 10 points or a decrease of 10%. 
         [0094]    The steps in the above-described process to vary the unit parameters are executed in combination. For example, the following concretely describes the circumstances illustrated in  FIG. 12 , in which a plurality of units A 2 , A 3 , B 2 , C 1 , C 2 , C 3 , and C 4  (for example, second units) are positioned in squares adjacent to unit A 1  (for example, a first unit) that is attacking unit B 1  (for example, a third unit), which is the target of attack. The codes A, B, and C for the units indicate the groups A, B, and C to which the units belong. 
         [0095]    In this case, the unit parameters for unit A 1 , for example, vary due to the presence of units A 2 , B 2 , C 3 , and C 4  positioned in squares adjacent to unit A 1 . Specifically, due to the presence of a unit (unit A 2 ) belonging to the same group (group A) as unit A 1 , the parameters are expected to increase once, for example by an increase of 10 points or an increase of 10%. Due to the presence of a unit (unit B 2 ) belonging to a different group (group B) than group A 1 , the parameters are expected to decrease once, for example by a decrease of 10 points or a decrease of 10%. Furthermore, since there are a plurality of units (units C 3 , C 4 ) belonging to a different group (group C) than both unit A 1  and unit B 1 , the parameters are expected to decrease once, for example by a decrease of 10 points or a decrease of 10%. Accordingly, by increasing once and decreasing twice, the unit parameters of unit A 1  end up being decreased once, for example by a decrease of 10 points or a decrease of 10%, and unit A 1  attacks unit B 1  in this decreased state. 
         [0096]    Process to Conduct a Battle 
         [0097]    Next, the process to conduct a battle in the game system  10  is described with reference to the flowchart in  FIG. 13 . 
         [0098]    First, the server control module  21  of the server device  11  transmits an instruction to display a battle screen to the terminal device  12  via the server communication module  14  (step S 400 ). 
         [0099]    Next, upon receiving the instruction in step S 400 , the terminal control module  26  of the terminal device  12  controls the display module  25  to display the battle screen (step S 401 ) and receives a user operation to select an action for the unit. For example, in the battle screen illustrated in  FIG. 14 , three squares  32   a ,  32   b , and  32   c  to which the user can move the unit A 1 , another unit B 1  that the unit A 1  can attack, and another unit A 2  that the unit A 1  can accompany are all displayed flashing. The user selects whether to move, attack, or accompany by tapping one of the flashing squares  32   a ,  32   b , and  32   c  to which the unit A 1  can move or one of the other flashing units. It is assumed that the user selects the destination of movement by tapping the flashing square  32   b  to which the unit A 1  can move. 
         [0100]    Subsequently, the terminal control module  26  of the terminal device  12  generates an action request to move the unit A 1  to the destination designated by the user in step S 401  and transmits the action request to the server device  11  via the terminal communication module  24  (step S 402 ). 
         [0101]    Next, upon receiving the action request transmitted in step S 402 , the server control module  21  of the server device  11  performs the action (movement) indicated in the action request on the unit A 1  (step S 403 ). 
         [0102]    Subsequently, the server control module  21  of the server device  11  transmits an instruction to update the battle screen to the terminal device  12  via the server communication module  14  (step S 404 ). 
         [0103]    Next, upon receiving the instruction in step S 404 , the terminal control module  26  of the terminal device  12  controls the display module  25  to update the battle screen (step S 405 ) and receives a user operation to select an action for the unit A 1 . For example, in the battle screen illustrated in  FIG. 15 , four squares  33   a ,  33   b ,  33   c , and  33   d  to which the user can move the unit A 1  and another unit A 2  that the unit A 1  can accompany are all displayed flashing. The user selects whether to move or accompany by tapping one of the flashing squares  33   a ,  33   b ,  33   c , and  33   d  to which the unit A 1  can move or the flashing unit A 2 . It is assumed that the user designates a unit for the unit A 1  to accompany by tapping the unit A 2 . 
         [0104]    Subsequently, the terminal control module  26  of the terminal device  12  generates an accompaniment request to cause the unit A 1  to accompany the other unit A 2  designated by the user in step S 405  and transmits the accompaniment request to the server device  11  via the terminal communication module  24  (step S 406 ). 
         [0105]    Upon receiving the accompaniment request transmitted in step S 406 , the server control module  21  of the server device  11  controls the unit A 1  to act automatically so that the unit A 1  moves to a square adjacent to the other unit A 2  indicated in the action request (step S 407 ). 
         [0106]    In this way, the server device  11  in the present embodiment varies the unit parameters in accordance with the positional relationship between a plurality of units on the field  23 , thereby allowing for dynamic variation of the unit parameters in accordance with units moving on the field  23 . Furthermore, since the game becomes more strategic by users cooperating, the game also becomes more interesting. 
         [0107]    In accordance with the group information associated with each unit, the server device  11  determines whether to increase or decrease the unit parameters being varied. For example, since the unit parameters are increased when a plurality of units belonging to the same group are adjacent to each other, even a user who does not hold cards with high card parameters can actively participate. Hence, the user&#39;s interest in the game can be enhanced. 
         [0108]    Since the unit parameters are decreased when, for example, a unit belonging to another group is adjacent, it becomes important for a plurality of users belonging to the same group to cooperate, thereby encouraging communication between users. 
         [0109]    When a first through a third unit belonging to different groups are present, the second unit, for example, can take sides with either the first unit or the third unit that are attacking each other. If a plurality of second units are adjacent to the first unit, it is very probable that the second units will side with the third unit and attack the first unit. In this case, the server device  11  reduces the unit parameters of the first unit, thereby reflecting the intention of the user operating the second unit who wishes to take sides with the third unit. 
         [0110]    Upon receiving an accompaniment request from the terminal device  12 , the server device  11  causes the user&#39;s unit to act automatically so that the user&#39;s unit has a predetermined positional relationship with the other unit indicated in the accompaniment request, for example by causing the user&#39;s unit to move to a square adjacent to the other unit. It is thus possible to maintain an increase in the unit parameters via the process to vary the unit parameters by having the user&#39;s unit automatically follow another unit even when, for example, the user is away from the terminal device  12  (when the user cannot participate in the game), thereby enhancing user-friendliness. A user whose unit is being accompanied may also find game operations to be more satisfying, since in addition to the user&#39;s own unit, the user is also in charge of operating another user&#39;s unit. 
         [0111]    During the process to determine the unit parameters, the server device  11  determines each of a plurality of unit parameters of the unit based on a portion of a plurality of cards included in the deck information. This increases the occasions for using a card that is not frequently used in a regular battle, in which individual cards are used, due to the card parameters being unbalanced, such as the HP being high yet the AT and DF being extremely low. The user&#39;s interest in the game can thus be enhanced. 
         [0112]    The server device  11  increases the unit parameters when the card attribute of a card included in the deck information matches a predetermined card attribute (specialty card attribute) corresponding to the unit type indicated by the unit type information. Since the user can thus increase unit strength by appropriately selecting the unit type, it is possible to make the game more interesting. 
         [0113]    Although the present invention has been described based on drawings and examples, it is to be noted that various changes and modifications will be apparent to those skilled in the art based on the present disclosure. Therefore, such changes and modifications are to be understood as included within the scope of the present invention. For example, the functions and the like included in the various units and steps may be reordered in any logically consistent way. Furthermore, units or steps may be combined into one or divided. 
         [0114]    For example, in the above embodiment, the deck information includes information on a plurality of cards, yet the deck information may be configured to include only card IDs of a plurality of cards. 
         [0115]    The field  23  may, for example, be divided into hexagons. Alternatively, the field  23  may be a three-dimensional space. 
         [0116]    In the above embodiment, the unit parameter variation module  20  varies the unit parameters of a unit in accordance with the presence of another unit positioned in the square adjacent to the unit, yet the other unit is not limited to being in an adjacent square. The unit parameters may be varied in accordance with the presence of another unit having a predetermined positional relationship with a certain unit. For example, in addition to when a unit is present in an adjacent square, the parameter may be varied when another unit is present within the attack range of a unit, when a plurality of units in a predetermined formation are present on the field  23 , or when a plurality of units surround a stronghold on the field  23 . 
         [0117]    In the above embodiment, the unit parameter variation module  20  determines whether to increase or decrease the unit parameters based on group information associated with each of a plurality of units, yet an increase or decrease in the unit parameters may be determined regardless of the group information. For example, an ally or enemy may be judged based on a unit&#39;s activity history, with the unit parameters being increased in the case of an ally and decreased in the case of an enemy. 
         [0118]    A computer may be suitably used to function as the server device  11 . A program containing the processing for achieving the functions of the server device  11  is stored in the memory module  15  of the computer, and the functions are achieved by the central processing unit (CPU) of the computer reading and executing the program. 
       REFERENCE SIGNS LIST 
       [0000]    
       
         
           
               10 : Game system 
               11 : Server device 
               12 : Terminal device 
               13 : Network 
               14 : Server communication module 
               15 : Memory module 
               16 : Unit type information retrieval module 
               17 : Deck information retrieval module 
               18 : Unit parameter determination module 
               19 : Unit deployment module 
               20 : Unit parameter variation module 
               21 : Server control module 
               22 : User information 
               23 : Field 
               24 : Terminal communication module 
               25 : Display module 
               26 : Terminal control module 
               27   a ,  27   b ,  27   c : Unit type description 
               28   a ,  28   b ,  28   c : Select button 
               29 ,  29   a ,  29   b ,  29   c : Deck formation region 
               30   a ,  30   b ,  30   c : Unit parameter information 
               31 : Participate button 
               32   a ,  32   b ,  32   c : Square to which a unit can move 
               33   a ,  33   b ,  33   c ,  33   d : Square to which a unit can move