Game program, information processing system, game processing method, and information processing device.

Abstract

In combat scenarios, players will be able to specify commands even if the conditions for them are not met, under certain circumstances. [Solution] In a battle scene in a game, if a first instruction specifies one of several types of commands and the state of the specified command is usable, the information processing system causes the player character to perform the action associated with the command, transitions the command to an unusable state, and resets the first parameter associated with the command. If a second instruction specifies a command that is in an unusable state and it is possible to consume the second parameter, the information processing system consumes the second parameter, causes the player character to perform the action associated with the command, sets the command to an unusable state, and resets the first parameter associated with the command.

Description

Technical Field

[0001] The present invention relates to a game program, an information processing system, a game processing method, and an information processing device for executing a game in which a player character and an enemy character fight.

Background Art

[0002] Conventionally, in a battle scene between a player character and an enemy character, there is a game that causes the player character to perform an action according to a command specified by the player (for example, see Non-Patent Document 1).

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] Depending on the type of command, it may be necessary to satisfy conditions such as the elapse of a certain time until the same command can be specified again after the command is specified. For such types of commands, since the conditions have not been satisfied since the command was previously specified, the player may not be able to specify the command at the timing desired by the player during the game.

[0005] Therefore, an object of the present invention is to provide a game program, an information processing system, a game processing method, and an information processing device that allow a player to specify a command that does not satisfy the conditions under certain conditions.

Means for Solving the Problems

[0006] To solve the above problems, the present invention employs the following configurations (1) to (10).

[0007] (1) One example of the present invention is a game program that causes a computer to perform the following processes. In a game's combat scene between a player character and an enemy character, a first instruction based on input specifies one of several types of commands. If the state of the specified command is in the usable state (out of usable and unusable states), the player character performs the action associated with that command, transitions the command to the unusable state, resets the first parameter associated with that command (one of the first parameters set for each command), updates the first parameter for each unusable command according to the game's progress, and if the first parameter satisfies the first condition, transitions the command associated with that first parameter to the usable state. In the above combat scene, if a command is designated as unusable by a second instruction based on the input, and it is possible to consume the second parameter, the process involves consuming the second parameter, having the player character perform the action associated with the command, setting the command to unusable, and resetting the first parameter associated with the command.

[0008] According to the configuration described in (1) above, in a game where conditions are set for reusing a command, it is possible to allow the player to specify a command even if those conditions are not met, under certain conditions.

[0009] (2) In the configuration described in (1) above, the game program may cause the computer to update the first parameter for each command that is unavailable, as time progresses, as part of the game's progression.

[0010] According to the configuration in (2) above, if the second parameter can be consumed, the player can use the command without waiting for time to pass.

[0011] (3) In the configuration described in (2) above, the first condition may be satisfied when a time period of a length set for each command has elapsed since the first parameter was reset.

[0012] According to the configuration described in (3) above, the time required for the first parameter to satisfy the first condition can be set for each command.

[0013] (4) In any of the configurations described in (1) to (3) above, the game program may cause the computer to consume the second parameter by reducing it by a certain amount if a command that is in an unusable state is specified by the second instruction, and the remaining second parameter is equal to or greater than the amount of reduction corresponding to the shortfall in the first parameter of the command at that time until it satisfies the first condition.

[0014] According to the configuration described in (4) above, the command can be enabled by consuming an amount of the second parameter corresponding to the deficiency of the first parameter.

[0015] (5) In any of the configurations described in (1) to (4) above, the game program may instruct the computer to restore the second parameter after the end of a battle scene.

[0016] According to the configuration in (5) above, it becomes easier to consume the second parameter in each battle scene.

[0017] (6) In the configuration described in (5) above, the game program may prevent the computer from recovering the second parameter during a battle.

[0018] According to the configuration of (6) above, it is possible to impose a limit on the consumption of the second parameter in one combat scene. Therefore, for simple combat scenes such as battles against weak enemy characters, combat can proceed smoothly, and for challenging combat scenes such as battles against strong enemy characters, strategic combat can be provided without making the combat too easy.

[0019] (7) In any of the configurations from (1) to (6) above, the game program may cause the computer to not recover the second parameter during the combat scene, recover the second parameter to its maximum value after the end of the combat scene, and increase the maximum value of the second parameter in a predetermined scene in the game.

[0020] According to the configuration of (7) above, by giving the player an opportunity to increase the maximum value of the second parameter, it is possible to motivate the player to advance the game.

[0021] (8) In any of the configurations from (1) to (7) above, the game program may further cause the computer to display, for each command, an icon indicating whether it is in an available state or an unavailable state, and the first parameter in the unavailable state, and a gauge indicating the second parameter.

[0022] According to the configuration of (8) above, the player can check the state of the command and determine whether to use a command in the unavailable state by consuming the second parameter, referring to the current value of the second parameter.

[0023] (9) In the configuration of (8) above, the first instruction may be an instruction for specifying by causing a command to be selected based on a direction input and causing the selected command to be determined in response to a first button input. The second instruction may be an instruction for specifying by causing a command to be selected based on a direction input and causing the selected command to be determined in response to a second button input. The game program may further cause the computer to display an index indicating whether it is possible to consume a second parameter for each selected command.

[0024] According to the configuration of (9) above, it is possible to present to the player whether a command in an unusable state can be used by consuming a second parameter.

[0025] (10) In any of the configurations of (1) to (9) above, the game program may further cause the computer to make the effect of the action corresponding to the first command among a plurality of types of commands higher during a period in which a second condition regarding the battle situation is satisfied than during a period in which the second condition is not satisfied.

[0026] According to the configuration of (10) above, a situation occurs in which a specific command becomes effective in the game during a specific period, and in such a situation, it is possible to make it easier to use the command.

[0027] Note that another example of the present invention may be an information processing apparatus or an information processing system that executes the processing in (1) to (10) above. Another example of the present invention may be a game processing method that causes the information processing system to execute the processing in (1) to (10) above.

Effects of the Invention

[0028] According to the game program, information processing system, game processing method, or information processing apparatus described above, even for a command that does not satisfy the conditions, the player can specify it under certain conditions.

Brief Description of the Drawings

[0029] [Figure 1] A diagram showing an example of a game system. [Figure 2] Block diagram showing an example of the internal configuration of the main unit. [Figure 3] This figure shows an example of a game image from a combat scene executed within the game system. [Figure 4] This diagram shows an example of how the appearance of action command icons can change. [Figure 5] This diagram shows an example of a game image in a situation where commands based on the consumption of recast parameters can be used. [Figure 6] This image shows an example of a game screenshot illustrating a situation where it is impossible to use commands based on the consumption of recast parameters. [Figure 7] This diagram shows an example of a game image in a situation where an enemy character has fallen over. [Figure 8] This diagram shows an example of a game image where a message from a companion character is displayed. [Figure 9] This diagram shows an example of various types of data used in information processing within a game system. [Figure 10] A flowchart illustrating an example of the flow of combat scene processing performed by the game system. [Figure 11] Figure 10 shows a subflowchart illustrating an example of a detailed flow of the command control process in step S2. [Figure 12] Figure 10 shows a subflowchart illustrating an example of a detailed flow of the command control process in step S2. [Modes for carrying out the invention]

[0030] [1. Game System Configuration] The following describes a game system according to an example of this embodiment. Figure 1 is a diagram showing an example of the game system. The example of the game system 1 in this embodiment includes a main unit (information processing device; in this embodiment, it functions as the main unit of the game device) 2, a left controller 3, and a right controller 4. The main unit 2 is a device that performs various processes (for example, game processing) in the game system 1. The left controller 3 and the right controller 4 include a plurality of buttons and an analog stick as an example of an operation unit for user input.

[0031] The main unit 2 is configured so that the left controller 3 and the right controller 4 can be attached and detached. In other words, the game system 1 can be used as an integrated device by attaching the left controller 3 and the right controller 4 to the main unit 2, or the main unit 2 and the left controller 3 and the right controller 4 can be used as separate units. In the following, the left controller 3 and the right controller 4 will be collectively referred to as "controllers".

[0032] Figure 2 is a block diagram showing an example of the internal configuration of the main unit 2. As shown in Figure 2, the main unit 2 includes a processor 21. The processor 21 is an information processing unit that performs various information processing (e.g., game processing) in the main unit 2, and includes, for example, a CPU (Central Processing Unit) and a GPU (Graphics Processing Unit). The processor 21 may consist only of a CPU, or it may consist of a SoC (System-on-a-chip) that includes multiple functions such as CPU functions and GPU functions. The processor 21 performs various information processing by executing information processing programs (e.g., game programs) stored in a storage unit (specifically, an internal storage medium such as flash memory 26, or an external storage medium installed in slot 29).

[0033] The main unit 2 also includes a display 12. The display 12 displays images generated by the main unit 2. In this embodiment, the display 12 is a liquid crystal display (LCD). However, the display 12 may be any type of display device. The display 12 is connected to the processor 21. The processor 21 displays images generated (for example, by executing the above-mentioned information processing) and / or images acquired from an external source on the display 12.

[0034] Furthermore, the main unit 2 is equipped with a left terminal 23, which is a terminal for the main unit 2 to communicate with the left controller 3 via wired connection, and a right terminal 22, which is for the main unit 2 to communicate with the right controller 4 via wired connection.

[0035] Furthermore, the main unit 2 includes a flash memory 26 and a DRAM (Dynamic Random Access Memory) 27 as examples of internal storage media built into it. The flash memory 26 and DRAM 27 are connected to the processor 21. The flash memory 26 is a memory mainly used to store various types of data (which may be programs) stored in the main unit 2. The DRAM 27 is a memory used to temporarily store various types of data used in information processing.

[0036] The main unit 2 is equipped with a slot 29. The slot 29 has a shape that allows a predetermined type of storage medium to be inserted. The predetermined type of storage medium is, for example, a storage medium (e.g., a dedicated memory card) dedicated to the game system 1 and similar information processing devices. The predetermined type of storage medium is used to store, for example, data used by the main unit 2 (e.g., save data for game applications, etc.) and / or programs executed by the main unit 2 (e.g., game programs, etc.).

[0037] The main unit 2 is equipped with a slot interface (hereinafter abbreviated as "I / F") 28. The slot I / F 28 is connected to the processor 21. The slot I / F 28 is connected to slot 29 and reads and writes data to a predetermined type of storage medium (for example, a dedicated memory card) installed in slot 29, according to instructions from the processor 21.

[0038] The processor 21 performs the above-mentioned information processing by appropriately reading and writing data to and from the flash memory 26 and DRAM 27, as well as to each of the above-mentioned storage media.

[0039] Furthermore, the main unit 2 includes a network communication unit 24. The network communication unit 24 is connected to the processor 21. The network communication unit 24 communicates with external devices wirelessly or via wired connection over a network. In this embodiment, as a first communication mode, the network communication unit 24 connects to a wireless LAN and communicates with external devices using a method compliant with the Wi-Fi® standard. In addition, as a second communication mode, the network communication unit 24 performs wireless communication with other main unit 2 of the same type using a predetermined communication method (for example, communication using a proprietary protocol or infrared communication). The wireless communication using the second communication mode is possible with other main unit 2 located within a closed local network area, and realizes a function that enables so-called "local communication" in which data is transmitted and received by communicating directly or indirectly via access points between multiple main unit 2.

[0040] The main unit 2 includes a controller communication unit 25. The controller communication unit 25 is connected to the processor 21. The controller communication unit 25 communicates wirelessly with the left controller 3 and / or the right controller 4 when they are detached from the main unit 2. The communication method between the main unit 2 and the left controller 3 and the right controller 4 is arbitrary, but in this embodiment, the controller communication unit 25 communicates with the left controller 3 and the right controller 4 in accordance with the Bluetooth® standard.

[0041] The processor 21 is connected to the left terminal 23 and the right terminal 22 described above. When the processor 21 communicates with the left controller 3 via a wired connection, it transmits data to the left controller 3 via the left terminal 23 and receives operation data from the left controller 3 via the left terminal 23. Similarly, when the processor 21 communicates with the right controller 4 via a wired connection, it transmits data to the right controller 4 via the right terminal 22 and receives operation data from the right controller 4 via the right terminal 22. Thus, in this embodiment, the main unit 2 can perform both wired and wireless communication with the left controller 3 and the right controller 4, respectively.

[0042] In addition to the elements shown in Figure 2, the main unit 2 also includes a battery for supplying power and output terminals for outputting images and sound to a display device other than the display 12 (for example, a television).

[0043] [2. Overview of processing in the game system] Next, with reference to Figures 3 to 8, an overview of the game processing performed in game system 1 will be described. In this embodiment, game system 1 executes a game that includes a battle scene in which a player character, controllable by the player (also called the user), engages in combat with an enemy character.

[0044] Figure 3 shows an example of a game image in a battle scene executed in game system 1. As shown in Figure 3, in this embodiment, player character 31 and enemy character 35 appear in the virtual game space. In this embodiment, companion characters 32-34, who are allies of player character 31, also appear in the battle scene. In other embodiments, companion characters 32-34 do not need to appear.

[0045] The player controls the player character 31 through inputs to the controller. For example, the player character moves in the game space in a direction specified by the input to the analog stick of the left controller 3. The player character also takes actions associated with commands specified by the player through inputs. Commands include actions such as attacking enemy character 35 or healing player character 31 or allied characters 32-34.

[0046] In this embodiment, in addition to attacks by the above command, the player character 31 automatically performs attacks on the enemy character 35 (hereinafter referred to as "normal attacks"). For example, if the enemy character 35 is within the attack range of the player character 31, the game system 1 controls the player character 31 to perform normal attacks on the enemy character 35 at predetermined time intervals, independently of instructions from the player. In other embodiments, the game system 1 may cause the player character 31 to perform normal attacks in response to the player's input for instructing a normal attack. Among the actions that the player character 31 can take, there may or may not be actions that are automatically controlled by the game system 1.

[0047] In this embodiment, the actions of the allied characters 32-34 and the enemy character 35 are automatically controlled by the game system 1. For example, allied characters 32-34 may move around the game space, attack the enemy character 35, or heal the player character 31, themselves, or other allied characters. The enemy character 35 may move around the game space and attack the player character 31 or allied characters 32-34. The number of enemy characters in a battle scene is arbitrary, and multiple enemy characters may appear. In other embodiments, allied characters 32-34 may also be controllable by the player. For example, in a battle scene, the character controlled by the player may be switched from character 31 to one of the other characters 32-34 in response to a predetermined input from the player.

[0048] As described above, in the battle scene of this embodiment, while each character 32-35 acts automatically and the battle progresses, the player can control player character 31, allowing the battle to proceed in real time.

[0049] As shown in Figure 3, the game images representing the battle scene include UI images related to game operations in the battle scene, in addition to images representing the game space in which each character appears. In the example shown in Figure 3, the game images include player character-related images 36 and enemy character-related images 37 as UI images. The player character-related images 36 show the status of player character 31 and companion characters 32-34. The player character-related images 36 include, for example, gauges showing the health of each character 31-34 and images showing the current status of each character 31-34. The enemy character-related images 37 show the status of enemy character 35. The enemy character-related images 37 include, for example, a gauge showing the health of enemy character 35 and images showing the current status of enemy character 35.

[0050] In the example shown in Figure 3, the game image includes command icons 40-48 and a cursor 51 as a UI image. Each of the command icons 40-48 represents a command in the game. In this embodiment, the game system 1 moves the cursor 51 in response to a selection input to the controller, and the command icon pointed to by the cursor 51 becomes the selected command icon. In the example shown in Figure 3, the command icons 40-48 are arranged side by side in the left-right direction, and the cursor 51 is controlled so that the command icon pointed to by the cursor 51 switches one by one to the left or right in response to the selection input. The selection input may be performed by directional input to buttons corresponding to the movement of the cursor 51 in a predetermined forward direction and buttons corresponding to the movement of the cursor 51 in the reverse direction, or by directional input to the analog stick of the controller. Furthermore, when a predetermined first confirmation input is made to the controller, the game system 1 sets the command icon that is selected at the time the first confirmation input is made as the command icon specified by the player. The first confirmation input may be, for example, an input to a predetermined button on the controller. As described above, the player can specify the command indicated by the specified command icon by instructing the controller to select one of the command icons 40 to 48 using the directional input and button input described above.

[0051] The start command icon 40 indicates a command to start a battle. In this embodiment, if the start command icon 40 is selected while the player character 31 is approaching an enemy character in the game space, a battle scene between the player character 31 and the enemy character will begin. The conditions for starting a battle scene are arbitrary, and a battle scene may be started under conditions other than those described above. For example, a battle scene may be started when the player character 31 makes contact with an enemy character, or it may be started in accordance with the progression of the game's story.

[0052] Action command icons 41-48 each represent commands associated with actions that player character 31 can take in a battle scene. When an action command icon is specified in a battle scene, the game system 1 controls player character 31 to take the action associated with the command indicated by the specified action command icon. The specific content of the action associated with the command is arbitrary. Examples of such actions include actions that perform an attack or weakening on an enemy character that is different from the normal attack, or actions that heal or strengthen player character 31 or allied characters 32-34. In the example shown in Figure 3, eight action command icons 41-48 are displayed, and there are eight types of actions that player character 31 can take based on the action command icons, but the number of action command icons is arbitrary. For example, the number of action command icons may increase as the game progresses. Also, for example, the player may be able to set the types of action command icons displayed in the battle scene. For example, before the battle scene, a predetermined number of action command icons may be selected by the player from among several candidate action command icons, and the selected action command icons may be displayed in the battle scene.

[0053] In this embodiment, a command can be in an usable state, where it can be used (also called specified), or an unusable state, where it cannot be used. The game system 1 manages whether a command is in an usable state or an unusable state for each command. If a command is in an usable state, the player character 31 is controlled to take the action associated with that command, in accordance with the specification of that command. At this time, the game system 1 also transitions the command to an unusable state. On the other hand, if a command is in an unusable state, the game system 1 does not accept the specification of that command by the first decision input. In other words, in the above case, even if the first decision input is made while the action command icon indicating that command is selected, the player character 31 will not take the action associated with that command.

[0054] If a command is unavailable, the game system 1 updates the command parameters for that command according to the game's progress. In this embodiment, the command parameters indicate the elapsed time since the command became unavailable. The command parameters are reset (specifically set to 0) when the command becomes unavailable and increase over time. When the command parameters of a command reach a predetermined recovery time, the game system 1 transitions the command to an available state. The recovery time is set for each command and may be set to a different value for each command. For example, commands associated with actions that have a greater effect in the game, such as commands associated with powerful attack actions, may have longer recovery times.

[0055] The command parameter may also indicate the remaining time until the command becomes available again. In this case, the command parameter is reset to the recovery time value when the command becomes unavailable and is updated to subtract as time passes. As in the example above and in this embodiment, the command parameter may be updated according to the passage of time as the game progresses. Furthermore, the condition for a command to become available may be a condition that is met by the passage of time since the command became unavailable.

[0056] Furthermore, command parameters are not limited to those relating to the elapsed time since the command became unusable. For example, command parameters may be parameters that are updated each time player character 31 performs the normal attack in a battle scene. In this case, the command parameter may be reset to 0 when the command becomes unusable, increased with each normal attack, and the command may become usable when the command parameter reaches a predetermined value. Alternatively, for example, the command parameter may be reset to a predetermined value when the command becomes unusable, decreased with each normal attack, and the command may become usable when the command parameter reaches 0. Also, for example, in the case of so-called turn-based combat, command parameters may be parameters that are updated according to the passage of turns.

[0057] As described above, command parameters may be any parameters that are updated as the game progresses so as to approach values ​​that satisfy the conditions for setting the command to an usable state.

[0058] As described above, in this embodiment, by temporarily disabling a specified command, it is possible to prevent the player from specifying the same command repeatedly. This reduces the possibility that the difficulty of the battle may become too low due to, for example, the repeated specification of powerful commands, thereby improving the strategic depth of the game.

[0059] In this embodiment, the appearance of the action command icon changes to represent the status of the command. Figure 4 shows an example of how the appearance of the action command icon changes. In the example shown in Figure 4, the action command icon 45 shown in Figure 3 is described, but the appearance of the other action command icons 41-44 and 46-48 are controlled in the same way as the action command icon 45.

[0060] As shown in Figure 4, when a command is available, the action command icon is displayed in its normal form, where the entire icon is visible (see the top section of Figure 4). When a command is specified and becomes unavailable, the game system 1 displays the action command icon representing that command in a modified form (see the middle section of Figure 4). The modified form is a display mode that is either not visible or more difficult to see than the normal form. In Figure 4, the portion of the action command icon displayed in the modified form is indicated by diagonal lines. Furthermore, the game system 1 displays the action command icon so that the portion displayed in the normal form increases as time elapses since the command became unavailable (see the bottom section of Figure 4). The display of the action command icon is controlled so that the entire action command icon returns to its normal form when the command parameters reach the recovery time mentioned above. In this way, the player can be notified by the action command icon whether a command is available or not, and if unavailable, how long it will take for it to become available.

[0061] The display mode of the action command icon is not limited to the above. For example, in the example shown in Figure 4, the portion displayed in the normal mode is a sector whose central angle increases with the passage of time, but in other embodiments, the display of the action command icon may be controlled so that the portion displayed in the normal mode gradually expands upward from the lower part of the action command icon as time passes. In other embodiments, a gauge that extends along the circumference of the action command icon as time passes may be displayed. These also allow the player to be notified whether the command is available or not, and if it is unavailable, how long it will take for it to become available.

[0062] Furthermore, each action command icon may be categorized into several types depending on the content of the action associated with the command and the effect of that action, and may be displayed in a color corresponding to the category, or may be displayed with a mark corresponding to the category.

[0063] As described above, in this embodiment, commands that are currently unavailable are permitted to be used again once the command parameters have reached their recovery time. The process of a command becoming reusable is generally called recasting, and the time until recasting is called recast time or recast duration. In this embodiment, the game system 1 manages the recast parameters and, in addition to conventional recasting methods such as those based on the command parameters reaching their recovery time, it also performs an immediate recast on the command in question, allowing it to be used again, based on the consumption of the held recast parameters. This makes it easier to use commands at the desired timing in combat. The use of commands based on the consumption of recast parameters will be explained below.

[0064] Figure 5 shows an example of a game image in a situation where commands based on the consumption of recast parameters can be used. In the situation shown in Figure 5, the action command icon 45 is selected by the cursor 51, and the selected action command icon 45 is displayed in a way that indicates that the command is unavailable.

[0065] As shown in Figures 3 and 5, the game image includes a recast gauge 52 that shows the recast parameter. In this embodiment, the recast parameter is a parameter corresponding to the recast time. While command parameters are set for each command, recast parameters are not set for each command, but are applied commonly to all commands. In the example shown in Figure 5, the value of the recast parameter shown by the recast gauge 52 is assumed to be large enough to allow the use of the command shown by the action command icon 45.

[0066] In the situation shown in Figure 5, the command indicated by the selected action command icon 45 is unavailable. Therefore, even if the player makes the first decision input described above, the command will not be accepted, and the player character 31 will not take the action associated with that command. In this embodiment, in the situation shown in Figure 5, the player can make a second decision input to use the command in exchange for consuming a recast parameter. The second decision input is, for example, a different button input from the button input for the first decision input. Thus, in this embodiment, the player can also specify a command from among the multiple action command icons 41 to 48 by using directional input to the controller and a button input for the second decision input.

[0067] As shown in Figures 3 and 5, in this embodiment, the game image includes a button image 53 indicating a button for the second decision input. Here, the button for the second decision input is the Y button on the right controller 4, and the button image 53 represents the Y button. In this embodiment, the button image 53 is displayed in association with the recast gauge 52. For example, the button image 53 is placed near the recast gauge 52. The button image 53 makes it easier for the player to understand how to perform the second decision input.

[0068] If a second decision input is made while an action command icon is being selected, the game system 1 accepts the selection of the command, provided that the time indicated by the recast parameter is equal to or greater than the remaining time until the command parameter of the selected command reaches the above recovery time. In other words, if the time indicated by the recast parameter is equal to or greater than the above remaining time, the game system 1 considers the selected command to have an immediate recast and has the player character 31 perform the action associated with the selected command.

[0069] Furthermore, in this embodiment, when a command is specified in response to the second decision input, the recast parameter is consumed by the remaining time. Specifically, the game system 1 updates the recast parameter to a value that represents the time obtained by subtracting the remaining time from the current value. For example, in the example shown in Figure 5, if the remaining time until the command parameter of the command indicated by the action command icon 45 reaches the recovery time is 3 seconds, and the time indicated by the recast parameter is 10 seconds, then the recast parameter is consumed by 3 seconds, and the recast parameter after consumption becomes 7 seconds. Thus, in this embodiment, when a command is used based on the consumption of the recast parameter, an amount of the recast parameter corresponding to the shortfall in the current command parameter until it reaches the recovery time is consumed. This allows the player to use a command by consuming an amount of the recast parameter corresponding to the shortfall in the command parameter. For example, the player will have to decide whether to use the command immediately by consuming a large amount of the recast parameter, or to wait to use the command to reduce the consumption of the recast parameter, thereby improving the strategic aspect of the game in combat situations.

[0070] In this embodiment, the recast parameter is a time value of the same type as the command parameter. However, in other embodiments, the recast parameter does not need to be a value of the same type as the command parameter. For example, the recast parameter may indicate the number of times a command can be used based on the consumption of the recast parameter. Alternatively, the amount of recast parameter consumed may be calculated as a value obtained by multiplying the command parameter deficit by a predetermined coefficient. In this case, the condition for a command to be accepted in response to the second decision input is that the recast parameter is equal to or greater than the amount obtained by multiplying the command parameter deficit by a predetermined coefficient.

[0071] Furthermore, the recast parameter may be a parameter whose value decreases as the recast parameter is consumed, as in this embodiment, or it may be a parameter whose value increases as it is consumed, unlike in this embodiment. A recast parameter whose value decreases as it is consumed can be said to represent an amount that can compensate for the shortage of command parameters. A recast parameter whose value increases as it is consumed may be set to 0 at the start of combat, and updated so that an amount corresponding to the shortage of command parameters is added when the recast parameter is consumed. Such a recast parameter can be said to represent the amount that has so far compensated for the shortage of command parameters. A maximum value is set for such a parameter, and the game system 1 accepts the command specified in response to the second decision input if the value obtained by subtracting the current recast parameter from the maximum value is greater than the amount corresponding to the shortage of command parameters.

[0072] Furthermore, the recast parameter does not need to be a parameter that indicates time. For example, if the command parameter is a parameter that is updated in response to a normal attack by player character 31 as described above, or a parameter that is updated as turns pass, the recast parameter does not need to be a parameter that indicates time, and can be, for example, the same type of value as the command parameter.

[0073] When a command is used based on the consumption of recast parameters, the command is set to an unavailable state after use, just as when the command is used while it is available. Also, when a command is used based on the consumption of recast parameters, the command parameters of that command are reset. If the command parameters were not reset in the above case, the command could be used repeatedly in succession with only a small consumption of recast parameters, provided that the shortage of command parameters is small. In contrast, in this embodiment, by resetting the command parameters in the above case, it is possible to suppress the repeated use of the same command with a small consumption in the above situation. In other embodiments, the command parameters of the command may not be reset in the above case.

[0074] Furthermore, if a second decision input is made when the selected command is in an usable state, in this embodiment, the game system 1 performs processing in the same way as when a first decision input is made. In other words, even in the above case, the selected command is accepted, and the player character 31 takes the action associated with the command. Here, for example, in a situation where the command parameter is almost at the recovery time, the player who intends to specify the selected command will attempt to make a second decision input, but it is possible that by the time the player actually makes the second decision input, the command parameter has reached the recovery time and the command has become usable. If a second decision input were not accepted when the selected command is in an usable state, then in the above case, even if the player makes a second decision input, the command will not be accepted, which may cause the player to feel uncomfortable with the operation. In contrast, in this embodiment, even in the above case, the command is used by the second decision input, so the possibility of the player feeling uncomfortable with the operation due to the command not being used even after making a second decision input can be reduced, and the operability of the game can be improved. In other embodiments, if the selected command is available, the game system 1 may not accept a second decision input.

[0075] In this embodiment, for each command, an action command icon 41-48 is displayed indicating whether it is usable or unusable, along with an action command icon 41-48 showing the amount of the command parameter, and a recast gauge 52 is displayed. This presents the player with the status of the currently selected command and the remaining amount of the recast parameter, allowing the player to check the command status and decide whether or not to use an unusable command by consuming the recast parameter, by referring to the current value of the recast parameter.

[0076] Figure 6 shows an example of a game image in a situation where a command cannot be used due to the consumption of the recast parameter. In the situation shown in Figure 6, the action command icon 43 is selected by the cursor 51, and the action command icon 43 is displayed in a way that indicates the command is unavailable. Furthermore, in the situation shown in Figure 6, the value of the recast parameter indicated by the recast gauge 52 is the value at which the command indicated by the action command icon 43 cannot be used, that is, it is a value smaller than the remaining time until the command parameter corresponding to the action command icon 43 reaches its recovery time.

[0077] In this embodiment, if the selected command cannot be used based on the consumption of the recast parameter, the game system 1 displays an unusable mark 54 to indicate that it cannot be used (see Figure 6). The unusable mark 54 is placed, for example, superimposed on the recast gauge 52. The unusable mark 54 notifies the player whether or not the selected command can be used based on the consumption of the recast parameter. In other embodiments, the unusable mark 54 may be displayed in response to a second decision input. Alternatively, the game system 1 may display a button image 53 when the command can be used based on the consumption of the recast parameter, instead of or in conjunction with displaying the unusable mark 54, as an image indicating whether or not it can be used based on the consumption of the recast parameter.

[0078] The display of the unusable mark 54 is controlled based on the selected command. For example, in the situation shown in Figure 6, if the cursor 51 is moved by the selection input described above and the action command icon 44 is selected, the game system 1 clears the displayed unusable mark 54. In the situation shown in Figure 6, the value of the recast parameter shown by the recast gauge 52 is assumed to be greater than the remaining time until the command parameter corresponding to the action command icon 44 reaches its recovery time. As described above, in this embodiment, the game system 1 displays an unusable mark 54 for each selected command, so that the player can be notified whether the currently selected command can be used based on the consumption of the recast parameter.

[0079] Furthermore, as described above, in this embodiment, the game system 1 updates the command parameters over time, and accepts the use of a command based on the consumption of the recast parameter when the recast parameter is greater than or equal to the shortfall until the command parameter reaches its recovery time. In this configuration, the unavailable mark 54 is displayed for each command depending on whether the recast parameter is less than the shortfall. This allows the player to check whether it is currently possible to use a command based on the consumption of the recast parameter using the unavailable mark 54, and if the command is unavailable, they can check other commands by selecting another command. For example, the player can consider whether to wait for a currently unavailable command to become available and then specify that command, or to specify another command that is currently available, thus improving the strategic aspect of the game.

[0080] In this embodiment, the recast parameter is restored after the battle scene ends. Specifically, when the battle scene ends, the game system 1 sets the recast parameter to its maximum value, regardless of the value of the recast parameter at the end of the battle scene. The amount of recast parameter restoration after the battle scene ends is arbitrary. In other embodiments, the recast parameter may be restored by a predetermined amount after the battle scene ends. For example, the game system 1 may determine the amount of recast parameter restoration depending on the content of the battle, such as the number of enemy characters defeated during the battle. According to the above, the player can use commands based on the consumption of the recast parameter for each battle scene. This makes it easier for the player to consume the recast parameter in each battle scene, thereby improving the convenience of using commands based on the consumption of the recast parameter.

[0081] In other embodiments, the timing of the recast parameter's recovery is arbitrary, and the recast parameter may be recovered at a time other than the end of a combat scene. For example, in other embodiments, the game system 1 may set the recast parameter to 0 at the start of a combat scene, update the recast parameter to increase as the game progresses in the combat scene, and update the recast parameter to decrease as commands are used based on the consumption of the recast parameter.

[0082] Furthermore, in this embodiment, the game system 1 does not recover the recast parameter during combat. This makes it possible to impose restrictions on the use of commands based on the consumption of the recast parameter during a single combat scene.

[0083] As described above, in this embodiment, for example, in battles against relatively weak enemy characters, the recast parameter is restored after each battle, making it easier to end the battle quickly by consuming the recast parameter. On the other hand, in battles against relatively strong enemy characters such as boss characters, a limit is placed on the amount of recast parameter that can be consumed in a single battle, requiring the player to consider the appropriate timing for consuming the recast parameter as they proceed with the battle. As a result, the strategic depth can be improved without making the battles too easy. As described above, according to this embodiment, players can progress through the game at a good pace by completing battles quickly in low-difficulty battle scenes, and can enjoy a highly strategic game in high-difficulty battle scenes.

[0084] In this embodiment, the game system 1 increases the maximum value of the recast parameter in a predetermined scene in the game. The predetermined scene is, for example, a scene in which the game's story progresses, a scene in which a challenge set in the game is cleared, or a scene in which the player character 31 uses a predetermined item. The above example is an example in which the predetermined scene is a scene different from a battle scene, but the predetermined scene may also be a scene that occurs during a battle scene. In this case, even if the maximum value of the recast parameter increases, the value of the recast parameter itself does not increase. Since increasing the maximum value of the recast parameter makes it easier for the player to progress through battles, giving the player an opportunity to increase the maximum value of the recast parameter as described above can motivate the player to progress through the game.

[0085] In this embodiment, companion characters 32-34 will not perform actions that consume recast parameters. However, in other embodiments, the game system 1 may, for example, cause companion characters 32-34 to perform actions that consume recast parameters in response to instructions from the player.

[0086] Next, we will explain an example of how using commands based on the consumption of recast parameters can give you an advantage in combat situations.

[0087] Figure 7 shows an example of a game image in a situation where an enemy character has fallen over. In this embodiment, enemy character 35 may be thrown off balance or thrown over by an attack from player character 31 or allied characters 32-34. For example, enemy character 35 may fall over if it is attacked and thrown off balance, and then receives a specific type of attack. After a certain amount of time has passed since being thrown off balance or thrown over, enemy character 35 recovers from that state and returns to its normal state. In the example shown in Figure 7, a state image 55 is displayed indicating that enemy character 35 is in a fallen state. In addition to a mark indicating the state of enemy character 35, the state image 55 may also include a game showing the time until the state recovers. Furthermore, the states that enemy character 35 can be in are arbitrary, and in addition to the states of being thrown off balance or thrown over, it may also be in a state of being unconscious, etc.

[0088] In this embodiment, during the period when enemy character 35 is downed, certain attack actions performed using specific action commands are more effective than during normal periods. For example, when enemy character 35 is downed, attacks deal more damage and are more likely to hit. In this embodiment, even if the above-mentioned specific command becomes unusable during the period when enemy character 35 is downed, the player can use the command by consuming the recast parameter. Thus, in this embodiment, using commands based on the consumption of the recast parameter makes it easier to gain an advantage in battle.

[0089] In this embodiment, if the enemy character 35 is in a fallen state, the game system 1 displays a notification mark 56 for the action command icon (action command icon 44 in the example of Figure 7) that indicates the specific attack action that is more effective when the character is fallen. This allows the player to be notified of commands that are effective against the fallen enemy character 35.

[0090] Figure 8 shows an example of a game image in a situation where a message from a companion character is displayed. As shown in Figure 8, in this embodiment, when predetermined message conditions are met in a battle scene, a message image 58 indicating a message from a companion character is displayed. The above message conditions are arbitrary. For example, the message conditions may be when the player character 31 takes a specific action or when the player character 31's parameters reach predetermined values. Alternatively, for example, the message conditions may be when an enemy character is in a predetermined state, such as having a part destroyed or being knocked down as described above. In this embodiment, the message image 58 is displayed for a predetermined period of time.

[0091] The above message suggests an action that the player character 31 can take at that time to gain an advantage in battle. In the example shown in Figure 8, the message image 58 includes the message "Please provide covering fire!" and an image 59 showing an action command icon 42 indicating a shooting attack command. If the commands that the player can use are classified into multiple types, the message image 58 may show a specific command or it may show the type of command. Also, in the case shown in Figure 8, as in Figure 7, a notification mark 56 may be attached to the action command icon 42 shown in the message image 58.

[0092] If player character 31 takes the action suggested by the message image 58 during the period when the message image 58 is displayed, player character 31 is granted a game benefit. This benefit is not granted during the period when the message image 58 is not displayed. The specific content of this benefit is arbitrary. For example, the benefit may be an increase in the points that player character 31 can use for special skills, or an increase in the effect of the action. In this embodiment, even if the command suggested by the message image 58 is unavailable during the period when the message image 58 is displayed, the player can use the command by consuming the recast parameter. In this embodiment, in addition to the situation shown in Figure 7, the use of commands based on the consumption of the recast parameter also makes it easier to gain an advantage in battle in the situation shown in Figure 8.

[0093] Furthermore, in this embodiment, for attack actions using specific commands, the damage dealt is greater when the attack action is performed from behind the enemy character 35 than when the attack action is performed from any other angle. Therefore, even during the period when the player character 31 is positioned behind the enemy character 35, the game can be advanced to an advantage by using specific commands, similar to the examples shown in Figures 7 and 8. In this embodiment, even in such a situation, the player can use the command by consuming the recast parameter, even if the command is unavailable. Also, during the above period, the action command icon indicating the specific command may be marked with the notification mark 56 described above.

[0094] As described above, in this embodiment, the game system 1 increases the effectiveness of the player character 31's actions corresponding to a predetermined command during periods when the conditions related to the battle situation are met, compared to periods when the conditions are not met. However, since it is difficult for the player to accurately predict when the period in which the above conditions are met will arrive, it is possible that the command may be used before such a time arrives, and by the time it arrives, the command may be unusable. In this regard, in this embodiment, the player can use the command by consuming the recast parameter even in such situations, thereby improving the convenience of using commands.

[0095] [3. Specific examples of processing in game systems] Next, we will explain specific examples of information processing in game system 1 with reference to Figures 9 to 12.

[0096] Figure 9 shows an example of various data used for information processing in the game system 1. The various data shown in Figure 9 are stored in a storage medium accessible by the main unit 2 (for example, flash memory 26, DRAM 27, and / or a memory card inserted in slot 29).

[0097] As shown in Figure 9, the game system 1 stores the game program. The game program is a game program for executing the game processing in this embodiment (see Figures 10 to 12). The game system 1 also stores character data, command data, and recast data.

[0098] Character data is data relating to the characters that appear in battle scenes. Game system 1 stores character data for each character. In this embodiment, character data includes data indicating parameters such as the character's health, and data indicating the character's status.

[0099] Command data is data relating to commands that the player character 31 can use in combat. The game system 1 stores command data for each command. In this embodiment, the command data includes data indicating the command parameters of the command, and data indicating a status flag indicating the state of the command. The status flag is set to "on" when the command is usable and to "off" when it is unavailable.

[0100] Recast data is data relating to recast parameters. In this embodiment, recast data includes data indicating the recast parameters, data indicating the maximum value of the recast parameters, and data indicating the immediate recast flag. The immediate recast flag is a flag indicating whether or not a command based on the consumption of recast parameters can be used.

[0101] Figure 10 is a flowchart illustrating an example of the combat scene processing flow executed by Game System 1. Combat scene processing is game processing performed during combat scenes in the game. Combat scene processing is initiated when a combat scene begins during the execution of the game program described above. In this embodiment, at the start of a combat scene, the start command icon among multiple command icons is set to a selected state, and the command data for each command is set to indicate that it is available for use. Also, at the start of a combat scene, the value of the recast parameter indicated by the recast data is at its maximum value.

[0102] In this embodiment, the processor 21 of the main unit 2 executes the game program stored in the game system 1, thereby executing the processing of each step shown in Figures 10 to 12. However, in other embodiments, some of the processing of each step may be executed by a processor other than the processor 21 (for example, a dedicated circuit). Also, if the game system 1 can communicate with other information processing devices (for example, a server), some of the processing of each step shown in Figures 10 to 12 may be executed by the other information processing device. Furthermore, the processing of each step shown in Figures 10 to 12 is merely an example, and the processing order of each step may be changed, or other processing may be executed in addition to (or instead of) the processing of each step, as long as similar results can be obtained.

[0103] Furthermore, the processor 21 executes the processing of each step shown in Figures 10 to 12 using memory (for example, DRAM 27). That is, the processor 21 stores the information (in other words, data) obtained by each processing step in memory, and when it is necessary to use that information in subsequent processing steps, it reads the information from memory and uses it.

[0104] In step S1 shown in Figure 10, the processor 21 acquires operation data indicating the player's input. That is, the processor 21 acquires operation data received from the controller via the controller communication unit 25 and / or terminals 22 and 23 and stores it in memory. The processing in step S2 is executed after step S1.

[0105] In step S2, the processor 21 executes a command control process that accepts commands under certain conditions in response to the player's input. The details of the command control process in step S2 will be described below with reference to Figure 11.

[0106] Figures 11 and 12 are subflowcharts showing an example of a detailed flow of the command control process in step S2 shown in Figure 10. In the command control process, first in step S11, the processor 21 increments the command parameters. In this embodiment, the command control process shown in Figure 12 is repeatedly executed at a rate of once per frame. Therefore, the processor 21 increments the values ​​of the command parameters of each command that have not reached the recovery time by a value corresponding to one frame. The processor 21 updates the command data stored in memory to reflect the incremented values. The process in step S12 is executed after step S11.

[0107] In step S12, the processor 21 determines whether any of the command parameters increased in step S11 have reached their recovery time. If the result of the determination in step S12 is positive, the process in step S13 is executed. On the other hand, if the result of the determination in step S12 is negative, the process in step S14 is executed.

[0108] In step S13, the processor 21 sets the command whose command parameters have reached their recovery time, as determined in step S12, to an usable state. Specifically, the processor 21 updates the command data stored in memory so that the status flag described above indicates that it is on. The process in step S14 is executed after step S13.

[0109] In step S14, the processor 21 determines whether the selected command can be used based on the consumption of the recast parameter. The determination in step S14 is made based on the value of the recast parameter indicated by the recast data stored in memory and the value of the command parameter updated by the processing in step S11. Specifically, the determination in step S14 is made based on whether the value of the recast parameter is greater than or equal to the value obtained by subtracting the value of the command parameter from the recovery time (i.e., the remaining time until the command becomes usable). If the determination result in step S14 is positive, the processing in step S15 is executed. On the other hand, if the determination result in step S14 is negative, the processing in step S16 is executed.

[0110] In step S15, the processor 21 sets the immediate recast flag indicated by the recast data to ON. At this time, the immediate recast flag indicates that the selected command can be used based on the consumption of the recast parameter. The processing in step S17 is executed after step S15.

[0111] In step S16, the processor 21 sets the immediate recast flag indicated by the recast data to off. At this time, the immediate recast flag indicates that the selected command cannot be used based on the consumption of recast parameters. When the immediate recast flag is set to off, an unusable mark (see Figure 6) indicating that it cannot be used based on the consumption of recast parameters is displayed in the processing of step S5 described below. The processing of step S17 is executed after step S16.

[0112] In step S17, the processor 21 determines whether the player has made a selection input to change the selected command. Specifically, the processor 21 determines whether a directional input for selection input has been made based on the operation data obtained in step S1. If the result of the determination in step S17 is affirmative, the process in step S18 is executed. On the other hand, if the result of the determination in step S17 is negative, the process in step S19, which will be described later, is executed.

[0113] In step S18, the processor 21 changes the currently selected command icon from among the selectable command icons according to the input. Specifically, the processor 21 uses the currently selected command icon as the new selected command icon and selects the command icon located one position to the left or right, depending on the left or right direction input. The process in step S19 is executed after step S18.

[0114] In step S19, the processor 21 determines whether the player has made a first decision input to specify the selected command. Specifically, the processor 21 determines whether a button input for the first decision input has been made based on the operation data acquired in step S1. If the determination result in step S19 is affirmative, the process in step S20 is executed. On the other hand, if the determination result in step S19 is negative, the process in step S24 shown in Figure 12 is executed.

[0115] In step S20, the processor 21 refers to the command data stored in memory and determines whether the command indicated by the selected command icon is available. If the result of the determination in step S20 is positive, the process in step S21 is executed. On the other hand, if the result of the determination in step S20 is negative, the process in step S24 shown in Figure 12 is executed.

[0116] In step S21, the processor 21 accepts the command indicated by the selected command icon. At this time, in the process of step S3 described below, the player character is controlled to take the action associated with the accepted command. The process of step S23 is executed after step S22.

[0117] In step S22, the processor 21 sets the command indicated by the selected command icon to an unusable state. Specifically, the processor 21 updates the command data stored in memory so that the status flag described above indicates off. The process in step S23 is executed after step S22.

[0118] In step S23, the processor 21 resets the command parameters of the command indicated by the selected command icon. Specifically, the processor 21 updates the command data stored in memory so that the value of the command parameter of that command is 0. Following step S23, the process of step S24 shown in Figure 12 is executed.

[0119] In step S24 shown in Figure 21, the processor 21 determines whether the player has made a second decision input to specify the selected command. Specifically, the processor 21 determines whether a button input for the second decision input has been made based on the operation data acquired in step S1. If the determination result in step S24 is positive, the process in step S25 is executed. On the other hand, if the determination result in step S24 is negative, the process in step S26, described below, is executed.

[0120] In step S25, the processor 21 refers to the command data stored in memory and determines whether the command indicated by the selected command icon is available. If the result of the determination in step S25 is positive, the processes in steps S26 to S28 are executed. On the other hand, if the result of the determination in step S25 is negative, the process in step S29 is executed.

[0121] The processing in steps S26 to S28 is the same as the processing in steps S21 to S23 above. That is, in step S26, the selected command is accepted; in step S27, the command is set to an unusable state; and in step S28, the command parameters of the command are reset. After step S28, the processor 21 terminates the command control processing.

[0122] In step S29, the processor 21 determines whether the command indicated by the selected command icon can be used based on the consumption of recast parameters. The determination in step S29 is made, for example, by whether the immediate recast flag indicated by the recast data stored in memory is set to ON. If the determination result in step S29 is positive, the processing in steps S30 to S32 is executed. On the other hand, if the determination result in step S29 is negative, the processor 21 terminates the command control processing.

[0123] The processing in steps S30 and S31 is the same as the processing in steps S21 and S23 described above. That is, in step S30, the selected command is accepted, and in step S31, the command parameters of the command are reset. In this embodiment, if the determination result in step S29 is affirmative, the status flag indicated by the command data for the selected command is off (i.e., it indicates an unusable state), so the same processing as in step S22 is not performed. However, the processing that manages the state of a command when it is used based on the consumption of recast parameters may be any processing that sets the state of the command after use to an unusable state. The processor 21 may accept the command with the command data still indicating an unusable state, or it may update the command data to indicate an usable state and then update it again to indicate an unusable state. For example, in another embodiment, if the determination result in step S29 is affirmative, the processor 21 may set the status flag to on before processing in step S30, and then set the status flag back to off after processing in step S30.

[0124] In step S32, the processor 21 consumes the recast parameter. In this embodiment, the recast parameter is set to a value obtained by subtracting the remaining time until the selected command becomes available from its current value. The processor 21 updates the recast data stored in memory to reflect the value after the subtraction. After step S32, the processor 21 terminates the command control process.

[0125] Returning to the explanation of Figure 10, in the next step S3 following step S2, the processor 21 controls each character appearing in the battle scene. The player character's actions are controlled based on the player's input. In this embodiment, the player character is controlled to move within the game space in response to input indicating direction, and to take actions associated with a command if a command is received in the command control process of step S2. In this embodiment, the player character is also controlled according to an algorithm defined in the game program, and performs the normal attack described above if the conditions are met. In addition, the actions of allied characters and enemy characters are controlled according to an algorithm defined in the game program. Note that the processing in step S3 may be the same as conventional character control processing.

[0126] In this embodiment, during the processing of step S3, each character is controlled to perform an action for one frame. The processor 21 may control each character to perform a single action, such as an attack action or a recovery action, over multiple frames. In this case, for example, during a period when a player character is performing a certain action, the processor 21 may not accept any input or commands to cause other actions. The processing of step S4 is executed after step S3.

[0127] In step S4, the processor 21 updates the parameters for each character based on the results of the actions controlled in step S3. For example, the processor 21 may decrease the health parameter of a character that has been attacked by another character, increase the health of a character that has received a healing action, or update parameters indicating the character's state under certain conditions. The processor 21 updates the character data stored in memory to reflect the updated parameters. The processing in step S5 is executed after step S4.

[0128] In step S5, the processor 21 generates and displays a game image. In this embodiment, the generated game image includes an image representing the game space and a UI image (see Figure 3). The processor 21 generates the game space image so that, for example, the player character 31 whose actions are controlled in the processing of step S3 is included in the field of view. The processor 21 also generates the game image by superimposing the UI image onto the game space image. In this embodiment, the UI image includes the player character-related image 36, enemy character-related image 37, and command icons 40-48, message image 58, etc. (see Figure 3). The player character-related image 36 and enemy character-related image 37 are generated to show the parameters updated by the processing of step S4. The images of the action command icons 41-48 are generated to display in a manner corresponding to the state and command parameters of the command updated in the command control processing of step S2 (see Figure 4). The image of the cursor 51 is placed at a position that points to the action command icon indicating the selected command, which was set in the command control processing of step S2. The image of the recast gauge 52 is generated to show the updated recast parameter value in the command control process of step S2. If the immediate recast flag is set to off in the command control process of step S2, an unavailable mark 54 is added to the image of the recast gauge 52. Also, if the above message conditions are met by the processing result of step S3 or S4, the above message image 58 is generated. The display device on which the generated game image is displayed may be the display 12 of the main unit 2, or another display device connected to the main unit 2. The processing of step S6 is executed after step S5.

[0129] In step S6, processor 21 determines whether to end the battle scene. For example, processor 21 determines whether all enemy characters have been defeated, or whether the player character and all allied characters have been defeated. If the result of the determination in step S6 is negative, the process in step S1 is executed again. Thereafter, the series of processes from steps S1 to S6 are repeatedly executed until it is determined in step S6 that the battle scene should end. On the other hand, if the result of the determination in step S6 is positive, the process in step S7 is executed.

[0130] In step S7, the processor 21 recovers the recast parameter. In this embodiment, the processor 21 updates the recast data stored in memory so that the recast parameter shows its maximum value. After step S7, the processor 21 terminates the battle scene processing.

[0131] [4. Effects and Modifications of This Embodiment] As described above, in this embodiment, the game system 1, in addition to having the player character perform the action associated with a command when the command is available, also allows the player character to perform the action associated with the command by consuming a recast parameter when the command is unavailable. This allows the player to specify commands that do not yet meet the conditions for using a command again in games where such conditions are set. This makes it easier for the player to use commands at their desired timing during gameplay, thereby improving the convenience of command use.

[0132] In the above embodiment, a battle scene was described as an example in which game images showing the actions of each character in the game space are displayed, but the battle scene is not limited to this. For example, the battle scene is not limited to one in which combat progresses in real time, but may also be one in which combat progresses in a turn-based system. Furthermore, the game images representing the battle scene are not limited to those that include images of player characters and enemy characters, but may include only images of enemy characters without including images of player characters, or they may not include images of characters at all, and the battle situation may be displayed in text.

[0133] In the above embodiment, when processing is performed using data (meaning including programs) in a certain information processing device, some of the data necessary for the processing may be transmitted from another information processing device different from the said information processing device. In this case, the said information processing device may perform the processing using the data received from the other information processing device and the data stored in itself.

[0134] In other embodiments, the information processing system may not have to include some of the configurations in the above embodiments, nor may it perform some of the processes executed in the above embodiments. For example, in order to obtain some specific results in the above embodiments, the information processing system may have to include the configurations for obtaining those results and perform the processes for obtaining those results, but it may not have to include other configurations or perform other processes. [Explanation of Symbols]

[0135] 1. Game System 2. Main unit 21 processors 31 Player Characters 35 Enemy Characters 41-48 Action Command Icons 52 Recast Gauge

Claims

1. On the computer, In combat scenes between player characters and enemy characters in games, Based on the operation input, one of several types of commands is specified by the first instruction, and if the state of the specified command is in the "available" state among the "available" and "unavailable" states, The player character is instructed to perform the action associated with the command, The command is then switched to the disabled state. The first parameter associated with a particular command, among the first parameters set for each command, is reset. For each of the commands in the disabled state, the respective first parameter is updated according to the game progress, and when the first parameter satisfies the first condition, the command associated with the first parameter is transitioned to the enabled state. When the command in the unavailable state is specified by a second instruction based on the operation input, and it is possible to consume the second parameter, This consumes the second parameter, The player character is instructed to perform the action associated with the command, Set the command to the disabled state described above. Reset the first parameter associated with the command. Game program.

2. To the aforementioned computer, The game program according to claim 1, wherein for each of the commands in the disabled state, the first parameter is updated in accordance with the passage of time as the game progresses.

3. The game program according to claim 2, wherein the first condition is satisfied when the first parameter is reset and a time period of a length set for each command has elapsed.

4. To the aforementioned computer, The game program according to any one of claims 1 to 3, wherein, when the command in the unavailable state is specified by the second instruction, the remaining second parameter is consumed by reducing the second parameter by an amount equal to the amount of decrease corresponding to the shortfall in the first parameter of the command at that time until the first condition is met.

5. To the aforementioned computer, A game program according to any one of claims 1 to 3, wherein the second parameter is restored after the end of the combat scene.

6. To the aforementioned computer, The game program according to claim 5, wherein the second parameter is not restored during the aforementioned combat scene.

7. To the aforementioned computer, During the aforementioned combat scene, the second parameter is not restored. After the end of the aforementioned combat scene, the second parameter is restored to its maximum value. A game program according to any one of claims 1 to 3, wherein the maximum value of the second parameter is increased in a predetermined scene in the game.

8. The aforementioned computer further: A game program according to any one of claims 1 to 3, wherein for each command, the program displays whether the command is in the usable state or the unusable state, an icon indicating the first parameter in the unusable state, and a gauge indicating the second parameter.

9. The first instruction is an instruction that causes the user to select the command based on the directional input and to confirm the selected command in response to the first button input, The second instruction is an instruction that causes the user to select the command based on the directional input and to confirm the selected command in response to the second button input, The aforementioned computer further: The game program according to claim 8, which displays an indicator for each selected command indicating whether or not it is possible to consume the second parameter.

10. The aforementioned computer further: A game program according to any one of claims 1 to 3, wherein, during a period when a second condition regarding the battle situation is met, the effect of the action corresponding to the first of the multiple types of commands is increased compared to a period when the second condition is not met.

11. An information processing system, In combat scenes between player characters and enemy characters in games, Based on the operation input, one of several types of commands is specified by the first instruction, and if the state of the specified command is in the "available" state among the "available" and "unavailable" states, The player character is instructed to perform the action associated with the command, The command is then switched to the disabled state. Reset the first parameter associated with the command, which is one of the first parameters set for each command. For each of the commands in the disabled state, the respective first parameter is updated according to the game progress, and when the first parameter satisfies the first condition, the command associated with the first parameter is transitioned to the enabled state. When the command in the unavailable state is specified by a second instruction based on the operation input, and it is possible to consume the second parameter, Consume the second parameter, The player character is instructed to perform the action associated with the command, Set the command to the disabled state, Reset the first parameter associated with the command. Information processing system.

12. The information processing system according to claim 11, wherein for each of the commands in the disabled state, the first parameter is updated in accordance with the passage of time as the game progresses.

13. The information processing system according to claim 12, wherein the first condition is satisfied when a time period of a length set for each command has elapsed since the first parameter was reset.

14. The information processing system according to any one of claims 11 to 13, wherein, when the command in the unavailable state is specified by the second instruction, the remaining second parameter is consumed by reducing the second parameter by an amount equal to the amount of reduction corresponding to the shortfall in the first parameter of the command at that time until the first condition is met.

15. An information processing system according to any one of claims 11 to 13, which recovers the second parameter after the end of the combat scene.

16. The information processing system according to claim 15, wherein the second parameter is not restored during the aforementioned combat scene.

17. During the aforementioned combat scene, the second parameter is not restored. After the end of the aforementioned combat scene, the second parameter is restored to its maximum value. An information processing system according to any one of claims 11 to 13, wherein the maximum value of the second parameter is increased in a predetermined scene in the game.

18. An information processing system according to any one of claims 11 to 13, wherein for each command, the system displays whether the command is in the available state or the unavailable state, an icon indicating the first parameter in the unavailable state, and a gauge indicating the second parameter.

19. The first instruction is an instruction that causes the user to select the command based on the directional input and to confirm the selected command in response to the first button input, The second instruction is an instruction that causes the user to select the command based on the directional input and to confirm the selected command in response to the second button input, The information processing system according to claim 18, which displays an indicator for each selected command indicating whether or not it is possible to consume the second parameter.

20. An information processing system according to any one of claims 11 to 13, wherein, during a period when a second condition regarding the combat situation is met, the effect of the action corresponding to the first of the multiple types of commands is higher than during a period when the second condition is not met.

21. In the information processing system, In combat scenes between player characters and enemy characters in games, Based on the operation input, one of several types of commands is specified by the first instruction, and if the state of the specified command is in the "available" state among the "available" and "unavailable" states, The player character is instructed to perform the action associated with the command, The command is then switched to the disabled state. The first parameter associated with a particular command, among the first parameters set for each command, is reset. For each of the commands in the disabled state, the respective first parameter is updated according to the game progress, and when the first parameter satisfies the first condition, the command associated with the first parameter is transitioned to the enabled state. When the command in the unavailable state is specified by a second instruction based on the operation input, and it is possible to consume the second parameter, This consumes the second parameter, The player character is instructed to perform the action associated with the command, Set the command to the disabled state described above. Reset the first parameter associated with the command. Game processing method.

22. In the aforementioned information processing system, The game processing method according to claim 21, wherein for each of the commands in the disabled state, the first parameter is updated in accordance with the passage of time as the game progresses.

23. The game processing method according to claim 22, wherein the first condition is satisfied when a time period of a length set for each command has elapsed since the first parameter was reset.

24. In the aforementioned information processing system, The game processing method according to any one of claims 21 to 23, wherein, when the command in the unavailable state is specified by the second instruction, the remaining second parameter is consumed by reducing the second parameter by an amount corresponding to the deficiency of the first parameter of the command at that time until the first condition is met.

25. In the aforementioned information processing system, A game processing method according to any one of claims 21 to 23, wherein the second parameter is restored after the end of the combat scene.

26. In the aforementioned information processing system, The game processing method according to claim 25, wherein the second parameter is not restored during the aforementioned combat scene.

27. In the aforementioned information processing system, During the aforementioned combat scene, the second parameter is not restored. After the end of the aforementioned combat scene, the second parameter is restored to its maximum value. A game processing method according to any one of claims 21 to 23, wherein the maximum value of the second parameter is increased in a predetermined scene in the game.

28. The aforementioned information processing system further includes: The game processing method according to any one of claims 21 to 23, wherein for each command, the method displays whether the command is in the usable state or the unusable state, an icon indicating the first parameter in the unusable state, and a gauge indicating the second parameter.

29. The first instruction is an instruction that causes the user to select the command based on the directional input and to confirm the selected command in response to the first button input, The second instruction is an instruction that causes the user to select the command based on the directional input and to confirm the selected command in response to the second button input, The aforementioned information processing system further includes: The game processing method according to claim 28, wherein for each selected command, an indicator is displayed showing whether or not it is possible to consume the second parameter.

30. The aforementioned information processing system further includes: A game processing method according to any one of claims 21 to 23, wherein, during a period when a second condition regarding the battle situation is met, the effect of the action corresponding to the first of the multiple types of commands is made higher than during a period when the second condition is not met.

31. An information processing device equipped with a processor, The aforementioned processor, In combat scenes between player characters and enemy characters in games, Based on the operation input, one of several types of commands is specified by the first instruction, and if the state of the specified command is in the "available" state among the "available" and "unavailable" states, The player character is instructed to perform the action associated with the command, The command is then switched to the disabled state. Reset the first parameter associated with the command, which is one of the first parameters set for each command. For each of the commands in the disabled state, the respective first parameter is updated according to the game progress, and when the first parameter satisfies the first condition, the command associated with the first parameter is transitioned to the enabled state. When the command in the unavailable state is specified by a second instruction based on the operation input, and it is possible to consume the second parameter, Consume the second parameter, The player character is instructed to perform the action associated with the command, Set the command to the disabled state, Reset the first parameter associated with the command. Information processing device.

Images