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 performing processing on a character in a virtual space. [Background technology]

[0002] 2. Description of the Related Art There is a conventional 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 a state in which the player character owns the character (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 the above-mentioned non-patent document 1, the ball can be thrown to capture a character only 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, for example, the following configurations.

[0007] One configuration example of a game program of the present invention causes a computer of an information processing device to switch between at least a first mode and a second mode based on a first operation input, and in the first mode, determines an aiming direction in 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, and when the item is fired at a location where the field character is placed, gives the field character an effect associated with the item, and in the second mode, determines an 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, and when the combat character is fired at a location where the field character is placed, starts a battle on the field between the field character and the combat character.

[0008] According to the above, by switching between the first mode and the second mode, it is possible to cause the player character to perform a number of different types of actions, such as firing an item that has an effect on a field character at a targeted field character on the field, and firing a combat character that engages in combat with the field character on the field, by inputting an operation to fire the character at a target on the field.

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

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

[0011] In addition, the above 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 determination.

[0012] Based on the above, before releasing the capture item, it is possible to give an advantage in determining whether or not the capture item is successfully captured by using the capture item.

[0013] The above 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] The computer may further be caused to aim at the field character based on a fourth operation input.

[0016] Based on the above, the aiming direction can be easily directed toward the 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 a successful capture determination for the field character toward which the aiming direction is directed.

[0018] According to the above, the indicator can be used as a factor in determining whether or not to use the capture item to capture. In addition, since the indicator is displayed while the aiming direction is directed toward the field character, the user can release the capture item after making the above-mentioned determination.

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

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

[0021] The field character information may include mission information relating to a 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 a basis for deciding whether to capture or fight.

[0023] Furthermore, the computer may further be configured to, after the start of a battle, have a battle between a combat character and a field character take place on the 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 field character will be successfully captured using the capture item based on the state of the field character which changes during the battle, 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 at least the state of the field character with respect to physical strength at a position set corresponding to the position of the field character during battle, and control the orientation of the virtual camera based on a sixth operation input.

[0026] According to the above, even if the stamina indicator of the field character is not displayed, the orientation of the virtual camera can be changed by operational input, so that the indicator can be displayed if the user wishes.

[0027] Furthermore, in the second mode, when the computer sends a combat character to a location on the field where a collection object indicating that an item can be acquired is located, the combat character may be caused 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] The computer may further be configured to display an indicator indicating the aiming direction in a different display manner between 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 by hitting a field character. In this case, the computer may be caused to determine that an in-game event has been cleared when a plurality of event items have been hit against a field character until a predetermined clearing condition is met, and may be caused to control so that the clearing condition becomes easier to meet when a battle with the field character is won.

[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 with 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, by a combat character winning a battle between the combat character and a field character, it becomes easier to hit the field character with an item, and an in-game event can be cleared advantageously through the battle other than by releasing an item.

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

[0036] According to the above, it is possible to increase the effect of items released in in-game events, and it is possible to advantageously clear the in-game events through the above-mentioned battles other than releasing items.

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

[0038] According to the present invention, by switching between the first mode and the second mode, it is possible to cause the player character to 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 engages in combat with the field character on the field, by inputting an operation to fire the character at a target on the field. [Brief description of the drawings]

[0039] [Figure 1] FIG. 1 shows an example of a state in which a left controller 3 and a right controller 4 are attached to a main unit 2. [Diagram 2] FIG. 1 shows an example of a state in which the left controller 3 and the right controller 4 are removed from the main unit 2. [Diagram 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 [Diagram 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. 13 shows an example of a game image in the first stage of a scene in which a field character FC is captured. [Figure 9] FIG. 13 shows an example of a game image in the second stage of the scene in which the field character FC is captured. [Figure 10] FIG. 13 shows an example of a game image in the third stage of the scene where the field character FC is captured. [Figure 11] FIG. 13 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. 13 shows an example of a game image in the second stage of a battle scene between a field character FC and a combat character BC. [Figure 13]FIG. 13 shows an example of a game image in a third stage of a battle scene between a field character FC and a combat character BC. [Figure 14] FIG. 13 shows an example of a game image in a 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] FIG. 13 shows an example of a game image in the second stage where a combat character BC collects a collection object OBJ. [Figure 17] A diagram showing an example of the illustrated book display of a field character FC [Figure 18] FIG. 13 shows an example of a game image in which a boss character MC is attacked. [Figure 19] FIG. 13 shows an example of a game image in the first stage of a battle scene between a boss character MC and a battle character BC. [Figure 20] FIG. 13 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. 1 shows an example of a data area set in the DRAM 85 of the main unit 2 in this embodiment. [Figure 22] A flowchart showing an example of a game process 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. [Diagram 25] A subroutine showing a detailed example of the boss item use process performed in step S130 in FIG. [Figure 26] A subroutine showing a detailed example of the second character use process performed in step S132 in FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0040] A game system according to an example of this embodiment will be described below. An example of the game system 1 in 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 as a separate device from the main unit 2, the left controller 3, and the right controller 4 (see FIG. 2). The hardware configuration of the game system 1 of this embodiment will be described below, and then the control of the game system 1 of this embodiment will be described.

[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 includes a display 12. The left controller 3 and the right controller 4 are devices that include an operation unit that allows the user to perform input.

[0042] Fig. 2 is a diagram showing an example of a state in which the left controller 3 and the right controller 4 have been removed 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. In the following, the left controller 3 and the right controller 4 may be collectively referred to as "controller."

[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 in shape.

[0044] The shape and size of the housing 11 are arbitrary. As an example, the housing 11 may be of a size that is portable. Furthermore, the main unit 2 alone or an integrated device in which the left controller 3 and the 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 a main surface of a housing 11. The display 12 displays an image 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 unit 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 (e.g., a capacitive type). However, the touch panel 13 may be of any type, and may be of a type that allows single-touch input (e.g., a resistive film type), for example.

[0047] The main unit 2 includes 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 in 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 side terminal 17, which is a terminal through which the main unit 2 performs wired communication with the left controller 3, and a right side terminal 21 through which the main unit 2 performs wired communication with the right controller 4.

[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 attached thereto. 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 in the main unit 2 (e.g., application save data, etc.) and / or programs executed in the main unit 2 (e.g., application programs, etc.). The main unit 2 also includes a power button 28.

[0050] The main unit 2 includes 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 a function of charging the all-in-one device or the main unit 2 alone that is placed on it. The cradle also has a function of a hub device (more 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 FIG. 1 and FIG. 4). The left controller 3 can also be held in a vertically long orientation when removed 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 capable of inputting a direction. By tilting the analog stick 32, the user can input a direction according to the tilt direction (and input a magnitude according to the tilt angle). Note that the left controller 3 may include a cross key or a slide stick capable of slide input, instead of an analog stick, as the direction input unit. Also, in this embodiment, input is possible by pressing the analog stick 32.

[0053] The left controller 3 includes various operation buttons. The left controller 3 includes 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. Furthermore, the left controller 3 includes a record button 37 and a - (minus) button 47. The left controller 3 includes 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 also includes a second L button 43 and a second R button 44 on the side of the housing 31 that is attached when the left controller 3 is attached to the main unit 2. These operation buttons are used to give instructions according to various programs (for example, OS programs and application programs) executed on the main unit 2.

[0054] In addition, the left controller 3 is equipped with a terminal 42 that enables the left controller 3 to communicate with the main unit 2 via wire.

[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 removed 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] The right controller 4, like the left controller 3, includes an analog stick 52 as a direction 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 include a cross key or a slide stick capable of slide input, instead of the analog stick. The right controller 4, like the left controller 3, includes 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 further includes a + (plus) button 57 and a home button 58. The right controller 4 also includes a first R button 60 and a ZR button 61 on the upper right of the side surface of the housing 51. The right controller 4 also includes a second L button 65 and a second R button 66, like the left controller 3.

[0057] In addition, the right controller 4 is equipped with a terminal 64 for enabling the right controller 4 to communicate with the main unit 2 via wire.

[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 only a CPU (Central Processing Unit), or may be composed of a SoC (System-on-a-chip) including 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 (e.g., a game program) stored in a storage unit (specifically, an internal storage medium such as a flash memory 84, or an external storage medium inserted in the slot 23, etc.).

[0060] The main unit 2 includes a flash memory 84 and a dynamic random access memory (DRAM) 85 as examples of internal storage media built into the main unit 2. The flash memory 84 and the DRAM 85 are connected to the processor 81. The flash memory 84 is a memory used mainly for storing various data (which may be programs) saved in the main unit 2. The DRAM 85 is a memory used for temporarily storing various 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 in the slot 23 in response to an instruction from the processor 81.

[0062] The processor 81 appropriately reads and writes data from and to the flash memory 84, DRAM 85, and each of the above storage media to execute the above 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 an external device via a network (specifically, wireless communication). In this embodiment, the network communication unit 82 connects to a wireless LAN and communicates with an external device 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 (for example, communication using a unique protocol or infrared communication) as a second communication mode. Note that the 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 directly communicating between multiple main units 2.

[0064] The main unit 2 includes 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 the 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 the right controller 4 in accordance with the Bluetooth (registered trademark) standard.

[0065] The processor 81 is connected to the left terminal 17, the right terminal 21, and the lower terminal 27. When the processor 81 performs wired communication with the left controller 3, it 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 the processor 81 performs wired communication with the right controller 4, it 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 the processor 81 performs communication with the cradle, it transmits data to the cradle via the lower terminal 27. Thus, in this embodiment, the main unit 2 can perform both wired communication and wireless communication with the left controller 3 and the right controller 4. When the main unit 2 alone or an integrated device with the left controller 3 and the right controller 4 attached to the main unit 2 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 with a plurality of left controllers 3 simultaneously (in other words, in parallel). The main unit 2 can also communicate with a plurality of right controllers 4 simultaneously (in other words, in parallel). Therefore, a plurality of users can simultaneously input to the main unit 2 using each set of left controllers 3 and right controllers 4. As an 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 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-mentioned 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 speaker 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 speaker 88 and the audio input / output terminal 25.

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

[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 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 unit 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 unit of the main unit 2 (specifically, each unit that receives power from the battery 98, the left terminal 17, and the right terminal 21). The power control unit 97 controls the supply of power from the battery 98 to each of the above-mentioned units 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 unit 2 via lower terminal 27, battery 98 is charged with the supplied power.

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

[0075] The left controller 3 includes 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 by both wired communication via the terminal 42 and wireless communication not via the terminal 42. The communication control unit 101 controls the communication method by which the left controller 3 communicates with 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. Also, when the left controller 3 is detached from the main unit 2, the communication control unit 101 performs wireless communication with the main unit 2 (specifically, the controller communication unit 83). The wireless communication between the controller communication unit 83 and the communication control unit 101 is performed according to, 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 with, for example, 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 relating to operations performed on them to the communication control unit 101 at appropriate timing.

[0078] The left controller 3 includes an inertial sensor. Specifically, the left controller 3 includes an acceleration sensor 104. The left controller 3 also includes 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 in one or two axial directions. 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 by 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 specified process on the acquired information) to the main unit 2. The operation data is repeatedly transmitted once every specified 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 performed on the left controller 3. That is, the main unit 2 can determine the operations on the buttons 103 and the analog stick 32 based on the operation data. In addition, the main unit 2 can calculate information regarding 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 includes a communication control unit 111 that communicates with the main unit 2. The right controller 4 also includes 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 the memory 112 have the same functions as the communication control unit 101 and the memory 102 of the left controller 3. Therefore, the communication control unit 111 can communicate with the main unit 2 by both wired communication via the terminal 64 and wireless communication (specifically, communication in accordance with the Bluetooth (registered trademark) standard) that does not go through the terminal 64, and controls the method of communication that the right controller 4 uses with 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). Each of these input units has the same function as the input units of the left controller 3, and operates 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 the right controller 4 are detachable from the main unit 2. In addition, by mounting an integrated device in which the left controller 3 and the right controller 4 are mounted on the main unit 2 or the main unit 2 alone on 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. 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 a mode in which the left controller 3 and the right controller 4 are fixed to the main unit 2 (for example, a mode in which the main unit 2, the left controller 3, and the right controller 4 are integrated into one housing).

[0086] Game play is performed using a virtual space displayed on the display 12 in response to operations such as operations of the operation buttons and sticks on the left controller 3 and / or right controller 4 in the game system 1, or touch operations on the touch panel 13 of the main unit 2. In this embodiment, as an example, game play is possible 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 with the field character FC on the field in response to user operations using the operation buttons, sticks, and touch panel 13.

[0087] An outline of the game processing performed in the game system 1 will be described with reference to Figs. 8 to 20. Fig. 8 is a diagram showing an example of a game image in a first stage of a scene where 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 where 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 where 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 where a field character FC and a combat character BC fight. Fig. 12 is a diagram showing an example of a game image in a second stage of a scene where a field character FC and a combat character BC fight. Fig. 13 is a diagram showing an example of a game image in a third stage of a scene where a field character FC and a combat character BC fight. Fig. 14 is a diagram showing an example of a game image in a fourth stage of a scene where a field character FC and a combat character BC fight. Fig. 15 is a diagram showing an example of a game image in a first stage of a scene where a combat character BC collects a collection object OBJ. Fig. 16 is a diagram showing an example of a game image in a second stage of a scene where a combat character BC collects a collection 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 made to perform a plurality of different types of actions, such as firing an item that affects a field character FC at a field character FC aimed at the field, and firing a combat character BC that fights with the field character FC on the field, by inputting an operation for firing the player character PC toward the aim 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 in the virtual space in response to a user operation. 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 in the virtual space, and move in the virtual space under automatic control of a processor 81 based on a predetermined algorithm or the like. A user who operates the player character PC can capture the field character FC by the operation of the player character PC, and make it into a state in which the user owns the field character FC.

[0090] The player character PC shown in Fig. 8 is holding a ball item B and is about to throw the empty ball item B that he 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 when the capture success determination is judged to be positive, the field character FC hit by the ball item B is captured and set to a state in which it is owned by the user.

[0091] For example, the user can make the player character PC take a ready position to throw the selected item (for example, take a position shown in FIG. 8) 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 item is indicated by the aim M, and the position of the aim M moves according to a predetermined operation input (for example, the tilt direction of the analog stick 32 or 52, the position of the left controller 3 body or the right controller 4 body, the movement or pointing position of the body, etc.). Then, when the user releases the operation input for performing the ready position (for example, releasing the pressed operation button (ZR button) 61), the player character PC takes the action of throwing 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 with the field character FC on the field is selected are included, and the category group (mode) selected is switched by the user pressing the operation button 55. In addition, the user can select an item that the player character PC throws 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 indicating that an empty ball item B is selected from the first category group by the user is displayed. For example, the first category group may include multiple types of ball items with different performance and appearances, or may include items other than ball items that, when thrown, restrict the movement of a field character and thereby assist in throwing and catching a ball item.

[0093] When an item selected from the first category group is selected as a thrown object, the first aim M1 (for example, an aim in a standard display mode) is displayed. 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 set (lock on) the first aim M1 to a position superimposed on 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 the thrown item.

[0094] When the first sight M1 is locked on to the field character FC, capture information Ig indicating the ease of capturing the field character FC by hitting the field character FC with an empty ball item B is displayed near the first sight M1. For example, an indicator indicating the ease of a positive determination of the capture success determination for the field character FC, which is performed 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 a plurality of stages indicating the ease 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. In addition, the capture information Ig may be an indicator indicating the ease of a positive determination of the capture success determination by design or letters, an indicator indicating a size or movement, or an indicator indicating a color, brightness, or the like. In addition, the capture information Ig does not have to be displayed on the display 12, and the ease of a positive determination of the capture success determination may be indicated by a sound, a vibration applied to the controller 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 sight M1 by releasing the operation input for making the player character PC perform a ready action (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 in the empty ball item B as shown in FIG. 10. Then, the successfully captured field character FC is set to a state 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 fails to capture the field character FC, an effect image showing the situation is displayed on the display 12. Here, if the player 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, starting a battle, or the like.

[0097] In the above explanation, one of the conditions for successfully capturing the field character FC is that the empty ball item B thrown by the player character PC hits the field character FC, but even if the empty ball item B does not hit the field character FC, the field character FC may be captured 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] The ease of capture may be changed according to the state of the field character FC to be captured (emotions, durability, remaining vitality, 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 informed of the change by displaying capture information Ig in the vicinity of the first sight M1.

[0099] In the first embodiment, the empty ball item B is used as an example of an item selected from the first category group (first mode) including 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 it is hit, an item that takes away the physical strength of the field character FC when it is hit, an item that changes the joy, anger, sadness, and happiness of the field character FC when it is hit, an item that attracts the field character FC, and the like. By combining hitting the field character FC with these items or placing them at a position where the field character FC is desired to be attracted, 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 with a combat character BC inside, and is about to throw the ball item Bs into the virtual space. Here, the ball item Bs with the combat character BC inside is thrown onto the field, causing the combat character BC to appear in the virtual space. For example, when 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, the user can make the player character PC take a stance to throw the selected combat character BC (ball item Bs) (for example, a stance shown in FIG. 11 and FIG. 12) by performing a predetermined operation input (for example, pressing the operation button (ZR button) 61). The direction in which the player character PC throws the selected combat character BC (ball item Bs) is indicated by the aim M, and the position of the aim M moves according to a predetermined operation input (for example, the tilt direction of the analog stick 32 or 52, the stance of the left controller 3 body or the right controller 4 body, the action of the body or the position pointed to, etc.). Then, the user releases the operation input for taking the stance (for example, releasing the pressed operation button (ZR button) 61), and the player character PC takes a stance to throw the selected combat character BC (ball item Bs) in the direction indicated by the aim 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 example shown in FIG. 11 and FIG. 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 (a ball item Bs housing a combat character BC) selected from the second category group is selected as a thrown object, a second aim M2 is displayed. The second aim M2 is displayed in a display manner different from that of the first aim M1. As an example, the second aim M2 is displayed as an indicator having a color imitating a ball item Bs housing a combat character BC therein, unlike an aim in a standard display manner. In this way, by displaying the second aim M2 in a display manner different from that of the first aim M1, it becomes easier to understand the thrown object that the player character PC is about to throw, even while looking at the aim.

[0104] As shown in FIG. 12, when the second sight M2 is placed at a position where it overlaps with the range in 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 suggests a fight 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 contains the fighting character BC inside.

[0105] In FIG. 13, the display 12 displays a game image in which a combat character BC that appears 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 making the player character PC perform a ready action (for example, by releasing the pressed operation button (ZR button) 61). When the ball item Bs thrown by the player character PC reaches a range in which the player character FC can fight, the combat character BC appears from within the range. Then, the combat character BC starts fighting with 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 by a common operation for making the player character PC perform a throwing action toward the sight M.

[0106] During the battle between the combat character BC and the 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 remaining vitality of the field character FC in the battle with the combat character BC, and indicates a parameter that gradually decreases in response to an effective attack made by the combat character BC against the field character FC. When the remaining vitality indicated by the gauge G1 becomes 0, the combat character BC wins the battle. As will be made clear later, the state of the field character FC indicated by the gauge G1 also serves as an index indicating the ease of capturing the field character FC during the battle.

[0107] As shown in Fig. 14, while the combat character BC and the 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 the combat character BC and the 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 the command instruction images C. The user can select one of the comments by performing an operation input using an 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 the user can make the combat character BC move in an attack movement corresponding to the attack content by performing an operation to select from the plurality of attack contents.

[0109] The user can control the action 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 be used from a plurality of items including a capture item, and the user can perform an operation to select an item to be used from the plurality of items, thereby causing the player character PC to perform an action using the selected item. As an example, the user can perform an operation to select a capture item for capturing a field character FC during the battle, thereby causing the player character PC to perform an action of capturing the field character FC using the capture item.

[0110] The capture item used during the battle may be the same as or similar to the ball item B. For example, when a command using a capture item is selected during the battle, an effect is performed in which the player character PC throws the capture item so as to hit the field character FC during the battle, and whether or not the capture is successful is determined in the same manner as in the non-battle state. The capture success determination during the battle is performed based on the state of the field character FC that changes due to the battle, that is, the state of the field character FC indicated by the gauge G1. Specifically, when the state of the field character FC that changes due to the battle (for example, remaining strength) has decreased to a predetermined state due to the battle, the capture success determination is more likely to be determined as positive. Note that the threshold value may change according to at least one of the type of the field character FC, the type of the capture item selected by the command, the ability value of the player character PC, and the ability value of the combat character BC. Even if the capture success determination during the battle is determined as 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 when the combat character BC and the field character FC are fighting, instead of operating by selecting a command, the player character PC may be caused to throw a capture item toward the aim M, as in the capture outside of combat described above, thereby causing the player character PC to use the capture item to capture the field character FC.

[0111] The user can make another combat character BC appear during the battle or make the combat character BC exit the battle by performing an operation input to select an appearance / exit command. The appearance may be a new combat character BC replacing an already appearing combat character BC, or a new combat character BC may appear in addition to the already appearing combat character BC. As an example, when the appearance / exit command is selected, the user is prompted to select one of a plurality of characters to be made to appear or to select an exit command, and the user can make the player character PC perform an operation to select one of the plurality of characters to appear as a combat character BC.

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

[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 capture the field character FC by engaging in such a battle, 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; however, the combat character BC may also be released into the virtual space by directly throwing the combat character BC.

[0115] 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 the first-person viewpoint of the player character PC. In either case, the position and / or attitude of the virtual camera may be configured to be changeable in response to a user's operation input. In this case, depending on the position and orientation of the player character PC in the virtual space, there may be a scene in which the field character FC during the above-mentioned battle is not included in the field of view, or a gauge G1 indicating the state of the field character FC is not included in the display range. However, if the position and / or attitude of the virtual camera is configured to be changeable in response to a user's operation input even during a battle between a battle character BC and a field character FC, even if the battle between the battle character FC and the battle character BC starts in a state in which the field character FC is not displayed, the gauge G1 indicating the state of the field character FC, that is, an indicator that affects the capture of the field character FC, can be displayed in response to a user's operation. Also, the player character PC may be freely moved in response to a user's operation input even during a battle. Therefore, no matter what scene the battle starts in, the user can change to an appropriate camera thereafter, so that a configuration is possible in which the battle can be started freely regardless of the scene.

[0116] In the first embodiment, the combat character BC appearing from the ball item Bs can be made to perform actions on the field that are different from those in the above-mentioned battle. For example, in the first embodiment, the player character PC can throw a ball item Bs containing the combat character BC onto the field of the virtual space to simply make the combat character BC appear on the field, or the combat character BC can be made to perform a predetermined action on a virtual object OBJ arranged on the field to make the appearing combat character BC move.

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

[0118] The player character PC shown in FIG. 15 is holding a ball item Bs with a combat character BC housed 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 prepares 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 by the user from the second category group.

[0119] As described above, when a combat character BC (a ball item Bs containing a combat character BC) selected from the second category group is selected as a thrown object, the second sight M2 is displayed. When the second sight M2 is placed at a position overlapping with a range in which the collection action of the collection object OBJ is possible, the second sight M2 is changed to the fourth sight M4. The fourth sight M4 is displayed in a display mode 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. In this way, by displaying the fourth sight M4 in a display mode different from the first sight M1, the second sight M2, and the third sight M3, it becomes easy to understand, even while looking at the sight, that it is possible to make a field character FC appear in a state different from the above-mentioned battle by throwing a ball item Bs containing a combat character BC inside.

[0120] 16, a game image is displayed on the display 12 in which a combat character BC that has appeared 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 (for example, 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 the range. Then, the combat character BC starts collecting the collection object OBJ.

[0121] In the first embodiment, information on the field character FC to which the aim M is locked on can be displayed (picture book 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) with the first aim M1 locked on to the field character FC as shown in Fig. 8, that is, when an operation for displaying the picture book is performed while performing an operation to lock on to the field character FC, information on the field character FC as shown in Fig. 17 is displayed. Here, the information on the field character FC includes mission information related to the history of missions in the game, including at least the number of times the player character PC has captured the locked-on field character FC and the number of battles with the field character FC. In an example of the pictorial encyclopedia display of the field character FC shown in FIG. 17, the number of captures (the number of captures of field character A), the number of heavy size captures (the number of captures of relatively heavy field character A), the number of battles (the number of battles with field character A), the number of kills (the number of kills of field character A in battle), the number of types of confirmed appearances (the number of types of field character A that appear in the virtual space and are displayed on the display 12), and other history data are displayed as information of the field character FC. In addition, in an example of the pictorial encyclopedia display of the field character FC shown in FIG. 17, the missions to be achieved in each item and their progress are displayed. As an example, the mission information is displayed by displaying the required value (the number of times the mission is achieved) for each item in the pictorial encyclopedia display for each stage, and for the missions that have already been achieved, a mark (a check mark in the example of FIG. 17) indicating the completion is added to the required value of the mission.

[0122] In this way, the history information of the missions to be accomplished for the field character FC on the field is displayed, which can be referred to when selecting whether to capture the field character FC or to fight the field character FC. Note that the configuration may also be such that information on field characters FC of a type different from the locked-on field character A can be further displayed. 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, information on other types of field characters FC can also be displayed.

[0123] Second embodiment As another example of this embodiment, the game processing according to the second embodiment will be described. In this embodiment, it is also possible to fight against a boss character MC, which is an example of a field character arranged on a field in a virtual space, and in the second embodiment, the game processing is performed against the boss character MC. Here, the boss character MC is a character that appears on the field in the same virtual space as the field character FC, which attacks the player character PC and moves toward the player character PC. Therefore, the user needs to operate the player character PC so that the player character PC is not attacked by the boss character MC and can hit the boss character MC with a boss attack item AI. In the second embodiment, by switching between the first mode and the second mode, the player character PC is made to perform a plurality of different types of actions, namely, firing an item that affects the boss character MC at the boss character MC aimed at the target M and firing a combat character BC that fights the boss character MC on the field, by an operation input for causing the player character PC to perform an action of firing at the target M.

[0124] In Fig. 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 progresses to a special event (for example, a boss battle event), and is a character that operates on a field in the virtual space under automatic control of the processor 81 based on a predetermined algorithm or the like, similar to the field character FC. A user who operates the player character PC can fight between the player character PC or the battle character BC and the boss character MC. The boss character MC may be a field character that cannot be captured like the above-mentioned field character FC.

[0125] The player character PC shown in FIG. 18 is holding a boss attack item AI and is about to throw the boss attack item AI into the virtual space. Here, the boss attack item AI is an item that progresses the boss battle event by hitting the boss character MC on the field. For example, a boss state parameter indicating the state of the boss character MC in the boss battle event is set, and the boss state parameter decreases when the boss attack item AI hits the boss character MC. As an example, when the boss attack item AI thrown by the player character PC hits the boss character MC, an attack judgment 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 judgment is subtracted from the boss state parameter of the boss character MC. Then, when the boss state parameter decreases to reach a threshold value (for example, reach 0), the boss character MC is defeated and the boss battle event is cleared. In the example of the game image in FIG. 18, a gauge G2 indicating the remaining amount of the boss state 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 posture 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 throws the selected boss attack item AI is indicated by the first aim M1, and the position of the first aim M1 moves according to a predetermined operation input (for example, the tilt direction of the analog stick 32 or 52, the posture of the left controller 3 body or the right controller 4 body, the movement or pointing position of the body, etc.). Then, when the user releases 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 aim M1.

[0127] Even during the 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 with the boss character MC on the field is selected are included, and the category group (mode) selected is switched by the user pressing the operation button 55. In addition, the user can select an item to be thrown by the player character PC 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 throwing object information Im3 indicating that a boss attack item AI is selected from the first category group by the user is displayed. 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 making the player character PC take a ready action (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 judgment. 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 it is, or is added so that the boss state parameter increases by a predetermined amount.

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

[0130] In the second embodiment, the boss attack item AI is used as an example of an item selected from the first category group (first mode) including a plurality of items that affect the boss character MC, 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 boss character MC when it is hit, an item that changes the emotions of the boss character MC when it is hit, an item that attracts the boss character MC, etc. By combining hitting the boss character MC with these items or placing them in a position where the boss character MC is desired to be attracted, etc., 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, the battle character BC can be made to appear on the field, and the battle character BC can be made to fight the boss character MC. The player character PC shown in FIG. 19 is holding a ball item Bs containing the battle character BC inside, and is about to throw the ball item Bs being held into the virtual space. Here, the ball item Bs containing the battle character BC inside can be thrown onto the field even during a boss battle event, causing the battle character BC to appear in the virtual space. For example, when the ball item Bs thrown by the player character PC is thrown near the boss character MC, the battle character BC appears 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 switching the location.

[0132] For example, even during a boss battle event, the user can make the player character PC take a stance (for example, a stance shown in FIG. 19) to throw the selected combat character BC (ball item Bs) by performing a predetermined operation input (for example, pressing the operation button (ZR button) 61). The direction in which the player character PC throws the selected combat character BC (ball item Bs) is indicated by the second sight M2, and the position of the second sight M2 moves according to a predetermined operation input (for example, the tilt direction of the analog stick 32 or 52, the stance of the left controller 3 body or the right controller 4 body, the action or pointing position of the body, etc.). Also, as shown in FIG. 19, even during a boss battle event, if the second sight M2 is placed at a position overlapping with a 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 example shown in FIG. 19 and FIG. 20, the second category group (second mode) is selected, and thrown object information Im2 indicating that a predetermined combat character BC has been selected by the user from the second category group is displayed.

[0134] In FIG. 20, the display 12 displays a game image in which a fighting character BC that appears 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, the player character PC can be made to perform an action of throwing the ball item Bs containing the selected fighting character BC toward the third target M3 by releasing the operation input for making the player character PC take a ready action (for example, releasing the pressed operation button (ZR button) 61). When the ball item Bs thrown by the player character PC reaches a range in which the player character MC can fight, the fighting character BC appears from within the range. Then, the fighting character BC starts fighting the boss character MC. Therefore, in the second embodiment, various actions can be performed against the boss character MC on the field by switching the category group (mode) of the thrown object by a common operation for making the player character PC perform a throwing action toward the target M.

[0135] During the battle between the fighting character BC and the boss character MC, 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 remaining vitality of the boss character MC 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. Then, when the remaining vitality of the boss indicated by the gauge G3 becomes 0, the fighting character BC wins the battle.

[0136] During the battle between the combat character BC and the boss character MC, the user can control the action of the combat character BC by selecting a command. As an example, the user can select from a plurality of attack commands to cause the combat character BC to perform an attack action corresponding to the selected attack command.

[0137] In a battle between the boss character MC and the 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 at least within a predetermined period. This makes it easier for the user to hit the boss character MC with the boss attack item AI, and makes it easier to reduce the boss state parameter for clearing the boss battle event, which results in easier satisfaction of the clearing condition for 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 at least within a predetermined period is relatively increased. This makes it easier for the user to reduce the boss state parameter, which results in easier satisfaction of the clearing condition for the boss battle event. As a third example, if the fighting character BC wins 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 state parameters, which in turn makes it easier to meet the conditions for clearing the boss battle event. In the second embodiment, at least two of the above examples may be combined to make it easier to meet the conditions for clearing the boss battle event.

[0138] In addition, the start of the battle between the battle character BC and the 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 has an opening, a state in which the boss character MC is in a predetermined posture, a state in which the 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. In addition, the state in which the battle cannot be started may be a state in which the battle character BC does not appear even if the player character PC throws the ball item Bs, a state in which the player character PC does not perform a throwing action even if an operation input for performing a throwing action 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 of throwing an item that has an effect on the boss character MC (boss attack item AI) in the direction of the aim, and an operation of throwing a combat character BC that fights with the boss character MC in the direction of the aim, so that the user can choose whether to attack the boss character MC using an item or to attack the boss character MC using the combat character BC, thereby realizing a highly strategic game.

[0140] Also, in the above-mentioned 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 above-mentioned first and second embodiments, the first mode and the second mode are switched to each other, and the player character PC throws the ball toward the target. However, many more modes may be provided. For example, the mode may be configured to be switchable 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, a category group including a plurality of items that affect the virtual space, and the like, so that three or more modes can be switched.

[0142] Next, an example of a specific process executed by the game system 1 in the first and second embodiments will be described with reference to Fig. 21 to Fig. 26. Fig. 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 Fig. 21, the DRAM 85 also stores data used in other processes, 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 the 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 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, aim data Dj, capture information data Dk, character battle capable 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 the right controller 4 and the main unit 2. As described above, the operation data acquired from the left controller 3 and / or the right controller 4 and the main unit 2 includes information on inputs (specifically, information on operations) from each input unit (specifically, each button, analog stick, touch panel). In this embodiment, the operation data is acquired from the left controller 3 and / or the right controller 4 and the main unit 2, and the operation data Da is appropriately updated using the acquired operation data. The update cycle of the operation data Da may be updated every frame, which is the cycle of processing executed by the game system 1 described later, or may be updated every cycle in which the above 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 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, location, posture, movement, status, 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 related to the history of missions within the game.

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

[0153] The aim data Dj is data that indicates the type and position of the aim at which the player character PC throws a projectile.

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

[0155] The character battle capable flag data Dm is data indicating a character battle capable 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, images of each item, images of the collection object OBJ and other objects, an image of a target, an image of a virtual space, a background image, etc.) on a display screen (e.g., the display 12 of the main unit 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 flow chart 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, a series of processing shown in Figs. 22 to 26 is performed by the processor 81 executing a predetermined application program (game program) included in the various programs Pa. In addition, the timing at which the game processing shown in Figs. 22 to 26 is started is arbitrary.

[0158] 22 to 26 are merely examples, and the order of the steps may be changed, or other processes may be executed in addition to (or instead of) the steps, as long as the same results are obtained. In addition, in this embodiment, the steps of the flowchart are described as being executed by the processor 81, but some of the steps of the flowchart may be executed by a processor other than the processor 81 or a dedicated circuit. Some of the processes executed in the main unit 2 may be executed by another information processing device that can communicate with the main unit 2 (for example, a server that can communicate with the main unit 2 via a network). That is, the processes shown in FIGS. 22 to 26 may be executed by a plurality of information processing devices including the main unit 2 working together.

[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, the processor 81 acquires operation data from the left controller 3, the right controller 4, and / or the main unit 2, updates the operation data Da (step S122), and proceeds to the next step.

[0161] Next, processor 81 determines whether or not a boss battle event is in progress (step S123). For example, if operation data Da does not indicate an instruction to start a boss battle event and if the boss battle event is not currently in progress, 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 in progress, processor 81 proceeds to process step S129.

[0162] In step S124, the processor 81 determines whether or not it is a scene in which an item is to be used, according to the operation data Da. Then, when the operation data Da indicates an instruction to use an item or when an effect in which an item is to be used is already in progress, the processor 81 advances the process to step S125. On the other hand, when 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, the processor 81 advances the process to step S126. As an example, the processor 81 determines that the user operation instruction is to use an item when an operation input (e.g., pressing the operation button (ZR button) 61) for making the player character PC perform an action of preparing to throw an item is performed and the first category group (first mode) is selected as an object to be thrown by a predetermined operation input (e.g., pressing the operation button (X button) 55). Note that, even when an effect in which an item is to be used is in progress, when the operation data Da indicates an instruction to use a combat character, the processor 81 makes a negative determination in the above 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 presentation processing is in progress (step S140). For example, if capture item use presentation processing or item use presentation processing has started in steps S149 and S153 described below, processor 81 makes an affirmative determination in the above step S140. Then, if processor 81 is not in item use presentation processing, it proceeds to step S141. On the other hand, if processor 81 is in item use presentation processing, it 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 response to an operation input for selecting an 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 response to 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 is a capture item (e.g., empty ball item B) (step S142). If the item set in step S141 is a capture item, processor 81 proceeds to step S143. On the other hand, if the item set in step S141 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 makes a positive determination in step S143 if an operation input for locking on to a field character FC (for example, an operation input for pressing operation button (ZL button) 39) has been performed. Then, if processor 81 has locked on to a field character FC, processor 81 advances the process to step S144. On the other hand, if processor 81 has not locked on to a field character FC, processor 81 advances the process to step S147.

[0168] In step S144, processor 81 sets the position of first aim M1 as the position to be locked on, 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, a field character FC located at the closest position in front of the player character PC as a target to be locked on. Then, processor 81 sets a position displayed overlapping a predetermined position (e.g., center of gravity position) of the field character FC extracted as the target to be locked on as the position of first aim M1 to be locked on, and updates aim data Dj. Furthermore, processor 81 calculates the probability of a positive determination being made when a capture success determination of the field character FC is made based on the type and state of the field character FC extracted as the target to be locked on, and sets capture information Ig according to the calculation result at a position to be added to first aim M1, and updates capture information data Dk.

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

[0170] In step S146, processor 81 performs a pictorial book image setting process, and proceeds to step S148. For example, processor 81 refers to 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 locked-on field characters FC. Then, processor 81 sets a pictorial book image (see FIG. 17) of the locked-on field character FC based on the extracted mission information.

[0171] On the other hand, in step S147, processor 81 determines whether or not first aim M1 is arranged at a position superimposed on the capture range of field character FC (step S147). For example, if the first aim M1 is set at a position superimposed on the capture range of any of field character data DC arranged on the field using aim data Dj and field character data Dc, a positive determination is made in step S147. Then, if processor 81 determines that first aim M1 is arranged at a position superimposed on the capture range of field character FC, processor 81 advances the process to step S148. On the other hand, if processor 81 determines that first aim M1 is not arranged at a position superimposed on the capture range of field character FC, processor 81 advances the process to 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 makes a positive determination in the above-mentioned step S148 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 the pressed operation button (ZR button) 61) has been performed. Then, if processor 81 determines that the item will be thrown, it proceeds to step S149. On the other hand, if processor 81 determines that the item will not be thrown, it ends the processing of the subroutine.

[0173] In step S149, processor 81 starts a capture item use effect process in which the player character PC throws the capture item, and 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 the pressed operation button (ZR button) 61) has been performed, makes a positive determination in the above-mentioned step S152. Then, if processor 81 is to throw the item, it advances the process to step S153. On the other hand, if processor 81 is not to throw the item, it ends the process of the subroutine.

[0175] In step S153, processor 81 starts an item use effect process in which player character PC throws the capture item or an item other than the capture item, and ends the processing of this subroutine. Note that with the start of the item use effect process, processor 81 updates the 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 that the item use presentation process is in progress, processor 81 performs item use presentation process (step S154) and proceeds to the next step. For example, in the item use presentation process, 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 sets the action of moving in the virtual space by throwing the item.

[0177] In the item use effect process, 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 throwing the item based on the type of item, the position where the thrown item reaches, the state of the target where the item is thrown, etc. Then, processor 81 changes the target in the virtual space where 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 addition, in determining the effect of the item, it is possible that no effect is obtained by throwing the item. As an example, if the capture item is thrown outside the range where the field character FC can be captured, the item may fall or disappear in the virtual space without causing any change to the field character FC. Also, if no effect is obtained by throwing the item, the item may not be thrown. As an example, if no effect is obtained by throwing the item, the player character PC may be maintained in the above-mentioned ready posture without starting the performance of throwing the item, even if the user performs an operation input to perform the action of throwing the item.

[0179] In addition, in the above-mentioned item use presentation processing, when a situation arises in which the item use presentation processing should be ended, processor 81 ends the item use presentation processing and ends the item use processing using the subroutine. Examples of situations in which the item use presentation processing should be ended include when a condition for ending the item use presentation processing is satisfied (for example, 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 presentation processing.

[0180] Next, processor 81 determines whether or not to perform capture determination processing (step S155). For example, when the movement of the thrown capture item in the virtual space has ended and it is time to perform the capture determination processing, processor 81 makes an affirmative determination in the above step S155. Then, when processor 81 determines to perform the capture determination processing, it proceeds to step S156. On the other hand, when it is not yet time to perform the capture determination processing or when 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 or not the capture of field character FC is successful based on the type of the thrown capture item, whether or not 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 a state owned by the user, and ends the processing of the subroutine. For example, processor 81 sets a successful capture effect (see FIGS. 9 and 10) in which the field character FC is captured by being stored in an empty ball item B, ends the item use effect processing, and ends the item use processing that uses the 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 makes a setting for a capture failure effect to be performed, and ends the processing of the subroutine. For example, processor 81 makes a setting for a capture failure effect to be performed, which effects that the field character FC is not contained in the empty ball item B, and ends the item use effect processing and the item use processing that uses the subroutine.

[0185] Returning to FIG. 22, if it is determined in step S124 that the scene is not one in which an item is to be used, the processor 81 determines whether or not the scene is one in which a combat character is to be used, according to the operation data Da (step S126). Then, if the operation data Da indicates an instruction to use a combat character or if a performance using a combat character is already in progress, the processor 81 advances the process to step S127. On the other hand, if the operation data Da does not indicate an instruction to use a combat character and if a performance using a combat character is not in progress, the processor 81 advances the process to step S128. As an example, the 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 the operation button (ZR button) 61) is performed to cause the player character PC to take a stance to throw the combat character, and the second category group (second mode) is selected as a thrown object by a predetermined operation input (e.g., pressing the operation button (X button) 55).

[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 combat character is undergoing combat processing (step S161). For example, if a combat processing for causing a combat character to fight a field character has started in step S167 described below, processor 81 makes an affirmative determination in step S161. If a combat character is not undergoing combat processing, processor 81 proceeds to the process in step S162. On the other hand, if a combat character is undergoing combat processing, processor 81 proceeds to the process in step S174.

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

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

[0190] Next, processor 81 determines whether or not second aim M2 is arranged at a position superimposing a battle range in which a battle with field character FC can be performed (step S164). For example, when processor 81 uses aim data Dj and field character data Dc to set a position in which second aim M2 is superimposed and displayed in a battle range in which a battle with any of field character data DC arranged on the field can be performed, processor 81 makes a positive determination in the above step S164. Then, when processor 81 determines that second aim M2 is arranged at a position superimposing the above battle range, processor 81 advances the process to step S165. On the other hand, when processor 81 determines that second aim M2 is not arranged at a position superimposing the above battle range, processor 81 advances the process to step S169.

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

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

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

[0194] On the other hand, in step S169, the processor 81 determines whether the second aim M2 is arranged at a position overlapping the appearance performance range in which a combat character can appear in the virtual space and perform an action other than the combat. For example, when the second aim M2 is set at a position overlapping and displayed within a range in which an action (appearance performance) of collecting any of the collection objects OBJ (see FIG. 15 and FIG. 16) arranged on the field can be performed using the aim data Dj and the collection object data Df, the processor 81 makes a positive determination in the above step S169. Then, when the second aim M2 is arranged at a position overlapping the appearance performance range, the processor 81 advances the process to step S170. On the other hand, when the second aim M2 is not arranged at a position overlapping the appearance performance range, the processor 81 ends the process of the subroutine.

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

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

[0197] In step S167, processor 81 starts an appearance effect process for making a combat character appear in the virtual space and perform an action other than the combat, and 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] In addition, when an operation input is performed to perform an action of throwing a combat character in a state where a target (specifically, the second target 2) is superimposed and displayed outside the above-mentioned battle range and outside the above-mentioned appearance performance 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 performs 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 posture and the first character use process may be continued without starting the performance of throwing the ball item Bs. Also, the first character use process may be temporarily ended without starting the performance of throwing the ball item Bs.

[0199] If it is determined in step S161 that the battle process is in progress, processor 81 performs the battle process (step S174) and ends the processing of the subroutine. For example, in the battle process, 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 the virtual space indicated by the third sight M3, sets the action of moving the ball item Bs in the virtual space by being thrown, and sets a series of effects in which the battle character BC appears from the position in the virtual space where the ball item Bs reaches. Then, after the series of effects is performed, processor 81 performs processing in which the appeared battle character BC and the field character FC fight each other.

[0200] During the above-mentioned battle processing, the processor 81 changes the state of the battle character BC and the field character FC by fighting with the battle character BC, and causes a character whose state has fallen to a predetermined threshold value to be defeated in the battle. During the above-mentioned battle processing, the processor 81 sets the action of the battle character BC and / or the player character PC in response to an operation input for selecting a command for controlling the action of the battle character BC and / or the player character PC. For example, when the operation data Da indicates an operation input for selecting a command from among a plurality of attack commands, the processor 81 controls the battle character BC with an attack action corresponding to the attack command. When the operation data Da indicates an operation input for selecting a command for using a capture item for capturing the field character FC during the battle, the processor 81 causes the player character PC to perform an action of capturing the field character FC using the capture item. Then, the processor 81 performs a capture success determination for the field character FC based on the above-mentioned state of the field character FC, etc. When the above-mentioned capture success determination is determined to be positive, the processor 81 sets a performance 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 process in step S161, when a situation arises in which the battle process should be ended, processor 81 ends the battle process and ends the first character use process that uses the subroutine. Examples of situations in which the battle process should be ended include when a condition for ending the battle process is satisfied (for example, the field character FC with which the battle character BC is fighting is captured, the battle character BC wins / lose the battle, etc.), or when the user performs an operation to end the battle process, 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 the 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, sets the action of the ball item Bs moving in the virtual space by being thrown, and sets 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 the appearance effect processing in which the appeared combat character BC performs a predetermined action (for example, an action of collecting a collection object OBJ).

[0203] In the appearance effect process, when a situation arises in which the appearance effect process needs to be ended, processor 81 ends the appearance effect process and ends the first character use process that uses the subroutine. Examples of situations in which the appearance effect process needs to be ended include when a condition for ending the appearance effect process is satisfied (for example, the above-mentioned predetermined action by the combat character BC ends), or when the user performs an operation to end the appearance effect process.

[0204] 22, if it is determined in step S126 above that the scene does not use 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 the boss battle event is in progress, the processor 81 determines whether or not the boss battle event is in progress in a scene where a boss item is to be used, according to the operation data Da (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 used is already in progress, the processor 81 advances the process to 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 used is not in progress, the processor 81 advances the process to step S131. As an example, the processor 81 determines that the user operation instruction is to use a boss item when an operation input (e.g., pressing the operation button (ZR button) 61) for causing the player character PC to perform a motion of preparing to throw a boss item is performed and the first category group (first mode) is selected as a thrown object by a predetermined operation input (e.g., pressing the operation button (X button) 55). It should be noted that, even during an effect in which a boss item is used, if operation data Da indicates an instruction to use a combat character, processor 81 makes a negative determination in step S129 above.

[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 a boss item use effect process is in progress (step S180). For example, if the boss item use effect process has started in step S183 described below, processor 81 makes an affirmative determination in the above step S180. Then, if processor 81 is not in the boss item use effect process, it proceeds to step S181. On the other hand, if processor 81 is in the boss item use effect process, it proceeds to step S188.

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

[0209] Next, processor 81 determines whether or not to throw a boss item (step S182). For example, processor 81 refers to operation data Da and makes a positive determination in the above step S182 when an operation for performing an action of throwing a boss item (for example, an operation for releasing an operation for performing the above-mentioned ready action, as one example, an operation of releasing pressed operation button (ZR button) 61) has been performed. Then, if processor 81 determines to throw the boss item, it proceeds to step S183. On the other hand, if processor 81 determines not to throw the boss item, it 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 combat with boss character MC. For example, when the boss character MC is in a predetermined state, processor 81 makes an affirmative determination in step S184. Then, when processor 81 is in a state in which a combat character BC can be made to appear, processor 81 advances the process to step S185. On the other hand, when processor 81 is not in a state in which a combat character BC can be made to appear, processor 81 advances the process to step S186.

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

[0213] In step S186, processor 81 determines whether or not to end the boss battle event. Examples of situations in which the boss battle event is ended include when a condition for ending the boss battle event is satisfied (for example, the boss state parameter (see gauge G2 shown in FIG. 18) reaches a threshold value, the boss character MC wins / loses an event battle with the player character PC, 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, it proceeds to step S187. On the other hand, if processor 81 determines not to end the boss battle event, it ends the processing of 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 to player character PC, etc.

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

[0216] In the boss item use effect process, after the effect of throwing the boss item is performed, the processor 81 sets the effect of the boss item at the position where the boss item reaches. For example, the processor 81 determines the effect of throwing the boss item based on the type of the 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 is thrown, and the like. Then, the processor 81 changes the boss character MC where the boss item is thrown and the target in the virtual space based on the determination of the boss item effect. As an example, when the boss item hits the boss character MC, the processor 81 changes the state of the boss character MC (for example, boss state parameters) based on the determination result 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 using the 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 is terminated), or when the user performs an operation to terminate the boss item use presentation process.

[0218] Returning to FIG. 22, if it is determined in step S129 that the scene is not one in which a boss item is to be used, the processor 81 determines whether or not the scene is one in which a combat character is to be used, according to the operation data Da (step S131). Then, if the operation data Da indicates an instruction to use a combat character or if a performance using a combat character is already in progress, the processor 81 advances the process to step S132. On the other hand, if the operation data Da does not indicate an instruction to use a combat character and if a performance using a combat character is not in progress, the processor 81 advances the process to step S133. As an example, the 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 the operation button (ZR button) 61) is performed to cause the player character PC to take a stance to throw the combat character, and the second category group (second mode) is selected as a thrown object by a predetermined operation input (e.g., pressing the operation button (X button) 55).

[0219] In step S132, processor 81 performs a process for using a second character, and 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 the process in 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 the process in step S198.

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

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

[0223] In step S194, the processor 81 determines whether the second aim M2 is arranged at a position that overlaps the battle range in which the actions of the boss character MC and the battle character BC can be fought. For example, when the processor 81 uses the aim data Dj and the boss character data Dd to set the second aim M2 at a position that is superimposed and displayed within the battle range in which the battle with the boss character MC arranged on the field can be fought, the processor 81 makes a positive determination in the above step S194. Then, when the second aim M2 is arranged at a position that overlaps the above battle range, the processor 81 advances the process to step S195. On the other hand, when the second aim M2 is not arranged at a position that overlaps the above battle range, the processor 81 advances the process to step S200.

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

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

[0226] In step S197, processor 81 starts boss battle processing in which the battle character and the 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, the above-mentioned battle range in which the boss character MC and the fighting character BC can fight each other does not have to be provided. In this case, no matter where the second aim M2 is located, it is changed to the third aim M3. Also, no matter where the changed third aim M3 is located, it is possible to start the boss battle process in which the player character PC throws the fighting character BC and makes the fighting character MC fight the boss character MC.

[0228] If it is determined in step S191 that the battle process is in progress, processor 81 performs boss battle process (step S198) and proceeds to step S200. For example, in the boss battle process, 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 the virtual space indicated by the third sight M3, sets the action of the ball item Bs moving in the virtual space by being thrown, and sets a series of effects in which the battle character BC appears from the position in the virtual space reached by the ball item Bs. Then, after the series of effects are performed, processor 81 performs a process in which the appeared battle character BC and boss character MC fight each other.

[0229] During the boss battle process, the processor 81 changes the state of the battle character BC and the field character FC through a battle with the battle character BC, and causes any character whose state has fallen below a predetermined threshold to be defeated in the battle. Also, during the boss battle process, the processor 81 sets the behavior of the battle character BC and / or the player character PC in response to an operation input that selects a command for controlling the behavior of the battle character 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 character BC with an attack behavior corresponding to the attack command.

[0230] Also, in the boss battle process in step S198, when a situation arises in which the boss battle process should be ended, processor 81 ends the boss battle process and ends the second character use process using the subroutine. Examples of situations in which the boss battle process should be ended include when a condition for ending the boss battle process is met (for example, boss character MC wins / lose in a battle with battle character BC) or when the user performs an operation to end the boss battle process. Note that when the battle character BC wins against the boss character MC in the battle between the boss character MC and the battle character BC, processor 81 adjusts the boss battle event so that the clearing conditions are more easily met, for example by making settings that limit the movement of the boss character MC in the virtual space at least within a predetermined period of time from the time of the victory.

[0231] In step S200, processor 81 determines whether or not to end the boss battle event. Examples of situations in which the boss battle event is ended include when a condition for ending the boss battle event is satisfied (e.g., 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. Then, if processor 81 decides to end the boss battle event, it proceeds to step S201. On the other hand, if processor 81 does not decide to end the boss battle event, it ends the processing of the subroutine.

[0232] In step S201, processor 81 performs boss battle event end processing, and ends the processing of the 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 to player character PC, etc.

[0233] 22, if it is determined in step S131 that the scene does not use 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, and update player character data Db. Note that, if a 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 action processing, and proceeds to the next step. For example, processor 81 sets the actions 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 amount of each gauge, based on the processing results of steps S122 to S133 above. As an example, processor 81 sets the position, posture, action, state, and the like of each character and the remaining amount of each gauge, based on the contents set in steps S122 to S133 above, the progress of the set performance, the action algorithm of the automatically controlled character, the virtual physical calculation in the virtual space, the operation input indicated by the operation data Da, and the like, 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 makes a related character appear in the virtual space in response to the start, and sets the position, posture, movement, status, etc. of the character and the remaining amount of each gauge, thereby updating each character data.

[0235] Next, the processor 81 performs a display control process (step S135) and proceeds to the next step. For example, the processor 81 arranges each character, object, gauge, item, and the like in the virtual space based on the process results of the above steps S122 to S134 and data related to each character, object, and item. The processor 81 also performs control to set the position and attitude of the virtual camera based on the operation data Da and the position and orientation of the player character PC, generate an image of the virtual space seen from the virtual camera, and display it on the display 12. The processor 81 also performs control to superimpose the aim and / or capture information on the image of the virtual space based on the aim data Dh and the capture information data Di and display it on the display 12. Note that the aim and / or capture information may be displayed as part of the image of the virtual space seen from the virtual camera by arranging it in the virtual space. The processor 81 also performs control to display the encyclopedia image set in the above step S146 on the display 12 when it is an encyclopedia display scene.

[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 to repeat 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 is repeatedly executed until it is determined in step S136 that the process is to end.

[0237] In this manner, 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 has an effect on the field character FC or boss character MC at the targeted field character FC or boss character MC on the field, and firing a combat character BC that engages in combat with 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-mentioned 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 above 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 body, operations using the movement or posture of the left controller 3 body or the right controller 4 body, pointing operations using the left controller 3 body or the right controller 4 body, etc. may be used as the above-mentioned operation inputs.

[0239] In the above embodiment, the player character throws items or characters into the virtual space toward the target, but other actions may be used to throw items or characters into the virtual space. For example, the player character may kick, push, blow, shoot (fire, bombard, radiate, irradiate, etc.), hit, or the like to throw items or characters into the virtual space toward the target.

[0240] In the above-mentioned embodiment, an item described as having an effect when it hits a target such as a field character FC, a boss character MC, or a collection object OBJ may have an effect when it reaches within a range formed near the target without hitting the target. Conversely, an item described as having an effect when it reaches within a range formed near the target in the above-mentioned embodiment may have an effect when it hits the target. In addition, the process of locking on to any of the field characters FC in response to an operation input may be configured to lock on to the boss character MC in response to the same operation input during a boss battle event.

[0241] In the above embodiment, gauges G (gauges G1 to G3) are used to indicate the state of the field character FC and the boss character MC, but these gauges G may indicate any parameter as long as they indicate a parameter that progresses a mission or an event in the game. For example, the parameter that progresses a mission or an event in the game may indicate the state of the character's emotions, durability, remaining physical strength, operating state, life value, etc.

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

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

[0244] In the above description, an example was used in which the information processing (game processing) is performed by the game system 1, but at least a part of the above processing steps may be performed by another device. For example, if the game system 1 is configured to be capable of communicating with another device (e.g., a server, another information processing device, another image display device, another game device, another mobile terminal), the above processing steps may be executed by the cooperation of the other device. In this way, by performing at least a part of the above processing steps by another device, processing similar to the above processing is possible. In addition, the above information processing can 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. In the above embodiment, the processor 81 of the game system 1 can execute a predetermined program to perform information processing, but a part or all of the above processing may be executed by a dedicated circuit provided in the game system 1.

[0245] According to the above-mentioned modified example, the present invention can be realized in a so-called cloud computing system form or a distributed wide area network and local network system form. For example, in a distributed local network system form, the above-mentioned processing can be executed by cooperation between a stationary information processing device (stationary game device) and a portable information processing device (portable game device). In these system forms, there is no particular limitation on which device performs the above-mentioned processing, and it goes without saying that the present invention can be realized regardless of the division of processing load.

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

[0247] The program may be supplied to the game system 1 through an external storage medium such as an external memory, or may be supplied to the device through a wired or wireless communication line. The program may be pre-recorded in a non-volatile storage device inside the device. The information storage medium for storing the program may be a non-volatile memory, a CD-ROM, a DVD, or an optical disk-shaped storage medium similar to these, a flexible disk, a hard disk, a magneto-optical disk, a magnetic tape, or the like. The information storage medium for storing the program may be a volatile memory for storing the program. Such a storage medium may be a recording medium that can be read 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 programs from these recording media.

[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. Needless to say, various improvements and modifications can be made without departing from the scope of the present invention. In addition, it is understood that a person skilled in the art can implement an equivalent range based on the description of the present invention and technical common sense from the description of specific examples of the present invention. In addition, it should be understood that the terms used in this specification are used in the sense commonly used in the field unless otherwise specified. Therefore, unless otherwise defined, all technical terms and technical terms used in this specification have the same meaning as commonly understood by a person skilled in the art to which this invention belongs. In the event of a conflict, this specification (including definitions) shall 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 section 83...Controller communication section 85…DRAM 89, 104, 114...Accelerometer 90, 105, 115...Angular velocity sensor 101, 111...Communication control unit

Claims

1. A computer of an information processing device, Determine the aiming direction based on the directional input, In the first situation, making the player character shoot an event item, which causes an in-game event to progress, in the direction of the target based on an operational input, and when the event item hits a field character arranged on a field in a virtual space, varying a state parameter of the field character; In the second situation, A game program which, when a state parameter of the field character reaches a predetermined value due to a hit by the event item, causes the player character to release a combat character that will engage in combat in the aiming direction based on operational input, and when the combat character is released at a location where the field character is located, starts a battle on the field between the field character and the combat character.

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; 2. The game program according to claim 1, further comprising control for making it easier to satisfy the clear condition when the battle with the field character is won.

3. A game program as described in claim 2, wherein, if the battle with the field character is won, 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 computer-readable storage medium according to claim 2, wherein, when the battle with the field character is won, an amount of decrease in the state parameter in accordance with hitting the event item within at least a predetermined period of time is made relatively large.

5. A game system having a processor, The processor, Determine the aiming direction based on the directional input, In the first situation, making the player character shoot an event item, which causes an in-game event to progress based on an operational 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 situation, When the state parameter of the field character reaches a predetermined value due to a hit by the event item, the game system causes the player character to release a combat character that will engage in combat in the aiming direction based on operational input, and when the combat character is released at a location where the field character is located, initiates a battle on the field between the field character and the combat character.

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, when the battle with the field character is won, the clearing condition becomes easier to satisfy.

7. A game system as described in claim 6, wherein, if the battle with the field character is won, the 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, an amount of decrease in the state parameter corresponding to hitting the event item within at least a predetermined period of time is made relatively large.

9. A gaming device having a processor, The processor, Determine the aiming direction based on the directional input, In the first situation, making the player character shoot an event item, which causes an in-game event to progress based on an operational 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 situation, When a state parameter of the field character reaches a predetermined value due to a hit by the event item, a combat character that will engage in combat is launched by the player character in the aiming direction based on an operational input, and when the combat character is launched at a location where the field character is located, a battle between the field character and the combat character is initiated on the field.

10. The processor further comprising: 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. A game device as described in claim 10, wherein, if the battle with the field character is won, the 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, if the battle with the field character is won, an amount of decrease in the state parameter corresponding to hitting the event item within at least a predetermined period of time is made relatively large.

13. A processor of an information processing device, Determine the aiming direction based on the directional input, In the first situation, making the player character shoot an event item, which causes an in-game event to progress based on an operational 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 situation, A game processing method in which, when a state parameter of the field character has reached a predetermined value due to a hit by the event item, a combat character that will engage in combat is released by the player character in the aiming direction based on an operational input, and when the combat character is released at a location where the field character is located, a battle between the field character and the combat character is initiated on the field.

14. The processor further comprising: 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, further comprising the step of: controlling the game so that the clearing condition becomes easier to satisfy when the battle with the field character is won.

15. A game processing method as described in claim 14, wherein, if the battle with the field character is won, the 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, an amount of decrease in the state parameter corresponding to hitting the event item within at least a predetermined period of time is made relatively large.

Images