Patent Document

CROSS-REFERENCE TO RELATED APPLICATIONS 
     This is a Continuation of application Ser. No. 14/445,652 filed Jul. 29, 2014, which claims priority to and the benefit of Japanese Patent Application No. 2013-158440 filed Jul. 31, 2013, and Japanese Patent Application No. 2014-42978 filed Mar. 5, 2014, the entire contents of which are incorporated herein by reference. 
     TECHNICAL FIELD 
     The present invention relates to a non-transitory computer readable recording medium, a game server, a game control method, and a game system. 
     BACKGROUND ART 
     As a video game using an information processing device such as a computer, a battle game has been proposed to allow a user to fight an opponent by controlling a player character in the game (for example, see Patent Literature 1). In such a battle game, a turn-based combat system is used, and the user battles by selecting a command during each turn to determine the action of the player character. 
     CITATION LIST 
     Patent Literature 
     Patent Literature 1: JP 2007-075612 A 
     SUMMARY OF INVENTION 
     Technical Problem 
     In a conventional battle game, however, during one battle, the user needs to select a command to determine the action of the player character many times, which may make operation troublesome. 
     The present invention has been conceived in light of the above circumstances, and it is an object thereof to provide a non-transitory computer readable recording medium, a game server, a game control method, and a game system that make the user operation in a battle game less troublesome. 
     Solution to Problem 
     A non-transitory computer readable recording medium according to the present invention for solving the above problems is a non-transitory computer readable recording medium having stored thereon instructions to be executed on a computer providing a battle game to a communication terminal, the instructions causing the computer to perform the steps of: storing a battle history including an identifier of an opponent with whom a user has battled in the battle game; determining, based on the battle history and on an identifier of an opponent with whom a battle begins, a procedure for conducting the battle in the battle game to be one of a first mode for conducting the battle based on user operations and a second mode for conducting the battle with fewer user operations than in the first mode; and conducting the battle with the determined procedure. 
     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: when the identifier of the opponent with whom the battle begins matches the identifier of the opponent included in the battle history, causing the communication terminal to display a mode selection screen allowing the user to select between the first mode and the second mode; receiving a user operation via the mode selection screen; and determining the procedure for conducting the battle in accordance with the user operation that is received; and when the identifier of the opponent with whom the battle begins does not match the identifier of the opponent included in the battle history, determining the procedure for conducting the battle to be the first mode. 
     In the non-transitory computer readable recording medium according to the present invention, the battle history preferably further includes win-loss information on the user for each opponent with whom the user has battled, and the instructions preferably further cause the computer to perform the steps of: when the identifier of the opponent with whom the battle begins matches an identifier that is included in the battle history and that identifies an opponent against whom the user has won, causing the communication terminal to display a mode selection screen allowing the user to select between the first mode and the second mode; receiving a user operation via the mode selection screen; and determining the procedure for conducting the battle in accordance with the user operation that is received; and when the identifier of the opponent with whom a battle begins does not match an identifier that is included in the battle history and that identifies an opponent against whom the user has won, determining the procedure for conducting the battle to be the first mode. 
     In the non-transitory computer readable recording medium according to the present invention, the battle history preferably further includes win-loss information on the user for each opponent with whom the user has battled, and the instructions preferably further cause the computer to perform the steps of: when the identifier of the opponent with whom the battle begins matches an identifier that is included in the battle history and that identifies an opponent against whom the user has won, calculating a predicted result of the battle in the second mode; and before determining the procedure for conducting the battle, causing the communication terminal to display information in accordance with the predicted result. 
     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: when the predicted result is more adverse for the user than a predetermined standard and the user has selected the second mode on the mode selection screen, causing the communication terminal to display a confirmation screen for the user to confirm selection of the second mode. 
     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: when conducting the battle in the second mode, storing a battle log indicating content of the battle; and displaying a battle log screen to present the battle log to the user. 
     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: when the user wins the battle, determining a winning reward in accordance with the procedure for conducting the battle; and providing the determined winning reward to the user. 
     A non-transitory computer readable recording medium according to the present invention is a non-transitory computer readable recording medium having stored thereon instructions to be executed on a computer providing a battle game to a communication terminal, the instructions causing the computer to perform the steps of: causing the communication terminal to display at least one of i) information in accordance with a battle result when a battle is conducted in a second mode for conducting the battle with fewer user operations than in a first mode for conducting the battle based on user operations, and ii) information indicating that an opponent is an opponent with whom a user has battled before; causing the communication terminal to display a mode selection screen allowing the user to select between the first mode and the second mode; determining a procedure for conducting the battle to be the first mode or the second mode in accordance with a user operation received via the mode selection screen; and conducting the battle with the determined procedure. 
     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: when the battle result for conducting the battle in the second mode is more adverse for the user than a predetermined standard and the user has selected the second mode on the mode selection screen, causing the communication terminal to display a confirmation screen for the user to confirm selection of the second mode. 
     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: when conducting the battle in the second mode, storing a battle log indicating content of the battle; and displaying a battle log screen to present the battle log to the user. 
     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: when the user wins the battle, providing the user with a winning reward determined in accordance with the procedure for conducting the battle. 
     A game server according to the present invention is a game server for providing a battle game to a communication terminal, the game server comprising: a storage unit configured to store a battle history including an identifier of an opponent with whom a user has battled in the battle game; a procedure determination unit configured to determine, based on the battle history and on an identifier of an opponent with whom a battle begins, a procedure for conducting the battle in the battle game to be one of a first mode for conducting the battle based on user operations and a second mode for conducting the battle with fewer user operations than in the first mode; and a control unit configured to conduct the battle with the determined procedure. 
     A game server according to the present invention is a game server for providing a battle game to a communication terminal, the game server comprising: a server control unit configured to cause the communication terminal to display at least one of i) information in accordance with a battle result when a battle is conducted in a second mode for conducting the battle with fewer user operations than in a first mode for conducting the battle based on user operations, and ii) information indicating that an opponent is an opponent with whom a user has battled before, and to cause the communication terminal to display a mode selection screen allowing the user to select between the first mode and the second mode; and a procedure determination unit configured to determine a procedure for conducting the battle to be the first mode or the second mode in accordance with a user operation received via the mode selection screen, wherein the server control unit conducts the battle with the determined procedure. 
     A game control method according to the present invention is a game control method used in a game server for providing a battle game to a communication terminal, the game control method comprising the steps of: storing a battle history including an identifier of an opponent with whom a user has battled in the battle game; determining, based on the battle history and on an identifier of an opponent with whom a battle begins, a procedure for conducting the battle in the battle game to be one of a first mode for conducting the battle based on user operations and a second mode for conducting the battle with fewer user operations than in the first mode; and conducting the battle with the determined procedure. 
     A game control method according to the present invention is a game control method used in a game server for providing a battle game to a communication terminal, the game control method comprising the steps of: causing the communication terminal to display at least one of i) information in accordance with a battle result when a battle is conducted in a second mode for conducting the battle with fewer user operations than in a first mode for conducting the battle based on user operations, and ii) information indicating that an opponent is an opponent with whom a user has battled before; causing the communication terminal to display a mode selection screen allowing the user to select between the first mode and the second mode; determining a procedure for conducting the battle to be the first mode or the second mode in accordance with a user operation received via the mode selection screen; and conducting the battle with the determined procedure. 
     A game system according to the present invention is a game system comprising a communication terminal and a game server for providing a battle game to the communication terminal, the game server storing a battle history including an identifier of an opponent with whom a user has battled in the battle game; determining, based on the battle history and on an identifier of an opponent with whom a battle begins, a procedure for conducting the battle in the battle game to be one of a first mode for conducting the battle based on user operations and a second mode for conducting the battle with fewer user operations than in the first mode; and conducting the battle with the determined procedure. 
     A game system according to the present invention is a game system comprising a communication terminal and a game server for providing a battle game to the communication terminal, the game server causing the communication terminal to display at least one of i) information in accordance with a battle result when a battle is conducted in a second mode for conducting the battle with fewer user operations than in a first mode for conducting the battle based on user operations, and ii) information indicating that an opponent is an opponent with whom a user has battled before; causing the communication terminal to display a mode selection screen allowing the user to select between the first mode and the second mode; determining a procedure for conducting the battle to be the first mode or the second mode in accordance with a user operation received via the mode selection screen; and conducting the battle with the determined procedure. 
     Advantageous Effect of Invention 
     The non-transitory computer readable recording medium, game server, game control method, and game system according to the present invention can make the user operation in a battle game less troublesome. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
       The present invention will be further described below with reference to the accompanying drawings, wherein: 
         FIG. 1  is a block diagram of a game system according to an embodiment of the present invention; 
         FIGS. 2( a ) and 2( b )  illustrate an example of the user data in  FIG. 1 ; 
         FIGS. 3( a ) and 3( b )  illustrate an example of the opponent database in  FIG. 1 ; 
         FIG. 4  illustrates an example of the battle history in  FIG. 1 ; 
         FIG. 5  illustrates an example of the battle log in  FIG. 1 ; 
         FIGS. 6( a ) and 6( b )  illustrate an example of a mode selection screen according to an embodiment of the present invention; 
         FIG. 7  illustrates an example of a confirmation screen according to an embodiment of the present invention; 
         FIG. 8  illustrates an example of an auto mode rendering screen according to an embodiment of the present invention; 
         FIG. 9  illustrates an example of a battle result screen according to an embodiment of the present invention; 
         FIG. 10  illustrates an example of a battle log screen according to an embodiment of the present invention; 
         FIG. 11  illustrates an example of a reward attainment screen according to an embodiment of the present invention; 
         FIG. 12  illustrates an example of a manual mode battle screen according to an embodiment of the present invention; 
         FIG. 13  is a flowchart illustrating operations of a game server according to an embodiment of the present invention; and 
         FIG. 14  is a flowchart illustrating operations of a communication terminal according to an embodiment of the present invention. 
     
    
    
     DESCRIPTION OF EMBODIMENTS 
     The following describes an embodiment of the present invention. 
       FIG. 1  is a block diagram of a game system according to an embodiment of the present invention. The game system according to the present embodiment includes a game server  1  and a plurality of communication terminals  2 . For the sake of simplicity, only one communication terminal  2  is illustrated in  FIG. 1 . The game server  1  transmits a battle game to the communication terminal  2 . In the explanation below, a user in this game forms a deck from a maximum of  12  cards by combining cards within the game. Each card has a command determining an action of the player character controlled by the user. The user battles with an enemy character, i.e. an opponent, by selecting a card included in the deck as a command to determine the action of the player character. A battle takes place when a predetermined battle event occurs within the game, such as when the player character encounters an enemy. 
     The game server  1  includes a server communication unit  10 , a storage unit  11 , a procedure determination unit  12 , an auto mode processing unit  13 , a winning reward determination unit  14 , and a server control unit  15 . 
     The server communication unit  10  communicates with the communication terminal  2  over either or both of a wireless and wired connection. 
     The storage unit  11  stores user data  110 , an opponent database (DB)  111 , a battle history  112 , and a battle log  113 . 
     With reference to  FIGS. 2( a ) and 2( b ) , the user data  110  is described. The user data  110  ( 110   a,    110   b ) is unique information for each user and includes a variety of information necessary to play the battle game. 
     As illustrated in  FIG. 2( a ) , the user data  110   a  includes the parameters “level”, “experience”, “maximum deck cost”, and “money” in association with a “user ID” that uniquely identifies a user. The user data  110   a  may also include information such as a list of cards or a list of game items held by the user. 
     The “user ID” may be a character string, a player character name that the user freely sets, or the like that can uniquely identify a user. The “level” is a parameter indicating the degree of development of the player character within the game. A higher numerical value for the level indicates a higher degree of development. “Experience” is a parameter that contributes to an increase in level and increases in accordance with progress in the game, battles, and the like. When experience reaches 100%, the level rises, and experience is reset to 0%. The “maximum deck cost” is a parameter contributing to the degree of freedom for forming the deck. As described below, a “cost” is set for each card, and the user must form the deck so that the total cost of all the cards in the deck is equal to or less than the maximum deck cost. Accordingly, the maximum deck cost is the maximum value of the total cost of cards that can be included in the deck. The maximum deck cost increases as the level rises. “Money” is a parameter indicating the amount of game currency that the user has. Money increases in accordance with progress in the game, battles, and the like. 
     The user data  110   b  includes information on the deck that the user has formed. As illustrated in  FIG. 2( b ) , the user data  110   b  includes the following parameters for each card constituting the user&#39;s deck: “card ID”, “level”, “experience”, “evolution”, “cost”, “HP”, “ATK”, “command ID”, “command type”, and “activation/recovery turns”. 
     The “card ID” is information that can identify a card within the game and may be any character string, a character name depicted on the card, or the like that can uniquely identify a card. The “level” is a parameter indicating the degree of development of the card. A higher numerical value for the level indicates a higher degree of development. “Experience” is a parameter that contributes to an increase in level and increases in accordance with progress in the game, battles, and the like. “Evolution” is a parameter indicating the number of times that evolution is possible with a predetermined method such as synthesizing a card of the same type. “Evolution” is indicated as “current evolution level/final evolution level”. For example, if “evolution” is “⅓”, this indicates that evolution is possible two more times. “Cost” is a parameter indicating the cost necessary to include the card in the deck. “HP” is a parameter contributing to the hit points (HP) of the player character and increases in accordance with level and evolution. The maximum HP value for the player character is the total of the HP of each card in the deck. The player character&#39;s HP decreases when, for example, the player character is attacked by an opponent in a battle, and the player character loses the battle when HP reaches zero. “ATK” is a parameter contributing to the power of s player character actions via commands such as attack, recover, and the like. The power of a command increases as the ATK value is higher. The “command ID” is information that can identify a command that a card has and may, for example, be any character string or any command name that can uniquely identify a command. The “command type” is information indicating the type of the corresponding command. For example, command types include “attack”, which inflicts damage on an opponent, “recover”, which recovers the player character&#39;s HP, “assist”, which for example strengthens/weakens the player character/opponent, and the like. “Activation/recovery turns” is a parameter indicating the time required from when a card is selected at the start of the turn until the action due to the command is performed (number of turns to activation) and the time required from when the action due to the command is performed until the card can be selected again (number of turns to recovery). “Activation/recovery turns” is indicated as “number of turns to activation/number of turns to recovery”. For example, if the user starts a turn by selecting “card001” that includes “cmd01” for which the “activation/recovery turns” is “½”, the player character attacks the opponent with the command “cmd01” one turn after card selection, i.e. in the turn immediately after selection of the card. The user then cannot select “card001” again until two turns after selection of the card, i.e. until one more turn has passed after completion of the turn in which the player character attacks with the command “cmd01”. Note that a turn is an opportunity for the player character and the opponent to act. At the start of a turn, the user selects a card to determine the action of the player character, and the turn progresses. When the player character and all of the opponents that can act in a turn have acted, or when there is no player character nor opponent who can act in the turn, then the turn finishes, and a new turn begins. 
     Next, with reference to  FIGS. 3( a ) and 3( b ) , the opponent database  111  is described. The opponent database  111  ( 111   a,    111   b ) includes a variety of information related to the enemy characters that become opponents. 
     As illustrated in  FIG. 3( a ) , the opponent database  111   a  includes the parameters “level”, “HP”, “ATK”, “command ID”, “command type”, and “activation/recovery turns” in association with an “enemy character ID” that can uniquely identify an enemy character. Since these parameters are the same as the card parameters described for the user data  110   b,  a description thereof is omitted. An enemy character may have a plurality of commands, for example as “enemy002” does. When the enemy character has a plurality of commands, one of the commands is automatically selected, and the enemy character acts. 
     As illustrated in  FIG. 3( b ) , the opponent database  111   b  includes combinations of enemy character IDs that appear as opponents in association with “opponent sets”. Specifically, at the start of a battle in the game, one of the opponent sets is selected from the opponent database  111   b  to determine the opponent. For example, when “set01” is selected as the “opponent set”, three of “enemy001” appear as opponents. In other words, the “opponent set” is an identifier indicating a combination of enemy characters that constitute the opponent(s). 
     Next, with reference to  FIG. 4 , the battle history  112  is described. The battle history  112  is information related to opponents with whom the user has battled in the past. Specifically, in association with a user ID, the battle history  112  includes “battled opponent sets”, i.e. the opponent sets (identifiers) of opponents with whom the user has battled in the past, and includes win-loss information on the user for each battled opponent set. For example, in  FIG. 4 , “user001” has won against opponents corresponding to “set01” and “set02”, and the win-loss information indicates “win”. Furthermore, “user001” has not won against the opponent corresponding to “set03”, and the win-loss information indicates “loss”. Next, “user002” has won against the opponent corresponding to “set02”, and the win-loss information indicates “win”. On the other hand, “user002” has not won against the opponent corresponding to “set03”, and the win-loss information indicates “loss”. Furthermore, “user002” has not battled against the opponent corresponding to “set01”, and hence “set01” is not included in the “battled opponent set”. 
     Next, with reference to  FIG. 5 , the battle log  113  is described. The battle log  113  is information indicating the content of a battle when the battle is conducted in the below-described auto mode. Specifically, the battle log  113  includes a “turn number”, “acting character”, and “content of action”. The battle log  113  may be temporarily stored in the storage unit  11  and erased after completion of the battle process. 
     The “turn number” indicates each turn that occurred from the start to the end of a battle. The “acting character” indicates the ID of each player character and enemy character that acted in the turn indicated by the turn number. The “content of action” indicates the result of the action taken by the corresponding acting character. For example,  FIG. 5  shows that in the “first turn”, “user001” attacked via “cmd01” and inflicted 1000 points of damage on “enemy001a”. Note that  FIG. 5  shows an example of the opponent being three of “enemy001”, differentiated from each other by being listed as “enemy001a”, “enemy001b”, and “enemy001c”. 
     The explanation now returns to  FIG. 1 . For each battle taking place in the game, the procedure determination unit  12  determines a procedure for conducting the battle to be either a manual mode (first mode) for conducting the battle based on user operations and an auto mode (second mode) for conducting the battle with fewer user operations than in the manual mode. Conducting the battle with fewer user operations than in the manual mode includes, for example, the cases of conducting the battle semi-automatically by omitting a portion of command selection by the user and conducting the battle automatically by omitting all command selection by the user. Specifically, at the start of a battle in the game, the procedure determination unit  12  looks up the opponent set selected as the opponent in the battle history  112 . The procedure determination unit  12  judges whether the opponent set matches a battled opponent set, included in the battle history  112 , for which the win-loss information is “win”, i.e. whether the user has battled the opponent in the past and won. When the opponent set matches a battled opponent set for which the win-loss information is “win”, i.e. when the user has won against the opponent in the past, then upon acquiring an input signal from the communication terminal  2 , the procedure determination unit  12  determines the procedure for conducting the battle based on the input signal. The input signal is for a user operation that the communication terminal  2  has received on the below-described mode selection screen  3  or confirmation screen  4 . On the other hand, when the opponent set does not match a battled opponent set for which the win-loss information is “win”, i.e. when the user has not won against the opponent in the past, then the procedure determination unit  12  determines the procedure for conducting the battle to be the manual mode and transmits an instruction to the communication terminal  2  to conduct the battle in manual mode. 
     The auto mode processing unit  13  performs a battle process in auto mode. Specifically, the auto mode processing unit  13  automatically controls the player character, selecting cards and attacking the opponent in accordance with a predetermined process. One possible predetermined process is, for example, to use only the cards included in the deck for which the command type is attack and to attack in order starting with the first enemy character. Any other process, however may be used. For example, when the recovery is turn becomes longer as the power of the command is higher, then the battle may be conducted by prioritizing use of cards having commands with a long recovery turn. Until the battle ends, i.e. until the HP of either every opponent or of the player character reaches zero, the auto mode processing unit  13  continues to attack and calculates the battle result. The battle result includes whether the battle was a win or a loss and the remaining HP of the player character. The auto mode processing unit  13  then stores the content of the battle in auto mode in the storage unit  11  as the battle log  113 . 
     Before the communication terminal  2  is caused to display the below-described mode selection screen  3 , i.e. before the user selects the procedure for conducting the battle, the auto mode processing unit  13  preferably performs the above-described process to calculate the battle result by auto mode as a predicted result. When the procedure determination unit  12  determines that the procedure for conducting the battle is auto mode, the auto mode processing unit  13  then determines the calculated predicted result to be the battle result of the battle. 
     When the player character wins the battle, the winning reward determination unit  14  determines a winning reward in the game and provides the winning reward to the user. Specifically, the winning reward determination unit  14  judges whether the user has won the battle based on the battle result calculated by the auto mode processing unit  13  or on the battle result acquired from the communication terminal  2 . When the user has won the battle, the winning reward determination unit  14  then determines the winning reward by a predetermined method and provides the winning reward to user. The winning reward determination unit  14  preferably determines the winning reward in accordance with the procedure for conducting the battle. For example, the winning reward for a battle in manual mode may be selected from a reward group with a higher value than the winning reward for a battle in auto mode. 
     The server control unit  15  controls the various operations of the game server  1  and the overall conduction of the game. 
     The server control unit  15  also determines the opponent with whom the user battles. Specifically, at the start of a battle in the game, the server control unit  15  selects an opponent set from the opponent database  111   b  and determines the selected opponent set to be the opponent. 
     Via the server communication unit  10 , the server control unit  15  transmits an instruction to the communication terminal  2  to display a variety of game screens. The variety of game screens include, for example, the below-described mode selection screen  3 , confirmation screen  4 , auto mode rendering screen  5 , battle result screen  6 , battle log screen  7 , reward attainment screen  8 , and manual mode battle screen  9 . 
     The communication terminal  2  is provided with a terminal communication unit  20 , a display unit  21 , an operation unit  22 , a manual mode processing unit  23 , and a terminal control unit  24 . 
     The terminal communication unit  20  communicates with the game server  1  over either or both of a wireless and wired connection. 
     The display unit  21  outputs display pertaining to the game provided by the game server  1 . Specifically, the display unit  21  displays the below-described mode selection screen  3 , confirmation screen  4 , auto mode rendering screen  5 , battle result screen  6 , battle log screen  7 , reward attainment screen  8 , and manual mode battle screen  9 . Any type of display device may be used in the display unit  21 , such as a liquid crystal display, organic EL display, or the like. 
     The operation unit  22  receives user operations for the game. The operation unit  22  transmits an input signal in accordance with the received user operation to the terminal control unit  24 . Any input interface may be used in the operation unit  22 , such as a button, touch panel, or the like. In the following explanation, the operation unit  22  is assumed to be a touch panel. 
     The manual mode processing unit  23  performs a battle process in manual mode. Specifically, the manual mode processing unit  23  displays the below-described manual mode battle screen  9  on the display unit  21  and conducts the battle based on user operations. Once the battle ends, the manual mode processing unit  23  determines the battle result and transmits the battle result to the game server  1  via the terminal communication unit  20 . 
     The terminal control unit  24  controls the various operations of the communication terminal  2 . Also, upon acquiring an input signal from the operation unit  22  in accordance with a user operation received on one of the various screens displayed on the display unit  21 , the terminal control unit  24  transmits the input signal to the game server  1  via the terminal communication unit  20 . 
     Next, with reference to  FIGS. 6( a ) and 6( b ) , the mode selection screen  3  is described. The mode selection screen  3  is a screen for causing the user to select between the manual mode and the auto mode as the procedure for conducting the battle. At the start of a battle in the game, when the user has battled the opponent in the past, the mode selection screen  3  is displayed on the display unit  21  of the communication terminal  2 . 
     Information in accordance with the predicted result of the battle calculated by the auto mode processing unit  13  of the game server  1  is preferably displayed on the mode selection screen  3 . The information in accordance with the predicted result is information suggestive of the battle result when conducting the battle in auto mode. Specifically, as illustrated in  FIG. 6( a ) , when the predicted result for example corresponds to “can win with remaining HP of at least 80% and less than 100%”, then “You can easily win!” is the displayed information. On the other hand, if the predicted result corresponds to “can&#39;t win”, then “This is quite a tough opponent . . . ” is the displayed information. 
     As illustrated in  FIG. 6( b ) , the mode selection screen  3  includes a character icon  30 , message displaying area  31 , manual button  32 , and auto button  33 . 
     The character icon  30  is the image of a character that presents the information displayed in the message displaying area  31  to the user. 
     The message displaying area  31  is an area displaying a comment encouraging the user to select a procedure for conducting the battle and displaying information in accordance with the predicted result of the battle. Specifically, when for example the predicted result is “can win with at least 80% and less than 100% of HP remaining”, then “You&#39;ve battled this enemy before, and you can win easily! Which way will you fight?” is displayed in the message displaying area  31 . 
     The manual button  32  is an input interface that receives a user operation for selecting the manual mode as the procedure for conducting the battle. Once the user taps the manual button  32 , the display switches to the below-described manual mode battle screen  9 . 
     The auto button  33  is an input interface that receives a user operation for selecting the auto mode as the procedure for conducting the battle. Once the user taps the auto button  33 , the display switches to the below-described confirmation screen  4  or auto mode rendering screen  5 . 
     Next, with reference to  FIG. 7 , the confirmation screen  4  is described. The confirmation screen  4  is a confirmation screen for the user to confirm selection of the auto mode on the mode selection screen  3 . The confirmation screen  4  is displayed on the display unit  21  of the communication terminal  2  when the predicted result is more adverse for the user than a predetermined standard and the user has selected the auto mode on the mode selection screen  3 . The predetermined standard may be set freely by the game provider or the like and may, for example, be a standard value relating to the remaining HP of the player character after the battle. In this case, a predicted result that is advantageous for the user indicates that the remaining HP is at least the standard value. Conversely, a predicted result that is adverse for the user indicates that the remaining HP is less than the standard value. In this way, for example by setting the predetermined standard to be “remaining HP 50%”, the confirmation screen  4  is displayed when the remaining HP in the predicted result is less than 50% of the maximum HP and the user has selected auto mode on the mode selection screen  3 . 
     As illustrated in  FIG. 7 , the confirmation screen  4  includes a character icon  40 , a message displaying area  41 , a manual button  42 , and an auto button  43 . Since the character icon  40 , manual button  42 , and auto button  43  are respectively similar to the character icon  30 , manual button  32 , and auto button  33  in the mode selection screen  3 , a description thereof is omitted. 
     The message displaying area  41  is an area displaying a comment encouraging the user to confirm selection of auto mode on the mode selection screen  3  despite the fact that the predicted result is a battle result that is more adverse for the user than the predetermined standard. Specifically, “You don&#39;t stand a chance of winning this way . . . your only hope is to fight the battle yourself. Will you?” is displayed in the message displaying area  41 . 
     Next, with reference to  FIG. 8 , the auto mode rendering screen  5  is described. The auto mode rendering screen  5  is a screen presenting the user with a rendition of the battle in auto mode. The auto mode rendering screen  5  includes a displaying area  50  for the enemy character name, a displaying area  51  for enemy character images, and a displaying area  52  for the deck. 
     The displaying area  50  for the enemy character name is an area for displaying the enemy character ID of the enemy character that is the opponent and the number of that enemy character that appears. The displaying area  51  for enemy character images is an area for displaying the image of each enemy character that is the opponent. The displaying area  52  for the deck is an area for displaying images of the plurality of cards included in the user&#39;s deck. As a rendition of a battle in auto mode, the displaying area  52  for the deck moves towards the displaying area  51  for enemy character images. The displaying area  51  for enemy character images and the displaying area  52  for the deck then collide, and the entire screen turns white. Display then switches to the below-described battle result screen  6 . As compared to the rendition of a battle with the below-described manual mode battle screen  9 , the rendition of a battle with the auto mode rendering screen  5  has a shorter display time and is a simpler rendition. Hence, the processing load is smaller. 
     Next, with reference to  FIG. 9 , the battle result screen  6  is described. The battle result screen  6  is a screen presenting the user with the result of the battle in auto mode. The battle result screen  6  includes a displaying area  60  for the result, a displaying area  61  for the deck, a battle log button  62 , and a next button  63 . Since the displaying area  61  for the deck is similar to the displaying area  52  for the deck, a description thereof is omitted. 
     The displaying area  60  for the result is an area displaying whether the battle was won or lost.  FIG. 9  shows an example in which the user won the battle, and “WIN!!” is displayed in the displaying area  60  for the result. Conversely, when the user loses the battle, for example “LOSE . . . ” or the like may be displayed in the displaying area  60  for the result. 
     The battle log button  62  is an input interface for receiving a user operation to display the content of the battle in auto mode. Once the user taps the battle log button  62 , the display switches to the below-described battle log screen  7 . 
     The next button  63  is an input interface for receiving a user operation to switch from the battle result screen  6  to the next screen. Once the user taps the next button  63 , the display switches to the below-described reward attainment screen  8 . 
     Next, with reference to  FIG. 10 , the battle log screen  7  is described. The battle log screen  7  is a screen presenting the user with the battle log  113  that indicates the content of the battle in auto mode. The battle log screen  7  includes a displaying area  70  for the battle log and a close button  71 . 
     The displaying area  70  for the battle log is an area for displaying the battle log  113 . By the user swiping the displaying area  70  for the battle log up and down, the entire battle log  113  can be displayed by scrolling. 
     The close button  71  is an input interface for receiving a user operation to terminate display of the battle log screen  7 . Once the user taps the close button  71 , the display switches to the battle result screen  6 . 
     Next, with reference to  FIG. 11 , the reward attainment screen  8  is described. The reward attainment screen  8  is a screen presenting the user with the winning reward provided to the user when the user has won the battle. The reward attainment screen  8  includes a displaying area  80  for the reward and an OK button  81 . 
     The displaying area  80  for the reward is an area for displaying information related to the winning reward provided to the user. The information related to the winning reward includes, for example, an image of the game card or item that is the reward, a card ID or an item ID that can identify an item, and an acquisition count. By the user swiping the displaying area  80  for the reward up and down, the information relating to all of the winning rewards can be displayed by scrolling. 
     The OK button  81  is an input interface for receiving a user operation to terminate the battle process. Once the user taps the OK button  81 , the battle process terminates, and the display switches for example to the screen immediately before the start of a battle. 
     Next, with reference to  FIG. 12 , the manual mode battle screen  9  is described. The manual mode battle screen  9  is a screen for fighting a battle in manual mode. The manual mode battle screen  9  includes i) a field area  90   a  displaying a player character  91 , a displaying area  92  for player status, an enemy character  93  ( 93   a,    93   b,    93   c ), an enemy HP indicator  94  ( 94   a,    94   b,    94   c ), a number of enemy wait turns  95  ( 95   a,    95   b,    95   c ), and a target icon  96 , and ii) a displaying area  90   b  for the deck in which cards  97  ( 97   a,    97   b,    97   c,    97   d,    97   e ) are displayed.  FIG. 12  illustrates the state immediately before the start of a turn, i.e. the state of waiting for a user operation to determine the action of the player character  91 . 
     The field area  90   a  is an area for displaying graphics such as the player character  91 . The turn progresses once the user determines the action of the player character  91 , and a rendition is provided in the field area  90   a  in accordance with the action of the player character  91  and the like. 
     The player character  91  is a 2D or 3D graphic representing the player character that the user controls. The displaying area  92  for player status displays the remaining HP of the player character  91  numerically and with an indicator. 
     Each enemy character  93  ( 93   a,    93   b,    93   c ) is a 2D or 3D graphic representing an enemy character that is the opponent. Each enemy HP indicator  94  ( 94   a,    94   b,    94   c ) indicates the remaining HP of the corresponding enemy character  93 . The number of enemy wait turns  95  ( 95   a,    95   b,    95   c ) indicates the number of turns until the corresponding enemy character  93  acts next. The target icon  96  indicates the target that the player character  91  is attacking. The user can change the attack target by tapping an enemy character  93 . 
     The displaying area  90   b  for the deck is an area for displaying cards  97  included in the user&#39;s deck. By the user swiping the displaying area  90   b  for the deck to the left and right, the card  97  of every card included in the deck can be displayed. The displaying area  90   b  for the deck can preferably be minimized towards the bottom of the display screen. In this case, the entire manual mode battle screen  9  becomes the field area  90   a.    
     Each card  97  is displayed as a combination of a card image and an image indicating the command type of the command that the card has. At the start of each turn, the user selects one card from among selectable cards  97  to determine the action of the player character  91 . For example, in the state illustrated in  FIG. 12 , the card  97   a  is selected if the user drags the card  97   a  from the displaying area  90   b  for the deck into the field area  90   a.  The player character  91  then attacks the enemy character  93   a  with the command that the selected card  97   a  has. When a user cannot select a card  97 , such as during rendition of the battle, it is preferably made clear that the user cannot tap the cards  97  for example by darkening display of the cards  97 . 
     Next, with reference to  FIG. 13 , operations of the game server  1  according to the present embodiment are described. The flowchart in  FIG. 13  illustrates operations for a battle process performed by the game server  1 . This process begins when a predetermined battle event occurs, such as when the player character encounters an enemy. 
     First, the server control unit  15  determines the opponent with whom the user battles (step S 100 ). Specifically, the server control unit  15  selects an opponent set from the opponent database  111   b  and determines the selected opponent set to be the opponent. 
     Next, the procedure determination unit  12  judges whether the user has battled the opponent determined in step S 100  in the past and won (step S 101 ). Specifically, the procedure determination unit  12  looks up the opponent set determined in step S 100  in the battle history  112 . When the opponent set matches a battled opponent set that is included in the battle history  112  and for which the win-loss information is “win”, the procedure determination unit  12  judges that the user has won in the past (step S 101 : Yes), and the process proceeds to step S 102 . Conversely, when the opponent set does not match a battled opponent set that is included in the battle history  112  and for which the win-loss information is “win”, the procedure determination unit  12  judges that the user has not battled and won in the past (step S 101 : No), and the process proceeds to step S 110 . 
     In step S 101 , when determining that the user has won in the past (step S 101 : Yes), the auto mode processing unit  13  calculates the predicted result of the battle in auto mode (step S 102 ). 
     Next, the server control unit  15  transmits an instruction to the communication terminal  2  to display the mode selection screen  3  (step S 103 ). 
     Next, upon receiving from the communication terminal  2  an input signal for a user operation received on the mode selection screen  3 , the procedure determination unit  12  judges whether auto mode has been selected based on the input signal (step S 104 ). When auto mode has been selected (step S 104 : Yes), the process proceeds to step S 105 . Conversely, when manual mode has been selected (step S 104 : No), the process proceeds to step S 110 . 
     When auto mode has been selected in step S 104  (step S 104 : Yes), the server control unit  15  judges whether the predicted result of the battle calculated in step S 102  is more adverse for the user than a predetermined standard (step S 105 ). When the predicted result is more adverse than the predetermined standard (step S 105 : Yes), the process proceeds to step S 106 . Conversely, when the predicted result is at least the predetermined standard (step S 105 : No), the process proceeds to step S 108 . 
     When the predicted result is more adverse than the predetermined standard in step S 105  (step S 105 : Yes), the server control unit  15  transmits an instruction to the communication terminal  2  to display the confirmation screen  4  (step S 106 ). 
     Next, upon receiving from the communication terminal  2  an input signal for a user operation received on the confirmation screen  4 , the procedure determination unit  12  judges whether auto mode has been selected based on the input signal (step S 107 ). When auto mode has been selected (step S 107 : Yes), the process proceeds to step S 108 . Conversely, when manual mode has been selected (step S 107 : No), the process proceeds to step S 110 . 
     When the predicted result is at least the predetermined standard in step S 105  (step S 105 : No), or when auto mode has been selected in step S 107  (step S 107 : Yes), the auto mode processing unit  13  determines the predicted result calculated in step S 102  to be the battle result of the battle (step S 108 ). 
     Next, the server control unit  15  transmits an instruction to the communication terminal  2  to display the auto mode rendering screen  5  (step S 109 ). 
     Conversely, when judging in step S 101  that the user has not won in the past (step S 101 : No) or when manual mode is selected in step S 104  or step S 107  (step S 104 : No, step S 107 : No), the procedure determination unit  12  determines the procedure for conducting the battle to be manual mode and transmits an instruction to the communication terminal  2  to execute a battle process in manual mode (step S 110 ). 
     After step S 110 , the server control unit  15  waits until acquiring the battle result for manual mode from the communication terminal  2  (step S 111 ), and upon acquisition of the battle result, the process proceeds to step S 112 . 
     After step S 109  or step S 111 , the server control unit  15  transmits an instruction to the communication terminal  2  to display the battle result screen  6  (step S 112 ). 
     Next, the server control unit  15  waits until acquiring from the communication terminal  2  an input signal for a user operation received by the communication terminal  2  on the battle result screen  6  (step S 113 ). 
     Upon acquiring the input signal in step S 113 , the server control unit  15  then judges whether the input signal is an input signal via the battle log button  62  (step S 114 ). When the input signal is an input signal via the battle log button  62  (step S 114 : Yes), the process proceeds to step S 115 . On the other hand, when the input signal is an input signal via the next button  63  (step S 114 : No), the process proceeds to step S 116 . 
     When the input signal in step S 114  is an input signal via the battle log button  62  (step S 114 : Yes), the server control unit  15  transmits to the communication terminal  2  an instruction to display the battle log screen  7  (step S 115 ). The process then returns to step S 113  and continues. 
     On the other hand, when the input signal in step S 114  is an input signal via the next button  63  (step S 114 : No), the winning reward determination unit  14  judges whether the user has won the battle based on the battle result determined by the auto mode processing unit  13  in step S 108  (step S 116 ). When the user has won (step S 116 : Yes), the process proceeds to step S 117 . Conversely, when the user has lost (step S 116 : No), the present process terminates. 
     When the user has won in step S 116  (step S 116 : Yes), the winning reward determination unit  14  determines a winning reward and provides the winning reward to the user (step S 117 ). The winning reward determination unit  14  preferably determines the winning reward in accordance with the procedure for conducting the battle. 
     The server control unit  15  then transmits an instruction to the communication terminal  2  to display the reward attainment screen  8  (step S 118 ), and the process terminates. 
     Next, with reference to  FIG. 14 , operations of the communication terminal  2  according to the present embodiment are described. The flowchart in  FIG. 14  illustrates operations for a battle process performed by the communication terminal  2 . This process begins when a predetermined battle event occurs, such as when the player character encounters an enemy. 
     First, the terminal control unit  24  waits for an instruction from the game server  1  and judges whether an instruction to execute a battle process in manual mode has been received (step S 200 ). When an instruction for manual mode has been received (step S 200 : Yes), the process proceeds to step S 209 . Conversely, when an instruction for manual mode has not been received (step S 200 : No), the process proceeds to step S 201 . 
     When an instruction for manual mode has not been received in step S 200  (step S 200 : No), the terminal control unit  24  receives an instruction to display the mode selection screen  3  from the game server  1  and displays the mode selection screen  3  on the display unit  21  (step S 201 ). 
     Next, upon acquiring from the operation unit  22  an input signal for a user operation received on the mode selection screen  3 , the terminal control unit  24  transmits the input signal to the game server  1  (step S 202 ). 
     The terminal control unit  24  then waits for an instruction from the game server  1  and judges whether an instruction to execute a battle process in manual mode has been received (step S 203 ). When an instruction for manual mode has not been received (step S 203 : No), the process proceeds to step S 204 . Conversely, when an instruction for manual mode has been received (step S 203 : Yes), the process proceeds to step S 209 . 
     When an instruction for manual mode has not been received in step S 203  (step S 203 : No), the terminal control unit  24  waits for an instruction from the game server  1  and judges whether an instruction to display the confirmation screen  4  has been received (step S 204 ). When an instruction to display the confirmation screen  4  has been received (step S 204 : Yes), the process proceeds to step S 205 . Conversely, when an instruction to display the confirmation screen  4  has not been received (step S 204 : No), the process proceeds to step S 208 . 
     When an instruction to display the confirmation screen  4  has been received in step S 204  (step S 204 : Yes), the terminal control unit  24  displays the confirmation screen  4  on the display unit  21  (step S 205 ). 
     Next, upon acquiring from the operation unit  22  an input signal for a user operation received on the confirmation screen  4 , the terminal control unit  24  transmits the input signal to the game server  1  (step S 206 ). 
     The terminal control unit  24  then waits for an instruction from the game server  1  and judges whether an instruction to execute a battle process in manual mode has been received (step S 207 ). When an instruction for manual mode has not been received (step S 207 : No), the process proceeds to step S 208 . Conversely, when an instruction for manual mode has been received (step S 207 : Yes), the process proceeds to step S 209 . 
     When an instruction for manual mode has not been received in step S 207  (step S 207 : No), then upon receiving an instruction to display the auto mode rendering screen  5  from the game server  1 , the terminal control unit  24  displays the auto mode rendering screen  5  on the display unit  21  (step S 208 ). 
     Conversely, when an instruction for manual mode has been received in step S 200 , step S 203 , or step S 207  (step S 200 : Yes, step S 203 : Yes, step S 207 : Yes), the manual mode processing unit  23  performs a battle process in manual mode (step S 209 ). 
     Next, once the battle ends, the manual mode processing unit  23  determines the battle result and transmits the battle result to the game server  1  (step S 210 ). 
     After step S 208  or step S 210 , upon receiving an instruction to display the battle result screen  6  from the game server  1 , the terminal control unit  24  displays the battle result screen  6  on the display unit  21  (step S 211 ). 
     Next, upon acquiring from the operation unit  22  an input signal for a user operation received on the battle result screen  6 , the terminal control unit  24  transmits the input signal to the game server  1  (step S 212 ). 
     The terminal control unit  24  then judges whether the input signal acquired in step S 212  is an input signal via the battle log button  62  (step S 213 ). When the input signal is an input signal via the battle log button  62  (step  213 : Yes), the process proceeds to step S 214 . On the other hand, when the input signal is an input signal via the next button  63  (step S 213 : No), the process proceeds to step S 216 . 
     When the input signal in step S 213  is an input signal via the battle log button  62  (step S 213 : Yes), then upon receiving an instruction to display the battle log screen  7  from the game server  1 , the terminal control unit  24  displays the battle log screen  7  on the display unit  21  (step S 214 ). 
     Next, the terminal control unit  24  waits for a user operation on the battle log screen  7  (step S 215 ), and upon receipt of an input signal via the close button  71  from the operation unit  22 , the process returns to step S 211  and continues. 
     On the other hand, when the input signal in step S 213  is an input signal via the next button  63  (step S 213 : No), the terminal control unit  24  waits for an instruction from the game server  1  and judges whether an instruction to display the reward attainment screen  8  has been received (step S 216 ). When an instruction to display the reward attainment screen  8  has been received (step S 216 : Yes), the process proceeds to step S 217 . Conversely, when an instruction to display the reward attainment screen  8  has not been received (step S 216 : No), the process terminates. 
     When an instruction to display the reward attainment screen  8  has been received in step S 216  (step S 216 : Yes), the terminal control unit  24  displays the reward attainment screen  8  on the display unit  21  (step S 217 ). 
     The terminal control unit  24  then waits for a user operation on the reward attainment screen  8  (step S 218 ), and upon receipt of an input signal via the OK button  81  from the operation unit  22 , the process terminates. 
     As described above, according to the present embodiment, a battle history  112  that includes identifiers (opponent sets) of opponents with whom the user has battled is stored. Based on the battle history  112  and on the identifier of the opponent with whom a battle begins, a procedure for conducting the battle in the battle game is determined to be either manual mode or auto mode, and the battle is conducted with the determined procedure. It is hence possible to change the procedure for conducting the battle in accordance with the user&#39;s past battle experience. While maintaining the gaming aspect of a battle in manual mode, user operation can be made less troublesome during a battle in auto mode. Furthermore, the user can efficiently battle in a short period of time in auto mode, thereby improving the user&#39;s experience. 
     According to the present embodiment, when the identifier of the opponent with whom the battle begins matches the identifier of an opponent included in the battle history  112 , the mode selection screen  3  allowing the user to select either manual mode or auto mode is displayed. Conversely, when the identifier of the opponent with whom the battle begins does not match the identifier of an opponent included in the battle history  112 , the procedure for conducting the battle is determined to be manual mode. In this way, the gaming aspect of a battle in manual mode for an opponent that the user is battling for the first time can be maintained. At the same time, when the user has already battled an opponent and hence is highly likely to have lost interest, the user can choose to battle using an easy operation in auto mode, thereby improving the user&#39;s experience. The identifier of the opponent may be the individual enemy character IDs of the opponents or the opponent set that indicates a combination of opponents. For example, as in the above-described embodiment, using the opponent set as the identifier of the opponent allows for maintenance of the gaming aspect in manual mode even when the user has already won against the individual enemy characters, since the level of battle difficulty or the like varies due to a different number or combination of enemy characters. 
     According to the present embodiment, the battle history  112  may further include win-loss information on the user for each opponent with whom the user has battled, and when the identifier of the opponent with whom the battle begins matches an identifier that is included in the battle history  112  and that identifies an opponent against whom the user has won, the mode selection screen  3  may be displayed. In this way, for an opponent against whom the user has won in the past, i.e. an opponent against whom the user is highly likely to win in a new battle, the user can choose to battle using an easy operation in auto mode, thereby improving the user&#39;s experience. 
     According to the present embodiment, the auto mode processing unit  13  calculates the predicted result of the battle in auto mode, and before determining the procedure for conducting the battle, displays information corresponding to the predicted result on the display unit  21 . In this way, by suggesting the battle result in auto mode to the user, the user can decide which procedure for conducting the battle to select based on the suggestion. 
     According to the present embodiment, when the predicted result is more adverse for the user than a predetermined standard and the user has selected auto mode on the mode selection screen  3 , the confirmation screen  4  for the user to confirm selection of auto mode is displayed. It is thus possible to reduce the chance of an unintended adverse result, as when the user selects auto mode due to an erroneous operation or the like on the mode selection screen  3 . 
     According to the present embodiment, when conducting the battle in auto mode, the battle log  113  indicating the content of the battle is stored, and the battle log screen  7  for presenting the battle log  113  to the user is displayed. Even for a battle in auto mode, the user can therefore confirm the content of the battle, thus increasing the user&#39;s degree of satisfaction. 
     According to the present embodiment, the winning reward is determined in accordance with the procedure for conducting the battle, and the determined winning reward is provided to the user. For example, the winning reward for a battle in manual mode is selected from a reward group with a higher value than the winning reward for a battle in auto mode. By thus encouraging the user to battle in manual mode, for which the gaming aspect is greater, the user&#39;s interest in the game can be enhanced. 
     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. 
     For example, the determination of whether to display the mode selection screen  3  may be made based on any information related to the opponent. Specifically, the mode selection screen  3  may be displayed when the player character&#39;s level is at least a predetermined value higher than the level of the enemy character that is the opponent. 
     Furthermore, the opponent is not limited to being an enemy character and may be the player character of another user or the like. 
     Another example is how, when the user wins a battle in manual mode with a result more advantageous for the user than the predicted result of the battle in auto mode, the winning reward may be selected from a reward group with an even higher value than the normal winning reward for manual mode. The user is thus encouraged to consider battle strategy in manual mode, thereby enhancing the user&#39;s interest in the game. 
     Yet another example is that the above-described processes performed by the game server  1  or the communication terminal  2  may be performed in cooperation by the game server  1  and the communication terminal  2 . For example, for a process to cause the communication terminal  2  to display a game screen, one possible configuration is for a portion of the screen (such as the portion displaying an image in accordance with game progress) to be a web display that is displayed based on data generated by the game server  1 , and another portion (such as the portion displaying a menu or other fixed input interface) to be a native display via a native application installed on the communication terminal  2 . 
     REFERENCE SIGNS LIST 
       1 : Game server 
       2 : Communication terminal 
       3 : Mode selection screen 
       4 : Confirmation screen 
       5 : Auto mode rendering screen 
       6 : Battle result screen 
       7 : Battle log screen 
       8 : Reward attainment screen 
       9 : Manual mode battle screen 
       10 : Server communication unit 
       11 : Storage unit 
       110 ,  110   a,    110   b : User data 
       111 ,  111   a,    111   b : Opponent database (DB) 
       112 : Battle history 
       113 : Battle log 
       12 : Procedure determination unit 
       13 : Auto mode processing unit 
       14 : Winning reward determination unit 
       15 : Server control unit 
       20 : Terminal communication unit 
       21 : Display unit 
       22 : Operation unit 
       23 : Manual mode processing unit 
       24 : Terminal control unit 
       30 : Character icon 
       31 : Message displaying area 
       32 : Manual button 
       33 : Auto button 
       40 : Character icon 
       41 : Message displaying area 
       42 : Manual button 
       43 : Auto button 
       50 : Displaying area for the enemy character name 
       51 : Displaying area for enemy character images 
       52 : Displaying area for the deck 
       60 : Displaying area for the result 
       61 : Displaying area for the deck 
       62 : Battle log button 
       63 : Next button 
       70 : Displaying area for the battle log 
       71 : Close button 
       80 : Displaying area for the reward 
       81 : OK button 
       90   a : Field area 
       90   b : Displaying area for the deck 
       91 : Player character 
       92 : Displaying area for player status 
       93 ,  93   a,    93   b,    93   c : Enemy character 
       94 ,  94   a,    94   b,    94   c : Enemy HP indicator 
       95 ,  95   a,    95   b,    95   c : Number of enemy wait turns 
       96 : Target icon 
       97 ,  97   a,    97   b,    97   c,    97   d,    97   e : Card

Technology Category: 1