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

Abstract

To provide a game program, a game system, a game device, and a game processing method allowing a player character to perform various kinds of motions on a field in a virtual space.SOLUTION: A sighting direction within a virtual space is determined based on second operation input in a first mode, a player character is allowed to release an item affecting a field character disposed on a field within a virtual space toward the sighting direction on the basis of third operation input, a sighting direction is determined based on second operation input in a second mode, and the play character is allowed to release a fighting character who fights toward the sighting direction on the basis of the third operation input.SELECTED DRAWING: Figure 22

Description

[Technical Field]

[0001] The present invention relates to a game program, a game system, a game device, and a game processing method for processing a character in a virtual space. [Background technology]

[0002] BACKGROUND ART Conventionally, there is a game program in which a player character throws a ball at a character in a virtual space, thereby capturing the character and setting the character in the player character's possession (see, for example, Non-Patent Document 1). [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] "Catching Wild Pokemon", [online], The Pokemon Company, [Retrieved December 8, 2021], Internet (URL: https: / / www.pokemon.com / us / strategy / pokemon-rpgs-101 / ) Summary of the Invention [Problem to be solved by the invention]

[0004] However, in the game program disclosed in Non-Patent Document 1, the ability to throw the ball and capture a character is limited to during battle, and the ball cannot be thrown on the field.

[0005] Therefore, an object of the present invention is to provide a game program, a game system, a game device, and a game processing method that enable a player character to perform various types of actions on a field in a virtual space. [Means for solving the problem]

[0006] In order to achieve the above object, the present invention may employ the following configurations, for example.

[0007] One configuration example of a game program of the present invention causes a computer of an information processing device to switch at least between a first mode and a second mode based on a first operation input, and in the first mode, determines the aiming direction within a virtual space based on a second operation input, and causes the player character to fire an item that affects a field character placed on a field in the virtual space in the aiming direction based on a third operation input, so that when the item is fired at a location where the field character is placed, an effect associated with the item is given to the field character, and in the second mode, determines the aiming direction based on the second operation input, and causes the player character to fire a combat character that will engage in combat in the aiming direction based on the third operation input, so that when the combat character is fired at a location where the field character is placed, a battle between the field character and the combat character begins on the field.

[0008] According to the above, by switching between the first mode and the second mode, it is possible to make the player character perform a number of different types of actions, such as firing an item that affects a field character at a targeted field character on the field, and firing a combat character that fights against the field character on the field, by inputting an operation to fire at the targeted field character.

[0009] The items may include at least a capture item for capturing a field character. The computer may further be caused to perform a capture success determination as to whether the capture is successful or not when the capture item released in the first mode hits a field character, and may be caused to set the field character hit by the capture item to a state where it is owned by the player when the capture success determination is affirmative.

[0010] Based on the above, the user can select whether to capture a field character or to have the field character and the combat character fight.

[0011] The items may further include an item that has the effect of making it easier for a positive determination to be made regarding a successful capture.

[0012] Based on the above, it is possible to make the determination of whether or not the capture item is successful more favorable by using the capture item before releasing the capture item.

[0013] The items may further include an item that has the effect of restricting the movement of the field character on the field.

[0014] Based on the above, by restricting the movement of a targeted field character on the field, it is possible to make it easier for the capture item to hit the field character.

[0015] Furthermore, the computer may be further caused to aim at the field character based on a fourth operation input.

[0016] Based on the above, it is possible to easily aim at a targeted field character on the field.

[0017] Furthermore, the computer may further display, based on a fourth operation input, an indicator indicating the likelihood of making a positive determination of the capture success determination for the field character that is being aimed at.

[0018] According to the above, the indicator can be used as a basis for determining whether or not to use the capture item to capture. In addition, since the indicator is displayed while the aiming direction is aimed at the field character, the player can release the capture item after making the above-mentioned decision.

[0019] Furthermore, the computer may further display information about the field character that the aiming direction is directed at, based on a fourth operation input and a fifth operation input.

[0020] Based on the above, it is possible to easily view information about a field character that is targeted on the field.

[0021] The information about the field character may also include mission information about the history of missions within the game, including at least the number of times the field character has been captured and the number of times the field character has been fought.

[0022] According to the above, the mission history of the field character targeted on the field is displayed, which can be used as information for making a decision when selecting between the capture and the battle.

[0023] Furthermore, the computer may further be configured to, after the start of a battle, cause a battle between a combat character and a field character on a field based on operational input including at least an attack instruction by the combat character and an instruction to use an item, and when an instruction to use a capture item is given during the battle, make an in-battle capture success determination as to whether or not the capture of the field character will be successful based on the state of the field character that changes during the battle using the capture item, and when the in-battle capture success determination is judged to be positive, set the field character to a state owned by the player.

[0024] Based on the above, it is possible to select whether to capture a field character during a period other than a battle using a combat character, or to capture a field character during the battle.

[0025] Furthermore, the computer may further display an indicator indicating the state of the field character with respect to at least physical strength at a position set corresponding to the position of the field character during battle, and may control the orientation of the virtual camera based on a sixth operation input.

[0026] According to the above, even when the indicator of the field character's stamina is not displayed, the direction of the virtual camera can be changed by inputting an operation, so that the indicator can be displayed when the user wishes.

[0027] Furthermore, in the second mode, when the computer releases a combat character at a location on the field where a collection object indicating that an item can be acquired is located, the combat character may be made to perform a predetermined action on the collection object, causing the player to acquire the item associated with the collection object.

[0028] Based on the above, the combat character can be used for purposes other than combat with the field character.

[0029] Furthermore, the computer may further display an indicator indicating the aiming direction in different display modes in the first mode and the second mode.

[0030] According to the above, it becomes easy to see what the player character is about to shoot even while aiming at the field character.

[0031] The item may be an event item that progresses an in-game event when it hits a field character. In this case, the computer may be configured to determine that the in-game event has been cleared when a plurality of event items have been hit on the field character until a predetermined clearing condition has been met, and may be configured to control the game so that the clearing condition becomes easier to meet when the player wins a battle with the field character.

[0032] According to the above, by switching between a first mode in which items that affect field characters are released and a second mode in which combat characters that fight against field characters on the field, it is possible to enrich strategies for clearing in-game events.

[0033] Furthermore, when the player wins a battle against the field character, the movement of the field character within the virtual space may be restricted for at least a predetermined period of time.

[0034] According to the above, if a combat character wins a battle between the combat character and a field character, it becomes easier to hit the field character with an item, and the in-game event can be cleared advantageously through the battle other than by releasing the item.

[0035] The clear condition may also be to reduce an event parameter, which decreases each time an event item hits a field character, to a predetermined standard. If the battle with the field character is won, the amount of decrease in the event parameter corresponding to hitting the field character with an event item within at least a predetermined period of time may be relatively large.

[0036] According to the above, the effect of the items released in the in-game event can be increased, and the in-game event can be advantageously cleared by the above battle other than releasing the items.

[0037] The present invention may also be embodied in the form of a game system, a game device, and a game processing method. [Effects of the Invention]

[0038] According to the present invention, by switching between the first mode and the second mode, it is possible to make the player character perform a number of different types of actions, such as firing an item that affects a field character at a targeted field character on the field, and firing a combat character that fights against the field character on the field, by inputting an operation to fire at the targeted field character. [Brief explanation of the drawings]

[0039] [Figure 1] FIG. 1 shows an example of a state in which the left controller 3 and the right controller 4 are attached to the main unit 2. [Figure 2] FIG. 10 shows an example of a state in which the left controller 3 and the right controller 4 are detached from the main unit 2. [Figure 3] Six-sided views showing an example of the main unit 2 [Figure 4] Six-sided diagram showing an example of the left controller 3 [Figure 5] Six-sided diagram showing an example of the right controller 4 [Figure 6] A block diagram showing an example of the internal configuration of the main unit 2. [Figure 7] A block diagram showing an example of the internal configuration of the main unit 2, the left controller 3, and the right controller 4. [Figure 8] FIG. 10 shows an example of a game image in the first stage of capturing a field character FC. [Figure 9] FIG. 10 shows an example of a game image in the second stage of the scene where the field character FC is captured. [Figure 10] FIG. 10 shows an example of a game image in the third stage of capturing a field character FC. [Figure 11] FIG. 10 shows an example of a game image in the first stage of a battle scene between a field character FC and a combat character BC. [Figure 12] FIG. 10 shows an example of a game image in the second stage of a battle between a field character FC and a combat character BC. [Figure 13]FIG. 10 shows an example of a game image in the third stage of a battle scene between a field character FC and a combat character BC. [Figure 14] FIG. 10 shows an example of a game image in the fourth stage of a battle scene between a field character FC and a combat character BC. [Figure 15] A diagram showing an example of a game image in the first stage where a combat character BC collects a collection object OBJ. [Figure 16] A diagram showing an example of a game image in the second stage where a combat character BC collects a collection object OBJ. [Figure 17] Figure showing an example of the field character FC encyclopedia display [Figure 18] FIG. 10 shows an example of a game image in which a boss character MC is attacked. [Figure 19] FIG. 10 shows an example of a game image in the first stage of a battle between a boss character MC and a battle character BC. [Figure 20] FIG. 10 shows an example of a game image in the second stage of a battle scene between a boss character MC and a battle character BC. [Figure 21] FIG. 10 is a diagram showing an example of a data area set in the DRAM 85 of the main device 2 in this embodiment. [Figure 22] A flowchart showing an example of game processing executed by the game system 1. [Figure 23] A subroutine showing a detailed example of the item use process performed in step S125 in FIG. [Figure 24] A subroutine showing a detailed example of the first character use process performed in step S127 in FIG. 22. [Figure 25] A subroutine showing a detailed example of the boss item use process performed in step S130 in FIG. 22. [Figure 26] A subroutine showing a detailed example of the second character use process performed in step S132 in FIG. DETAILED DESCRIPTION OF THE INVENTION

[0040] A game system according to an example of this embodiment will be described below. An example of the game system 1 according to this embodiment includes a main unit (information processing device; in this embodiment, it functions as a game device main unit) 2, a left controller 3, and a right controller 4. The left controller 3 and the right controller 4 are each detachable from the main unit 2. In other words, the game system 1 can be used as an integrated device by attaching the left controller 3 and the right controller 4 to the main unit 2. The game system 1 can also be used by separating the main unit 2 from the left controller 3 and the right controller 4 (see FIG. 2). Below, the hardware configuration of the game system 1 according to this embodiment will be described, followed by a description of the control of the game system 1 according to this embodiment.

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

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

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

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

[0045] 3, the main unit 2 includes a display 12 provided on the main surface of the housing 11. The display 12 displays images generated by the main unit 2. In this embodiment, the display 12 is a liquid crystal display (LCD). However, the display 12 may be any type of display device.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0063] The main unit 2 includes a network communication unit 82. The network communication unit 82 is connected to the processor 81. The network communication unit 82 communicates with external devices via a network (specifically, wireless communication). In this embodiment, the network communication unit 82 connects to a wireless LAN and communicates with external devices using a method conforming to the Wi-Fi standard as a first communication mode. The network communication unit 82 also performs wireless communication with other main units 2 of the same type using a predetermined communication method (e.g., communication using a proprietary protocol or infrared communication) as a second communication mode. Note that wireless communication using the second communication mode enables wireless communication with other main units 2 located within a closed local network area, and realizes a function that enables so-called "local communication," in which data is transmitted and received by direct communication between multiple main units 2.

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

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

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

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

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

[0069] The main unit 2 also includes an acceleration sensor 89. In this embodiment, the acceleration sensor 89 detects the magnitude of acceleration along three predetermined axes (for example, the x, y, and z axes shown in FIG. 1). The acceleration sensor 89 may also detect acceleration along one or two axes.

[0070] The main body device 2 also includes an angular velocity sensor 90. In this embodiment, the angular velocity sensor 90 detects angular velocities around three predetermined axes (for example, the x, y, and z axes shown in FIG. 1). Note that the angular velocity sensor 90 may also detect angular velocities around one axis or two axes.

[0071] The acceleration sensor 89 and the angular velocity sensor 90 are connected to the processor 81, and the detection results of the acceleration sensor 89 and the angular velocity sensor 90 are output to the processor 81. The processor 81 can calculate information related to the movement and / or attitude of the main unit 2 based on the detection results of the acceleration sensor 89 and the angular velocity sensor 90.

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

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

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

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

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

[0077] The left controller 3 includes buttons 103 (specifically, buttons 33 to 39, 43, 44, and 47). The left controller 3 also includes an analog stick (referred to as "stick" in FIG. 7) 32. Each button 103 and analog stick 32 repeatedly outputs information related to operations performed on the button 103 and analog stick 32 to the communication control unit 101 at appropriate timing.

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

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

[0080] By transmitting the above operation data to the main unit 2, the main unit 2 can obtain the input made to the left controller 3. That is, the main unit 2 can determine the operation of each button 103 and analog stick 32 based on the operation data. The main unit 2 can also calculate information about the movement and / or attitude 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).

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

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

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

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

[0085] As described above, in the game system 1 of this embodiment, the left controller 3 and right controller 4 are detachable from the main unit 2. Furthermore, by attaching an all-in-one device in which the left controller 3 and right controller 4 are attached to the main unit 2 or the main unit 2 alone to a cradle, it is possible to output images (and sounds) to an external display device such as a stationary monitor. In the following explanation, the game system 1 will be described in a usage mode in which images are displayed on the display 12. Note that when using the game system 1 in a usage mode in which images are displayed on the display 12, it is also possible to use a game system 1 in which the left controller 3 and right controller 4 are fixed to the main unit 2 (for example, in a mode in which the main unit 2, left controller 3, and right controller 4 are integrated into a single housing).

[0086] Game play is performed using a virtual space displayed on the display 12 in response to operations such as the operation buttons and sticks on the left controller 3 and / or right controller 4 of the game system 1, or touch operations on the touch panel 13 of the main unit 2. In this embodiment, as an example, in response to user operations using the operation buttons, sticks, and touch panel 13, game play can be performed using characters such as a player character PC and a field character FC that operate on a field in the virtual space, and a combat character BC that fights against the field character FC on the field.

[0087] An overview of the game processing performed in the game system 1 will be described using FIGS. 8 to 20. FIG. 8 is a diagram showing an example of a game image in a first stage of a scene in which a field character FC is captured. FIG. 9 is a diagram showing an example of a game image in a second stage of a scene in which a field character FC is captured. FIG. 10 is a diagram showing an example of a game image in a third stage of a scene in which a field character FC is captured. FIG. 11 is a diagram showing an example of a game image in a first stage of a scene in which a field character FC and a combat character BC are fighting. FIG. 12 is a diagram showing an example of a game image in a second stage of a scene in which a field character FC and a combat character BC are fighting. FIG. 13 is a diagram showing an example of a game image in a third stage of a scene in which a field character FC and a combat character BC are fighting. FIG. 14 is a diagram showing an example of a game image in a fourth stage of a scene in which a field character FC and a combat character BC are fighting. FIG. 15 is a diagram showing an example of a game image in a first stage of a scene in which a combat character BC is gathering a gathering object OBJ. FIG. 16 is a diagram showing an example of a game image in a second stage of a scene in which a combat character BC is gathering a gathering object OBJ. Fig. 17 is a diagram showing an example of an illustrated book display of a field character FC. Fig. 18 is a diagram showing an example of a game image in a scene where a boss character MC is attacked. Fig. 19 is a diagram showing an example of a game image in a first stage of a scene where a boss character MC and a combat character BC are fighting. Fig. 20 is a diagram showing an example of a game image in a second stage of a scene where a boss character MC and a combat character BC are fighting.

[0088] (First embodiment) As an example of this embodiment, a game process according to the first embodiment will be described. In the first embodiment, by switching between a first mode and a second mode, the player character PC is caused to perform a plurality of different types of actions, such as firing an item that affects a field character FC at a targeted field character FC on the field, and firing a combat character BC that fights against the field character FC on the field, by operating an operation input for causing the player character PC to perform an action of firing toward the target M.

[0089] In FIG. 8, a game image in which a player character PC is placed in a virtual space is displayed on the display 12 of the game system 1. The player character PC moves within the virtual space in response to user operations. The game image displayed on the display 12 also displays a field character FC placed in the virtual space. A plurality of field characters FC are placed on a field within the virtual space, and move within the virtual space under automatic control of the processor 81 based on a predetermined algorithm or the like. A user operating the player character PC can capture a field character FC by the operation of the player character PC and make it into the possession of the user.

[0090] The player character PC shown in Figure 8 is holding a ball item B and is about to throw the empty ball item B that it is holding into the virtual space. Here, the empty ball item B functions as a capture item that makes it possible to capture a field character FC by hitting the field character FC on the field. For example, when the empty ball item B thrown by the player character PC hits a field character, a capture success determination is made as to whether or not the capture is successful, and if the capture success determination is positive, the field character FC that was hit by the ball item B is captured and set to a state in which it is owned by the user.

[0091] For example, by performing a predetermined operation input (for example, by pressing the operation button (ZR button) 61), the user can cause the player character PC to take a stance to throw the selected item (for example, a stance as shown in FIG. 8). The direction in which the player character PC will throw the selected item is indicated by the aim M, and the position of the aim M moves in accordance with a predetermined operation input (for example, the tilt direction of the analog stick 32 or 52, the stance of the left controller 3 or right controller 4, the stance of the main body of the main body, the position pointed by the main body, etc.). Then, by the user releasing the operation input for taking the stance (for example, by releasing the pressed operation button (ZR button) 61), the player character PC takes a stance to throw the selected item in the direction indicated by the aim M.

[0092] For example, the user can change the category group that the player character PC throws by performing a predetermined operation input (for example, pressing the operation button (X button) 55). In the first embodiment, at least a first mode in which a first category group including a plurality of items that affect the field character FC is selected and a second mode in which a second category group including a plurality of combat characters BC that fight the field character FC on the field are selected are included, and the selected category group (mode) is switched by the user pressing the operation button 55. In addition, the user can select an item that the player character PC will throw from the selected category group by pressing the operation button (L button) 38 or the operation button (R button) 60. In the example shown in FIG. 8, the first category group (first mode) is selected, and thrown object information Im1 is displayed indicating that an empty ball item B has been selected from the first category group by the user. For example, the first category group may include multiple types of ball items with different performance and appearance, or may include items other than ball items that, when thrown, restrict the movement of the field character and thereby assist in throwing and capturing the ball item.

[0093] When an item selected from the first category group is selected as a thrown object, a first aim M1 (for example, an aim in a standard display mode) is displayed. Furthermore, when an empty ball item B that can capture a field character FC is selected as a thrown object from the first category group, the position of the first aim M1 can be moved by the operation of moving the aim M described above, but the user can also set (lock on) the first aim M1 to a position where it overlaps with the field character FC by performing a predetermined operation input (for example, pressing the operation button (ZL button) 39). Locking on the first aim M1 to the position of the field character FC makes it easier to hit the field character FC with a thrown item.

[0094] When the first sight M1 is locked on to the field character FC, capture information Ig indicating the likelihood of capturing the field character FC when an empty ball item B hits the field character FC is displayed near the first sight M1. For example, an indicator indicating the likelihood of a positive determination of the capture success determination for the field character FC, which is made when an empty ball item B thrown by the player character PC hits the field character FC, is displayed as the capture information Ig. The capture information Ig may be an indicator indicating one of multiple levels indicating the likelihood of a positive determination of the capture success determination, or an indicator indicating a numerical value indicating the probability or degree of a positive determination. Furthermore, the capture information Ig may be an indicator indicating the likelihood of a positive determination of the capture success determination using a design or text, an indicator indicating size or movement, or an indicator indicating color, brightness, or the like. Furthermore, the capture information Ig does not have to be displayed on the display 12; the likelihood of a positive determination of the capture success determination may be indicated by sound, vibration applied to the controllers 3 and / or 4, or the like.

[0095] 9 and 10, the display 12 displays a game image in which an empty ball item B thrown by the player character PC hits a field character FC and the field character FC is captured. For example, the user can cause the player character PC to perform an action of throwing the selected item toward the first aim M1 by releasing the operation input for causing the player character PC to take a ready position (for example, by releasing the pressed operation button (ZR button) 61). When the empty ball item B thrown by the player character PC hits the field character FC, an effect image is displayed indicating that the field character FC has been hit (and / or captured), as shown in FIG. 9. Then, when the field character FC is successfully captured, an effect image is displayed indicating that the field character FC has been captured by storing the field character FC inside the empty ball item B, as shown in FIG. 10. Then, the successfully captured field character FC is set to a state in which it is owned by the user. The successfully captured field character FC may be available to the user as a combat character BC in subsequent processing.

[0096] On the other hand, if the empty ball item B thrown by the player character PC does not hit the field character FC, or if the player character PC fails to capture the field character FC, an effect image showing the situation is displayed on the display 12. Here, if the player character PC fails to capture the field character FC, a demerit may occur, such as the field character FC running away or the field character FC attacking the player, initiating a battle.

[0097] In the above explanation, one of the conditions for successfully capturing a field character FC is that the empty ball item B thrown by the player character PC hits the field character FC, but it may also be possible to capture the field character FC even if the empty ball item B does not hit the field character FC, by the empty ball item B reaching within a predetermined range including the position of the field character FC. In this case, the ease of capture may be changed depending on whether or not the field character FC is hit.

[0098] Furthermore, the ease of capture may be changed depending on the state of the field character FC to be captured (emotions, durability, remaining stamina, size, action state, etc.) and the type of item thrown by the player character PC (for example, the type of empty ball item B). Even when the ease of capture changes in this way, the user can be made aware of the change by displaying capture information Ig near the first sight M1.

[0099] Furthermore, in the first embodiment, an empty ball item B was used as an example of an item selected from a first category group (first mode) that includes a plurality of items that affect the field character FC, but the first category group may also include other types of items. For example, the first category group may include an item that slows down the movement of the field character FC when hit, an item that drains the stamina of the field character FC when hit, an item that changes the emotions of the field character FC when hit, an item that attracts the field character FC, etc. By combining these items with the field character FC and placing them in a position where you want to attract the field character FC, it is possible to expect the effect of making it easier to capture the field character FC by throwing a capture item (for example, an empty ball item B).

[0100] In FIG. 11, in the second mode described above, the player character PC is holding a ball item Bs containing a combat character BC inside and is about to throw the ball item Bs into the virtual space. Here, the ball item Bs containing the combat character BC is thrown onto the field, causing the combat character BC to appear in the virtual space. For example, if the ball item Bs thrown by the player character PC is thrown near a field character FC, the combat character BC appears from the ball item Bs, and a battle with the field character FC begins. The battle begins directly on the field without switching locations.

[0101] For example, by performing a predetermined operation input (e.g., pressing the operation button (ZR button) 61), the user can cause the player character PC to take a stance to throw the selected combat character BC (ball item Bs) (e.g., a stance as shown in FIGS. 11 and 12). The direction in which the player character PC will throw the selected combat character BC (ball item Bs) is indicated by a crosshair M, and the position of the crosshair M moves in accordance with a predetermined operation input (e.g., the tilt direction of the analog stick 32 or 52, the stance of the left controller 3 or right controller 4, the stance of the controller, the position of the controller, and the like). Then, by the user releasing the operation input for taking the stance (e.g., releasing the pressed operation button (ZR button) 61), the player character PC takes a stance to throw the selected combat character BC (ball item Bs) in the direction indicated by the crosshair M.

[0102] As described above, the user can switch to the second category group (second mode) including a plurality of combat characters BC by performing a predetermined operation input (for example, pressing the operation button (X button) 55). Then, the user can select a combat character BC to be thrown by the player character PC from the selected second category group by performing a predetermined operation input (for example, pressing the operation button (L button) 38 or the operation button (R button) 60). For example, in the examples shown in FIGS. 11 and 12, the second category group (second mode) is selected, and thrown object information Im2 is displayed indicating that a predetermined combat character BC has been selected by the user from the second category group.

[0103] When a combat character BC selected from the second category group (a ball item Bs containing a combat character BC inside) is selected as the thrown object, a second sight M2 is displayed. The second sight M2 is displayed in a display manner different from that of the first sight M1. As an example, the second sight M2 differs from the standard display manner of the sight and is displayed as an indicator having a color that resembles the ball item Bs containing the combat character BC inside. In this way, by displaying the second sight M2 in a display manner different from that of the first sight M1, it becomes easier to see the object that the player character PC is about to throw while looking at the sight.

[0104] As shown in FIG. 12, when the second sight M2 is positioned so that it overlaps with the range within which the field character FC and the fighting character BC can fight, the second sight M2 is changed to the third sight M3. The third sight M3 is displayed in a display manner different from both the first sight M1 and the second sight M2. As an example, the third sight M3 is displayed as an indicator with a design that evokes fighting added to the center of the second sight M2. In this way, by displaying the third sight M3 in a display manner different from both the first sight M1 and the second sight M2, it becomes easy to understand, even while looking at the sight, that it is possible to fight the field character FC by throwing a ball item Bs that houses a fighting character BC inside.

[0105] In FIG. 13 , the display 12 displays a game image in which a combat character BC, which has appeared from a ball item Bs thrown by the player character PC, is fighting a field character FC. For example, the user can cause the player character PC to perform an action of throwing the ball item Bs containing the selected combat character BC toward the third sight M3 by releasing the operation input for causing the player character PC to take a stance (e.g., by releasing the pressed operation button (ZR button) 61). When the ball item Bs thrown by the player character PC reaches a range within which the player character FC can fight, the combat character BC appears from within that range. The combat character BC then begins fighting the field character FC. Therefore, in the first embodiment, various actions can be performed on the field character FC on the field by switching the category group (mode) of the thrown object through a common operation that causes the player character PC to perform a throwing action toward the sight M.

[0106] During a battle between a combat character BC and a field character FC, a gauge G1 indicating the state of the field character FC is displayed at a position set corresponding to the position of the field character FC. Here, the state of the field character FC indicated by the gauge G1 indicates at least a parameter related to the field character FC's remaining strength in the battle with the combat character BC, and indicates a parameter that gradually decreases in response to an effective attack by the combat character BC against the field character FC. When the remaining strength indicated by the gauge G1 reaches 0, the combat character BC wins the battle. As will become clearer below, the state of the field character FC indicated by the gauge G1 also serves as an indicator of the ease of capturing the field character FC during the battle.

[0107] As shown in FIG. 14, while a combat character BC and a field character FC are fighting, the user can control the actions of the player character PC and / or the combat character BC by selecting a command. For example, during a battle between a combat character BC and a field character FC, a plurality of command instruction images C are displayed for the user to select a command. For example, in FIG. 14, an attack command, an item command, an appearance / exit command, and an escape command are displayed as examples of command instruction images C. The user can select one of the comments by operating the input unit provided on the left controller 3 or the right controller 4 or the touch panel 12 of the main unit 2.

[0108] The user can control the movement of the combat character BC by performing an operation input to select an attack command. As an example, when an attack command is selected, the user is prompted to select from a plurality of attack contents, and by performing an operation to select from the plurality of attack contents, the user can cause the combat character BC to perform an attack movement corresponding to the attack content.

[0109] The user can control the actions of the player character PC by performing an operation input to select an item command. As an example, when an item command is selected, the user is prompted to select an item to use from a plurality of items including a capture item, and by performing an operation to select an item to use from the plurality of items, the user can cause the player character PC to perform an action using the selected item. As an example, by performing an operation during the battle to select a capture item for capturing a field character FC, the user can cause the player character PC to perform an action to capture the field character FC using the capture item.

[0110] The capture item used during battle may be the same as or similar to the ball item B described above. For example, if a command using a capture item is selected during battle, an effect is produced in which the player character PC throws the capture item so that it hits the field character FC during the battle. Whether the capture is successful or not is determined in the same manner as in a non-battle state. The capture success determination during battle is based on the state of the field character FC that changes during the battle, i.e., the state of the field character FC indicated by the gauge G1. Specifically, if the state of the field character FC that changes during the battle (e.g., remaining strength) has decreased to a predetermined state due to the battle, the capture success determination is more likely to be positive. Note that the threshold value may vary depending on at least one of the type of field character FC, the type of capture item selected by the command, the ability value of the player character PC, the ability value of the combat character BC, etc. Even if the capture success determination during battle is positive, the field character FC for which the command using the capture item was used is captured and set to a state owned by the user. As another example, even while a combat character BC and a field character FC are fighting, instead of operating by selecting a command, the player character PC may be caused to perform an operation of throwing a capture item toward the aim M, as in the capture outside of combat described above, thereby causing the player character PC to perform the action of capturing the field character FC using the capture item.

[0111] By performing an operation input to select an appearance / exit command, the user can make another combat character BC appear during the battle or make the combat character BC that is currently in the battle exit. The appearance may involve a new combat character BC replacing a combat character BC that has already appeared, or a new combat character BC may appear in addition to a combat character BC that has already appeared. For example, when the appearance / exit command is selected, the user is prompted to select one of a plurality of characters to appear or to select an exit command. By performing an operation to select one of the plurality of characters, the user can have the player character PC perform an action to make the selected character appear as a combat character BC.

[0112] Furthermore, by performing an operation input to select an escape command, the user can end the battle between the combat character BC and the field character FC and control the action of the player character PC to escape from the field character FC. At this time, the appearing combat character BC may be collected by the player character PC and exit the field, or may be left on the field.

[0113] In this way, even during a battle between a combat character BC and a field character FC, the field character FC can be captured in the same way as in a non-combat state by selecting a command that uses a capture item, so the user can choose whether to capture the field character FC without engaging in a battle using the combat character BC, or to engage in such a battle and capture the field character FC, thereby realizing a highly strategic game.

[0114] In the first embodiment, the player character PC throws a ball item Bs containing the combat character BC toward the target M, thereby releasing the combat character BC into the virtual space, but the combat character BC may also be released into the virtual space by directly throwing the combat character BC.

[0115] The position and orientation of the virtual camera for generating the game image displayed on the display 12 may be set so that the player character PC is included in the field of view from behind the player character PC, or may be set as the player character PC's first-person viewpoint. In either case, the position and / or orientation of the virtual camera may be changeable in response to user input. In this case, depending on the position and orientation of the player character PC in the virtual space, there may be scenes in which the field character FC during the battle is not included in the field of view, or the gauge G1 indicating the state of the field character FC is not included in the display range. However, if the position and / or orientation of the virtual camera is changeable in response to user input even during a battle between a combat character BC and a field character FC, even if the field character FC is not displayed when the battle between the combat character BC and the field character FC begins, the gauge G1 indicating the state of the field character FC, i.e., an indicator affecting the capture of the field character FC, can be displayed in response to user input. Furthermore, the player character PC may be able to move freely during battle in response to user input. Therefore, regardless of the scene in which the battle begins, the user can subsequently change to an appropriate camera, allowing the battle to begin freely regardless of the scene.

[0116] In addition, in the first embodiment, the combat character BC that appears from the ball item Bs can be made to perform actions on the field that are different from those in the battle. For example, in the first embodiment, the player character PC can simply make the combat character BC appear on the field in the virtual space by throwing a ball item Bs that contains the combat character BC onto the field, or the combat character BC that appears can be made to perform a predetermined action on a virtual object OBJ placed on the field.

[0117] For example, as shown in Fig. 15, collection objects OBJ are placed on a field in a virtual space. In the first embodiment, the player character PC may collect the collection objects OBJ by directly contacting the collection objects OBJ, but a combat character BC may also appear to collect the collection objects OBJ.

[0118] The player character PC shown in Fig. 15 is holding a ball item Bs with a combat character BC stored inside, similar to the state illustrated in Fig. 11, and by performing a predetermined operation input (for example, pressing the operation button (ZR button) 61), the player character PC is taking action to prepare to throw the selected combat character BC (ball item Bs). In the example shown in Fig. 15, the second category group (second mode) is selected, and thrown object information Im2 is displayed, indicating that a predetermined combat character BC has been selected from the second category group by the user.

[0119] As described above, when a combat character BC selected from the second category group (a ball item Bs containing a combat character BC inside) is selected as a thrown object, the second sight M2 is displayed. When the second sight M2 is positioned so as to overlap with the range within which the collection action of the collection object OBJ can be performed, the second sight M2 is changed to the fourth sight M4. The fourth sight M4 is displayed in a display manner different from the first sight M1, the second sight M2, and the third sight M3. As an example, the fourth sight M4 is displayed as an indicator with a design imitating a part of the combat character BC added to the center of the second sight M2. By displaying the fourth sight M4 in a display manner different from the first sight M1, the second sight M2, and the third sight M3 in this way, it becomes easy to understand, even while looking at the sights, that by throwing a ball item Bs containing a combat character BC inside, it is possible to cause a field character FC to appear in a state different from the above-mentioned battle.

[0120] 16, the display 12 displays a game image in which a combat character BC, which has emerged from a ball item Bs thrown by the player character PC, is collecting a collection object OBJ. For example, the user can cause the player character PC to perform an action of throwing the ball item Bs containing the selected combat character BC toward the fourth sight M4 by releasing the operation input for causing the player character PC to perform a ready action (e.g., by releasing the pressed operation button (ZR button) 61). When the ball item Bs thrown by the player character PC reaches a range within which the collection object OBJ can be collected, the combat character BC appears from within that range. The combat character BC then begins collecting the collection object OBJ.

[0121] In the first embodiment, information about the field character FC to which the reticle M is locked on can be displayed (pictorial encyclopedia display). For example, when a predetermined operation input is performed (for example, the operation button (down button) 34 or the down button on the cross key is pressed) while the first reticle M1 is locked on to the field character FC as shown in Fig. 8, that is, when an operation to display the pictorial encyclopedia is performed while locking on to the field character FC, information about the field character FC is displayed as shown in Fig. 17. Here, the information about the field character FC includes mission information about the history of missions in the game, including at least the number of field characters FC that the player character PC has captured that are locked on and the number of battles with those field characters FC. In the example of the field character FC encyclopedia display shown in FIG. 17, the locked-on field character A out of the multiple types of field characters FC is targeted, and the history for each item, such as the number of captures (the number of field characters A captured), the number of heavy-sized captures (the number of relatively heavy field characters A captured), the number of battles (the number of battles with field character A), the number of defeats (the number of field characters A defeated in battle), and the number of confirmed appearance types (the number of field character A types that appear in the virtual space and are displayed on the display 12), is displayed as information about the field character FC. Also, in the example of the field character FC encyclopedia display shown in FIG. 17, the missions to be achieved for each item and their progress are displayed. For example, the mission information includes a required number of times (the number of times the mission is achieved) for each item in the encyclopedia display, and for missions that have already been achieved, a mark (a check mark in the example of FIG. 17) indicating that the mission has been achieved is added to the required number of the mission.

[0122] In this way, by displaying the history information of the missions to be accomplished for the field character FC on the field, the information can be referred to when choosing whether to capture the field character FC or to fight the field character FC. Note that the display may also be configured to be able to display information about field characters FC of types other than the locked-on field character A. For example, in the example of FIG. 17, tags are provided for each type of field character FC (e.g., field characters A to E) at the right end of the display screen, and by performing an operation to select one of these tags, it becomes possible to display information about other types of field characters FC.

[0123] (Second embodiment) As another example of this embodiment, game processing according to a second embodiment will be described. In this embodiment, it is possible to battle against a boss character MC, which is an example of a field character located on a field in a virtual space. In the second embodiment, the game processing is directed to the boss character MC. Here, the boss character MC is a character that appears on the same field in the virtual space as the field character FC and attacks the player character PC and moves toward the player character PC. Therefore, the user must operate the player character PC so that the player character PC is not attacked by the boss character MC and so that the boss attack item AI hits the boss character MC. In the second embodiment, by switching between the first mode and the second mode, the player character PC is caused to perform multiple different types of actions, such as firing an item that affects the boss character MC at the boss character MC targeted on the field, and firing a combat character BC that engages in combat with the boss character MC on the field, by inputting an operation to cause the player character PC to fire at the target M.

[0124] 18, the display 12 displays a game image in which a player character PC and a boss character MC are arranged in a virtual space. For example, the boss character MC appears in the virtual space when the game transitions to a special event (e.g., a boss battle event) and, like the field character FC, operates on a field in the virtual space under automatic control of the processor 81 based on a predetermined algorithm or the like. A user operating the player character PC can engage in a battle between the player character PC or the battle character BC and the boss character MC. Note that the boss character MC may be a field character that cannot be captured, like the field character FC described above.

[0125] The player character PC shown in FIG. 18 is holding a boss attack item AI and is about to throw it into the virtual space. Here, the boss attack item AI is an item that progresses the boss battle event when it hits a boss character MC on the field. For example, a boss status parameter indicating the state of the boss character MC in the boss battle event is set, and when the boss attack item AI hits the boss character MC, the boss status parameter decreases. As an example, when the boss attack item AI thrown by the player character PC hits the boss character MC, an attack determination is made based on the position of the hit and the state of the boss character MC, and the amount of decrease based on the attack determination is subtracted from the boss status parameter of the boss character MC. Then, when the boss status parameter decreases to a threshold value (e.g., 0), the boss character MC is defeated and the boss battle event is cleared. In the example game image in FIG. 18, a gauge G2 indicating the remaining amount of the boss status parameter of the boss character MC is displayed at the top of the display screen.

[0126] Even during a boss battle event, the user can make the player character PC take a stance to throw the selected boss attack item AI (for example, take the stance shown in FIG. 18 ) by performing a predetermined operation input (for example, pressing the operation button (ZR button) 61). The direction in which the player character PC will throw the selected boss attack item AI is indicated by the first aiming point M1, and the position of the first aiming point M1 moves in accordance with a predetermined operation input (for example, the tilt direction of the analog stick 32 or 52, the stance of the left controller 3 or right controller 4, the action of the controller or the position it is pointing to, etc.). Then, by the user releasing the operation input for taking the stance (for example, releasing the pressed operation button (ZR button) 61), the player character PC takes the action of throwing the selected boss attack item AI in the direction indicated by the first aiming point M1.

[0127] Even during a boss battle event, the user can change the category group that the player character PC throws by performing a predetermined operation input (for example, pressing the operation button (X button) 55). In the second embodiment, at least a first mode in which a first category group including a plurality of items that affect the boss character MC is selected and a second mode in which a second category group including a plurality of combat characters BC that fight the boss character MC on the field are selected are included, and the selected category group (mode) is switched by the user pressing the operation button 55. In addition, the user can select an item that the player character PC will throw from the selected category group by pressing the operation button (L button) 38 or the operation button (R button) 60. For example, in the example shown in FIG. 18, the first category group (first mode) is selected, and thrown object information Im3 is displayed indicating that the user has selected a boss attack item AI from the first category group. Even during a boss battle event, if a boss attack item AI selected from the first category group is selected as a thrown item, the first sight M1 (for example, a sight in a standard display mode) is displayed.

[0128] As described above, by releasing the operation input for causing the player character PC to take a stance (for example, by releasing the pressed operation button (ZR button) 61), the player character PC can be made to throw the selected boss attack item AI toward the first target M1. If the boss attack item AI thrown by the player character PC hits the boss character MC, the boss state parameter of the boss character MC is subtracted based on the attack determination described above. On the other hand, if the boss attack item AI thrown by the player character PC does not hit the boss character MC, the boss state parameter of the boss character MC is maintained as is, or is added so as to increase the boss state parameter by a predetermined amount.

[0129] In the above explanation, one of the conditions for reducing the boss character MC's boss state parameter is that the boss attack item AI thrown by the player character PC hits the boss character MC, but the boss character MC's boss state parameter may also be reduced by the boss attack item AI reaching a predetermined range including the position of the boss character MC even if it does not hit the boss character MC directly.

[0130] Furthermore, in the second embodiment, the boss attack item AI was used as an example of an item selected from a first category group (first mode) containing multiple items that affect the boss character MC, but the first category group may also contain other types of items. For example, the first category group may contain items that slow down the movements of the boss character MC when hit, items that change the emotions of the boss character MC when hit, and items that attract the boss character MC. By combining these items with the boss character MC and placing them in a position to attract the boss character MC, it is possible to expect the effect of making it easier for the boss attack item AI to hit the boss character MC.

[0131] In the second embodiment, a battle character BC can be made to appear on the field, and a battle can be made between the battle character BC and a boss character MC. The player character PC shown in FIG. 19 is holding a ball item Bs containing the battle character BC and is about to throw the ball item Bs into the virtual space. Even during a boss battle event, the ball item Bs containing the battle character BC can be thrown onto the field to cause the battle character BC to appear in the virtual space. For example, if the ball item Bs thrown by the player character PC is thrown near the boss character MC, the battle character BC emerges from the ball item Bs, and a battle with the boss character MC begins. The battle with the boss character MC also begins directly on the field without a location change.

[0132] For example, even during a boss battle event, the user can make the player character PC prepare to throw the selected combat character BC (ball item Bs) (for example, assume the posture shown in FIG. 19 ) by performing a predetermined operation input (for example, pressing the operation button (ZR button) 61). The direction in which the player character PC will throw the selected combat character BC (ball item Bs) is indicated by the second sight M2, and the position of the second sight M2 moves in accordance with a predetermined operation input (for example, the tilt direction of the analog stick 32 or 52, the posture of the left controller 3 or right controller 4, the movement or pointing position of the respective controllers, etc.). Furthermore, as shown in FIG. 19 , even during a boss battle event, if the second sight M2 is positioned so as to overlap with the range in which the boss character MC and the combat character BC can fight, the second sight M2 is changed to the third sight M3.

[0133] Even during a boss battle event, the user can switch to a second category group (second mode) including a plurality of combat characters BC by performing a predetermined operation input (for example, pressing the operation button (X button) 55). Then, the user can select a combat character BC to be thrown by the player character PC from the selected second category group by performing a predetermined operation input (for example, pressing the operation button (L button) 38 or the operation button (R button) 60). For example, in the examples shown in FIGS. 19 and 20, the second category group (second mode) is selected, and thrown object information Im2 is displayed indicating that a predetermined combat character BC has been selected by the user from the second category group.

[0134] In FIG. 20 , the display 12 displays a game image in which a fighting character BC, which has appeared from a ball item Bs thrown by the player character PC, is fighting a boss character MC. For example, even during a boss battle event, by releasing the operation input for causing the player character PC to take a stance (e.g., by releasing the pressed operation button (ZR button) 61), the player character PC can be made to throw the ball item Bs containing the selected fighting character BC toward the third target M3. When the ball item Bs thrown by the player character PC reaches a range within which the player character MC can fight, the fighting character BC appears from within that range. The fighting character BC then begins fighting the boss character MC. Therefore, in the second embodiment, various actions can be taken against the boss character MC on the field by switching the category group (mode) of the thrown object through a common operation that causes the player character PC to throw the item toward the target M.

[0135] While the fighting character BC and the boss character MC are fighting, a gauge G3 indicating the state of the boss character MC in the battle with the fighting character BC is displayed at a position set corresponding to the position of the boss character MC. Here, the state of the boss character MC indicated by the gauge G3 indicates at least a parameter related to the boss character MC's remaining vitality in the battle with the fighting character BC, and indicates a parameter that gradually decreases in response to an effective attack by the fighting character BC against the boss character MC. When the remaining vitality indicated by the gauge G3 reaches 0, the fighting character BC wins the battle.

[0136] While the fighting character BC and the boss character MC are fighting, the user can control the actions of the fighting character BC by selecting a command. For example, the user can select from a plurality of attack commands to make the fighting character BC perform an attack action corresponding to the selected attack command.

[0137] In a battle between a boss character MC and a fighting character BC, if the fighting character BC wins, the conditions for clearing the boss battle event are adjusted to be easier to meet. As a first example, if the fighting character BC wins against the boss character MC, the movement of the boss character MC in the virtual space is restricted for at least a predetermined period of time. This makes it easier for the user to hit the boss character MC with the boss attack item AI and reduce the boss state parameter required to clear the boss battle event, thereby making it easier to meet the conditions for clearing the boss battle event. As a second example, if the fighting character BC wins against the boss character MC, the amount of reduction in the boss state parameter corresponding to hitting the boss character MC with the boss attack item AI is relatively increased for at least a predetermined period of time. This makes it easier for the user to reduce the boss state parameter, thereby making it easier to meet the conditions for clearing the boss battle event. As a third example, if the fighting character BC wins the battle against the boss character MC, the boss state parameter at the end of the battle is reduced by a predetermined amount. This makes it easier for the user to reduce the boss status parameter, which in turn makes it easier to meet the conditions for clearing the boss battle event. Note that in the second embodiment, adjustments may be made to make it easier to meet the conditions for clearing the boss battle event by combining at least two of the above examples.

[0138] Note that the start of a battle between a battle character BC and a boss character MC in the boss battle event may be possible only when the boss character MC is in a predetermined state. For example, the predetermined state may be a state in which the boss character MC is vulnerable, a state in which the boss character MC is in a predetermined posture, a state in which a boss state parameter of the boss character MC has reached a predetermined value, a state in which a predetermined time has passed since the start of the boss battle event, etc. Furthermore, the state in which the battle cannot be started may be a state in which the battle character BC does not appear even when the player character PC throws a ball item Bs, a state in which the player character PC does not perform a throwing motion even when an operation input for performing a throwing motion is performed, a state in which the ball item Bs cannot be selected as a thrown object, etc.

[0139] Thus, in the second embodiment, even in a boss battle event in which a boss character MC appears, it is possible to perform an operation to throw an item that affects the boss character MC (boss attack item AI) in the direction of the aim, and an operation to throw a combat character BC that fights the boss character MC in the direction of the aim, so the user can choose whether to attack the boss character MC using an item or to attack the boss character MC using a combat character BC, thereby realizing a highly strategic game.

[0140] Also, in the boss battle event, the position and attitude of the virtual camera for generating the game image to be displayed on the display 12 may be set so that the player character PC is included in the field of view from behind the player character PC, or may be set as a first-person viewpoint of the player character PC, and in either case, the position and / or attitude of the virtual camera may be configured to be changeable in response to user operation input.

[0141] In the first and second embodiments described above, an example was used in which the player character PC throws the ball at a target by switching between the first mode and the second mode, but many more modes may be provided. For example, a configuration may be made in which three or more modes can be switched by switching between a category group including a plurality of items that affect the combat character BC, a category group including a plurality of items that affect the collection object OBJ, a category group including a plurality of items that affect the player character PC, and a category group including a plurality of items that affect the virtual space.

[0142] Next, an example of specific processing executed by the game system 1 in the first and second embodiments will be described with reference to Figures 21 to 26. Figure 21 is a diagram showing an example of a data area set in the DRAM 85 of the main unit 2 in the first and second embodiments. In addition to the data shown in Figure 21, the DRAM 85 also stores data used in other processing, but detailed description thereof will be omitted.

[0143] The program storage area of ​​the DRAM 85 stores various programs Pa executed by the game system 1. In this embodiment, the various programs Pa store application programs (e.g., game programs) for performing information processing based on data acquired from the left controller 3 and / or right controller 4 or the main unit 2. The various programs Pa may be stored in advance in the flash memory 84, or may be acquired from a storage medium removable from the game system 1 (e.g., a predetermined type of storage medium inserted in the slot 23) and stored in the DRAM 85, or may be acquired from another device via a network such as the Internet and stored in the DRAM 85. The processor 81 executes the various programs Pa stored in the DRAM 85.

[0144] Furthermore, the data storage area of ​​the DRAM 85 stores various types of data used in processes such as information processing executed in the game system 1. In this embodiment, the DRAM 85 stores operation data Da, player character data Db, field character data Dc, boss character data Dd, battle character data De, collected object data Df, acquired character data Dg, history data Dh, item data Di, aiming data Dj, capture information data Dk, character battle ready flag data Dm, image data Dn, and the like.

[0145] The operation data Da is operation data acquired appropriately from the left controller 3 and / or right controller 4 and the main unit 2. As described above, the operation data acquired from the left controller 3 and / or right controller 4 and the main unit 2 includes information (specifically, information about the operation) related to inputs from the input units (specifically, each button, analog stick, touch panel). In this embodiment, operation data is acquired from the left controller 3 and / or right controller 4 and the main unit 2, and the acquired operation data is used to update the operation data Da as appropriate. The update cycle of the operation data Da may be every frame, which is the cycle of processing executed by the game system 1, which will be described later, or may be every cycle in which the operation data is acquired.

[0146] The player character data Db is data that indicates the position and posture of the player character PC placed in the virtual space, as well as the movement and state of the player character PC in the virtual space.

[0147] The field character data Dc is data indicating the type, position, posture, movement, status, etc. of each field character FC placed in the virtual space. The boss character data Dd is data indicating the type, position, posture, movement, status, etc. of a boss character MC placed in the virtual space.

[0148] The combat character data De is data that indicates the type, position, posture, movement, state, etc. of a combat character BC that appears in the virtual space.

[0149] The collection object data Df is data that indicates the type, placement position, placement attitude, placement state, etc. of each collection object OBJ placed in the virtual space.

[0150] The acquired character data Dg is data indicating the type and number of field characters FC (combat characters) that the user has acquired by capture or the like.

[0151] The history data Dh is data that indicates mission information relating to the history of missions within the game.

[0152] The item data Di is data that indicates the type and quantity of items that the player character PC possesses.

[0153] The aim data Dj is data that indicates the type and position of the aim that the player character PC will use to throw the projectile.

[0154] The capture information data Dk is data relating to capture information that indicates the likelihood of making a positive determination of the capture success determination for the locked-on field character FC.

[0155] The character battle available flag data Dm is data indicating a character battle available flag that is set to ON when a battle using a battle character BC is possible in a boss battle event.

[0156] The image data Dn is data for displaying images (e.g., an image of the player character PC, an image of the field character FC, an image of the boss character MC, an image of the combat character BC, an image of each item, an image of the collection object OBJ or other objects, an image of the aiming target, an image of the virtual space, a background image, etc.) on a display screen (e.g., the display 12 of the main device 2).

[0157] Next, a detailed example of the game processing in the first and second embodiments will be described with reference to FIGS. 22 to 26. FIG. 22 is a flowchart showing an example of the game processing executed by the game system 1. FIG. 23 is a subroutine showing a detailed example of the item use processing performed in step S125 in FIG. 22. FIG. 24 is a subroutine showing a detailed example of the first character use processing performed in step S127 in FIG. 22. FIG. 25 is a subroutine showing a detailed example of the boss item use processing performed in step S130 in FIG. 22. FIG. 26 is a subroutine showing a detailed example of the second character use processing performed in step S132 in FIG. 22. In this embodiment, the series of processes shown in FIGS. 22 to 26 are performed by the processor 81 executing a predetermined application program (game program) included in the various programs Pa. The game processing shown in FIGS. 22 to 26 may be started at any timing.

[0158] 22 to 26 are merely examples, and the order of the steps may be changed, or other processes may be performed in addition to (or instead of) the steps, as long as the same results are obtained. In addition, although the present embodiment describes the steps of the flowcharts as being executed by the processor 81, some of the steps in the flowcharts may be executed by a processor other than the processor 81 or a dedicated circuit. Some of the processes executed by the main unit 2 may be executed by another information processing device capable of communicating with the main unit 2 (for example, a server capable of communicating with the main unit 2 via a network). That is, the processes shown in FIGS. 22 to 26 may be executed by cooperation between a plurality of information processing devices, including the main unit 2.

[0159] 22, processor 81 performs initial settings in the game processing (step S121) and proceeds to the next step. For example, in the initial settings, processor 81 initializes parameters for performing the processing described below.

[0160] Next, processor 81 acquires operation data from left controller 3, right controller 4, and / or main unit 2, updates operation data Da (step S122), and proceeds to the next step.

[0161] Next, processor 81 determines whether a boss battle event is currently occurring (step S123). For example, if operation data Da does not indicate an instruction to start a boss battle event and if a boss battle event is not currently occurring, processor 81 proceeds to process step S124 assuming that the scene is a normal field scene. Note that a description of scenes in the game that are neither a boss battle event nor a normal field scene will be omitted. On the other hand, if operation data Da indicates an instruction to start a boss battle event or if a boss battle event is already occurring, processor 81 proceeds to process step S129.

[0162] In step S124, processor 81 determines, in accordance with the operation data Da, whether or not it is a scene in which an item is to be used. If the operation data Da indicates an instruction to use an item or if an effect in which an item is to be used is already in progress, processor 81 proceeds to process step S125. On the other hand, if the operation data Da does not indicate an instruction to use an item and an effect in which an item is to be used is not in progress, processor 81 proceeds to process step S126. As an example, processor 81 determines that the user operation instruction is to use an item when an operation input (e.g., pressing operation button (ZR button) 61) is made to cause the player character PC to prepare to throw an item and when the first category group (first mode) is selected as the object to be thrown by a predetermined operation input (e.g., pressing operation button (X button) 55). Note that, even if an effect in which an item is to be used is in progress, processor 81 makes a negative determination in step S124.

[0163] In step S125, processor 81 performs an item use process, and proceeds to step S134. Hereinafter, the item use process performed in step S125 will be described with reference to FIG.

[0164] 23, processor 81 determines whether or not item use effect processing is in progress (step S140). For example, if captured item use effect processing or item use effect processing has started in steps S149 and S153 described below, processor 81 makes a positive determination in step S140. If item use effect processing is not in progress, processor 81 proceeds to step S141. On the other hand, if item use effect processing is in progress, processor 81 proceeds to step S154.

[0165] In step S141, processor 81 sets an item to be thrown by player character PC, sets first aim M1, and proceeds to the next step. For example, processor 81 refers to operation data Da and item data Di, and selects and sets an item to be thrown from items possessed by player character PC in accordance with an operation input for selecting the item (for example, an operation input for pressing operation button (L button) 38 or operation button (R button) 60), and sets thrown object information Im1 (see FIGS. 8 and 9). Processor 81 also refers to operation data Da, and sets the type of aim to first aim M1 (see FIG. 8), and sets the position of the aim in accordance with an operation input for moving the aim (for example, the tilt direction of analog stick 32 or 52), thereby updating aim data Dj.

[0166] Next, processor 81 determines whether the item set in step S141 above is a capture item (e.g., empty ball item B) (step S142). If the item set in step S141 above is a capture item, processor 81 proceeds to step S143. On the other hand, if the item set in step S141 above is not a capture item, processor 81 proceeds to step S152.

[0167] In step S143, processor 81 determines whether or not a field character FC is locked on. For example, processor 81 refers to operation data Da, and if an operation input to lock on to a field character FC (for example, an operation input to press operation button (ZL button) 39) has been made, processor 81 makes an affirmative determination in step S143 above. If processor 81 has locked on to a field character FC, processor 81 proceeds to step S144. On the other hand, if processor 81 has not locked on to a field character FC, processor 81 proceeds to step S147.

[0168] In step S144, processor 81 sets the position of first aim M1 as the lock-on position, adds capture information Ig to first aim M1, and proceeds to the next step. For example, processor 81 extracts, based on field character data Dc, the field character FC located closest in front of the player character PC as the lock-on target. Processor 81 then sets a position that overlaps with a predetermined position (e.g., the center of gravity) of the field character FC extracted as the lock-on target as the position of first aim M1 to lock on, and updates aim data Dj. Processor 81 also calculates the probability that a positive determination will be made when a capture success determination for the field character FC is made, based on the type and state of the field character FC extracted as the lock-on target, and sets capture information Ig corresponding to the calculation result at a position to be added to first aim M1, thereby updating capture information data Dk.

[0169] Next, processor 81 determines whether or not it is a scene for displaying an illustrated book (step S145). For example, if operation data Da indicates an instruction to display an illustrated book (for example, an instruction to press operation button (down button) 34) or if the illustrated book is already being displayed, processor 81 proceeds to step S146. On the other hand, if operation data Da does not indicate an instruction to display an illustrated book and the illustrated book is not being displayed, processor 81 proceeds to step S148.

[0170] In step S146, processor 81 performs an illustrated book image setting process, and proceeds to step S148. For example, processor 81 references history data Dh to extract mission information relating to the history of missions in the game, such as the number of captures and the number of battles of the locked-on field character FC. Then, processor 81 sets an illustrated book image (see FIG. 17) of the locked-on field character FC based on the extracted mission information.

[0171] Meanwhile, in step S147, processor 81 determines whether first aim M1 is positioned to overlap the capture range of field character FC (step S147). For example, if aim data Dj and field character data Dc are used to set first aim M1 at a position where it is superimposed within the range in which any of field character data DC positioned on the field can be captured, a positive determination is made in step S147. Then, if processor 81 determines that first aim M1 is positioned to overlap the capture range of field character FC, processor 81 proceeds to process step S148. On the other hand, if processor 81 determines that first aim M1 is not positioned to overlap the capture range of field character FC, processor 81 proceeds to process step S152.

[0172] In step S148, processor 81 determines whether or not to throw the item. For example, processor 81 refers to operation data Da, and when an operation for performing the action of throwing the item (for example, an operation for canceling the operation for performing the above-mentioned ready action, such as an operation for releasing pressed operation button (ZR button) 61) has been performed, processor 81 makes an affirmative determination in step S148. Then, if processor 81 determines to throw the item, the process proceeds to step S149. On the other hand, if processor 81 determines not to throw the item, processor 81 ends the process of this subroutine.

[0173] In step S149, processor 81 starts a capture item use effect process in which player character PC throws the capture item, and then ends the processing of this subroutine. Note that with the start of the capture item use effect process, processor 81 updates aim data Dj so that the displayed first aim M1 is erased.

[0174] Meanwhile, in step S152, processor 81 determines whether or not to throw the item selected as the thrown object. For example, processor 81 refers to operation data Da, and when an operation for performing the action of throwing the item (for example, an operation for releasing the operation for performing the above-mentioned ready action, as one example, an operation for releasing pressed operation button (ZR button) 61) has been performed, processor 81 makes an affirmative determination in the above-mentioned step S152. Then, if processor 81 decides to throw the item, the process proceeds to step S153. On the other hand, if processor 81 decides not to throw the item, processor 81 ends the processing of this subroutine.

[0175] In step S153, processor 81 starts an item use effect process in which player character PC throws a capture item or an item other than the capture item, and then ends the processing of this subroutine. Note that, with the start of the item use effect process, processor 81 updates aim data Dj (and capture information data Dk) so that the displayed first aim M1 (and capture information Ig) is erased.

[0176] If it is determined in step S140 above that item use effect processing is in progress, processor 81 performs item use effect processing (step S154), and proceeds to the next step. For example, in the item use effect processing above, processor 81 sets the action of player character PC to throw the item selected as the thrown object (a capture item or an item other than a capture item) toward the position in the virtual space indicated by first sight M1, and also sets the action of moving within the virtual space by the item being thrown.

[0177] In the item use effect processing, after the effect of throwing the item is performed, processor 81 sets the effect of the item at the position where the item reaches. For example, processor 81 determines the effect of the item being thrown based on the type of item, the position where the thrown item reaches, the state of the target at which the item is thrown, etc. Then, processor 81 changes the target in virtual space at which the item is thrown based on the determination of the item effect. As an example, when an item that changes the state of a field character FC is thrown, the state of the field character FC is changed based on the result of the determination of the item effect, and the field character data Dc of the field character FC is updated.

[0178] In determining the effect of the item, it is possible that no effect will be obtained by throwing the item. For example, if the capture item is thrown outside the capture range of the field character FC, the item may fall into the virtual space or disappear without causing any change to the field character FC. Furthermore, if no effect will be obtained by throwing the item, the item may not be thrown. For example, if no effect will be obtained by throwing the item, the player character PC may be maintained in the ready position without starting the effect of throwing the item, even if the user performs an operation input to perform the action of throwing the item.

[0179] Furthermore, in the above-mentioned item use effect processing, when a situation arises in which the item use effect processing should be ended, processor 81 ends the item use effect processing and also ends the item use processing that uses the subroutine. Examples of situations in which the above-mentioned item use effect processing should be ended include when a condition for ending the item use effect processing is satisfied (for example, when the effect of the item is no longer being reflected on objects or characters in the virtual space), or when the user performs an operation to end the item use effect processing.

[0180] Next, processor 81 determines whether or not to perform capture determination processing (step S155). For example, if the movement of the thrown capture item in virtual space has ended and it is time to perform capture determination, processor 81 makes an affirmative determination in step S155. If processor 81 determines to perform capture determination processing, it proceeds to step S156. On the other hand, if it is not yet time to perform capture determination processing or if an item other than the capture item has been thrown, processor 81 ends the processing of this subroutine.

[0181] In step S156, processor 81 performs capture determination processing and proceeds to the next step. For example, processor 81 determines whether the capture of field character FC is successful based on the type of thrown capture item, whether the thrown capture item hits field character FC, the state of field character FC, etc.

[0182] Next, processor 81 determines whether or not the capture of field character FC was successful in the capture determination process of step S156 (step S157). If the capture of field character FC was successful, processor 81 proceeds to step S158. On the other hand, if the capture of field character FC was unsuccessful, processor 81 proceeds to step S159.

[0183] In step S158, processor 81 sets a successful capture effect, sets the successfully captured field character FC to be owned by the user, and ends the processing of this subroutine. For example, processor 81 sets a successful capture effect (see FIGS. 9 and 10) to be performed, which effects the capture of field character FC by storing the field character FC in an empty ball item B, ends the item use effect processing, and ends the item use processing that uses this subroutine. Processor 81 also updates acquired character data Dg so that the successfully captured field character FC is owned by the user.

[0184] In step S159, processor 81 sets a capture failure effect to be performed, and ends the processing of this subroutine. For example, processor 81 sets a capture failure effect to be performed, which effects that field character FC is not contained in empty ball item B, and ends the item use effect processing and the item use processing that uses this subroutine.

[0185] 22, if it is determined in step S124 that the scene is not one in which an item is to be used, processor 81 determines, in accordance with operation data Da, whether the scene is one in which a combat character is to be used (step S126). If operation data Da indicates an instruction to use a combat character or if an effect using a combat character is already in progress, processor 81 proceeds to process step S127. On the other hand, if operation data Da does not indicate an instruction to use a combat character and an effect using a combat character is not in progress, processor 81 proceeds to process step S128. As an example, processor 81 determines that the user operation instruction is one in which a combat character is to be used when an operation input (e.g., pressing operation button (ZR button) 61) is made to cause player character PC to prepare to throw the combat character and when a predetermined operation input (e.g., pressing operation button (X button) 55) is made to select the second category group (second mode) as a thrown object.

[0186] In step S127, processor 81 performs a first character use process, and proceeds to step S134. Hereinafter, the first character use process performed in step S127 will be described with reference to FIG.

[0187] 24, processor 81 determines whether or not a battle process for a battle character is in progress (step S161). For example, if a battle process for causing a battle character to fight a field character has started in step S167 described below, processor 81 makes an affirmative determination in step S161. If a battle process for a battle character is not in progress, processor 81 proceeds to process step S162. On the other hand, if a battle process for a battle character is in progress, processor 81 proceeds to process step S174.

[0188] In step S162, processor 81 determines whether or not the combat character appearance effect processing is in progress. For example, if the combat character appearance effect processing has started in step S172 described below, processor 81 makes an affirmative determination in step S162. If the combat character appearance effect processing is not in progress, processor 81 proceeds to step S163. On the other hand, if the combat character appearance effect processing is in progress, processor 81 proceeds to step S175.

[0189] In step S163, processor 81 sets a combat character to be thrown by player character PC, sets second aim M2, and proceeds to the next step. For example, processor 81 references operation data Da and acquired character data Dg, and in accordance with an operation input to select a combat character (for example, an operation input to press operation button (L button) 38 or operation button (R button) 60), selects and sets a combat character BC to be thrown from the characters owned by player character PC, and sets thrown object information Im2 (see FIGS. 11 to 16). Processor 81 also references operation data Da, and sets the type of aim to second aim M2 (see FIG. 11), and sets the position of the aim in accordance with an operation input to move the aim (for example, the tilt direction of analog stick 32 or 52), thereby updating aim data Dj.

[0190] Next, processor 81 determines whether second aim M2 is positioned to overlap a battle area in which a battle with field character FC is possible (step S164). For example, if processor 81 uses aim data Dj and field character data Dc to set second aim M2 to a position where it is superimposed on a battle area in which a battle with any of field character data DC positioned on the field is possible, processor 81 makes a positive determination in step S164. If second aim M2 is positioned to overlap the battle area, processor 81 proceeds to process step S165. On the other hand, if second aim M2 is not positioned to overlap the battle area, processor 81 proceeds to process step S169.

[0191] In step S165, processor 81 changes and sets second aim M2 to third aim M3, and proceeds to the next step. For example, processor 81 changes and sets the type of aim to third aim M3 (see FIG. 12), and updates aim data Dj.

[0192] Next, processor 81 determines whether to throw the combat character (step S166). For example, processor 81 references operation data Da and makes a positive determination in step S166 above when an operation for performing an action of throwing the combat character (ball item Bs) (for example, an operation for canceling the operation for performing the above-mentioned ready action, such as an operation of releasing pressed operation button (ZR button) 61) has been performed. Then, if processor 81 determines that the combat character will be thrown, the process proceeds to step S167. On the other hand, if processor 81 determines that the combat character will not be thrown, the process ends with this subroutine.

[0193] In step S167, processor 81 starts battle processing in which the battle character and the field character fight, and then ends the processing of this subroutine. Note that with the start of the battle processing, processor 81 updates aim data Dj so that the displayed third aim M3 is erased.

[0194] Meanwhile, in step S169, processor 81 determines whether second aim M2 is located at a position superimposing an appearance effect range in which a combat character can appear in the virtual space and perform an action other than the combat action. For example, processor 81 makes a positive determination in step S169 when, using aim data Dj and collection object data Df, second aim M2 is set at a position superimposed within a range in which an action (appearance effect) of collecting one of the collection objects OBJ (see FIGS. 15 and 16) located on the field can be performed. Then, if processor 81 determines that second aim M2 is located at a position superimposing the appearance effect range, it proceeds to step S170. On the other hand, if processor 81 determines that second aim M2 is not located at a position superimposing the appearance effect range, it ends the processing of this subroutine.

[0195] In step S170, processor 81 changes and sets second aim M2 to fourth aim M4, and proceeds to the next step. For example, processor 81 changes and sets the type of aim to fourth aim M4 (see FIG. 15), and updates aim data Dj.

[0196] Next, processor 81 determines whether to throw the combat character (step S171). For example, processor 81 references operation data Da and makes a positive determination in step S171 above when an operation for performing an action of throwing the combat character (ball item Bs) (for example, an operation for canceling the operation for performing the above-mentioned ready action, such as an operation of releasing pressed operation button (ZR button) 61) has been performed. Then, if processor 81 determines that the combat character will be thrown, the process proceeds to step S172. On the other hand, if processor 81 determines that the combat character will not be thrown, it ends the process of this subroutine.

[0197] In step S167, processor 81 starts an appearance effect process in which a combat character appears in the virtual space and performs an action other than combat, and then ends the processing of this subroutine. In addition, with the start of the appearance effect process, processor 81 updates aim data Dj so that the displayed fourth aim M4 is erased.

[0198] Note that, when an operation input is made to perform an action of throwing a combat character while a crosshair (specifically, the second crosshair 2) is superimposed and displayed outside the combat range and outside the appearance effect range, as one example, the combat character BC may not appear and the ball item Bs may fall or disappear into the virtual space. As another example, the ball item Bs containing the combat character BC may not be thrown. In this case, even if the user makes an operation input to perform an action of throwing the ball item Bs, the player character PC may be maintained in the above-mentioned ready position and the first character use processing may continue without starting the effect of throwing the ball item Bs. Alternatively, the first character use processing may be temporarily terminated without starting the effect of throwing the ball item Bs.

[0199] If it is determined in step S161 above that battle processing is in progress, processor 81 performs the battle processing (step S174) and ends the processing of this subroutine. For example, in the battle processing, processor 81 sets the action of the player character PC to throw a ball item Bs containing a battle character BC selected as a thrown object toward the position in virtual space indicated by the third sight M3, sets the action of the ball item Bs moving in virtual space as a result of being thrown, and sets a series of effects in which the battle character BC appears from the position in virtual space where the ball item Bs reaches. Then, after the series of effects are performed, processor 81 performs processing in which the appeared battle character BC and the field character FC fight each other.

[0200] During the battle processing, the processor 81 changes the states of the battle characters BC and the field characters FC through battle with the battle characters BC, and causes any character whose state has dropped below a predetermined threshold to be defeated in the battle. During the battle processing, the processor 81 also sets the actions of the battle characters BC and / or the player character PC in response to an operation input selecting a command to control the actions of the battle characters BC and / or the player character PC. For example, when the operation data Da indicates an operation input selected from a plurality of attack commands, the processor 81 controls the battle characters BC with an attack action corresponding to the attack command. Furthermore, when the operation data Da indicates an operation input selected from a command using a capture item to capture a field character FC during battle, the processor 81 causes the player character PC to perform an action to capture the field character FC using the capture item. The processor 81 then performs a capture success determination for the field character FC based on the above state of the field character FC, etc. If the capture success determination is affirmative, the processor 81 sets an effect in which the field character FC is captured, and sets the field character FC to a state owned by the user.

[0201] Furthermore, in the battle processing in step S161, when a situation arises in which the battle processing should be ended, processor 81 ends the battle processing and also ends the first character use processing that uses the subroutine. Circumstances in which the battle processing should be ended include, for example, when a condition for ending the battle processing is satisfied (for example, when a field character FC with which a battle character BC is fighting is captured, or when a battle character BC wins / loses the battle), or when the user performs an operation to end the battle processing, etc.

[0202] If it is determined in step S162 that the appearance effect processing is in progress, processor 81 performs the appearance effect processing (step S175) and ends the processing of this subroutine. For example, in the appearance effect processing, processor 81 sets the action of the player character PC to throw a ball item Bs containing a combat character BC selected as a thrown object toward the position in the virtual space indicated by the fourth sight M4, and sets the action of the ball item Bs moving in the virtual space as a result of being thrown, thereby setting a series of effects in which the combat character BC appears from the position in the virtual space where the ball item Bs reaches. Then, after the series of effects are performed, processor 81 performs appearance effect processing in which the appeared combat character BC performs a predetermined action (for example, the action of collecting a collection object OBJ).

[0203] In the appearance effect processing, when a situation arises in which the appearance effect processing should be ended, processor 81 ends the appearance effect processing and also ends the first character use processing that uses the subroutine. The situation in which the appearance effect processing is ended may be, for example, when a condition for ending the appearance effect processing is satisfied (for example, when the predetermined action by the combat character BC ends), or when the user performs an operation to end the appearance effect processing.

[0204] 22, if it is determined in step S126 above that the scene does not involve the use of a combat character, processor 81 performs other processing in accordance with operation data Da (step S128), and the process proceeds to step S134. As an example of the other processing, processor 81 performs processing to change the position and posture of player character PC in the virtual space in accordance with an operation input for moving player character PC indicated by operation data Da, thereby updating player character data Db.

[0205] If it is determined in step S123 that a boss battle event is in progress, processor 81 determines, in accordance with the operation data Da, whether or not a scene in which a boss item is to be used is occurring during the boss battle event (step S129). Then, if the operation data Da indicates an instruction to use a boss item or if an effect in which a boss item is to be used is already in progress, processor 81 proceeds to process step S130. On the other hand, if the operation data Da does not indicate an instruction to use a boss item and an effect in which a boss item is to be used is not in progress, processor 81 proceeds to process step S131. As an example, processor 81 determines that the user operation instruction is to use a boss item when an operation input (e.g., pressing operation button (ZR button) 61) is performed to cause the player character PC to prepare to throw a boss item and when the first category group (first mode) is selected as a thrown object by a predetermined operation input (e.g., pressing operation button (X button) 55). It should be noted that processor 81 makes a negative determination in step S129 above when operation data Da indicates an instruction to use a combat character, even during an effect in which a boss item is used.

[0206] In step S130, processor 81 performs a boss item use process, and proceeds to step S134. Hereinafter, with reference to FIG. 25, the boss item use process performed in step S130 will be described.

[0207] 25, processor 81 determines whether or not boss item use effect processing is in progress (step S180). For example, if boss item use effect processing has started in step S183 described below, processor 81 makes an affirmative determination in step S180. If boss item use effect processing is not in progress, processor 81 proceeds to process step S181. On the other hand, if boss item use effect processing is in progress, processor 81 proceeds to process step S188.

[0208] In step S181, processor 81 sets a boss item to be thrown by player character PC, sets first aim M1, and proceeds to the next step. For example, processor 81 refers to operation data Da and item data Di, and in response to an operation input to select the boss item (for example, an operation input to press operation button (L button) 38 or operation button (R button) 60), selects and sets a boss item to be thrown from items possessed by player character PC, and sets thrown object information Im3 (see FIG. 18). Processor 81 also refers to operation data Da, and sets the type of aim to first aim M1 (see FIG. 18), and sets the position of the aim in response to an operation input to move the aim (for example, the tilt direction of analog stick 32 or 52), thereby updating aim data Dj.

[0209] Next, processor 81 determines whether to throw a boss item (step S182). For example, processor 81 refers to operation data Da, and when an operation for performing the action of throwing a boss item (for example, an operation for releasing the operation for performing the above-mentioned ready action, such as an operation of releasing pressed operation button (ZR button) 61) has been performed, processor 81 makes an affirmative determination in the above-mentioned step S182. Then, when processor 81 determines to throw the boss item, the process proceeds to step S183. On the other hand, when processor 81 determines not to throw the boss item, the process proceeds to step S184.

[0210] In step S183, processor 81 starts boss item use effect processing in which the player character PC throws a boss item, and proceeds to step S184.

[0211] In step S184, processor 81 determines whether or not a state is present in which a combat character BC can be made to appear for a battle with a boss character MC. For example, if the boss character MC is in a predetermined state, processor 81 makes an affirmative determination in step S184. If the state is present in which a combat character BC can be made to appear, processor 81 proceeds to step S185. On the other hand, if the state is not present in which a combat character BC can be made to appear, processor 81 proceeds to step S186.

[0212] In step S185, processor 81 sets the character battle ready flag to ON to update character battle ready flag data Dm, and proceeds to step S186.

[0213] In step S186, processor 81 determines whether to end the boss battle event. Examples of situations in which the boss battle event may be ended include when a condition for ending the boss battle event is satisfied (for example, when a boss state parameter (see gauge G2 shown in FIG. 18) reaches a threshold, when the boss character MC wins / loses an event battle with the player character PC, when the event time expires, etc.), or when the user performs an operation to end the boss battle event. If processor 81 determines to end the boss battle event, the process proceeds to step S187. On the other hand, if processor 81 determines not to end the boss battle event, the process ends with this subroutine.

[0214] In step S187, processor 81 performs boss battle event end processing, and ends the processing of this subroutine. For example, processor 81 ends the boss item use processing, and performs boss battle event end processing by setting an effect in which boss character MC wins / loses against player character PC, etc.

[0215] If it is determined in step S180 above that the boss item use effect processing is in progress, processor 81 performs boss item use effect processing (step S188), and proceeds to step S186 above. For example, in the boss item use effect processing above, processor 81 sets the action of player character PC to throw the boss item selected as a thrown object toward the position in virtual space indicated by first sight M1, and sets the action of moving within the virtual space by throwing the boss item.

[0216] In the boss item use effect processing, after the effect of throwing the boss item is performed, processor 81 sets the effect of the boss item at the position where the boss item reaches. For example, processor 81 determines the effect of throwing the boss item based on the type of boss item, the position where the thrown boss item reaches, the position where the thrown boss item hits the boss character MC, the state of the boss character MC where the boss item was thrown, etc. Then, processor 81 changes the boss character MC where the boss item was thrown or an object in the virtual space based on the determination of the boss item effect. For example, when the boss item hits the boss character MC, processor 81 changes the state of the boss character MC (e.g., boss state parameters) based on the result of the determination of the boss item effect, and updates the boss character data Dd.

[0217] In the boss item use presentation process, when the situation arises where the boss item use presentation process needs to be terminated, processor 81 updates the aim data Dj so that the displayed first aim M1 is erased, terminates the boss item use presentation process, and terminates the boss item use presentation process that uses this subroutine. Examples of situations where the item use presentation process needs to be terminated include when a condition for terminating the item use presentation process is satisfied (for example, the effect of the boss item on the boss character MC in the virtual space has finished being reflected), or when the user performs an operation to terminate the boss item use presentation process.

[0218] 22, if it is determined in step S129 that the scene is not one in which a boss item is to be used, processor 81 determines, in accordance with operation data Da, whether the scene is one in which a combat character is to be used (step S131). Then, if the operation data Da indicates an instruction to use a combat character or if an effect using a combat character is already in progress, processor 81 proceeds to process step S132. On the other hand, if the operation data Da does not indicate an instruction to use a combat character and an effect using a combat character is not in progress, processor 81 proceeds to process step S133. As an example, processor 81 determines that the user operation instruction is one in which a combat character is to be used when an operation input (e.g., pressing operation button (ZR button) 61) is made to cause the player character PC to prepare to throw the combat character and when a predetermined operation input (e.g., pressing operation button (X button) 55) is made to select the second category group (second mode) as a thrown object.

[0219] In step S132, processor 81 performs a process for using a second character, and then proceeds to step S134. Hereinafter, the process for using a second character performed in step S132 will be described with reference to FIG.

[0220] 26, processor 81 determines whether or not a battle process between a battle character and a boss character is in progress (step S191). For example, if boss battle process in which a battle between a battle character and a boss character is in progress in step S197 described below, processor 81 makes an affirmative determination in step S191. If a battle process between a battle character and a boss character is not in progress, processor 81 proceeds to process step S192. On the other hand, if a battle process between a battle character and a boss character is in progress, processor 81 proceeds to process step S198.

[0221] In step S192, processor 81 sets a combat character to be thrown by player character PC, sets second aim M2, and proceeds to the next step. For example, processor 81 references operation data Da and acquired character data Dg, and in response to an operation input to select a combat character (e.g., an operation input to press operation button (L button) 38 or operation button (R button) 60), selects and sets a combat character BC to be thrown from the characters owned by player character PC, and sets thrown object information Im2 (see FIGS. 19 and 20). Processor 81 also references operation data Da, and sets the type of aim to second aim M2, and sets the position of the aim in response to an operation input to move the aim (e.g., the tilt direction of analog stick 32 or 52), thereby updating aim data Dj.

[0222] Next, processor 81 references character battle ready flag data Dm to determine whether the character battle ready flag is set to on (step S193). If the character battle ready flag is set to on, processor 81 proceeds to process step S194. On the other hand, if the character battle ready flag is set to off, processor 81 proceeds to process step S200.

[0223] In step S194, processor 81 determines whether second sight M2 is positioned to overlap a battle area in which a battle between boss character MC and combat character BC can take place. For example, if processor 81 determines, using aim data Dj and boss character data Dd, that second sight M2 is set to a position in which it is superimposed on a battle area in which a battle with boss character MC located on the field can take place, processor 81 makes a positive determination in step S194. If second sight M2 is positioned to overlap the battle area, processor 81 proceeds to step S195. On the other hand, if second sight M2 is not positioned to overlap the battle area, processor 81 proceeds to step S200.

[0224] In step S194, processor 81 changes and sets second aim M2 to third aim M3, and proceeds to the next step. For example, processor 81 changes and sets the type of aim to third aim M3 (see FIG. 19), and updates aim data Dj.

[0225] Next, processor 81 determines whether to throw the combat character (step S196). For example, processor 81 references operation data Da and makes a positive determination in step S196 above when an operation for performing an action of throwing the combat character (ball item Bs) (for example, an operation for canceling the operation for performing the above-mentioned ready action, such as an operation of releasing pressed operation button (ZR button) 61) has been performed. Then, if processor 81 determines that the combat character will be thrown, the process proceeds to step S197. On the other hand, if processor 81 determines that the combat character will not be thrown, the process ends with this subroutine.

[0226] In step S197, processor 81 starts boss battle processing in which a battle character and a boss character fight, and proceeds to step S200. With the start of the boss battle processing, processor 81 updates aim data Dj so that the displayed third aim M3 is erased.

[0227] In this embodiment, it is not necessary to provide the above-mentioned battle range in which the boss character MC and the fighting character BC can fight each other. In this case, regardless of the position of the second sight M2, it is changed to the third sight M3. Furthermore, regardless of the position of the changed third sight M3, it is possible for the player character PC to throw the fighting character BC and start boss battle processing to have the fighting character BC fight the boss character MC.

[0228] If it is determined in step S191 that battle processing is in progress, processor 81 performs boss battle processing (step S198) and proceeds to step S200. For example, in the boss battle processing, processor 81 sets the action of the player character PC to throw a ball item Bs containing a battle character BC selected as a thrown object toward the position in virtual space indicated by the third sight M3, sets the action of the ball item Bs moving in virtual space as a result of being thrown, and sets a series of effects in which the battle character BC appears from the position in virtual space reached by the ball item Bs. After the series of effects are performed, processor 81 performs processing in which the appeared battle character BC and boss character MC battle each other.

[0229] During the boss battle processing, processor 81 changes the states of the combat characters BC and field characters FC through battle with the combat characters BC, and causes any characters whose states have fallen below a predetermined threshold to be defeated in the battle. Also, during the boss battle processing, processor 81 sets the actions of the combat characters BC and / or player character PC in response to an operational input that selects a command to control the actions of the combat characters BC and / or player character PC. For example, when operation data Da indicates an operational input selected from a plurality of attack commands, processor 81 controls the combat characters BC with an attack action corresponding to the attack command.

[0230] Furthermore, in the boss battle processing in step S198, if a situation arises in which the boss battle processing should be ended, processor 81 ends the boss battle processing and also ends the second character use processing that uses the subroutine. The boss battle processing may be ended, for example, when a condition for ending the boss battle processing is satisfied (for example, boss character MC wins / loses the battle against battle character BC), or when the user performs an operation to end the boss battle processing, etc. If battle character BC wins the battle between boss character MC and battle character BC, processor 81 may, for example, make settings that restrict the movement of boss character MC within the virtual space for at least a predetermined period of time from the time of the victory, thereby making it easier to meet the conditions for clearing the boss battle event.

[0231] In step S200, processor 81 determines whether to end the boss battle event. Circumstances for ending the boss battle event include, for example, when a condition for ending the boss battle event is satisfied (for example, boss character MC wins / loses an event battle against player character PC, the event time expires, etc.), or when the user performs an operation to end the boss battle event, etc. If processor 81 determines to end the boss battle event, it proceeds to step S201. On the other hand, if processor 81 determines not to end the boss battle event, it ends the processing of this subroutine.

[0232] In step S201, processor 81 performs boss battle event end processing and ends the processing of this subroutine. For example, processor 81 ends the second character use processing and performs boss battle event end processing by setting an effect in which boss character MC wins / loses against player character PC, etc.

[0233] 22, if it is determined in step S131 that the scene does not involve the use of a combat character, processor 81 performs other processing in accordance with operation data Da (step S133), and proceeds to step S134. As an example of the other processing, processor 81 performs processing to change the position and posture of player character PC in the virtual space in accordance with an operation input for moving player character PC indicated by operation data Da, thereby updating player character data Db. Note that if the condition for ending the boss battle event is satisfied in step S128, processor 81 performs boss battle event end processing.

[0234] In step S134, processor 81 performs character movement processing and proceeds to the next step. For example, processor 81 sets the movements of each character in the virtual space, such as player character PC, battle character BC, field character FC, and boss character MC, and the remaining amounts of each gauge, based on the processing results of steps S122 to S133 above. As an example, processor 81 sets the position, posture, movement, status, and the like of each character, as well as the remaining amounts of each gauge, based on the settings made in steps S122 to S133 above, the progress of the set performance, the movement algorithm of the automatically controlled character, virtual physical calculations in the virtual space, and the operation input indicated by operation data Da, and updates player character data Db, field character data Dc, boss character data Dd, and battle character data De. As another example, when an in-game event or an in-game mission such as the boss battle event described above is started based on the game progress or the operation input indicated by the operation data Da, processor 81 causes a related character to appear in the virtual space in response to the start, sets the position, posture, movement, status, etc. of the character, and the remaining amount of each gauge, and updates each character data.

[0235] Next, processor 81 performs a display control process (step S135) and proceeds to the next step. For example, processor 81 arranges characters, objects, gauges, items, and the like in the virtual space based on the processing results of steps S122 to S134 and data related to each character, object, and item. Furthermore, processor 81 sets the position and orientation of a virtual camera based on the operation data Da and the position and orientation of the player character PC, and controls the generation and display of an image of the virtual space seen from the virtual camera on display 12. Furthermore, processor 81 controls the superimposition of the aiming and / or capture information on the image of the virtual space on display 12 based on the aiming data Dh and the capture information data Di. Note that the aiming and / or capture information may be arranged in the virtual space and displayed as part of the image of the virtual space seen from the virtual camera. Furthermore, when the encyclopedia display scene is displayed, processor 81 controls the display of the encyclopedia image set in step S146 on display 12.

[0236] Next, processor 81 determines whether or not to end the game processing (step S136). Conditions for ending the game processing in step S136 above include, for example, a condition for ending the game processing being satisfied, or the user performing an operation to end the game processing. If processor 81 does not end the game processing, it returns to step S122 above and repeats the process, and if it ends the game processing, it ends the process according to this flowchart. Thereafter, the series of processes from step S122 to step S136 are repeatedly executed until it is determined in step S136 that the process should end.

[0237] In this way, in this embodiment, by switching between the first mode and the second mode, it is possible to cause the player character PC to perform a number of different types of actions, such as firing an item that affects the field character FC or boss character MC at the field character FC or boss character MC that is targeted on the field, and firing a combat character BC that will fight the field character FC or boss character MC on the field, by inputting an operation to cause the player character PC to perform a firing action toward the target M.

[0238] In the above-described embodiment, examples of operation inputs for executing each process are described, but it goes without saying that the operation inputs do not have to be the examples. In this embodiment, in addition to operations using each operation button or stick, touch operations using the touch panel 13, operations using the movement or posture of the main unit 2, operations using the movement or posture of the left controller 3 or right controller 4, pointing operations using the left controller 3 or right controller 4, etc. may be used as the operation inputs.

[0239] In the above-described embodiment, the player character throws items or characters into the virtual space toward the target using a throwing action, but items or characters may be thrown into the virtual space using other actions. For example, the player character may kick, push, blow, shoot (fire, bombard, radiate, illuminate, etc.), hit, etc. to throw items or characters into the virtual space toward the target.

[0240] Furthermore, in the above-described embodiments, items described as having an effect when hitting a target such as a field character FC, a boss character MC, or a collection object OBJ may have an effect when reaching within a range formed near the target, even if the item does not hit the target. Conversely, in the above-described embodiments, items described as having an effect when reaching within a range formed near the target may have an effect when hitting the target. Furthermore, the process of locking onto one of the field characters FC in response to an operation input may be configured to allow locking onto the boss character MC in response to the same operation input during a boss battle event.

[0241] In the above-described embodiment, gauges G (gauges G1 to G3) are used to indicate the state of the field character FC and boss character MC, but these gauges G may indicate any parameters that indicate parameters that progress in-game missions or events. For example, parameters that progress in-game missions or events may indicate the state of a character, such as joy, anger, sorrow, happiness, endurance, remaining stamina, action state, or life value.

[0242] In addition, the in-game events and in-game missions in the above-described embodiments are assumed to be seamlessly connected throughout the entire game, and to be played on a field within the same virtual space. However, in this embodiment, even if the games are played on a field within the same virtual space, the scenes may be switched between events and missions.

[0243] Furthermore, the game system 1 may be any device, such as a portable game device or any portable electronic device (PDA (Personal Digital Assistant), mobile phone, personal computer, camera, tablet, etc.). In this case, the input device for performing operations to move the player character PC or the combat character BC does not have to be the left controller 3, the right controller 4, or the touch panel 13, but may be another controller, a mouse, a touchpad, a touch panel, a trackball, a keyboard, a cross key, a slide pad, etc.

[0244] Furthermore, although the above description uses an example in which information processing (game processing) is performed by the game system 1, at least some of the above processing steps may be performed by another device. For example, if the game system 1 is configured to be able to communicate with yet another device (e.g., a server, another information processing device, another image display device, another game device, or another mobile terminal), the above processing steps may be executed in cooperation with the other device. In this way, by executing at least some of the above processing steps in another device, processing similar to the above-described processing becomes possible. Furthermore, the above-described information processing may be executed by one processor or by cooperation between multiple processors included in an information processing system composed of at least one information processing device. Furthermore, in the above embodiment, information processing can be performed by the processor 81 of the game system 1 executing a predetermined program, but some or all of the above processing may be performed by a dedicated circuit provided in the game system 1.

[0245] According to the above-described modified example, the present invention can also be realized in a so-called cloud computing system configuration, or in a distributed wide area network or local network system configuration. For example, in a distributed local network system configuration, the above processing can be performed cooperatively between a stationary information processing device (stationary game device) and a portable information processing device (portable game device). Note that in these system configurations, there is no particular limitation on which device performs the above processing, and it goes without saying that the present invention can be realized regardless of the processing division.

[0246] Furthermore, the processing order, setting values, conditions used for judgment, etc. used in the information processing described above are merely examples, and it goes without saying that this embodiment can be realized even with other orders, values, and conditions.

[0247] The program may be supplied to the game system 1 not only through an external storage medium such as an external memory, but also through a wired or wireless communication line. The program may be pre-recorded in a nonvolatile storage device within the device. The information storage medium for storing the program may be a nonvolatile memory, a CD-ROM, a DVD, or similar optical disk-shaped storage media, a flexible disk, a hard disk, a magneto-optical disk, or a magnetic tape. The information storage medium for storing the program may also be a volatile memory for storing the program. Such a storage medium may be a recording medium readable by a computer or the like. For example, the various functions described above can be provided by having a computer or the like read and execute the program from such a recording medium.

[0248] Although the present invention has been described in detail above, the above description is merely illustrative of the present invention in all respects and is not intended to limit its scope. It goes without saying that various improvements and modifications can be made without departing from the scope of the present invention. Furthermore, those skilled in the art will understand that, from the description of specific embodiments of the present invention, they will be able to implement equivalents based on the description of the present invention and common technical knowledge. Furthermore, unless otherwise specified, it should be understood that the terms used in this specification are used in the same sense as commonly used in the art. Therefore, unless otherwise defined, all technical and technical terms used in this specification have the same meaning as commonly understood by those skilled in the art to which this invention belongs. In the event of any conflict, the present specification (including definitions) will prevail. [Industrial Applicability]

[0249] As described above, the present invention can be used as a game program, a game system, a game device, a game processing method, etc. that enable a player character to perform various types of actions on a field in a virtual space. [Explanation of symbols]

[0250] 1. Information processing system 2...Main unit 3...Left controller 4...Right controller 11. Housing 12...Display 13...Touch panel 32, 52...Analog stick 42, 64...Terminals 81...Processor 82...Network Communication Department 83...Controller communication section 85...DRAM 89, 104, 114...Acceleration sensors 90, 105, 115...Angular rate sensor 101, 111...Communication control unit

Claims

1. The computer of the information processing device Determine the aiming direction based on the directional input, In the first scene, based on an operation input, an event item that progresses an in-game event is fired by the player character in the aiming direction, and when the event item hits a field character arranged on a field in the virtual space, a state parameter of the field character is changed; In the second scene, A game program that determines, when a state parameter of the field character reaches a predetermined value due to a hit with the event item, that a state is in which a combat character that will engage in combat can be made to appear, and based on an operation input in that state, causes the player character to release the combat character in the aiming direction, and when the combat character is released at a location where the field character is located, causes a battle on the field between the field character and the combat character to begin.

2. The computer further comprises: In the in-game event, determining that the in-game event has been cleared when a plurality of the event items have been hit on the field character until a predetermined clearing condition is satisfied; The game program according to claim 1 , wherein control is performed so that the clear condition becomes easier to fulfill when the battle with the field character is won.

3. 3. The game program according to claim 2, wherein, when the player wins the battle with the field character, the movement of the field character within the virtual space is restricted for at least a predetermined period of time.

4. the clear condition is that the status parameter, which decreases each time the event item hits the field character, is reduced to a predetermined standard; 4. The game program according to claim 2, wherein, if the battle with the field character is won, the amount of decrease in the status parameter corresponding to hitting the event item within at least a predetermined period of time is made relatively large.

5. A gaming system including a processor, The processor: Determine the aiming direction based on the directional input, In the first scene, causing the player character to fire an event item, which causes an in-game event to progress based on an operation input, in the aiming direction, and when the event item hits a field character placed in a field in a virtual space, varying a state parameter of the field character; In the second scene, When the state parameter of the field character reaches a predetermined value due to a hit by the event item, the game system determines that the state is such that a combat character that will engage in combat can be made to appear, and based on an operation input in that state, causes the player character to release the combat character in the aiming direction, and when the combat character is released at a location where the field character is located, causes a battle on the field between the field character and the combat character to begin.

6. The processor further comprises: In the in-game event, determining that the in-game event has been cleared when a plurality of the event items have been hit on the field character until a predetermined clearing condition is satisfied; 6. The game system according to claim 5, wherein control is performed so that the clearing condition becomes easier to fulfill when the battle with the field character is won.

7. 7. The game system according to claim 6, wherein, when the battle with the field character is won, movement of the field character within the virtual space is restricted for at least a predetermined period of time.

8. the clear condition is that the status parameter, which decreases each time the event item hits the field character, is reduced to a predetermined standard; 8. The game system according to claim 6, wherein, if the battle with the field character is won, the amount of decrease in the status parameter corresponding to hitting the event item within at least a predetermined period of time is made relatively large.

9. A gaming device equipped with a processor, The processor: Determine the aiming direction based on the directional input, In the first scene, causing the player character to fire an event item, which causes an in-game event to progress based on an operation input, in the aiming direction, and when the event item hits a field character placed in a field in a virtual space, varying a state parameter of the field character; In the second scene, When the state parameter of the field character reaches a predetermined value due to a hit with the event item, the game device determines that the state is such that a combat character that will engage in combat can be made to appear, and based on an operation input in that state, causes the player character to release the combat character in the aiming direction, and when the combat character is released at a location where the field character is located, causes a battle between the field character and the combat character to begin on the field.

10. The processor further comprises: In the in-game event, determining that the in-game event has been cleared when a plurality of the event items have been hit on the field character until a predetermined clearing condition is satisfied; The game device according to claim 9 , wherein control is performed so that the clearing condition becomes easier to fulfill when the battle with the field character is won.

11. 11. The game device according to claim 10, wherein, when the battle with the field character is won, movement of the field character within the virtual space is restricted for at least a predetermined period of time.

12. the clear condition is that the status parameter, which decreases each time the event item hits the field character, is reduced to a predetermined standard; 12. The game device according to claim 10, wherein, when the battle with the field character is won, the amount of decrease in the status parameter corresponding to hitting the event item within at least a predetermined period of time is made relatively large.

13. The processor of the information processing device Determine the aiming direction based on the directional input, In the first scene, causing the player character to fire an event item, which causes an in-game event to progress based on an operation input, in the aiming direction, and when the event item hits a field character placed in a field in a virtual space, varying a state parameter of the field character; In the second scene, When a state parameter of the field character reaches a predetermined value due to a hit by the event item, the game processing method determines that the state is such that a combat character that will engage in combat can be made to appear, and based on an operation input in that state, causes the player character to release the combat character in the aiming direction, and when the combat character is released at a location where the field character is located, causes a battle on the field between the field character and the combat character to begin.

14. The processor further comprises: In the in-game event, determining that the in-game event has been cleared when a plurality of the event items have been hit on the field character until a predetermined clearing condition is satisfied; The game processing method according to claim 13, wherein control is performed so that the clearing condition becomes easier to fulfill when the battle with the field character is won.

15. 15. The game processing method according to claim 14, wherein, if the battle with the field character is won, movement of the field character within the virtual space is restricted for at least a predetermined period of time.

16. the clear condition is that the status parameter, which decreases each time the event item hits the field character, is reduced to a predetermined standard; 16. The game processing method according to claim 14, wherein, if the battle with the field character is won, the amount of decrease in the status parameter corresponding to hitting the event item within at least a predetermined period of time is made relatively large.

Images