Computer-readable non-transitory recording medium on which game program is recorded, game system, game processing method, and game device

Abstract

Provided are a computer-readable non-transitory recording medium on which a game program is recorded, a game system, a game processing method, and a game device. Performing movement control on the player character based on the first operation input; transitioning the player character to a locked state in which the enemy character has been locked on the basis of the second operation input; a control unit that causes, on the basis of a third operation input, the combat character to perform an attack behavior corresponding to the third operation input with respect to the enemy character to be locked on the basis of the third operation input when the combat character that is in the locked state and that is to combat with the enemy character has exited in the virtual space; causing, on the basis of the fourth operation input, the player character to release the capture item toward the enemy character as a lock object in the locked state, and release the capture item toward the front sight direction in an unlocked state that is not the locked state; and setting the enemy character to be held by the player when the capture success determination is successful.

Description

[0001] Cross reference to related applications

[0002] The publications of Japanese Patent Application No. 2024-113974 filed on July 17, 2024, Japanese Patent Application No. 2024-214604 filed on December 9, 2024, Japanese Patent Application No. 2024-214605 filed on December 9, 2024, and Japanese Patent Application No. 2024-214606 filed on December 9, 2024, are incorporated herein by reference. Technical Field

[0003] This disclosure relates to a game processing method for handling characters within a virtual space. Background Technology

[0004] Previously, there was a known game where a player character could capture a character in a virtual space by launching a ball at that character, thus establishing that character as owned by the player character. Additionally, there was a known game where a player character could initiate a battle with another player character by launching a combat character instead of a ball at that virtual space.

[0005] Regarding the game as described above, there is still room for improvement in providing new methods related to character capture and combat. Summary of the Invention

[0006] Given the above, the following structural examples can be cited, for instance.

[0007] (Structure 1)

[0008] Structure 1 is a computer-readable non-transitory recording medium containing a game program that causes the computer to perform the following processes: controlling the movement of a player character within a virtual space based on a first operation input (direction input); changing the player character to a locked state (locked against an enemy character in the virtual space) based on a second operation input; in the locked state, if a combat character to fight the enemy character appears in the virtual space, causing the combat character to perform an attack on the locked enemy character corresponding to the third operation input based on a third operation input; and causing the player character to perform the following actions based on a fourth operation input: in the locked state, releasing a capture item towards the locked enemy character; in the unlocked state (not locked), releasing a capture item towards the crosshair direction; and if the capture item hits the enemy character, performing a capture success determination; and if the capture success determination is successful, setting the enemy character as being held by the player.

[0009] According to the above structure, the player character can perform the action of releasing the capturing item regardless of whether the player character is in the middle of an attack by the battle character or not. In addition, the operation for locking the enemy character has the effect of changing the state to a state in which an attack can be instructed, so the capturing item can be released easily while the battle is performed.

[0010] (Structure 2)

[0011] With regard to Structure 2, it can also be that, in the above Structure 1, the attack behavior is a behavior that changes the state of the enemy character, and the success easiness of the capturing success determination changes according to the state of the enemy character.

[0012] According to the above structure, it is easy to adjust the success easiness by the attack behavior and to perform the action of releasing the capturing item at a desired timing.

[0013] (Structure 3)

[0014] With regard to Structure 3, it can also be that, in the above Structure 1 or Structure 2, the computer further performs the following processing: a hunting determination of whether the enemy character has been hunted by the attack behavior; in the case where the enemy character has been hunted, the enemy character is eliminated from the virtual space after a first period after the hunting; and in the case where the capturing item hits the enemy character within the first period, the success easiness is raised to perform the capturing success determination.

[0015] According to the above structure, it is possible to provide a motive for hunting the enemy character.

[0016] (Structure 4)

[0017] With regard to Structure 4, it can also be that, in any of the above Structures 1 to 3, the third operation input is included in a first operation input group including a plurality of operation inputs, and the attack behavior is a battle behavior corresponding to the third operation input among a plurality of battle behaviors respectively corresponding to the operation inputs of the first operation input group. Also, the computer can perform the following processing: in the case where any of the operation inputs of the first operation input group is performed in the locked state, the battle behavior corresponding to the performed operation input is performed by causing the battle character to move so as to become a positional relationship set for the battle behavior and causing the battle character to perform an animation set for the battle behavior.

[0018] (Structure 5)

[0019] As for the structure 5, it can also be that, in any of the above structures 1 to 4, the computer is caused to perform the following processing: in a case where the attack behavior is in the launchable state, the combat character is caused to perform the attack behavior based on the third operation input, and the attack behavior is caused to shift to the unlaunchable state; and the attack behavior in the unlaunchable state is caused to shift to the launchable state according to the passage of time.

[0020] According to the above structure, a waiting time is provided for the launch of the attack behavior, so it is possible to provide leeway for switching to the player's operation during the interval of the attack.

[0021] (structure 6)

[0022] As for the structure 6, it can also be that, in any of the above structures 1 to 5, the computer is caused to perform the following processing: the trajectory of the descent corresponding to the distance is used to move control the captured prop thrown by the player character.

[0023] According to the above structure, when the captured prop is thrown, it is sometimes missed if it is far, so it is possible to provide an element that takes into account the stance of the player character.

[0024] (structure 7)

[0025] As for the structure 7, it can also be that, in any of the above structures 1 to 6, the computer is caused to perform the following processing: the enemy character is caused to perform an enemy attack behavior that is an attack on the combat character; a hit determination of the enemy attack behavior on the player character is performed based on the position at which the enemy attack behavior is performed and the position of the player character; and in a case where the enemy attack behavior hits the player character, damage is applied to the player character.

[0026] According to the above structure, it is possible to provide an element in which the player character tries to capture while taking into account the stance to avoid being drawn into the attack in the battle.

[0027] In addition, each of the above structures can also be implemented as a game processing method in which a computer including at least one processor is caused to execute, a game system provided with at least one processor, and a game device provided with at least one processor. BRIEF DESCRIPTION OF DRAWINGS

[0028] Figure 1 is a drawing showing an example of a state in which the left controller 3 and the right controller 4 are attached to the main body device 2.

[0029] Figure 2 is a drawing showing an example of a state in which the left controller 3 and the right controller 4 are detached from the main body device 2.

[0030] Figure 3 is a six-view drawing showing an example of the main body device 2.

[0031] Figure 4 is a six-face view showing an example of the left controller 3.

[0032] Figure 5 is a six-face view showing an example of the right controller 4.

[0033] Figure 6 is a block diagram showing an example of the internal structure of the main body device 2.

[0034] Figure 7 is a block diagram showing an example of the internal structure of the main body device 2, the left controller 3, and the right controller 4.

[0035] Figure 8 is a diagram showing an example of the third controller.

[0036] Figure 9 is a block diagram showing an example of the internal structure of the third controller.

[0037] Figure 10 is an example of a game screen related to the present embodiment.

[0038] Figure 11 is an example of a game screen related to the present embodiment.

[0039] Figure 12 is an example of a game screen related to the first embodiment.

[0040] Figure 13 is an example of a game screen related to the first embodiment.

[0041] Figure 14 is an example of a game screen related to the first embodiment.

[0042] Figure 15 is an example of a game screen related to the first embodiment.

[0043] Figure 16 is an example of a game screen related to the first embodiment.

[0044] Figure 17 is an example of a game screen related to the first embodiment.

[0045] Figure 18 is an example of a game screen related to the first embodiment.

[0046] Figure 19 is an example of a game screen related to the first embodiment.

[0047] Figure 20 is an example of a game screen related to the first embodiment.

[0048] Figure 21is an example of a game screen involved in the first embodiment.

[0049] Figure 22 is an example of a game screen involved in the first embodiment.

[0050] Figure 23 is an example of a game screen involved in the first embodiment.

[0051] Figure 24 is an example of a game screen involved in the first embodiment.

[0052] Figure 25 is an example of a game screen involved in the first embodiment.

[0053] Figure 26 is an example of a game screen involved in the first embodiment.

[0054] Figure 27 is an example of a game screen involved in the first embodiment.

[0055] Figure 28 is an example of a game screen involved in the first embodiment.

[0056] Figure 29 is an example of a game screen involved in the first embodiment.

[0057] Figure 30 is a memory distribution diagram showing an example of various data stored in the DRAM 85.

[0058] Figure 31 is an example of a data structure of the character master data 309.

[0059] Figure 32 is an example of a data structure of the character possession data 310.

[0060] Figure 33 is an example of a data structure of the FC management data 318.

[0061] Figure 34 is a flowchart showing details of the game processing involved in the first embodiment.

[0062] Figure 35 is a flowchart showing details of the PC control processing.

[0063] Figure 36 is a flowchart showing details of the movement control processing.

[0064] Figure 37 is a flowchart showing details of the appearance control processing.

[0065] Figure 38is a flowchart showing details of the pose gesture association processing.

[0066] Figure 39 is a flowchart showing details of the lock-on association processing.

[0067] Figure 40 is a flowchart showing details of the capture behavior processing.

[0068] Figure 41 is a flowchart showing details of the capture decision processing.

[0069] Figure 42 is a flowchart showing details of the BC control processing.

[0070] Figure 43 is a flowchart showing details of the BC control processing.

[0071] Figure 44 is a flowchart showing details of the FC control processing.

[0072] Figure 45 is a flowchart showing details of the non-combat state processing.

[0073] Figure 46 is a flowchart showing details of the combat state processing.

[0074] Figure 47 is a flowchart showing details of the combat state processing.

[0075] Figure 48 is a flowchart showing details of the opportunity state processing.

[0076] Figure 49 is a diagram explaining the operation of the character column 201.

[0077] Figure 50 is a diagram explaining the operation of the character column 201.

[0078] Figure 51 is a diagram explaining the operation of the character column 201.

[0079] Figure 52 is a diagram for explaining the operation in the second embodiment.

[0080] Figure 53 is a memory distribution diagram showing an example of various data in the second embodiment.

[0081] Figure 54 is a flowchart showing details of the game processing involved in the second embodiment.

[0082] Figure 55 is a flowchart showing details of the PC control processing involved in the second embodiment.

[0083] Figure 56 is a flowchart showing details of the mobile association processing.

[0084] Figure 57 is a flowchart showing details of the normal mobile processing.

[0085] Figure 58 is a flowchart showing details of the mobile processing in lock.

[0086] Figure 59 is a flowchart showing details of the lock association processing.

[0087] Figure 60 is a flowchart showing details of the lock mode processing.

[0088] Figure 61 is a flowchart showing details of the capture association processing.

[0089] Figure 62 is a flowchart showing details of the capture behavior processing involved in the second embodiment.

[0090] Figure 63 is a flowchart showing details of the instruction operation association processing.

[0091] Figure 64 is a flowchart showing details of the normal command processing.

[0092] Figure 65 is a flowchart showing details of the attack command processing.

[0093] Figure 66 is a flowchart showing details of the appearance control processing.

[0094] Figure 67 is a flowchart showing details of the right joystick control processing.

[0095] Figure 68 is a flowchart showing details of the BC control processing involved in the second embodiment.

[0096] Figure 69 is a flowchart showing details of the BC control processing involved in the second embodiment.

[0097] Figure 70 is a flowchart showing details of the reinforcement state control processing.

[0098] Figure 71 is a flowchart showing details of the virtual camera control processing.

[0099] Figure 72 is a flowchart showing details of the menu processing.

[0100] Figure 73 is a flowchart showing details of map processing. DETAILED DESCRIPTION

[0101] Hereinafter, one embodiment will be described. Figure 1 An example of an appearance of a game system to which the present embodiment pertains is shown. One example of the game system 1 in the present embodiment includes a main body device (an information processing device, which functions as a game device main body in the present embodiment) 2, which is one 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 with respect to the main body device 2. That is, the game system 1 can be utilized as a device in which the left controller 3 and the right controller 4 are respectively attached to the main body device 2 to be integrated. In addition, the game system 1 can also independently use the main body device 2 and the left controller 3 and the right controller 4 (see Figure 2 ). Hereinafter, a hardware structure of the game system 1 of the present embodiment will be described, and then a control of the game system 1 of the present embodiment will be described.

[0102] The above Figure 1 is a diagram showing one example of a state in which the left controller 3 and the right controller 4 are attached to the main body device 2. As shown in Figure 1 , the left controller 3 and the right controller 4 are respectively attached to the main body device 2 to be integrated. The main body device 2 is a device that executes various processes (for example, game processing) in the game system 1. The main body device 2 is provided with a display 12. The left controller 3 and the right controller 4 are devices provided with an operation section for input by a player.

[0103] Figure 2 is a diagram showing one example of a state after the left controller 3 and the right controller 4 are respectively detached from the main body device 2. As shown in Figure 1 and Figure 2 , the left controller 3 and the right controller 4 are each detachable with respect to the main body device 2. Furthermore, hereinafter, as a collective term of the left controller 3 and the right controller 4, "controller" is sometimes written.

[0104] Figure 3 is a six-view diagram showing one example of the main body device 2. As shown in Figure 3 , the main body device 2 is provided with a housing 11 which is substantially plate-shaped. In the present embodiment, a main surface (in other words, a surface of a front side, that is, a surface on which the display 12 is provided) of the housing 11 is substantially rectangular in shape.

[0105] Furthermore, the shape and size of the housing 11 are arbitrary. For example, the housing 11 can be a portable size. Alternatively, the main unit 2 can be a standalone unit, or an integrated unit with the left controller 3 and right controller 4 mounted on the main unit 2, which can also be a handheld device. Additionally, the main unit 2 or the integrated unit can also be a portable device.

[0106] like Figure 3 As shown, the main body device 2 includes a display 12 disposed on the main surface of the housing 11. The display 12 is used to display images generated by the main body device 2. In this embodiment, the display 12 is assumed to be a liquid crystal display (LCD). However, the display 12 can be any type of display device.

[0107] In addition, the main device 2 has a touch panel 13 on the screen of the display 12. In this embodiment, the touch panel 13 is a touch panel capable of multi-touch input (e.g., capacitive touch). However, the touch panel 13 can also be any type of touch panel, such as a touch panel capable of single-touch input (e.g., resistive touch).

[0108] The main unit 2 has a speaker inside the housing 11 (i.e., Figure 6 The speaker 88 shown. Figure 3 As shown, speaker holes 11a and 11b are formed on the main surface of the housing 11. Moreover, the output sound of the speaker 88 is output from these speaker holes 11a and 11b respectively.

[0109] In addition, the main unit 2 has a left terminal 17 for wired communication between the main unit 2 and the left controller 3, and a right terminal 21 for wired communication between the main unit 2 and the right controller 4.

[0110] like Figure 3 As shown, the main unit 2 includes a slot 23. The slot 23 is located on the upper side of the housing 11. The slot 23 has a shape suitable for storing a specified type of storage medium. The specified type of storage medium is, for example, a storage medium (e.g., a dedicated memory card) used by the game system 1 and similar information processing devices. The specified type of storage medium is used to store data used in the main unit 2 (e.g., application save data) and / or programs executed in the main unit 2 (e.g., application programs). In addition, the main unit 2 includes a power button 28.

[0111] The main unit 2 includes a lower terminal 27. The lower terminal 27 is used for communication between the main unit 2 and the bracket. In this embodiment, the lower terminal 27 is a USB connector (more specifically, a concave-side connector). When the aforementioned integrated device or main unit 2 is mounted on the bracket, the game system 1 can display the image generated and output by the main unit 2 on a fixed monitor. Furthermore, in this embodiment, the bracket has the function of charging the mounted integrated device or main unit 2. Additionally, the bracket functions as a hub device (specifically, a USB hub).

[0112] Figure 4 This is a six-view diagram showing an example of the left controller 3. (Example) Figure 4 As shown, the left controller 3 includes a housing 31. In this embodiment, the housing 31 has a longitudinal shape, that is, in Figure 4 The vertical direction in the middle ( Figure 4 The shape is elongated along the y-axis (as shown). The left controller 3 can be held longitudinally even when detached from the main body 2. The housing 31 is designed to be held in a shape and size that allows it to be held with one hand, especially the left hand, when held longitudinally. In addition, the left controller 3 can also be held laterally. When the left controller 3 is held laterally, it can also be held with both hands.

[0113] The left controller 3 includes a left analog stick (hereinafter referred to as the left stick) 32, which serves as an example of a direction input device. Figure 4 As shown, the left joystick 32 is mounted on the main surface of the housing 31. The left joystick 32 can be used as a direction input unit. The player can input the direction corresponding to the tilting direction (and the magnitude corresponding to the tilting angle) by tilting the left joystick 32. Alternatively, the left controller 3 can be equipped with a D-pad or a sliding joystick capable of sliding input to replace the analog joystick as the direction input unit. Furthermore, in this embodiment, pressing the left joystick 32 is also possible.

[0114] The left controller 3 is equipped with various operation buttons. On the main surface of the housing 31, the left controller 3 has four operation buttons 33-36 (specifically, a right-direction button 33, a down-direction button 34, an up-direction button 35, and a left-direction button 36). Furthermore, the left controller 3 has a recording button 37 and a negative button 47. On the upper left side of the housing 31, the left controller 3 has a first L button 38 and a ZL button 39. Additionally, on the side of the housing 31 on the side where it is mounted when installed on the main unit 2, the left controller 3 has a second L button 43 and a second R button 44. These operation buttons are used to give instructions corresponding to various programs (e.g., OS programs, application programs) executed by the main unit 2.

[0115] In addition, the left controller 3 has a terminal 42 for wired communication between the left controller 3 and the main unit 2.

[0116] Figure 5 This is a six-view diagram showing an example of the right controller 4. (Example) Figure 5 As shown, the right controller 4 includes a housing 51. In this embodiment, the housing 51 has a longitudinal shape, that is, in Figure 5 The vertical direction in the middle ( Figure 5 The shape is elongated along the y-axis (as shown). The right controller 4 can be held longitudinally even when detached from the main body 2. The housing 51 is designed to be held in a shape and size that allows for single-handed, particularly right-handed, handling when held longitudinally. Furthermore, the right controller 4 can also be held laterally. When held laterally, the right controller 4 can also be held with both hands.

[0117] Like the left controller 3, the right controller 4 also has a right analog stick 52 (hereinafter referred to as the right stick 52) as a direction input unit. In this embodiment, the right stick 52 has the same structure as the left stick 32 of the left controller 3. Alternatively, the right controller 4 may have a cross key or a sliding joystick capable of sliding input instead of the analog stick. Like the left controller 3, the right controller 4 also has four operation buttons 53-56 (specifically, A button 53, B button 54, X button 55, and Y button 56) on the main surface of the housing 51. Furthermore, the right controller 4 has a + (positive) button 57 and a Home button 58. Additionally, the right controller 4 has a first R button 60 and a ZR button 61 on the upper right side of the housing 51. Also like the left controller 3, the right controller 4 has a second L button 65 and a second R button 66.

[0118] In addition, the right controller 4 has a terminal 64 for wired communication between the right controller 4 and the main unit 2.

[0119] Figure 6 This is a block diagram illustrating an example of the internal structure of the main body device 2. The main body device 2, besides... Figure 3 In addition to the structure shown, it also has Figure 6 The constituent elements 81 to 91, 97 and 98 are shown. Some of these constituent elements 81 to 91, 97 and 98 can also be mounted as electronic components on an electronic circuit board and housed in the housing 11.

[0120] The main body device 2 includes a processor 81. The processor 81 is an information processing unit that performs various information processing performed in the main body device 2, and can be configured of only a CPU (Central Processing Unit), or can be configured of an SoC (System-on-a-chip) including a plurality of functions such as a CPU function and a GPU (Graphics Processing Unit) function. The processor 81 performs various 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 a flash memory 84, or an external storage medium mounted to a slot 23, or the like).

[0121] As an example of an internal storage medium built in the main body device 2 itself, the main body device 2 includes a flash memory 84 and a DRAM (Dynamic Random Access Memory) 85. The flash memory 84 and the DRAM 85 are connected to the processor 81. The flash memory 84 is a memory mainly used for storing various data (may be a program) held in the main body device 2. The DRAM 85 is a memory used for temporarily storing various data used in information processing.

[0122] The main body 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 performs data readout and data write to a prescribed kind of storage medium (for example, a dedicated memory card) mounted to the slot 23, according to an instruction of the processor 81.

[0123] The processor 81 appropriately reads out or writes data between the flash memory 84, the DRAM 85, and each of the above-described storage media, and performs the above-described information processing.

[0124] The main body device 2 includes a network communication unit 82. The network communication unit 82 is connected to the processor 81. The network communication unit 82 performs communication (specifically, wireless communication) with an external device via a network. In the present embodiment, as a first communication method, the network communication unit 82 performs communication with an external device by connecting to a wireless LAN in compliance with a standard of Wi-Fi. In addition, as a second communication method, the network communication unit 82 performs wireless communication with other main body devices 2 of the same kind by a prescribed communication method (for example, communication based on a custom protocol, infrared communication). Furthermore, wireless communication based on the above-described second communication method enables wireless communication with other main body devices 2 arranged in a closed local area network, and thereby realizes a function of so-called "local communication" that enables transmission and reception of data by direct communication between a plurality of main body devices 2.

[0125] The main body device 2 is provided with a controller communication section 83. The controller communication section 83 is connected to the processor 81. The controller communication section 83 performs wireless communication with the left controller 3 and / or the right controller 4. The communication method between the main body device 2 and the left controller 3 and the right controller 4 is arbitrary, and in the present embodiment, the controller communication section 83 performs communication in compliance with the standard of Bluetooth (registered trademark) with the left controller 3 and the right controller 4.

[0126] The processor 81 is connected to the above-described left side terminal 17, the right side terminal 21, and the lower side terminal 27. In the case where the processor 81 performs wired communication with the left controller 3, the processor 81 transmits data to the left controller 3 via the left side terminal 17, and receives operation data from the left controller 3 via the left side terminal 17. In addition, in the case where the processor 81 performs wired communication with the right controller 4, the processor 81 transmits data to the right controller 4 via the right side terminal 21, and receives operation data from the right controller 4 via the right side terminal 21. In addition, in the case where the processor 81 performs communication with the cradle, the processor 81 transmits data to the cradle via the lower side terminal 27. In this way, in the present embodiment, the main body device 2 is capable of performing both wired communication and wireless communication with the left controller 3 and the right controller 4, respectively. In addition, in the case where the left controller 3 and the right controller 4 are installed to the main body device 2 to form an integrated device, or the main body device 2 is installed to the cradle alone, the main body device 2 is capable of outputting data (for example, image data, sound data) to a stationary monitor or the like via the cradle.

[0127] Here, the main body device 2 is capable of performing communication with a plurality of left controllers 3 simultaneously (in other words, in parallel). In addition, the main body device 2 is capable of performing communication with a plurality of right controllers 4 simultaneously (in other words, in parallel). Thus, a plurality of players are capable of simultaneously inputting to the main body device 2 using a group of left controllers 3 and right controllers 4, respectively. As an example, it is possible to input to the main body device 2 by a second player using a second group of left controllers 3 and right controllers 4 simultaneously with inputting to the main body device 2 by a first player using a first group of left controllers 3 and right controllers 4.

[0128] The main body device 2 is provided with a touch panel controller 86, which is a circuit that performs control of the touch panel 13. The touch panel controller 86 is connected between the touch panel 13 and the processor 81. The touch panel controller 86 generates data indicating, for example, a position at which a touch input is performed, based on a signal from the touch panel 13, and outputs the data to the processor 81.

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

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

[0131] The main unit 2 is provided with a power control section 97 and a battery 98. The power control section 97 is connected to the battery 98 and the processor 81. In addition, although not illustrated, the power control section 97 is connected to each section of the main unit 2 (specifically, each section that receives supply of power from the battery 98, the left-side terminal 17, and the right-side terminal 21). The power control section 97 controls supply of power from the battery 98 to each section described above based on an instruction from the processor 81.

[0132] In addition, the battery 98 is connected to the lower-side terminal 27. In a case where an external charging device (for example, a cradle) is connected to the lower-side terminal 27 and supplies power to the main unit 2 via the lower-side terminal 27, the supplied power is charged into the battery 98.

[0133] Figure 7 is a block diagram illustrating an example of the internal structure of the main unit 2, the left controller 3, and the right controller 4. Furthermore, details of the internal structure related to the main unit 2 have been illustrated in Figure 6 , and thus are omitted in Figure 7 .

[0134] The left controller 3 is provided with a communication control section 101 that performs communication with the main unit 2. As illustrated in Figure 7 , the communication control section 101 is connected to each constituent element including the terminal 42. In the present embodiment, the communication control section 101 is able to perform communication with the main unit 2 through both wired communication via the terminal 42 and wireless communication without passing through the terminal 42. The communication control section 101 controls the communication method of the left controller 3 to the main unit 2. That is, in a case where the left controller 3 is attached to the main unit 2, the communication control section 101 performs communication with the main unit 2 via the terminal 42. In addition, in a case where the left controller 3 is detached from the main unit 2, the communication control section 101 performs wireless communication with the main unit 2 (specifically, the controller communication section 83). The wireless communication between the controller communication section 83 and the communication control section 101 is performed, for example, in compliance with the standard of Bluetooth (registered trademark).

[0135] In addition, the left controller 3 is provided with, for example, a memory 102 such as a flash memory. The communication control section 101 is constituted by, for example, a microcomputer (also referred to as a microprocessor), and performs various processes by executing firmware stored in the memory 102.

[0136] The left controller 3 is provided with each button 103 (specifically, buttons 33 to 39, 43, 44, and 47). In addition, the left controller 3 is provided with a left joystick 32. Each button 103 and the left joystick 32 repeatedly output information about an operation performed on itself to the communication control section 101 at an appropriate timing.

[0137] The left controller 3 is provided with an inertial sensor. Specifically, the left controller 3 is provided with an acceleration sensor 104. In addition, the left controller 3 is provided with an angular velocity sensor 105. In the present embodiment, the acceleration sensor 104 detects the magnitude of acceleration in the direction of each of three prescribed axes (for example, the xyz axes shown in the drawing). In addition, the acceleration sensor 104 can also detect acceleration in the direction of one axis or in the direction of two axes. In the present embodiment, the angular velocity sensor 105 detects angular velocity around each of three prescribed axes (for example, the xyz axes shown in the drawing). In addition, the angular velocity sensor 105 can also detect angular velocity around one axis or around two axes. The acceleration sensor 104 and the angular velocity sensor 105 are each connected to the communication control section 101. Furthermore, the detection results of the acceleration sensor 104 and the angular velocity sensor 105 are repeatedly output to the communication control section 101 at an appropriate timing. Figure 4 Figure 4 The communication control section 101 acquires information about input (specifically, information about an operation or a detection result of a sensor) from each input section (specifically, each button 103, the left joystick 32, each sensor 104 and 105). The communication control section 101 transmits operation data containing the acquired information (or information obtained by performing prescribed processing on the acquired information) to the main body device 2. In addition, the operation data is repeatedly transmitted at a rate of once every prescribed time. In addition, the interval at which information about input is transmitted to the main body device 2 can be the same or different among the input sections.

[0138] By transmitting the above-described operation data to the main body device 2, the main body device 2 can know the input performed on the left controller 3. That is, the main body device 2 can determine the operation of each button 103 and the left joystick 32 based on the operation data. In addition, the main body device 2 can calculate information about the activity 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).

[0139] By transmitting the above-described operation data to the main body device 2, the main body device 2 can know the input performed on the left controller 3. That is, the main body device 2 can determine the operation of each button 103 and the left joystick 32 based on the operation data. In addition, the main body device 2 can calculate information about the activity 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).

[0140] ​The left controller 3 has an oscillator 107 for notifying the user by vibration. In the present embodiment, the oscillator 107 is controlled in accordance with an instruction from the main body device 2. That is, the communication control section 101 drives the oscillator 107 in accordance with the instruction when receiving the instruction from the main body device 2. Here, the left controller 3 has a codec section 106. The communication control section 101 outputs a control signal corresponding to the instruction to the codec section 106 when receiving the instruction. The codec section 106 generates a drive signal for driving the oscillator 107 in accordance with the control signal from the communication control section 101 and supplies the drive signal to the oscillator 107. The oscillator 107 thus operates.

[0141] More specifically, the oscillator 107 is a linear vibration motor. The linear vibration motor, unlike a general motor that performs a rotational motion, is driven in a prescribed direction in accordance with an input voltage, and thus can vibrate at an amplitude and a frequency corresponding to a waveform of the input voltage. In the present embodiment, a vibration control signal transmitted from the main body device 2 to the left controller 3 can be a digital signal indicating a frequency and an amplitude per unit time. In another embodiment, information indicating a waveform itself can be transmitted from the main body device 2, but the communication data amount can be reduced by transmitting only the amplitude and the frequency. Further, in order to further reduce the data amount, a difference from a previous value can be transmitted instead of a value of the amplitude and the frequency at that time. In this case, the codec section 106 converts a digital signal indicating the values of the amplitude and the frequency acquired from the communication control section 101 into a waveform of an analog voltage, and drives the oscillator 107 in accordance with the waveform input voltage. Thus, the main body device 2 can control the amplitude and the frequency at which the oscillator 107 vibrates at that time by changing the amplitude and the frequency transmitted per unit time. Further, the number of amplitudes and frequencies transmitted from the main body device 2 to the left controller 3 is not limited to one, and two or more can be transmitted. In this case, the codec section 106 can generate a waveform of a voltage for controlling the oscillator 107 by synthesizing waveforms respectively indicated by the received plurality of amplitudes and frequencies.

[0142] The left controller 3 has a power supply section 108. In the present embodiment, the power supply section 108 has a battery and a power control circuit. Although not illustrated, the power control circuit is connected to the battery and to each section of the left controller 3 (specifically, each section that receives supply of power from the battery).

[0143] As Figure 7As shown, the right controller 4 includes a communication control unit 111 for communicating with the main unit 2. Additionally, the right controller 4 includes a memory 112 connected to the communication control unit 111. The communication control unit 111 is connected to various components, including a terminal 64. The communication control unit 111 and the memory 112 have the same functions as the communication control unit 101 and the memory 102 of the left controller 3. Therefore, the communication control unit 111 can communicate with the main unit 2 through both wired communication via the terminal 64 and wireless communication without the terminal 64 (specifically, communication conforming to the Bluetooth standard), controlling the communication method of the right controller 4 with the main unit 2.

[0144] The right controller 4 has the same inputs as the left controller 3. Specifically, it has buttons 113, a right joystick 52, and inertial sensors (accelerometer 114 and angular velocity sensor 115). These inputs have the same functions as the inputs of the left controller 3 and operate in the same manner.

[0145] Furthermore, the right controller 4 includes an oscillator 117 and an encoding / decoding unit 116. The oscillator 117 and the encoding / decoding unit 116 operate in the same manner as the oscillator 107 and the encoding / decoding unit 106 of the left controller 3. That is, the communication control unit 111 uses the encoding / decoding unit 116 to operate the oscillator 117 according to the instructions from the main unit 2.

[0146] The right controller 4 has a power supply unit 118. The power supply unit 118 has the same function as the power supply unit 108 of the left controller 3 and operates in the same way.

[0147] Furthermore, the controller is not limited to using the left controller 3 and right controller 4 as described above; for example, it can also use... Figure 8 The controller shown. Figure 8 The controller shown is one of the peripheral devices, and it is configured to integrate the right controller 4 and the left controller 3 (hereinafter referred to as the third controller). Therefore, its operating unit and functions are the same as those of the controllers mentioned above. Specifically, Figure 8The third controller has the same left stick 32, right direction button 33, down direction button 34, up direction button 35, left direction button 36, recording button 37, - button 47, and first L button 38 on the substantially left half of the housing thereof as the left controller 3. In addition, although not illustrated, the third controller has the same ZL button 39 as the left controller 3. In addition, the third controller has the same right stick 52, A button 53, B button 54, X button 55, Y button 56, + button 57, Home button 58, and first R button 60 on the substantially right half thereof as the right controller 4. In addition, although not illustrated, the third controller has the same ZR button 61 as the right controller 4.

[0148] In addition, Figure 9 A block diagram showing an example of the internal structure of the third controller is shown in FIG. 10. As with the above-described controllers, the third controller has a communication control section 101 that communicates with the main body device 2, the terminal 42, a memory 102, the above-described buttons 123, the left stick 32, the right stick 52, and a power supply section 108. The structures are the same as those used in the above-described controllers, and thus the descriptions thereof are omitted here. Figure 7 The structures are the same as those described above, and thus the descriptions thereof are omitted here.

[0149] [Outline of game processing in the first embodiment]

[0150] Next, an outline of the game processing performed by the game system 1 according to the first embodiment will be described. As described above, in the game system 1, the left controller 3 and the right controller 4 are configured to be detachable with respect to the main body device 2. When the game is played in a state in which the left controller 3 and the right controller 4 are attached to the main body device 2, the game image is output to the display 12. In addition, in a case in which the main body device 2 alone in a state in which the left controller 3 and the right controller 4 are detached is attached to the cradle, the main body device 2 can also output the game image to a stationary monitor or the like via the cradle. In the first embodiment, a case in which the game is played in the latter manner will be mainly described as an example. Specifically, a case in which the main body device 2 alone in a state in which the left controller 3 and the right controller 4 are detached is attached to the cradle, and the main body device 2 outputs the game image or the like to a stationary monitor or the like via the cradle. Of course, the same game processing can be performed in a case in which the game is played in the former manner, or in a case in which the game is played using the above-described third controller.

[0151] In addition, in the following description, the left controller 3 and the right controller 4 will be sometimes collectively referred to as simply "controllers".

[0152] [About the game to be assumed]

[0153] Next, the game assumed in the first embodiment will be described. The game involved in the first embodiment is a game of capturing a field character (hereinafter referred to as FC) on a field in a virtual space (hereinafter referred to as field) into a state of being possessed by a player character (hereinafter referred to as PC). More specifically, in the first embodiment, a determination of success or failure of capture is made by throwing a capture prop toward the FC by the PC, and if successful, the FC can be captured. In the first embodiment, the processing associated with the above capture will be mainly described.

[0154] Next, the outline of the processing associated with the above capture in the first embodiment will be described using screen examples. Figure 10 is an example of a game image of the game. In Figure 10 , a third-person point of view display of a three-dimensional virtual space is observed from a viewpoint behind the PC. Further, a virtual camera is basically controlled to move in a manner of following the PC. In Figure 10 , the PC, FC, and a possessed character bar 201 are displayed. Further, Figure 10 , the FC is in a "non-battle state" described later. The FC can be changed from the "non-battle state" to a state such as "battle state" or "chance state", the details of which will be described later. In addition, the possessed character bar 201 displays a character possessed by the PC at the time point (hereinafter referred to as possessed character), and in Figure 10 , it is shown that the PC possesses three possessed characters.

[0155] Here, the movement operation and the camera operation in the game will be briefly described. In the game, the player can move the PC in a desired direction on the field in the virtual space by operating the left stick 32. In addition, the player can change the orientation of the virtual camera by operating the right stick 52.

[0156] Next, an operation example associated with the above capture will be described using screen examples. In the game, the FC can be attempted to be captured by throwing the above capture prop toward the FC. A specific operation example will be shown, in Figure 10 , when the player presses the ZR button 61 (hereinafter referred to as posing operation), the PC becomes a "posing state" for throwing the capture prop 202 as shown in Figure 12 . In Figure 12 , the state in which the PC holds the spherical capture prop 202 in the right hand and raises the right arm is shown. Hereinafter, this state will be referred to as "posing state". The "posing state" is basically continued during the period when the ZR button 61 is continuously pressed. Further, the state of the PC which is not the "posing state" (the state described above Figure 10 ) will be referred to as "normal state" hereinafter.

[0157] In addition, when the PC becomes the posing state, the virtual camera is controlled to move in a manner of following the PC as described above Figure 11A reticle 203 is also displayed in the center of the screen as shown. This reticle 203 is used to show the direction (or the place) in which the capturing item 202 is thrown. When the player stops pressing the ZR button 61 (removes the finger from the ZR button 61) in this stance state, the PC performs an action of throwing the capturing item with the reticle 203 as a target (hereinafter referred to as a capturing action).

[0158] In addition, when the PC is moved in the state described above Figure 11 , the "side movement" in which the PC is moved left and right without changing the orientation of the PC. In this case, the PC is moved left and right in a state in which the reticle 203 is always displayed in the center of the screen. Figure 12 An example of a state in which the PC is slightly moved to the right from the state described above Figure 11 is shown. In addition, the capturing item 202 is thrown toward the reticle 203, and thus it is also possible to throw the capturing item 202 toward an object other than the FC, for example.

[0159] [Regarding lock-on]

[0160] Here, the lock-on function of the reticle 203 described above is supplemented. In this game, for example, by pressing the ZL button 39 by the PC in the stance state as shown in the above Figure 12 , it is possible to fix the reticle 203 to the nearest FC and perform lock-on as shown in the above Figure 13 . In addition, when the lock-on is performed, the display mode of the reticle 203 also slightly changes so that it is possible to grasp that the lock-on is performed. In addition, when the lock-on is performed, the object to which the lock-on is performed is displayed in a manner in which it is located in the center of the screen (that is, the state in which the reticle 203 is maintained in the center of the screen). Furthermore, when the capturing item 202 is thrown in the state in which the lock-on is performed, the capturing item 202 is thrown with the FC to which the lock-on is performed as a target. In addition, the lock-on is released by removing the finger from the ZL button 39 (hereinafter referred to as a lock-off operation). In addition, when there is another FC within a prescribed range in the state in which the lock-on is performed, it is possible to switch the lock-on object to the other FC by operating the right stick 52. In other words, in the state in which the lock-on is performed, it is not possible to change the orientation of the virtual camera using the right stick 52.

[0161] In addition, when the PC is moved in the state in which the lock-on is performed, since the reticle 203 is fixed to the FC, the movement control is performed in a manner in which the reticle 203 and the FC to which the lock-on is performed are always displayed in the center of the screen. That is, the movement control (and the virtual camera control) is performed while the orientation of the PC (the orientation of the virtual camera) is always oriented in the direction of the FC to which the lock-on is performed.

[0162] [Regarding the capturing action]

[0163] Next, the above-mentioned capturing action is explained in more detail. As explained above, by the player stopping pressing the ZR button 61 in the posing state, the capturing item 202 is thrown toward the reticle as shown in Figure 14 . Hereinafter, the state from the start of the activity of throwing the capturing item by the PC until the determination result of the capturing comes out is called the capturing action state. That is, by the player stopping pressing the ZR button 61, the PC shifts from the posing state to the capturing action state. Further, after the determination result of the capturing comes out, the PC shifts to the normal state. Furthermore, Figure 14 , an example in which the capturing item 202 is thrown in the state in which the lock is open is shown. Therefore, the capturing item 202 moves toward the FC to which the open lock is applied. As a result thereof, the capturing item 202 hits the FC as shown in Figure 15 . Further, as to the hit here, it can be that, in addition to the case in which the capturing item 202 collides with the FC, in the case where the position relationship becomes such that although strictly speaking there is no collision, there is a slight deviation, it is also treated as having hit. When the capturing item 202 hits the FC, the determination of whether or not the capturing is successful (hereinafter, called the capturing determination) is performed. In this example, a capturing success rate is set in advance for each FC, and by performing a lottery using the capturing success rate, whether or not the capturing is successful is determined. Further, the capturing success rate can be adjusted according to the situation, and the details are described later. In the case where the result of the capturing determination is that the capturing is successful, an animation in which the FC disappears from the field (hereinafter, called the disappearance animation) is displayed as shown in Figure 16 , and then a capturing animation as shown in Figure 17-18 is displayed. In the capturing animation shown in Figure 17 , an animation in which a spherical object (showing that the FC is housed in the thrown capturing item 202) flies toward the owning character column 201 is displayed. Then, as shown in Figure 18 , a display in which the FC of this capturing is added to the owning character column 201 is performed. In the example shown in Figure 18 , the FC of this capturing is shown as the fourth owning character.

[0164] On the other hand, in the case where the result of the above-mentioned capturing determination is that the capturing is failed, the state of the FC shifts from the "non-battle state" to the "battle state". The FC in the "battle state" attacks the PC or the battle character (hereinafter, called the BC) explained later.

[0165] Moreover, in the first embodiment, the number of the above-mentioned capture tools 202 held is limited. Also, it is provided that one capture tool 202 is consumed regardless of success or failure of the above-mentioned capturing action when the capturing action is performed once. In addition, in the first embodiment, one kind of capture tool 202 is provided, but in other embodiments, there can be a plurality of capture tools 202 having different performances. For example, there can be a high-performance capture tool 202 having a 10% higher success rate in addition to the usual capture tool 202. Also, it can be that the kind of capture tool 202 to be used can be designated when the above-mentioned posing state is entered. In addition, for example, it can be that the kind of capture tool 202 to be used can be designated by operating the right direction button 33 or the left direction button 36 while in the posing state.

[0166] In addition, with respect to the above-mentioned posing state, in addition to being able to be released by stopping pressing the ZR button 61, it can also be released by pressing the B button 54 while the ZR button 61 is being pressed (hereinafter referred to as a posing release operation).

[0167] [About the Battle]

[0168] Next, the battle element with the FC and the above-mentioned capturing will be described. In the present game, the PC cannot directly attack the FC. In order to battle with the FC, the above-mentioned BC needs to be used. Specifically, the BC needs to be caused to appear on the field by a prescribed operation and to battle with the FC. Here, in the present game, in the case of battling with the FC, the screen is not switched to another battle screen, but the battle with the FC is seamlessly started by satisfying a battle start condition. In addition, the BC and the FC perform attack actions in parallel based on the player's instruction and a prescribed algorithm, respectively, so that a real-time battle is performed. The battle start condition is the case where the capturing action has failed in the above-mentioned "non-battle state", the case where the FC has noticed the PC or the BC as described below, and the case where the FC has been attacked by the BC without noticing as described below.

[0169] Before describing the battle element, the BC will first be described. In the present game, one of the owning characters of the PC in a state in which it can battle is selected and caused to appear on the field as the above-mentioned BC. Hereinafter, the operation of causing the BC to appear on the field will be referred to as a "BC appearance operation".

[0170] Figure 19-21 Figures showing examples of the screen when the BC appearance operation is performed (examples of appearance performance) are shown in Figs. 17A to 17C. These screen examples are examples in the case where the PC is in the above-mentioned "non-battle state" and the above-mentioned "posing state". Figure 12In the indicated position, the player selects their desired character through a pre-defined action and performs the BC (Breakfast / Card) entry action. In this situation, the selected character enters as BC at a designated position, for example, diagonally to the right and in front of the PC (Player / PC). Figure 19-21 In the performance shown, firstly, as Figure 19 In this way, the ball containing the character to be played as BC (hereinafter referred to as the BC ball) is thrown in the designated direction. Then, as... Figure 20 That way, the landing point of the BC ball displays a smoke-like performance. Then, as... Figure 21 As shown, the selected character enters the battle as the BC (Battle Royale). Furthermore, the BC can perform any animation during its entrance animation. For example, the BC can perform a roaring action after entering the battle. Specifically, it's also possible to perform the roaring action while the character is in battle, before it becomes targetable, thus setting a waiting period before it becomes targetable to prevent the BC's transition from being too advantageous. Additionally, the player can specify the BC's entrance position and the direction in which the BC ball is thrown. For example, a cursor that can move within a specified range centered on the PC to indicate the entrance position can be displayed, and the player can manipulate this cursor. Moreover, the PC can throw the BC ball with the cursor's direction or location as the target.

[0171] In addition, with the appearance of BC, such as Figure 21As shown, a BC information bar 204, an attack option bar 205, and an energy bar 208 are added to the screen. The BC information bar 204 displays the face of the BC and a health bar representing the BC's stamina. The attack option bar 205 is a set of four diamond-shaped images showing the attack methods the BC can perform. The player can use the attack option bar 205 as a reference to issue attack commands to the BC. Specifically, in this game, each BC (FC) has a maximum of four attack methods. The attack option bar 205 is the portion displayed by assigning these four attack methods to any of the controller's A button 53, B button 54, X button 55, and Y button 56 (hereinafter collectively referred to as the ABXY buttons). The four diamond-shaped images are arranged to mimic the configuration of the ABXY buttons, making it easy to intuitively understand which attack method corresponds to which button. Therefore, by pressing any of the ABXY buttons, the player can cause the BC to perform an attack using the attack method corresponding to that button. This attack can change the state of the FC. Examples of various attack methods include: attacks that reduce the FC's health, attacks that inflict status ailments on the FC, and attacks that weaken the FC (debuffs). Furthermore, actions that do not directly affect the FC, such as restoring one's own health or applying a so-called "buff," are also included in these attack methods. Through such attacks, the FC's health is reduced or a status ailment is inflicted, thereby increasing the FC's capture success rate. Therefore, compared to attempting capture without having the BC appear, as described above, attempting capture after having the BC attack the FC to reduce its health allows for a capture decision based on a higher capture success rate (however, a lower rate than in the chance state described later). Additionally, the energy gauge 208 accumulates a predetermined amount each time an attack is indicated to the BC; by consuming the predetermined amount of accumulated energy, the BC can perform a more powerful attack.

[0172] As described above, the BC (Breakfast) can act autonomously to some extent based on a prescribed algorithm. For example, if there are no FCs (Functional Fighters) around, the BC will follow the PC (Player PC). Conversely, if there are FCs around the BC, the BC will gradually move closer to those FCs. Furthermore, the player can instruct the BC to act.

[0173] Figure 22The following situation is illustrated: the result of the player's instruction or BC's autonomous action is that BC moves closer to FC to a certain extent. In other words, the following situation is illustrated: the positional relationship between FC and BC satisfies a specified condition, which in this case is a certain distance. Let's assume that in this situation, FC "notices" the presence of BC and processes the action. As a result, FC transitions from a "non-combat state" to a "combat state," as shown... Figure 23 As shown, an attack is initiated against BC. Furthermore, a health bar representing the FC's health is displayed above the FC's head when it enters "battle mode". Additionally, not only when BC approaches the FC, but also when PC approaches the FC, the FC will notice PC and enter "battle mode".

[0174] then, Figure 24 The image shows an example of a player instructing BC to attack by pressing the X button (55). Figure 24 The following situation is shown: Based on the player's attack instruction, BC is attacking FC using the "Attack 1" attack method assigned to button X 55. It is also shown that if the attack hits, the damage corresponding to the attack method is inflicted on FC, and FC's health is reduced.

[0175] [Regarding charging time]

[0176] In this game, each attack method has a "charging time." When an attack method is used, it is unusable until the charging time has elapsed. After the charging time, it becomes usable. In other words, for a given attack method, the period while it is charging is the attack standby state, and the period when it is not charging is the attackable state. For example, if the player issues an attack command to use the attack method corresponding to button A 53, and if the method is charging, the player must wait for the charging time to become attackable before pressing button A 53. Therefore, in this game, it is not possible to continuously use the same attack method. This is also the case in the attack action control of the FC (Famicom). Furthermore, while charging, for example... Figure 24 As shown, for the diamond-shaped image corresponding to the attack method used above, the performance of the charge meter gradually accumulating from bottom to top is displayed.

[0177] [Regarding the state of opportunity]

[0178] If, as described above, the result of BC attacking FC is that the final FC's HP reaches 0, then the FC is considered defeated, and it transitions from "Battle State" to "Opportunity State." This "Opportunity State" lasts for a certain period. In the "Opportunity State," the FC becomes unable to act (neither movement nor attack can be performed). Additionally, the "Opportunity State" has a higher capture success rate than in a non-Opportunity State (e.g., the default success rate). When transitioning to the "Opportunity State," as... Figure 25 As shown, this depicts a "capture opportunity performance" where the star marker revolves around the FC. This shows the FC in a state of neither moving nor attacking, and in a state of semi-consciousness. In this "opportunity state," by... Figure 26 By inducing the PC to perform a capture action as shown, a capture attempt can be made with a higher success rate than in the "non-combat state" described above. Furthermore, a capture attempt can be made with a higher success rate than in the "combat state." As a result, if the capture is successful, it can be performed as follows: Figure 27 After capturing the scene as shown above, add the FC to the character that owns it.

[0179] Additionally, during the "Chance State," the player can make the PC perform any number of capture attempts. Therefore, even if the first capture attempt fails during the "Chance State," the PC can still attempt a second capture attempt.

[0180] On the other hand, the "chance state" ends when the aforementioned period has elapsed while the capture attempt remains unsuccessful or no capture action has been taken at all. In this case, such as... Figure 28 As shown, the above-mentioned elimination performance is displayed, and the FC is eliminated from the field, becoming a state that no longer exists on the field.

[0181] Furthermore, it's possible to issue an attack command to BC without FC's notice, thus provoking an attack or attempting a capture. For example, it's possible to approach FC from behind and launch a preemptive attack without FC noticing. In this case, the aforementioned battle start conditions are also met, and FC (if stamina remains) transitions from "non-combat state" to "combat state." Additionally, if FC's stamina reaches 0 after a preemptive attack, it directly transitions from "non-combat state" to "opportunity state." Alternatively, when approaching FC from behind and performing a capture from behind without FC noticing, the success rate of the capture judgment is higher than when FC notices.

[0182] Alternatively, when throwing the aforementioned BC ball to bring BC into play, the position of the FC (FC in a non-combat state) can also be designated as the landing point of the BC ball. That is, the PC throws the BC ball towards the FC. In this case, if the BC ball hits the FC, it is considered that the FC has been provoked by BC, causing the FC to enter a "combat state." Furthermore, even if the ball misses, the FC will still enter a "combat state" because the BC ball's presence near the FC will alert the FC to its presence.

[0183] Additionally, in this game, such as Figure 29 As shown, the capture action can also be initiated against an FC in "battle mode". In this case, the capture success rate is adjusted based on the FC's remaining stamina. Specifically, it is adjusted so that the lower the stamina, the higher the success rate.

[0184] Thus, in the first embodiment, it is possible to directly attempt to capture an FC (Final Fighter) in a non-combat state. Furthermore, it is also possible to attempt to capture an FC in a state where the capture success rate is further increased by provoking a battle and defeating it. Moreover, capture attempts can be made even while the FC is in battle. Therefore, the game involved in the first embodiment is a game that provides capture opportunities in diverse scenarios.

[0185] [Details of the game processing in the first embodiment]

[0186] Next, refer to Figure 30-48 The game processing in the first embodiment will be described in more detail below. Here, the processing related to capture will be described in detail, and details of other game processing will be omitted.

[0187] [Regarding Data Usage]

[0188] First, let me explain the various data used in the processing of this game. Figure 30 This is a memory layout diagram showing an example of various data stored in the DRAM 85 of the main unit 2. The DRAM 85 of the main unit 2 stores 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 unlock object data 320, capture candidate data 321, lock unlock flag 322, appearance scene flag 323, etc.

[0189] Game program 301 is a program for performing the game processing in the first embodiment.

[0190] PC data 302 is data related to the aforementioned PC. PC data 302 includes current position / pose data 303, PC status data 304, etc. In addition, although the illustration is omitted, PC data 302 also includes various data required for game processing, such as data representing the appearance of the PC (polygon data, etc.) and data on various activities performed by the PC (animation data).

[0191] Current position / pose data 303 represents the current position and pose of the PC on the field. Additionally, PC state data 304 represents the current state of the PC. Specifically, PC state data 304 contains information indicating one of the following: "normal state," "pose state," or "capture behavior state."

[0192] The capture item data 305 is data related to the aforementioned capture item 202. The capture item data 305 includes movement trajectory data 306, current position data 307, etc. Movement trajectory data 306 represents the movement path of the capture item 202 calculated based on the position of the crosshair 203. Current position data 307 represents the current position of the capture item 202. In addition, the capture item data 305 also includes data such as the appearance of the capture item 202.

[0193] Character Master Data 309 is the master data defined for characters appearing in this game other than those on PC (FC, BC). Figure 31 This diagram illustrates an example of the structure of character master data 309. Character master data 309 is a database consisting of a collection of records containing at least the following items: Character ID 331, Character Appearance Data 332, Performance Data 333, Initial Success Rate 334, and Action Algorithm 335. Character ID 331 is an ID used to identify each character. Character Appearance Data 332 is data representing the character's appearance. Performance Data 333 defines the character's performance and initial status. For example, it defines stamina and available attack methods. Initial Success Rate 334 represents the character's default capture success rate. Action Algorithm 335 defines the character's action algorithm. Action algorithms are defined separately for the case where the character is an FC (Final Fantasy) and the case where the character is a BC (Best-Cut). In addition, although the diagram is omitted, it also includes various data required for game processing. For example, it also includes animation data representing the aforementioned attack actions.

[0194] Return to Figure 30 The character data 310 represents the characters owned by the PC (that is, the captured characters). Figure 32The diagram illustrates an example of the data structure for the ownership role data 310. The ownership role data 310 is a database consisting of a set of records that have at least a role category 342 and a unique ownership ID 341 identifying the ownership role. The role category 342 is set to one of the aforementioned role IDs 331. Here, in the first embodiment, multiple roles of the same type (roles with the same ID in terms of role ID 331) can appear as different individuals' FCs. Furthermore, it is also possible to own roles of the same type as ownership roles. In this case, different ownership IDs 341 are assigned to these roles of the same type to manage them as ownership roles of different individuals.

[0195] Return to Figure 30 BC Management Data 311 is used to manage the aforementioned BCs. BC Management Data 311 includes BCID 312, BC Status Data 313, BC Position / Posture Data 314, BC Current Status 315, Attack Target Data 316, and Specified Attack Method Data 317, etc. Furthermore, the initial value of BC Management Data 311 is empty, indicating that a BC does not exist (has not appeared).

[0196] BC ID 312 is set to the aforementioned owner ID 341 corresponding to the character currently appearing as BC. BC Status Data 313 is data indicating the current state of BC. BC states include, for example, "non-combat state" and "combat state." BC Position / Posture Data 314 is data indicating the current position and posture of BC. BC Status Status 315 is data indicating the current health value of BC, etc. Attack Target Data 316 is data used to determine the opponent's FC (Fist of the Fury) that BC attacks. Designated Attack Method Data 317 is data indicating the current attack method designated according to the player's instructions. This data is used for calculating damage inflicted on the FC, etc.

[0197] Next, FC management data 318 is the data used to manage the FC. Figure 33The diagram shows an example of the data structure of FC management data 318. FC management data 318 is a database consisting of a set of records containing at least the following items: FC ID 351, FC type 352, FC appearance status 353, FC current location 354, FC current state 355, FC status 356, and FC attack flag 357. FC ID 351 is an ID used to uniquely identify each individual FC present on the field. FC type 352 is an ID used to determine the type of role of each FC, and is set to one of the role IDs 331 mentioned above. FC appearance status 353 is data indicating whether the FC is currently present on the field (configured on the field). For example, it is set to "yes" if it is present on the field, and set to "no" if it is not present. FC current location 354 is data indicating the current location of the FC on the field. FC current state 355 is data indicating which of the above-mentioned states—"non-combat state," "combat state," and "opportunity state"—the FC is in. FC Status 356 displays data such as the current health value of each FC. FC Attack Flag 357 indicates whether the FC is currently performing an attack action (reproduction of an attack activity). In addition, although illustrations are omitted, various data required for managing FCs during game processing are also included in FC Management Data 318.

[0198] Return to Figure 30 Next, operation data 319 represents the various operations performed on the controller. This includes data indicating the pressed state of each button on the controller and the input state of each joystick.

[0199] Locked Open Object Data 320 is data used to determine the FC that is set as a locked open object.

[0200] Capture candidate data 321 is data used to determine the FC (hereinafter referred to as capture candidate) of the object to be captured successfully.

[0201] The lock-on flag 322 is a flag used to indicate whether the lock is on. When on, it indicates that the specified FC has been locked.

[0202] The performance entry sign 323 indicates whether the person is in one of the aforementioned performances.

[0203] In addition, although the illustration is omitted, various data required for game processing are also stored in DRAM 85. For example, data such as the current meter value used to manage the aforementioned energy meter 208 may also be stored.

[0204] [Details of the processing performed by processor 81]

[0205] Next, the details of the game processing in the first embodiment will be explained. Furthermore, the flowchart shown below is merely one example of the processing procedure. Therefore, the order of the steps can be reversed as long as the same result can be obtained. Additionally, the values ​​of the variables and the thresholds used in the decision-making step are also just examples; other values ​​can be used as needed.

[0206] Figure 34 This is a flowchart illustrating the details of the game processing involved in the first embodiment. The frame rate is adjusted accordingly during a 1-second interval. Figure 34 The processing loops involved in steps S1 to S8 are repeatedly executed a predetermined number of times. Furthermore, it is assumed that the initialization of various data and the configuration of various FCs and PCs on the field have been completed before this processing begins.

[0207] exist Figure 34 First, in step S1, the processor 81 acquires operation data 319.

[0208] Next, in step S2, processor 81 performs PC control processing. Figure 35 This is a flowchart illustrating the details of the PC control process. Figure 35 In step S11, the processor 81 first determines whether the PC is in a capture state based on the PC status data 304. If the result of this determination is that the PC is not in a capture state ("No" in step S11), in step S12, the processor 81 determines whether a movement operation (operation of the left joystick 32) has been performed based on the operation data 319. If the result of this determination is that a movement operation has been performed ("Yes" in step S12), then in step S13, the processor 81 executes movement control processing.

[0209] Figure 36 This is a flowchart illustrating the details of the aforementioned motion control process. Figure 36 In the process, firstly, in step S31, the processor 81 determines whether the PC is in a posing state based on the PC state data 304. If the result of this determination is that the PC is not in a posing state ("No" in step S31), in step S32, the processor 81 performs movement control on the PC based on the operation content. On the other hand, if the PC is in a posing state ("Yes" in step S31), in step S33, the processor 81 determines whether the specified FC is locked and unlocked based on the lock unlock flag 322. If the result of this determination is that the lock is unlocked ("Yes" in step S33), in step S35, the processor 81 performs movement control on the PC based on the operation data 319 while orienting the PC toward the lock unlocked object. After that, the processor 81 ends the movement control process.

[0210] On the other hand, if the result of the determination in step S33 is that the lock is not open ("No" in step S33), in step S37, the processor 81 moves the PC based on the operation data 319. As an example, the processor 81 can also control the movement of the PC by causing it to move sideways as described above. After that, the processor 81 ends the movement control process.

[0211] Return to Figure 35 If the result of the determination in step S12 is that no move operation was performed ("No" in step S12), then in step S14, the processor 81 determines whether a factory association operation has been performed based on the operation data 319. Here, the factory association operation is assumed to be either the BC factory operation or the operation of deactivating the BC's factory state (return operation). If either of these operations has been performed ("Yes" in step S14), then in step S15, the processor 81 executes factory control processing.

[0212] Figure 37 This is a flowchart illustrating the details of the above-described exit control process. First, in step S41, the processor 81 determines whether the operation is a BC exit operation or a return operation based on the operation data 319. If the result of this determination is a BC exit operation ("Yes" in step S41), in step S42, the processor 81 sets the owner role selected during the BC exit operation to BC. For example, it is also possible that a cursor that can be moved left and right using the right direction button 33 and the left direction button 36 is pre-set in the owner role column 201, and the owner role where the cursor is located during the BC exit operation is selected and set to BC. Specifically, the processor 81 sets the BC management data 311 based on data related to the selected owner role. In addition, the position for BC exit and the trajectory of the BC ball are also determined.

[0213] Next, in step S43, the processor 81 activates the entrance performance flag 323. In the following step S44, the processor 81 begins the process described above. Figure 19-21 The exit sequence is shown. In this sequence, a sequence is displayed where ball BC exits after it has moved along the trajectory determined above. Afterwards, processor 81 terminates the exit control process.

[0214] On the other hand, if the result of the determination in step S41 is that the operation content is a return operation ("No" in step S41), in step S45, the processor 81 initializes the BC management data 311. As a result, the BC is removed from the field. Furthermore, the processor 81 begins the prescribed process of removing the BC from the field. Afterwards, the processor 81 ends the field control process.

[0215] Return to Figure 35 If the result of the determination in step S14 is that no exit association operation was performed (the result in step S14 is "No"), then in step S16, the processor 81 performs the pose association processing.

[0216] Figure 38 This is a flowchart illustrating the details of the pose association process described above. First, in step S51, the processor 81 determines whether the PC is in a pose state based on the PC status data 304. If the result of this determination is that the PC is not in a pose state ("No" in step S51), in step S52, the processor 81 determines whether the pose operation described above has been performed. That is, it determines whether an operation to change the ZR button 61 from the off state to the on state has been performed based on the operation data 319. If the result of this determination is that a pose operation has been performed ("Yes" in step S52), in step S53, the processor 81 sets the PC status data 304 to "pose state". Next, in step S54, the processor 81 configures the crosshair 203 so that it is displayed in the center of the screen. After that, the processor 81 ends the pose association process.

[0217] On the other hand, if the result of the determination in step S52 is that no posing operation was performed ("No" in step S52), the processing involved in steps S53 to S54 is skipped.

[0218] On the other hand, if the result of the determination in step S51 is that the PC is in a posing state (yes in step S51), in step S55, the processor 81 determines, based on the operation data 319, whether an operation has been performed to change the ZR button 61 from the on state to the off state. That is, it determines whether the finger has been removed from the continuously pressed ZR button 61. If the result of this determination is that the finger has been removed from the ZR button 61 (yes in step S55), in step S56, the processor 81 sets the PC state data 304 to "capture behavior state". In addition, the processor 81 causes the PC to start performing actions related to the capture behavior, that is, causes the PC to start performing the actions described above. Figure 14 The activity of throwing the capture item 202 is shown. Next, in step S57, the processor 81 calculates the trajectory of the capture item 202 based on the position of the crosshair 203 at that time point and sets it to the movement trajectory data 306.

[0219] Next, in step S58, the processor 81 removes the crosshair 203 from the screen. After that, the processor 81 ends the pose association processing.

[0220] On the other hand, if the result of the determination in step S55 is that the finger has not yet left the ZR button 61 ("No" in step S55), in step S59, the processor 81 determines whether the above-mentioned pose release operation has been performed. If the result of this determination is that the pose release operation has been performed ("Yes" in step S59), in step S60, the processor 81 sets the PC status data 304 to "normal state". Then, the process proceeds to step S58.

[0221] On the other hand, if the result of the determination in step S59 is that no pose release operation is performed ("No" in step S59), in step S61, the processor 81 performs the lock release association processing.

[0222] Figure 39 This is a flowchart illustrating the details of the aforementioned lock unlocking association process. Figure 39 In step S71, the processor 81 first determines whether the current state is locked based on the lock-on flag 322. If the result of this determination is that the current state is not locked ("No" in step S71), then in step S72, the processor 81 determines whether the aforementioned lock-on operation has been performed based on the operation data 319. If the result of this determination is that the lock-on operation has been performed ("Yes" in step S72), then in step S73, the processor 81 sets the lock-on flag 322 to be enabled. Next, in step S74, the processor 81 determines the lock-on target and sets the lock-on target data 320. For example, the processor 81 sets the FC closest to the position of the crosshair 203 at this time as the lock-on target.

[0223] Next, in step S75, the processor 81 sets the position of the crosshair 203 to overlap with the FC (Front-up Controller) that is the target of lock-on. Then, the processor 81 sets the parameters of the virtual camera so that the crosshair 203 and the FC that has been locked are always displayed in the center of the screen. After that, the processor 81 ends the lock-on association process.

[0224] On the other hand, if no lock unlocking operation is performed ("No" in step S72), the above steps S73 to S75 are skipped.

[0225] On the other hand, if the result of the determination in step S71 is that the lock is open (yes in step S71), in step S76, the processor 81 determines whether the lock closing operation has been performed. If the result of this determination is that the lock closing operation has been performed (yes in step S76), in step S77, the processor 81 sets the lock opening flag 322 to off. After that, the processor 81 ends the lock opening association process.

[0226] On the other hand, if the result of the determination in step S76 is that no lock-off operation was performed ("No" in step S76), in step S78, the processor 81 determines whether a lock-on object switching operation was performed (in this example, an operation on the right joystick 52). If the result of this determination is that a lock-on object switching operation was performed ("Yes" in step S78), in step S79, the processor 81 changes the lock-on object based on the operation content and resets the content of the lock-on object data 320. Then, the process proceeds to step S75.

[0227] On the other hand, if no lock-on object switching operation is performed, the above step S79 is skipped, and the lock-on association process ends.

[0228] Return to Figure 38 If the locking and unlocking process ends, then the posing and unlocking process ends.

[0229] Return to Figure 35 Next, in step S17, the processor 81 determines whether an attack instruction operation targeting BC has been performed. That is, with BC in the active state, it determines whether any of the ABXY buttons has been pressed. If the result of this determination is that an attack instruction operation has been performed ("Yes" in step S17), in step S18, the processor 81 sets the designated attack method data 317 based on its operation content. Alternatively, at this time, it can also be set so that the FC that can be specified by the player as the attack target. In this case, the process of setting the designated FC in the attack target data 316 is also performed.

[0230] On the other hand, if no attack instruction operation is performed ("No" in step S17), the processing of step S18 above is skipped.

[0231] Next, in step S19, the processor 81 determines whether a virtual camera orientation change operation has been performed based on the operation data 319. That is, the processor 81 determines whether the right joystick 52 was operated while the PC was in its normal state. If this operation was performed ("Yes" in step S19), in step S20, the processor 81 changes the virtual camera parameters (virtual camera orientation) based on the operation content. On the other hand, if no virtual camera orientation change operation was performed ("No" in step S19), the above-mentioned step S20 is skipped. Afterwards, the processor 81 ends the PC control processing.

[0232] Next, we will explain the processing when the result of the determination in step S11 is that the PC is in a capture behavior state ("Yes" in step S11). In this case, in step S21, the processor 81 performs capture behavior processing.

[0233] Figure 40 This is a flowchart illustrating the details of the above-mentioned capture behavior processing. Figure 40 In step S81, the processor 81 first moves the capture tool 202 based on the aforementioned movement trajectory data 306. The current position data 307 is also updated accordingly. Furthermore, if the activity related to the PC's capture behavior has not ended at this time, that activity continues.

[0234] Next, in step S82, the processor 81 determines whether the capture item 202 has hit the FC. Regarding this hit determination, a hit is considered to have occurred if the capture item 202 collides with the FC. Alternatively, in other embodiments, a hit can be determined at the point in time when the positional relationship between the capture item 202 and the FC becomes close, even if there is only a slight deviation.

[0235] If the result of the above determination is that the capture tool 202 hits the FC (yes in step S82), in step S83, the processor 81 sets the hit FC as a capture candidate to the capture candidate data 321.

[0236] Next, in step S84, the processor 81 performs capture determination processing on the above-mentioned capture candidates as objects. Figure 41 This is a flowchart illustrating the details of the capture determination process. Figure 41 In step S91, the processor 81 refers to the role master data 309 to obtain the initial success rate 334 corresponding to the above-mentioned capture candidate.

[0237] Next, in step S92, the processor 81 determines whether the capture candidate is currently in an "opportunity state" based on the FC management data 318. If the determination result is that it is in an "opportunity state" ("yes" in step S92), in step S93, the processor 81 adjusts the capture success rate to be higher than the initial success rate 334 mentioned above. After that, the process proceeds to step S96, which will be described later.

[0238] On the other hand, if the target is not in an "opportunity state" ("No" in step S92), then in step S94, the processor 81 determines whether the target is in a "battle state". If the result of this determination is that the target is in a "battle state" ("Yes" in step S94), then in step S95, the processor 81 adjusts the capture success rate based on the target's current state, such as the target's remaining health points, and whether it has been given a status ailment. For example, the adjustment is made in such a way that the lower the health points, the higher the capture success rate compared to the initial success rate 334 mentioned above. After that, the process proceeds to step S96, which will be described later.

[0239] On the other hand, if the user is not in a "combat state" ("No" in step S94), the processing in step S95 above is skipped. In this case, the capture determination is performed in a "non-combat state" and the determination is made based on the initial success rate mentioned above.

[0240] Next, in step S96, the processor 81 uses the capture success rate adjusted by the above steps S92 to S95, or the capture success rate that is the same as the initial success rate 334, to determine whether the capture is successful or not.

[0241] Next, in step S97, the processor 81 determines whether the capture was successful. If the result of this determination is that the capture was successful ("Yes" in step S97), in step S98, the processor 81 removes the captured object from the field. Specifically, the processor 81 sets the FC occurrence status 353 of the capture candidate in the FC management data 318 to "No".

[0242] Next, in step S99, processor 81 performs the above-described steps. Figure 16-18 The settings shown are for displaying the elimination and capture of events.

[0243] Next, in step S100, the processor 81 adds the aforementioned capture candidates to the role-owning data 310. After that, the processor 81 ends the capture determination process.

[0244] On the other hand, if the result of the determination in step S97 is that the capture has failed ("No" in step S97), the processing in steps S98 to S100 is skipped and the capture determination process ends.

[0245] Return to Figure 40 Next, in step S85, processor 81 sets the PC status data 304 to "normal state". After that, processor 81 ends the capture behavior processing.

[0246] On the other hand, if the result of the determination in step S82 is that the capture item did not hit the FC (No in step S82), in step S86, the processor 81 determines whether the movement of the capture item 202 has ended. That is, it determines whether the capture item 202 fell to the ground without hitting the FC. If the result of this determination is that the movement has ended (Yes in step S86), the process proceeds to step S85. As a result, the result that the capture action ended without the capture item hitting the FC is determined. On the other hand, if the movement has not ended (No in step S86), the capture action process ends.

[0247] Return to Figure 35 If the capture behavior processing ends, the processor 81 terminates the PC control processing.

[0248] Return to Figure 34 Next, in step S3, processor 81 performs BC control processing. Figure 42-43 This is a flowchart illustrating the details of the BC control process. First, in step S111, the processor 81 determines whether a BC exists in the factory based on the BC management data 311. If the result of this determination is that no BC exists ("No" in step S111), the processor 81 ends the BC control process.

[0249] On the other hand, if a BC (Breakthrough Character) is in progress ("Yes" in step S111), in step S112, the processor 81 determines whether it is currently in a performance based on the performance exit flag 323. If it is in a performance exit ("Yes" in step S112), in step S113, the processor 81 continues the performance exit. Next, in step S114, the processor 81 determines whether the performance exit has ended. If it has ended ("Yes" in step S114), in step S115, the processor 81 sets the performance exit flag 323 to off. Then, the process proceeds to step S116.

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

[0251] On the other hand, if the result of the determination in step S112 is that the attack is not in the performance ("No" in step S112), in step S116, if there is an attack method that is currently charging among the attack methods possessed by BC, then the processor 81 enables the charging of the attack method to proceed.

[0252] Next, in step S117, the processor 81 determines whether an attack from any FC has hit the BC. If the result of this determination is a hit ("yes" in step S117), in step S118, the processor 81 calculates the damage value based on the attack method that resulted in the hit. Then, the BC status 315 is updated in such a way that the stamina value is reduced by an amount corresponding to the damage value.

[0253] On the other hand, if the attack from the FC fails (No in step S117), the processing in step S118 above is skipped.

[0254] Next, in step S119, processor 81 determines whether BC's stamina value is 0 based on BC's current status 315. If the result of this determination is 0 ("Yes" in step S119), in step S120, processor 81 executes a process to remove the BC from the field (returning it to the state of owning the character). Specifically, processor 81 begins a removal animation to remove BC from the field and initializes BC management data 311. Afterward, processor 81 ends the BC control process.

[0255] On the other hand, if the stamina value is not 0 ("No" in step S119), then, Figure 43 In step S121, the processor 81 determines whether BC is currently in an attack operation. That is, it determines whether an attack activity corresponding to the specified attack method is being reproduced. If the result of this determination is that an attack operation is in progress ("yes" in step S121), in step S122, the processor 81 causes BC to continue the attack operation. After that, the processor 81 ends the BC control process.

[0256] On the other hand, if no attack action is being performed ("No" in step S122), then in step S123, the processor 81 determines whether an attack instruction has been given based on the operation data 319. If the result of this determination is that no attack instruction has been given ("No" in step S123), then in step S124, the processor 81 controls the action of the BC based on the aforementioned action algorithm 335. For example, the following processes are performed: controlling the BC to follow the PC's movement, or setting the nearest FC to the attack target data 316. After that, the BC control process ends.

[0257] On the other hand, if an attack indication exists ("Yes" in step S123), in step S125, the processor 81 determines whether the specified attack method is charging. If it is charging ("Yes" in step S125), the processor 81 ends the BC control process. That is, even if the button corresponding to the charging attack method is pressed, the BC does nothing. On the other hand, if it is not charging ("No" in step S125), in step S126, the processor 81 sets information representing the specified attack method in the specified attack method data 317, causing the BC to start the attack action corresponding to the specified attack method. Additionally, at this time, the charging table associated with the attack method is set to empty, and charging begins. Afterwards, the processor 81 ends the BC control process.

[0258] Return to Figure 34 After the BC control processing, in step S4, the processor 81 executes the FC control processing. Figure 44 This is a flowchart illustrating the details of the FC control process. First, in step S131, the processor 81 selects one FC from those FCs whose FC occurrence status 353 in the FC management data 318 is "Yes" as the object of the process described below. This FC will be referred to as the processing object FC below.

[0259] Next, in step S132, the processor 81 determines whether the target FC is in a non-combat state based on the current state 355 of the FC. If the determination result is that it is in a non-combat state ("yes" in step S132), the processor 81 performs non-combat state processing in step S133. After that, the processing proceeds to step S137, which will be described later.

[0260] Figure 45 This is a flowchart illustrating the details of the above-described non-combat state processing. First, in step S141, the processor 81 performs movement control on the processing object FC based on the above-described action algorithm 335.

[0261] Next, in step S142, the processor 81 determines whether the attack from BC on the target FC has hit. If the result of this determination is a miss ("No" in step S142), the processor 81 ends the non-combat state processing. On the other hand, if the miss has occurred ("Yes" in step S142), in step S143, the processor 81 calculates the damage value corresponding to the attack method specified by the specified attack method data 317. Then, the processor 81 updates the FC status 356 by reducing the stamina value by an amount corresponding to the damage value.

[0262] Next, in step S144, the processor 81 determines whether the stamina value of the target FC has become 0. If the result of this determination is that it has become 0 (yes in step S144), in step S146, the processor 81 sets the current state 355 of the target FC to an "opportunity state". Then, in step S147, the processor 81 begins the process described above. Figure 25 The capture opportunity is shown. Afterwards, processor 81 ends the non-combat state processing.

[0263] On the other hand, if the value does not change to 0 ("No" in step S144), in step S145, the processor 81 sets the current state 355 of the FC of the processing target FC to "battle state". After that, the processor 81 ends the non-battle state processing.

[0264] Return to Figure 44 If the determination in step S132 indicates that the device is not in a "non-combat state" ("No" in step S132), then in step S134, the processor 81 determines whether the target FC is in an "opportunity state." If the determination indicates that the device is not in an "opportunity state" ("No" in step S134), then in step S135, the processor 81 performs combat state processing. On the other hand, if the device is in an "opportunity state" ("Yes" in step S134), then in step S136, the processor 81 performs opportunity state processing.

[0265] Figure 46-47 This is a flowchart illustrating the details of the aforementioned combat status processing. Figure 46 First, in step S151, if there is an attack method currently being charged among the attack methods possessed by the FC, the processor 81 enables the charging progress of that attack method.

[0266] Next, in step S152, the processor 81 determines whether the attack from BC on the target FC has hit. If the result of this determination is a hit (yes in step S152), in step S153, the processor 81 calculates the damage value corresponding to the attack method specified by the specified attack method data 317. Then, the processor 81 updates the FC status 356 by reducing the stamina value by an amount corresponding to the damage value. On the other hand, if there is no hit (no in step S152), the processor 81 skips the processing in step S153.

[0267] Next, in step S154, the processor 81 determines whether the stamina value of the target FC has become 0. If the result of this determination is that it has become 0 (yes in step S154), in step S155, the processor 81 sets the current state 355 of the target FC to an "opportunity state". Then, in step S156, the processor 81 begins the process described above. Figure 25 The capture opportunity is shown. Afterwards, processor 81 terminates the combat state processing.

[0268] On the other hand, if the result of the determination in step S154 is that the stamina value is not 0 ("No" in step S154), in step S157, the processor 81 determines whether the target FC is in an attack action based on the FC attack flag 357. If the result of this determination is that it is in an attack action ("Yes" in step S157), in step S159, the processor 81 causes the target FC to continue its current attack action. Alternatively, if the result is that the attack action has ended, the processor 81 sets the FC attack flag 357 to off. Afterwards, the processor 81 ends the battle state processing.

[0269] On the other hand, if no attack action is being performed ("No" in step S157), in step S158, the processor 81 determines the attack method based on the aforementioned action algorithm 335.

[0270] Next, in Figure 47 In step S160, the processor 81 determines whether the attack method determined above is charging. If it is charging ("Yes" in step S160), in step S161, the processor 81 puts the processing target FC into standby mode until charging is complete. On the other hand, if it is not charging ("No" in step S160), in step S162, the processor 81 causes the processing target FC to begin the attack action corresponding to the attack method determined above. Additionally, at this time, the charging table associated with the attack method is emptied, and charging begins.

[0271] Next, in step S163, the processor 81 sets the flag 357 to be enabled for the FC attack of the target FC. After that, the processor 81 ends the battle state processing.

[0272] Next, the handling of the above-mentioned opportunity states will be explained. Figure 48 This is a flowchart illustrating the details of the above-mentioned opportunity state processing. Figure 48In the process, firstly, in step S171, the processor 81 determines whether a certain period has elapsed since the state of opportunity was entered. If the result of this determination is that no certain period has elapsed ("No" in step S171), in step S172, the processor 81 continues to display the aforementioned opportunity capture performance. Afterward, the processor 81 ends the opportunity state processing.

[0273] On the other hand, if a certain period of time has elapsed since the state of opportunity was changed ("yes" in step S171), in step S173, the processor 81 sets the appearance status of the processing target FC in the FC management data 318 to "no". Thus, the setting is performed to make the processing target FC disappear from the field.

[0274] Next, in step S174, processor 81 begins the elimination process for the target FC. Afterward, processor 81 ends the opportunity state processing.

[0275] Return to Figure 44 If any of the above steps S133, S135, and S136 have been completed, then in step S137, the processor 81 determines whether the above-described processing has been performed on all FCs whose FC status 353 in the FC management data 318 is "Yes". If there are still unprocessed FCs ("No" in step S137), the process returns to step S131 and repeats the processing. If the above processing has been performed on all FCs ("Yes" in step S137), then the processor 81 ends the FC control processing.

[0276] Return to Figure 34 Next, in step S5, the processor 81 performs various game control processes other than those described above. For example, it performs various collision determinations other than those described above and performs processing based on the collision determination results. In addition, it also appropriately performs processing such as applying slip damage caused by poison to BC and FC, and motion control processing for various mechanisms set up on the field.

[0277] Next, in step S6, the processor 81 executes virtual camera control processing. In this processing, the following steps are performed: the virtual camera is controlled based on the virtual camera parameters set through the above-described processing.

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

[0279] Next, in step S8, the processor 81 determines whether an instruction to end the game has been given. If no instruction to end the game has been given ("No" in step S8), the process returns to step S1 and repeats. On the other hand, if an instruction to end the game has been given ("Yes" in step S8), the processor 81 ends the game processing.

[0280] Thus, in the first embodiment, the opportunity to capture the FC is provided even if the FC is defeated in a battle. Furthermore, the opportunity to capture the FC is also provided when it is not in battle, and even when the FC is in battle with BC. Therefore, the ability to capture the FC in diverse scenarios enhances the game's enjoyment.

[0281] (Second Embodiment)

[0282] Next, a second embodiment will be described as another example of the game processing described above. In the second embodiment, the processing is substantially the same as that described above, and the second embodiment will be described in more detail and with greater specificity.

[0283] First, for game system 1, the same structure as in the first embodiment is used, so the description is omitted.

[0284] Next, an outline of the game processing in the second embodiment will be described. The game is envisioned to be essentially the same as in the first embodiment, but further explanation or more detailed description will be provided regarding the following aspects.

[0285] (Regarding PC actions)

[0286] First, the control of the PC will be explained. In addition to the actions shown in the first embodiment, the PC can also perform "dash" and "dodge" actions. For example, as a "dash" action, when pressing button B 54 while inputting a direction using the left analog stick 32 (B + left analog stick input), the PC can move in that input direction at a faster speed than usual. Furthermore, pressing button Y 56 enables the PC to perform a "dodge" action. A "dodge" action is, for example, a predefined action (animation) such as rolling forward in the direction facing the PC's current posture. In this game, basically, even when BC is not present, the FC sometimes attacks the PC. Therefore, collision detection is performed between the FC's attack and the PC. Moreover, it is assumed that the PC may also be damaged if hit by an attack from the FC. For example, if the explosive shockwave of an attack from the FC hits the PC, the PC may be damaged. However, when performing this "dodge" action, collision detection is not performed against attacks from the FC. In other words, the FC's attack can be dodged. Therefore, it can also provide gameplay such as: while BC and FC are fighting, try to capture the PC while considering its positioning to avoid being caught in FC's attacks. In addition, by making the aforementioned evasion actions possible, it can also provide gameplay such as dodging FC's attacks while waiting for a capture opportunity.

[0287] (Controls for locking / unlocking)

[0288] In addition, as another control example related to the aforementioned lock-on activation, the second embodiment performs the following control. In the second embodiment, during the pressing of the ZL button 39, the PC transitions to a "locked mode" state (locked mode becomes on). Furthermore, the following control is performed: a specified FC is locked by satisfying a "lock-on condition" in this locked mode. Specifically, the lock-on condition is that the position relationship between the virtual camera following the PC (or the PC's position) and the FC satisfies a specified condition. More specifically, the following control is performed: when the FC is in a positional relationship in the virtual space such that it exists within a specified distance from the virtual camera and is within a specified range (e.g., a pyramidal shape) that includes the line of sight from the virtual camera's position, and within this specified range, a ray projected from the virtual camera's position to the FC can reach the FC without being obstructed by obstacles, the FC is locked. Furthermore, when multiple FCs satisfy the "lock-on condition" exist, the nearest FC is set as the lock-on target. Furthermore, after temporarily locking a specified FC, if the state changes to one that no longer meets the aforementioned locking conditions, such as the distance to the FC increasing, the locking will be released. Additionally, if the previously pressed ZL button 39 is no longer pressed, the locking mode is released (the locking mode becomes off). Also, if a specified FC is locked at this time, the locked state is also released along with the release of the locking mode.

[0289] (Regarding the crosshair)

[0290] In addition, in the second embodiment, the following control example will be used to illustrate: when the lock is on, the crosshair is displayed in a way that overlaps with the lock-on object; when the lock is off, the crosshair is always displayed in the center of the screen (regardless of whether a pose is being made for a capture item).

[0291] (Regarding menu screen and map screen)

[0292] Additionally, in the aforementioned game, menu and map screens can be displayed according to prescribed operations. The menu screen displays, for example, a UI (user interface) indicating the use of available items. These items, for example, are items usable on the player character (BC) and can provide healing or buff effects. The map screen displays a map of the virtual world, the PC's current location, etc. Furthermore, in this game, game progress is paused while the menu or map screen is displayed. In the second embodiment, in the example where the X button 55 is assigned to the menu screen display and the + button 57 to the map screen display, the flowchart described later will explain the control process for displaying the menu and map screens.

[0293] (Regarding operations related to having character slot 201)

[0294] Next, further explanation will be given regarding the operations related to having the character slot 201. That is, the "BC exit operation" described above will be explained in more detail. In the second embodiment, as a specific example of the "BC exit operation", the right direction button 33, the down direction button 34, the up direction button 35, and the left direction button 36 can be used to perform the following operations.

[0295] first, Figure 49 The above is shown in the figure. Figure 10 The above is an enlarged image of the character slot 201. Figure 49 The image shows three selection boxes (BC) and a selection cursor 501. The selection cursor 501 indicates the currently selected BC. Furthermore, when in... Figure 49 When the up button 35 is pressed in that state, it controls the exit of the leftmost BC box selected by the selection cursor 501. In other words, the up button 35 is assigned to the exit indication operation of the BC. When the BC exits, as... Figure 50 As shown, the exit cursor 502 is displayed at the top of the BC frame. That is, the exit cursor 502 indicates the currently exiting BC. Furthermore, by pressing the down arrow button 34, the currently exiting BC can be returned to its non-existent state (simply possessing the character). Upon the BC returning, the exit cursor 502 is also cleared.

[0296] Additionally, the right arrow button 33 and the left arrow button 36 can be used to move the selection cursor 501 to the adjacent BC box. For example, Figure 51 This is an example of moving the selection cursor 501 to the right.

[0297] Additionally, if another BC is selected while the specified BC is already out of the display and the up button 35 is pressed, the other BC will swap with the BC currently being exited and exit. That is, the BC currently being exited will automatically return and the other BC will exit.

[0298] (Supplementary information regarding operation)

[0299] Next, based on the above, the operation in the second embodiment will be supplemented. Figure 52The table below shows a summary of the operations envisioned 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, similar to the first embodiment, is used to control the "pose state" and capture behavior. The left joystick 32 is used to move the PC, and the right directional buttons 33, 34, 35, and 36 are used to control the exit of the BC as described above. Regarding the ABXY buttons, + button 57, and right joystick 52, their functions may vary depending on whether the lock mode is on or off, and whether the BC is currently exiting the BC.

[0300] First, let's explain the ABXY buttons and the + button 57 mentioned above. Specifically, when the ZL button 39 is not pressed (lock mode is off), regardless of whether BC is in the exit state, the following actions apply: A button 53 is used as a decision indicator, B button 54 is used as a dash indicator, Y button 56 is used as an avoidance indicator, X button 55 is used as a navigation indicator to the menu screen, and + button 57 is used as a navigation indicator to the map screen.

[0301] Next, with ZL button 39 activated (lock mode activated), the functions executed differ depending on whether the specified FC is locked. When the FC is not locked, A button 53 is used as a decision indicator, B button 54 as a dash indicator, and Y button as an evasion indicator. X button 55 and + button 57 are disabled. On the other hand, when the FC is locked, the ABXY buttons, as described in the first embodiment, are used to initiate an attack on the locked FC using the attack methods assigned to each button. Furthermore, the specific attack methods assigned to each button can be arbitrarily set by the user in a designated settings screen, etc. Additionally, + button 57 is used for switching to "strong attack mode".

[0302] Here, we provide supplementary explanation of the aforementioned "Strong Attack Mode". In the second embodiment, the "Strong Attack Mode" is toggled on / off whenever the + button 57 is pressed. When Strong Attack Mode is on, the attack content of BC emitted via the ABXY buttons changes to a strengthened version compared to when Strong Attack Mode is off. For example, the attack power increases, the recovery amount increases, and the duration of the debuff effect on the FC is extended. However, to activate Strong Attack Mode, a specified amount of the aforementioned... Figure 21 The energy metering bar 208 is shown. For example, with... Figure 21 For example, the energy meter 208 could be composed of 5 meters, and one of the meters could be consumed to activate the strong attack mode.

[0303] Next, the operation of the right analog stick 52 will be explained. The right analog stick 52 can basically be used to control the virtual camera via directional input. However, when the locked mode is enabled, thus locking the specified FC (Front-Cut Position), as explained in the first embodiment above, the object to be locked can be switched via directional input.

[0304] Additionally, by pressing the right analog stick 52, BC can be switched to an "enhanced state" under specified conditions. The enhanced state refers to a state where BC's performance (various parameters) is temporarily increased. In the second embodiment, by using the above... Figure 21 When the energy gauge 208 is at its maximum and BC is in the starting state, pressing the right stick 52 will transform BC into an enhanced state. While in enhanced state, the energy gauge 208 gradually decreases over time. If the energy gauge becomes empty, the enhanced state is deactivated, and BC returns to its normal state. In other words, the fully charged energy gauge can be completely consumed to transform BC into enhanced state.

[0305] Furthermore, regarding the various buttons on the controller as described above, from a button allocation perspective, the left controller 3 can be said to be assigned inputs for PC movement (left joystick 32), lock-on / lock-off mode activation / deactivation (ZL button 39), and BC exit control inputs (right directional button 33, down directional button 34, up directional button 35, and left directional button 36). On the other hand, the right controller 4 is assigned inputs for PC behavior control (B button 54, Y button 56), attack instructions for BC (ABXY buttons), use of capture items (ZR button 61), switching of locked targets (right joystick 52), operation inputs related to BC enhancement (+ button 57, right joystick pressed), menu and map display operation inputs (X button 55, + button 57), and virtual camera control inputs (right joystick 52). Therefore, it is possible to perform the following operations: simultaneously controlling PC movement and lock-on activation with the left hand, and simultaneously throwing capture items or issuing attack instructions for BC with the right hand. In other words, the following operations can be performed: using the left hand to control the PC's position and whether the lock is active, and using the right hand to control the timing of various actions performed by the PC and BC. By allocating the operating system to the left and right hands in this way, it is possible to provide operations that can execute different actions such as "attack" and "capture" simultaneously and in parallel. In addition, it is possible to use a limited number of buttons to efficiently control the PC's position and the timing of various actions during such operations.

[0306] Next, the various data used in the processing of the second embodiment will be described. Figure 53The diagram shows an example of a memory layout representing various data stored in the DRAM 85 of the main device 2 in the second embodiment. Furthermore, the same reference numerals are used for the same data as in the first embodiment described above, and detailed descriptions are omitted. Specifically, in Figure 53 In this embodiment, the data other than the selection cursor data 371, lock mode flag 372, capture flag 373, enhancement flag 374, menu flag 375, and map flag 376 are the same as those in the first embodiment described above, so detailed descriptions are omitted.

[0307] exist Figure 53 In the middle, selecting cursor data 371 is used to determine the above. Figure 49 The cursor position in the character selection bar 201 shown is the position of the currently selected character.

[0308] The lock mode flag 372, as described above, is used to determine whether the ZL button 39 is pressed.

[0309] Capture flag 373 is a flag used to indicate whether it is for any of the following periods: from the time the capture item is thrown until the capture judgment ends, or from the time 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 aforementioned periods.

[0310] Enhancement flag 374 is used to indicate whether the BC in the field is currently in an enhanced state. The initial value is off, and it becomes on when in an enhanced state.

[0311] Menu flag 375 is used to determine whether the menu screen is displayed. The initial value is off, and when on, it indicates that the menu screen is displayed.

[0312] Map flag 376 is used to determine whether the map view is displayed. The initial value is off, and when on, it indicates that the map view is displayed.

[0313] Here, we will supplement the PC state data 304 described above in the second embodiment. In the second embodiment, we will describe an example of the PC performing an avoidance action as described above. Therefore, we can also set data indicating that the PC is in an avoidance state for the PC state data.

[0314] Next, use Figure 54-73 The flowchart shown illustrates the details of the processing involved in the second embodiment. Furthermore, in this flowchart, the same reference numerals are used to label the same processes as in the first embodiment, and detailed descriptions are omitted.

[0315] Figure 54 This is a flowchart illustrating the details of the game processing involved in the second embodiment.Figure 54 In the process, firstly, in step S1, the processor 81 acquires operation data 319. Next, in step S201, the processor 81 determines whether the menu flag 375 is on. If the result of this determination is that the menu flag 375 is off ("No" in step S201), in step S202, the processor 81 determines whether the map flag 376 is on. If the map flag 376 is off ("No" in step S202), in step S203, the processor 81 executes PC control processing.

[0316] Figure 55 This is a flowchart illustrating the details of the PC control processing involved in the second embodiment. Figure 55 In the process, firstly, in step S211, the processor 81 determines whether the PC state is in the aforementioned avoidance action state, i.e., the "avoidance state," based on the PC state data 304. If the determination result is that the PC state is in the avoidance state ("Yes" in step S211), in step S217, the processor 81 continues to control the avoidance action. In the next step S218, the processor 81 determines whether the avoidance action has ended. If it has ended ("Yes" in step S218), in step S219, the processor 81 sets the PC state to the "normal state." On the other hand, if it has not ended ("No" in step S218), the processing in step S219 is skipped. After that, the PC control processing ends.

[0317] On the other hand, if the result of the determination in step S211 is that the processor is not in an avoidance state ("No" in step S211), in step S212, the processor 81 performs the movement association processing.

[0318] Figure 56 This is a flowchart illustrating the details of the aforementioned movement association process. First, in step S231, the processor 81 determines whether it is in a locked-on state, where the specified FC has been locked, based on the lock-on flag 322. If it is not in a locked-on state ("No" in step S231), the processor 81 performs normal movement processing in step S232. On the other hand, if it is in a locked-on state ("Yes" in step S231), the processor 81 performs locked movement processing in step S233.

[0319] Figure 57 This is a flowchart illustrating the details of the aforementioned typical movement process. Figure 57In the process, firstly, in step S241, the processor 81 determines whether a directional input has been made to the left joystick 32. If the result of this determination is that no directional input has been made to the left joystick 32 ("No" in step S241), the normal movement process ends. On the other hand, if a directional input has been made to the left joystick 32 ("Yes" in step S241), in step S242, the processor 81 determines whether the B button 54 is turned on (pressed). If the result of this determination is that it is not turned on ("No" in step S242), in step S243, the processor 81 performs movement control on the PC at the normal movement speed based on the input direction of the left joystick 32. On the other hand, if it is turned on ("Yes" in step S242), in step S244, the processor 81 performs movement control based on the input direction of the left joystick 32 while increasing the movement speed of the PC. Additionally, at this time, a special dash action can also be used to control the movement of the PC. Afterwards, the normal movement process ends.

[0320] Furthermore, in this embodiment, the lunge operation is described using an example of "B button + left joystick". However, in other embodiments, it is also possible to control the lunge action to occur even without directional input from the left joystick 32, simply by pressing the B button 54. For example, a lunge action towards the front of the PC at this time can also be performed.

[0321] Next, the details of the movement process during the aforementioned locking will be explained. Figure 58 This is a flowchart illustrating the details of the movement process during the aforementioned locking. Figure 58 In step S251, the processor 81 first determines whether a directional input has been made to the left joystick 32. If the result of this determination is that no directional input has been made to the left joystick 32 ("No" in step S251), the movement process during locking ends. On the other hand, if a directional input has been made to the left joystick 32 ("Yes" in step S251), in step S252, the processor 81 determines whether BC is currently in the exit phase. If the result of this determination is that BC is not in the exit phase ("No" in step S252), in step S253, the processor 81 determines whether button B 54 has been pressed. If the result of this determination is that button B 54 has not been pressed ("No" in step S253), in step S254, the processor 81 moves the PC towards the direction of the lock-opening target while controlling the movement of the PC based on the input direction of the left joystick 32. On the other hand, when button B 54 is turned on ("Yes" in step S253), in step S255, the processor 81 performs movement control based on the input direction of the left joystick 32 while increasing the movement speed of the PC and moving the PC toward the locked object.

[0322] On the other hand, if the result of the determination in step S252 is that BC is in the factory state (yes in step S252), the determination in step S253 is skipped, and the process proceeds to step S254. As described above, when the lock is open and BC is in the factory state, the ABXY button is used as an attack indication for BC, so the input determination for button B 54 is not performed here.

[0323] This concludes the explanation of mobile association processing.

[0324] Return to Figure 55 Next, in step S213, processor 81 performs lock association processing. Figure 59 This is a flowchart illustrating the details of the lock association processing. Figure 59 In step S261, the processor 81 first determines whether the current state is locked based on the lock mode flag 372. If the result of this determination is that the current state is not locked ("No" in step S261), then in step S262, the processor 81 determines whether the ZL button 39 has become on. That is, it determines whether the ZL button 39 has changed from a closed state to an open state. If the result of this determination is that the ZL button 39 is on ("Yes" in step S262), then in step S263, the processor 81 sets the lock mode flag 372 to be on. On the other hand, if the ZL button is closed ("No" in step S262), the above-mentioned step S263 is skipped.

[0325] On the other hand, if the result of the determination in step S261 is that the device is in a locked mode ("yes" in step S261), in step S264, the processor 81 performs locked mode processing. Figure 60 This is a flowchart illustrating the details of the locking mode processing. Figure 60In step S271, the processor 81 first determines whether the ZL button 39 is closed. That is, it determines whether an unlocking operation has been performed. If the result of this determination is that the ZL button 39 is not closed ("No" in step S271), in step S272, the processor 81 determines whether it is currently in a locked-on state based on the lock-on flag 322. If the result of this determination is that it is not in a locked-on state ("No" in step S272), in step S273, the processor 81 determines whether there is an FC that satisfies the "lock-on condition" as described above. If the result of this determination is that there is an FC that satisfies the "lock-on condition" ("Yes" in step S273), in step S274, the processor 81 sets the lock-on flag 322 to open. Next, in step S275, the processor 81 sets the lock-on object data 320 in a way that makes the FC that satisfies the "lock-on condition" a lock-on object. Furthermore, if there are multiple FCs that satisfy the "lock-on condition," the most recent FC is set as the lock-on object, as described above. After that, the locked mode processing ends.

[0326] On the other hand, if there is no FC that meets the "lock unlocking condition" ("No" in step S273), the processing of steps S274 and S275 above is skipped. In this case, although in locked mode, the state where the lock is not unlocked continues.

[0327] On the other hand, if the result of the determination in step S272 is that the lock is in an open state (yes in step S272), in step S276, the processor 81 determines whether the current lock-on object no longer meets the "lock-on condition". For example, it determines whether the distance between the current lock-on object and the virtual camera has changed to a distance greater than a specified distance. If the result of this determination is that the "lock-on condition" no longer meets the condition (yes in step S276), in step S278, the processor 81 releases the lock-on object setting by clearing the lock-on object data 320. In the next step S279, the processor 81 sets the lock-on flag 322 to off. After that, the lock mode processing ends.

[0328] Furthermore, as a possible alternative to the case where "yes" is set in step 276 above, if another FC (Functional Control Unit) exists at that time that satisfies the lock-on condition, the lock-on target can be switched to that other FC. In this case, steps S278 and S279 above can be omitted.

[0329] On the other hand, if the result of the determination in step S276 is that the current locked object maintains the "locked unlock condition" ("No" in step S276), the processing of steps S278 and S279 is skipped, and the locked unlock state is maintained.

[0330] On the other hand, if the determination in step S271 indicates that button ZL 39 is closed ("Yes" in step S271), in step S277, processor 81 sets the lock mode flag 372 to off. Then, the process proceeds to steps S278 and S279, and the lock-on state is also released. Afterwards, the lock mode processing ends.

[0331] This concludes the explanation of the lock association process.

[0332] Return to Figure 55 Next, in step S214, processor 81 performs capture association processing. Figure 61 This is a flowchart illustrating the details of the capture-related processing. Furthermore, in Figure 61 In the process, most of the processing is the same as that used in the first embodiment. Figure 38 The same processing described above applies to the "pose association processing". Therefore, the same reference numerals are used to label the processing that is the same as the "pose association processing" here, and detailed descriptions are omitted. The explanation will focus on the differences from the "pose association processing".

[0333] exist Figure 61 In step S55, if the determination is "yes" (when the operation of throwing a capture item is performed), in step S291, the processor 81 sets the capture flag 373 to be enabled and changes the PC state from "posing state" to "normal state".

[0334] Next, in step S292, the processor 81 calculates the trajectory of the captured item. If the lock is active, the trajectory is calculated with the target being locked as the firing direction. Conversely, if the lock is not active, the trajectory is calculated with the direction of the crosshair displayed in the center of the screen as the firing direction. Furthermore, a movable distance can be set for the captured item, and the trajectory can be calculated based on the falling trajectory corresponding to that distance. In this case, for example, depending on the distance to the target being locked, sometimes the captured item may not reach the target being locked.

[0335] Next, in step S293, the processor 81 initiates the action of the PC throwing the capture item, causing the capture item to move based on the calculated trajectory. Then, the process proceeds to step S294.

[0336] Next, in step S294, the processor 81 determines whether the capture flag 373 is enabled. If it is enabled ("Yes" in step S294), in step S295, the processor 81 executes the capture behavior processing involved in the second embodiment. Figure 62 This is a diagram illustrating the details of the capture behavior processing involved in the second embodiment. Here, in Figure 62 In the flowchart, apart from the processing in step S301, execution and use Figure 40 The capture behavior processing described in the first embodiment above is the same. Therefore, only the processing of step S301 will be described here, and the description of other processes will be omitted.

[0337] exist Figure 62 After step S84, or if "Yes" is selected in step S86, in step S301, the processor 81 sets the capture flag 373 to off. That is, the capture flag 373 is set to off when the capture item hits the FC or when the movement ends without hitting it.

[0338] Return to Figure 61 If the capture behavior processing ends, the capture association processing ends. On the other hand, if the result of the determination in step S294 is that the capture flag is not enabled ("No" in step S294), the processing in step S295 is skipped, and the capture association processing ends.

[0339] This concludes the explanation of capture and association processing.

[0340] Return to Figure 55 Next, in step S215, the processor 81 executes instruction operation association processing. In this processing, it mainly performs control corresponding to the operations on buttons A 53, B 54, X 55, Y 56, and + 57, as well as control of operations related to the aforementioned character bar 201. Figure 63 This is a flowchart illustrating the details of the instruction operation associated processing. First, in step S311, the processor 81 determines whether it is currently in a locked open state and in a state where BC has exited. If the result of this determination is that it is not in a locked open state and BC has exited ("No" in step S311), in step S312, the processor 81 executes normal command processing. On the other hand, if it is in a locked open state and BC has exited ("Yes" in step S311), in step S313, the processor 81 executes attack command processing.

[0341] Figure 64This is a flowchart illustrating the details of the aforementioned typical command processing. This processing is performed when the system is not in locked mode, or when it is in locked mode but not in an unlocked state, or when it is in an unlocked state but BC has not yet been displayed. Figure 64 In the process, firstly, in step S321, the processor 81 determines whether the Y button 56 is turned on. If it is turned on ("Yes" in step S321), in step S322, the processor 81 causes the PC to begin the avoidance action described above. In the next step S323, the processor 81 sets the PC state to "Avoidance State". After that, the normal command processing ends.

[0342] Furthermore, in other embodiments, the avoidance action can also be controlled in combination with directional input to the left joystick 32, similar to the aforementioned lunge. For example, an avoidance action towards that direction can be initiated when directional input to the left joystick 32 occurs while the Y button 56 is pressed.

[0343] On the other hand, if the result of the determination in step S321 is that button Y 56 is not turned on ("No" in step S321), then in step S324, processor 81 determines whether button A 53 is turned on. If the result of this determination is that button A 53 is turned on ("Yes" in step S324), then in step S325, processor 81 executes a decision process. In this process, a process is executed that causes a predetermined action corresponding to the current state of the PC to be performed. For example, appropriately executing a process to operate a button configured in the virtual space, or opening a door, or picking up a fallen item, etc. After that, the normal command processing ends.

[0344] On the other hand, if button A 53 is not turned on ("No" in step S324), then in step S326, processor 81 determines whether button X 55 (menu indicator) is turned on. If button X 55 is turned on ("Yes" in step S326), then in step S327, processor 81 determines whether the current mode is locked. If the result of this determination is that the mode is not locked ("No" in step S327), although button X 55 is turned on, button ZL 39 is in a closed state. In this case, in step S328, processor 81 pauses the game progress and sets menu flag 375 to open. On the other hand, if the mode is locked ("Yes" in step S327), the X button is turned on and button ZL 39 is also turned on (however, lock on flag 322 is closed). In this case, the process proceeds to step S329, which will be described later. That is, while button ZL 39 is pressed, control is performed to invalidate the operation of button X 55. In other words, even if BC and FC are in the middle of a battle, as long as the ZL button 39 is not pressed, the menu screen can be opened to use the specified items, such as items that restore BC's health.

[0345] On the other hand, if the X button 55 is not turned on ("No" in step S326), then in step S329, the processor 81 determines whether the + button 57 is turned on. If the + button 57 is turned on ("Yes" in step S329), then in step S330, the processor 81 determines whether the current mode is locked. If the result of this determination is that the current mode is not locked ("No" in step S330), then in step S331, the processor 81 pauses the game progress and sets the map marker 376 to be turned on. After that, the normal command processing ends. On the other hand, if the current mode is locked ("Yes" in step S330), the normal command processing ends. That is, while the ZL button 39 is pressed, control is performed to invalidate the operation of the + button 57.

[0346] Next, the processing of the aforementioned attack command will be explained. This processing is performed when the lock is open and BC has also appeared. Figure 65This is a flowchart illustrating the details of the attack command processing. First, in step S341, the processor 81 determines whether the + button 57 is turned on. If the result of this determination is that it is turned on ("Yes" in step S341), in step S342, the processor 81 performs the aforementioned switching control between turning the strong attack mode on and off. That is, whenever the + button 57 is pressed, the strong attack mode is switched between on and off. In addition, when switching from off to on, the processor 81 also controls the consumption of a predetermined amount of the aforementioned energy meter 208. However, if the energy meter 208 has not accumulated the predetermined amount at this time, the processor 81 does not switch the strong attack mode on and allows the processing to proceed. After that, the attack command processing ends.

[0347] On the other hand, if the + button 57 is not turned on ("No" in step S341), in step S343, the processor 81 determines whether any of the A button 53, B button 54, X button 55, and Y button 56 has become turned on. If the result of this determination is that none of them have become turned on ("No" in step S343), the attack command processing ends. On the other hand, if any button is turned on ("Yes" in step S343), then, in step S344, the processor 81 determines whether the strong attack mode has been switched on. If the result of this determination is that the strong attack mode is off ("No" in step S344), in step S345, an instruction is given to start BC to attack using the attack method assigned to any button that was determined to be turned on in the above determination. Furthermore, in step S347, the processor 81 adds a predetermined amount to the energy meter 208. That is, the energy meter 208 is accumulated whenever an attack instruction is given. Furthermore, the amount added can be varied depending on the positions of the PC and BC when the attack instruction is given. For example, the closer the two are in a positional relationship, the more measurement bar is added.

[0348] On the other hand, if the strong attack mode is enabled ("Yes" in step S344), in step S346, the processor 81 instructs BC to start an attack in strong attack mode using the attack method assigned to any button determined to be enabled in the above determination. For example, it controls the issuance of an attack start instruction based on doubling the attack power parameter set predetermined for the attack method, and issues an instruction to perform an attack using a pre-prepared parameter set for the strong attack mode. After that, the attack command processing ends.

[0349] Return to Figure 63 Next, in step S314, the processor 81 executes the factory control process. This process is executed regardless of the lock being open state. Figure 66This is a flowchart illustrating the details of the exit control process. First, in step S351, the processor 81 determines whether the right direction button 33 or the left direction button 36 is activated. That is, it determines whether a movement operation of the selection cursor 501 has been performed. If the result of this determination is that a movement operation of the selection cursor 501 has been performed ("yes" in step S351), in step S352, the processor 81 moves the selection cursor 501 based on the operation content, so that the content of the selection cursor data 371 is changed to the ownership role specified by the moved selection cursor 501. After that, the exit control process ends.

[0350] On the other hand, if no movement operation of the selection cursor 351 is performed ("No" in step S351), then in step S353, the processor 81 determines whether the down arrow button 34 is turned on, that is, whether an operation to return the BC in the exit position (return operation) has been performed. If the result of this determination is that a return operation has been performed ("Yes" in step S353), in step S354, the processor 81 determines whether the BC in the exit position exists. If it exists ("Yes" in step S354), the processor controls the BC to return. At this time, if the BC in the exit position is in an enhanced state, the processor 81 sets the enhanced flag 374 to off. In addition, the processor controls the removal of the exit cursor 502. On the other hand, if the BC in the exit position does not exist ("No" in step S354), this process is skipped. After that, the exit control process ends.

[0351] On the other hand, if no return operation is performed (No in step S353), in step S356, the processor 81 determines whether the up button 35 is turned on. That is, it determines whether an operation to remove the BC (removal operation) has been performed. If the result of this determination is that a removal operation has been performed (Yes in step S356), in step S357, the processor 81 determines whether there is a BC in the removal process. If there is (Yes in step S357), in step S358, the processor 81 performs the same control to return the BC as described above. If there is no BC (No in step S357), the processing in step S358 is skipped.

[0352] Next, the same processing as steps S42 to S44 in the first embodiment described above is performed. Specifically, in step S42, the processor 81 sets the ownership role specified by the selection cursor data 371 to BC. Next, in step S43, the processor 81 sets the entrance performance flag 323 to be enabled, and in the following step S44, the processor 81 begins the same entrance performance as in the first embodiment. Control of the entrance cursor 502 is also performed accordingly. After that, the entrance control process ends.

[0353] This concludes the explanation of the associated processing of the instructions.

[0354] Return to Figure 55 Next, in step S216, the processor 81 performs right joystick control processing. Figure 67 This is a flowchart illustrating the details of the right joystick control process. First, in step S371, the processor 81 determines whether there is a directional input operation to the right joystick 52 based on operation data 319. If the result of this determination is that there is a directional input ("Yes" in step S371), in step S372, the processor 81 determines whether the lock-on flag 322 is on. If the lock-on flag 322 is on ("Yes" in step S372), in step S374, the processor 81 controls the switching of the lock-on object. On the other hand, if the lock-on flag 322 is off ("No" in step S372), in step S373, the processor 81 sets the parameters of the virtual camera based on the operation content. In the virtual camera control process described later, the virtual camera is controlled based on the parameters set here, thereby realizing the operation of the virtual camera via the right joystick 52. Then, the process proceeds to step S375.

[0355] On the other hand, if the result of the determination in step S371 is that there is no direction input ("No" in step S371), then in step S375, the processor 81 determines whether the right joystick 52 has been pressed. If the result of this determination is that a pressing operation has been performed ("Yes" in step S375), then in step S376, the processor 81 determines whether the enhancement condition of the BC is met. Specifically, if the BC is in the factory and the energy meter 208 is at its maximum, then the enhancement condition is determined to be met. Furthermore, depending on the type of BC, there may be a type of BC that does not have the ability to be enhanced. In this case, it is sufficient to use the fact that a type of BC that can be enhanced is in the factory as the enhancement condition.

[0356] If the result of the above determination is that the enhancement conditions are met ("Yes" in step S376), in step S377, the processor 81 sets the enhancement flag to be enabled.

[0357] On the other hand, if the right analog stick 52 is not pressed ("No" in step S375), the processing in steps S376 to S377 above is skipped. The right analog stick control processing ends here.

[0358] Return to Figure 55 If the right joystick control process ends, then the PC control process ends.

[0359] Return to Figure 54After the PC control processing, in step S204, the processor 81 executes the BC control processing. Figure 68-69 This is a flowchart illustrating the details of the BC control process involved in the second embodiment. Figure 68-69 In addition to the processing involved in step S381, the process is performed in the same manner as in the first embodiment described above. Figure 42-43 The BC control process described herein is the same. Therefore, this section mainly describes only the process involved in step S381, omitting the description of other processes.

[0360] exist Figure 68 In step S381, the processor 81 performs enhanced state control processing. This is processing related to the enhanced state of BC described above. Figure 70 This is a flowchart illustrating the details of the enhanced state control process. First, in step S391, the processor 81 determines whether the enhanced flag 374 is enabled. If the result of this determination is disabled ("No" in step S391), in step S396, the processor 81 sets the normal parameters to the parameters of the BC in the factory (e.g., attack power). Therefore, in subsequent processing, the normal parameters are used to perform the BC's action control (attack actions, etc.).

[0361] On the other hand, when the enhancement flag 374 is activated ("Yes" in step S391), in step S392, the processor 81 determines whether the enhancement release condition is met. In this example, the enhancement release condition is determined to be met if the energy meter 208 becomes 0, or if an operation is performed to return the enhanced BC to the character owner state, or if the enhanced BC's health value becomes 0. If the enhancement release condition is not met ("No" in step S392), in step S393, the processor 81 sets the parameters for the enhanced state to the parameters of the BC in the field. This may involve, for example, setting various parameters or the effects of various attacks in the normal state to a multiplied value, or setting preset parameters that are pre-set as parameters for the enhanced state. Thus, in subsequent processing, the enhanced parameters are used to control the BC's actions (attack actions, etc.). In addition, while the BC is in the enhanced state, the BC's appearance can also be changed to the appearance for the enhanced state, making it visually clear that the BC is in the enhanced state.

[0362] Next, in step S394, the processor 81 reduces the energy metering bar 208 by a predetermined amount. Afterwards, the enhanced state control process ends.

[0363] On the other hand, if the result of the determination in step S392 is that the enhancement removal condition is met ("Yes" in step S392), in step S395, the processor 81 sets the enhancement flag 374 to be turned off. Then, the process proceeds to step S396.

[0364] The explanation of the enhanced state control process concludes here. Following the enhanced state control process, as a subsequent step in the BC control process, the processing after step S116 described above is executed. Here, supplementary information is provided regarding the BC attack action control involved in steps S122 and S126. As attack methods performed by the BC in this embodiment, including the first embodiment described above, at least two types are prepared: "long-range attack" and "close-range attack" (in addition, recovery actions are also prepared, but these are omitted here). Furthermore, supplementary information is provided regarding the BC actions related to these two attack methods.

[0365] First, if the attack instruction in step S123 is "long-range attack," then in steps S126 and S122, BC is controlled to perform the following actions: First, BC is moved to a predetermined attack start position. This position is, for example, a position diagonally in front of the PC. Next, if the attack start position has been reached, a long-range attack activity corresponding to the attack instruction is initiated, performing a long-range attack (e.g., firing a predetermined projectile) towards the FC, which is the target of the lock-on. Furthermore, in the case of long-range attacks, the attack distance can be set for each attack method. In this case, depending on the distance between BC and FC, sometimes the long-range attack may not reach the target; therefore, the element of considering the positional relationship with the FC is added to the movement, which enhances the game's enjoyment.

[0366] Next, if the attack instruction is "approach attack," the BC is controlled to perform the following actions. In this case, the BC is also moved to the designated attack start position, but in the case of a approach attack, the position adjacent to the FC (FC) that is the target of lock-on activation becomes the attack start position. Then, if the attack start position has been reached, the approach attack activity corresponding to the attack instruction begins, performing a approach attack (e.g., punching) towards the FC that is the target of lock-on activation. Afterward, if the approach attack activity ends, the BC returns to the vicinity of the PC.

[0367] In this way, the starting position of BC's attack action is different in long-range and close-range attacks. Therefore, users can decide whether to use a long-range or close-range attack while considering the starting position of the attack and the positional relationship between FC and BC, which improves the strategic nature of the game.

[0368] Return to Figure 54After the BC control process, the FC control process is executed. This process is the same as step S4 in the first embodiment described above, so its description is omitted.

[0369] Next, in step S205, the processor 81 performs various other game control processes. That is, it performs various collision determinations and processing based on the collision determination results. This processing is essentially the same as step S5 of the first embodiment described above, but with some additional explanations. In the second embodiment, as described above, an example is given where the PC can perform an evasion action. Therefore, based on the position of the FC attack and the PC's position, it is determined whether the FC attack collided with the PC. During this determination, it is also determined whether the PC is in the aforementioned "evasion state." If it is in the evasion state, the system is controlled to prevent collision determination between the FC attack and the PC. As a result, the PC evades the FC attack.

[0370] Next, in step S206, processor 81 executes virtual camera control processing. Figure 71 This is a flowchart illustrating the details of the virtual camera control process. Figure 71 In the process, firstly, in step S411, the processor 81 determines whether the lock-on flag 322 is on (whether it is in the lock-on state). 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 S413, the processor 81 sets the crosshair to the center of the screen. After that, the virtual camera control process ends.

[0371] On the other hand, when the lock-on flag is on ("Yes" in step S411), in step S414, the processor 81 controls the virtual camera so that the lock-on object is displayed within a specified range converged to the center of the screen. Next, in step S415, the processor 81 configures the crosshair to overlap with the lock-on object. The virtual camera control process then concludes.

[0372] Furthermore, the appearance of the crosshair when the lock-on indicator is on can be made different from the appearance of the crosshair when the lock-on indicator is off. This makes it easier to visually determine whether the FC has been locked or unlocked.

[0373] Return to Figure 54 After the virtual camera control processing, in step S7, the processor 81 generates and outputs a game image reflecting the above-mentioned processing content. Then, similarly to the first embodiment, in step S8, a determination of game end is made.

[0374] Next, we will explain the processing if the result of the determination in step S201 is that the menu flag is on ("Yes" in step S201). In this case, in step S207, the processor 81 performs menu processing. Figure 72 This is a flowchart illustrating the details of the menu processing. First, in step S421, the processor 81 determines whether an operation to close the menu screen has been performed based on operation data 319. If the result of this determination is that no operation to close the menu screen was performed ("No" in step S421), in step S422, the processor 81 performs various processes related to the menu screen based on operation data 319. For example, it performs processes such as using owned items.

[0375] On the other hand, when the operation to close the menu screen is performed ("Yes" in step S421), in step S423, the processor 81 sets the menu flag 375 to be off. Next, in step S424, the processor 81 performs the process of clearing the menu screen. Then, in step S425, the processor 81 restarts the progress of the paused game processing. Afterwards, the menu processing ends.

[0376] Return to Figure 54 If the menu processing is finished, then proceed to step S7 above.

[0377] Next, we will explain the processing if the result of the determination in step S202 is that the map flag is enabled ("Yes" in step S202). In this case, in step S208, the processor 81 performs map processing. Figure 73 This is a flowchart illustrating the details of map processing. First, in step S431, the processor 81 determines whether an operation to close the map screen has been performed based on operation data 319. If the result of this determination is that no operation to close the map screen has been performed ("No" in step S431), in step S432, the processor 81 performs various processes related to the map screen based on operation data 319 to generate the map screen.

[0378] On the other hand, when the operation to close the map screen is performed ("Yes" in step S431), in step S433, the processor 81 sets the map flag 376 to be closed. Next, in step S434, the processor 81 performs the process of clearing the map screen. Then, in step S435, the processor 81 restarts the progress of the paused game processing. Afterwards, the map processing ends.

[0379] Return to Figure 54 If map processing is complete, then proceed to step S7 above.

[0380] This concludes the description of the game processing involved in the second embodiment.

[0381] In the second embodiment, similar to the first embodiment, FC capture can be performed in various scenarios. Furthermore, the action of throwing capture items can be performed concurrently with the battle against the FC. In other words, the BC can attack the FC while the PC performs another action (throwing a capture item or taking an evasive action). That is, the capture operation and the attack instruction to the BC can be performed simultaneously in real time. Thus, for example, it is easy to perform actions such as planning the timing of throwing the capture item while increasing the capture success rate by having the BC attack the FC to reduce its health. Furthermore, even though the number of buttons available is limited, as with the controller described above, the two objects, the PC and the BC, can be operated simultaneously and in parallel in real time. Additionally, since a charging time is set for the attack method against the BC as described above, leeway is provided, for example, to switch to PC operation during the charging time interval, facilitating simultaneous operation. Furthermore, by controlling the switching between operation groups that require locking and those that do not, based on the lock-on / unlocked state, the buttons can be used flexibly without wasting the limited number of buttons. Additionally, regarding the ABXY button, when it changes to the locked-on state while BC is in the field, the ABXY button becomes the state used to indicate an attack on BC. In other words, the operation used to unlock (activating ZL button 39) also serves as the transition to using the ABXY button to indicate an attack on BC, thus making it easy to perform actions such as throwing capture items at the locked-on target while fighting the FC.

[0382] [Variation Example]

[0383] Furthermore, the above embodiment illustrates an example where the FC can be captured even when in "battle mode." In other embodiments, it is also possible to configure the FC so that it cannot be captured when it is in "battle mode." For example, it is also possible to perform an action such that even if a capture attempt is made, the capture item is deflected by the FC.

[0384] Furthermore, in the above embodiments, an example is shown where the "chance state" ends after a certain period of time elapsed since the state transitioned from FC to "chance state". Moreover, an example is shown where any number of capture attempts can be made during the "chance state". Regarding this, in other embodiments, a limit may be set on the number of capture attempts during the "chance state". For example, if the number of attempts is set to 3, it is possible that if 3 capture attempts during the "chance state" result in no capture, the "chance state" ends at that point in time, even if no certain period of time has elapsed since the state transitioned to "chance state".

[0385] Furthermore, in the above implementation, when the FC's stamina value becomes 0, the FC is considered to have been defeated and enters an "opportunity state". Regarding this, it is also possible that the determination of being defeated is not limited to the stamina value becoming 0, but also when it becomes below a certain value, such as the stamina value becoming 10% or less.

[0386] Furthermore, in the above embodiments, the following example is given: if the capture attempt is performed when the FC is in "non-combat state" and the capture fails, the system switches to "combat state". In other embodiments, the FC may escape if the capture fails. For example, the system may pre-set whether to switch to "combat state" or escape based on the type of FC; alternatively, the system may determine whether to switch to "combat state" or escape by random selection when the capture fails.

[0387] Furthermore, in the above embodiment, only one BC is shown, but in other embodiments, it is also possible to have multiple BCs appear.

[0388] Alternatively, in the BC control process described above, if the distance between BC and PC remains above a predetermined distance for a certain period of time, BC may be moved by teleporting to the PC. Furthermore, if an attack instruction is given while the distance between BC and PC remains above a predetermined distance, control may also be applied to temporarily teleport BC to the PC and then move it to the aforementioned attack initiation position.

[0389] In addition, in the example above, the control of turning the lock mode on and off was shown to be set to on while the ZL button 39 is pressed. However, it can also be set to switch the lock mode on and off whenever the ZL button 39 is pressed.

[0390] Furthermore, regarding the enhanced state transition of BC via pressing the right analog stick 52, in the example above, an example of completely consuming the energy gauge that has been accumulated to its maximum was shown. However, in addition to this, it is also possible that, not limited to, the entire energy gauge that has been accumulated to its maximum is consumed, for example, by consuming a second amount that is more than the first amount, where the first amount is the amount of gauge consumed when switching to the aforementioned "strong attack mode".

[0391] Furthermore, the timing for the enhanced state transition of BC is not limited to the aforementioned timings. For example, it can be configured to transition to the enhanced state only when the lock is open.

[0392] Furthermore, the above embodiment describes the case where the game processing described above is performed by a single main unit 2. This main unit 2 may also include multiple storage devices and processors. Moreover, the game processing can be performed by each of these devices separately. The above processing can also be performed in a distributed system consisting of multiple information processing devices, including at least one server.

[0393] The present disclosure has been described in detail above; however, the foregoing description is merely illustrative in all respects and is not intended to limit its scope. It is self-evident that various modifications and variations can be made without departing from the scope of the present disclosure.

Claims

1. A computer-readable, non-transitory recording medium containing game programs. The game program causes the computer to perform the following processes: Based on the first operation input as directional input, the player character's movement is controlled within the virtual space; Based on the second operation input, the player character is switched to a locked state, in which the enemy character configured in the virtual space is locked; When a combat character who is locked in the state and is about to fight the enemy character appears in the virtual space, the combat character performs an attack on the enemy character who is the locked target based on a third operation input. Based on the fourth operation input, the player character performs the following actions: in the locked state, releases a capture item for capturing the enemy character towards the locked target; in the unlocked state (not the locked state), releases a capture item for capturing the enemy character towards the crosshair direction. as well as If the capture item hits the enemy character, a capture success check is performed. If the capture success check is successful, the enemy character is set to be held by the player.

2. The computer-readable non-transitory recording medium containing a game program as described in claim 1, wherein, The attack is an action that alters the state of the enemy character. The ease of successfully capturing an enemy varies depending on the enemy character's state.

3. The computer-readable non-transitory recording medium containing a game program as described in claim 2, wherein, The game program also causes the computer to perform the following processes: Perform a subjugation determination regarding whether the enemy character has been subjugated through the aforementioned attack behavior; If the enemy character is defeated, the enemy character will be removed from the virtual space after the first period following the defeat. as well as If the capture item hits the enemy character during the first period, the success rate is increased to determine the capture success.

4. The computer-readable non-transitory recording medium containing a game program as described in claim 1, wherein, The third operation input is included in the first operation input group, which includes multiple operation inputs. The attack behavior is one of a plurality of combat behaviors corresponding to the operation inputs of the first operation input group, and the combat behavior corresponding to the third operation input. The game program causes the computer to perform the following processing: when any operation input from the first operation input group is performed in the locked state, for the combat action corresponding to the operation input, the combat character is moved to a positional relationship set for the combat action, and then the combat character is made to perform an action with an animation set for the combat action.

5. The computer-readable non-transitory recording medium containing a game program as described in claim 4, wherein, The game program causes the computer to perform the following processes: When the attack is in a state where it can be launched, the combat character performs the attack based on the third operation input, and the attack is changed to a state where it cannot be launched. as well as The attack behavior that was in the inactive state is transformed into the active state over time.

6. The computer-readable non-transitory recording medium containing a game program as described in claim 4, wherein, The game program causes the computer to perform the following processing: to control the movement of the captured item released by the player character with a trajectory corresponding to the distance.

7. The computer-readable non-transitory recording medium containing a game program as described in claim 4, wherein, The game program causes the computer to perform the following processes: Cause the enemy character to perform an enemy attack as an attack against the combat character; The hit determination of the enemy attack on the player character is based on the location of the enemy attack and the location of the player character. as well as If the enemy's attack hits the player character, damage is inflicted on the player character.

8. A game processing method, which is a game processing method executed by a computer including at least one processor, wherein, The game processing method causes the computer to perform the following processes: Based on the first operation input as directional input, the player character's movement is controlled within the virtual space; Based on the second operation input, the player character is switched to a locked state, in which the enemy character configured in the virtual space is locked; When a combat character who is locked in the state and is about to fight the enemy character appears in the virtual space, the combat character performs an attack on the enemy character who is the locked target based on a third operation input. Based on the fourth operation input, the player character performs the following actions: in the locked state, releases a capture item for capturing the enemy character towards the locked target; in the unlocked state (not the locked state), releases a capture item for capturing the enemy character towards the crosshair direction. as well as If the capture item hits the enemy character, a capture success check is performed. If the capture success check is successful, the enemy character is set to be held by the player.

9. The game processing method according to claim 8, wherein, The attack is an action that alters the state of the enemy character. The ease of successfully capturing an enemy varies depending on the enemy character's state.

10. The game processing method according to claim 9, wherein, The game processing method causes the computer to perform the following processes: Perform a subjugation determination regarding whether the enemy character has been subjugated through the aforementioned attack behavior; If the enemy character is defeated, the enemy character will be removed from the virtual space after the first period following the defeat. as well as If the capture item hits the enemy character during the first period, the success rate is increased to determine the capture success.

11. The game processing method according to claim 8, wherein, The third operation input is included in the first operation input group, which includes multiple operation inputs. The attack behavior is one of a plurality of combat behaviors corresponding to the operation inputs of the first operation input group, and the combat behavior corresponding to the third operation input. The game processing method causes the computer to perform the following processing: when any operation input from the first operation input group is performed in the locked state, for the combat behavior corresponding to the operation input, the combat character is moved to a positional relationship set for the combat behavior, and then the combat character is made to perform an animation set for the combat behavior to perform the combat behavior.

12. The game processing method according to claim 11, wherein, The game processing method causes the computer to perform the following processes: When the attack is in a state where it can be launched, the combat character performs the attack based on the third operation input, and the attack is changed to a state where it cannot be launched. as well as The attack behavior that was in the inactive state is transformed into the active state over time.

13. The game processing method according to claim 11, wherein, The game processing method causes the computer to perform the following processing: control the movement of the captured item released by the player character with a trajectory corresponding to the distance.

14. The game processing method according to claim 11, wherein, The game processing method causes the computer to perform the following processes: Cause the enemy character to perform an enemy attack as an attack against the combat character; The hit determination of the enemy attack on the player character is based on the location of the enemy attack and the location of the player character. as well as If the enemy's attack hits the player character, damage is inflicted on the player character.

15. A game system having at least one processor, wherein, The processor performs the following processing: Based on the first operation input as directional input, the player character's movement is controlled within the virtual space; Based on the second operation input, the player character is switched to a locked state, in which the enemy character configured in the virtual space is locked; When a combat character who is locked in the state and is about to fight the enemy character appears in the virtual space, the combat character performs an attack on the enemy character who is the locked target based on a third operation input. Based on the fourth operation input, the player character performs the following actions: in the locked state, releases a capture item for capturing the enemy character towards the locked target; in the unlocked state (not the locked state), releases a capture item for capturing the enemy character towards the crosshair direction. as well as If the capture item hits the enemy character, a capture success check is performed. If the capture success check is successful, the enemy character is set to be held by the player.

16. The game system according to claim 15, wherein, The attack is an action that alters the state of the enemy character. The ease of successfully capturing an enemy varies depending on the enemy character's state.

17. The game system according to claim 16, wherein, The processor performs the following processing: Perform a subjugation determination regarding whether the enemy character has been subjugated through the aforementioned attack behavior; If the enemy character is defeated, the enemy character will be removed from the virtual space after the first period following the defeat. as well as If the capture item hits the enemy character during the first period, the success rate is increased to determine the capture success.

18. The game system according to claim 15, wherein, The third operation input is included in the first operation input group, which includes multiple operation inputs. The attack behavior is one of a plurality of combat behaviors corresponding to the operation inputs of the first operation input group, and the combat behavior corresponding to the third operation input. The processor performs the following processing: when any operation input from the first operation input group is performed in the locked state, for the combat action corresponding to the operation input, the combat character is moved to a positional relationship set for the combat action, and then the combat character is made to perform an animation set for the combat action to perform the combat action.

19. The game system according to claim 18, wherein, The processor performs the following processing: When the attack is in a state where it can be launched, the combat character performs the attack based on the third operation input, and the attack is changed to a state where it cannot be launched. as well as The attack behavior that was in the inactive state is transformed into the active state over time.

20. The game system according to claim 18, wherein, The processor performs the following processing: controls the movement of the captured item released by the player character with a trajectory corresponding to the distance.

21. The game system according to claim 18, wherein, The processor performs the following processing: Cause the enemy character to perform an enemy attack as an attack against the combat character; The hit determination of the enemy attack on the player character is based on the location of the enemy attack and the location of the player character. as well as If the enemy's attack hits the player character, damage is inflicted on the player character.

22. A gaming device comprising at least one processor, wherein, The processor performs the following processing: Based on the first operation input as directional input, the player character's movement is controlled within the virtual space; Based on the second operation input, the player character is switched to a locked state, in which the enemy character configured in the virtual space is locked; When a combat character who is locked in the state and is about to fight the enemy character appears in the virtual space, the combat character performs an attack on the enemy character who is the locked target based on a third operation input. Based on the fourth operation input, the player character performs the following actions: in the locked state, releases a capture item for capturing the enemy character towards the locked target; in the unlocked state (not the locked state), releases a capture item for capturing the enemy character towards the crosshair direction. as well as If the capture item hits the enemy character, a capture success check is performed. If the capture success check is successful, the enemy character is set to be held by the player.

Images