Computer-readable storage medium having game program stored therein, game system, game processing method, and game

Abstract

To provide a game program, a game processing method, a game system and a game device for providing a new method related with the capture and battle of a virtual character.SOLUTION: Controlling movement of a player character based on a first operation input, causing the player character to transition to a locked state in which an enemy character is locked based on a second operation input, and causing the player character to further perform a first action based on a third operation input in an unlocked state that is not the locked state; In a locked state and when a battle character appears in a virtual space, based on any of a first operation input group, a battle action corresponding to an operation input performed among a plurality of battle actions respectively corresponding to the first operation input group is caused to be performed on a locked enemy character, and the battle action is caused to transition to a non-runnable state and transition to a runnable state based on a lapse of time.SELECTED DRAWING: Figure 54

Description

[Technical Field]

[0001] The present disclosure relates to game processing that performs processing on a character in a virtual space. [Background technology]

[0002] Conventionally, there are known games in which a player character can capture a character in a virtual space by throwing a ball at the character and set the character as the player character's possession. Also, there is known a game in which a player character can start a battle with a combat character by throwing a combat character, instead of a ball, at the character in the virtual space (for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 07398425 Summary of the Invention [Problem to be solved by the invention]

[0004] With games like these, there was room for new approaches to character capture and combat. [Means for solving the problem]

[0005] In view of the above, the following configuration example can be given.

[0006] (Configuration 1) Configuration 1 is a game program that causes a computer to control the movement of a player character within a virtual space based on a first operation input that is a directional input, transitions the player character to a locked state in which an enemy character located within the virtual space is locked based on a second operation input, and in an unlocked state where the player character is not in the locked state, causes the player character to further perform a first action based on a third operation input, and when in the locked state and a combat character that will fight the enemy character has appeared in the virtual space, based on one of a first operation input group including the third operation input, if a combat action corresponding to the performed operation input among multiple combat actions corresponding to each of the first operation input group is in an executable state, causes the combat character to perform the combat action against the locked enemy character and transitions the combat action to an inactivatable state, and transitions the inactivatable combat action to an executable state based on the passage of time.

[0007] According to the above configuration, it is possible to have the attacking character attack while having the player character perform another action. Furthermore, with a limited number of buttons, it is possible to control two targets in real time. Furthermore, since a waiting time is provided for combat actions before they can be performed, it is possible to provide time to switch to player control between attacks. Furthermore, since the operations that do not need to be locked and the operations that do need to be locked are switched depending on whether the operations are locked, the limited number of buttons can be used efficiently.

[0008] (Configuration 2) In configuration 2, in the above configuration 1, the computer may further cause an enemy character to perform an enemy attack action which is an attack on the player character or the combat character, determine whether the enemy attack action has hit the player character based on the position where the enemy attack action was performed and the position of the player character, and, when the enemy attack action hits the player character, inflict damage on the player character, and perform an action to avoid the enemy attack action as a first action.

[0009] According to the above configuration, the element of having the player character avoid attacks is added, making the game more entertaining.

[0010] (Configuration 3) Configuration 3 may be configured in the above-described configuration 2, wherein the computer, in the unlocked state, controls the movement of the player character at high speed based on a fourth operation input included in the first operation input group.

[0011] According to the above configuration, an element of high-speed movement is added to the actions of the player character, thereby increasing the interest level.

[0012] (Configuration 4) In a fourth aspect of the present invention, in any one of the first to third aspects, the first action may be an action for performing movement control at high speed.

[0013] According to the above configuration, an element of high-speed movement is added to the actions of the player character, thereby increasing the interest level.

[0014] (Configuration 5) Configuration 5, in any of configurations 1 to 4 above, may further cause the computer to present a menu UI that allows the user to at least select a use item to be used for the combat character based on a fifth operation input included in the first operation input group, at least in a first state that is an unlocked state.

[0015] According to the above configuration, even during combat, the menu can be opened and items can be used. In addition, when the menu button is locked, it can be assigned to combat actions.

[0016] (Configuration 6) Configuration 6 may be such that, in any of configurations 1 to 5 above, the computer further selects one of a plurality of combat characters based on a sixth operation input not included in the first operation input group, and causes the selected combat character to appear in the virtual space based on a seventh operation input not included in the first operation input group.

[0017] According to the above configuration, the operation of selecting and appearing a combat character can be performed regardless of the lock state.

[0018] (Configuration 7) Configuration 7 may be such that, in any of configurations 1 to 6 above, the computer further controls the direction of the virtual camera based on an eighth operation input, which is a directional input, when unlocked, and controls the virtual camera based on the position of the enemy character to be locked on when locked, and changes the enemy character to be locked on based on the eighth operation input.

[0019] (Configuration 8) Configuration 8 may further include, in any of configurations 1 to 7, having the computer, based on a ninth operation input, cause the player character to release a capture item for capturing the enemy character, toward the enemy character to be locked in the locked state, or toward the aimed direction in the unlocked state, and if the capture item hits the enemy character, make a capture success determination, and if the capture success determination is successful, set the enemy character to a state in which it is held by the player.

[0020] (Configuration 9) Configuration 9 may be such that, in any of configurations 1 to 8 above, when one of the first group of operation inputs is performed in the locked state, the computer performs a combat action corresponding to the performed operation input by moving a combat character to a positional relationship set for that combat action, and then moving the combat character in the animation set for that combat action.

[0021] (Configuration 10) Configuration 10 may be such that, in the above configuration 9, if the combat action is a long-range attack action, the computer moves the combat character to a predetermined position based on the position of the player character and then makes a long-range attack on the enemy character to be locked, and if the combat action is a close-range attack action, the computer moves the combat character closer to the enemy character and makes a close-range attack.

[0022] (Configuration 11) Configuration 11 may be such that, in any of configurations 1 to 10 above, the computer increases a first parameter based on the execution of a combat action, and in a locked state, transitions to a state in which an enhanced combat action can be performed by consuming a first amount of the first parameter based on a tenth operation input, and strengthens the combat character by consuming a second amount of the first parameter that is greater than the first amount based on an eleventh operation input.

[0023] (Configuration 12) Configuration 12 may be configured in any one of configurations 1 to 11, wherein the computer transitions to the locked state while the second operation input is continuing and when the positional relationship between the player character and the enemy character satisfies a predetermined condition.

[0024] Furthermore, each of the above configurations may be realized as a game processing method executed by a computer including at least one processor, a game system including at least one processor, or a game device including at least one processor. [Brief explanation of the drawings]

[0025] [Figure 1] FIG. 1 shows an example of a state in which the left controller 3 and the right controller 4 are attached to the main unit 2. [Figure 2] FIG. 10 shows an example of a state in which the left controller 3 and the right controller 4 are detached from the main unit 2. [Figure 3] Six-sided views showing an example of the main unit 2 [Figure 4] Six-sided diagram showing an example of the left controller 3 [Figure 5] Six-sided diagram showing an example of the right controller 4 [Figure 6] A block diagram showing an example of the internal configuration of the main unit 2. [Figure 7] A block diagram showing an example of the internal configuration of the main unit 2, the left controller 3, and the right controller 4. [Figure 8] FIG. 10 is a diagram showing an example of a third controller. [Figure 9] A block diagram showing an example of the internal configuration of a third controller. [Figure 10] An example of a game screen according to this embodiment [Figure 11] An example of a game screen according to this embodiment [Figure 12] An example of a game screen according to the first embodiment [Figure 13] An example of a game screen according to the first embodiment [Figure 14] An example of a game screen according to the first embodiment [Figure 15] An example of a game screen according to the first embodiment [Figure 16] An example of a game screen according to the first embodiment [Figure 17] An example of a game screen according to the first embodiment [Figure 18] An example of a game screen according to the first embodiment [Figure 19] An example of a game screen according to the first embodiment [Figure 20] An example of a game screen according to the first embodiment [Figure 21] An example of a game screen according to the first embodiment [Figure 22] An example of a game screen according to the first embodiment [Figure 23] An example of a game screen according to the first embodiment [Figure 24] An example of a game screen according to the first embodiment [Figure 25] An example of a game screen according to the first embodiment [Figure 26] An example of a game screen according to the first embodiment [Figure 27] An example of a game screen according to the first embodiment [Figure 28] An example of a game screen according to the first embodiment [Figure 29] An example of a game screen according to the first embodiment [Figure 30] A memory map showing an example of various data stored in the DRAM 85 [Figure 31] An example of the data configuration of the character master data 309 [Figure 32] An example of the data structure of the owned character data 310 [Figure 33] An example of the data configuration of FC management data 318 [Figure 34] 1 is a flowchart showing details of a game process according to a first embodiment; [Figure 35] Flowchart showing details of PC control processing [Figure 36] Flowchart showing details of movement control processing [Figure 37] Flowchart showing details of appearance control processing [Figure 38] Flowchart showing details of stance-related processing [Figure 39] Flowchart showing details of lock-on related processing [Figure 40] Flowchart showing details of capture action processing [Figure 41] Flowchart showing details of capture determination processing [Figure 42] Flowchart showing details of BC control processing [Figure 43] Flowchart showing details of BC control processing [Figure 44] Flowchart showing details of FC control processing [Figure 45] Flowchart showing details of non-combat state processing [Figure 46] Flowchart showing details of combat state processing [Figure 47] Flowchart showing details of combat state processing [Figure 48] Flowchart showing details of chance state processing [Figure 49] A diagram illustrating the operation of the owned character column 201. [Figure 50] A diagram illustrating the operation of the owned character column 201. [Figure 51] A diagram illustrating the operation of the owned character column 201. [Figure 52] FIG. 10 is a diagram for explaining an operation in the second embodiment; [Figure 53] A memory map showing an example of various data in the second embodiment. [Figure 54] 10 is a flowchart showing details of a game process according to a second embodiment. [Figure 55] 10 is a flowchart showing details of a PC control process according to a second embodiment. [Figure 56] Flowchart showing details of movement-related processing [Figure 57] Flowchart showing details of normal movement processing [Figure 58] Flowchart showing details of the lock state move process [Figure 59] Flowchart showing details of lock-related processing [Figure 60] Flowchart showing details of lock mode processing [Figure 61] Flowchart showing details of capture-related processing [Figure 62] 10 is a flowchart showing details of a capture action process according to a second embodiment. [Figure 63] 10 is a flowchart showing details of instruction operation-related processing. [Figure 64] Flowchart showing details of normal command processing [Figure 65] Flowchart showing attack command processing details [Figure 66] Flowchart showing details of appearance control processing [Figure 67] Flowchart showing details of right stick control processing [Figure 68] 10 is a flowchart showing details of a BC control process according to a second embodiment. [Figure 69] 10 is a flowchart showing details of a BC control process according to a second embodiment. [Figure 70] Flowchart showing details of reinforced state control processing [Figure 71] 10 is a flowchart showing details of a virtual camera control process. [Figure 72] Flowchart showing details of menu processing [Figure 73] Flowchart showing details of map processing DETAILED DESCRIPTION OF THE INVENTION

[0026] An embodiment will be described below. FIG. 1 shows an example of the appearance of a game system according to this embodiment. An example of a game system 1 according to this embodiment includes a main unit (information processing device; in this embodiment, it functions as a game device main unit) 2, which is an example of a computer, and a left controller 3 and a right controller 4. The left controller 3 and the right controller 4 are each detachable from the main unit 2. 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. The game system 1 can also be used by separating the main unit 2 from the left controller 3 and the right controller 4 (see FIG. 2). Below, the hardware configuration of the game system 1 according to this embodiment will be described, followed by a description of the control of the game system 1 according to this embodiment.

[0027] FIG. 1 above is a diagram showing an example of a state in which a left controller 3 and a right controller 4 are attached to a main unit 2. As shown in FIG. 1, the left controller 3 and the right controller 4 are each attached to and integrated with the main unit 2. The main unit 2 is a device that executes various processes (e.g., game processes) in the game system 1. The main unit 2 is equipped with a display 12. The left controller 3 and the right controller 4 are devices that have operation units that allow the player to perform inputs.

[0028] Fig. 2 is a diagram showing an example of the state in which the left controller 3 and the right controller 4 are detached from the main unit 2. As shown in Figs. 1 and 2, the left controller 3 and the right controller 4 are detachable from the main unit 2. Note that, below, the left controller 3 and the right controller 4 may be collectively referred to as "controllers."

[0029] Fig. 3 is a six-sided view showing an example of the main unit 2. As shown in Fig. 3, the main unit 2 includes a substantially plate-shaped housing 11. In this embodiment, the main surface of the housing 11 (in other words, the front surface, i.e., the surface on which the display 12 is provided) is generally rectangular.

[0030] The shape and size of the housing 11 are arbitrary. As an example, the housing 11 may be of a portable size. Furthermore, the main unit 2 alone or an integrated device in which the left controller 3 and right controller 4 are attached to the main unit 2 may be a portable device. Furthermore, the main unit 2 or the integrated device may be a handheld device. Furthermore, the main unit 2 or the integrated device may be a portable device.

[0031] 3, the main unit 2 includes a display 12 provided on the main surface of the housing 11. 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.

[0032] The main device 2 also includes a touch panel 13 on the screen of the display 12. In this embodiment, the touch panel 13 is of a type that allows multi-touch input (for example, a capacitance type). However, the touch panel 13 may be of any type, and may be of a type that allows single-touch input (for example, a resistive type).

[0033] The main unit 2 is provided with a speaker (i.e., speaker 88 shown in FIG. 6) inside the housing 11. As shown in FIG. 3, speaker holes 11a and 11b are formed on the main surface of the housing 11. The output sound of the speaker 88 is output from these speaker holes 11a and 11b, respectively.

[0034] The main unit 2 also has a left terminal 17, which is a terminal for the main unit 2 to communicate with the left controller 3 via a wired connection, and a right terminal 21, which is a terminal for the main unit 2 to communicate with the right controller 4 via a wired connection.

[0035] As shown in FIG. 3, the main unit 2 includes a slot 23. The slot 23 is provided on the upper side of the housing 11. The slot 23 has a shape that allows a predetermined type of storage medium to be inserted therein. 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 the same type of information processing device. The predetermined type of storage medium is used, for example, to store data used by the main unit 2 (e.g., application save data, etc.) and / or programs executed by the main unit 2 (e.g., application programs, etc.). The main unit 2 also includes a power button 28.

[0036] The main unit 2 has a lower terminal 27. The lower terminal 27 is a terminal through which the main unit 2 communicates with the cradle. In this embodiment, the lower terminal 27 is a USB connector (more specifically, a female connector). When the all-in-one device or the main unit 2 alone is placed on the cradle, the game system 1 can display images generated and output by the main unit 2 on a stationary monitor. In this embodiment, the cradle also has the function of charging the all-in-one device or the main unit 2 alone that is placed on it. The cradle also has the function of a hub device (specifically, a USB hub).

[0037] FIG. 4 is a six-sided view showing an example of the left controller 3. As shown in FIG. 4, the left controller 3 includes a housing 31. In this embodiment, the housing 31 has a vertically long shape, that is, a shape that is long in the up-down direction in FIG. 4 (the y-axis direction shown in FIG. 4). The left controller 3 can also be held in a vertically long orientation when detached from the main unit 2. The housing 31 has a shape and size that allows it to be held in one hand, particularly the left hand, when held in a vertically long orientation. The left controller 3 can also be held in a horizontally long orientation. When the left controller 3 is held in a horizontally long orientation, it may be held with both hands.

[0038] The left controller 3 is equipped with a left analog stick (hereinafter referred to as the left stick) 32, which is an example of a directional input device. As shown in FIG. 4, the left stick 32 is provided on the main surface of the housing 31. The left stick 32 can be used as a directional input unit that can input directions. By tilting the left stick 32, the player can input a direction corresponding to the tilt direction (and input a magnitude corresponding to the tilt angle). Note that the left controller 3 may be equipped with a cross key or a slide stick that can perform slide inputs, instead of an analog stick, as a directional input unit. In this embodiment, input can be made by pressing down the left stick 32.

[0039] The left controller 3 is equipped with various operation buttons. The left controller 3 is equipped with four operation buttons 33 to 36 (specifically, a right button 33, a down button 34, an up button 35, and a left button 36) on the main surface of the housing 31. The left controller 3 is also equipped with a record button 37 and a - (minus) button 47. The left controller 3 is equipped with a first L button 38 and a ZL button 39 on the upper left side of the housing 31. The left controller 3 is also equipped with a second L button 43 and a second R button 44 on the side of the housing 31 that is attached to the main unit 2. These operation buttons are used to issue instructions according to various programs (for example, OS programs and application programs) executed on the main unit 2.

[0040] The left controller 3 also includes a terminal 42 for wired communication between the left controller 3 and the main unit 2.

[0041] FIG. 5 is a six-sided view showing an example of the right controller 4. As shown in FIG. 5, the right controller 4 includes a housing 51. In this embodiment, the housing 51 has a vertically long shape, that is, a shape that is long in the up-down direction in FIG. 5 (the y-axis direction shown in FIG. 5). The right controller 4 can also be held in a vertically long orientation when detached from the main unit 2. The housing 51 has a shape and size that allows it to be held in one hand, particularly the right hand, when held in a vertically long orientation. The right controller 4 can also be held in a horizontally long orientation. When the right controller 4 is held in a horizontally long orientation, it may be held with both hands.

[0042] Like the left controller 3, the right controller 4 is equipped with a right analog stick (hereinafter referred to as the right stick) 52 as a directional input unit. In this embodiment, the right stick 52 has the same configuration as the left stick 32 of the left controller 3. The right controller 4 may also be equipped with a cross key or a slide stick capable of slide input, instead of an analog stick. Like the left controller 3, the right controller 4 is equipped with four operation buttons 53 to 56 (specifically, an A button 53, a B button 54, an X button 55, and a Y button 56) on the main surface of the housing 51. The right controller 4 is further equipped with a + (plus) button 57 and a home button 58. The right controller 4 is also equipped with a first R button 60 and a ZR button 61 on the upper right side of the housing 51. Like the left controller 3, the right controller 4 is also equipped with a second L button 65 and a second R button 66.

[0043] The right controller 4 also includes a terminal 64 for wired communication between the right controller 4 and the main unit 2.

[0044] Fig. 6 is a block diagram showing an example of the internal configuration of main unit 2. In addition to the configuration shown in Fig. 3, main unit 2 includes components 81-91, 97, and 98 shown in Fig. 6. Some of these components 81-91, 97, and 98 may be mounted on an electronic circuit board as electronic components and housed in housing 11.

[0045] The main unit 2 includes a processor 81. The processor 81 is an information processing unit that executes various types of information processing executed in the main unit 2, and may be composed of, for example, only a CPU (Central Processing Unit), or may be composed of an SoC (System-on-a-chip) that includes multiple functions such as a CPU function and a GPU (Graphics Processing Unit) function. The processor 81 executes various types of information processing by executing an information processing program (for example, a game program) stored in a storage unit (specifically, an internal storage medium such as flash memory 84, or an external storage medium inserted into slot 23, etc.).

[0046] The main device 2 includes a flash memory 84 and a DRAM (Dynamic Random Access Memory) 85 as examples of internal storage media built into the main device 2. The flash memory 84 and the DRAM 85 are connected to the processor 81. The flash memory 84 is a memory used primarily to store various types of data (which may be programs) saved in the main device 2. The DRAM 85 is a memory used to temporarily store various types of data used in information processing.

[0047] The main device 2 includes a slot interface (hereinafter abbreviated as "I / F") 91. The slot I / F 91 is connected to the processor 81. The slot I / F 91 is connected to the slot 23, and reads and writes data from and to a predetermined type of storage medium (e.g., a dedicated memory card) inserted into the slot 23 in accordance with instructions from the processor 81.

[0048] The processor 81 reads and writes data from and to the flash memory 84, DRAM 85, and the above-mentioned storage media as appropriate, to execute the above-mentioned information processing.

[0049] The main unit 2 includes a network communication unit 82. The network communication unit 82 is connected to the processor 81. The network communication unit 82 communicates with external devices via a network (specifically, wireless communication). In this embodiment, the network communication unit 82 connects to a wireless LAN and communicates with external devices using a method conforming to the Wi-Fi standard as a first communication mode. The network communication unit 82 also performs wireless communication with other main units 2 of the same type using a predetermined communication method (e.g., communication using a proprietary protocol or infrared communication) as a second communication mode. Note that wireless communication using the second communication mode enables wireless communication with other main units 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 direct communication between multiple main units 2.

[0050] The main unit 2 is equipped with a controller communication unit 83. The controller communication unit 83 is connected to the processor 81. The controller communication unit 83 performs wireless communication with the left controller 3 and / or right controller 4. Any communication method may be used between the main unit 2 and the left controller 3 and right controller 4, but in this embodiment, the controller communication unit 83 performs communication with the left controller 3 and right controller 4 in accordance with the Bluetooth (registered trademark) standard.

[0051] The processor 81 is connected to the left terminal 17, right terminal 21, and lower terminal 27. When performing wired communication with the left controller 3, the processor 81 transmits data to the left controller 3 via the left terminal 17 and receives operation data from the left controller 3 via the left terminal 17. When performing wired communication with the right controller 4, the processor 81 transmits data to the right controller 4 via the right terminal 21 and receives operation data from the right controller 4 via the right terminal 21. When performing wired communication with the right controller 4, the processor 81 transmits data to the cradle via the lower terminal 27. As described above, in this embodiment, the main unit 2 can perform both wired and wireless communication with the left controller 3 and the right controller 4. When an integrated device in which the left controller 3 and the right controller 4 are attached to the main unit 2 or the main unit 2 alone is attached to the cradle, the main unit 2 can output data (e.g., image data and audio data) to a stationary monitor or the like via the cradle.

[0052] Here, the main unit 2 can communicate simultaneously (in other words, in parallel) with multiple left controllers 3. The main unit 2 can also communicate simultaneously (in other words, in parallel) with multiple right controllers 4. Therefore, multiple players can simultaneously input to the main unit 2 using their own sets of left controllers 3 and right controllers 4. For example, a first player can input to the main unit 2 using a first set of left controllers 3 and right controllers 4, while a second player can simultaneously input to the main unit 2 using a second set of left controllers 3 and right controllers 4.

[0053] The main device 2 includes a touch panel controller 86, which is a circuit that controls the touch panel 13. The touch panel controller 86 is connected between the touch panel 13 and the processor 81. Based on a signal from the touch panel 13, the touch panel controller 86 generates data indicating, for example, the position where a touch input was made, and outputs the data to the processor 81.

[0054] The display 12 is also connected to the processor 81. The processor 81 displays on the display 12 an image generated (for example, by executing the above-described information processing) and / or an image acquired from the outside.

[0055] The main unit 2 includes a codec circuit 87 and speakers (specifically, a left speaker and a right speaker) 88. The codec circuit 87 is connected to the speakers 88 and the audio input / output terminal 25, and is also connected to the processor 81. The codec circuit 87 is a circuit that controls the input and output of audio data to and from the speakers 88 and the audio input / output terminal 25.

[0056] The main device 2 includes a power control unit 97 and a battery 98. The power control unit 97 is connected to the battery 98 and the processor 81. Although not shown, the power control unit 97 is also connected to each part of the main device 2 (specifically, each part that receives power from the battery 98, the left terminal 17, and the right terminal 21). The power control unit 97 controls the power supply from the battery 98 to each of the above parts based on instructions from the processor 81.

[0057] Furthermore, battery 98 is connected to lower terminal 27. When an external charging device (e.g., a cradle) is connected to lower terminal 27 and power is supplied to main device 2 via lower terminal 27, battery 98 is charged with the supplied power.

[0058] Figure 7 is a block diagram showing an example of the internal configuration of the main unit 2, left controller 3, and right controller 4. Note that details of the internal configuration of the main unit 2 are omitted in Figure 7 because they are shown in Figure 6.

[0059] The left controller 3 is equipped with a communication control unit 101 that communicates with the main unit 2. As shown in FIG. 7 , the communication control unit 101 is connected to each component, including the terminal 42. In this embodiment, the communication control unit 101 can communicate with the main unit 2 both via wired communication via the terminal 42 and via wireless communication without using the terminal 42. The communication control unit 101 controls the method of communication between the left controller 3 and the main unit 2. That is, when the left controller 3 is attached to the main unit 2, the communication control unit 101 communicates with the main unit 2 via the terminal 42. When the left controller 3 is detached from the main unit 2, the communication control unit 101 communicates wirelessly with the main unit 2 (specifically, with the controller communication unit 83). Wireless communication between the controller communication unit 83 and the communication control unit 101 is performed in accordance with, for example, the Bluetooth (registered trademark) standard.

[0060] The left controller 3 also includes a memory 102, such as a flash memory. The communication control unit 101 is configured, for example, by a microcomputer (also called a microprocessor), and executes firmware stored in the memory 102 to perform various processes.

[0061] The left controller 3 includes buttons 103 (specifically, buttons 33 to 39, 43, 44, and 47). The left controller 3 also includes a left stick 32. Each button 103 and left stick 32 repeatedly outputs information relating to an operation performed on that button 103 and left stick 32 to the communication control unit 101 at an appropriate timing.

[0062] The left controller 3 is equipped with an inertial sensor. Specifically, the left controller 3 is equipped with an acceleration sensor 104. The left controller 3 is also equipped with an angular velocity sensor 105. In this embodiment, the acceleration sensor 104 detects the magnitude of acceleration along three predetermined axes (for example, the x, y, and z axes shown in FIG. 4). The acceleration sensor 104 may detect acceleration along one or two axes. In this embodiment, the angular velocity sensor 105 detects angular velocity around three predetermined axes (for example, the x, y, and z axes shown in FIG. 4). The angular velocity sensor 105 may detect angular velocity around one or two axes. The acceleration sensor 104 and the angular velocity sensor 105 are each connected to the communication control unit 101. The detection results of the acceleration sensor 104 and the angular velocity sensor 105 are repeatedly output to the communication control unit 101 at appropriate timing.

[0063] The communication control unit 101 acquires information about the input (specifically, information about the operation or the detection results by the sensors) from each input unit (specifically, each button 103, left stick 32, and each sensor 104 and 105). The communication control unit 101 transmits operation data including the acquired information (or information obtained by performing a predetermined process on the acquired information) to the main unit 2. The operation data is repeatedly transmitted once every predetermined time. The interval at which the information about the input is transmitted to the main unit 2 may or may not be the same for each input unit.

[0064] By transmitting the above operation data to the main unit 2, the main unit 2 can obtain the input made to the left controller 3. That is, the main unit 2 can determine the operation of each button 103 and left stick 32 based on the operation data. Furthermore, the main unit 2 can calculate information regarding the movement and / or posture of the left controller 3 based on the operation data (specifically, the detection results of the acceleration sensor 104 and the angular velocity sensor 105).

[0065] The left controller 3 is equipped with a vibrator 107 for notifying the user by vibration. In this embodiment, the vibrator 107 is controlled by commands from the main unit 2. That is, when the communication control unit 101 receives the command from the main unit 2, it drives the vibrator 107 in accordance with the command. Here, the left controller 3 is equipped with a codec unit 106. When the communication control unit 101 receives the command, it outputs a control signal corresponding to the command to the codec unit 106. The codec unit 106 generates a drive signal for driving the vibrator 107 from the control signal from the communication control unit 101 and provides the drive signal to the vibrator 107. This causes the vibrator 107 to operate.

[0066] More specifically, the vibrator 107 is a linear vibration motor. Unlike conventional motors that perform rotary motion, a linear vibration motor is driven in a predetermined direction in response to an input voltage, allowing it to vibrate at an amplitude and frequency corresponding to the input voltage waveform. In this embodiment, the vibration control signal transmitted from the main unit 2 to the left controller 3 may be a digital signal representing the frequency and amplitude per unit time. In another embodiment, the main unit 2 may transmit information representing the waveform itself, but transmitting only the amplitude and frequency can reduce the amount of communication data. To further reduce the amount of data, the main unit 2 may transmit only the difference from the previous value instead of the current amplitude and frequency values. In this case, the codec unit 106 converts the digital signal representing the amplitude and frequency values ​​acquired from the communication control unit 101 into an analog voltage waveform and inputs a voltage corresponding to the waveform to drive the vibrator 107. Therefore, the main unit 2 can control the amplitude and frequency at which the vibrator 107 vibrates by changing the amplitude and frequency transmitted per unit time. The main unit 2 may transmit two or more amplitudes and frequencies to the left controller 3. In this case, the codec unit 106 can generate a voltage waveform for controlling the vibrator 107 by combining the waveforms indicated by the received multiple amplitudes and frequencies.

[0067] The left controller 3 is equipped with a power supply unit 108. In this embodiment, the power supply unit 108 has a battery and a power control circuit. Although not shown, the power control circuit is connected to the battery and to each part of the left controller 3 (specifically, each part that receives power from the battery).

[0068] As shown in FIG. 7, the right controller 4 is equipped with a communication control unit 111 that communicates with the main unit 2. The right controller 4 also has a memory 112 that is connected to the communication control unit 111. The communication control unit 111 is connected to each component, including the terminal 64. The communication control unit 111 and memory 112 have the same functions as the communication control unit 101 and memory 102 of the left controller 3. Therefore, the communication control unit 111 can communicate with the main unit 2 both via wired communication via the terminal 64 and via wireless communication that does not use the terminal 64 (specifically, communication in accordance with the Bluetooth (registered trademark) standard), and controls the method of communication between the right controller 4 and the main unit 2.

[0069] The right controller 4 has input units similar to those of the left controller 3. Specifically, it has buttons 113, a right stick 52, and inertial sensors (an acceleration sensor 114 and an angular velocity sensor 115). These input units have the same functions as those of the left controller 3, and operate in the same manner.

[0070] The right controller 4 also includes a vibrator 117 and a codec unit 116. The vibrator 117 and the codec unit 116 operate in the same manner as the vibrator 107 and the codec unit 106 of the left controller 3. That is, the communication control unit 111 operates the vibrator 117 using the codec unit 116 in accordance with instructions from the main unit 2.

[0071] The right controller 4 is equipped with a power supply unit 118. The power supply unit 118 has the same functions as the power supply unit 108 of the left controller 3 and operates in the same manner.

[0072] The controllers are not limited to the left controller 3 and right controller 4 described above, and a controller such as that shown in FIG. 8 may also be used. The controller shown in FIG. 8 is one of the peripheral devices, and is a controller (hereinafter referred to as the third controller) configured so that the right controller 4 and the left controller 3 are integrated. Therefore, the operation units and functions provided are also similar to those of the above-mentioned controllers. Specifically, the third controller in FIG. 8 is provided, on approximately the left half of its housing, with a left stick 32, a right directional button 33, a down directional button 34, an up directional button 35, a left directional button 36, a record button 37, a - button 47, and a first L button 38, similar to those of the left controller 3. Although not shown, the third controller is also provided with a ZL button 39, similar to those of the left controller 3. The third controller is also provided, on approximately the right half, with a right stick 52, an A button 53, a B button 54, an X button 55, a Y button 56, a + button 57, a home button 58, and a first R button 60, similar to those of the right controller 4. Although not shown, the right controller 4 also has a ZR button 61.

[0073] 9 is a block diagram showing an example of the internal configuration of the third controller. Like the above-mentioned controllers, it includes a communication control unit 101 that communicates with the main unit 2, a terminal 42, a memory 102, the above-mentioned buttons 123, a left stick 32, a right stick 52, and a power supply unit 108. Each component is the same as the component described above with reference to FIG. 7, so a description thereof will be omitted here.

[0074] [Outline of game processing in the first embodiment] Next, an overview of the operation of the game processing executed by the game system 1 according to the first embodiment will be described. As described above, in the game system 1, the main unit 2 is configured so that the left controller 3 and the right controller 4 can be detachably attached to each other. When playing a game with the left controller 3 and the right controller 4 attached to the main unit 2, game images are output to the display 12. Furthermore, when the main unit 2 alone with the left controller 3 and the right controller 4 detached is attached to a cradle, the main unit 2 can also output game images to a stationary monitor or the like via the cradle. In the first embodiment, the latter mode of gameplay will be mainly described as an example. Specifically, the main unit 2 alone with the left controller 3 and the right controller 4 detached is attached to a cradle, and the main unit 2 outputs game images and the like to a stationary monitor or the like via the cradle. Of course, similar game processing can be performed when playing in the former mode or when playing using the third controller.

[0075] In the following description, the left controller 3 and the right controller 4 may be collectively referred to simply as "controllers."

[0076] [About the assumed game] Next, a game assumed in the first embodiment will be described. The game according to the first embodiment is a game in which a field character (hereinafter referred to as FC) on a virtual field (hereinafter simply referred to as field) in a virtual space is captured and made into the possession of a player character (hereinafter referred to as PC). More specifically, in the first embodiment, the PC throws a capture item at the FC, and a determination is made as to whether the capture is successful, and if successful, the FC can be captured. In the first embodiment, the process related to the capture will be mainly described.

[0077] Below, an overview of the capture process in the first embodiment will be explained using screen examples. FIG. 10 is an example of a game image of the game. In FIG. 10, a three-dimensional virtual space is displayed from a third-person perspective as seen from a viewpoint behind the PC. The virtual camera is basically controlled to move while following the PC. In FIG. 10, the PC, FC, and owned character column 201 are displayed. Note that the FC in FIG. 10 is in a "non-combat state" as described below. As will be described in detail later, the FC can transition from a "non-combat state" to a "combat state" or a "chance state." The owned character column 201 also displays the characters that the PC currently owns (hereinafter referred to as "owned characters"). In the example of FIG. 10, it is shown that the PC owns three owned characters.

[0078] Here, we will briefly explain the movement and camera operations in this game. In this game, the player can move the PC in a desired direction on the field in virtual space by operating the left stick 32. In addition, the player can change the direction of the virtual camera by operating the right stick 52.

[0079] Next, an example of the operation related to the above capture will be explained using an example screen. In this game, you can attempt to capture an FC by throwing the capture item at it. To give a specific example of the operation, when the player presses the ZR button 61 in the state of Figure 10 (hereinafter referred to as the ready operation), the PC will enter a "ready" state to throw the capture item 202, as shown in Figure 12. Figure 12 shows a state in which the PC is holding a ball-shaped capture item 202 in its right hand and raising its right arm. Hereinafter, this state will be referred to as the "ready state." The "ready state" basically continues as long as the ZR button 61 is pressed. Note that a state of the PC that is not in the "ready state" (the state of Figure 10 above) will be referred to as the "normal state" below.

[0080] Furthermore, when the PC is in a ready state, a crosshair 203 is also displayed in the center of the screen as shown in Fig. 11 above. The crosshair 203 indicates the direction (or landing point) of throwing the capture item 202. When the player stops pressing the ZR button 61 (releases his / her finger from the ZR button 61) in the ready state, the PC will perform the action of throwing the capture item at the crosshair 203 (hereinafter referred to as the capture action).

[0081] Furthermore, if the PC is moved in the state shown in FIG. 11 above, it will be a "strife move" in which the PC moves left and right without changing its orientation. In this case, the aim 203 will always be displayed in the center of the screen while moving left and right. FIG. 12 shows an example of the state in which the PC has been moved slightly to the right from the state shown in FIG. 11 above. Note that since the capture item 202 is thrown toward the aim 203, it is also possible to throw the capture item 202 at a target other than the FC, for example.

[0082] [About Lock-On] Here, we will provide additional information regarding the lock-on function of the crosshair 203. In this game, for example, when the PC is in the stance shown in FIG. 12, the crosshair 203 can be fixed and locked onto the nearest FC by pressing the ZL button 39 (hereinafter referred to as the lock-on operation) as shown in FIG. 13. When locked on, the display mode of the crosshair 203 also changes slightly to make it clear. Also, when locked on, the locked-on target is displayed as being located at the center of the screen (i.e., the crosshair 203 remains at the center of the screen). Then, when the player throws the capture item 202 while locked on, the capture item 202 is thrown at the locked-on FC. Also, by releasing the finger from the ZL button 39 (hereinafter referred to as the lock-off operation), the lock-on is released. Also, when another FC is within a predetermined range during lock-on, the lock-on target can be switched to another FC by operating the right stick 52. In other words, during lock-on, the direction of the virtual camera cannot be changed using the right stick 52.

[0083] Furthermore, if the PC is moved during lock-on, the aim 203 is fixed to the FC, so movement is controlled so that the aim 203 and the locked-on FC are always displayed in the center of the screen. In other words, movement control (and virtual camera control) is performed so that the orientation of the PC (or the orientation of the virtual camera) always faces the direction of the locked-on FC.

[0084] [About capture actions] Next, the capture action will be described in more detail. As described above, when the player stops pressing the ZR button 61 in the ready state, the player can throw the capture item 202 toward the target, as shown in FIG. 14. Hereinafter, the state from when the PC starts the motion of throwing the capture item to when the capture determination result is announced will be referred to as the capture action state. In other words, when the player stops pressing the ZR button 61, the PC transitions from the ready state to the capture action state. After the capture determination result is announced, the PC transitions to the normal state. Note that FIG. 14 shows an example in which the capture item 202 is thrown in a locked-on state. Therefore, the capture item 202 moves toward the locked-on FC. As a result, it is assumed that the capture item 202 hits the FC, as shown in FIG. 15. Note that a hit here may refer to a collision between the capture item 202 and the FC, or may be considered to have occurred when the capture item 202 and the FC are in close proximity but not strictly speaking a collision. When the capture item 202 hits an FC, a determination is made as to whether the capture has been successful (hereinafter referred to as a capture determination). In this example, a capture success rate is preset for each FC, and a lottery is held using this capture success rate to determine whether the capture has been successful. Note that, as will be described in detail later, this capture success rate can be adjusted depending on the situation. If the capture determination results in a successful capture, an effect in which the FC disappears from the field (hereinafter referred to as a disappearance effect) is displayed, as shown in FIG. 16, and then a capture effect such as that shown in FIGS. 17 and 18 is displayed. In the capture effect shown in FIG. 17, an effect is displayed in which a ball-shaped object (indicating that an FC is contained in the thrown capture item 202) flies toward the owned character column 201. Then, as shown in FIG. 18, a display is displayed in which the currently captured FC has been added to the owned character column 201. The example in FIG. 18 shows that the currently captured FC has been added as the fourth owned character.

[0085] On the other hand, if the capture check fails, the FC's state changes from "non-combat state" to "combat state." In "combat state," the FC will attack the PC or a combat character (hereinafter referred to as BC), which will be explained next.

[0086] In the first embodiment, the number of capture items 202 available is limited. Performing one capture action consumes one capture item 202, regardless of whether the capture is successful or not. While the first embodiment uses one type of capture item 202, other embodiments may use multiple types of capture items 202 with different performance. For example, in addition to the normal capture item 202, there may be a high-performance capture item 202 that increases the capture success rate by 10%. The type of capture item 202 to be used may be specified when transitioning to the ready state. For example, the type of capture item 202 to be used may be specified by operating the right direction button 33 or the left direction button 36 while in the ready state.

[0087] Furthermore, the above-mentioned ready state can be released not only by releasing the press of the ZR button 61, but also by pressing the B button 54 while keeping the ZR button 61 pressed (hereinafter referred to as a ready release operation).

[0088] [About combat] Next, we will explain the combat elements with the FC and the capture mentioned above. In this game, the PC cannot directly attack the FC. To combat the FC, the BC mentioned above must be used. Specifically, a specific operation is required to make the BC appear on the field and have the BC fight the FC. In this game, when combating the FC, the screen does not switch to a separate battle screen such as a battle scene; instead, combat with the FC begins seamlessly once the battle start conditions are met. Furthermore, the BC and the FC perform attacks in parallel based on the player's instructions and a specific algorithm, respectively, resulting in a real-time battle. The battle start conditions include a failed capture action in the "non-combat state" mentioned above, the FC noticing the approach of the PC or BC, as explained below, and the FC being attacked by the BC without noticing.

[0089] Before explaining the battle elements, let's first explain BC. In this game, you can select one of the characters owned by the PC that is capable of fighting and have it appear on the field as the BC. Hereinafter, the operation to make a BC appear on the field will be referred to as the "BC appearance operation."

[0090] 19 to 21 show examples of screens (examples of appearance effects) when a BC appearance operation is performed. These screen examples are examples in which, with the PC located at the position shown in FIG. 12, the player selects a character he or she wants to have appear by performing a predetermined operation and performs a BC appearance operation to make the BC appear. In this case, the selected character appears as the BC at a predetermined position, for example, diagonally in front of the right of the PC. In the appearance effects shown in FIGS. 19 to 21, first, as shown in FIG. 19, a ball containing a character to be made to appear as the BC (hereinafter, the BC ball) is thrown in a predetermined direction. Then, as shown in FIG. 20, a smoke-like effect is displayed where the BC ball lands. Then, as shown in FIG. 21, the selected character appears as the BC. Note that the BC may perform any animation during the appearance effect. For example, the BC may perform a roaring motion after appearing. In particular, during battle, the BC may perform a roaring motion before it becomes commandable, and a waiting time may be set before it becomes commandable, so that switching the BC does not become too advantageous. The position where the BC appears and the direction in which the BC ball is thrown may be specified by the player. For example, a cursor that can be moved within a predetermined range centered on the PC and that indicates the appearance position may be displayed and operated by the player. The PC may then aim the BC ball in the direction of the cursor or at the position of the cursor.

[0091] With the appearance of the BC, as shown in FIG. 21 , a BC information field 204, an attack option field 205, and a power gauge 208 are additionally displayed on the screen. The BC information field 204 displays a facial image of the BC and a health bar indicating the BC's health value. The attack option field 205 is a collection of four diamond-shaped images, which indicate the attack methods available to the BC. The player can issue attack instructions to the BC by referring to the attack option field 205. Specifically, in this game, each BC (FC) has up to four attack methods. These four attack methods are assigned to one of the A button 53, B button 54, X button 55, and Y button 56 (hereinafter collectively referred to as the ABXY buttons) on the controller and displayed in the attack option field 205. Each of the four diamond-shaped images is arranged to resemble the layout of the ABXY buttons, making it easy to intuitively understand which attack method corresponds to which button. Therefore, by pressing one of the ABXY buttons, the player can have the BC perform an attack action using the attack method corresponding to that button. Such attacks can change the state of the FC. Examples of attack methods include, for example, an attack method that reduces the FC's health value, an attack method that inflicts a status abnormality or weakens the FC (debuff), etc. Note that actions that do not directly affect the FC, such as actions that restore one's own health value or apply a so-called "buff," may also be included in this definition. Such attack actions reduce the FC's health value or inflict a status abnormality, thereby increasing the success rate of capturing the FC. Therefore, for example, rather than attempting a capture action without introducing the BC as described above, having the BC attack the FC and reduce the FC's health value before attempting a capture action will result in a higher success rate of capture (although this rate is lower than in the chance state described below). The power gauge 208 is a gauge that accumulates a predetermined amount by issuing an attack command to the BC, and by consuming a predetermined amount of the accumulated gauge, it is possible to make the BC perform a more powerful attack.

[0092] The BC that appears as described above can act autonomously to a certain extent based on a predetermined algorithm. For example, if there is no FC nearby, the BC will follow the PC. Also, if there is an FC nearby, the BC will move closer to the FC. The player can also instruct the BC to act.

[0093] Figure 22 shows a situation in which the BC has approached the FC to a certain extent as a result of the player's instructions or the BC's autonomous actions. In other words, it shows a situation in which the relative positions of the FC and the BC satisfy a predetermined condition, in this case, a certain distance or less. In this case, the FC is considered to have "noticed" the presence of the BC. As a result, the FC transitions from a "non-combat state" to a "combat state" and launches an attack on the BC, as shown in Figure 23. Note that a stamina bar indicating the FC's stamina is displayed above the head of the FC that has transitioned to a "combat state." In addition, the FC can also transition to a "combat state" if the PC approaches the FC, not just if the BC approaches the FC.

[0094] Next, Fig. 24 shows an example of a screen that appears when the player issues an attack command to the BC by pressing the X button 55. Fig. 24 shows the situation in which, based on the player's attack command, the BC is performing an attack action against the FC using the attack method "Attack 1" assigned to the X button 55. It also shows that, as a result of the attack hitting, damage corresponding to the attack method has been inflicted on the FC, and the FC's strength value has decreased.

[0095] [Charging time] In this game, each attack method has a "charge time." Once an attack method is used, it cannot be used again until the charge time has elapsed. Once the charge time has elapsed, it becomes available for use. In other words, when a certain attack method is being charged, it is in an attack standby state, and when it is not being charged, it is in an attack enabled state. When a player issues an attack command using an attack method corresponding to, for example, the A button 53, if this method is being charged, the player must wait for the charge time to elapse before pressing the A button 53. Therefore, in this game, the same attack method cannot be used consecutively. This also applies to the control of the FC's attack behavior. During charging, for example, as shown in FIG. 24, a diamond-shaped image corresponding to the attack method used above is displayed with a charge meter filling up from bottom to top.

[0096] [About the chance state] If the BC attacks the FC as described above and the FC's health value finally reaches 0, the FC is considered defeated, and the FC transitions from the "battle state" to the "chance state." This "chance state" lasts for a certain period of time. In the "chance state," the FC is unable to act (it neither moves nor attacks). The "chance state" also indicates a higher capture success rate than when the FC is not in the chance state (e.g., the default success rate). When the FC enters the "chance state," a "capture chance effect" is displayed, as shown in Figure 25, in which star marks circle around the FC. This indicates that the FC is not moving or attacking and is in a daze. In this "chance state," the PC can perform a capture action, as shown in Figure 26, to attempt a capture check with a higher success rate than in the "non-battle state." Furthermore, the capture check can be attempted with a higher success rate than in the "battle state." If the capture is successful, the capture effect described above is displayed, as shown in Figure 27, and the FC can be added to the owned characters.

[0097] Also, during the "chance state," the player can have the PC perform the capture action any number of times. Therefore, even if the first capture action during the "chance state" fails, it is possible to have the PC perform the capture action a second time and attempt to capture again.

[0098] On the other hand, if the above-mentioned certain period of time has passed without a successful capture or without any capture action being performed, the "chance state" ends. In this case, as shown in Figure 28, the above-mentioned disappearance effect is displayed, and the FC disappears from the field, and it no longer exists on the field.

[0099] It is also possible to issue an attack command to the BC to attack the FC without the FC noticing, or to attempt a capture action. For example, it is possible to approach the FC from behind and launch a preemptive attack from behind without the FC noticing. In this case, the above-mentioned battle start conditions are met, and the FC will transition from a "non-combat state" to a "combat state" (if they have remaining vitality). Also, if the FC's vitality is reduced to 0 by a single preemptive attack, they will transition directly from a "non-combat state" to a "chance state." On the other hand, if the BC approaches the FC from behind and performs a capture action from behind without the FC noticing, the success rate of the capture decision may be higher than if the FC is aware of the attack.

[0100] Furthermore, when throwing the BC ball to make the BC appear, it may be possible to specify the location of the FC in a "non-combat state" as the landing point of the BC ball. In other words, the PC will throw the BC ball at the FC. In this case, if the BC ball hits the FC, the FC will be considered to have been attacked by the BC, and the FC will transition to a "combat state." Even if the BC ball does not hit the FC, the FC will be aware of the BC's presence as a result of the BC appearing near the FC, and the FC will transition to a "combat state."

[0101] In this game, as shown in Figure 29, the above capture action can also be attempted on an FC that is in "combat mode." In this case, the capture success rate is adjusted according to the FC's remaining vitality at that time. Specifically, the success rate is adjusted so that the lower the vitality, the higher the success rate.

[0102] In this way, in the first embodiment, it is possible to attempt to directly capture an FC that is not in a combat state. Also, by challenging the FC to a battle and defeating it to create a chance state, it is possible to attempt capture in a state where the success rate of capture is increased. Furthermore, it is possible to attempt capture even during combat. In this way, the game according to the first embodiment is a game that provides opportunities for capture in a variety of situations.

[0103] [Details of Game Processing in the First Example] Next, the game processing in the first embodiment will be described in more detail with reference to Figures 30 to 48. Here, the processing relating to capture will be mainly described, and details of other game processing will not be described.

[0104] [About data usage] First, the various data used in this game processing will be described. Figure 30 is a memory map showing an example of the various data stored in the DRAM 85 of the main unit 2. The DRAM 85 of the main unit 2 stores a game program 301, PC data 302, capture item data 305, character master data 309, owned character data 310, BC management data 311, FC management data 318, operation data 319, lock-on target data 320, capture candidate data 321, lock-on flag 322, entrance effect flag 323, etc.

[0105] The game program 301 is a program for executing the game processing in the first embodiment.

[0106] PC data 302 is data related to the PC. The PC data 302 includes current position and posture data 303, PC status data 304, etc. Although not shown, the PC data 302 also includes various data required for game processing, such as data indicating the appearance of the PC (polygon data, etc.) and various motion data (animation data) performed by the PC.

[0107] Current position and posture data 303 is data indicating the current position and posture of the PC on the field. Also, PC status data 304 is data indicating the current status of the PC. Specifically, information indicating any of the above-mentioned "normal state," "ready state," and "capture action state" is set in the PC status data 304.

[0108] The capture item data 305 is data related to the capture item 202. The capture item data 305 includes movement trajectory data 306, current position data 307, etc. The movement trajectory data 306 is data that indicates the movement path of the capture item 202, calculated based on the position of the aim 203. The current position data 307 is data that indicates the current position of the capture item 202. In addition, the capture item data 305 also includes data that indicates the appearance of the capture item 202, for example.

[0109] Character master data 309 is master data defining characters (FC, BC) appearing in the game other than the PC. FIG. 31 shows an example of the configuration of character master data 309. Character master data 309 is a database consisting of a collection of records having at least the following fields: character ID 331, character appearance data 332, performance data 333, initial success rate 334, and behavior algorithm 335. Character ID 331 is an ID for identifying each character. Character appearance data 332 is data indicating the character's appearance. Performance data 333 is data defining the character's performance and initial status, such as data defining its stamina value and attack methods. Initial success rate 334 is data indicating the character's default capture success rate. Behavior algorithm 335 is data defining the character's behavior algorithm. Behavior algorithms are defined separately for when the character is an FC and when it is a BC. Although not shown in the figure, various data necessary for game processing is also included. For example, animation data showing the movements of the attack actions is also included.

[0110] Returning to FIG. 30, owned character data 310 is data indicating characters owned by the PC (i.e., captured characters). FIG. 32 shows an example of the data configuration of owned character data 310. Owned character data 310 is a database consisting of a collection of records having at least owned ID 341 that uniquely identifies owned characters and character type 342. Character type 342 is set to one of the character IDs 331 described above. Here, in the first embodiment, multiple characters of the same type (characters with the same ID as character ID 331) may appear as separate FCs. Characters of the same type may also be owned as owned characters. In this case, different owned IDs 341 are assigned to the characters of the same type, and they are managed as separate owned characters.

[0111] 30, the BC management data 311 is data for managing the above-mentioned BC. The BC management data 311 includes a BC ID 312, BC state data 313, BC position and posture data 314, BC status 315, attack target data 316, and specified attack method data 317. The initial value of the BC management data 311 is null data, which indicates that the BC does not exist (has not appeared).

[0112] The BCID 312 is set with the above-mentioned owned ID 341 corresponding to the owned character currently appearing as the BC. The BC state data 313 is data indicating the current state of the BC. The BC state includes, for example, the above-mentioned "non-combat state" and "combat state". The BC position and posture data 314 is data indicating the current position and posture of the BC. The BC status 315 is data indicating the current vitality value of the BC, etc. The attack target data 316 is data specifying the FC that the BC will attack. The specified attack method data 317 is data indicating the current attack method specified by the player's instructions. This data is used to calculate damage to the FC, etc.

[0113] Next, FC management data 318 is data for managing FCs. FIG. 33 shows an example of the data configuration of FC management data 318. FC management data 318 is a database consisting of a collection of records having at least the following items: FCID 351, FC type 352, FC appearance state 353, FC current position 354, FC current state 355, FC status 356, and FC attacking flag 357. FCID 351 is an ID for uniquely identifying each FC present on the field. FC type 352 is an ID for specifying the character type of each FC, and is set to one of the character IDs 331 described above. FC appearance state 353 is data indicating whether the FC is currently appearing (placed) on the field. For example, if the FC is appearing on the field, "YES" is set, and if not, "NO" is set. FC current position 354 is data indicating the current position of the FC on the field. The FC current state 355 is data indicating whether the FC is in the "non-combat state," "combat state," or "chance state." The FC status 356 is data indicating the current stamina value of each FC. The FC attacking flag 357 is a flag indicating whether the FC is currently performing an attacking action (playing an attack motion). In addition, although not shown in the figure, various data necessary for managing the FC in game processing are also included in the FC management data 318.

[0114] 30, operation data 319 is data indicating the details of various operations performed on the controller, including data indicating the pressed state of each button on the controller and the input state of each stick.

[0115] The lock-on target data 320 is data that identifies the FC that is the lock-on target.

[0116] The capture candidate data 321 is data that identifies the FC (hereinafter referred to as the capture candidate) that is the target for determining whether or not the capture is successful.

[0117] The lock-on flag 322 is a flag for indicating whether or not a lock-on state is in progress. When it is on, it indicates that a predetermined FC is locked on and in a lock-on state.

[0118] The entrance effect flag 323 is a flag indicating whether or not the entrance effect is being performed.

[0119] Although not shown, various data necessary for game processing is also stored in the DRAM 85. For example, data for managing the current gauge amount of the power gauge 208 may also be stored.

[0120] [Details of the processing performed by Processor 81] Next, details of the game processing in the first embodiment will be explained. Note that the flowchart shown below is merely an example of the processing steps. Therefore, the processing order of each step may be changed as long as the same results are obtained. Furthermore, the values ​​of variables and thresholds used in the determination steps are merely examples, and other values ​​may be used as necessary.

[0121] Figure 34 is a flowchart showing the details of the game processing according to Example 1. The processing loop according to steps S1 to S8 in Figure 34 is repeated a predetermined number of times per second according to the frame rate. Furthermore, it is assumed that the initialization of various data and the processing of placing various FCs and PCs on the field have been completed prior to the start of this processing.

[0122] In FIG. 34, first, in step S1, the processor 81 acquires the operation data 319.

[0123] Next, in step S2, processor 81 executes PC control processing. Fig. 35 is a flowchart showing the details of the PC control processing. In Fig. 35, first, in step S11, processor 81 determines whether or not the PC is in a capture action state based on PC state data 304. If the result of this determination is that the PC is not in a capture action state (NO in step S11), processor 81 determines in step S12 whether or not a movement operation (operation of left stick 32) has been performed based on operation data 319. If the result of this determination is that a movement operation has been performed (YES in step S12), processor 81 executes movement control processing in step S13.

[0124] Fig. 36 is a flowchart showing details of the movement control process. In Fig. 36, first, in step S31, processor 81 determines whether or not the PC is in a ready state based on PC state data 304. If the result of this determination is that the PC is not in a ready state (NO in step S31), in step S32, processor 81 controls the movement of the PC based on the operation content. On the other hand, if the PC is in a ready state (YES in step S31), in step S33, processor 81 determines whether or not a predetermined FC is currently locked on based on lock-on flag 322. If the result of this determination is that a predetermined FC is locked on (YES in step S33), in step S35, processor 81 controls the movement of the PC based on operation data 319 while orienting the PC toward the lock-on target. Thereafter, processor 81 ends the movement control process.

[0125] On the other hand, if the result of the determination in step S33 above is that the PC is not locked on (NO in step S33), in step S37, processor 81 moves the PC based on operation data 319. As an example, processor 81 may control the movement of the PC so that the PC moves strife-like as described above. Thereafter, processor 81 ends the movement control process.

[0126] Returning to FIG. 35, if the result of the determination in step S12 above is that a move operation has not been performed (NO in step S12), then in step S14, processor 81 determines whether an appearance-related operation has been performed based on operation data 319. Here, the appearance-related operation is assumed to be either the BC appearance operation or an operation to cancel the BC appearance state (return operation). If either of these operations has been performed (YES in step S14), in step S15, processor 81 executes appearance control processing.

[0127] FIG. 37 is a flowchart showing details of the appearance control process. First, in step S41, processor 81 determines, based on operation data 319, whether the operation content is a BC appearance operation or a return operation. If the result of this determination is a BC appearance operation (YES in step S41), processor 81 sets, in step S42, the owned character selected at the time of the BC appearance operation as the BC. For example, in owned character column 201, a cursor that can be moved left and right using right direction button 33 and left direction button 36 may be provided, and the owned character on which the cursor is located at the time of the BC appearance operation may be selected and set as the BC. Specifically, processor 81 sets BC management data 311 based on data related to the selected owned character. In addition, the position at which the BC will appear and the trajectory of the BC ball are also determined.

[0128] Next, in step S43, processor 81 sets entrance effect flag 323 to ON. Subsequently, in step S44, processor 81 starts an entrance effect as shown in FIGS. 19 to 21 above. In this effect, an effect in which the BC ball appears after the BC ball moves along the determined BC ball trajectory is displayed. Thereafter, processor 81 ends the entrance control process.

[0129] On the other hand, if the result of the determination in step S41 above is that the operation is a return operation (NO in step S41), then in step S45, processor 81 initializes BC management data 311. This causes the BC to be erased from the field. Furthermore, processor 81 starts a predetermined effect to erase the appearing BC from the field. Thereafter, processor 81 terminates the appearance control process.

[0130] Returning to FIG. 35, if the result of the determination in step S14 above is that an entry-related operation has not been performed (NO in step S14), then in step S16, processor 81 executes stance-related processing.

[0131] FIG. 38 is a flowchart showing details of the stance-related processing. First, in step S51, processor 81 determines whether or not the PC is in a stance state based on PC state data 304. If the result of this determination is that the PC is not in a stance state (NO in step S51), then in step S52, processor 81 determines whether or not the stance operation has been performed. That is, processor 81 determines whether or not an operation has been performed to change ZR button 61 from an OFF state to an ON state based on operation data 319. If the result of this determination is that a stance operation has been performed (YES in step S52), then in step S53, processor 81 sets PC state data 304 to "stance state." Next, in step S54, processor 81 positions aim 203 so that it is displayed at the center of the screen. Thereafter, processor 81 ends the stance-related processing.

[0132] On the other hand, if the result of the determination in step S52 above is that a ready operation has not been performed (NO in step S52), the processes in steps S53 and S54 above are skipped.

[0133] On the other hand, if the determination result in step S51 above is that the PC is in a ready state (YES in step S51), then in step S55, processor 81 determines, based on operation data 319, whether or not an operation has been performed to change ZR button 61 from an ON state to an OFF state. That is, it determines whether or not the finger has been released from ZR button 61, which has been continuously pressed. If the determination result is that the finger has been released from ZR button 61 (YES in step S55), then in step S56, processor 81 sets PC state data 304 to a "capture action state." Furthermore, processor 81 causes the PC to start an operation related to the capture action, that is, causes the PC to start the motion of throwing capture item 202 as shown in FIG. 14 above. Next, in step S57, processor 81 calculates the trajectory of capture item 202 based on the position of aim 203 at this time point, and sets the calculated trajectory in movement trajectory data 306.

[0134] Next, in step S58, processor 81 erases aim 203 from the screen, and then processor 81 ends the stance-related processing.

[0135] On the other hand, if the result of the determination in step S55 above is that the finger has not yet been released from ZR button 61 (NO in step S55), then in step S59, processor 81 determines whether or not the stance release operation has been performed. If the result of the determination is that the stance release operation has been performed (YES in step S59), then in step S60, processor 81 sets PC status data 304 to "normal status." Thereafter, the process proceeds to step S58 above.

[0136] On the other hand, if it is determined in step S59 that a stance release operation has not been performed (NO in step S59), then in step S61, processor 81 executes lock-on related processing.

[0137] Figure 39 is a flowchart showing details of the lock-on related processing. In Figure 39, first, in step S71, processor 81 determines whether or not a lock-on is currently in progress based on lock-on flag 322. If the result of this determination is that a lock-on is not in progress (NO in step S71), in step S72, processor 81 determines whether or not the lock-on operation has been performed based on operation data 319. If the result of this determination is that a lock-on operation has been performed (YES in step S72), in step S73, processor 81 sets lock-on flag 322 to ON. Next, in step S74, processor 81 identifies a lock-on target and sets lock-on target data 320. For example, processor 81 sets the FC closest to the position of aim 203 at this time as the lock-on target.

[0138] Next, in step S75, processor 81 sets the position of aim 203 to a position where it is displayed overlapping with the FC to be locked on. Then, processor 81 sets the parameters of the virtual camera so that aim 203 and the locked-on FC are always displayed in the center of the screen. Thereafter, processor 81 ends the lock-on related processing.

[0139] On the other hand, if a lock-on operation has not been performed (NO in step S72), the processes in steps S73 to S75 are skipped.

[0140] On the other hand, if the result of the determination in step S71 above is that the object is locked on (YES in step S71), then in step S76, processor 81 determines whether or not the lock-off operation has been performed. If the result of the determination is that the object has been locked on (YES in step S76), then in step S77, processor 81 sets lock-on flag 322 to OFF. Thereafter, processor 81 ends the lock-on related processing.

[0141] On the other hand, if the result of the determination in step S76 above is that a lock-off operation has not also been performed (NO in step S76), then in step S78 processor 81 determines whether an operation to switch the lock-on target (in this example, an operation of right stick 52) has been performed. If the result of this determination is that the operation has been performed (YES in step S78), then in step S79 processor 81 changes the lock-on target based on the operation content and resets the content of lock-on target data 320. Thereafter, processing proceeds to step S75 above.

[0142] On the other hand, if the operation to switch the lock-on target has not been performed, the process of step S79 is skipped and the lock-on related process ends.

[0143] Returning to FIG. 38, once the lock-on related processing is completed, the stance related processing ends.

[0144] Returning to FIG. 35, next, in step S17, processor 81 determines whether or not an attack instruction operation has been performed on a BC. That is, it is determined whether or not any of the ABXY buttons has been pressed while a BC is present. If the result of this determination is that an attack instruction operation has been performed (YES in step S17), in step S18, processor 81 sets designated attack method data 317 based on the content of the operation. At this time, the player may be able to designate an FC to be the attack target. In this case, a process of setting the designated FC as attack target data 316 is also performed.

[0145] On the other hand, if an attack instruction operation has not been performed (NO in step S17), the process of step S18 is skipped.

[0146] Next, in step S19, processor 81 determines whether or not an operation to change the orientation of the virtual camera has been performed, based on operation data 319. That is, processor 81 determines whether or not right stick 52 has been operated while the PC is in the normal state. If such an operation has been performed (YES in step S19), in step S20, processor 81 changes the parameters of the virtual camera (orientation of the virtual camera) based on the operation content. On the other hand, if an operation to change the orientation of the virtual camera has not been performed (NO in step S19), the processing of step S20 is skipped. Thereafter, processor 81 ends the PC control processing.

[0147] Next, a description will be given of the process when the result of the determination in step S11 above is that the PC is in a capture action state (YES in step S11). In this case, in step S21, processor 81 executes a capture action process.

[0148] Figure 40 is a flowchart showing the details of the capture action process. In Figure 40, first, in step S81, processor 81 moves capture item 202 based on movement trajectory data 306. Accordingly, current position data 307 is also updated. At this time, if the motion of the PC related to the capture action has not ended, the motion is continued.

[0149] Next, in step S82, processor 81 determines whether or not capture item 202 has hit FC. The hit determination may be made if capture item 202 and FC collide. In other embodiments, even if there is no precise collision, a hit may be determined when capture item 202 and FC are positioned close to each other (even if there is some deviation).

[0150] As a result of the above determination, if capture item 202 hits an FC (YES in step S82), processor 81 sets the hit FC as a capture candidate in capture candidate data 321 in step S83.

[0151] Next, in step S84, processor 81 executes capture determination processing for the capture candidate. Figure 41 is a flowchart showing the details of the capture determination processing. In Figure 41, first, in step S91, processor 81 references character master data 309 and obtains initial success rate 334 corresponding to the capture candidate.

[0152] Next, in step S92, processor 81 determines whether the capture candidate is currently in a "chance state" based on FC management data 318. If the result of this determination is that the capture candidate is in a "chance state" (YES in step S92), in step S93, processor 81 adjusts the capture success rate so that it is higher than initial success rate 334. Thereafter, processing proceeds to step S96, which will be described later.

[0153] On the other hand, if the target is not in a "chance state" (NO in step S92), then in step S94, processor 81 determines whether the target is in a "combat state." If the result of this determination is that the target is in a "combat state" (YES in step S94), then in step S95, processor 81 adjusts the capture success rate according to the target's current state, such as the target's remaining vitality value and whether or not it has been given an abnormal status. For example, the lower the vitality value, the higher the capture success rate is adjusted to be higher than initial success rate 334. Then, processing proceeds to step S96, which will be described later.

[0154] On the other hand, if it is not in a "combat state" (NO in step S94), the process of step S95 is skipped. In this case, the capture determination is made in a "non-combat state", and the determination is made with the initial success rate unchanged.

[0155] Next, in step S96, processor 81 determines whether or not the capture has been successful, using the capture success rate adjusted in steps S92 to S95 above, or the capture success rate left unchanged as initial success rate 334 above.

[0156] Next, in step S97, processor 81 determines whether the capture was successful or not based on the result of the capture success / failure. If the result of this determination is that the capture was successful (YES in step S97), in step S98, processor 81 erases the capture target from the field. Specifically, processor 81 sets "NO" to FC appearance state 353 of the capture candidate in FC management data 318.

[0157] Next, in step S99, processor 81 performs settings for displaying the disappearance effects and capture effects as shown in FIGS.

[0158] Next, in step S100, processor 81 adds the capture candidate to owned character data 310. Thereafter, processor 81 ends the capture determination process.

[0159] On the other hand, if the result of the determination in step S97 above is that the capture has failed (NO in step S97), the processes in steps S98 to S100 above are skipped and the capture determination process ends.

[0160] 40, next, in step S85, processor 81 sets "normal state" to PC state data 304. Thereafter, processor 81 ends the capture action process.

[0161] On the other hand, if the result of the determination in step S82 above is that the capture item has not hit the FC (NO in step S82), then in step S86 processor 81 determines whether or not the movement of capture item 202 has ended. That is, it is determined whether or not capture item 202 has landed on the ground without hitting the FC. If the result of this determination is that the movement has ended (YES in step S86), processing proceeds to step S85 above. As a result, the result of the capture action is determined to be that the capture item has ended without hitting the FC. On the other hand, if the movement has not yet ended (NO in step S86), the capture action processing ends.

[0162] Returning to FIG. 35, when the capture action process is completed, processor 81 ends the PC control process.

[0163] Returning to Fig. 34, next, in step S3, the processor 81 executes the BC control process. Figs. 42 and 43 are flowcharts showing the details of the BC control process. First, in step S111, the processor 81 determines whether or not there is a currently appearing BC, based on the BC management data 311. If the result of the determination is that there is no BC (NO in step S111), the processor 81 ends the BC control process.

[0164] On the other hand, if there is a BC currently appearing (YES in step S111), in step S112, processor 81 determines whether or not the entrance performance is currently in progress based on entrance performance flag 323. If the entrance performance is in progress (YES in step S112), in step S113, processor 81 continues the entrance performance. Next, in step S114, processor 81 determines whether or not the entrance performance has ended. If it has ended (YES in step S114), in step S115, processor 81 sets entrance performance flag 323 to OFF. Then, the process proceeds to step S116.

[0165] On the other hand, if the result of the determination in step S114 is that the entrance performance has not yet ended (NO in step S114), processor 81 ends the BC control process.

[0166] On the other hand, if the result of the determination in step S112 above is that the appearance performance is not in progress (NO in step S112), in step S116, processor 81 advances the charging of any attack method currently being charged among the attack methods possessed by the BC.

[0167] Next, in step S117, processor 81 determines whether an attack from any FC hits BC. If the result of this determination is a hit (YES in step S117), processor 81 calculates a damage value based on the attack method that hit. Then, processor 81 updates BC status 315 so that the vitality value is reduced by the amount of the damage value.

[0168] On the other hand, if the attack from FC does not hit (NO in step S117), the processing of step S118 is skipped.

[0169] Next, in step S119, processor 81 determines whether the BC's vitality value is 0, based on BC status 315. If the result of this determination is 0 (YES in step S119), processor 81 executes processing to erase the appearing BC from the field (returning it to the state of an owned character) in step S120. Specifically, processor 81 starts a disappearance effect in which the BC disappears from the field, and initializes BC management data 311. After that, processor 81 ends the BC control processing.

[0170] On the other hand, if the vitality value is not 0 (NO in step S119), then in step S121 of FIG. 43, processor 81 determines whether or not the BC is currently performing an attacking action. That is, it is determined whether or not an attack motion corresponding to a predetermined attack method is being played. If the result of this determination is that the BC is performing an attacking action (YES in step S121), in step S122, processor 81 causes the BC to continue the attacking action. Thereafter, processor 81 ends the BC control process.

[0171] On the other hand, if the PC is not in an attacking operation (NO in step S122), then in step S123, processor 81 determines whether an attack instruction has been issued based on operation data 319. If the result of this determination is that an attack instruction has not been issued (NO in step S123), in step S124, processor 81 controls the behavior of the BC based on behavior algorithm 335. For example, control is performed so that the BC moves following the PC, or processing is performed such that the nearest FC is set as attack target data 316. Thereafter, the BC control processing ends.

[0172] On the other hand, if an attack instruction has been issued (YES in step S123), in step S125, processor 81 determines whether the designated attack method is currently charging. If it is currently charging (YES in step S125), processor 81 terminates the BC control process. That is, even if the button corresponding to the currently charging attack method is pressed, the BC will not do anything. On the other hand, if it is not currently charging (NO in step S125), in step S126, processor 81 sets information indicating the designated attack method in designated attack method data 317, and causes the BC to begin an attack action corresponding to the designated attack method. At this time, the charge meter related to that attack method is emptied and begins charging. Thereafter, processor 81 terminates the BC control process.

[0173] Returning to Fig. 34, after the BC control process, in step S4, processor 81 executes FC control process. Fig. 44 is a flowchart showing the details of the FC control process. First, in step S131, processor 81 selects one FC to be the target of the process described below from among the FCs for which FC appearance status 353 is "YES" in FC management data 318. Hereinafter, this FC will be referred to as the FC to be processed.

[0174] Next, in step S132, processor 81 determines whether the processing target FC is in a non-combat state, based on FC current state 355. If the result of this determination is that the FC is in a non-combat state (YES in step S132), processor 81 executes non-combat state processing in step S133. Thereafter, the process proceeds to step S137, which will be described later.

[0175] 45 is a flowchart showing the details of the non-battle state processing. First, in step S141, processor 81 controls the movement of the processing target FC based on behavior algorithm 335.

[0176] Next, in step S142, processor 81 determines whether the attack from the BC has hit the processing target FC. If the result of this determination is that the attack has not hit (NO in step S142), processor 81 ends non-combat state processing. On the other hand, if the attack has hit (YES in step S142), in step S143, processor 81 calculates a damage value according to the attack method specified in specified attack method data 317. Then, processor 81 updates FC status 356 so that the vitality value is reduced by the amount of the damage value.

[0177] Next, in step S144, processor 81 determines whether the vitality value of the processing target FC has become 0. If the result of this determination is that the vitality value has become 0 (YES in step S144), in step S146, processor 81 sets FC current state 355 of the processing target FC to "chance state." Next, in step S147, processor 81 starts a capture chance presentation as shown in FIG. 25 above. Thereafter, processor 81 ends non-combat state processing.

[0178] On the other hand, if it is not 0 (NO in step S144), in step S145, processor 81 sets FC current state 355 of the processing target FC to “combat state.” After that, processor 81 ends the non-combat state processing.

[0179] 44, if the result of the determination in step S132 above is not the "non-combat state" (NO in step S132), then in step S134, processor 81 determines whether the processing target FC is in the "chance state". If the result of this determination is not the "chance state" (NO in step S134), processor 81 executes combat state processing in step S135. On the other hand, if the processing target FC is in the "chance state" (YES in step S134), processor 81 executes chance state processing in step S136.

[0180] 46 and 47 are flowcharts showing the details of the above-mentioned battle state processing. In Fig. 46, first, in step S151, processor 81 advances the charging of any attack method currently being charged among the attack methods possessed by FC.

[0181] Next, in step S152, processor 81 determines whether the attack from BC has hit the processing target FC. If the result of this determination is that the attack has hit (YES in step S152), in step S153, processor 81 calculates a damage value according to the attack method specified in specified attack method data 317. Then, processor 81 updates FC status 356 so that the vitality value is reduced by the amount of the damage value. On the other hand, if the attack has not hit (NO in step S152), processor 81 skips the processing of step S153.

[0182] Next, in step S154, processor 81 determines whether the vitality value of the processing target FC has become 0. If the result of this determination is that the vitality value has become 0 (YES in step S154), in step S155, processor 81 sets FC current state 355 of the processing target FC to "chance state." Next, in step S156, processor 81 starts a capture chance presentation as shown in FIG. 25 above. Thereafter, processor 81 ends the battle state processing.

[0183] On the other hand, if the result of the determination in step S154 above is that the vitality value is not 0 (NO in step S154), then in step S157, processor 81 determines whether the FC to be processed is in an attacking motion based on FC attacking flag 357. If the result of this determination is that the FC is in an attacking motion (YES in step S157), then in step S159, processor 81 causes the FC to be processed to continue the current attacking motion. Furthermore, if the attacking motion ends as a result, processor 81 sets FC attacking flag 357 to OFF. Thereafter, processor 81 ends the battle state processing.

[0184] On the other hand, if an attacking action is not being performed (NO in step S157), processor 81 determines the attacking method based on behavior algorithm 335 described above in step S158.

[0185] Next, in step S160 of Figure 47, processor 81 determines whether or not the determined attack method is currently charging. If it is currently charging (YES in step S160), in step S161, processor 81 causes the processing target FC to wait until charging is complete. On the other hand, if it is not currently charging (NO in step S160), in step S162, processor 81 causes the processing target FC to begin an attack action corresponding to the determined attack method. At this time, the charge meter for that attack method is emptied and charging begins.

[0186] Next, in step S163, processor 81 sets FC attacking flag 357 of the processing target FC to ON. After that, processor 81 ends the battle state process.

[0187] Next, the chance state processing will be described. Figure 48 is a flowchart showing the details of the chance state processing. In Figure 48, first, in step S171, processor 81 determines whether or not a certain period of time has passed since the chance state was entered. If the result of the determination is that the certain period has not passed (NO in step S171), in step S172, processor 81 continues displaying the capture chance effect. Thereafter, processor 81 ends the chance state processing.

[0188] On the other hand, if a certain period of time has passed since the chance state was entered (YES in step S171), in step S173, processor 81 sets “NO” to the appearance state of the FC to be processed in FC management data 318. This means that the FC to be processed is set to disappear from the field.

[0189] Next, in step S174, processor 81 starts the disappearance effect for the processing target FC. After that, processor 81 ends the chance state process.

[0190] 44, once the processing of any one of steps S133, S135, or S136 is completed, then in step S137, processor 81 determines whether or not the above processing has been performed for all FCs for which FC appearance status 353 is "YES" in FC management data 318. If there are still unprocessed FCs remaining (NO in step S137), the process returns to step S131 and is repeated. If the above processing has been performed for all FCs (YES in step S137), processor 81 ends the FC control processing.

[0191] 34, next, in step S5, processor 81 executes various game control processes other than those described above. For example, various collision determinations other than those described above are performed, and processes based on the results of the collision determinations are executed. In addition, other processes such as adding slip damage, such as damage due to poison, to BC and FC, and operation control processes for various gimmicks installed on the field are also executed as appropriate.

[0192] Next, in step S6, the processor 81 executes a virtual camera control process, in which the virtual camera is controlled based on the virtual camera parameters set by the above process.

[0193] Next, in step S7, processor 81 generates and outputs a game image that reflects the above processing content.

[0194] Next, in step S8, processor 81 determines whether an instruction to end the game has been given, and if not (NO in step S8), processor 81 returns to step S1 and repeats the process. On the other hand, if an instruction to end the game has been given (YES in step S8), processor 81 ends the game processing.

[0195] In this way, in the first embodiment, even if you defeat an FC as a result of fighting it, you are given the opportunity to capture that FC. You are also given the opportunity to capture an FC even when the FC is not in combat, and even when the FC and BC are in combat. This makes it possible to capture an FC in a variety of situations, increasing the interest of the game.

[0196] (Second Example) Next, a second example will be described, which is another example of the game processing described above. In the second example, the same processing as the above-described processing is basically performed, but the second example will be described in more detail and with more specific content than the above-described processing.

[0197] First, the game system 1 has the same configuration as in the first embodiment, so a description thereof will be omitted.

[0198] Next, an outline of the game processing in Example 2 will be explained. Basically, the same game as in Example 1 is assumed, but the following points will be supplemented or explained in more detail.

[0199] (About PC operation) First, we will explain how to control the PC. In addition to the actions described in the first embodiment, the PC may also be capable of "dash" and "dodge" actions. For example, as a "dash" action, pressing the B button 54 and using the left stick 32 to input a direction (B + left stick input) moves the PC in the input direction at a faster-than-normal speed. Pressing the Y button 56 also allows the PC to perform an "dodge" maneuver. An "dodge" maneuver is a predefined motion (animation), such as a forward roll toward the front of the PC's current position. In this game, the FC may attack the PC if the BC is not present. Therefore, collision detection is performed between the FC's attack and the PC. If the FC's attack hits the PC, the PC may also receive damage. For example, if the blast from the FC's attack hits the PC, the PC may receive damage. However, collision detection is not performed against the FC's attack during the "dodge" maneuver. In other words, the FC's attack can be avoided. Therefore, during a battle between the BC and FC, the PC can attempt to capture the enemy while considering their positioning to avoid being caught in the FC's attack. Also, by enabling the above-mentioned evasive actions, it is possible to provide a way to avoid the FC's attacks while waiting for an opportunity to capture the enemy.

[0200] (Regarding lock-on control) As another control example related to the lock-on, the second embodiment performs the following control. In the second embodiment, while the ZL button 39 is pressed, the PC transitions to a state called "lock mode" (lock mode is turned on). Then, when the "lock-on conditions" are met in this lock mode, a control is performed to lock onto a specific FC. Specifically, the lock-on condition is that the positional relationship between the position of the virtual camera (or the position of the PC) tracking the PC and the FC satisfies a specific condition. More specifically, in virtual space, an FC is located within a specific distance from the virtual camera and within a specific range (e.g., a pyramidal range) that is narrower than the field of view and includes the line of sight from the virtual camera position, and a raycast from the virtual camera position to the FC within the specific range reaches the FC without being blocked by obstacles, etc. When there are multiple FCs that satisfy the "lock-on conditions," the nearest FC is set as the lock-on target. Furthermore, after locking on to a specific FC, if the distance from that FC increases, or if the state no longer meets the lock-on conditions, the lock-on will be released. Furthermore, if the pressed ZL button 39 is released, the lock mode will be released (lock mode will be turned off). Even if a specific FC was locked on at this time, the lock-on state will also be released when the lock mode is released.

[0201] (About aiming) In addition, in the second embodiment, a control example will be explained in which, during lock-on, the reticle is displayed superimposed on the lock-on target, and when not locked on, the reticle is always displayed in the center of the screen (regardless of whether or not a capture item is being held).

[0202] (Menu screen, map screen) Furthermore, in the above-described game, a menu screen and a map screen may be displayed in response to a predetermined operation. The menu screen displays, for example, a UI (user interface) that allows instructions to use owned items. The items are, for example, items that can be used against BCs and provide recovery effects, buff effects, etc. The map screen displays a map image of the virtual world and the current location of the PC. Note that in this game, progress of the game is paused while the menu screen or map screen is displayed. In the second embodiment, the X button 55 is assigned to display the menu screen, and the + button 57 is assigned to display the map screen. The flowcharts described below will explain processing including control of operations to display the menu screen and map screen.

[0203] (Regarding operations related to the owned character column 201) Next, a supplementary explanation will be given regarding operations related to the owned character column 201. That is, the above-mentioned "BC appearance operation" will be explained in more detail. In the second embodiment, as a specific example of the "BC appearance operation", the following operations can be performed using the right direction button 33, the down direction button 34, the up direction button 35, and the left direction button 36.

[0204] First, FIG. 49 shows an enlarged view of the owned character column 201 in FIG. 10. FIG. 49 shows that three BC frames and a selection cursor 501 are displayed. The selection cursor 501 indicates the currently selected BC. When the up button 35 is pressed in the state shown in FIG. 49, a control is performed to make the BC in the leftmost BC frame selected by the selection cursor 501 appear. In other words, the up button 35 is assigned to the operation of instructing the BC to appear. When a BC appears, as shown in FIG. 50, an appearance cursor 502 is displayed above the BC frame. In other words, the appearance cursor 502 indicates the currently appearing BC. Furthermore, by pressing the down button 34, the currently appearing BC can be returned to a non-appearing state (to a state where it is simply a owned character). When the BC returns, the appearance cursor 502 also disappears.

[0205] Also, the selection cursor 501 can be moved to an adjacent BC frame using the right direction button 33 and the left direction button 36. For example, Fig. 51 shows an example in which the selection cursor 501 has been moved to the right.

[0206] Furthermore, when a predetermined BC has already appeared, if another BC is selected and the up button 35 is pressed, the other BC will appear, replacing the currently appearing BC. In other words, the currently appearing BC will automatically return, and the appearance of the other BC will be displayed.

[0207] (Additional information about operation) Next, we will provide additional information regarding the operations in the second embodiment, taking the above into consideration. Figure 52 shows a list of operations assumed in the second embodiment. The ZL button 39 is used to turn the lock mode on and off as described above. The ZR button 61 is used to control the "ready state" and capture action, as in the first embodiment. The left stick 32 is used to move the PC, and the right button 33, down button 34, up button 35, and left button 36 are used to control the appearance of the BC as described above. The functions executed by the ABXY buttons, + button 57, and right stick 52 can change depending on whether the lock mode is on or off, and further depending on whether the BC is appearing or not.

[0208] First, we will explain the ABXY buttons and + button 57. Specifically, when the ZL button 39 is not pressed (lock mode off), regardless of whether BC appears or not, the A button 53 is used as a confirmation command, the B button 54 as a dash command, the Y button 56 as an evasion command, the X button 55 as a transition command to the menu screen, and the + button 57 as a transition command to the map screen.

[0209] Next, when the ZL button 39 is on (lock mode is on), the executed function differs depending on whether or not a specific FC is locked on. When an FC is not locked on, the A button 53 is used as a confirm command, the B button 54 as a dash command, and the Y button as an evasion command. The X button 55 and + button 57 are disabled. On the other hand, when an FC is locked on, the ABXY buttons are used to cause the BC to launch an attack on the locked-on FC using the attack method assigned to each button, as explained in the first embodiment. Note that the specific attack method assigned to each button may be arbitrarily set by the user on a specific setting screen, etc. The + button 57 is also used to control switching to "strong attack mode."

[0210] Here, a supplementary explanation will be given regarding the "strong attack mode." In the second embodiment, the "strong attack mode" is switched on and off each time the + button 57 is pressed. When the strong attack mode is on, the BC attack content issued by the ABXY buttons is strengthened compared to when the strong attack mode is off. For example, the attack power increases, the recovery amount increases, the duration of the weakening effect on the FC is extended, etc. However, in order to turn on the strong attack mode, a predetermined amount of the power gauge 208 shown in FIG. 21 above is required to be consumed. For example, in the example of FIG. 21, the power gauge 208 is composed of five gauges, and the strong attack mode may be turned on by consuming one of these gauges.

[0211] Next, we will explain the operation of the right stick 52. Basically, the right stick 52 can be used to control the virtual camera by inputting directions. However, if the lock mode is on and a specific FC is locked on, the target to be locked on can be changed by inputting directions, as explained in the first embodiment above.

[0212] Furthermore, by pressing the right stick 52, under certain conditions, the BC can be transitioned to an "enhanced state." The enhanced state is a state in which the BC's performance (various parameters) is temporarily improved. In the second embodiment, when the power gauge 208 shown in FIG. 21 is fully charged and a BC has appeared, pressing the right stick 52 can transition the appearing BC to the enhanced state. During the enhanced state, the power gauge 208 decreases over time, and when the power gauge is depleted, the enhanced state is canceled and the BC returns to its normal state. In other words, the BC can be transitioned to the enhanced state in exchange for consuming all of the power gauge that has been fully charged.

[0213] Regarding the various buttons on the controller, in terms of key assignment, the left controller 3 is assigned PC movement input (left stick 32), lock mode on / off input (ZL button 39), and BC appearance control input (right button 33, down button 34, up button 35, and left button 36). On the other hand, the right controller 4 is assigned PC action control input (B button 54, Y button 56), attack instructions to the BC (ABXY buttons), use of capture items (ZR button 61), input to switch lock targets (right stick 52), operation input related to BC strengthening (+ button 57, pressing the right stick), menu and map display operation input (X button 55, + button 57), and virtual camera control input (right stick 52). Therefore, it is possible to control PC movement and lock-on with the left hand, while throwing capture items and issuing attack instructions to the BC with the right hand. In other words, the left hand controls the PC's positioning and whether or not to enable lock-on, while the right hand controls the timing of various actions for the PC and BC. By allocating controls between the left and right hands in this way, it is possible to provide operations that allow different actions, such as "attack" and "capture," to be performed simultaneously in parallel, and it is also possible to efficiently control the PC's positioning and the timing of various actions using a limited number of buttons.

[0214] Next, various data used in the processing of the second embodiment will be described. Fig. 53 shows a memory map illustrating an example of various data stored in the DRAM 85 of the main unit 2 in the second embodiment. Note that data similar to those in the first embodiment are given the same reference numerals, and detailed descriptions will be omitted. Specifically, in Fig. 53, data other than selection cursor data 371, lock mode flag 372, capture flag 373, enhancement flag 374, menu flag 375, and map flag 376 is similar to that in the first embodiment, and detailed descriptions will be omitted.

[0215] In FIG. 53, selection cursor data 371 is data for specifying the position of selection cursor 501 in owned character column 201 shown in FIG. 49 and the like, that is, the currently selected owned character.

[0216] The lock mode flag 372 is a flag for determining whether or not the ZL button 39 is pressed as described above.

[0217] The capture flag 373 is a flag that indicates whether the period is from when the capture item is thrown until the capture determination is completed, or from when the capture item is thrown until the movement of the capture item ends without hitting the FC. The initial value is off, and it is set to on during the above periods.

[0218] The strengthening flag 374 is a flag for indicating whether the currently appearing BC is in a strengthened state or not. The initial value is off, and when in a strengthened state, it is turned on.

[0219] The menu flag 375 is a flag for determining whether or not to display a menu screen. The initial value is off, and when it is on, it indicates that the menu screen is to be displayed.

[0220] The map flag 376 is a flag for determining whether or not a map screen is to be displayed. The initial value is off, and when it is on, it indicates that the map screen is to be displayed.

[0221] Here, we will provide additional information regarding the PC status data 304 in the second embodiment. In the second embodiment, an example will be described in which the PC performs an avoidance operation as described above. Therefore, data indicating that the PC is in an avoidance state may also be set in the PC status data.

[0222] Next, details of the processing according to the second embodiment will be explained using the flowcharts shown in Figures 54 to 73. In the flowcharts, the same processes as those in the first embodiment will be given the same reference numerals, and detailed explanations will be omitted.

[0223] Figure 54 is a flowchart showing details of game processing according to the second example. In Figure 54, first, in step S1, processor 81 acquires operation data 319. Next, in step S201, processor 81 determines whether menu flag 375 is on. If the result of this determination is that menu flag 375 is off (NO in step S201), processor 81 determines whether map flag 376 is on (NO in step S202). If map flag 376 is off (NO in step S202), processor 81 executes PC control processing in step S203.

[0224] Fig. 55 is a flowchart showing details of the PC control process according to the second embodiment. In Fig. 55, first, in step S211, the processor 81 determines, based on the PC state data 304, whether or not the PC state is in the "avoidance state," in which the above-mentioned avoidance operation is in progress. If the result of this determination is the avoidance state (YES in step S211), the processor 81 continues control of the avoidance operation in step S217. In the following step S218, the processor 81 determines whether or not the avoidance operation has ended, and if it has ended (YES in step S218), the processor 81 sets the PC state to the "normal state" in step S219. On the other hand, if it has not yet ended (NO in step S218), the process of step S219 is skipped. Thereafter, the PC control process ends.

[0225] On the other hand, if the result of the determination in step S211 above is that the vehicle is not in the avoidance state (NO in step S211), then in step S212, processor 81 executes movement-related processing.

[0226] 56 is a flowchart showing details of the movement-related processing. First, in step S231, processor 81 determines whether or not a lock-on state in which a predetermined FC is locked on is in progress, based on lock-on flag 322. If the FC is not in a lock-on state (NO in step S231), processor 81 executes normal movement processing in step S232. On the other hand, if the FC is in a lock-on state (YES in step S231), processor 81 executes locked-on movement processing in step S233.

[0227] FIG. 57 is a flowchart showing details of the normal movement processing. In FIG. 57, first, in step S241, processor 81 determines whether or not a directional input is being made using left stick 32. If the result of this determination is that no directional input is being made (NO in step S241), the normal movement processing ends. On the other hand, if the B button 54 is being made (YES in step S241), processor 81 determines whether or not B button 54 is on (pressed) in step S242. If the result of this determination is that it is not on (NO in step S242), processor 81 controls the movement of the PC at the normal movement speed based on the input direction of left stick 32 in step S243. On the other hand, if it is on (YES in step S242), processor 81 controls the movement of the PC at the normal movement speed based on the input direction of left stick 32 in a state where the movement speed of the PC is increased in step S244. At this time, the motion of the PC may be controlled using a motion dedicated to dashing. Thereafter, the normal movement processing ends.

[0228] In this embodiment, the dash operation is explained using the example of the operation of "B button + left stick," but in other embodiments, the dash action may be controlled to be performed by simply pressing the B button 54 without any directional input from the left stick 32. For example, the dash action may be performed in the direction directly ahead of the PC at that time.

[0229] Next, the details of the movement while locked process will be described. FIG. 58 is a flowchart showing the details of the movement while locked process. In FIG. 58, first, in step S251, processor 81 determines whether or not a directional input is being made with left stick 32. If the result of this determination is that no directional input is being made (NO in step S251), the movement while locked process ends. On the other hand, if a directional input is being made (YES in step S251), processor 81 determines whether or not a BC is appearing in step S252. If the result of this determination is that the BC has not appeared in step S252 (NO in step S252), processor 81 determines whether or not B button 54 is pressed in step S253. If the result of this determination is that the B button is not pressed in step S253 (NO in step S253), processor 81 controls the movement of the PC based on the input direction of left stick 32 while directing the PC toward the lock-on target in step S254. On the other hand, if it is on (YES in step S253), in step S255, processor 81 increases the movement speed of the PC and controls movement based on the input direction of left stick 32 while directing the PC toward the lock-on target.

[0230] On the other hand, if the result of the determination in step S252 above is that a BC has appeared (YES in step S252), the determination in step S253 above is skipped and the process proceeds to step S254. This is because, as described above, when a BC has appeared in the locked-on state, the ABXY buttons are used to issue an attack command to the BC, so the input determination for the B button 54 is not performed here.

[0231] This concludes the description of the movement-related processing.

[0232] Returning to FIG. 55, next, in step S213, the processor 81 executes lock-related processing. FIG. 59 is a flowchart showing the details of the lock-related processing. In FIG. 59, first, in step S261, the processor 81 determines whether or not the current mode is the lock mode based on the lock mode flag 372. If the result of this determination is that the current mode is not the lock mode (NO in step S261), the processor 81 determines in step S262 whether or not the ZL button 39 has been turned on. That is, the processor 81 determines whether or not the ZL button 39 has been turned on from an off state. If the result of this determination is that the ZL button 39 is on (YES in step S262), the processor 81 sets the lock mode flag 372 to on in step S263. On the other hand, if the current mode is off (NO in step S262), the processing of step S262 is skipped.

[0233] On the other hand, if the result of the determination in step S261 above is that the lock mode is in effect (YES in step S261), then in step S264, the processor 81 executes lock mode processing. FIG. 60 is a flowchart showing the details of the lock mode processing. In FIG. 60, first, in step S271, the processor 81 determines whether or not the ZL button 39 is off. That is, it is determined whether or not an operation to release the lock mode has been performed. If the result of the determination is that the ZL button 39 is not off (NO in step S271), then in step S272, the processor 81 determines whether or not the current state is a lock-on state based on the lock-on flag 322. If the result of the determination is that the current state is not a lock-on state (NO in step S272), then in step S273, the processor 81 determines whether or not an FC exists that satisfies the "lock-on condition" as described above. If the result of the determination is that an FC exists that satisfies the "lock-on condition" (YES in step S273), then in step S274, the processor 81 sets the lock-on flag 322 to "on." Next, in step S275, processor 81 sets lock-on target data 320 so that the FC that satisfies the "lock-on condition" is the lock-on target. If there are multiple FCs that satisfy the "lock-on condition," the nearest FC is set as the lock-on target, as described above. Thereafter, lock mode processing ends.

[0234] On the other hand, if there is no FC that satisfies the "lock-on condition" (NO in step S273), the processes of steps S274 and S275 are skipped. In this case, the state of being in lock mode but not locked on will continue.

[0235] On the other hand, if the result of the determination in step S272 above is the locked-on state (YES in step S272), then in step S276, processor 81 determines whether or not the "lock-on condition" for the current lock-on target is no longer satisfied. For example, it is determined whether or not the distance between the current lock-on target and the virtual camera has changed to or exceeded a predetermined distance. If the result of this determination is that the "lock-on condition" is no longer satisfied (YES in step S276), then in step S278, processor 81 clears lock-on target data 320, thereby canceling the setting of the lock-on target. In the following step S279, processor 81 turns off lock-on flag 322. Thereafter, the lock mode processing ends.

[0236] If the answer to step S276 is YES, and there is another FC that meets the lock-on conditions at this point, the lock-on target may be switched to that other FC. In this case, the processes of steps S278 and S279 may not be performed.

[0237] On the other hand, if the result of the determination in step S276 above is that the "lock-on condition" is maintained for the current lock-on target (NO in step S276), the processes in steps S278 and S279 above are skipped and the lock-on state is maintained.

[0238] On the other hand, if the result of the determination in step S271 above is that ZL button 39 is off (YES in step S271), processor 81 sets lock mode flag 372 to off in step S277. Thereafter, the process proceeds to steps S278 and S279 described above, where the lock-on state is also released. Thereafter, the lock mode process ends.

[0239] This concludes the description of the lock-related processing.

[0240] Returning to FIG. 55, next, in step S214, processor 81 executes capture-related processing. FIG. 61 is a flowchart showing the details of this capture-related processing. Note that in the flow of FIG. 61, most of the processing is similar to the "stance-related processing" described in the first embodiment using FIG. 38 above. Therefore, here, the same processing as the "stance-related processing" is given the same reference numerals, and detailed description will be omitted, and the following description will focus on the differences from the "stance-related processing."

[0241] In FIG. 61, if the determination in step S55 is YES (when an operation to throw a capture item is performed), in step S291, processor 81 sets capture flag 373 to ON and changes the PC state from the "ready state" to the "normal state."

[0242] Next, in step S292, processor 81 calculates the movement trajectory of the capture item. At this time, if locked-on, the movement trajectory is calculated with the lock-on target as the launch direction. On the other hand, if not locked-on, the movement trajectory is calculated with the direction of the aim displayed in the center of the screen as the launch direction. Note that a movable distance may be set for the capture item, and the movement trajectory may be calculated based on a trajectory that causes the item to fall depending on the distance. In this case, for example, depending on the distance to the lock-on target, the capture item may not reach the lock-on target.

[0243] Next, in step S293, processor 81 causes the PC to start the action of throwing the capture item, and causes the capture item to start moving based on the calculated movement trajectory. Thereafter, the process proceeds to step S294.

[0244] Next, in step S294, processor 81 determines whether capture flag 373 is on. If it is on (YES in step S294), in step S295, processor 81 executes second capture action processing. Figure 62 is a diagram showing details of the capture action processing according to the second embodiment. Here, in the flowchart of Figure 62, except for the processing of step S301, the same processing as the capture action processing of the first embodiment described above using Figure 40 is executed. Therefore, only the processing of step S301 will be described here, and descriptions of the other processing will be omitted.

[0245] 62, or if YES in step S86, in step S301, processor 81 sets capture flag 373 to OFF. That is, capture flag 373 is set to OFF when the capture item hits an FC or when the movement ends without hitting the FC.

[0246] 61, once the capture action process is completed, the capture-related process ends. On the other hand, if the result of the determination in step S294 is that the capture flag is not on (NO in step S294), the process in step S295 is skipped and the capture-related process ends.

[0247] This concludes the description of the capture-related processing.

[0248] Returning to FIG. 55, next, in step S215, processor 81 executes instruction operation-related processing. This processing mainly involves control of operations to A button 53, B button 54, X button 55, Y button 56, and + button 57, and control of operations related to owned character column 201. FIG. 63 is a flowchart showing details of the instruction operation-related processing. First, in step S311, processor 81 determines whether the current state is a lock-on state and a BC has appeared. If the result of this determination is that the current state is not a lock-on state and a BC has not appeared (NO in step S311), processor 81 executes normal command processing in step S312. On the other hand, if the current state is a lock-on state and a BC has appeared (YES in step S311), processor 81 executes attack command processing in step S313.

[0249] FIG. 64 is a flowchart showing the details of the normal command processing. This processing is executed when the game is not in lock mode, when the game is in lock mode but not in a locked-on state, or when the game is in a locked-on state but no BC has appeared. In FIG. 64, first, in step S321, processor 81 determines whether Y button 56 is on. If it is on (YES in step S321), in step S322, processor 81 causes the PC to start the avoidance action described above. In the following step S323, processor 81 sets the PC state to "avoidance state." Thereafter, the normal command processing ends.

[0250] In other embodiments, the evasive action may be controlled in combination with a directional input to the left stick 32, as in the case of the dash described above. For example, when a directional input to the left stick 32 occurs while the Y button 56 is pressed, an evasive action in that direction may be initiated.

[0251] On the other hand, if the result of the determination in step S321 above is that Y button 56 is not on (NO in step S321), then in step S324, processor 81 determines whether or not A button 53 is on. If the result of the determination is that A button 53 is on (YES in step S324), processor 81 executes a decision process in step S325. In this process, a process is executed to perform a predetermined action according to the current state of the PC. For example, a process is executed appropriately to operate a button located in the virtual space, open a door, pick up a dropped item, etc. Then, the normal command process ends.

[0252] On the other hand, if A button 53 is not on (NO in step S324), then in step S326, processor 81 determines whether or not X button 55 (menu instruction) is on. If X button 55 is on (YES in step S326), then in step S327, processor 81 determines whether or not the current mode is the lock mode. If the determination result shows that the current mode is not the lock mode (NO in step S327), X button 55 is on but ZL button 39 is off. In this case, in step S328, processor 81 pauses the game progress and sets menu flag 375 to on. On the other hand, if the current mode is the lock mode (YES in step S327), then the X button is on and the ZL button 39 is also on (however, lock-on flag 322 is off). In this case, the process proceeds to step S329, which will be described later. In other words, control is exercised to disable operation of X button 55 while ZL button 39 is being pressed. In other words, even if the BC and FC are fighting, as long as the ZL button 39 is not pressed, it is possible to open the menu screen and use a specific item, for example, an item that restores the BC's stamina.

[0253] On the other hand, if X button 55 is not on (NO in step S326), then in step S329, processor 81 determines whether or not + button 57 is on. If + button 57 is on (YES in step S329), then in step S330, processor 81 determines whether or not the current mode is the lock mode. If the result of this determination is that the current mode is not the lock mode (NO in step S330), processor 81 pauses the game progress and sets map flag 376 to ON in step S331. Thereafter, normal command processing ends. On the other hand, if the current mode is the lock mode (YES in step S330), normal command processing ends. In other words, control is exercised to disable operation of + button 57 while ZL button 39 is being pressed.

[0254] Next, the attack command processing will be described. This processing is executed when the lock-on state is established and a BC has also appeared. Figure 65 is a flowchart showing the details of the attack command processing. First, in step S341, processor 81 determines whether + button 57 is on. If the result of this determination is on (YES in step S341), in step S342, processor 81 controls the on / off switching of the strong attack mode described above. That is, each time + button 57 is pressed, the strong attack mode is switched on and off. When switching from off to on, processor 81 also controls the consumption of a predetermined amount of power gauge 208. However, if power gauge 208 has not yet accumulated to the predetermined amount at this time, processor 81 proceeds with the processing without switching the strong attack mode on. Thereafter, the attack command processing ends.

[0255] On the other hand, if + button 57 is not on (NO in step S341), processor 81 determines in step S343 whether any of A button 53, B button 54, X button 55, and Y button 56 is on. If the result of this determination is that none of them is on (NO in step S343), attack command processing ends. On the other hand, if any button is on (YES in step S343), processor 81 next determines in step S344 whether strong attack mode has been switched on. If the result of this determination is that strong attack mode is off (NO in step S344), processor 81 instructs the BC to begin an attack using the attack method assigned to any of the buttons determined to be on in the above determination. Furthermore, in step S347, processor 81 adds a predetermined amount to power gauge 208. That is, power gauge 208 is accumulated each time an attack instruction is issued. Note that the amount to be added may vary depending on the positions of the PC and BC when the attack instruction is issued. For example, the closer the two are to each other, the greater the gauge amount that is added.

[0256] On the other hand, if the strong attack mode is on (YES in step S344), in step S346, processor 81 instructs the BC to start an attack in the strong attack mode using the attack method assigned to any of the buttons determined to be on in the above determination. For example, control may be exercised to double the attack power parameter set for that attack method and then issue an instruction to start the attack, or control may be exercised to issue an instruction to attack using a parameter set for the strong attack mode that has been prepared in advance. Then, attack command processing ends.

[0257] Returning to FIG. 63, next, in step S314, processor 81 executes appearance control processing. This processing is executed regardless of the lock-on state. FIG. 66 is a flowchart showing details of the appearance control processing. First, in step S351, processor 81 determines whether right direction button 33 or left direction button 36 is on. That is, it determines whether an operation to move selection cursor 501 has been performed. If the result of the determination is that an operation to move selection cursor 501 has been performed (YES in step S351), in step S352, processor 81 moves selection cursor 501 based on the operation content, and changes the content of selection cursor data 371 so that it becomes the owned character designated by selection cursor 501 after the movement. Thereafter, the appearance control processing ends.

[0258] On the other hand, if the operation to move selection cursor 351 has not been performed (NO in step S351), then in step S353, processor 81 determines whether down button 34 is on or not, that is, whether an operation to move back an appearing BC (back operation) has been performed. If the result of this determination is that a back operation has been performed (YES in step S353), processor 81 determines in step S354 whether an appearing BC exists or not, and if so (YES in step S354), performs control to move back that BC. At this time, if the appearing BC is in an enhanced state, processor 81 sets enhancement flag 374 to OFF. Also, processor 81 performs control to erase appearing cursor 502. On the other hand, if there is no appearing BC (NO in step S354), this process is skipped. Thereafter, the appearance control process ends.

[0259] On the other hand, if a return operation has not been performed (NO in step S353), in step S356, processor 81 determines whether or not up button 35 is on. That is, it is determined whether or not an operation to make a BC appear (appearance operation) has been performed. If the result of this determination is that an appearance operation has been performed (YES in step S356), processor 81 determines in step S357 whether or not there is a currently appearing BC. If there is (YES in step S357), in step S358, processor 81 performs control to return the BC in the same manner as above. If there is not (NO in step S357), the processing of step S358 is skipped.

[0260] Next, the same processing as steps S42 to S44 in the first embodiment is performed. Specifically, in step S42, processor 81 sets the owned character designated by selection cursor data 371 as the BC. Next, in step S43, processor 81 sets entrance effect flag 323 to ON, and in the following step S44, processor 81 starts an entrance effect similar to that in the first embodiment. Accordingly, control is also performed to display entrance cursor 502. Thereafter, the entrance control processing ends.

[0261] This concludes the description of the instruction operation-related processing.

[0262] Returning to FIG. 55, next, in step S216, processor 81 executes right stick processing. FIG. 67 is a flowchart showing the details of the right stick processing. First, in step S371, processor 81 determines, based on operation data 319, whether or not a directional input operation has been performed on right stick 52. If the determination result shows that a directional input has been performed (YES in step S371), processor 81 determines, in step S372, whether or not lock-on flag 322 is on. If lock-on flag 322 is on (YES in step S372), processor 81 performs control to switch the lock-on target (step S374). On the other hand, if lock-on flag 322 is off (NO in step S372), processor 81 sets parameters of the virtual camera based on the operation content (step S373). In virtual camera control processing, which will be described later, the virtual camera is controlled based on the parameters set here, thereby realizing operation of the virtual camera by right stick 52. Thereafter, the process proceeds to step S375.

[0263] On the other hand, if the result of the determination in step S371 is that no directional input has been made (NO in step S371), then in step S375, processor 81 determines whether or not a pressing operation of right stick 52 has been performed. If the result of the determination is that a pressing operation has been performed (YES in step S375), processor 81 determines in step S376 whether or not a strengthening condition for the BC has been met. Specifically, if a BC is currently appearing and power gauge 208 is filled to the MAX, it is determined that the strengthening condition has been met. Note that, depending on the type of BC, there may be a BC of a type that does not have the ability to be strengthened; in this case, the strengthening condition may be that a BC of a strengthenable type is currently appearing.

[0264] As a result of the above determination, if the strengthening condition is satisfied (YES in step S376), processor 81 sets the strengthening flag to ON in step S377.

[0265] On the other hand, if the right stick 52 has not been pressed (NO in step S375), the processes of steps S376 to S377 are skipped. This is the end of the right stick control process.

[0266] Returning to FIG. 55, once the right stick control process is completed, the PC control process ends.

[0267] Returning to Fig. 54, after the PC control processing, in step S204, the processor 81 executes BC control processing. Figs. 68 and 69 are flowcharts showing details of the BC control processing according to the second embodiment. Here, the flows in Figs. 68 and 69 perform the same processing as the BC control processing described using Figs. 42 and 43 in the first embodiment, except for the processing related to step S381. Therefore, here we will mainly describe the processing related to step S381, and omit descriptions of the other processing.

[0268] In FIG. 68, in step S381, processor 81 executes strengthened state control processing. This is processing related to the strengthened state of the BC. FIG. 70 is a flowchart showing details of the strengthened state control processing. First, in step S391, processor 81 determines whether strengthened flag 374 is on or not. If the result of this determination is off (NO in step S391), in step S396, processor 81 sets normal parameters as parameters (e.g., attack power, etc.) of the appearing BC. As a result, in subsequent processing, the BC's action control (attack action, etc.) will be performed using the normal parameters.

[0269] On the other hand, if enhancement flag 374 is on (YES in step S391), processor 81 determines in step S392 whether the enhancement cancellation condition is satisfied. In this example, the enhancement cancellation condition is determined to be satisfied when power gauge 208 reaches 0, when an operation is performed to return an enhanced BC to its owned character state, or when the strength value of an enhanced BC reaches 0. If the enhancement cancellation condition is not satisfied (NO in step S392), processor 81 sets enhanced state parameters as the parameters of the currently appearing BC. For example, this control may involve setting various parameters and attack effects doubled from those in the normal state, or setting preset parameters as parameters for the enhanced state. As a result, in subsequent processing, the BC's actions (such as attack actions) are controlled using the enhanced parameters. Furthermore, while the BC is in an enhanced state, the BC's appearance may be changed to that of the enhanced state so that this fact can be visually recognized.

[0270] Next, in step S394, processor 81 decreases power gauge 208 by a predetermined amount, and then the enhanced state control process ends.

[0271] On the other hand, if the result of the determination in step S392 above is that the enhancement cancellation condition is satisfied (YES in step S392), in step S395, processor 81 sets enhancement flag 374 to OFF. Then, the process proceeds to step S396 above.

[0272] This concludes the explanation of the reinforced state control process. After the reinforced state control process, the processes from step S116 onwards are executed as a continuation of the BC control process. Here, a supplementary explanation will be given regarding the BC attack action control relating to steps S122 and S126. In this embodiment including the first example, at least two types of attack methods are prepared for the BC: a "long-range attack" and a "close-range attack" (other than these, recovery actions and the like are also prepared, but their explanation will be omitted here). A supplementary explanation will be given regarding the BC actions relating to these two types of attack methods.

[0273] First, if the attack instruction given in step S123 is a "long-range attack," the BC is controlled to perform the following actions in step S126 and the subsequent step S122. First, the BC is moved to a predetermined attack start position. This position may be, for example, a position diagonally in front of the PC to the right. Next, when the BC reaches the attack start position, a long-range attack motion according to the attack instruction is initiated, and a long-range attack (for example, firing a predetermined bullet) is performed toward the locked-on target FC. Note that in the case of long-range attacks, the reach of the attack may be set for each attack method. In this case, since the long-range attack may not reach the target depending on the distance between the BC and the FC, the excitement of the game can be improved by adding an element of maneuvering that takes into account the positional relationship with the FC.

[0274] Next, if the attack command is a "melee attack," the BC is controlled to perform the following actions. In this case, the BC is also moved to a predetermined attack start position, but in the case of a melee attack, the attack start position is a position adjacent to the FC that is the lock-on target. Once the BC reaches the attack start position, it begins a melee attack motion according to the attack command, and performs a melee attack (such as a punch) toward the FC that is the lock-on target. After that, once the melee attack motion is complete, the BC returns to the vicinity of the PC.

[0275] In this way, since the starting position of the BC attack action differs between long-range attacks and close-range attacks, the user can decide whether to use a long-range attack or a close-range attack while taking into account the attack starting position and the relative positions of the FC and BC, improving the strategic nature of the game.

[0276] Returning to Fig. 54, after the BC control process, the FC control process is executed. This process is the same as step S4 in the second embodiment, and therefore a description thereof will be omitted.

[0277] Next, in step S205, processor 81 executes various other game control processes. That is, various collision determinations and processes based on the results of the collision determinations are executed. This process is basically the same as step S5 in the first embodiment, but some supplementary explanation is provided below. In the second embodiment, as described above, the PC is capable of evasive action. Therefore, whether the FC's attack has collided with the PC is determined based on the position of the FC's attack and the position of the PC. During this determination, it is also determined whether the PC is in the "evasive state." If the PC is in the evasive state, control is exercised so that a collision determination between the FC's attack and the PC is not performed. As a result, the PC will avoid the FC's attack.

[0278] Next, in step S206, the processor 81 executes virtual camera control processing. FIG. 71 is a flowchart showing the details of the virtual camera control processing. In FIG. 71, first, in step S411, the processor 81 determines whether or not the lock-on flag 322 is on (whether or not the lock-on state is in). If it is off (NO in step S411), in step S412, the processor 81 controls the virtual camera based on the camera parameters set in step S373 above. Next, in step S414, the processor 81 places the aim at a position that will be the center of the screen. Thereafter, the virtual camera control processing ends.

[0279] On the other hand, if the lock-on flag is on (YES in step S411), in step S414, processor 81 controls the virtual camera so that the lock-on target is displayed within a predetermined range in the center of the screen. Next, in step S415, processor 81 positions the crosshairs so that they are superimposed on the lock-on target. This ends the virtual camera control processing.

[0280] The appearance of the sight may be different depending on whether the lock-on flag is on or off, which makes it easier to visually understand that the FC is locked on.

[0281] 54, after the virtual camera control process, in step S7, processor 81 generates and outputs a game image that reflects the above process content. Thereafter, as in the first embodiment, in step S8, it is determined whether the game is over.

[0282] Next, a description will be given of the process when the menu flag is on as a result of the determination in step S201 above (YES in step S201). In this case, in step S207, processor 81 executes menu processing. FIG. 72 is a flowchart showing the details of the menu processing. First, in step S421, processor 81 determines, based on operation data 319, whether or not an operation to close the menu screen has been performed. If the result of this determination is that no operation has been performed (NO in step S421), processor 81 executes various processes related to the menu screen based on operation data 319. For example, a process to use an owned item is executed.

[0283] On the other hand, if an operation to close the menu screen has been performed (YES in step S421), in step S423, processor 81 sets menu flag 375 to OFF. Next, in step S424, processor 81 executes processing to clear the menu screen. Next, in step S425, processor 81 resumes the paused game processing. Thereafter, menu processing ends.

[0284] Returning to FIG. 54, once the menu processing is completed, the process proceeds to step S7.

[0285] Next, the process when the map flag is on as a result of the determination in step S202 above (YES in step S202) will be described. In this case, in step S208, processor 81 executes map processing. FIG. 73 is a flowchart showing the details of the map processing. First, in step S431, processor 81 determines, based on operation data 319, whether or not an operation to close the map screen has been performed. If the result of the determination is that no operation has been performed (NO in step S431), processor 81 executes various processes related to the map screen based on operation data 319 to generate the map screen.

[0286] On the other hand, if an operation to close the map screen has been performed (YES in step S431), in step S433, processor 81 sets map flag 376 to OFF. Next, in step S434, processor 81 executes processing to erase the map screen. Next, in step S435, processor 81 resumes the paused game processing. Thereafter, map processing ends.

[0287] Returning to FIG. 54, once the map processing is completed, the process proceeds to step S7.

[0288] This concludes the explanation of the game processing according to the second embodiment.

[0289] As with the first embodiment, the second embodiment also allows for the capture of the FC in a variety of situations. Furthermore, it is possible to simultaneously execute the action of throwing a capture item and fighting the FC. In other words, while the BC attacks the FC, the PC itself can perform a different action (such as throwing a capture item or taking an evasive action). In other words, capture operations and instructions to attack the FC can be performed simultaneously in real time. This makes it easy to perform actions such as having the BC attack the FC to reduce its health, thereby increasing the capture success rate, and then throwing the capture item at the right time. Furthermore, even with a limited number of buttons available, such as the controller described above, it is possible to simultaneously control two control targets, the PC and the BC, in real time. Furthermore, as described above, the BC's attack method has a charge time, which allows for leeway for switching to control the PC during the charge time, making it easier to perform simultaneous operations in parallel. Furthermore, because the BC's attack method is controlled by switching between operations that require lock-on and operations that do not, depending on the lock-on state, the limited number of buttons can be used efficiently. Furthermore, when the ABXY buttons are locked on while a BC is present, they are used to issue attack commands to the BC. In other words, the operation to lock on (turning on the ZL button 39) also serves as a transition to a state where the ABXY buttons are used to issue attack commands to the BC, making it easy to throw capture items at the locked-on target while fighting the FC.

[0290] [Variations] In the above embodiment, an example was shown in which capture is possible even when the FC is in a "combat state." In other embodiments, a configuration may be adopted in which capture is not possible when the FC is in a "combat state." For example, even if a capture action is performed, the capture item may be repelled by the FC.

[0291] In the above embodiment, an example was shown in which the "chance state" ends after a certain period of time has passed since the FC entered the "chance state." Furthermore, an example was shown in which capture can be attempted any number of times during the "chance state." In this regard, in other embodiments, a limit may be placed on the number of capture attempts during the "chance state." For example, if the number of attempts is set to three, and if capture is unsuccessful after three capture attempts during the "chance state," the "chance state" may be ended at that point, even if a certain period of time has not yet passed since the "chance state" began.

[0292] In the above embodiment, when the FC's vitality value becomes 0, it is considered to have been defeated and the state transitions to a "chance state." In this regard, the determination of being defeated is not limited to when the vitality value becomes 0, but may also be determined to have been defeated when the vitality value becomes a predetermined value or less, for example, when the vitality value becomes 10% or less.

[0293] In the above embodiment, an example was given in which, if a capture action is performed when the FC is in a "non-combat state" and the capture fails, the FC transitions to a "combat state." In this regard, in other embodiments, if the capture fails, the FC may be made to flee. For example, whether to transition to a "combat state" or to flee may be preset depending on the type of FC, or whether to transition to a "combat state" or to flee when capture fails may be determined by lottery.

[0294] Furthermore, in the above embodiment, an example was given in which only one BC appears, but in other embodiments, a plurality of BCs may appear.

[0295] In addition, in the above-mentioned BC control process, if the distance between the BC and the PC remains at or above a predetermined distance for a certain period of time, the BC may be warped toward the PC. Furthermore, even if an attack command is issued when the distance between the BC and the PC is at or above a predetermined distance, the BC may be warped toward the PC first, and then moved to the attack start position.

[0296] In addition, in the above example, the lock mode is turned on while the ZL button 39 is pressed, but the lock mode may alternatively be turned on and off each time the ZL button 39 is pressed.

[0297] Furthermore, with regard to the transition of the BC to an enhanced state by pressing the right stick 52, the above example shows an example in which all of the power gauge accumulated to the maximum is consumed, but it is not limited to this, and transition to an enhanced state may also be made by consuming not all of the power gauge accumulated to the maximum, but for example, by consuming a second amount that is greater than the first amount, which is the amount of gauge consumed when switching to the above-mentioned "strong attack mode."

[0298] Furthermore, the timing at which the BC can transition to the strengthened state is not limited to the above, and it may be configured so that the BC can transition to the strengthened state only when in the lock-on state, for example.

[0299] In the above embodiment, the game processing described above is executed by a single main unit 2. The main unit 2 may include multiple storage devices and processors. The game processing may be executed by sharing the processing among these devices. The above processing may also be executed in a distributed system consisting of multiple information processing devices including at least one server. [Explanation of symbols]

[0300] 1. Game System 2 Main unit 3 Left Controller 4 Right Controller 81 processors 84 Flash memory 85 DRAM

Claims

1. On the computer, controlling the movement of a player character in a virtual space based on a first operation input which is a directional input; transitioning the player character to a locked state in which the player character is locked onto an enemy character disposed in the virtual space based on a second operation input; in an unlocked state that is not the locked state, causing the player character to further perform a first action based on a third operation input; In the locked state, when a combat character that will fight against the enemy character appears in the virtual space, if a combat action corresponding to an operation input that has been performed among a plurality of combat actions corresponding to each of the first operation input group based on any of the first operation input group including the third operation input is in a state in which the combat action corresponding to the performed operation input can be performed, the combat character is made to perform the combat action against the locked enemy character, and the state is transitioned to one in which the combat action cannot be performed; A game program that transitions the combat action that is not in an invokable state to the invokable state based on the passage of time.

2. The computer further comprises: causing the enemy character to perform an enemy attack action that is an attack on the player character or the combat character; determining whether the enemy attack action has hit the player character based on a position where the enemy attack action has been performed and a position of the player character; When the enemy attack action hits the player character, damage is inflicted on the player character; 2. The game program according to claim 1, wherein the first action is an action to avoid the enemy attack action.

3. The computer, 3. The game program according to claim 2, wherein in the unlocked state, the movement control of the player character is performed at high speed based on a fourth operation input included in the first operation input group.

4. 2. The game program according to claim 1, wherein the first action is an action for performing the movement control at high speed.

5. The computer further comprises: At least in the first state, which is the unlocked state, 2. The game program according to claim 1, wherein a menu UI is presented that allows the player to select at least an item to be used for the combat character based on a fifth operation input included in the first operation input group.

6. The computer further comprises: selecting one of the plurality of combat characters based on a sixth operation input that is not included in the first operation input group; 2. The game program according to claim 1, wherein the selected combat character is caused to appear in the virtual space based on a seventh operation input that is not included in the first operation input group.

7. The computer further comprises: controlling the direction of the virtual camera based on an eighth operation input that is a directional input when the virtual camera is unlocked; 2. The game program according to claim 1, wherein, during the locking state, the virtual camera is controlled based on the position of the enemy character to be locked, and the enemy character to be locked is changed to another enemy character based on the eighth operation input.

8. The computer further comprises: based on a ninth operation input, causing the player character to perform an action of releasing a capture item for capturing the enemy character, the capture item being aimed at the enemy character to be locked in the locked state, and being aimed in a target direction in the unlocked state; 2. The game program according to claim 1, wherein when the capture item hits the enemy character, a capture success determination is made, and when the capture success determination is successful, the enemy character is set to a state in which it is possessed by the player.

9. The computer, 2. The game program according to claim 1, wherein when any of the first group of operation inputs is performed in the locked state, the combat action corresponding to the performed operation input is performed by moving the combat character so that the positional relationship set for that combat action is established, and then moving the combat character in accordance with the animation set for that combat action.

10. The computer, when the combat action is a long-range attack action, moving the combat character to a predetermined position based on the position of the player character, and then causing the combat character to perform a long-range attack on the enemy character that is a lock target; 10. The game program according to claim 9, wherein, when the combat action is a close-range attack action, the combat character is caused to move closer to the enemy character and perform a close-range attack.

11. The computer, increasing a first parameter based on the execution of the combat action; In the locked state, transitioning to a state in which the enhanced combat action can be performed by consuming a first amount of the first parameter based on a tenth operation input; 2. The game program according to claim 1, wherein the combat character is strengthened by consuming the first parameter by a second amount greater than the first amount based on an eleventh operation input.

12. The computer, 12. The game program according to claim 1, wherein the game is transitioned to the locked state when the positional relationship between the player character and the enemy character satisfies a predetermined condition while the second operation input is continuing.

13. A game processing method executed by a computer including at least one processor, comprising: The computer, controlling the movement of a player character in a virtual space based on a first operation input which is a directional input; transitioning the player character to a locked state in which the player character is locked onto an enemy character disposed in the virtual space based on a second operation input; in an unlocked state that is not the locked state, causing the player character to further perform a first action based on a third operation input; In the locked state, when a combat character that will fight against the enemy character appears in the virtual space, if a combat action corresponding to an operation input that has been performed among a plurality of combat actions corresponding to each of the first operation input group based on any of the first operation input group including the third operation input is in a state in which the combat action corresponding to the performed operation input can be performed, the combat character is made to perform the combat action against the locked enemy character, and the state is transitioned to one in which the combat action cannot be performed; A game processing method for transitioning the combat action that is not in an invokable state to the invokable state based on the passage of time.

14. The computer further comprises: causing the enemy character to perform an enemy attack action that is an attack on the player character or the combat character; determining whether the enemy attack action has hit the player character based on a position where the enemy attack action has been performed and a position of the player character; When the enemy attack action hits the player character, damage is inflicted on the player character; 14. The game processing method according to claim 13, wherein the first action is an action to avoid the enemy attack action.

15. The computer, 15. The game processing method according to claim 14, wherein, in the unlocked state, the movement control of the player character is performed at high speed based on a fourth operation input included in the first operation input group.

16. 14. The game processing method according to claim 13, wherein the first action is an action for performing the movement control at high speed.

17. The computer further comprises: At least in the first state, which is the unlocked state, The game processing method according to claim 13 , further comprising presenting a menu UI for allowing at least a selection of an item to be used for the combat character based on a fifth operation input included in the first operation input group.

18. The computer further comprises: selecting one of the plurality of combat characters based on a sixth operation input that is not included in the first operation input group; 14. The game processing method according to claim 13, wherein the selected combat character is caused to appear in the virtual space based on a seventh operation input that is not included in the first operation input group.

19. The computer further comprises: controlling the direction of the virtual camera based on an eighth operation input that is a directional input when the virtual camera is unlocked; 14. The game processing method according to claim 13, wherein, during the locking state, the virtual camera is controlled based on the position of the enemy character to be locked, and the enemy character to be locked is changed to another enemy character based on the eighth operation input.

20. The computer further comprises: based on a ninth operation input, causing the player character to perform an action of releasing a capture item for capturing the enemy character, the capture item being aimed at the enemy character to be locked in the locked state, and being aimed in a target direction in the unlocked state; 14. A game processing method according to claim 13, wherein when the capture item hits the enemy character, a capture success determination is made, and when the capture success determination is successful, the enemy character is set to a state in which it is possessed by the player.

21. The computer, 14. A game processing method according to claim 13, wherein when any of the first group of operation inputs is performed in the locked state, the combat action corresponding to the performed operation input is performed by moving the combat character so that the positional relationship set for that combat action is established, and then causing the combat character to operate in an animation set for that combat action.

22. The computer, when the combat action is a long-range attack action, moving the combat character to a predetermined position based on the position of the player character, and then causing the combat character to perform a long-range attack on the enemy character that is a lock target; 22. A game processing method according to claim 21, wherein, when the combat action is a close-range attack action, the combat character is caused to move closer to the enemy character and perform a close-range attack.

23. The computer, increasing a first parameter based on the execution of the combat action; In the locked state, transitioning to a state in which the enhanced combat action can be performed by consuming a first amount of the first parameter based on a tenth operation input; 14. The game processing method according to claim 13, wherein the first parameter is consumed by a second amount greater than the first amount, based on an eleventh operation input, to strengthen the combat character.

24. The computer, 24. A game processing method according to claim 13, wherein while the second operation input is continuing, if the positional relationship between the player character and the enemy character satisfies a predetermined condition, the state is transitioned to the locked state.

25. 1. A gaming system comprising at least one processor, The processor: controlling movement of a player character within a virtual space based on a first operation input which is a directional input; transitioning the player character to a locked state in which the player character is locked onto an enemy character disposed in the virtual space based on a second operation input; in an unlocked state that is not the locked state, causing the player character to further perform a first action based on a third operation input; In the locked state, when a combat character that will fight against the enemy character appears in the virtual space, if a combat action corresponding to an operation input that has been performed among a plurality of combat actions corresponding to each of the first operation input group based on any of the first operation input group including the third operation input is in a state in which the combat action corresponding to the performed operation input can be performed, the combat character is made to perform the combat action against the locked enemy character, and the state is transitioned to one in which the combat action cannot be performed; The game system transitions the combat action that is not in an invokable state to the invokable state based on the passage of time.

26. The processor further comprises: causing the enemy character to perform an enemy attack action that is an attack on the player character or the combat character; determining whether the enemy attack action has hit the player character based on a position where the enemy attack action has been performed and a position of the player character; When the enemy attack action hits the player character, damage is inflicted on the player character; 26. The game system according to claim 25, wherein the first action is an action to avoid the enemy attack action.

27. The processor:

27. The game system according to claim 26, wherein, in the unlocked state, the movement control of the player character is performed at high speed based on a fourth operation input included in the first operation input group.

28. 26. The game system according to claim 25, wherein the first action is an action that performs the movement control at high speed.

29. The processor further comprises: At least in the first state, which is the unlocked state, 26. The game system according to claim 25, wherein a menu UI is presented that allows at least a selection of an item to be used for the combat character based on a fifth operation input included in the first operation input group.

30. The processor further comprises: selecting one of the plurality of combat characters based on a sixth operation input that is not included in the first operation input group; 26. The game system according to claim 25, wherein the selected combat character is caused to appear in the virtual space based on a seventh operation input that is not included in the first operation input group.

31. The processor further comprises: When the virtual camera is unlocked, the direction of the virtual camera is controlled based on an eighth operation input that is a directional input; 26. The game system according to claim 25, wherein, during the locked state, the virtual camera is controlled based on the position of the enemy character to be locked, and the enemy character to be locked is changed to another enemy character based on the eighth operation input.

32. The processor further comprises: based on a ninth operation input, causing the player character to perform an action of releasing a capture item for capturing the enemy character, the capture item being aimed at the enemy character to be locked in the locked state, and being aimed in a target direction in the unlocked state; 26. The game system according to claim 25, wherein when the capture item hits the enemy character, a capture success determination is made, and when the capture success determination is successful, the enemy character is set to a state in which it is possessed by the player.

33. The processor:

26. The game system of claim 25, wherein when any of the first group of operation inputs is performed in the locked state, the combat action corresponding to the performed operation input is performed by moving the combat character so that the positional relationship set for that combat action is established, and then moving the combat character in accordance with the animation set for that combat action.

34. The processor: when the combat action is a long-range attack action, moving the combat character to a predetermined position based on the position of the player character, and then causing the combat character to perform a long-range attack on the enemy character that is a lock target; 34. A game system according to claim 33, wherein, when the combat action is a close-range attack action, the combat character is caused to move closer to the enemy character and perform a close-range attack.

35. The processor: increasing a first parameter based on performance of the combat action; In the locked state, transitioning to a state in which the enhanced combat action can be performed by consuming a first amount of the first parameter based on a tenth operation input; 26. The game system according to claim 25, wherein the combat character is strengthened by consuming the first parameter by a second amount greater than the first amount based on an eleventh operation input.

36. The processor:

36. A game system according to claim 25, wherein the state is transitioned to the locked state when the positional relationship between the player character and the enemy character satisfies a predetermined condition while the second operation input is continuing.

37. A gaming device comprising at least one processor, The processor: controlling movement of a player character within a virtual space based on a first operation input which is a directional input; transitioning the player character to a locked state in which the player character is locked onto an enemy character disposed in the virtual space based on a second operation input; in an unlocked state that is not the locked state, causing the player character to further perform a first action based on a third operation input; In the locked state, when a combat character that will fight against the enemy character appears in the virtual space, if a combat action corresponding to an operation input that has been performed among a plurality of combat actions corresponding to each of the first operation input group based on any of the first operation input group including the third operation input is in a state in which the combat action corresponding to the performed operation input can be performed, the combat character is made to perform the combat action against the locked enemy character, and the state is transitioned to one in which the combat action cannot be performed; The game device causes the combat action that is not in an invokable state to transition to an invokable state based on the passage of time.

Images