JP2020151498A - Game program and game system - Google Patents

Abstract

To provide a game program and a game system including a function of enhancing strategic characteristics of a user (player) in a command battle.SOLUTION: In a command battle for selecting a command, such as "fight", from a command list, and for allowing a player object to take action corresponding to the command, the command is strengthened (boosted) by a boost item. For example, when a command of "fight" is not strengthened and is strengthened, a physical attack is performed once and twice, respectively.SELECTED DRAWING: Figure 13

Description

At least one of the embodiments of the present invention relates to a game program or the like for realizing a function of controlling the progress of a video game including a command battle between a player object and an enemy object on a computer.

Conventionally, in video games, there is a game of a genre called a role-playing game (RPG: Role Playing Game). In a role-playing game, a so-called command battle method is adopted as one of the methods for fighting a player object operated by a player and an enemy object (see, for example, Patent Document 1). In a command battle, one command is selected by the user from a plurality of commands (command list), and an action corresponding to the selected command is executed by the player object. For example, when the user selects the "fight" command, the player object performs an attack action against the enemy object.

Japanese Unexamined Patent Publication No. 2014-079529

The above-mentioned command battle method has been conventionally adopted in many role-playing games. Therefore, for a user who has played a command battle in another role-playing game in the past, that experience can be easily utilized for a new role-playing game such as a basic strategy of the command battle. On the other hand, since the contents of the commands included in the command list are fixed, it is an issue to expand the strategic range while maintaining the basic battle method of command battle.

An object of at least one embodiment of the present invention is to solve the above problems and provide a function of improving the strategic nature of a user (player) in a command battle.

From a non-limiting point of view, the game program according to the embodiment of the present invention is a game program for realizing a function of controlling the progress of a video game including a turn-based battle between a player object and an enemy object on a computer. Therefore, a battle control function that determines the execution order of actions of the player object and the enemy object in the turn-based battle and controls the progress of the turn-based battle, and a reception function that accepts the number of used items for each player object. The purpose of the battle control function is to realize a function of increasing the number of actions of the player object in one turn as the number of times the predetermined item is used increases.

From a non-limiting point of view, the game program according to an embodiment of the present invention is a server device connected by a communication network to a game terminal device that executes a video game including a turn-based battle between a player object and an enemy object. , A game program for controlling the progress of the video game, in which the server device determines the execution order of the actions of the player object and the enemy object in the turn-based battle, and controls the progress of the turn-based battle. The battle control function and the reception function that accepts the number of times a predetermined item is used for each player object are realized. In the description battle control function, the larger the number of times the predetermined item is used, the more the number of actions of the player object in one turn. It is for realizing the function of increasing.

From a non-limiting point of view, the game system according to the embodiment of the present invention is based on a game terminal device that executes a video game including a turn-based battle between a player object and an enemy object, and the game terminal device and a communication network. A game system including a server device to be connected, the player object is a battle control means for determining the execution order of actions of the player object and the enemy object in the turn-based battle and controlling the progress of the turn-based battle. The battle control means includes a reception means for accepting the number of times a predetermined item is used in a unit, and the battle control means increases the number of actions of the player object in one turn as the number of times the predetermined item is used increases. To do.

Each embodiment of the present application solves one or more shortages.

It is a block diagram which shows the example of the structure of the game system corresponding to at least one of the embodiments of this invention. It is a flowchart which shows the example of the battle progress process corresponding to at least one of the Embodiments of this invention. It is a flowchart which shows an example of the operation on the server apparatus side when the server apparatus corresponding to at least one of the Embodiments of this invention executes a battle progress process. It is a block diagram which shows the example of the structure of the game system corresponding to at least one of the embodiments of this invention. It is a flowchart which shows the example of the battle progress process corresponding to at least one of the Embodiments of this invention. It is a block diagram which shows the example of the structure of the game system corresponding to at least one of the embodiments of this invention. It is a flowchart which shows the example of the battle progress process corresponding to at least one of the Embodiments of this invention. It is a block diagram which shows the example of the structure of the game system corresponding to at least one of the embodiments of this invention. It is a flowchart which shows the example of the battle progress process corresponding to at least one of the Embodiments of this invention. It is a figure which shows an example of the command selection image corresponding to at least one of the embodiments of this invention. It is a figure which shows an example of the game image of the command battle corresponding to at least one of the embodiments of this invention. It is a figure which shows an example of the command list corresponding to at least one of the embodiments of this invention. It is a figure which shows an example of the command table corresponding to at least one of the embodiments of this invention. It is a figure which shows an example of the command table corresponding to at least one of the embodiments of this invention. It is a block diagram which shows the example of the structure of the game system corresponding to at least one of the embodiments of this invention. It is a figure which shows an example of the execution order table corresponding to at least one of the Embodiments of this invention. It is a flowchart which shows the example of the battle progress process corresponding to at least one of the Embodiments of this invention. It is a block diagram which shows the example of the structure of the game system corresponding to at least one of the embodiments of this invention. It is a figure which shows an example of the game image of the command battle corresponding to at least one of the embodiments of this invention. It is a flowchart which shows the example of the battle progress process corresponding to at least one of the Embodiments of this invention.

Hereinafter, examples of embodiments of the present invention will be described with reference to the drawings. It should be noted that the various components in the examples of the respective embodiments described below can be appropriately combined as long as there is no contradiction or the like. Further, the contents described as an example of a certain embodiment may be omitted in another embodiment. In addition, the contents of operations and processes not related to the characteristic parts of each embodiment may be omitted. Further, the order of various processes constituting the various flows described below is in no particular order as long as there is no contradiction in the processing contents.

[First Embodiment]
FIG. 1 is a block diagram showing an example of a configuration of a game system 100 corresponding to at least one of the embodiments of the present invention. As shown in FIG. 1, the game system 100 includes a single terminal device (game terminal device) 20 used by a user (player). Note that FIG. 1 shows the configuration of the terminal device 20A, which is an example of the configuration of the terminal device 20. Further, the configuration of the game system 100 is not limited to this. For example, the user's terminal device may be connected to a server device (video game processing server) via a communication network, and the video game service may be provided to the terminal device from this server device.

The game system 100 has various functions for executing a video game including a command battle in which a player object and an enemy object fight. In the command battle of the video game of the example of the present embodiment, the operation unit of the terminal device is used to cause the user to input (select) a command for the player object from one or more command options. Then, the player object is made to execute the action corresponding to the selected command, and the battle with the enemy object is advanced. The command is a command to the player object, and is associated with an action such as an attack to be executed by the player object. A player object is an object operated by a user, and is operated by a command in a command battle. Further, the enemy object is a non-player object that does not accept the user's operation, and the terminal device 20 controls actions such as an attack on the player object.

Further, in the video game of the example of the present embodiment, the above command can be strengthened by using the boost item. More specifically, when there is a request to use a boost item, as an action corresponding to the command, an action that is more advantageous in the command battle than an action when there is no request for use (hereinafter referred to as a normal action) (hereinafter, a boost action). ) Is executed by the player object. The number of boost items owned is managed in association with the user (or player object), for example. The number of possessions is stored in the storage unit of the terminal device 20, and is reduced by the amount (number of uses) used by the user to strengthen the command.

The advantageous action in the command battle means an action in which the player object is more likely to defeat the enemy object than the normal action.

The terminal device 20 is managed by a user who plays a video game, and is a terminal capable of playing a video game such as a stationary game device, a personal computer, a mobile phone terminal, a PDA (Personal Digital Assistants), or a portable game device. It is composed of devices.

Further, the terminal device 20 displays an operation device (operation unit) for executing a video game, a storage unit such as a hard disk drive, a control unit composed of a CPU for executing a game and generating a game image, and a game image. It is provided with a display device (display unit) and the like, but since it has a general configuration, detailed description thereof will be omitted. Further, in the terminal device 20, software (game program) for executing a video game and controlling the progress of the game is stored in a storage unit.

Next, the configuration of the terminal device 20A, which is an example of the configuration of the terminal device 20, will be described. The terminal device 20A includes at least a management unit 31 and a battle control unit 32 for controlling the progress of the video game by the control unit executing the game program of the storage unit.

The management unit 31 manages the number of boost items stored in the storage unit of the terminal device 20A. The number of possessions means the quantity of boost items available to the user. The management unit 31 reduces the number of possessions by the amount (number of uses) that the user uses the boost item. The battle control unit 32 controls the progress of the command battle. Specifically, in a command battle, the action of an enemy object or the like is controlled, and the player object is made to execute an action corresponding to a command selected by the user. Further, when the user requests the use of the boost item, the battle control unit 32 executes the above-mentioned boost action as an action corresponding to the command selected by the user.

Next, the operation of the game system 100 (system 100) of this embodiment will be described.

FIG. 2 is a flowchart showing an example of a battle progress process executed by the system 100. In the battle progress processing in this example, the progress processing of the command battle between the player object and the enemy object is performed. Hereinafter, a case where the terminal device 20A executes the battle progress process will be described as an example.

The battle progress process of this example is executed, for example, when a command battle is started. The command battle is started when a start condition is satisfied, such as when a player object comes into contact with an enemy object in the game space.

In the battle progress process, the terminal device 20A determines whether or not there is a request from the user to use the boost item (step S10). For example, the user may operate the operation unit to determine whether or not there is a request to use the boost item input. When it is determined that there is no usage request (step S10: NO), the terminal device 20A determines whether or not the user has selected (determined) a command (step S11). For example, the presence or absence of a command input (determined) by the user by operating the operation unit may be determined. If it is determined that the command has not been determined (step S11: NO), the terminal device 20A returns to the process of step S10.

On the other hand, when it is determined that the command has been determined (step S11: YES), the terminal device 20A executes the battle process (step S15). In the battle process, the player object and the enemy object are made to perform a battle action. That is, the battle between the player object and the enemy object progresses. Specifically, the player object is made to execute the action corresponding to the determined command. For example, let the player object attack an enemy object. The action of the player object is a normal action when there is no usage request, and a boost action when there is a usage request. In the example of the present embodiment, in the battle process when shifting from the process of step S11, since there is no request for using the boost item, the action corresponding to the determined command is a normal action. Further, the terminal measure 20A causes an enemy object to attack a player object, for example.

Further, in the battle process, for example, a process of increasing or decreasing the parameters of each object such as the vitality parameters of the player object and the enemy object is performed according to each action executed. After that, the terminal device 20A shifts to the process of step S16.

Next, when it is determined that the usage request has been made in the process of step S10, the terminal device 20A determines whether or not the usage request has been cancelled (step S12). For example, it may be determined whether or not the usage request input by the user is canceled by operating the operation unit. If it is determined that the usage request has been canceled (step S12: YES), the terminal device 20A returns to the process of step S10.

On the other hand, when there is no cancellation of the usage request (step S12: NO), the terminal device 20A determines whether or not the user's command is selected (determined) as in the process of step S11 (step S13). If it is determined that the command has not been determined (step S13: NO), the terminal device 20A returns to the process of step S12.

On the other hand, when it is determined that the command has been determined (step S13: YES), the terminal device 20A updates the number of boost items held (subtraction process) according to the number of boost items used (step S14). For example, if the number of boost items used is fixed at 1, the number of possessed items is subtracted by 1.

Next, the terminal device 20A executes the above-mentioned battle process (step S15). In the example of the present embodiment, in the battle process shifted from the process of step S14, since there is a usage request, the terminal device 20A causes the player object to execute the boost action as the action corresponding to the determined command.

After that, the terminal device 20A determines whether or not the end condition of the command battle is satisfied (step S16). The termination condition is, for example, that all the enemy objects are defeated (become incombatable), or that the player object is defeated (become incombatable). That is, the end condition is that the user (player object) wins or defeats the enemy object. The terminal device 20A may determine whether or not the end condition is satisfied based on, for example, the vitality parameter of each object updated by the battle process in step S15. When the end condition is satisfied (step S16: YES), the terminal device 20A ends the battle progress process. On the other hand, if the end condition is not satisfied (step S16: NO), the terminal device 20A returns to the process of step S10.

As described above, as one aspect of the first embodiment, since the terminal device 20A is configured to include the management unit 31 and the battle control unit 32, the action content corresponding to the command can be changed according to the use of the boost item. Be strengthened. That is, the command is strengthened. As a result, the range of command choices is widened, so it is possible to expand the range of strategies while maintaining the basic battle method in command battles. Therefore, it is possible to improve the strategic nature of the user (player) in the command battle.

In the example of the first embodiment described above, the terminal device 20A executes a game program to control the progress of the game, but the present invention is not particularly limited to this. Instead of the terminal device 20A, the server device may be configured to include a management unit and a battle control unit.

The server device includes a storage unit such as a hard disk drive (not shown) and a control unit including a CPU and the like. Further, the server device controls the progress of the video game in the same manner as the terminal device 20A by the control unit executing the above-mentioned game program stored in the storage unit. The server device has a general configuration for controlling the progress of a video game such as a control unit and a communication unit, but detailed description thereof will be omitted here.

The server device does not execute the video game unlike the terminal device 20A. The server device has, for example, a communication unit connected to an Internet line (communication network) and communicates with a terminal device that executes a video game. The server device receives an operation signal or the like from the user (terminal device), and also transmits information on the progress of the game to the terminal device. A plurality of server devices may cooperate to execute the game program, or the server device and the terminal device may cooperate to execute the game program (control the progress of the game).

FIG. 3 is a flowchart showing an example of the operation on the server device side when the server device executes the battle progress process shown in FIG.

In the battle progress process, the server device determines whether or not there is a request from the user to use the boost item (step S30). When it is determined that there is no usage request (step S30: NO), the server device determines whether or not the user has selected (determined) a command (step S31). If it is determined that the command has not been determined (step S31: NO), the server device returns to the process of step S30.

On the other hand, when it is determined that the command has been determined (step S31: YES), the server device executes the battle process (step S35). After that, the server device shifts to the process of step S36.

Next, when it is determined that the usage request has been made in the process of step S30, the server device determines whether or not the usage request has been cancelled (step S32). If it is determined that the usage request has been canceled (step S32: YES), the server device returns to the process of step S30.

On the other hand, if there is no cancellation of the usage request (step S32: NO), the server device determines whether or not the user's command is selected (determined) as in the process of step S31 (step S33). If it is determined that the command has not been determined (step S33: NO), the server device returns to the process of step S32. On the other hand, when it is determined that the command has been decided (step S33: YES), the server device updates (decreases) the number of boost items possessed according to the number of boost items used (step S34).

Next, the server device executes the above-mentioned battle process (step S35). After that, the server device determines whether or not the end condition of the command battle is satisfied (step S36). When the end condition is satisfied (step S36: YES), the server device ends the battle progress process. On the other hand, if the end condition is not satisfied (step S36: NO), the server device returns to the process of step S30.

The server device executes the above-mentioned battle progress process, and periodically transmits information on the progress of the command battle, including information for generating a game image of the command battle, to the terminal device. The terminal device receives information on the progress of the command battle and performs processing such as displaying a game image on the display unit.

The player object and the enemy object in the example of the first embodiment described above are not limited to one. In a command battle, a plurality of player objects may be combined into one party to fight against a plurality of enemy objects. In this case, the user may specify a command for each of the plurality of player objects.

Further, as the command of the example of the first embodiment described above, for example, there are "fight", "item" and the like. The user selects a command for the player object from options such as "fight" and "item". "Strike" causes a player object to execute a physical attack action using a weapon or the like. An "item" causes a player object (user) to perform an action using an item available in the game.

Further, as the boosting action of the example of the first embodiment described above, for example, in the case of the above-mentioned "fighting" command, there is an action of increasing the number of physical attacks from one to two. That is, even for the same physical attack action, one physical attack action is executed in the normal action, while two physical attacks are executed in the boost action. Further, for example, a physical attack having a higher attack power than a physical attack of a normal action may be used as a boost action.

In addition, the number of boost items used for one command in the example of the first embodiment described above may be input by the user together with the usage request. Further, when the number of usages is fixed, only the usage request may be input. Alternatively, only the input of the number of uses may be accepted. In this case, it may be determined that the usage request has been made depending on whether or not the number of usages has been input. The number of units of boost items when strengthening one command does not have to be one, and can be set arbitrarily.

Further, the update of the number of possessions in the above-described example of the first embodiment is not limited to the timing in the process of step S14. It can be subtracted according to the number of boost items used. In addition, the number of possessions may be increased according to predetermined conditions. As a predetermined condition, for example, the amount of decrease (damage amount) of the vitality parameter of the enemy object due to the attack of the player object has reached a predetermined value. The vitality parameter of the enemy object is reduced by the amount of damage received by the attack of the player object. When the vitality parameter decreases below a predetermined value, the enemy object is in a defeated state (incapable of fighting).

Further, the number of possessions of the above-described example of the first embodiment may be managed for each user or for each player object. For example, the number of possession of each boost item of a plurality of player objects may be managed and used for strengthening the command of the player object up to the corresponding number of possessions. Alternatively, the number of possessions may be managed for each user so that it can be used to strengthen the commands of each of a plurality of player objects.

Further, as the action of the enemy object in the command battle of the example of the first embodiment described above, for example, the terminal device 20A may execute the action determined by lottery from among a plurality of actions.

[Second Embodiment]
FIG. 4 is a block diagram showing a configuration of a terminal device 20B, which is an example of the terminal device 20. In this example, the terminal device 20B includes at least a management unit 31 and a battle control unit 32B. The management unit 31 manages the number of boost items stored in the storage unit of the terminal device 20B, as in the example of the first embodiment described above.

The battle control unit 32B controls the progress of the command battle in the same manner as in the example of the first embodiment described above. Further, in the battle control unit 32B of the example of the present embodiment, when the user requests the use of the boost item, as an action corresponding to the command, the larger the number of boost items used per command, the more in the command battle. Causes the player object to perform a favorable boost action. That is, different boost actions are executed according to the number of boost items used per command.

FIG. 5 is a flowchart showing an example of a battle progress process executed by the system 100. In the battle progress processing in this example, the progress processing of the command battle between the player object and the enemy object is performed. Hereinafter, a case where the terminal device 20B executes the battle progress process will be described as an example. The flowchart showing the operation of the server device will be omitted from the viewpoint of avoiding duplicate explanations.

The battle progress process of this example is executed, for example, when a command battle is started. The command battle is started when a start condition is satisfied, such as when a player object comes into contact with an enemy object in the game space.

In the battle progress process, the terminal device 20B determines whether or not there is a request from the user to use the boost item (step S10). For example, the user may operate the operation unit to determine whether or not the number of boost items used has been input. More specifically, if the number of usages is 0, it may be determined that there is no usage request, and if the number of usages is 1 or more, it may be determined that there is a usage request. When it is determined that there is no usage request (step S10: NO), the terminal device 20B determines whether or not the user has selected (determined) a command (step S11). If it is determined that the command has not been determined (step S11: NO), the terminal device 20B returns to the process of step S10.

On the other hand, when it is determined that the command has been determined (step S11: YES), the terminal device 20B executes the battle process (step S15-B). In the battle process, the player object and the enemy object are made to perform the battle action as in the example of the first embodiment described above. Further, in the example of the present embodiment, since there is no request for using the boost item in the battle process when shifting from the process of step S11, the action corresponding to the determined command is the example of the first embodiment. It becomes a normal action like. In the battle process of the example of the present embodiment, as described above, the larger the number of uses per command, the more advantageous the boost action in the command battle is executed by the player object. After that, the terminal device 20B shifts to the process of step S16.

Next, when it is determined that the usage request has been made in the process of step S10, the terminal device 20B determines whether or not the usage request has been cancelled (step S12). For example, it may be determined whether or not the number of used boost items input by the user is canceled by operating the operation unit. Alternatively, if the user makes an input to change the number of uses to 0, it may be determined to be canceled. If it is determined that the usage request has been canceled (step S12: YES), the terminal device 20B returns to the process of step S10.

On the other hand, when there is no cancellation of the usage request (step S12: NO), the terminal device 20B determines whether or not the user's command is selected (determined) as in the process of step S11 (step S13). If it is determined that the command has not been determined (step S13: NO), the terminal device 20B returns to the process of step S12.

On the other hand, when it is determined that the command has been determined (step S13: YES), the terminal device 20B updates the number of boost items possessed according to the number of boost items used (subtraction process) (step S14-B). .. The terminal device 20B reduces the number of possessions by the number of uses input by the user.

Next, the terminal device 20B executes the above-mentioned battle process (step S15-B). In the example of the present embodiment, in the battle process shifted from the process of step S14-B, there is a usage request. Therefore, the terminal device 20B causes the player object to execute the boost action according to the number of uses as the action corresponding to the determined command.

After that, the terminal device 20B determines whether or not the end condition of the command battle is satisfied (step S16). When the end condition is satisfied (step S16: YES), the terminal device 20B ends the battle progress process. On the other hand, if the end condition is not satisfied (step S16: NO), the terminal device 20B returns to the process of step S10.

As described above, as one aspect of the second embodiment, since the terminal device 20B is configured to include the management unit 31 and the battle control unit 32B, the command is strengthened according to the use of the boost item. As a result, the range of command choices is widened, so it is possible to expand the range of strategies while maintaining the basic battle method in command battles. Therefore, it is possible to improve the strategic nature of the user (player) in the command battle.

In addition, the more boost items are used, the stronger the action content corresponding to the command. Therefore, which one to set the number of usage per command while considering the number of boost items possessed is also a matter to be considered in order to advance the command battle advantageously. Therefore, since the range of command selection is widened, the strategic nature of the user (player) can be further improved in the command battle.

In the boost action of the second embodiment described above, for example, when the number of boost items used is 0 for the "fight" command, a physical attack using a weapon or the like is performed once on the player object. Have an action (normal action) executed. In addition, when the number of boost items used is 1 in response to the "fight" command, the action of performing the physical attack twice (boost action) is executed. Further, when the number of boost items used is 2 for the above "fight" command, the action of performing the above physical attack four times is executed as a boost action. Therefore, as the number of uses increases, the number of physical attacks increases, so the amount of damage given to enemy objects also increases, which is advantageous in command battles. Instead of increasing the number of times, the physical attack with higher attack power may be used as the boost action as the number of uses increases.

Further, in the example of the second embodiment described above, in the process of step S10, the presence / absence of the use request is determined according to the presence / absence of the number of uses, but the present invention is not particularly limited to this. For example, both the input of the usage request and the input of the number of usages may be accepted, and the determination in the process of step S10 may be made based on the presence or absence of the input of the usage request.

[Third Embodiment]
FIG. 6 is a block diagram showing a configuration of a terminal device 20C, which is an example of the terminal device 20. In this example, the terminal device 20C includes at least a management unit 31C and a battle control unit 32.

The management unit 31C manages the number of boost items stored in the storage unit of the terminal device 20C, as in the example of the first embodiment described above. In addition, the management unit 31C of the example of the present embodiment increases the number of possessions according to the progress of the command battle. The progress of the command battle is the progress of the battle between the player object and the enemy object. For example, the amount of damage that the player object gives to the enemy object, the amount of damage that the enemy object gives to the player object, and the state of the enemy object (incapable of fighting). State) etc. are also included. The battle control unit 32 controls the progress of the command battle in the same manner as in the example of the first embodiment described above.

FIG. 7 is a flowchart showing an example of a battle progress process executed by the system 100. In the battle progress processing in this example, the progress processing of the command battle between the player object and the enemy object is performed. Hereinafter, a case where the terminal device 20C executes the battle progress process will be described as an example. The flowchart showing the operation of the server device will be omitted from the viewpoint of avoiding duplicate explanations.

The battle progress process of this example is executed, for example, when a command battle is started. The command battle is started when a start condition is satisfied, such as when a player object comes into contact with an enemy object in the game space.

In the battle progress process, the terminal device 20C determines whether or not there is a request from the user to use the boost item (step S10). When it is determined that there is no usage request (step S10: NO), the terminal device 20C determines whether or not the user has selected (determined) a command (step S11). If it is determined that the command has not been determined (step S11: NO), the terminal device 20C returns to the process of step S10.

On the other hand, when it is determined that the command has been determined (step S11: YES), the terminal device 20C executes the battle process (step S15). That is, the battle between the player object and the enemy object is advanced. After that, the terminal device 20C shifts to the process of steps S15-10C. Next, when it is determined that the usage request has been made in the process of step S10, the terminal device 20C determines whether or not the usage request has been cancelled (step S12). If it is determined that the usage request has been canceled (step S12: YES), the terminal device 20C returns to the process of step S10.

On the other hand, when there is no cancellation of the usage request (step S12: NO), the terminal device 20C determines whether or not the user's command is selected (determined) as in the process of step S11 (step S13). If it is determined that the command has not been determined (step S13: NO), the terminal device 20C returns to the process of step S12.

On the other hand, when it is determined that the command has been determined (step S13: YES), the terminal device 20C updates the number of boost items possessed (subtraction process) according to the number of boost items used (step S14). Next, the terminal device 20C executes the above-mentioned battle process (step S15).

After that, the terminal device 20C updates the number of boost items possessed (increase processing) according to the progress of the command battle (step S15-10C). Specifically, the terminal device 20C determines and updates the amount of increase in the number of boost items possessed based on the progress of the command battle updated in the battle process in step S15.

After that, the terminal device 20C determines whether or not the end condition of the command battle is satisfied (step S16). When the end condition is satisfied (step S16: YES), the terminal device 20C ends the battle progress process. On the other hand, if the end condition is not satisfied (step S16: NO), the terminal device 20C returns to the process of step S10.

As described above, as one aspect of the third embodiment, since the terminal device 20C is configured to include the management unit 31C and the battle control unit 32, the command is strengthened according to the use of the boost item. As a result, the range of command choices is widened, so it is possible to expand the range of strategies while maintaining the basic battle method in command battles. Therefore, it is possible to improve the strategic nature of the user (player) in the command battle.

In addition, since the number of boost items possessed increases according to the progress of the command battle, the user will select the command in consideration of proceeding with the command battle so that the number of possessed items will increase efficiently. , The strategic nature of the user (player) can be further improved in the command battle.

As the progress of the command battle in the example of the third embodiment described above, for example, there is a decrease amount (damage amount) of the vitality parameter of the enemy object due to the attack of the player object. The vitality parameter of the enemy object is reduced by the amount of damage received by the attack of the player object. The more damage you do to this enemy object, the more you have. Therefore, the user will think of a strategy to select an attack command that causes more damage to the enemy object in order to increase the number of possessions. The amount of damage is calculated based on the attack power parameter, defense power parameter, and the like of the player object. Further, since the calculation of the damage amount is a general configuration, detailed description thereof will be omitted.

Further, in the example of the third embodiment described above, the process of increasing the number of possessions is performed in steps S15-10C, but the timing of the increase is not limited to this. For example, it may be executed while returning from the process of step S16 to the process of step S10.

[Fourth Embodiment]
FIG. 8 is a block diagram showing a configuration of the terminal device 20D, which is an example of the terminal device 20. In this example, the terminal device 20D includes at least a management unit 31, a battle control unit 32D, and a display control unit 33D.

The management unit 31 manages the number of boost items stored in the storage unit of the terminal device 20D, as in the example of the first embodiment described above. The battle control unit 32D controls the progress of the command battle in the same manner as in the example of the first embodiment described above. Further, the battle control unit 32D of the example of the present embodiment causes the player object to execute an action corresponding to a command selected from the command options included in the command selection image displayed on the display unit of the terminal device 20D. ..

The display control unit 33D causes the display unit to display a command selection image including one or more commands that can be selected by the user. For example, it is an image of a list in which one or more commands are arranged. Further, the display control unit 33D of the example of the present embodiment changes the display form of the command selection image according to the presence or absence of the request for using the boost item. Specifically, the display control unit 33D changes the display form of the command selection image so that the user can identify the case where the boost item is requested to be used and the case where the boost item is not used. The display form includes the shape, color, and the like of the command selection image.

Therefore, in the terminal device 20D of the example of the present embodiment, the input of the request for using the boost item is first received, and then the input of the user's command selection for the command selection image is received. In addition, when a command is selected for a command selection image in a display form for which there is no usage request, the action corresponding to the selected command is a normal action. On the other hand, when a command is selected for a command selection image in a display form for which a usage request is made, a boost action is performed as an action corresponding to the selected command. That is, in the example of the present embodiment, when there is a usage request, the boost action is executed regardless of which of the commands included in the command selection image can use the boost item. .. That is, by using the boost item, the command selection image is displayed so that all the commands that can use the boost item included in the command selection image are enhanced.

FIG. 9 is a flowchart showing an example of a battle progress process executed by the system 100. In the battle progress processing in this example, the progress processing of the command battle between the player object and the enemy object is performed. Hereinafter, a case where the terminal device 20D executes the battle progress process will be described as an example. The flowchart showing the operation of the server device will be omitted from the viewpoint of avoiding duplicate explanations.

The battle progress process of this example is executed, for example, when a command battle is started. The command battle is started when a start condition is satisfied, such as when a player object comes into contact with an enemy object in the game space.

In the battle progress process, the terminal device 20D causes the display unit to display a game image including a command selection image in a display form in which there is no request to use the boost item (step S5-10D). For example, as described above, an image of a list of commands that can be selected by the user is displayed.

Next, the terminal device 20D determines whether or not the user is requested to use the boost item (step S10). When it is determined that there is no usage request (step S10: NO), the terminal device 20D determines whether or not the user has selected (determined) a command (step S11). If it is determined that the command has not been determined (step S11: NO), the terminal device 20D returns to the process of step S5-10D.

On the other hand, when it is determined that the command has been determined (step S11: YES), the terminal device 20D executes the battle process (step S15). In the example of the present embodiment, in the battle process when shifting from the process of step S11, the command is selected in the command selection image in the display mode in which there is no request to use the boost item, so that the command is determined. The action corresponding to the command is a normal action. After that, the terminal device 20D shifts to the process of step S16.

Next, when it is determined in the process of step S10 that there is a usage request, the terminal device 20D causes the display unit to display a game image including a command selection image in a display form in which there is a usage request for the boost item (step S10). -20D).

After that, the terminal device 20D determines whether or not the usage request is canceled (step S12). If it is determined that the usage request has been canceled (step S12: YES), the terminal device 20D returns to the process of step S5-10D.

On the other hand, when there is no cancellation of the usage request (step S12: NO), the terminal device 20D determines whether or not the user's command is selected (determined) as in the process of step S11 (step S13). If it is determined that the command has not been determined (step S13: NO), the terminal device 20D returns to the process of step S10-20D.

On the other hand, when it is determined that the command has been determined (step S13: YES), the terminal device 20D updates the number of boost items held (subtraction process) according to the number of boost items used (step S14). If a command that does not correspond to the boost action is selected from the commands in the command selection image, the number of possessions is not updated (subtracted). Next, the terminal device 20D executes the above-mentioned battle process (step S15). In the example of the present embodiment, in the battle process shifted from the process of step S14, the command is selected in the command selection image in the display mode in which there is a request to use the boost item, so that the determined command is determined. As an action corresponding to, the player object is made to execute a boost action.

After that, the terminal device 20D determines whether or not the end condition of the command battle is satisfied (step S16). When the end condition is satisfied (step S16: YES), the terminal device 20D ends the battle progress process. On the other hand, if the end condition is not satisfied (step S16: NO), the terminal device 20D returns to the process of step S5-10D.

As described above, as one aspect of the fourth embodiment, the terminal device 20D is configured to include the management unit 31, the battle control unit 32D, and the display control unit 33D, so that the command can be issued according to the use of the boost item. It will be strengthened. As a result, the range of command choices is widened, so it is possible to expand the range of strategies while maintaining the basic battle method in command battles. Therefore, it is possible to improve the strategic nature of the user (player) in the command battle.

In addition, since the command selection image is displayed in a display form according to the presence or absence of a usage request, the user can select a command by operating the operation unit while visually recognizing which display form the command selection image is in. It can be carried out. In addition, among the commands included in the command selection image, all the commands that can use the boost item can be visually recognized as enhanced.

The command selection image of the example of the fourth embodiment described above may be, for example, an image of the command list 70 as shown in FIGS. 10 (A) and 10 (B). The command list 70 shown in FIG. 10A shows a state in which there is no request to use the boost item. The command list 70 shown in FIG. 10B shows a state in which there is a request to use the boost item. That is, one of the images of the box frame 72 and the box frame 720 is displayed depending on the presence or absence of the usage request.

[Fifth Embodiment]
11 (A) and 11 (B) are diagrams showing an example of a command battle game image displayed on the display unit of the terminal device 20E, which is an example of the terminal device 20. FIG. 11A is a game image in a state where there is no request to use coins, which are boost items. FIG. 11B is a game image in a state where there is a request to use coins.

The terminal device 20E of the example of the present embodiment is, for example, a role-playing game (video game) including a command battle in which a party of player objects 50 (50A to 50D) and a party of enemy objects 55 (55A to 55D) fight. Execute. In the example of this embodiment, the command battle is a turn-based strategy, and the objects 50 and 55 execute actions in a determined order. Further, in the example of the present embodiment, the command is strengthened by using coins in the command battle, and the player object executes the boost action.

In the example of this embodiment, various parameters such as vitality parameter, attack power parameter, and defense power parameter are set in each of the player object 50 and the enemy object 55. Further, when each object 50 is damaged by an attack from a combat opponent or the like, the vitality parameter is reduced by the amount of damage received. Then, when the vitality parameter becomes equal to or less than a predetermined value, the objects 50 and 55 are in a defeated state (combat impossible state). The amount of damage is calculated based on the attack power parameters and defense power parameters of the objects 50 and 55. Since the calculation of the damage amount is a general configuration, detailed description thereof will be omitted.

First, a game image in a state where coins are not used will be described with reference to FIG. 11 (A).

In the game image shown in FIG. 11A, a state in which four player objects 50A to 50D and four enemy objects 55A to 55D face each other is displayed. Further, on the upper left side of the game image, there is a display area 60 for the number of coins held by the user. In the display area 60, icon images of a number of coins corresponding to the number of possessions are displayed. In the game image shown in FIG. 11A, a state in which the user holds nine coins is displayed.

In addition, the display area 61 is displayed below the display area 60 of the number of possessions. In the display area 61, a gauge that visually represents the cumulative value of the coin acquisition parameters is displayed. When the coin acquisition parameter reaches a predetermined value (acquisition value), the user can acquire one new coin. That is, the number of coins held increases by one. The coin earning parameters increase according to the progress of the command battle (details will be described later).

Further, a command list (command selection image) 70 is displayed in the vicinity of the player object 50 for which command input is required. In the command list 70, the commands that can be selected for the player object 50 are displayed in one column. The user can operate the operation unit to move the cursor 71 and select one command. In the game image shown in FIG. 11A, the command list 70 is displayed in the vicinity of the player object 50A, and input (selection) of a command to the player object 50A is requested. For example, after the command selection of the player object 50A is completed, the display of the command list 70 moves to the vicinity of the player object 50D, and the input of the command to the player object 50D is required.

In addition, the commands of the example of this embodiment include "fight", "tokugi", "ability", "item", and "defense". "Strike" causes the player object 50 to perform a physical attack action with a weapon targeting any one of the enemy objects 55A to 55D. In the "Tokugi", a unique action set for each of the player objects 50 is executed. For example, there is an attack technique having a large attack power (attack power parameter), and a recovery action that recovers a predetermined amount of vitality parameters of all the player objects 50A to 50D of the party.

Regarding "Tokugi" and "Ability", there may be multiple corresponding commands. Therefore, when "Tokugi" and "Ability" are selected, the corresponding command is displayed in another window. For example, as shown in FIG. 12A, when the cursor 71 is moved to the "ability", the command "special sword 1" corresponding to the "ability" is displayed in the separate window 76. Then, if the user performs a determination operation while the cursor 710 specifies "Special Move 1", the action corresponding to "Special Sword 1" is executed by the player object 50.

The "ability" is a magical or physical attack action that can be executed according to the attributes of the player objects 50A to 50D. Attributes include, for example, occupations (jobs) such as warriors and wizards. For example, the player object 50B is an attribute of Shinobi, and as a command corresponding to the "ability", there is a command to activate a special move using a sword as a weapon. For example, there is "Special Sword 1" shown in FIG. 12 (A).

Further, for example, the player object 50C is an attribute of a wizard, and as a command corresponding to the "ability", there is a command to activate recovery magic. In this case, after selecting "Ability", a list of more selectable magic commands is displayed in window 76. Then, the magic activation corresponding to one command selected from the list is executed.

Next, in "defense", an action is executed to reduce the amount of damage received by the attack from the enemy objects 55A to 55D. In the example of this embodiment, "defense" is not a coin usage target (strengthening target).

Further, in the game image shown in FIG. 11A, the action sequence table 65 is displayed on the left side. The action sequence table 65 shows the execution order of the actions of the objects 50 and 55. In the action sequence table 65, the icon images of the objects 50 and 55 are arranged in a row according to the execution order. At the top, icon images of objects 50 and 55 with the first (first) execution order are displayed. For example, in the game image shown in FIG. 12A, the execution order 1 is displayed as the player object 50A, and the execution order 10 is displayed as the enemy object 55A. In the example of this embodiment, the execution order up to the 10th is displayed in the action order table 65, but the number of displays can be arbitrarily set. The action sequence table 65 does not have to be displayed.

Next, a game image in a state of using coins will be described with reference to FIG. 11 (B). In the example of this embodiment, the larger the number of coins used, the more advantageous the boost action is executed in the command battle. That is, the number of coins used means the command enhancement level. In the example of this embodiment, the coins held by the user are used to strengthen the commands for the player objects 50A to 50D.

Further, in the example of the present embodiment, when the number of coins used is input by the user by operating the operation unit, it is determined that the usage request has been made. For example, when 2 is input as the number of coins used without the coin usage request shown in FIG. 11A, the display form of the command list 70 is changed as shown in the game image shown in FIG. 11B. Will be done. Specifically, the display form of the command list 70 is changed so that the user can identify the case where the boost item is requested to be used and the case where the boost item is not used.

In the command list 70 shown in FIG. 11 (B), an image of the box frame 720 different from the image of the box frame 72 of the command list 70 shown in FIG. 11 (A) is displayed. The upper part of the box frame 720 includes a coin icon image showing the number of uses (enhancement level). For example, in the box frame 720 shown in FIG. 11B, icon images of two coins are displayed, and it is specified that the number of used coins is 2. In addition, the display form of the command also changes. For example, in FIG. 11 (A), it is “fighting”, but in FIG. 11 (B), it is displayed as “fighting × 4”. "Strike x 4" is a state in which "fight" is strengthened, and is a display form of strengthening level 3 (number of coins used: 2) as shown in FIG.

Further, as shown in FIG. 11B, the "tokugi" and the "ability" have the same display form as in the state where there is no usage request. However, the display form of the command corresponding to "Tokugi" and "Ability" displayed after the cursor 71 moves to "Tokugi" and "Ability" is changed according to the enhancement level. For example, when the cursor 71 is moved to the "ability", in the game image of FIG. 12 (A) when there is no use, "Special Sword 1" is displayed, but when there is use, FIG. 12 (B) In the game image of, "Special Sword 3" is displayed. As shown in FIG. 14, "Special Sword 3" is a display form of enhancement level 3 (number of coins used: 2). The display form of "defense", which is not the target of strengthening, does not change.

The actions corresponding to each of the above commands are associated with the command table as shown in FIGS. 13 and 14. The command table is included in the game data stored in the storage unit of the terminal device 20E.

FIG. 13 is a diagram showing an example of the command table 90 of the command “Strike”. In the command table 90, the enhancement level, display data, and action data are registered in association with the command ID. The command ID is unique identification information given to each command. The enhancement level indicates the degree of enhancement of the command according to the number of coins used. At the enhancement level 1, the number of coins used is 0, and at the maximum level, the enhancement level 4, the number of coins used is 3. That is, the boost action is associated with the command of the enhancement level 2 to 4. The display data is data indicating the name of the command to be displayed in the command list 70, and is, for example, text data. The action data is data that specifies the content of the action to be executed by the player object 50, and is, for example, identification information that identifies the action. In the action data shown in FIGS. 13 and 14, the content of the action is displayed for convenience of explanation.

The display data and the action data are registered in association with the enhancement level. At the enhancement level 1 (“fighting”), the action of one physical attack by the weapon possessed by the player object 50 is associated. Further, at the enhancement level 2 (“fighting × 2”), the action of two physical attacks by the weapon possessed by the player object 50 is executed. Two physical attacks mean that the above-mentioned enhancement level 1 physical attack is executed twice. Therefore, the amount of damage given to the enemy object 55 is larger than that in the case of enhancement level 1. Further, at the enhancement level 3 (“fighting × 4”), the action of four physical attacks by the weapon possessed by the player object 50 is executed. Furthermore, at enhancement level 4 (“Ougi”), one mysterious attack is performed with the weapon in possession. The mysterious attack is an attack that deals more damage to the enemy object 55 than four physical attacks.

Next, FIG. 14 is a diagram showing an example of the command table 95 of the command “ability”. In the command table 95, the enhancement level, the display data, and the action data are registered in association with the command ID, as in the command table 90 of the above-mentioned “fighting”. In addition, a plurality of types of abilities are registered in the command table 95 of the "abilities" of the present embodiment.

In the command ID: C01, the commands of "Special Sword 1", "Special Sword 2", "Special Sword 3", and "Special Sword 4" are associated with each other according to the enhancement level. Each action is an attack that activates a special move using a sword, and the attack power (attack power parameter) is different from each other. That is, the higher the strengthening level, the higher the attack power. Therefore, the higher the enhancement level, the greater the amount of damage done to the same enemy object 50.

Also, with command ID: C02, "recovery magic", "recovery magic (1.5 times)", "total recovery magic (1.5 times)", "total recovery magic (1.5 times)", depending on the enhancement level. (Double) + Defense UP "command is associated. Each action is a recovery magic that recovers the vitality parameter of the player object 50, and any one of the recovery amount (effect generation amount), the number of targets to be recovered, and the incidental effect is different from each other.

For example, "recovery magic (1.5 times)" has 1.5 times the amount of recovery that recovers the vitality parameter of one player object 50 as compared with "recovery magic" of enhancement level 1. In addition, the amount of recovery of "Overall recovery magic (1.5 times)" is 1.5 times that of "Recovery magic" of enhancement level 1, but the vitality parameters of all player objects 50A to 55D of one party. To recover. Furthermore, "total recovery magic (1.5 times) + defense UP" has the same amount of recovery and number of targets (all) as "total recovery magic (1.5 times)", but player object 50A ~ An additional effect (incidental effect) that increases the defense power (defense power parameter) of 50D is also generated. If the defense power parameter is high, the amount of damage that the player object 50 receives from the enemy object 55 is reduced, which is advantageous in command battles.

The "item" command increases the number of times the item is used once, twice, three times, and four times according to the enhancement level. Further, in the example of the present embodiment, coins can be used for each player object 50. For example, the number of coins used can be set to 0 for the command of the player object 50A, and the number of coins used can be set to 2 for the command of the player object 50B.

Next, the configuration of the terminal device 20E will be described. FIG. 15 is a block diagram showing a configuration of a terminal device 20E, which is an example of the terminal device 20. In this example, the terminal device 20E includes at least a management unit 31E, a battle control unit 32E, and a display control unit 33E.

The management unit 31E manages the number of coins held in the storage unit of the terminal device 20E. In addition, the management unit 31E reduces the number of coins held according to the number of coins used by the user. Further, the management unit 31E increases the number of coins held each time the coin acquisition parameter increases and reaches the acquisition value as described above.

The coin acquisition parameter increases the number of coins held by 1 in exchange for subtracting the acquired value. In addition, the number of coins held and the coin acquisition parameters are managed only between the start and end of one command battle. Therefore, at the start of the next command battle, an initial value (for example, 4) is set for the number of coins held, and an initial value (for example, 0) is set for the coin acquisition parameter. Further, in the example of the present embodiment, the maximum number of coins held is set to 12.

The coin acquisition parameter increases according to, for example, the amount of damage that the player object 50 gives to the enemy object 55 and the amount of damage that the player object 50 receives from the enemy object 55. Specifically, a value of 50% of the above damage amount is added to the coin acquisition parameter.

Further, the coin acquisition parameter is increased, for example, when the enemy object 55 becomes incapable of fighting. Specifically, when one enemy object 55 becomes incapable of fighting, a value sufficient to acquire one coin is added to the coin acquisition parameter.

Further, the coin acquisition parameter increases according to, for example, the cumulative number of turns that arrive at the player objects 55A to 55D. That is, the coin acquisition parameters increase as the turns of the player objects 55A to 55D progress. The amount of increase for each turn may be, for example, an amount that allows one coin to be obtained after four turns. In this case, the number of coins held will increase by 1 every at least 4 turns. For example, if each of the player objects 55A to 55D executes an action once, four turns have passed, and the number of coins held is increased by one.

As mentioned above, the number of coins held increases according to the progress of the command battle, so the user should fight with the enemy object while considering the timing of coin use, the efficient method of increasing coins, etc. It becomes.

In the example of this embodiment, the number of coins held is increased by using the coin acquisition parameter, but any configuration can be used as long as the number of coins held is increased according to the progress of the command battle. May be good. In addition, it is not necessary to increase the number of coins held. For example, there is a configuration in which the number of coins that can be used for each command battle is fixed. Further, in the example of the present embodiment, the number of coins held is reset for each command battle, but it may be continuously managed without resetting.

The battle control unit 32E controls the progress of the turn-based command battle. For example, the battle control unit 32E causes the player object 50 to execute an action corresponding to a command selected by the user. As an action corresponding to the command, as illustrated in FIGS. 13 and 14, either a normal action or a boost action is executed according to the number of coins used. Further, the battle control unit 32E determines the action of the enemy object by lottery (action lottery) based on the action table. In the action table, information on a plurality of types of actions (command IDs) and winning probabilities are registered in association with each other. Since the structure of the action lottery of the enemy object is a general structure, detailed description thereof will be omitted.

Further, the battle control unit 32E determines the execution order of the actions of the player object 50 and the enemy object 55 in the command battle. FIG. 16 is a diagram showing an example of the execution order table 110. The execution order table 110 shown in FIG. 16 illustrates the execution order shown in the game images of FIGS. 11A and 11B.

The execution order table 110 stores the execution order of actions up to a predetermined order (for example, the 10th) of the player object 50 and the enemy object 55 in the command battle. In the command battle of the example of this embodiment, the player object 50 can fight with a maximum of 5, and the enemy object 55 can fight with a maximum of 5. The execution order table 110 is stored in the storage unit of the terminal device 20E. The battle control unit 32E determines the execution order based on the agility parameters of the player object 50 and the enemy object 55 at the start of the command battle, for example. Since the method of determining the execution order has a general configuration, detailed description thereof will be omitted.

In the execution order table 110, the object ID, the command ID, and the enhancement level are registered in association with the execution order. The object ID is unique identification information given to the object. In the execution order table 110 shown in FIG. 16, the names of the objects are displayed for convenience of explanation.

In the command ID, the command ID for each of the objects 50 and 55 is registered. In the case of the player object 50, a command (command ID) selected by the user is registered. In the case of the enemy object 55, a command (command ID) corresponding to the action determined by the battle control unit 32E is registered. As the enhancement level, the number of coins used by the user is registered. In the example of this embodiment, since the enemy object 55 does not have a boost action setting, a fixed value (for example, enhancement level 0) is set.

As shown in FIG. 16, for example, the player object 50A in the execution order 1 has the command ID “A01” and the enhancement level 3 is registered. Therefore, referring to the command table 90 shown in FIG. 13, the player object 50A performs an action corresponding to the command and executes a boost action of performing a physical attack four times. When the turn of the player object 50A in the execution order 1 is completed, the information of the player object 50A in the execution order 1 is deleted, and each execution order is moved up by one. Then, the information of the corresponding objects 50 and 55 is newly registered (added) in the execution order 10.

The battle control unit 32E of the example of the present embodiment generates the execution order table 110 at the start of the command battle, and determines the execution order (execution order 1 to 10) to be registered in the execution order table 110. The battle control unit 32 also registers the command ID of the enemy object 50 when the execution order table 110 is generated.

The command ID and enhancement level of the player object 50 in the execution order table 110 are registered when the user selects a command. In the example of the present embodiment, the battle control unit 32E selects commands for one turn for each of the player objects 50A to 50D constituting the party, and then follows the execution order for one turn of each of the objects 50 and 55. Action is carried out. Then, the selection of the command for the next one turn is required. Further, the battle control unit 32E updates the execution order table 110 every time the actions of the objects 50 and 55 of 1 are executed.

Next, the display control unit 33E will be described. The display control unit 33E generates a game image according to the progress of the game. In the command battle, a game image showing the battle situation of the player objects 50A to 50D and the enemy objects 55A to 55D as shown in FIGS. 11A and 11B is generated. In addition, the display areas 60 and 61, the command list 70, the execution order table 65, and the like are also displayed in the game image. The execution order table 65 is displayed based on the execution order table 110 described above. Further, as shown in FIGS. 11A and 11B, the display control unit 33E changes the display form of the command list 70 according to the presence or absence of a coin use request.

FIG. 17 is a flowchart showing an example of a battle progress process executed by the system 100. In the battle progress processing in this example, the progress processing of the command battle between the player object 50 and the enemy object 55 is performed. Hereinafter, a case where the terminal device 20E executes the battle progress process will be described as an example. The flowchart showing the operation of the server device will be omitted from the viewpoint of avoiding duplicate explanations.

The battle progress process of this example is executed, for example, when a command battle is started. The command battle is started when a start condition is satisfied, such as when a player object comes into contact with an enemy object in the game space.

In the battle progress process, the terminal device 20E sets the number of coins held and the coin acquisition parameter to the initial values (step S5-5E), and also generates the execution order table 100 and stores it in the storage unit (step S5-6E). ). In the process of step S5-6, as described above, the terminal device 20E determines the execution order and the command ID for the enemy object 55 to generate the execution order table 110. Next, the terminal device 20E causes the display unit to display a game image including the command list 70 (command selection image) in a display form in which there is no request to use coins (step S5-10E). Specifically, the terminal device 20E displays the command list 70 in the vicinity of the player object 50 to be command selected.

Next, the terminal device 20E determines whether or not the user is requested to use coins (step S10). In the example of this embodiment, whether or not there is a usage request is determined depending on whether the number of coins used is 0 or 1 or more. When it is determined that there is no usage request (step S10: NO), the terminal device 20E determines whether or not the user has selected (determined) a command (step S11-E). That is, the terminal device 20E determines whether or not a command is selected in the displayed command list 70. If it is determined that the command has not been determined (step S11-E: NO), the terminal device 20E returns to the process of step S5-10E and continues the display.

On the other hand, when it is determined that the command has been determined (step S11-E: YES), the terminal device 20E updates the execution order table 110 (step S14-5E). Specifically, the command ID and enhancement level of the corresponding player object 50 are registered based on the command selected by the user. When shifting from the processing of steps SS11-E, since there is no coin usage request, the number of coins used is 0 as the information on the enhancement level of the execution order table 110 registered together with the command ID. Strengthening level 1 indicating is set.

Next, the terminal device 20E determines whether or not the selection of commands for one turn for all of the player objects 50A to 50D constituting the party is completed (step S14-10E). If it is determined that the command selection is not completed (step S14-10E: NO), the terminal device 20E returns to the process of step S5-10E and returns to the command list 70 corresponding to the player object 50 in the next execution order. Is displayed. For example, the command list 70 corresponding to the player object 50 having the second fastest execution order is displayed on the game image.

On the other hand, when it is determined that the command selection is completed (step S14-10E: YES), the terminal device 20E executes the battle process (step S15-E). For example, based on the above-mentioned execution order table 110, command tables 90, 95, etc., each object 50, 55 is made to execute an action for one turn, and the state is displayed on the display unit as a game image.

The terminal device 20E causes the player object 50 to execute either a normal action or a boost action based on the command (command ID) and the enhancement level of the execution order table 110. Further, the battle control unit 32E calculates the damage amount, the recovery amount, and the like according to each executed action, and performs a process of increasing or decreasing the parameters of each object such as the vitality parameters of the player object and the enemy object. Since the parameter processing is a general configuration, detailed description thereof will be omitted. In addition, the terminal device 20E also updates the execution order table 110 as much as it is executed. For example, as described above, each time the objects 50 and 55 execute an action, the execution order is advanced by one.

On the other hand, when it is determined in the process of step S10 that there is a usage request, the terminal device 20E causes the display unit to display the command list 70 in a display form in which there is a coin usage request (step S10-20E). For example, when the command list 70 corresponding to the player object 50A shown in FIG. 11A is displayed, the command list 70 is changed to the command list 70 in the display form shown in FIG. 11B.

After that, the terminal device 20E determines whether or not the usage request is canceled (step S12). If it is determined that the usage request has been canceled (step S12: YES), the terminal device 20E returns to the process of steps S5-10E.

On the other hand, when there is no cancellation of the usage request (step S12: NO), the terminal device 20E determines whether or not the user's command is selected (determined) as in the process of steps S11-E (step S13-E). If it is determined that the command has not been determined (step S13-E: NO), the terminal device 20E returns to the process of step S10-20E.

On the other hand, when it is determined that the command has been determined (step S13-E: YES), the terminal device 20E updates (subtracts) the number of coins held according to the number of coins used in the determined command. Processing) (step S14). After that, the terminal device 20E updates the execution order table 110 as described above (step S14-5E). When shifting from the process of steps S14-E, since there is a coin usage request, the enhancement level information of the execution order table 100 registered together with the command ID is the enhancement level according to the number of coins used. 2 to 4 are set.

Then, the terminal device 20E determines whether or not the selection of commands for one turn for all the player objects 50A to 50D constituting the party is completed as described above (steps S14-10E). If it is determined that the command selection is not completed (step S14-10E: NO), the terminal device 20E returns to the process of step S5-10E and displays the command list 70 for the player object 50 in the next execution order. Let me. Therefore, the display form of the command list 70 of the player object 50 in the next execution order is basically displayed without a coin usage request.

On the other hand, when it is determined that the command selection is completed (step S14-10E: YES), the terminal device 20E executes the battle process as described above (step S15-E). afterwards. The terminal device 20E updates the number of coins held (increase processing) (steps S15-10E). For example, the terminal device 20E calculates the amount of increase in the coin acquisition parameter according to the progress of the battle such as the amount of damage given to the enemy object as described above. Then, after adding the increase amount to the current value of the coin acquisition parameter, the number of coins held is increased according to the current value of the coin acquisition parameter.

Next, the terminal device 20E determines whether or not the end condition of the command battle is satisfied (step S16-E). For example, the termination condition includes the annihilation of the opposing enemy object 55. That is, the command battle ends when the state of all the enemy objects 55 becomes incapable of fighting. Alternatively, it is also an end condition that the player object 50 is completely destroyed (becomes incapable of fighting). The termination condition is, for example, that all the enemy objects 55 are defeated (become incapable of fighting), or that all of the player objects 50 are defeated (become incapable of fighting). That is, the end condition is that the user (player object 50) wins or defeats the enemy object 55.

The terminal device 20E determines, for example, whether or not the end condition is satisfied based on the parameters of the objects 50 and 55 in the battle process of steps S15-E. When the end condition is satisfied (step S16-E: YES), the terminal device 20E ends the battle progress process. On the other hand, when the end condition is not satisfied (step S16-E: NO), the terminal device 20E returns to the process of step S5-10E and includes the command list 70 corresponding to the player object 50 in the earliest execution order. Display the game image.

As described above, as one aspect of the fifth embodiment, since the terminal device 20E is configured to include the management unit 31E, the battle control unit 32E, and the display control unit 33E, it depends on the number of coins (boost items) used. And the command is strengthened. As a result, the range of command choices is widened, so it is possible to expand the range of strategies while maintaining the basic battle method in command battles. Therefore, it is possible to improve the strategic nature of the user (player) in the command battle.

Further, since the command list 70 (command selection image) is displayed in a display form according to the presence or absence of a usage request, the user operates the operation unit while visually recognizing which display form the command selection image is. You can select commands. In addition, among the commands included in the command selection image, all the commands that can use coins can be visually recognized as if they were enhanced.

Furthermore, since the number of coins held increases according to the progress of the command battle, the user must select a command in consideration of the efficient increase in the number of coins held, and the user (player) in the command battle. It is possible to further improve the strategic nature of.

The display form of the command list 70 of the example of the fifth embodiment described above has been changed depending on whether or not coins are used, but the present invention is not particularly limited to this. The display form may be changed according to the number of coins used. For example, the color of the box image in the command list is changed according to the number of coins used. Alternatively, the shape size of the box image in the command list may be changed according to the number of coins used (the larger the number of coins used, the larger the size, etc.).

Further, in the example of the fifth embodiment described above, a plurality of player objects and enemy objects are fighting in the command battle, but the number of each object may be any one as long as it is one or more.

Further, in the example of the fifth embodiment described above, the coin is subtracted in step S14 after the command is determined, but the timing of the subtraction is not limited to this. For example, the process of steps S15-10E may be performed together.

Further, in the example of the fifth embodiment described above, the "defense" command has a configuration in which coins cannot be used, but it may be made available. For example, the use of coins may increase the defense parameter.

Further, in the example of the fifth embodiment described above, the battle process of steps S15-E is executed after the commands for one turn of all the player objects 50 constituting the party are selected. It is not limited to. For example, the battle process may be executed every time the command of one player object 50 is selected.

Further, in the example of the fifth embodiment described above, the input of the number of coins used is accepted for one player object 50, but the input is not particularly limited to this. For example, when the number of coins used is entered as 1, the command for all the player objects 50 constituting the party may be the enhancement level 2.

Further, in the example of the fifth embodiment described above, the command is determined using the command list 70, but the present invention is not particularly limited to this. Any configuration may be used as long as the user can select a command. For example, in the case of an operation unit (game pad) having a plurality of buttons, one command may be set for each button. In this case, the user can select a command by pressing the button corresponding to the desired command. Further, one command may be selected by a combination such as pressing a plurality of buttons at the same time or pressing them continuously.

[Sixth Embodiment]
FIG. 18 is a block diagram showing a configuration of a terminal device 20F, which is an example of the terminal device 20. In this example, the terminal device 20F includes at least a management unit 31F, a battle control unit 32F, and a display control unit 33F.

The management unit 31F manages the number of coins held in the storage unit of the terminal device 20E, as in the example of the fifth embodiment described above. Further, in the example of the present embodiment, a magic command that generates an effect of reducing the amount of damage of the player object 50 received by the attack from the enemy object 55 can be selected. For example, a magic that temporarily causes the above effect only during a command battle can be selected as a command in "Ability". In this case, the management unit 31F calculates the amount of increase in the coin acquisition parameter with respect to the amount of damage before it is mitigated by magic. In this case, the battle control unit 32F subtracts a predetermined percentage (for example, 10%) of the damage received from the enemy object 55 (correction amount) from the vitality parameter as the damage of the player object 50. ..

Therefore, the amount of damage received by the enemy object 55 received by 10% is reduced by the above magic. However, when the damage amount is reduced as described above, the management unit 31F calculates the increase amount of the coin acquisition parameter not by the correction amount but by the damage amount before the correction. Therefore, since there is no change in the value of the coin acquisition parameter that can be acquired, a strategy such as counterattacking after acquiring coins while actively reducing the amount of damage is also effective. The damage reduction by the "defense" command is the same as the above magic.

The battle control unit 32F controls the progress of the turn-based command battle as in the example of the fifth embodiment described above. Further, the battle control unit 32F of the example of the present embodiment selects either a normal action or a boost action as the action of the enemy object 55 according to the strengthening level. For example, the party of the enemy object 55 may also set the number of coins held and execute the boost action according to the number of used coins in the same manner as the user (player object). Then, the enhancement level of the enemy object 55 is also set in the execution order table 110 together with the command ID.

The action of the enemy object 55 is determined by a lottery (action lottery) based on the action table, for example, as in the example of the fifth embodiment. In addition to the action lottery, a lottery for strengthening level (strengthening lottery) is also held. Then, the boost action is set in the execution order table 110, and the number of possessions is subtracted according to the number of uses. The winning probability of each enhancement level can be set arbitrarily. In addition, if the number of coins held is insufficient compared to the number of coins used based on the result of the enhanced lottery, the use of coins will be cancelled. The battle control unit 32E also increases the number of coins held by the party of the enemy object 55 according to the progress of the command battle, as in the case of the player object 50 of the fifth embodiment, for the enemy object 55. You may.

The boosting action of the enemy object 55 may be configured so that coins are not used. For example, it may be decided whether to execute the normal action or the boost action based only on the result of winning in the strengthening lottery.

The display control unit 33F generates a game image according to the progress of the game, as in the example of the fifth embodiment described above. Also in the command battle, as in the example of the fifth embodiment, a game image showing the battle status of the player object 50 and the enemy object 55 is generated. Further, in the example of the present embodiment, as shown in FIG. 19, the turn in which the boost action of the enemy object 55 is executed is displayed in the execution order table 650 in a identifiable display form. FIG. 19 is a diagram showing an example of a game image of a command battle displayed on the display unit of the terminal device 20F. FIG. 19 is a game image of a command battle of player objects 50A to 50D and enemy objects 55A to 55D, similar to the game image of FIG. 11A described above.

For example, only the icon images of the sixth and tenth enemy objects 55C and 55A in the execution order table 650 shown in FIG. 19 are displayed in a color different from other icon images (for example, red). Therefore, the user selects a command for the player object 50 in consideration of the sixth and tenth enemy objects 55C and 55A executing some boosting action. That is, the user can implement some preventive measures by the turn when the boosting action of the enemy object 55 is performed.

In the execution order table 650 of the example of the present embodiment, only the presence or absence of execution of the boost action can be specified, and the specific content of the boost action cannot be specified. Therefore, for example, collecting information such as which enemy object 55 executes what kind of boost action is one of the strategies in the command battle. The specific content of the boost action may be displayed in the execution order table 650.

FIG. 20 is a flowchart showing an example of a battle progress process executed by the system 100. In the battle progress processing in this example, the progress processing of the command battle between the player object 50 and the enemy object 55 is performed. Hereinafter, a case where the terminal device 20F executes the battle progress process will be described as an example. The flowchart showing the operation of the server device will be omitted from the viewpoint of avoiding duplicate explanations.

The battle progress process of this example is executed, for example, when a command battle is started. The command battle is started when a start condition is satisfied, such as when a player object comes into contact with an enemy object in the game space.

In the battle progress process, the terminal device 20F sets the number of coins held and the coin acquisition parameters to the initial values (step S5-5E) as in the example of the fifth embodiment, and also generates the execution order table 110. It is stored in the storage unit (step S5-6F). As described above, the terminal device 20F determines the execution order, the command ID for the enemy object 55, and the enhancement level, and generates the execution order table 110.

Next, the terminal device 20F causes the display unit to display a game image including the command list 70 (command selection image) in a display form in which there is no request to use coins, as in the fifth embodiment described above (step S5-). 10F). Further, in the process of step S5-10F, the terminal device 20F displays the icon image of the execution order table 650 of the enemy object 55 in which the enhancement level 2 or higher is registered in the execution order table 110 in red.

Next, the terminal device 20F determines whether or not the user is requested to use the coin (boost item) (step S10). When it is determined that there is no usage request (step S10: NO), the terminal device 20F determines whether or not the user has selected (determined) a command (step S11-E). If it is determined that the command has not been determined (step S11-E: NO), the terminal device 20F returns to the process of step S5-10F and continues the display.

On the other hand, when it is determined that the command has been determined (step S11-E: YES), the terminal device 20F updates the execution order table 110 (step S14-5E). Next, the terminal device 20F determines whether or not the selection of commands for one turn for all of the player objects 50A to 50D constituting the party is completed (step S14-10E). If it is determined that the command selection is not completed (step S14-10E: NO), the terminal device 20F returns to the process of step S5-10F and returns to the command list 70 corresponding to the player object 50 in the next execution order. Is displayed on the game image.

On the other hand, when it is determined that the command selection is completed (step S14-10E: YES), the terminal device 20F executes the battle process in the same manner as in the fifth embodiment described above (step S15-F). In the example of the present embodiment, in the battle process, either the normal action or the boost action is executed for the enemy object based on the command (command ID) of the command table 110 and the strengthening level.

On the other hand, when it is determined in the process of step S10 that there is a usage request, the terminal device 20F displays the command list 70 in the display mode in which there is a coin usage request on the display unit, as in the fifth embodiment. (Step S10-20F). In the example of this embodiment, in the process of steps S10-20F, the icon image of the turn of the enemy object 55 in which the enhancement level 1 or higher is registered in the execution order table 110 is displayed in red as described above.

After that, the terminal device 20F determines whether or not the usage request is canceled (step S12). If it is determined that the usage request has been canceled (step S12: YES), the terminal device 20F returns to the process of steps S5-10F.

On the other hand, when there is no cancellation of the usage request (step S12: NO), the terminal device 20F determines whether or not the user's command is selected (determined) as in the process of step S11-E (step S13-E). If it is determined that the command has not been determined (step S13-E: NO), the terminal device 20F returns to the process of step S10-20F.

On the other hand, when it is determined that the command has been determined (step S13-E: YES), the terminal device 20F is stored in the storage unit of the terminal device 20F according to the number of coins used in the determined command. The number of coins held is updated (subtraction process) (step S14). After that, the terminal device 20F updates the execution order table 100 (step S14-5E).

Then, the terminal device 20F determines whether or not the selection of commands for one turn for all the player objects 50A to 50D constituting the party has been completed as described above (steps S14-10E). If it is determined that the command selection is not completed (step S14-10E: NO), the terminal device 20F returns to the process of step S5-10F and displays the command list 70 for the player object 50 in the next execution order in the game. Display on the image.

On the other hand, when it is determined that the command selection is completed (step S14-10E: YES), the terminal device 20F executes the battle process as described above (step S15-F). afterwards. The terminal device 20F updates the number of coins held (increase processing) (step S15-10F) as in the fifth embodiment. In the example of the present embodiment, in the process of steps S15-10F, as described above, when the damage amount received from the enemy object 55 is corrected, the coin acquisition parameter is adjusted according to the damage amount before the correction. The amount of increase in is calculated.

Next, the terminal device 20F determines whether or not the end condition of the command battle is satisfied (step S16-E). When the end condition is satisfied (step S16-E: YES), the terminal device 20F ends the battle progress process. On the other hand, when the end condition is not satisfied (step S16-E: NO), the terminal device 20F returns to the process of step S5-10F.

As described above, as one aspect of the sixth embodiment, the terminal device 20F is configured to include the management unit 31F, the battle control unit 32F, and the display control unit 33F, so that it depends on the number of coins (boost items) used. And the command is strengthened. As a result, the range of command choices is widened, so it is possible to expand the range of strategies while maintaining the basic battle method in command battles. Therefore, it is possible to improve the strategic nature of the user (player) in the command battle.

Further, since the command list 70 (command selection image) is displayed in a display form according to the presence or absence of a usage request, the user operates the operation unit while visually recognizing which display form the command selection image is. You can select commands. In addition, among the commands included in the command selection image, all the commands that can use coins can be visually recognized as if they were enhanced.

Furthermore, since the number of coins held increases according to the progress of the command battle, the user must select a command in consideration of the efficient increase in the number of coins held, and the user (player) in the command battle. It is possible to further improve the strategic nature of. Moreover, since the increase amount of the coin acquisition parameter is calculated based on the damage amount before the correction, the value of the coin acquisition parameter itself that can be acquired does not change even if the damage amount received by the player object 50 is reduced. Therefore, it is effective to take a strategy such as counterattacking after earning coins while actively reducing the amount of damage.

Further, since the execution order table 650 displays whether or not the boost action of the enemy object 55 is executed, the user can implement some preventive measures before the boost action of the enemy object 55 is performed.

In the example of the sixth embodiment described above, the presence or absence of execution of the boost action of the enemy object 55 in the execution order table 650 is displayed, but the display mode is not limited to the above-described embodiment. For example, the display form may be such that the icon image blinks.

It should be noted that the concept of objects in the above-mentioned examples of the first to sixth embodiments includes various objects such as characters, avatars, and fighters. Further, in this embodiment, the game program also includes game data such as image data for generating each object.

In addition, the number of player objects and enemy objects in the above-described first to sixth embodiments may be one or more.

Further, as a game having the command battle of the examples of the first to sixth embodiments described above, for example, there is a role-playing game, but what if it is a video game in which the user is required to input a command. It may be anything.

Further, the update of the number of possessed boost items in the above-mentioned examples of the first to sixth embodiments is not limited to the timing in the above-described embodiment.

Further, the number of possessions of the above-mentioned examples of the first to sixth embodiments may be managed for each user or for each player object. For example, the number of possession of each boost item of a plurality of player objects may be managed, and the corresponding number of possessions may be maximized so that the command of the player object can be strengthened. Alternatively, the number of possessions may be managed for each user so that it can be used to strengthen the commands of each of a plurality of player objects.

Further, the number of units of the boost item when strengthening one command of the above-mentioned examples of the first to sixth embodiments does not have to be one, and can be set arbitrarily. In addition, the initial value of boost items and the maximum number of possessions can be set arbitrarily.

[Additional Notes]
The description of the above-described embodiment describes at least the following invention so that a person having ordinary knowledge in the field to which the invention belongs can carry out the invention.

[1]
A game program for a computer to realize a function to control the progress of a video game including a command battle between a player object and an enemy object.
A management function that manages the number of boost items used in the command battle,
A battle control function that controls the enemy object and causes the player object to execute an action corresponding to a command selected by the user via an operation unit to control the progress of the command battle.
Realized,
In the battle control function, when the user requests the use of the boost item via the operation unit, the command battle is performed as an action corresponding to the selected command rather than the action when the use request is not made. Ability to perform advantageous boost actions in
In the management function, a function of reducing the number of possessed items according to the number of used boost items,
A game program that realizes.

[2]
In the battle control function, the larger the number of the boost items used per command included in the usage request, the more advantageous the boost action is executed in the command battle.
The game program described in [1] for realizing the above.

[3]
In the management function, a function of increasing the number of possessions according to the progress of the command battle,
The game program according to [1] or [2] for realizing the above.

[4]
On the computer,
In the command battle, it is a function of displaying a command selection image including one or more commands that can be selected by the user via the operation unit on the display unit, and is a display form in which the user can specify the presence or absence of the usage request. Display control function to display the command selection image with
Realized,
In the battle control function, a function of executing the boost action as an action corresponding to a command selected based on the command selection image in the display form when the usage request is made.
The game program according to any one of [1] to [3] for realizing the above.

[5]
In the display control function, a function of displaying the command selection image in a display form according to the number of uses of the boost item per command included in the usage request.
The game program described in [4] for realizing the above.

[6]
The display form of the command selection image when the usage request is made includes a display form in which the user can specify a command that can use the boost item among one or more selectable commands.
The game program according to [4] or [5].

[7]
The display form of the command selection image when the usage request is made includes a display form capable of specifying the number of uses of the boost item per command included in the usage request.
The game program according to any one of [4] to [6].

[8]
In the battle control function, the vitality parameter of the enemy object is reduced based on the execution of the attack action included in the action of the player object, and the vitality parameter of the player object is reduced based on the attack action of the enemy object. ,
In the management function, the function of increasing the number of possessions according to the amount of decrease in the vitality parameter of the enemy object due to the attack action of the player object, and the incapacitated state in which the vitality parameter of the enemy object reaches a predetermined value. At least one of a function of increasing the number of possessions according to the situation and a function of increasing the number of possessions according to the amount of decrease in the vitality parameter of the player object due to the attacking action of the enemy object.
The game program described in [3] for realizing the above.

[9]
In the battle control function, a function of performing a correction for reducing a decrease in a vitality parameter of the player object due to an attack action of the enemy object according to a predetermined condition.
In the management function, the function of increasing the number of possessions according to the amount of decrease before the correction,
The game program according to [8] for realizing the above.

[10]
The battle control function is a function of controlling the progress of a turn-based command battle in which the player object executes an action corresponding to a command selected by the user based on the command selection image in the user's turn.
In the management function, a function of increasing the number of possessions according to the cumulative number of turns of the user in the command battle,
The game program described in [4] for realizing the above.

[12]
In the management function, after the user has made the usage request and the selection of the command, the function of reducing the number of possessions according to the number of usage of the boost item for the selected command.
The game program according to any one of [1] to [11] for realizing the above.

[13]
In the management function, the number of possessions is managed between the start and the end of the command battle, and the number of possessions is set to an initial value each time the command battle is started.
The game program according to any one of [1] to [12] for realizing the above.

[14]
The boost action is at least one of the number of executions, the amount of effect generated in the command battle, the number of objects on which the effect acts, and the number of occurrences of the effect, as compared with the action when there is no request to use the boost item. Is an action that has increased
The game program according to any one of [1] to [13].

[15]
In the battle control function,
A function of determining the execution order of actions of the player object and the enemy object in the command battle,
A function that causes the enemy object to perform the boost action based on a predetermined condition.
In the display control function,
A function of displaying the execution order on the display unit, and displaying the execution order in a display form capable of identifying the enemy object that executes the boost action.
The game program according to any one of [1] to [14] for realizing the above.

[16]
A server device characterized in that the game program described in any one of [1] to [15] is installed.

[17]
It is a terminal program for realizing a function of displaying a game screen on the display screen of a display device and controlling the progress of a video game on the game terminal device.
In the game terminal device
A connection function for connecting to the server device according to [16] via a communication network.
A program for terminals to realize.

[18]
A game program for controlling the progress of a video game by a server device connected by a communication network to a game terminal device that executes a video game including a command battle between a player object and an enemy object.
In the server device
A management function that manages the number of boost items used in the command battle,
A battle control function that controls the enemy object and causes the player object to execute an action corresponding to a command selected by the user via an operation unit to control the progress of the command battle.
Realized,
In the battle control function, when the user requests the use of the boost item via the operation unit, the command battle is performed as an action corresponding to the selected command rather than the action when the use request is not made. Ability to perform advantageous boost actions in
In the management function, a function of reducing the number of possessed items according to the number of used boost items,
A game program that realizes.

[19]
In the battle control function, the larger the number of the boost items used per command included in the usage request, the more advantageous the boost action is executed in the command battle.
The game program according to [18] for realizing the above.

[20]
In the management function, a function of increasing the number of possessions according to the progress of the command battle,
The game program according to [18] or [19] for realizing the above.

[21]
In addition to the server device
In the command battle, it is a function of displaying a command selection image including one or more commands that can be selected by the user via the operation unit on the display unit, and is a display form in which the user can specify the presence or absence of the usage request. Display control function to display the command selection image with
Realized,
In the battle control function, a function of executing the boost action as an action corresponding to a command selected based on the command selection image in the display form when the usage request is made.
The game program according to any one of [18] to [22] for realizing the above.

[22]
In the display control function, a function of displaying the command selection image in a display form according to the number of uses of the boost item per command included in the usage request.
The game program according to [21] for realizing the above.

[23]
The display form of the command selection image when the usage request is made includes a display form in which the user can specify a command that can use the boost item among one or more selectable commands.
The game program according to [21] or [22].

[24]
The display form of the command selection image when the usage request is made includes a display form capable of specifying the number of uses of the boost item per command included in the usage request.
The game program according to any one of [21] to [23].

[25]
In the battle control function, the vitality parameter of the enemy object is reduced based on the execution of the attack action included in the action of the player object, and the vitality parameter of the player object is reduced based on the attack action of the enemy object. ,
In the management function, the function of increasing the number of possessions according to the amount of decrease in the vitality parameter of the enemy object due to the attack action of the player object, and the incapacitated state in which the vitality parameter of the enemy object reaches a predetermined value. At least one of a function of increasing the number of possessions according to the situation and a function of increasing the number of possessions according to the amount of decrease in the vitality parameter of the player object due to the attacking action of the enemy object.
The game program according to [20] for realizing the above.

[26]
In the battle control function, a function of performing a correction for reducing a decrease in a vitality parameter of the player object due to an attack action of the enemy object according to a predetermined condition.
In the management function, the function of increasing the number of possessions according to the amount of decrease before the correction,
The game program according to [25] for realizing the above.

[27]
The battle control function is a function of controlling the progress of a turn-based command battle in which the player object executes an action corresponding to a command selected by the user based on the command selection image in the user's turn.
In the management function, a function of increasing the number of possessions according to the cumulative number of turns of the user in the command battle,
The game program according to [21] for realizing the above.

[28]
In the management function, after the user has made the usage request and the selection of the command, the function of reducing the number of possessions according to the number of usage of the boost item for the selected command.
The game program according to any one of [18] to [27] for realizing the above.

[29]
In the management function, the number of possessions is managed between the start and the end of the command battle, and the number of possessions is set to an initial value each time the command battle is started.
The game program according to any one of [18] to [28] for realizing the above.

[30]
The boost action is at least one of the number of executions, the amount of effect generated in the command battle, the number of objects on which the effect acts, and the number of occurrences of the effect, as compared with the action when there is no request to use the boost item. Is an action that has increased
The game program according to any one of [18] to [29].

[31]
In the battle control function,
A function of determining the execution order of actions of the player object and the enemy object in the command battle,
A function that causes the enemy object to perform the boost action based on a predetermined condition.
In the display control function,
A function of displaying the execution order on the display unit, and displaying the execution order in a display form capable of identifying the enemy object that executes the boost action.
The game program according to any one of [18] to [30] for realizing the above.

[32]
A game system including a game terminal device for executing a video game including a command battle between a player object and an enemy object, and a server device connected to the game terminal device via a communication network.
A management means for managing the number of boost items used in the command battle,
A battle control means that controls the enemy object and causes the player object to execute an action corresponding to a command selected by the user via an operation unit to control the progress of the command battle.
Including
When the user requests the use of the boost item via the operation unit, the battle control means performs the command battle as an action corresponding to the selected command rather than the action when the use request is not made. To perform a favorable boost action in
The management means reduces the number of possession items according to the number of use of the boost item.
Game system.

[33]
The battle control means causes a more advantageous boost action to be executed in the command battle as the number of uses of the boost item per command included in the usage request increases.
The game system according to [32].

[34]
In the management function, the number of possessions is increased according to the progress of the command battle.
The game system according to [32] or [33].

[35]
In the command battle, it is a means for displaying a command selection image including one or more commands that can be selected by the user via the operation unit on the display unit, and is a display form in which the user can specify the presence or absence of the usage request. Further includes a display control means for displaying the command selection image in
The battle control means executes the boost action as an action corresponding to a command selected based on the command selection image in the display form when the usage request is made.
The game system according to any one of [32] to [34].

[36]
The display control means displays the command selection image in a display form according to the number of uses of the boost item per command included in the usage request.
The game system according to [35].

[37]
The display form of the command selection image when the usage request is made includes a display form in which the user can specify a command that can use the boost item among one or more selectable commands.
The game program according to [35] or [36].

[38]
The display form of the command selection image when the usage request is made includes a display form capable of specifying the number of uses of the boost item per command included in the usage request.
The game system according to any one of [35] to [37].

[39]
The battle control means reduces the vitality parameter of the enemy object based on the execution of the attack action included in the action of the player object, and reduces the vitality parameter of the player object based on the attack action of the enemy object.
The management means increases the number of possessions according to the amount of decrease in the vitality parameter of the enemy object due to the attacking action of the player object, and the enemy object becomes incapable of fighting when the vitality parameter reaches a predetermined value. At least one of a process of increasing the number of possessions and a process of increasing the number of possessions according to the amount of decrease in the vitality parameter of the player object due to the attacking action of the enemy object is performed.
The game system according to [34].

[40]
The battle control means makes a correction to reduce the decrease amount of the vitality parameter of the player object due to the attack action of the enemy object according to a predetermined condition.
The management means increases the number of possessions according to the amount of decrease before the correction.
The game system according to [39].

[41]
The battle control means controls the progress of a turn-based command battle that causes the player object to execute an action corresponding to a command selected by the user based on the command selection image in the user's turn.
The management means increases the number of possessions according to the cumulative number of turns of the user in the command battle.
The game program according to [34].

[42]
The management means reduces the number of possessions according to the number of uses of the boost item for the selected command after the user has made the usage request and the selection of the command.
The game program according to any one of [32] to [41].

[43]
The management means manages the number of possessions between the start and the end of the command battle of 1, and sets the number of possessions to an initial value each time the command battle is started.
The game program according to any one of [32] to [42].

[44]
The boost action is at least one of the number of executions, the amount of effect generated in the command battle, the number of objects on which the effect acts, and the number of occurrences of the effect, as compared with the action when there is no request to use the boost item. Is an action that has increased
The game program according to any one of [32] to [43].

[45]
The battle control means
The execution order of the actions of the player object and the enemy object in the command battle is determined.
Based on a predetermined condition, the enemy object is made to perform the boost action,
The display control means
It is a function of displaying the execution order on the display unit, and displays the execution order in a display form capable of identifying the enemy object that executes the boost action.
The game program according to any one of [32] to [44].

[46]
A game terminal device that controls the progress of a video game including a command battle between a player object and an enemy object.
A management means for managing the number of boost items used in the command battle,
A battle control means that controls the enemy object and causes the player object to execute an action corresponding to a command selected by the user via an operation unit to control the progress of the command battle.
Including
When the user requests the use of the boost item via the operation unit, the battle control means performs the command battle as an action corresponding to the selected command rather than the action when the use request is not made. To perform a favorable boost action in
The management means reduces the number of possession items according to the number of use of the boost item.
Game terminal device.

[47]
A game progress control method in which a computer controls the progress of a video game including a command battle between a player object and an enemy object.
Management process that manages the number of boost items used in the command battle,
A battle control process that controls the enemy object and causes the player object to execute an action corresponding to a command selected by the user via the operation unit to control the progress of the command battle.
Including
In the battle control process, when the user requests the use of the boost item via the operation unit, the command battle is performed as an action corresponding to the selected command rather than the action when the use request is not made. Processing to execute advantageous boost action in
In the management process, a process of reducing the number of possessed items according to the number of used boost items.
Game progress control method including.

According to one of the embodiments of the present invention, it is useful for providing a function of improving the strategic nature of a user (player) in a command battle.

20 Terminal device 31 Management unit 32 Battle control unit 33 Display control unit 50 (50A to 50D) Player object 55 (55A to 55D) Enemy object 65,650 Action sequence table 70 Command list (command selection image)
100 game system

Claims (1)

A game program for a computer to realize a function to control the progress of a video game including a turn-based battle between a player object and an enemy object.
A battle control function that determines the execution order of actions of the player object and the enemy object in the turn-based battle and controls the progress of the turn-based battle.
A reception function that accepts the number of used items for each player object,
Realized,
In the battle control function, the more the number of times the predetermined item is used, the more the number of actions of the player object in one turn is increased.
A game program that realizes.