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

Abstract

The present invention provides a game program, game system, game device, and game processing method that enable player characters to perform various types of actions on a virtual space field. [Solution] In the first mode, based on the second operation input, the aiming direction in the virtual space is determined, and based on the third operation input, an item that affects a field character placed on the field in the virtual space is released to the player character in the aiming direction. In the second mode, based on the second operation input, the aiming direction is determined, and based on the third operation input, a combat character that will engage in combat is released to the player character in the aiming direction.

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 Art

[0002] Conventionally, there is a game program in which a player character throws a ball at a character in a virtual space to capture the character and set it in a state of being owned by the player character (see, for example, Non-Patent Document 1).

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in the game program disclosed in Non-Patent Document 1, the ability to throw a ball and capture a character is limited to during battle, and it is not possible to throw a ball 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 can cause a player character to perform various types of actions on the field of a virtual space.

Means for Solving the Problems

[0006] To achieve the above objective, the present invention may employ, for example, the following configuration.

[0007] One example of the game program configuration of the present invention involves causing the computer of an information processing device to switch between at least a first mode and a second mode based on a first operation input; in the first mode, based on a second operation input, the aiming direction in the virtual space is determined, and based on a third operation input, the player character is made to release an item that affects a field character placed on a field in the virtual space toward the aiming direction, and when the item is released to the location where the field character is placed, the field character is given the effect associated with the item; in the second mode, based on a second operation input, the aiming direction is determined, and based on a third operation input, the player character is made to release a combat character to engage in combat toward the aiming direction, and when the combat character is released to the location where the field character is placed, combat between the field character and the combat character on the field is initiated.

[0008] As described above, by switching between the first and second modes, it becomes possible to have the player character perform multiple different types of actions by inputting commands to aim and release, such as releasing items that affect field characters on a targeted field character on the field, and releasing combat characters to engage in battle with field characters on the field.

[0009] Furthermore, the above items may include at least one capture item for capturing field characters. The computer may also be instructed to perform a capture success check if a capture item released in the first mode hits a field character, and if the capture success check is positive, the computer may be instructed to set the field character that was hit by the capture item to be owned by the player.

[0010] According to the above, the user can choose to either capture the field character or have the field character fight against the combat character.

[0011] Furthermore, the above items may include items that have the effect of making it easier to get a positive result when determining the success of a capture.

[0012] According to the above, before releasing a capture item, it is possible to increase the chances of a successful capture by using that item.

[0013] Furthermore, the above items may include items that have the effect of restricting the movement of field characters on the field.

[0014] According to the above, by restricting the movement of a targeted field character on the field, it becomes easier to hit that field character with a capture item.

[0015] Furthermore, the computer may be instructed to direct its aiming direction toward the field character based on a fourth input.

[0016] According to the above, it is easy to aim the reticle at the target field character on the field.

[0017] Furthermore, the computer may also be instructed to display an index indicating the likelihood of a positive capture success determination for the field character to which the targeting direction is directed, based on the fourth operation input.

[0018] As described above, the indicator can be used as a basis for deciding whether or not to capture using a capture item. Furthermore, since the indicator is displayed when the aiming direction is directed towards the field character, you can release the item after making the above decision.

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

[0020] According to the above, information on a field character targeted on the field can be easily viewed.

[0021] Further, the information on the field character may include mission information regarding the history of missions in the game, including at least the number of captures of the field character and the number of battles with the field character.

[0022] According to the above, by displaying the mission history of the field character targeted on the field, it can be used as a basis for judgment when selecting the above capture and the above battle.

[0023] Further, after the start of the battle, based on an operation input including at least an attack instruction by the battle character and an instruction to use an item, the computer causes a battle between the battle character and the field character on the field. During the battle, when an instruction to use a capture item is given, a successful capture determination during battle regarding whether the capture of the field character is successful based on the state of the field character that changes due to the battle using the capture item is made. When the successful capture determination during battle is affirmed, the computer may set the field character to a state owned by the player.

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

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

[0026] According to the above, even when the physical strength index of the field character is not displayed, the direction of the virtual camera can be changed by operation input, so that when the user desires, the state where the index is displayed can be achieved.

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

[0028] According to the above, the combat character can be used not only for combat with the field character.

[0029] Further, in the computer, an index indicating the aiming direction may be displayed in different display modes in the first mode and the second mode.

[0030] According to the above, it becomes easier to understand what the player character is about to release, even while aiming at the field character.

[0031] Further, the item may be an event item that advances the in-game event by hitting the field character. In this case, in the computer, in the in-game event, when a plurality of event items are made to hit the field character until a predetermined clear condition is satisfied, it may be determined that the in-game event is cleared, and when winning in combat with the field character, it may be controlled so that the clear condition is more easily satisfied.

[0032] As described above, by switching between the first mode, which releases items that affect field characters, and the second mode, which releases combat characters that engage in battle with field characters on the field, a wide variety of strategies can be employed to clear in-game events.

[0033] Furthermore, if a player wins a battle against the aforementioned field character, they may restrict the field character's movement within the virtual space for at least a predetermined period of time.

[0034] According to the above, if a combat character wins a battle against a field character, it becomes easier to hit the field character with an item, and the battle, other than by using items, can be used to clear in-game events more easily.

[0035] Furthermore, the above clear condition may also be to reduce the event parameter, which decreases each time an event item hits a field character, to a predetermined level. If a battle with a field character is won, the amount of reduction in the event parameter corresponding to hitting with an event item within a predetermined period may be relatively increased.

[0036] As described above, the effects of items released during in-game events can be enhanced, and in-game events can be cleared more easily through the aforementioned battles, in addition to releasing items.

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

[0038] According to the present invention, by switching between the first mode and the second mode, it becomes possible to have the player character perform multiple different types of actions by inputting an action to fire while aiming, such as firing an item that affects a field character at a targeted field character on the field, and firing a combat character to engage in combat with a field character on the field. [Brief explanation of the drawing]

[0039] [Figure 1] This diagram shows an example of the main unit 2 with the left controller 3 and right controller 4 attached. [Figure 2] This diagram shows an example of the state in which the left controller 3 and right controller 4 have been removed from the main unit 2. [Figure 3] A six-view drawing showing an example of the main unit 2. [Figure 4] A six-view drawing showing an example of the left controller 3. [Figure 5] A six-view drawing showing an example of the right controller 4. [Figure 6] Block diagram showing an example of the internal configuration of the main unit 2. [Figure 7] Block diagram showing an example of the internal configuration of the main unit 2, left controller 3, and right controller 4. [Figure 8] This diagram shows an example of a game image from the first stage of capturing a field character (FC). [Figure 9] This diagram shows an example of a game image from the second stage of capturing a field character (FC). [Figure 10] This diagram shows an example of a game image from the third stage of capturing a field character (FC). [Figure 11] This diagram shows an example of a game image from the first stage of a battle scene between a field character FC and a battle character BC. [Figure 12] This diagram shows an example of a game image from the second stage of a battle scene between a field character FC and a battle character BC. [Figure 13]This diagram shows an example of a game image from the third stage of a battle scene between a field character FC and a battle character BC. [Figure 14] This diagram shows an example of a game image from the fourth stage of a battle scene between a field character FC and a battle character BC. [Figure 15] This diagram shows an example of a game image from the first stage of a scene where a combat character BC collects a harvesting object OBJ. [Figure 16] This diagram shows an example of a game image from the second stage of a scene where a combat character BC collects a harvesting object OBJ. [Figure 17] This diagram shows an example of how to display field information in the encyclopedia. [Figure 18] This diagram shows an example of a game image during an attack on the boss character MC. [Figure 19] This diagram shows an example of a game image from the first stage of a battle between the boss character MC and the combat character BC. [Figure 20] This diagram shows an example of a game image from the second stage of a battle between the boss character MC and the combat character BC. [Figure 21] This figure 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 game processing performed by game system 1. [Figure 23] A subroutine showing a detailed example of the item usage process performed in step S125 in Figure 22. [Figure 24] A subroutine showing a detailed example of the first character usage process performed in step S127 in Figure 22. [Figure 25] A subroutine showing a detailed example of the boss item usage process performed in step S130 in Figure 22. [Figure 26] A subroutine showing a detailed example of the second character usage process performed in step S132 in Figure 22. [Modes for carrying out the invention]

[0040] The following describes a game system according to an example of this embodiment. An example of the game system 1 in this embodiment includes a main unit (information processing device; functioning as the game device main unit in this embodiment) 2, a left controller 3, and a right controller 4. The left controller 3 and the right controller 4 are 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. Alternatively, the game system 1 can be used with the main unit 2 and the left controller 3 and right controller 4 as separate components (see Figure 2). The hardware configuration of the game system 1 in this embodiment will be described below, followed by a description of the control of the game system 1 in this embodiment.

[0041] Figure 1 shows an example of the main unit 2 with the left controller 3 and right controller 4 attached. As shown in Figure 1, the left controller 3 and right controller 4 are attached to the main unit 2 and integrated together. The main unit 2 is a device that performs various processes (e.g., game processing) in the game system 1. The main unit 2 is equipped with a display 12. The left controller 3 and right controller 4 are devices equipped with operation parts for user input.

[0042] Figure 2 shows an example of the left controller 3 and right controller 4 being removed from the main unit 2. As shown in Figures 1 and 2, the left controller 3 and right controller 4 are detachable from the main unit 2. In the following, the left controller 3 and right controller 4 will be collectively referred to as "controllers".

[0043] Figure 3 is a six-view drawing showing an example of the main unit 2. As shown in Figure 3, the main unit 2 includes a roughly 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 roughly rectangular in shape.

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

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

[0046] Furthermore, the main unit 2 is equipped with a touch panel 13 on the screen of the display 12. In this embodiment, the touch panel 13 is of a type that allows multi-touch input (for example, a capacitive touch panel). However, the touch panel 13 may be of any type, for example, a type that allows single-touch input (for example, a resistive touch panel).

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

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

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

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

[0051] Figure 4 is a six-view drawing showing an example of the left controller 3. As shown in Figure 4, the left controller 3 includes a housing 31. In this embodiment, the housing 31 has a vertically elongated shape, that is, it is long in the vertical direction (i.e., in the y-axis direction as shown in Figures 1 and 4). The left controller 3 can also be held in a vertically elongated orientation when detached from the main device 2. The housing 31 is shaped and sized to be held with one hand, especially the left hand, when held in a vertically elongated orientation. The left controller 3 can also be held in a horizontally elongated orientation. When the left controller 3 is held in a horizontally elongated orientation, it may be held with both hands.

[0052] The left controller 3 is equipped with an analog stick 32. As shown in Figure 4, the analog stick 32 is provided on the main surface of the housing 31. The analog stick 32 can be used as a directional input unit that can input direction. The user can input direction (and magnitude according to the angle of tilt) by tilting the analog stick 32. In addition, the left controller 3 may be equipped with a directional pad or a slide stick that allows slide input instead of the analog stick as the directional input unit. Furthermore, in this embodiment, input by pressing the analog stick 32 is also possible.

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

[0054] Furthermore, the left controller 3 is equipped with a terminal 42 for wired communication between the left controller 3 and the main unit 2.

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

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

[0057] Furthermore, the right controller 4 is equipped with a terminal 64 for wired communication between the right controller 4 and the main unit 2.

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

[0059] The main unit 2 includes a processor 81. The processor 81 is an information processing unit that performs various information processing operations performed in the main unit 2, and may consist of, for example, only a CPU (Central Processing Unit), or it may consist of an SoC (System-on-a-chip) that includes multiple functions such as CPU function and GPU (Graphics Processing Unit) function. The processor 81 performs various information processing operations by executing information processing programs (for example, game programs) stored in a storage unit (specifically, an internal storage medium such as flash memory 84, or an external storage medium installed in slot 23).

[0060] The main unit 2 includes, as an example of an internal storage medium built into itself, a flash memory 84 and a DRAM (Dynamic Random Access Memory) 85. The flash memory 84 and DRAM 85 are connected to the processor 81. The flash memory 84 is a memory mainly used to store various types of data (which may be programs) stored in the main unit 2. The DRAM 85 is a memory used to temporarily store various types of data used in information processing.

[0061] The main unit 2 is equipped with 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 slot 23 and reads and writes data to a predetermined type of storage medium (for example, a dedicated memory card) installed in slot 23, according to instructions from the processor 81.

[0062] The processor 81 performs the above-mentioned information processing by appropriately reading and writing data to the flash memory 84 and DRAM 85, as well as to each of the above-mentioned storage media.

[0063] The main unit 2 includes a network communication unit 82. The network communication unit 82 is connected to the processor 81. The network communication unit 82 communicates with external devices via a network (specifically, wirelessly). In this embodiment, the network communication unit 82 communicates with external devices by connecting to a wireless LAN using a method compliant with the Wi-Fi standard as a first communication mode. The network communication unit 82 also performs wireless communication with other main unit 2 of the same type using a predetermined communication method (for example, communication using a proprietary protocol or infrared communication) as a second communication mode. The wireless communication using the second communication mode is possible with other main unit 2 located within a closed local network area, and realizes a function that enables so-called "local communication" in which data is sent and received by communicating directly between multiple main unit 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 communicates wirelessly with the left controller 3 and / or the right controller 4. The communication method between the main unit 2 and the left controller 3 and the right controller 4 is arbitrary, but in this embodiment, the controller communication unit 83 communicates with the left controller 3 and with the right controller 4 in accordance with the Bluetooth® standard.

[0065] The processor 81 is connected to the left terminal 17, right terminal 21, and lower terminal 27 described above. When the processor 81 communicates with the left controller 3 via a wired connection, 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 communicates with the right controller 4 via a wired connection, 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 communicates 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 and wireless communication with the left controller 3 and the right controller 4, respectively. Furthermore, when the left controller 3 and the right controller 4 are mounted on the main unit 2 as an integrated unit, or when the main unit 2 alone is mounted on the cradle, the main unit 2 can output data (e.g., image data and audio data) to a stationary monitor or the like via the cradle.

[0066] Here, the main unit 2 can communicate simultaneously (in other words, in parallel) with multiple left controllers 3. Furthermore, the main unit 2 can communicate simultaneously (in other words, in parallel) with multiple right controllers 4. Therefore, multiple users can simultaneously input to the main unit 2 using their respective sets of left controllers 3 and right controllers 4. For example, while the first user inputs to the main unit 2 using the first set of left controllers 3 and right controllers 4, the second user can input to the main unit 2 using the 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 images generated (for example, by performing the above information processing) and / or images acquired from an external source on the display 12.

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

[0069] Furthermore, the main unit 2 is equipped with an acceleration sensor 89. In this embodiment, the acceleration sensor 89 detects the magnitude of acceleration along a predetermined three-axis direction (for example, the x, y, and z axes shown in Figure 1). Note that the acceleration sensor 89 may also detect acceleration in one axis direction or two axis directions.

[0070] Furthermore, the main unit 2 is equipped with an angular velocity sensor 90. In this embodiment, the angular velocity sensor 90 detects angular velocity around three predetermined axes (for example, the x, y, and z axes shown in Figure 1). The angular velocity sensor 90 may also detect angular velocity 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 from the acceleration sensor 89 and the angular velocity sensor 90 are output to the processor 81. Based on the detection results from the acceleration sensor 89 and the angular velocity sensor 90, the processor 81 can calculate information regarding the movement and / or orientation of the main unit 2.

[0072] The main unit 2 comprises 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 in the figures, the power control unit 97 is also connected to various parts of the main unit 2 (specifically, the parts that receive power from the battery 98, the left terminal 17, and the right terminal 21). Based on commands from the processor 81, the power control unit 97 controls the power supply from the battery 98 to the aforementioned parts.

[0073] The battery 98 is also connected to the lower terminal 27. When an external charging device (for example, a cradle) is connected to the lower terminal 27 and power is supplied to the main unit 2 via the lower terminal 27, the supplied power charges the battery 98.

[0074] Figure 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 the details of the internal configuration of the main unit 2 are shown in Figure 6 and are therefore omitted in Figure 7.

[0075] The left controller 3 includes a communication control unit 101 that communicates with the main unit 2. As shown in Figure 7, the communication control unit 101 is connected to each component, including the terminal 42. In this embodiment, the communication control unit 101 can communicate with the main unit 2 both by wired communication via the terminal 42 and by wireless communication without using the terminal 42. The communication control unit 101 controls the method of communication that the left controller 3 performs 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. 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). Wireless communication between the controller communication unit 83 and the communication control unit 101 is performed according to, for example, the Bluetooth® standard.

[0076] The left controller 3 also includes a memory 102, such as flash memory. The communication control unit 101 is composed of, for example, a microcontroller (also called a microprocessor) and performs various processes by executing firmware stored in the memory 102.

[0077] The left controller 3 is equipped with buttons 103 (specifically, buttons 33-39, 43, 44, and 47). The left controller 3 is also equipped with an analog stick (referred to as "stick" in Figure 7) 32. Each button 103 and the analog stick 32 repeatedly output information about the operations performed on them to the communication control unit 101 at appropriate intervals.

[0078] The left controller 3 is equipped with an inertial sensor. Specifically, the left controller 3 is equipped with an acceleration sensor 104. The left controller 3 is also equipped with an angular velocity sensor 105. In this embodiment, the acceleration sensor 104 detects the magnitude of acceleration along three predetermined axes (for example, the x, y, and z axes shown in Figure 4). Note that the acceleration sensor 104 may also detect acceleration in one or two axes. In this embodiment, the angular velocity sensor 105 detects angular velocity around three predetermined axes (for example, the x, y, and z axes shown in Figure 4). Note that the angular velocity sensor 105 may also 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 from the acceleration sensor 104 and the angular velocity sensor 105 are repeatedly output to the communication control unit 101 at appropriate timings.

[0079] The communication control unit 101 acquires information about the input (specifically, information about the operation or detection results from the sensor) from each input unit (specifically, each button 103 and the analog stick 32). The communication control unit 101 transmits operation data, including the acquired information (or information that has been processed in a predetermined manner), to the main unit 2. The operation data is transmitted repeatedly at a rate of once at predetermined intervals. The interval at which information about the input is transmitted to the main unit 2 may or may not be the same for each input unit.

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

[0081] The left controller 3 includes a power supply unit 108. In this embodiment, the power supply unit 108 includes 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 Figure 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 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 memory 102 of the left controller 3. Therefore, the communication control unit 111 can communicate with the main unit 2 both by wired communication via the terminal 64 and by wireless communication without the terminal 64 (specifically, communication according to the Bluetooth® standard), and controls the method of communication that the right controller 4 performs with the main unit 2.

[0083] The right controller 4 is equipped with the same inputs as the left controller 3. Specifically, it includes buttons 113, an analog stick 52, and inertial sensors (accelerometer 114 and angular velocity sensor 115). Each of these inputs has the same function and operates in the same way as the inputs of the left controller 3.

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

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

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

[0087] Figures 8 to 20 illustrate the overview of the game processing performed in game system 1. Figure 8 is an example of a game image in the first stage of capturing a field character FC. Figure 9 is an example of a game image in the second stage of capturing a field character FC. Figure 10 is an example of a game image in the third stage of capturing a field character FC. Figure 11 is an example of a game image in the first stage of a battle between a field character FC and a combat character BC. Figure 12 is an example of a game image in the second stage of a battle between a field character FC and a combat character BC. Figure 13 is an example of a game image in the third stage of a battle between a field character FC and a combat character BC. Figure 14 is an example of a game image in the fourth stage of a battle between a field character FC and a combat character BC. Figure 15 is an example of a game image in the first stage of a battle where a combat character BC collects a collection object OBJ. Figure 16 is an example of a game image in the second stage of a battle where a combat character BC collects a collection object OBJ. Figure 17 shows an example of how the field character FC is displayed in the encyclopedia. Figure 18 shows an example of a game image in a scene where the boss character MC is being attacked. Figure 19 shows an example of a game image in the first stage of a scene where the boss character MC and the battle character BC are fighting. Figure 20 shows an example of a game image in the second stage of a scene where the boss character MC and the battle character BC are fighting.

[0088] (First embodiment) As an example of this embodiment, the game processing according to the first embodiment will be described. In the first embodiment, by switching between the first mode and the second mode, the player character PC is made to perform multiple different types of actions based on the input for the player character PC to perform actions toward the target M. These actions include throwing an item that affects the field character FC at the targeted field character FC on the field, and throwing a combat character BC to engage in combat with the field character FC on the field.

[0089] In Figure 8, the display 12 of the game system 1 shows a game image in which a player character PC is placed in a virtual space. The player character PC operates within the virtual space in response to user input. The game image displayed on the display 12 also shows field characters FC placed in the virtual space. Multiple field characters FC are placed on the field within the virtual space and operate within the virtual space through automatic control by the processor 81 based on a predetermined algorithm. The user operating the player character PC can capture field characters FC through the player character PC's actions and make them owned by the user.

[0090] As shown in Figure 8, the player character PC is holding ball item B and is about to throw the empty ball item B into the virtual space. Here, the empty ball item B functions as a capture item that can capture a field character FC on the field by hitting that character FC. For example, if the empty ball item B thrown by the player character PC hits a field character, a capture success check is performed to determine whether the capture is successful or not. If the capture success check is positive, the field character FC that was hit by ball item B is captured and set to be owned by the user.

[0091] For example, by performing a predetermined operation input (for example, pressing the operation button (ZR button) 61), the user can cause the player character PC to perform a throwing motion for the selected item (for example, the motion to assume the posture shown in Figure 8). The direction in which the player character PC will throw the selected item is indicated by the aiming reticle M, and the position of the aiming reticle M moves according to the predetermined operation input (for example, the tilt direction of the analog stick 32 or 52, the posture of the left controller 3 or the right controller 4, the movement or pointing position of the controller, etc.). Then, when the user releases the operation input that caused the player character PC to perform the throwing motion (for example, releasing the operation button (ZR button) 61 that is being pressed), the player character PC throws the selected item in the direction indicated by the aiming reticle 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, there are at least two modes: a first mode in which a first category group including multiple items that affect the field character FC is selected, and a second mode in which a second category group including multiple battle characters BC that fight the field character FC on the field is selected, and the category group (mode) selected is switched by the user pressing the operation button 55. The user can also select an item to throw from the selected category group by pressing the operation button (L button) 38 or the operation button (R button) 60. In the example shown in Figure 8, the first category group (first mode) is selected, and throwing information Im1 is displayed indicating that an empty ball item B has been selected by the user from the first category group. For example, the first category group may include multiple types of ball items with different performance and appearances, or it may include items other than ball items that support the capture process by throwing ball items, such as restricting the movement of field characters when thrown.

[0093] If an item selected from the above first category group is selected as a throwable item, the first reticle M1 (for example, the standard display reticle) is displayed. Also, if an empty ball item B, which can capture the field character FC, is selected as a throwable item from the above first category group, the position of the first reticle M1 can be moved by the operation of moving the reticle M as described above, but the first reticle M1 can be set (locked on) to a position that overlaps with the field character FC by the user performing a predetermined operation input (for example, pressing the operation button (ZL button) 39). By locking the first reticle M1 onto the position of the field character FC, it becomes easier to hit the field character FC with the thrown item.

[0094] When the first target reticle M1 locks onto a field character FC, capture information Ig, indicating how easy it is to capture the field character FC by hitting it with an empty ball item B, is displayed near the first target reticle M1. For example, when an empty ball item B thrown by the player character PC hits the field character FC, an indicator showing how easy it is to make a positive capture success judgment is displayed as capture information Ig. Capture information Ig may be an indicator showing one of several stages indicating how easy it is to make a positive capture success judgment, or it may be an indicator showing a numerical value indicating the probability or degree of a positive judgment. Furthermore, capture information Ig may be an indicator that shows how easy it is to make a positive capture success judgment through design or text, or through size or movement, or through color or brightness, etc. Also, capture information Ig does not have to be displayed on display 12, and how easy it is to make a positive capture success judgment may be indicated by sound or vibration given to controllers 3 and / or 4.

[0095] In Figures 9 and 10, the display 12 shows 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 make the player character PC perform the action of throwing the selected item towards the first target M1 by releasing the input for the player character PC to perform the aiming action (for example, 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 image indicating that the field character FC has been hit (and / or captured) is displayed as shown in Figure 9. If the capture of the field character FC is successful, an image indicating that the field character FC has been captured is displayed as the field character FC is stored inside the empty ball item B, as shown in Figure 10. The captured field character FC is then set to be owned by the user. The captured field character FC may be made 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 capture of field character FC fails, an image illustrating the situation will be displayed on display 12. In this case, if the capture of field character FC fails, a disadvantage may occur, such as field character FC running away or field character FC attacking, initiating a battle.

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

[0098] Furthermore, the ease of capture may be changed depending on the state of the target field character FC (emotions, durability, remaining health, size, movement status, 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 will be aware of the change by displaying the capture information Ig near the first target reticle M1.

[0099] Furthermore, in the first embodiment, an empty ball item B was used as an example of an item selected from a first category group (first mode) that includes multiple items that affect the field character FC, but the first category group may also include other types of items. For example, items that slow down the movements of the hit field character FC, items that drain the health of the hit field character FC, items that change the emotions of the hit field character FC, and items that attract the field character FC may be included in the first category group. By combining these items, such as hitting the field character FC or placing them in a position where you want to attract the field character FC, it is possible to expect an effect that makes it easier to capture the field character FC by throwing a capture item (for example, an empty ball item B).

[0100] In Figure 11, the player character PC is holding a ball item Bs containing a combat character BC in the second mode described above, and is attempting to throw the ball item Bs into the virtual space. Here, throwing the ball item Bs containing the combat character BC onto the field causes the combat character BC to appear in the virtual space. For example, if the ball item Bs thrown by the player character PC is thrown near the field character FC, the combat character BC will appear from the ball item Bs, and combat with the field character FC will begin. The combat will start directly on the field without any location switching.

[0101] For example, by performing a predetermined operation input (for example, pressing the operation button (ZR button) 61), the user can cause the player character PC to perform an action to prepare to throw the selected combat character BC (ball item Bs) (for example, the action to assume the posture shown in Figures 11 and 12). The direction in which the player character PC will throw the selected combat character BC (ball item Bs) is indicated by the aiming reticle M, and the position of the aiming reticle M moves according to the predetermined operation input (for example, the tilt direction of the analog stick 32 or 52, the posture of the left controller 3 or right controller 4, the movement or pointing position of the said controller, etc.). Then, when the user releases the operation input that caused the player character PC to perform the above preparing action (for example, releasing the operation button (ZR button) 61 that is being pressed), the player character PC throws the selected combat character BC (ball item Bs) in the direction indicated by the aiming reticle M.

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

[0103] If a combat character BC (or ball item Bs containing a combat character BC) selected from the above second category group is selected as a throwable item, the second reticle M2 will be displayed. The second reticle M2 is displayed in a different manner than the first reticle M1. For example, unlike the standard display of the reticle, the second reticle M2 is displayed with an indicator that has a color scheme that mimics the ball item Bs containing the combat character BC. By displaying the second reticle M2 in a different manner than the first reticle M1 in this way, it becomes easier to see the throwable item that the player character PC is about to throw, even while looking at the reticle.

[0104] As shown in Figure 12, if the second reticle M2 is positioned in a location that overlaps with the combat range of the field character FC and the combat character BC, the second reticle M2 is changed to the third reticle M3. The third reticle M3 is displayed in a different manner from both the first reticle M1 and the second reticle M2. For example, the third reticle M3 is displayed as an indicator with a design that suggests combat added to the center of the second reticle M2. By displaying the third reticle M3 in a different manner from both the first reticle M1 and the second reticle M2 in this way, it becomes easier to understand, even while looking at the reticle, that it is possible to engage in combat with the field character FC by throwing the ball item Bs containing the combat character BC.

[0105] In Figure 13, the display 12 shows a game image in which a combat character BC, which has emerged 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 throw a ball item Bs containing the selected combat character BC towards the third target M3 by releasing the input for the player character PC to perform a aiming motion (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 it can fight the field character FC, the combat character BC emerges from that range. The combat character BC then begins fighting the field character FC. Therefore, in the first embodiment, by switching the category group (mode) of throwable items with a common operation of causing the player character PC to throw towards the target M, various actions can be performed on the field character FC on the field.

[0106] While combat character BC and field character FC are fighting, a gauge G1 indicating the status of field character FC is displayed at a position corresponding to the field character FC's location. Here, the status of field character FC indicated by gauge G1 shows at least the parameters related to the field character FC's remaining health in the battle with combat character BC, and also the parameters that gradually decrease in accordance with attacks that are effective against field character FC by combat character BC. When the remaining health indicated by gauge G1 reaches 0, combat character BC wins the battle. Furthermore, as will become clear later, the status of field character FC indicated by gauge G1 also serves as an indicator of how easy it is to capture field character FC during the battle.

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

[0108] The user can control the actions of the combat character BC by inputting an action to select an attack command. For example, when an attack command is selected, the user is prompted to choose from several attack options, and by performing the action to select one of these options, the combat character BC can perform an attack action corresponding to that selected attack.

[0109] The user can control the actions of their player character PC by inputting an action to select an item command. For example, when an item command is selected, the user is prompted to select an item to use from several items, including capture items. By selecting an item from these items, the user can make the player character PC perform an action using the selected item. For example, during the battle described above, the user can select a capture item to capture a field character FC, thereby making the player character PC perform an action to capture the field character FC using that capture item.

[0110] The capture item used during combat may be the same as or similar to the ball item B described above. For example, if the command to use a capture item is selected during the above combat, the player character PC will throw the capture item to hit the field character FC during the combat, but whether or not the capture is successful will be determined by a capture success check, just as in a non-combat state. The capture success check during combat will be based on the state of the field character FC that changes as a result of the combat, that is, the state of the field character FC indicated by gauge G1. Specifically, if the state of the field character FC that changes as a result of the combat (for example, remaining health) has decreased to a predetermined state as a result of the combat, the capture success check will be more likely to result in a positive judgment. Note that the above threshold may change depending on at least one of the following: the type of field character FC, the type of capture item selected in the command, the ability scores of the player character PC, and the ability scores of the combat characters BC. If the capture success check during combat is positive, the field character FC that was targeted by the command to use a capture item will be captured and set to be owned by the user. As another example, even while combat character BC and field character FC are fighting, instead of selecting a command, the player character PC may be instructed to throw a capture item towards the target M, similar to the capture outside of combat described above, thereby capturing field character FC using the capture item.

[0111] The user can summon another combat character BC during the battle or remove a combat character BC already present in the battle by selecting the summon / remove command. The summoning may involve replacing an already present combat character BC, or a new combat character BC may appear in addition to an already present one. For example, when the summon / remove command is selected, the user will be prompted to choose from multiple characters to summon or to remove. By selecting from these characters, the player character PC can then summon the selected character as a combat character BC.

[0112] Furthermore, by selecting the "escape" command, the user can end the battle between the combat character BC and the field character FC, and control the player character PC's actions by having the player character PC escape from the field character FC. At this time, the combat character BC that has appeared may be retrieved by the player character PC and removed from the field, or it may be left on the field.

[0113] Thus, even during combat between combat character BC and field character FC, selecting the command to use a capture item allows for the capture of field character FC, just as in a non-combat state. This gives the user the option of capturing field character FC without engaging in combat with combat character BC, or capturing field character FC by engaging in combat, resulting in a highly strategic gameplay experience.

[0114] In the first embodiment, the player character PC throws a ball item Bs containing the combat character BC towards the target M to release 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] Furthermore, the position and orientation of the virtual camera for generating the game image displayed on 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 it may be set as a first-person view of the player character PC. In either case, the position and / or orientation of the virtual camera may be configured to change according to the user's input. In this case, depending on the position and orientation of the player character PC in the virtual space, there may be scenes in which the field character FC during combat is not included in the field of view, or the gauge G1 indicating the status of the field character FC is not included in the display range. However, even during combat between combat character BC and field character FC, if the position and / or orientation of the virtual camera is configured to change according to the user's input, even if combat between the field character FC and combat character BC starts when the field character FC is not displayed, the gauge G1 indicating the status of the field character FC, i.e., the indicator that affects the capture of the field character FC, can be displayed according to the user's input. In addition, the player character PC may be allowed to move freely according to the user's input even during combat. Therefore, no matter what situation combat starts in, the user can change to an appropriate camera afterward, making it possible to configure the system to allow combat to be started freely regardless of the situation.

[0116] Furthermore, in the first embodiment, the combat character BC that emerges from the ball item Bs can be made to perform actions on the field that are different from those of the combat described above. For example, in the first embodiment, the player character PC can simply make the combat character BC appear on the field of the virtual space by throwing the ball item Bs containing the combat character BC onto the field, or the player character PC can make the emerged combat character BC perform an action by having a predetermined action be performed on a virtual object OBJ placed on the field.

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

[0118] The player character PC shown in Figure 15 is holding a ball item Bs containing a combat character BC, similar to the state illustrated in Figure 11. When a predetermined operation input is made (for example, when the operation button (ZR button) 61 is pressed), the player character PC performs an action to prepare to throw the selected combat character BC (ball item Bs). In the example shown in Figure 15, the second category group (second mode) is selected, and throwing information Im2 is displayed, indicating that a predetermined combat character BC has been selected by the user from that second category group.

[0119] As described above, when a combat character BC (ball item Bs containing a combat character BC) selected from the second category group is selected as a throwable item, the second reticle M2 is displayed. If the second reticle M2 is positioned in a location that overlaps with the range where the gathering action of a gathering object OBJ is possible, the second reticle M2 is changed to the fourth reticle M4. The fourth reticle M4 is displayed in a different manner from the first reticle M1, second reticle M2, and third reticle M3. For example, the fourth reticle M4 is displayed as an indicator with a design that mimics a part of the combat character BC added to the center of the second reticle M2. By displaying the fourth reticle M4 in a different manner from the first reticle M1, second reticle M2, and third reticle M3 in this way, it becomes easier to understand, even while looking at the reticle, that it is possible to make a field character FC appear in a state different from the above battle by throwing a ball item Bs containing a combat character BC.

[0120] In Figure 16, the display 12 shows a game image in which a combat character BC, which has emerged from a ball item Bs thrown by the player character PC, is collecting a harvesting object OBJ. For example, the user can cause the player character PC to throw the ball item Bs, which contains the selected combat character BC, towards the fourth aiming reticle M4 by releasing the input that causes the player character PC to assume a positioning motion (for example, by releasing the pressed operation button (ZR button) 61). When the ball item Bs thrown by the player character PC reaches the range from which the harvesting object OBJ can be collected, the combat character BC emerges from that range. The combat character BC then begins to collect the harvesting object OBJ.

[0121] In the first embodiment, information about the field character FC that the target reticle M has locked onto can be displayed (encyclopedia display). For example, as shown in Figure 8, when a predetermined operation input is performed (for example, when the operation button (down button) 34 or the down direction on the directional pad is pressed), that is, when an operation to display the encyclopedia is performed while the operation to lock onto the field character FC is performed, the information about the field character FC as shown in Figure 17 will be displayed. Here, the information about the field character FC includes mission information relating to the history of in-game missions, which at least includes the number of field character FCs that the player character PC has captured and the number of battles with said field character FC. In the example of the Field Character FC (Field Character) encyclopedia display shown in Figure 17, for Field Character A, which is locked on among multiple types of Field Character FCs, the history of each item such as the number of captures (number of Field Character A captures), the number of heavy-size captures (number of relatively heavy Field Character A captures), the number of battles (number of battles with Field Character A), the number defeated (number of Field Character A defeated in battle), and the number of types of appearances confirmed (number of types of Field Character A that appear in the virtual space and are displayed on display 12) is displayed as information for Field Character FC. In addition, in the example of the Field Character FC encyclopedia display shown in Figure 17, the missions to be completed and their progress are displayed for each item. As an example, as part of the mission information, the required value (number of times to complete) for completing the mission is displayed for each item in the encyclopedia display, and for missions that have already been completed, an indicator (a check mark in the example of Figure 17) is added to the required value of that mission.

[0122] In this way, the display of historical information on missions to be completed for field character FCs on the field can be used as reference when deciding whether to capture or engage in combat with the field character FC. It is also possible to configure the system to display information on field character FCs of different types than the locked-on field character A. For example, in the example shown in Figure 17, tags are provided on the far right of the display screen for each type of field character FC (e.g., field character A to E), and by selecting one of these tags, information on other types of field character FCs 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 play against a boss character MC, which is an example of a field character placed on a field in a virtual space, and in the second embodiment, the game processing is against the boss character MC. Here, the boss character MC is a character that appears on the same virtual space field as the field character FC, and attacks the player character PC or 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 so that the boss attack item AI hits the boss character PC. In the second embodiment, by switching between the first mode and the second mode, the player character PC is made to perform multiple different types of actions by inputting an action to make the player character PC perform an action toward the target M, such as throwing an item that affects the boss character MC at the targeted boss character MC on the field, and throwing a combat character BC that fights the boss character MC on the field.

[0124] In Figure 18, the display 12 shows a game image in which the player character PC and the boss character MC are placed in a virtual space. For example, the boss character MC appears in the virtual space when the game progresses to a special event (e.g., a boss battle event) and operates on the field in the virtual space under the automatic control of the processor 81 based on a predetermined algorithm, similar to the field character FC. The user controlling the player character PC can engage in battles between the player character PC, the battle character BC, and the boss character MC. The boss character MC may be a field character that cannot be captured, like the field character FC mentioned above.

[0125] In Figure 18, the player character PC is holding a boss attack item AI and is attempting to throw it into the virtual space. Here, the boss attack item AI is an item that advances the boss battle event when it hits the boss character MC on the field. For example, a boss state parameter is set that indicates the state of the boss character MC in the boss battle event, and this boss state parameter decreases when the boss attack item AI hits the boss character MC. For 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 hit location and the state of the boss character MC, and the amount of decrease based on this attack judgment is subtracted from the boss state parameter of the boss character MC. When the boss state parameter decreases to the point where it reaches a threshold (for example, to 0), the boss character MC is defeated and the boss battle event is cleared. In the example game image in Figure 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 assume a stance to throw the selected boss attack item AI (for example, the stance shown in Figure 18) by performing a predetermined input (for example, pressing the operation button (ZR button) 61). The direction in which the player character PC will throw the selected boss attack item AI is indicated by the first reticle M1, and the position of the first reticle M1 moves according to the predetermined input (for example, the tilt direction of the analog stick 32 or 52, the stance of the left controller 3 or right controller 4, the movement or pointing position of the controller, etc.). When the user releases the input that caused the stance to be performed (for example, releasing the operation button (ZR button) 61 that is being pressed), the player character PC throws the selected boss attack item AI in the direction indicated by the first reticle M1.

[0127] Even during a boss battle event, the user can change the category group of items thrown by the player character PC by performing a predetermined input (for example, pressing the operation button (X button) 55). In the second embodiment, there are at least two modes: a first mode in which a first category group containing multiple items that affect the boss character MC is selected, and a second mode in which a second category group containing multiple combat characters BC that fight the boss character MC on the field is selected, and the category group (mode) selected is switched by the user pressing the operation button 55. The user can also 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 Figure 18, the first category group (first mode) is selected, and throwing information Im3 is displayed indicating that the boss attack item AI has been selected by the user from the first category group. Even during boss battle events, if a boss attack item AI selected from the above first category group is selected as a throwable item, the first aiming reticle M1 (for example, the standard display mode aiming reticle) will be displayed.

[0128] As described above, releasing the input required to make the player character PC assume a stance (for example, releasing the pressed control button (ZR button) 61) will cause the player character PC to throw the selected boss attack item AI towards the first target M1. If the boss attack item AI thrown by the player character PC hits the boss character MC, the boss character MC's boss state parameter will be reduced based on the attack judgment described above. On the other hand, if the boss attack item AI thrown by the player character PC does not hit the boss character MC, the boss character MC's boss state parameter will remain unchanged, or will be increased by a predetermined amount.

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

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

[0131] In the second embodiment, a combat character BC can be made to appear on the field, and the combat character BC can be made to fight the boss character MC. As shown in Figure 19, the player character PC is holding a ball item Bs containing the combat character BC, and is about to throw the ball item Bs into the virtual space. Here, even during a boss battle event, the ball item Bs containing the combat character BC can be thrown onto the field to make the combat character BC appear in the virtual space. For example, if the ball item Bs thrown by the player character PC is thrown near the boss character MC, the combat character BC will appear from the ball item Bs, and the battle with the boss character MC will begin. The battle with the boss character MC also starts on the field without any location switching.

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

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

[0134] In Figure 20, the display 12 shows a game image in which a combat character BC, which emerged from a ball item Bs thrown by the player character PC, is fighting the boss character MC. For example, even during a boss battle event, when the input for the player character PC to assume a fighting position is released (for example, when the pressed operation button (ZR button) 61 is released), the player character PC can be made to throw the ball item Bs containing the selected combat character BC towards the third target M3. When the ball item Bs thrown by the player character PC reaches a range where it can fight the boss character MC, the combat character BC emerges from that range. The combat character BC then begins fighting the boss character MC. Therefore, in the second embodiment, by switching the category group (mode) of throwable items using a common operation that causes the player character PC to throw towards the target M, various actions can be performed on the boss character MC on the field.

[0135] While combat character BC and boss character MC are fighting, a gauge G3 is displayed at a position corresponding to boss character MC's position, indicating the boss character MC's status in the battle with combat character BC. Here, the status of boss character MC indicated by gauge G3 shows at least the parameters related to boss character MC's remaining health in the battle with combat character BC, and also shows the parameters that gradually decrease in accordance with attacks that are effective against boss character MC when combat character BC performs such attacks. When the boss's remaining health indicated by gauge G3 reaches 0, combat character BC wins the battle.

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

[0137] In a battle between the boss character MC and the combat character BC, if the combat character BC wins, adjustments are made to make it easier to meet the conditions for clearing the boss battle event. As a first example, if the combat character BC wins against the boss character MC, the movement of the boss character MC in the virtual space is restricted for at least a predetermined period of time. This makes it easier for the user to hit the boss character MC with the boss attack item AI, and thus easier to reduce the boss status parameters required to clear the boss battle event, making it easier to meet the conditions for clearing the event. As a second example, if the combat character BC wins against the boss character MC, the amount of reduction in the boss status parameters corresponding to hitting the boss character MC with the boss attack item AI for at least a predetermined period of time is relatively increased. This makes it easier for the user to reduce the boss status parameters, making it easier to meet the conditions for clearing the boss battle event. As a third example, if the combat character BC wins a battle against the boss character MC, the boss status parameters at the end of the battle are reduced by a predetermined amount. This makes it easier for the user to reduce the boss status parameters, and consequently, it becomes 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] Furthermore, the start of the battle between the combat character BC and the boss character MC in the above boss battle event may be limited to when the boss character MC reaches a predetermined state. For example, the predetermined state may be when the boss character MC is vulnerable, when the boss character MC is in a predetermined posture, when the boss character MC's boss state parameter reaches a predetermined value, or when a predetermined amount of time has elapsed since the start of the boss battle event. In addition, states in which the above battle cannot be started may include when the combat character BC does not appear even when the player character PC throws a ball item Bs, when the player character PC does not perform a throwing action even when inputting an action to make the player character PC throw, or when the ball item Bs cannot be selected as a throwable item.

[0139] Thus, in the second embodiment, even in a boss battle event where a boss character MC appears, it is possible to throw an item that affects the boss character MC (boss attack item AI) in the direction of the target, and to throw a combat character BC that fights the boss character MC in the direction of the target. As a result, the user can choose to attack the boss character MC using an item or using a combat character BC, enabling a game with rich strategic depth.

[0140] Furthermore, in the boss battle event described above, the position and orientation of the virtual camera used to generate the game image displayed on the display 12 may be set so that the player character PC is in the field of view from behind the player character PC, or it may be set as a first-person view of the player character PC, and in either case, the position and / or orientation of the virtual camera may be configured to change according to the user's input.

[0141] Furthermore, in the first and second embodiments described above, an example was used in which the player character PC throws an item towards the target by switching between the first and second modes, but many more modes may be provided. For example, by making it possible to switch to a group of categories containing multiple items that affect the combat character BC, a group of categories containing multiple items that affect the gathering object OBJ, a group of categories containing multiple items that affect the player character PC, a group of categories containing multiple items that affect the virtual space, etc., it may be configured to allow switching between three or more modes.

[0142] Next, with reference to Figures 21 to 26, we will describe some specific processes performed by the game system 1 in the first and second embodiments. Figure 21 shows an example of a data area set in the DRAM 85 of the main unit 2 in the first and second embodiments. In addition to the data shown in Figure 21, the DRAM 85 also stores data used in other processes, but a detailed explanation will be omitted.

[0143] The program memory area of ​​DRAM 85 stores various programs Pa that are executed by the game system 1. In this embodiment, the various programs Pa include 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 and the main unit 2. The various programs Pa may be pre-stored in flash memory 84, acquired from a storage medium that can be attached to the game system 1 (e.g., a predetermined type of storage medium installed in slot 23) and stored in DRAM 85, or acquired from other devices via a network such as the Internet and stored in DRAM 85. The processor 81 executes the various programs Pa stored in DRAM 85.

[0144] Furthermore, the data storage area of ​​the DRAM 85 stores various types of data used in information processing and other processes performed 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, targeting data Dj, capture information data Dk, character battle ready flag data Dm, and image data Dn, etc.

[0145] The operation data Da is operation data acquired as appropriate from the left controller 3 and / or the right controller 4 and the main unit 2, respectively. 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 about input from each input unit (specifically, each button, analog stick, and touch panel) (specifically, information about operation). In this embodiment, 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 updated as appropriate 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 it may be updated every cycle in which the above operation data is acquired.

[0146] The player character data database (Db) contains data indicating the placement and orientation of the player character PC in the virtual space, as well as their actions and status within the virtual space.

[0147] Field character data Dc is data that indicates the type, placement location, placement posture, movement, and state of each field character FC placed in the virtual space. Boss character data Dd is data that indicates the type, placement location, placement posture, movement, and state of the boss character MC placed in the virtual space.

[0148] The combat character data De is data that indicates the type, placement, posture, actions, and status of the combat character BC that appears in the virtual space.

[0149] The collected object data Df is data that indicates the type, placement location, placement orientation, and placement status of each collected object OBJ placed in the virtual space.

[0150] The acquired character data Dg is data that shows the type and number of field characters (combat characters) that the user has acquired through capture, etc.

[0151] History data Dh is data that shows mission information related to the history of in-game missions.

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

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

[0154] Capture information data Dk is data related to capture information that indicates how likely it is to make a positive judgment regarding the successful capture of the locked-on field character FC.

[0155] The character combat capability flag data Dm is data that indicates the character combat capability flag, which is set to ON when combat using combat character BC is possible in a boss battle event.

[0156] Image data Dn is data used to display images (for example, images of the player character PC, field character FC, boss character MC, battle character BC, images of each item, images of gathering object OBJ and other objects, images of the targeting reticle, images of the virtual space, background images, etc.) on a display screen (for example, the display 12 of the main unit 2).

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

[0158] The processing steps in the flowcharts shown in Figures 22 to 26 are merely examples; the order of the steps can be changed, or other processing can be performed in addition to (or instead of) the processing of each step, as long as similar results can be obtained. Furthermore, in this embodiment, the processing of each step in the flowchart is described as being performed by the processor 81, but some of the processing steps in the flowchart can be performed by a processor other than the processor 81 or a dedicated circuit. In addition, some of the processing performed in the main unit 2 may be performed by other information processing devices that can communicate with the main unit 2 (for example, a server that can communicate with the main unit 2 via a network). In other words, each of the processes shown in Figures 22 to 26 may be performed by multiple information processing devices, including the main unit 2, working together.

[0159] In Figure 22, the processor 81 performs initial setup for game processing (step S121) and proceeds to the next step. For example, in the initial setup described above, the processor 81 initializes the parameters for 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 the operation data Da does not indicate an instruction to start a boss battle event, and the current situation is not a boss battle event, processor 81 proceeds to step S124, treating the situation as a normal field scene. The explanation for game scenes that are neither boss battle events nor normal field scenes is omitted. On the other hand, if the 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 step S129.

[0162] In step S124, the processor 81 determines, based on the operation data Da, whether or not it is a scene where an item is to be used. If the operation data Da indicates an instruction to use an item or if an animation for using an item is already in progress, the processor 81 proceeds to step S125. On the other hand, if the operation data Da does not indicate an instruction to use an item and an animation for using an item is not in progress, the processor 81 proceeds to step S126. For example, the processor 81 determines that it is a user operation instruction to use an item if an operation input (for example, pressing the operation button (ZR button) 61) has been made to cause the player character PC to assume a throwing motion for an item, and the first category group (first mode) has been selected as the throwing item by a predetermined operation input (for example, pressing the operation button (X button) 55). However, even if an animation for using an item is in progress, if the operation data Da indicates an instruction to use a combat character, the processor 81 makes a negative determination in step S124.

[0163] In step S125, the processor 81 performs the item usage process and proceeds to step S134. The item usage process performed in step S125 will be described below with reference to Figure 23.

[0164] In Figure 23, the processor 81 determines whether or not the item usage animation process is in progress (step S140). For example, if the capture item usage animation process or the item usage animation process has started in steps S149 and S153 described later, the processor 81 makes a positive determination in step S140. If the item usage animation process is not in progress, the processor 81 proceeds to step S141. On the other hand, if the item usage animation process is in progress, the processor 81 proceeds to step S154.

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

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

[0167] In step S143, the processor 81 determines whether or not it has locked onto the field character FC. For example, the processor 81 refers to the operation data Da and, if an operation input that locks onto the field character FC (for example, an operation input that presses the operation button (ZL button) 39) has been performed, it makes a positive determination in step S143. If the processor 81 has locked onto the field character FC, it proceeds to step S144. On the other hand, if the processor 81 has not locked onto the field character FC, it proceeds to step S147.

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

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

[0170] In step S146, the processor 81 performs the encyclopedia image setting process and proceeds to step S148. For example, the processor 81 refers to the history data Dh and extracts mission information related to the history of in-game missions, such as the number of captured and battled field characters FCs that have been locked on. Then, based on the extracted mission information, the processor 81 sets the encyclopedia image (see Figure 17) of the locked-on field character FC.

[0171] On the other hand, in step S147, the processor 81 determines whether the first targeting reticle M1 is positioned so as to overlap the capture range of the field character FC (step S147). For example, if the first targeting reticle M1 is positioned so as to overlap the capture range of either of the field character data DCs placed on the field using the targeting data Dj and field character data Dc, the processor 81 makes a positive determination in step S147. If the first targeting reticle M1 is positioned so as to overlap the capture range of the field character FC, the processor 81 proceeds to step S148. On the other hand, if the first targeting reticle M1 is not positioned so as to overlap the capture range of the field character FC, the processor 81 proceeds to step S152.

[0172] In step S148, the processor 81 determines whether or not to throw the item. For example, the processor 81 refers to the operation data Da and, if an operation to cause the item to be thrown is performed (for example, an operation to cancel the operation to cause the above-mentioned aiming operation, and as an example, an operation to release the pressed operation button (ZR button) 61), it makes a positive determination in step S148. If the processor 81 decides to throw the item, it proceeds to step S149. On the other hand, if the processor 81 decides not to throw the item, it terminates the processing by the subroutine.

[0173] In step S149, the processor 81 starts the capture item usage animation process in which the player character PC throws a capture item, and then terminates the processing by the subroutine. In conjunction with the start of the capture item usage animation process, the processor 81 updates the target data Dj so that the displayed first target M1 is erased.

[0174] On the other hand, in step S152, the processor 81 determines whether or not to throw the item selected as a throwing object. For example, the processor 81 refers to the operation data Da and, if an operation to cause the throwing action of the item is performed (for example, an operation to cancel the operation to cause the above-mentioned aiming action, and as an example, an operation to release the pressed operation button (ZR button) 61), it makes a positive determination in step S152. If the processor 81 decides to throw the item, it proceeds to step S153. On the other hand, if the processor 81 decides not to throw the item, it terminates the processing by the subroutine.

[0175] In step S153, the processor 81 starts an item usage animation process in which the player character PC throws a capture item or an item other than the capture item, and then terminates the processing by the subroutine. In conjunction with the start of the item usage animation process, the processor 81 updates the targeting data Dj (and capture information data Dk) so that the displayed first targeting reticle M1 (and capture information Ig) is erased.

[0176] If it is determined in step S140 that the item usage animation process is in progress, the processor 81 performs the item usage animation process (step S154) and proceeds to the next step. For example, in the item usage animation process, the processor 81 sets the player character PC to throw the item selected as a throwable (capture item or an item other than a capture item) towards the position in the virtual space indicated by the first targeting reticle M1, and also sets the item to move within the virtual space as a result of being thrown.

[0177] In the item usage animation process described above, after the animation of the item being thrown is performed, the processor 81 sets the effect of the item at the location where the item lands. For example, the processor 81 determines the effect of the item being thrown based on the type of item, the location where the thrown item lands, the state of the target to which the item was thrown, etc. Then, based on the determination of the item effect, the processor 81 changes the target in the virtual space to which the item was thrown. As an example, if 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 item effect determination, and the field character data Dc of the field character FC is updated.

[0178] Furthermore, in determining the effects of the items described above, it is possible that the effect may not be obtained even if the item is thrown. For example, if the capture item is thrown outside the range in which a field character FC can be captured, the item may fall or disappear in the virtual space without affecting the field character FC. Also, if the effect of throwing an item is not obtained, the item may be prevented from being thrown. For example, if the effect of throwing an item is not obtained, even if the user inputs an action to throw the item, the player character PC may remain in the above-mentioned ready stance without initiating the animation of throwing the item.

[0179] Furthermore, in the item usage animation process described above, if the processor 81 encounters a situation where the item usage animation process needs to be terminated, it terminates the item usage animation process and also terminates the item usage process that uses the subroutine. Situations in which the item usage animation process needs to be terminated include, for example, when the conditions for terminating the item usage animation process are met (for example, when the effect of the item is no longer applied to objects or characters in the virtual space), or when the user performs an operation to terminate the item usage animation process.

[0180] Next, the processor 81 determines whether or not to perform a capture determination process (step S155). For example, if the throwing capture item has finished moving in the virtual space and it is time to perform a capture determination, the processor 81 makes a positive determination in step S155. If the processor 81 decides to perform a capture determination process, it proceeds to step S156. On the other hand, if it is not yet time to perform a capture determination process, or if an item other than a capture item has been thrown, the processor 81 terminates the processing by the subroutine.

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

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

[0183] In step S158, the processor 81 sets up a capture success animation and sets the captured field character FC to a state owned by the user, and then terminates the processing by the subroutine. For example, the processor 81 sets up a capture success animation (see Figures 9 and 10) in which the field character FC is placed inside an empty ball item B, indicating that the field character FC has been captured, and then terminates the item usage animation processing and the item usage processing that uses the subroutine. The processor 81 also updates the acquired character data Dg so that the captured field character FC is in a state owned by the user.

[0184] In step S159, the processor 81 sets up a capture failure animation to be performed and terminates the processing by the subroutine. For example, the processor 81 sets up a capture failure animation to be performed, which shows that the field character FC was not stored in the empty ball item B, and terminates the item usage animation processing and the item usage processing that uses the subroutine.

[0185] Returning to Figure 22, if it is determined in step S124 that it is not a scene to use an item, the processor 81 determines whether or not it is a scene to use a combat character, according to the operation data Da (step S126). If the operation data Da indicates an instruction to use a combat character or if a performance using a combat character is already underway, the processor 81 proceeds to step S127. On the other hand, if the operation data Da does not indicate an instruction to use a combat character and a performance using a combat character is not underway, the processor 81 proceeds to step S128. As an example, if an operation input (for example, pressing the operation button (ZR button) 61) has been made to cause the player character PC to assume a throwing motion for the combat character, and the second category group (second mode) has been selected as the throwing object by a predetermined operation input (for example, pressing the operation button (X button) 55), the processor 81 determines that it is a user operation instruction to use a combat character.

[0186] In step S127, the processor 81 performs the first character usage process and proceeds to step S134. The first character usage process performed in step S127 will be described below with reference to Figure 24.

[0187] In Figure 24, the processor 81 determines whether or not the combat character is in the middle of combat processing (step S161). For example, if the combat processing that will cause the combat character and the field character to fight has started in step S167, which will be described later, the processor 81 makes a positive determination in step S161. If the combat character is not in the middle of combat processing, the processor 81 proceeds to step S162. On the other hand, if the combat character is in the middle of combat processing, the processor 81 proceeds to step S174.

[0188] In step S162, the processor 81 determines whether or not the battle character appearance animation process is in progress. For example, if the battle character appearance animation process has started in step S172 (described later), the processor 81 makes a positive determination in step S162. If the battle character appearance animation process is not in progress, the processor 81 proceeds to step S163. On the other hand, if the battle character appearance animation process is in progress, the processor 81 proceeds to step S175.

[0189] In step S163, the processor 81 sets the combat character to be thrown by the player character PC, sets the second target reticle 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, in response to the operation input for selecting a combat character (for example, pressing operation button (L button) 38 or operation button (R button) 60), selects and sets the combat character BC to be thrown from the characters owned by the player character PC, and sets the thrown item information Im2 (see Figures 11 to 16). The processor 81 also refers to the operation data Da and sets the target reticle type to the second target reticle M2 (see Figure 11), sets the position of the reticle in accordance with the operation input for moving the reticle (for example, the tilt direction of the analog stick 32 or 52), and updates the target reticle data Dj.

[0190] Next, the processor 81 determines whether the second targeting reticle M2 is positioned in a location that overlaps with the combat range in which combat with the field character FC is possible (step S164). For example, using the targeting data Dj and the field character data Dc, the processor 81 determines in step S164 that the second targeting reticle M2 is positioned in a location that overlaps with the combat range in which combat with any of the field character data DC placed on the field is possible. If the second targeting reticle M2 is positioned in a location that overlaps with the combat range, the processor 81 proceeds to step S165. On the other hand, if the second targeting reticle M2 is not positioned in a location that overlaps with the combat range, the processor 81 proceeds to step S169.

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

[0192] Next, the processor 81 determines whether or not to throw the combat character (step S166). For example, the processor 81 refers to the operation data Da and, if an operation to cause the combat character (ball item Bs) to throw is performed (for example, an operation to cancel the operation to cause the above-mentioned stance operation, and as an example, an operation to release the pressed operation button (ZR button) 61), it makes a positive determination in step S166. If the processor 81 decides to throw the combat character, it proceeds to step S167. On the other hand, if the processor 81 decides not to throw the combat character, it terminates the processing by the subroutine.

[0193] In step S167, the processor 81 starts combat processing to make the combat character and the field character fight, and then terminates the processing by the subroutine. In addition, upon starting the combat processing, the processor 81 updates the targeting data Dj so that the displayed third targeting reticle M3 is erased.

[0194] On the other hand, in step S169, the processor 81 determines whether the second targeting reticle M2 is positioned in a location that overlaps with the appearance animation range in which a combat character can appear in the virtual space and perform actions other than combat. For example, if the processor 81 uses the targeting data Dj and the acquisition object data Df to determine that the second targeting reticle M2 is positioned to overlap with the range in which an action (appearance animation) of acquiring any of the acquisition objects OBJ (see Figures 15 and 16) placed on the field can be performed, it makes a positive determination in step S169. If the second targeting reticle M2 is positioned in a location that overlaps with the appearance animation range, the processor 81 proceeds to step S170. On the other hand, if the second targeting reticle M2 is not positioned in a location that overlaps with the appearance animation range, the processor 81 terminates the processing by the subroutine.

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

[0196] Next, the processor 81 determines whether or not to throw the combat character (step S171). For example, the processor 81 refers to the operation data Da and, if an operation to cause the combat character (ball item Bs) to throw is performed (for example, an operation to cancel the operation to cause the above-mentioned stance operation, and as an example, an operation to release the pressed operation button (ZR button) 61), it makes a positive determination in step S171. Then, if the processor 81 decides to throw the combat character, it proceeds to step S172. On the other hand, if the processor 81 decides not to throw the combat character, it terminates the processing by the subroutine.

[0197] In step S167, the processor 81 starts an appearance animation process that makes a combat character appear in the virtual space and has it perform actions other than combat, and then terminates the processing by the subroutine. In addition, the processor 81 updates the targeting data Dj so that the displayed fourth targeting reticle M4 is erased when the appearance animation process starts.

[0198] Furthermore, if an input is made to perform the action of throwing a combat character while the targeting reticle (specifically, the second targeting reticle 2) is superimposed outside the combat range and outside the appearance animation range, for 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 be made unthrowable. In this case, even if the user inputs an input to perform the action of throwing the ball item Bs, the player character PC may remain in the above-mentioned ready stance without initiating the ball item Bs throwing animation, and the first character usage process may continue. Alternatively, the first character usage process may be terminated without initiating the ball item Bs throwing animation.

[0199] If it is determined in step S161 that combat processing is underway, the processor 81 performs combat processing (step S174) and terminates the processing by the subroutine. For example, in the combat processing, the processor 81 sets the player character PC to throw a ball item Bs containing the combat character BC, which has been selected as a throwable object, towards the position in the virtual space indicated by the third target M3, and sets the ball item Bs to move in the virtual space as it is thrown, and sets a series of animations to make the combat character BC appear from the position in the virtual space where the ball item Bs has reached. After the above series of animations have been performed, the processor 81 performs processing to make the appeared combat character BC and the field character FC fight.

[0200] During the battle process described above, the processor 81 changes the state of the battle character BC and the field character FC through combat with the battle character BC, and defeats any character whose state falls to a predetermined threshold in that battle. Also during the battle process, the processor 81 sets the actions of the battle character BC and / or the player character PC according to the input of selecting a command to control the actions of the battle character BC and / or the player character PC. For example, if the operation data Da indicates that the operation input has been selected from multiple attack commands, the processor 81 controls the battle character BC with an attack action corresponding to that attack command. Also, if the operation data Da indicates that the operation input has been selected to use a capture item to capture the field character FC during battle, the processor 81 causes the player character PC to perform an action to capture the field character FC using that capture item. Then, the processor 81 makes a capture success determination for the field character FC based on the state of the field character FC described above. If the capture success determination is affirmative, the processor 81 sets up an animation for the field character FC to be captured and sets the field character FC to a state in which the user owns it.

[0201] Furthermore, in the battle processing in step S161 described above, if the processor 81 encounters a situation that warrants termination of the battle processing, it terminates the battle processing and also terminates the first character usage processing that uses the subroutine. Situations that warrant termination of the battle processing include, for example, the fulfillment of the conditions for termination of the battle processing (for example, the capture of the field character FC in which the battle character BC is fighting, the victory / defeat of the battle by the battle character BC, etc.), or the user performing an operation to terminate the battle processing.

[0202] If it is determined in step S162 that the appearance animation process is in progress, the processor 81 performs the appearance animation process (step S175) and terminates the processing by the subroutine. For example, in the appearance animation process, the processor 81 sets the player character PC to throw a ball item Bs containing the selected combat character BC towards the position in the virtual space indicated by the fourth targeting reticle M4, and also sets the ball item Bs to move in the virtual space as it is thrown, setting a series of animations to make the combat character BC appear from the position in the virtual space where the ball item Bs has reached. After the series of animations has been performed, the processor 81 performs an appearance animation process to make the appeared combat character BC perform a predetermined action (for example, an action to collect a collection object OBJ).

[0203] In the appearance animation process described above, when the processor 81 determines that the appearance animation process should be terminated, it terminates the appearance animation process and also terminates the first character usage process that uses the subroutine. Situations that lead to the termination of the appearance animation process include, for example, when the conditions for terminating the appearance animation process are met (for example, when the predetermined action by the battle character BC is completed) or when the user performs an operation to terminate the appearance animation process.

[0204] Returning to Figure 22, if it is determined in step S126 that it is not a situation in which a combat character is to be used, the processor 81 performs other processing according to the operation data Da (step S128) and proceeds to step S134. As an example of the above other processing, the processor 81 changes the position and orientation of the player character PC in the virtual space and updates the player character data Db in response to the operation input that moves the player character PC indicated by the operation data Da.

[0205] If it is determined in step S123 that a boss battle event is in progress, the processor 81 determines, based on the operation data Da, whether or not it is a scene in the boss battle event where a boss item is to be used (step S129). If the operation data Da indicates an instruction to use a boss item or if the animation for using a boss item is already in progress, the processor 81 proceeds to step S130. On the other hand, if the operation data Da does not indicate an instruction to use a boss item and the animation for using a boss item is not in progress, the processor 81 proceeds to step S131. As an example, if an operation input has been made to cause the player character PC to assume a throwing motion for a boss item (for example, pressing the operation button (ZR button) 61), and the first category group (first mode) has been selected as the throwing item by a predetermined operation input (for example, pressing the operation button (X button) 55), the processor 81 determines that it is a user operation instruction to use a boss item. Furthermore, even during the animation for using a boss item, if the operation data Da indicates an instruction to use a battle character, the processor 81 will make a negative determination in step S129 above.

[0206] In step S130, the processor 81 performs the boss item usage process and proceeds to step S134. The boss item usage process performed in step S130 will be explained below with reference to Figure 25.

[0207] In Figure 25, processor 81 determines whether or not the boss item usage animation process is in progress (step S180). For example, if the boss item usage animation process has started in step S183, which will be described later, processor 81 makes a positive determination in step S180. If the boss item usage animation process is not in progress, processor 81 proceeds to step S181. On the other hand, if the boss item usage animation process is in progress, processor 81 proceeds to step S188.

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

[0209] Next, the processor 81 determines whether or not to throw the boss item (step S182). For example, the processor 81 refers to the operation data Da and, if an operation to throw the boss item is performed (for example, an operation to cancel the operation to perform the above-mentioned aiming action, and as an example, an operation to release the pressed operation button (ZR button) 61), it makes a positive determination in step S182. Then, if the processor 81 decides to throw the boss item, it proceeds to step S183. On the other hand, if the processor 81 decides not to throw the boss item, it proceeds to step S184.

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

[0211] In step S184, the processor 81 determines whether or not it is in a state where it can summon the battle character BC for battle with the boss character MC. For example, if the boss character MC is in a predetermined state, the processor 81 makes a positive determination in step S184. If the processor 81 is in a state where it can summon the battle character BC, it proceeds to step S185. On the other hand, if the processor 81 is not in a state where it can summon the battle character BC, it proceeds to step S186.

[0212] In step S185, the processor 81 updates the character combat readiness flag data Dm by setting the character combat readiness flag to ON, and proceeds to step S186.

[0213] In step S186, the processor 81 determines whether or not to terminate the boss battle event. Situations that may terminate the boss battle event include, for example, when the conditions for terminating the boss battle event are met (for example, when the boss state parameter (see gauge G2 shown in Figure 18) reaches a threshold, when the boss character MC wins / loses the event battle against the player character PC, when the event time expires, etc.), or when the user performs an operation to terminate the boss battle event. If the processor 81 decides to terminate the boss battle event, it proceeds to step S187. On the other hand, if the processor 81 decides not to terminate the boss battle event, it terminates the processing by the subroutine.

[0214] In step S187, the processor 81 performs the boss battle event termination process and finishes processing by the subroutine. For example, the processor 81 finishes the boss item usage process and sets up the victory / defeat animation for the boss character MC against the player character PC, and then performs the boss battle event termination process.

[0215] If it is determined in step S180 that the boss item usage animation process is underway, the processor 81 performs the boss item usage animation process (step S188) and proceeds to step S186. For example, in the boss item usage animation process, the processor 81 sets the player character PC to throw the boss item selected as a projectile towards the position in the virtual space indicated by the first target M1, and also sets the boss item to move within the virtual space as a result of being thrown.

[0216] In the boss item usage animation process described above, after the animation of the boss item being thrown is performed, the processor 81 sets the effect of the boss item at the location where the boss item reaches. For example, the processor 81 determines the effect of the boss item being thrown based on the type of boss item, the location where the thrown boss item reaches, the location where the thrown boss item hits the boss character MC, the state of the boss character MC to which the boss item was thrown, etc. Then, based on the determination of the boss item effect, the processor 81 changes the boss character MC to which the boss item was thrown and targets in the virtual space. As an example, if the boss item hits the boss character MC, the processor 81 changes the state of the boss character MC (for example, the boss state parameter) based on the determination result of the boss item effect and updates the boss character data Dd.

[0217] In the boss item usage animation process described above, when the processor 81 determines that the boss item usage animation process is about to end, it updates the targeting data Dj so that the displayed first targeting reticle M1 is erased, and then terminates the boss item usage animation process and the boss item usage process that uses the subroutine. Situations in which the item usage animation process is about to end include, for example, when the conditions for terminating the item usage animation process are met (for example, when the effect of the boss item is no longer applied to the boss character MC in the virtual space), or when the user performs an operation to terminate the boss item usage animation process.

[0218] Returning to Figure 22, if it is determined in step S129 that it is not a scene to use a boss item, the processor 81 determines whether or not it is a scene to use a combat character, according to the operation data Da (step S131). If the operation data Da indicates an instruction to use a combat character or if a performance using a combat character is already underway, the processor 81 proceeds to step S132. On the other hand, if the operation data Da does not indicate an instruction to use a combat character and a performance using a combat character is not underway, the processor 81 proceeds to step S133. As an example, if an operation input has been made to cause the player character PC to assume a throwing motion for the combat character (for example, pressing the operation button (ZR button) 61), and the second category group (second mode) has been selected as the throwing item by a predetermined operation input (for example, pressing the operation button (X button) 55), the processor 81 determines that it is a user operation instruction to use a combat character.

[0219] In step S132, the processor 81 performs the second character usage process and proceeds to step S134. The second character usage process performed in step S132 will be described below with reference to Figure 26.

[0220] In Figure 26, processor 81 determines whether or not a battle is in progress between the combat character and the boss character (step S191). For example, if the boss battle process, which will be described later in step S197, has started, processor 81 makes a positive determination in step S191. If the battle is not in progress between the combat character and the boss character, processor 81 proceeds to step S192. On the other hand, if the battle is in progress between the combat character and the boss character, processor 81 proceeds to step S198.

[0221] In step S192, the processor 81 sets the combat character to be thrown by the player character PC, sets the second targeting reticle 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, in response to the operation input for selecting a combat character (for example, pressing operation button (L button) 38 or operation button (R button) 60), selects and sets the combat character BC to be thrown from the characters owned by the player character PC, and sets the thrown item information Im2 (see Figures 19 and 20). The processor 81 also refers to the operation data Da and sets the targeting reticle type to the second targeting reticle M2, sets the position of the reticle in accordance with the operation input for moving the reticle (for example, the tilting direction of the analog stick 32 or 52), and updates the targeting reticle data Dj.

[0222] Next, the processor 81 refers to the character combat readiness flag data Dm and determines whether the character combat readiness flag is set to ON or OFF (step S193). If the character combat readiness flag is set to ON, the processor 81 proceeds to step S194. On the other hand, if the character combat readiness flag is set to OFF, the processor 81 proceeds to step S200.

[0223] In step S194, the processor 81 determines whether the second targeting reticle M2 is positioned in a location that overlaps with the combat range in which the boss character MC and the combat character BC can engage in combat. For example, using the targeting data Dj and boss character data Dd, the processor 81 determines in step S194 that the second targeting reticle M2 is positioned to be superimposed within the combat range in which the boss character MC placed on the field can engage in combat. If the second targeting reticle M2 is positioned in a location that overlaps with the combat range, the processor 81 proceeds to step S195. On the other hand, if the second targeting reticle M2 is not positioned in a location that overlaps with the combat range, the processor 81 proceeds to step S200.

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

[0225] Next, the processor 81 determines whether or not to throw the combat character (step S196). For example, the processor 81 refers to the operation data Da and, if an operation to cause the combat character (ball item Bs) to be thrown is performed (for example, an operation to cancel the operation to cause the above-mentioned stance operation, and as an example, an operation to release the pressed operation button (ZR button) 61), it makes a positive determination in step S196. Then, if the processor 81 decides to throw the combat character, it proceeds to step S197. On the other hand, if the processor 81 decides not to throw the combat character, it terminates the processing by the subroutine.

[0226] In step S197, processor 81 starts boss battle processing, which involves pitting the combat character against the boss character, and proceeds to step S200. Upon starting the boss battle processing, processor 81 updates the targeting data Dj so that the displayed third targeting reticle M3 is erased.

[0227] In this embodiment, however, it is not necessary to provide the combat range described above, which allows for combat between the boss character MC and the combat character BC. In this case, regardless of the position of the second targeting reticle M2, it will be changed to the third targeting reticle M3. Furthermore, regardless of the position of the changed third targeting reticle M3, the player character PC can throw the combat character BC to initiate the boss combat process, causing it to fight the boss character MC.

[0228] If it is determined in step S191 that combat processing is underway, the processor 81 performs boss combat processing (step S198) and proceeds to step S200. For example, in the boss combat processing, the processor 81 sets the player character PC to throw a ball item Bs containing the combat character BC, which has been selected as a throwable object, towards the position in the virtual space indicated by the third target M3, and sets the ball item Bs to move within the virtual space as it is thrown, and sets a series of animations to make the combat character BC appear from the position in the virtual space where the ball item Bs has reached. After the above series of animations have been performed, the processor 81 performs processing to make the appeared combat character BC and the boss character MC fight.

[0229] During the boss battle processing described above, the processor 81 changes the state of the battle character BC and the field character FC through combat with the battle character BC, and defeats any character whose state falls below a predetermined threshold in that battle. Also during the boss battle processing described above, the processor 81 sets the actions of the battle character BC and / or the player character PC in response to an input that selects a command to control the actions of the battle character BC and / or the player character PC. For example, if the operation data Da indicates an input selected from multiple attack commands, the processor 81 controls the battle character BC with an attack action corresponding to that attack command.

[0230] Furthermore, in the boss battle processing in step S198 described above, if the processor 81 determines that the boss battle processing should be terminated, it terminates the boss battle processing and also terminates the second character usage processing that uses the subroutine. Situations in which the boss battle processing should be terminated include, for example, when the conditions for terminating the boss battle processing are met (for example, when the boss character MC wins / loses a battle with the battle character BC), or when the user performs an operation to terminate the boss battle processing. If, in the battle between the boss character MC and the battle character BC, the battle character BC wins against the boss character MC, the processor 81 adjusts the system to make it easier to meet the clear conditions for the boss battle event, for example, by setting restrictions on the movement of the boss character MC in the virtual space for at least a predetermined period from the time of victory.

[0231] In step S200, the processor 81 determines whether or not to terminate the boss battle event. Situations that may terminate the boss battle event include, for example, when the conditions for terminating the boss battle event are met (e.g., the boss character MC wins / loses the event battle against the player character PC, the event time expires, etc.) or when the user performs an operation to terminate the boss battle event. If the processor 81 decides to terminate the boss battle event, it proceeds to step S201. On the other hand, if the processor 81 decides not to terminate the boss battle event, it terminates the processing by the subroutine.

[0232] In step S201, processor 81 performs the boss battle event termination process and finishes processing by the subroutine. For example, processor 81 finishes the second character usage process and sets up the animation for when the boss character MC wins or loses against the player character PC, and then performs the boss battle event termination process.

[0233] Returning to Figure 22, if it is determined in step S131 that it is not a situation in which a combat character is to be used, the processor 81 performs other processing according to the operation data Da (step S133) and proceeds to step S134. As an example of the other processing, the processor 81 changes the position and orientation of the player character PC in the virtual space according to the operation input that moves the player character PC indicated by the operation data Da, and updates the player character data Db. Furthermore, if the conditions for the boss battle event to be terminated are met in step S128, the processor 81 performs the boss battle event termination processing.

[0234] In step S134, the processor 81 performs character movement processing and proceeds to the next step. For example, based on the processing results of steps S122 to S133, the processor 81 sets the movements and remaining amounts of each gauge for each character in the virtual space, such as the player character PC, battle character BC, field character FC, and boss character MC. As an example, based on the settings in steps S122 to S133, the progress of the set effects, the movement algorithm for the automatically controlled characters, the virtual physics calculations in the virtual space, and the operation inputs indicated by the operation data Da, the processor 81 sets the position, posture, movement, and state of each character, as well as the remaining amounts of each gauge, and updates the 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 such as the aforementioned boss battle event or an in-game mission is started based on the game progress or the operation input indicated by the operation data Da, the processor 81 makes the relevant character appear in the virtual space in response to the start of the event, sets the character's position, posture, movement, and state, and the remaining amount of each gauge, and updates the character data.

[0235] Next, the processor 81 performs display control processing (step S135) and proceeds to the next step. For example, the processor 81 places each character, object, gauge, and item in the virtual space based on the processing results of steps S122 to S134 and data related to each character, object, and item. The processor 81 also sets the position and orientation of the virtual camera based on the operation data Da and the position and orientation of the player character PC, and controls the generation of an image of the virtual space as seen from the virtual camera and displays it on the display 12. The processor 81 also controls the superimposition of targeting and / or capture information onto the image of the virtual space and displays it on the display 12 based on the targeting data Dh and capture information data Di. The targeting and / or capture information may also be displayed as part of the image of the virtual space as seen from the virtual camera by being placed within the virtual space. Furthermore, if it is a picture book display scene, the processor 81 controls the display 12 to display the picture book image set in step S146.

[0236] Next, the processor 81 determines whether or not to terminate the game processing (step S136). Conditions for terminating the game processing in step S136 include, for example, that the conditions for terminating the game processing have been met, or that the user has performed an operation to terminate the game processing. If the processor 81 does not terminate the game processing, it returns to step S122 and repeats the process, and if it decides to terminate the game processing, it terminates the process according to the flowchart. From there, the series of processes from steps S122 to S136 are repeatedly executed until it is determined in step S136 that the processing should be terminated.

[0237] Thus, in this embodiment, by switching between the first mode and the second mode, it becomes possible to have the player character PC perform multiple different types of actions by inputting an action to fire towards the target M. These actions include firing items that affect the field character FC or boss character MC targeted on the field, and firing a combat character BC to engage in combat with the field character FC or boss character MC on the field.

[0238] In the embodiments described above, examples of operation inputs for executing each process are provided, but it goes without saying that the operation inputs do not have to be limited to these examples. In this embodiment, in addition to operations using the operation buttons and sticks, touch operations using the touch panel 13, operations using the movement and orientation of the main unit 2, operations using the movement and orientation of the left controller 3 and right controller 4, and operations pointing using the left controller 3 and right controller 4 may also be used as the above operation inputs.

[0239] Furthermore, in the embodiments described above, the player character throws items and characters into the virtual space by throwing them, but items and characters can also be thrown into the virtual space by other actions. For example, the player character may throw items and characters into the virtual space by kicking, pushing, blowing, shooting (shooting, cannon fire, radiating, irradiating, etc.), hitting, etc.

[0240] Furthermore, in the above-described embodiment, items that are described as obtaining an effect by hitting a target such as a field character FC, boss character MC, or gathering object OBJ may obtain an effect by reaching an area formed near the target, even without hitting the target. Conversely, in the above-described embodiment, items that are described as obtaining an effect by reaching an area formed near the target may obtain an effect by hitting the target. Also, regarding the process of locking onto one of the field characters FC in response to an input, during a boss battle event, it may be configured to allow locking onto the boss character MC in response to the same input.

[0241] Furthermore, in the above-described embodiment, gauges G (gauges G1 to G3) are used to indicate the status of field character FC and boss character MC. However, these gauges G may indicate any parameters as long as they indicate parameters that advance in-game missions or events. For example, parameters that advance in-game missions or events may indicate the character's emotions (joy, anger, sadness, etc.), durability, remaining health, action status, life points, etc.

[0242] Furthermore, the in-game events and missions in the above-described embodiment are assumed to be seamlessly connected throughout the entire game and played on the same virtual field. However, even when playing on the same virtual field, this embodiment may also include scenes that switch between events and missions.

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

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

[0245] As described above, the invention can be realized in so-called cloud computing system configurations, distributed wide-area networks, and local network system configurations. For example, in a distributed local network system configuration, the above processing can be performed collaboratively between a stationary information processing device (stationary game device) and a portable information processing device (portable game device). It goes without saying that in these system configurations, there are no particular limitations on which device performs the above processing, and the invention can be realized regardless of how the processing is divided.

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

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

[0248] Although the present invention has been described in detail above, the above description is merely illustrative 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. Furthermore, those skilled in the art will understand from the description of specific embodiments of the present invention that an equivalent scope can be implemented based on the description of the present invention and common technical knowledge. In addition, it should be understood that the terms used herein are used in the sense commonly used in the art unless otherwise specified. Accordingly, unless otherwise defined, all technical terms used herein have the same meaning as commonly understood by those skilled in the art to which the present invention pertains. In case of any conflict, this specification (including definitions) shall prevail. [Industrial applicability]

[0249] As described above, the present invention can be used as a game program, game system, game device, and game processing method, etc., that enables player characters to perform various types of actions on a virtual space field. [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 Communications Department 83... Controller Communication Unit 85…DRAM 89, 104, 114... Accelerometer 90, 105, 115... Angular velocity sensors 101, 111... Communication Control Unit

Claims

1. In the computer of the information processing device, Based on the first operation input, the system switches between at least the first mode and the second mode. In the first mode, Based on the second input, the aiming direction in the virtual space is determined, Based on the third input, the player character is instructed to release an item that affects a field character placed on the field in the virtual space, aiming in the direction of the targeting, and when the item is released at the location where the field character is placed, the field character is given the effect associated with the item. In the second mode, Based on the second operation input, the aiming direction is determined, A game program that, based on the third operation input, causes the player character to release a combat character to engage in combat in the aiming direction, and when the combat character is released to a location where a field character is positioned, initiates combat between the field character and the combat character on the field.

2. The aforementioned item includes at least a capture item for capturing the aforementioned field character, The aforementioned computer further, If the capture item released in the first mode hits the field character, a capture success determination is made to determine whether the capture is successful or not. The game program according to claim 1, wherein, if the capture success determination is affirmative, the player is set to own the field character that was hit by the captured item.

3. The game program according to claim 2, further comprising an item having the effect of making it easier for the capture success determination to be positive.

4. The game program according to claim 2 or 3, further comprising an item having the effect of restricting the movement of the field character on the field.

5. The game program according to any one of claims 2 to 4, further comprising causing the computer to direct the aiming direction toward the field character based on a fourth operation input.

6. The game program according to claim 5, further comprising the computer displaying an index indicating the ease of making a positive determination of the capture success for the field character to which the aiming direction is directed, based on the fourth operation input.

7. The game program according to claim 5 or 6, further comprising causing the computer to display information about the field character to which the aiming direction is directed, based on the fourth and fifth operation inputs.

8. The game program according to claim 7, wherein the field character information includes mission information relating to the history of in-game missions, which at least includes the number of field characters captured and the number of battles fought with the field characters.

9. The aforementioned computer further, After the start of the battle, the combat character and the field character are made to fight on the field based on the input of the combat character, which includes at least attack commands and item usage commands. If an instruction to use the capture item is given during the aforementioned battle, the system will use the capture item to perform an in-battle capture success determination regarding whether or not the field character will be successfully captured based on the state of the field character that changes as a result of the battle. The game program according to any one of claims 2 to 8, wherein if the capture success check during the battle is determined to be positive, the program sets the field character to be owned by the player.

10. The aforementioned computer further, In the aforementioned battle, An indicator showing the state of the field character, at least regarding its physical strength, is displayed at a position set corresponding to the position of the field character. A game program according to any one of claims 1 to 9, which controls the orientation of a virtual camera based on a sixth operation input.

11. The game program according to any one of claims 1 to 10, further comprising the following steps: when the computer is released in the second mode, the combat character is placed in a location on the field where a gathering object indicating that an item can be obtained is located, the combat character is made to perform a predetermined action on the gathering object, causing the player to acquire the item associated with the gathering object.

12. The game program according to any one of claims 1 to 11, further comprising causing the computer to display the indicator showing the aiming direction in different display modes for the first mode and the second mode.

13. The aforementioned item is an event item that advances an in-game event when it hits the aforementioned field character. To the aforementioned computer, In the aforementioned in-game event, When multiple event items are hit on the field character until the predetermined clear conditions are met, the in-game event is determined to have been cleared. The game program according to claim 1, which controls the game so that the clear conditions are more easily met when the player wins the battle against the field character.

14. The game program according to claim 13, wherein if the player wins the battle against the field character, the program restricts the movement of the field character in the virtual space for at least a predetermined period of time.

15. The aforementioned clear condition is to reduce the event parameter, which decreases each time the event item hits the field character, to a predetermined standard. The game program according to claim 13 or 14, wherein, if the player wins the battle against the field character, the amount of decrease in the event parameter corresponding to hitting the event item within a predetermined period is relatively increased.

16. A game system equipped with a processor, The aforementioned processor, Based on the first operation input, the system switches between at least the first mode and the second mode. In the first mode, Based on the second input, the aiming direction in the virtual space is determined, Based on the third input, the player character is instructed to release an item that affects a field character placed on the field in the virtual space, aiming in the direction of the targeting, and when the item is released at the location where the field character is placed, the field character is given the effect associated with the item. In the second mode, Based on the second operation input, the aiming direction is determined, A game system that, based on the third operation input, causes the player character to release a combat character to engage in combat in the aiming direction, and when the combat character is released to a location where a field character is positioned, initiates combat between the field character and the combat character on the field.

17. The aforementioned item includes at least a capture item for capturing the aforementioned field character, The aforementioned processor further, If the capture item released in the first mode hits the field character, a capture success determination is made to determine whether the capture is successful or not. The game system according to claim 16, wherein, if the capture success determination is affirmative, the player is set to own the field character that was hit by the capture item.

18. The game system according to claim 17, further comprising an item having the effect of making it easier for the capture success determination to be positive.

19. The game system according to claim 17 or 18, further comprising an item having the effect of restricting the movement of the field character on the field.

20. The game system according to any one of claims 17 to 19, wherein the processor further directs the aiming direction toward the field character based on a fourth operation input.

21. The game system according to claim 20, wherein the processor further displays an index indicating the ease of making a positive determination of the capture success for the field character to which the aiming direction is directed, based on the fourth operation input.

22. The game system according to claim 20 or 21, wherein the processor further displays information about the field character to which the aiming direction is directed, based on the fourth and fifth operation inputs.

23. The game system according to claim 22, wherein the information of the field character includes mission information relating to the history of in-game missions, which at least includes the number of field characters captured and the number of battles fought with the field characters.

24. The aforementioned processor further, After the start of the battle, the combat character and the field character are made to fight on the field based on the input of the combat character, which includes at least attack commands and item usage commands. If an instruction to use the capture item is given during the aforementioned battle, a battle-in-battle capture success determination is made using the capture item, based on the state of the field character that changes as a result of the battle, to determine whether or not the capture of the field character is successful. The game system according to any one of claims 17 to 23, wherein if the capture success check during the aforementioned battle is determined to be positive, the field character is set to be owned by the player.

25. The aforementioned processor further, In the aforementioned battle, An indicator showing at least the state of the field character, relating to its physical strength, is displayed at a position set corresponding to the position of the field character. A game system according to any one of claims 16 to 24, which controls the orientation of a virtual camera based on a sixth operation input.

26. The game system according to any one of claims 16 to 25, wherein the processor further, in the second mode, when the combat character is placed in a location on the field where a gathering object indicating that an item can be obtained is located, causes the combat character to perform a predetermined action on the gathering object, and puts the item associated with the gathering object into a state where the player has obtained it.

27. The game system according to any one of claims 16 to 26, wherein the processor further displays the indicator showing the aiming direction in different display modes for the first mode and the second mode.

28. The aforementioned item is an event item that advances an in-game event when it hits the aforementioned field character. The aforementioned processor, In the aforementioned in-game event, When multiple event items are hit on the field character until the predetermined clear conditions are met, it is determined that the in-game event has been cleared. The game system according to claim 16, wherein if the player wins the battle against the field character, the system controls the game to make it easier to satisfy the clear conditions.

29. The game system according to claim 28, wherein if the player wins the battle against the field character, the player restricts the movement of the field character in the virtual space for at least a predetermined period of time.

30. The aforementioned clear condition is to reduce the event parameter, which decreases each time the event item hits the field character, to a predetermined standard. The game system according to claim 28 or 29, wherein, if the player wins the battle against the field character, the amount of decrease in the event parameter corresponding to hitting the event item within a predetermined period is relatively increased.

31. A game device equipped with a processor, The aforementioned processor, Based on the first operation input, the system switches between at least the first mode and the second mode. In the first mode, Based on the second input, the aiming direction in the virtual space is determined, Based on the third input, the player character is instructed to release an item that affects a field character placed on the field in the virtual space, aiming in the direction of the targeting, and when the item is released at the location where the field character is placed, the field character is given the effect associated with the item. In the second mode, Based on the second operation input, the aiming direction is determined, A game device that, based on the third operation input, causes the player character to release a combat character to engage in combat in the aiming direction, and when the combat character is released to a location where a field character is positioned, initiates combat between the field character and the combat character on the field.

32. The aforementioned item includes at least a capture item for capturing the aforementioned field character, The aforementioned processor further, If the capture item released in the first mode hits the field character, a capture success determination is made to determine whether the capture is successful or not. The game device according to claim 31, wherein, if the capture success determination is affirmative, the player is set to own the field character that was hit by the captured item.

33. The aforementioned processor further, After the start of the battle, the combat character and the field character are made to fight on the field based on the input of the combat character, which includes at least attack commands and item usage commands. If an instruction to use the capture item is given during the aforementioned battle, a battle-in-battle capture success determination is made using the capture item, based on the state of the field character that changes as a result of the battle, to determine whether or not the capture of the field character is successful. The game device according to claim 32, wherein if the capture success determination during the battle is determined to be positive, the field character is set to be owned by the player.

34. The aforementioned item is an event item that advances an in-game event when it hits the aforementioned field character. The aforementioned processor, In the aforementioned in-game event, When multiple event items are hit on the field character until the predetermined clear conditions are met, it is determined that the in-game event has been cleared. The game device according to claim 31, which controls the game so that the clear conditions are more easily met when the player wins the battle against the field character.

35. In the processor of the information processing device, Based on the first operation input, the system switches between at least the first mode and the second mode. In the first mode, Based on the second input, the aiming direction in the virtual space is determined, Based on the third input, the player character is instructed to release an item that affects a field character placed on the field in the virtual space, aiming in the direction of the targeting, and when the item is released at the location where the field character is placed, the field character is given the effect associated with the item. In the second mode, Based on the second operation input, the aiming direction is determined, A game processing method that, based on the third operation input, causes the player character to release a combat character to engage in combat, aiming in the targeting direction, and when the combat character is released to a location where a field character is positioned, initiates combat between the field character and the combat character on the field.

36. The aforementioned item includes at least a capture item for capturing the aforementioned field character, The aforementioned processor further includes, If the capture item released in the first mode hits the field character, a capture success determination is made to determine whether the capture is successful or not. The game processing method according to claim 35, wherein, if the capture success determination is affirmative, the player is set to own the field character that was hit by the captured item.

37. The aforementioned processor further includes, After the start of the battle, the combat character and the field character are made to fight on the field based on the input of the combat character, which includes at least attack commands and item usage commands. If an instruction to use the capture item is given during the aforementioned battle, the system will use the capture item to perform an in-battle capture success determination regarding whether or not the field character will be successfully captured based on the state of the field character that changes as a result of the battle. The game processing method according to claim 36, wherein if the capture success determination during the battle is determined to be positive, the field character is set to be owned by the player.

38. The aforementioned item is an event item that advances an in-game event when it hits the aforementioned field character. The aforementioned processor, In the aforementioned in-game event, When multiple event items are hit on the field character until the predetermined clear conditions are met, the in-game event is determined to have been cleared. The game processing method according to claim 35, wherein if the player wins the battle against the field character, the game is controlled to make it easier to satisfy the clear conditions.

Images