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

Abstract

To provide a game program, game device, game system, and game processing method that offer appropriate operation methods according to the camera position. [Solution] In the first mode, a reference point is moved based on the operation input, a point of focus is set based on the reference point, a first game image is generated in which the first cursor is displayed, and if a decision instruction is given when the first cursor overlaps with an object of the first type, the first process is executed. In the second mode, a virtual camera is placed closer to the virtual surface than in the first mode, a reference point is moved based on the operation input, a second game image is generated in which the second cursor is displayed, a point of focus is set so that the first area in which the object of the first type is placed does not overlap with the second cursor, and if a decision instruction is given when the second area corresponding to the object of the first type overlaps with the second cursor without overlapping with the first area, the first process is executed.

Description

[[Technical Field]]

[0001] The present disclosure relates to game processing for capturing an image of a virtual space with a virtual camera operable by a user. [[Background Art]]

[0002] Conventionally, there has been known a game that allows the position of a virtual camera in a virtual space to be moved closer to or farther away from a target of interest based on a user's operation (see, for example, Patent Document 1). [[Prior Art Documents]] [[Patent Documents]]

[0003] [[Patent Document 1]] Japanese Unexamined Patent Application Publication No. 2024-163200 [[Summary of the Invention]] [[Problem to be Solved by the Invention]]

[0004] With regard to the above-described games, there was room for improvement in the operation method according to the position of the virtual camera. [[Means for Solving the Problem]]

[0005] In view of the above points, for example, the following configuration examples are given.

[0006] (Configuration Example 1) Configuration Example 1 is a game program that causes a computer to execute the following steps. Switching between a first mode and a second mode based on an operation input. In the first mode, based on the operation input, a reference point is moved, a point of focus of a virtual camera in a virtual space including a virtual surface on which a first type of object is placed based on the reference point is set, a first game image is generated based on the virtual camera, in which a first cursor is displayed at a predetermined position in the image, and if the first cursor is overlapping a first type of object and a decision instruction is given based on the operation input, a first process relating to the first type of object is executed. Furthermore, in the second mode, the virtual camera is positioned closer to the virtual surface than the virtual camera's position in the first mode, the reference point is moved based on the operation input, a second game image is generated based on the virtual camera, in which a second cursor is displayed at a position on the virtual surface determined based on the reference point, if an object of the first type is located within a predetermined range from the virtual camera, at least a part of the object of the first type is hidden, in setting the gaze point based on the reference point, the gaze point is set so that the first region where the object of the first type is located does not overlap with the second cursor, and if the second region, which includes at least a region that does not overlap with the first region and corresponds to the position where the object of the first type is located, overlaps with the second cursor, and a decision instruction is given based on the operation input, the first processing relating to the object of the first type is executed.

[0007] According to the above configuration example, an appropriate operating method can be provided depending on the position of the virtual camera.

[0008] (Configuration example 2) Configuration Example 2 may involve placing an object of the first type at a position in the virtual space based on the operation input, as described in Configuration Example 1.

[0009] (Configuration Example 3) Configuration 3, in Configuration Example 1 or 2 described above, may further cause the computer to set a point of focus based on a reference point such that when the first cursor is overlapping an object of a first type and the system switches from the first mode to the second mode based on the operation input, the second cursor is displayed at a position overlapping the first area.

[0010] (Configuration example 4) Configuration Example 4 may restrict switching from the first mode to the second mode based on operation input if the first cursor is overlapping an object of the first type in Configuration Example 1 or 2.

[0011] (Configuration example 5) Configuration Example 5 is a configuration example in which, in Configuration Example 1 or 2, when the first cursor is overlapping an object of the first type and the system switches from the first mode to the second mode based on the operation input, the focus point may be set so that the second cursor is displayed in a position that does not overlap with the first area.

[0012] (Configuration example 6) Configuration Example 6 is an example in which, in any of Configuration Examples 1 to 5, the downward angle of the virtual camera in the first mode may be smaller than the downward angle of the virtual camera in the second mode.

[0013] (Configuration example 7) Configuration Example 7 is one of the above Configuration Examples 1 to 6, in which the height of the virtual camera in the virtual space is controlled in the second mode based on the height of the reference point in the virtual space.

[0014] (Configuration example 8) Configuration Example 8 is an example in Configuration Example 7 in which, when the height of the reference point changes from a first height to a second height, the height of the virtual camera is set from a height based on the first height to a height based on the second height, and when the height of the reference point changes from a second height to a first height, the height of the virtual camera is set to a height based on the second height.

[0015] (Configuration example 9) Configuration Example 9 is a configuration in any of Configuration Examples 1 to 8 above in which, in the first mode, if the first cursor is overlapping with a second type of object and a decision instruction is given, the second process relating to the second type of object may be executed, and if the first cursor is overlapping with a second type of object and the system switches from the first mode to the second mode based on an operation input, the first process relating to the second type of object may be executed. Alternatively, in the second mode, if the second cursor is overlapping with a third area corresponding to the position where the second type of object is placed, and a decision instruction is given, the first process relating to the second type of object may be executed.

[0016] (Configuration example 10) Configuration Example 10 is a configuration in which, in any of Configuration Examples 1 to 9 above, data relating to the first type of object is embedded in the pixels within a first range that includes pixels where the first type of object is displayed in the first game image, and when a decision instruction is given when the first cursor and the pixels in which the data relating to the first type of object is embedded overlap, the first processing relating to the first type of object is executed.

[0017] (Configuration Example 11) Configuration Example 11 is an example in which, in Configuration Example 10, the first range may be wider than the range in which objects of the first type are displayed.

[0018] (Configuration Example 12) Configuration Example 12 may display a first marker indicating a first type of object in pixels of a second range, which is at least a part of the first range in the first game image, as described in Configuration Example 11.

[0019] (Configuration Example 13) Configuration Example 13, in the above Configuration Example 12, may be configured such that, when a determination instruction is issued in a case where a first cursor overlaps a pixel that is included in a first region, does not display a first-type object, but displays another first-type object, a first process relating to said another first-type object may be executed.

[0020] (Configuration Example 14) Configuration Example 14, in the above Configuration Example 13, may be configured such that, when the first cursor does not overlap a pixel within a second range that displays another first-type object, a first indicator and said another first-type object are displayed overlapping on said pixel; and when the first cursor overlaps a pixel within a second range that displays another first-type object, the first indicator is hidden on said pixel, and said another first-type object may be displayed.

[0021] (Configuration Example 15) Configuration Example 15, in any one of the above Configuration Examples 1 to 14, may be configured such that, when a first-type object is located within a first distance in a direction based on a line-of-sight direction of a virtual camera, the transparency of said first-type object may be increased as time elapses.

[0022] In addition, each of the above configuration examples may be applied to a game processing method executed by a computer including at least one processor, and a game system including at least one processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] [Figure 1] A diagram showing an example of a state where a left controller and a right controller are attached to a main body device [Figure 2] A diagram showing an example of a state where the left controller and the right controller are each detached from the main body device [Figure 3] Six orthographic views showing an example of the main body device [Figure 4] Six orthographic views showing an example of the left controller [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] An example of a game screen according to this embodiment. [Figure 9] An example of a game screen according to this embodiment. [Figure 10] Diagram to explain camera modes [Figure 11] An example of a game screen according to this embodiment. [Figure 12] An example of a cursor collision area [Figure 13] Example of an access area [Figure 14] Diagram illustrating building access in the case of ground cameras. [Figure 15] Diagram illustrating building access in the case of ground cameras. [Figure 16] Diagram illustrating building access in the case of ground cameras. [Figure 17] Diagram to explain the types of buildings [Figure 18] A diagram showing an example of building access processing. [Figure 19] A diagram showing an example of building access processing. [Figure 20] A diagram illustrating building access to a C-shaped building from an overhead camera perspective. [Figure 21] A diagram illustrating building access to a C-shaped building from an overhead camera perspective. [Figure 22] Diagram to explain the processing of the pick function. [Figure 23] Diagram to explain the processing of the pick function. [Figure 24] Diagram to explain the processing of the pick function. [Figure 25] Diagram to explain the processing of the pick function. [Figure 26]Diagram to explain the processing of the pick function. [Figure 27] Diagram to explain the processing of the pick function. [Figure 28] A memory map showing an example of various data stored in DRAM85. [Figure 29] An example of the data structure of building data 303 [Figure 30] An example of the data structure of operation data 310 [Figure 31] Flowchart showing details of game processing according to this embodiment [Figure 32] A flowchart showing the details of normal processing. [Figure 33] A flowchart illustrating the details of user interaction processes. [Figure 34] A flowchart showing the details of the camera operation process. [Figure 35] Flowchart showing the details of the callout control process [Figure 36] A flowchart showing the details of the building access determination process. [Figure 37] A flowchart showing the details of the building access determination process. [Figure 38] A flowchart showing the details of the virtual camera control process. [Figure 39] A flowchart showing the details of the game image generation process. [Figure 40] A flowchart showing the details of the building access process. [Figure 41] A flowchart showing the details of the building access process. [Modes for carrying out the invention]

[0024] The following describes one embodiment. Figure 1 shows an example of the appearance of a game system, which is an example of an information processing system. The example of game system 1 in this embodiment includes a main unit (information processing device; in this embodiment, it functions as the main unit of the game device) 2, which is an example of a computer, and a left controller 3 and a right controller 4. The left controller 3 and the right controller 4 are detachable from the main unit 2. In other words, 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, game system 1 can be used with the main unit 2 and the left controller 3 and right controller 4 as separate units (see Figure 2). The following describes the hardware configuration of game system 1 in this embodiment, and then the control of game system 1 in this embodiment will be described.

[0025] Figure 1 above 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 sections for player input.

[0026] 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".

[0027] 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.

[0028] 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.

[0029] 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.

[0030] 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).

[0031] 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.

[0032] 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.

[0033] 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.

[0034] 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).

[0035] 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 (y-axis direction shown in Figure 4). When the left controller 3 is detached from the main device 2, it can also be held in a vertically elongated orientation. 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.

[0036] The left controller 3 is equipped with a left analog stick (hereinafter referred to as the left stick) 32, which is an example of a directional input device. As shown in Figure 4, the left stick 32 is provided on the main surface of the housing 31. The left stick 32 can be used as a directional input unit that can input direction. The player can input direction (and magnitude according to the angle of tilt) by tilting the left 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 an analog stick as the directional input unit. Furthermore, in this embodiment, input by pressing the left stick 32 is also possible.

[0037] 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. Furthermore, the left controller 3 is equipped with a record button 37 and a minus button 47. The left controller 3 is equipped with a first L button 38 and a ZL button 39 on the upper left side of the side of the housing 31. In addition, the left controller 3 is equipped with 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.

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

[0039] 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, it is long in the vertical direction (y-axis direction shown in Figure 5). The right controller 4 can also be held in a vertically elongated orientation when detached from the main unit 2. 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.

[0040] The right controller 4, like the left controller 3, is equipped with a right analog stick (hereinafter referred to as the right stick) 52 as a directional input unit. In this embodiment, the right stick 52 has the same configuration as the left stick 32 of the left controller 3. The right controller 4 may also be equipped with a 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 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.

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

[0042] 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.

[0043] 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).

[0044] 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. The processor 81 performs various information processing by appropriately reading and writing data to and from storage media such as the flash memory 84 and DRAM 85. In this embodiment, "memory" may include at least flash memory and DRAM, or it may include other storage media.

[0045] 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.

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

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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 players 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 player inputs to the main unit 2 using the first set of left controllers 3 and right controllers 4, the second player can input to the main unit 2 using the second set of left controllers 3 and right controllers 4.

[0051] The main unit 2 includes a touch panel controller 86, which is a circuit that controls the touch panel 13. The touch panel controller 86 is connected between the touch panel 13 and the processor 81. Based on signals from the touch panel 13, the touch panel controller 86 generates data indicating, for example, the position where a touch input occurred, and outputs it to the processor 81.

[0052] 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.

[0053] 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.

[0054] 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.

[0055] 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.

[0056] 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.

[0057] 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.

[0058] 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.

[0059] 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 a left stick 32. Each button 103 and the left stick 32 repeatedly output information about the operations performed on them to the communication control unit 101 at appropriate intervals.

[0060] 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.

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

[0062] 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 left 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).

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

[0064] More specifically, the vibrator 107 is a linear vibration motor. Unlike a conventional motor that performs rotational motion, a linear vibration motor is driven in a predetermined direction according to the input voltage, and can therefore vibrate with an amplitude and frequency corresponding to the waveform of the input voltage. In this embodiment, the vibration control signal transmitted from the main unit 2 to the left controller 3 may be a digital signal representing frequency and amplitude for each unit time. In another embodiment, the main unit 2 may transmit information indicating the waveform itself, but the amount of communication data can be reduced by transmitting only the amplitude and frequency. Furthermore, to further reduce the amount of data, instead of transmitting the numerical values ​​of the amplitude and frequency at that time, only the difference from the previous value may be transmitted. In this case, the codec unit 106 converts the digital signal indicating the amplitude and frequency values ​​obtained from the communication control unit 101 into an analog voltage waveform, and drives the vibrator 107 by inputting a voltage according to that waveform. Therefore, the main unit 2 can control the amplitude and frequency at which the vibrator 107 vibrates at that time by changing the amplitude and frequency transmitted for each unit time. Furthermore, the amplitude and frequency transmitted from the main unit 2 to the left controller 3 are not limited to one; two or more may be transmitted. In this case, the codec unit 106 can generate a voltage waveform for controlling the oscillator 107 by synthesizing the waveforms represented by each of the received amplitudes and frequencies.

[0065] 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).

[0066] 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.

[0067] The right controller 4 is equipped with the same inputs as the left controller 3. Specifically, it includes buttons 113, a right 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.

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

[0069] 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.

[0070] [Overview of game processing in this embodiment] Next, we will describe the operation overview of the game processing performed by the game system 1 according to this embodiment. In the following description, the left controller 3 and the right controller 4 may be collectively referred to simply as "controllers".

[0071] [About the game we envision] Next, the game envisioned in this embodiment will be described. In the game envisioned in this embodiment, the user can freely place various objects in a three-dimensional virtual space (hereinafter simply referred to as the virtual space) to create a virtual city (hereinafter referred to as the virtual city). In this example, a virtual "island" is provided in the virtual space, and the virtual city can be created on this island. Objects that can be placed include, for example, building-type objects (hereinafter simply referred to as buildings) and decorative objects (hereinafter referred to as decorations). Examples of buildings include, for example, houses, apartments, shops, etc. Examples of decorative objects include, for example, roads, street trees, plants, streetlights, traffic lights, etc. The user can place these objects in predetermined locations on the island by performing predetermined operations on a predetermined edit screen. In addition, regarding buildings, in addition to using pre-prepared buildings, it may also be possible for the user to create and edit their appearance. For example, a "building editor" function may be implemented. As will be described in detail later, building-type objects are further classified into several types.

[0072] Furthermore, in this game, users can create virtual residents and place them within the virtual city. Users can also create and edit the appearance of these virtual residents. Each placed virtual resident acts autonomously and lives a virtual life. In short, users can create virtual residents and have them live in the virtual city.

[0073] Here, each virtual resident is assigned a parameter called a "relationship parameter," and virtual relationships are built between virtual residents. These relationships can be, for example, strangers, acquaintances, friends, lovers, spouses, parent and child, etc. Based on these relationships, various events (conversations, skits, etc.) occur between the virtual residents.

[0074] As described above, this game allows users to create a virtual city, place virtual residents in it, and observe how each virtual resident lives their life.

[0075] [About camera modes] Next, we will explain the game's screen examples and virtual camera modes. Figures 8 and 9 show examples of the game's screen. First, let's explain the screen example in Figure 8. Figure 8 displays a game screen from an overhead perspective, as if looking down on the virtual city from above. The game screen also displays a finger-shaped cursor and several virtual residents. The finger-shaped cursor is also the object that the user can actually control. To explain this more precisely, in this game, an invisible point called a "reference point" is provided, and the user's direct object of control is this reference point. Specifically, the user changes the X and Z coordinates of the reference point in the virtual space by operating the left stick 32. Collision detection is not performed, and it may be possible to move, for example, along the ground surface of the virtual city. Alternatively, if the X and Z coordinates of the reference point overlap with the building objects of the virtual city, the Y coordinate may be determined so that the reference point is positioned higher than the building objects. Alternatively, it may be possible to move, for example, on the XZ plane of the virtual space at a predetermined height from the virtual city. In this example, we will explain the case where the reference point is moved along the surface of the virtual city. The position of the virtual camera's point of focus and the finger cursor (and the circular cursor described later) are each determined individually based on the position of the reference point. In this game, the position of the reference point, the point of focus, and the finger cursor are set to be in approximately the same position. That is, the reference point is located near the center of the game screen, the point of focus of the virtual camera is also in the center of the screen, and the finger cursor is also displayed in the center of the screen. Therefore, in this game, when you operate the left stick 32, the virtual camera is moved so that the finger cursor is always displayed in the center of the game screen, providing the feeling that you are moving the finger cursor (the user's viewpoint) above the virtual city.

[0076] Note that the positions of the reference point, the point of focus, and the finger-shaped cursor (and the circular cursor described later) do not necessarily always coincide, and the positions of the reference point, the point of focus, and the finger-shaped cursor may not always coincide. For example, if the reference point is moved rapidly, and the virtual camera is controlled to follow with a slight delay to avoid abrupt changes in viewpoint, the positions of the reference point and the point of focus may temporarily be misaligned (they will eventually be controlled to coincide). Also, for example, if the finger-shaped cursor is aligned with a specific virtual resident, the finger-shaped cursor may be fixed (locked on) to this virtual resident, and the virtual camera may be controlled to automatically follow. In this case, depending on the position of the virtual resident, the position of the finger-shaped cursor may be slightly off from the reference point.

[0077] Next, let's explain the example screen in Figure 9. In Figure 9, a game image is displayed that appears to be viewed from a perspective close to that of a virtual resident, near the ground surface of the virtual city. Therefore, compared to the game image in Figure 8 above, it is possible to move around the virtual city from the perspective of a virtual resident, providing a more immersive game image. Also, in Figure 9, a circular cursor is displayed instead of the finger-shaped cursor mentioned above. In the following explanation, the finger-shaped cursor and the circular cursor will be collectively referred to simply as "cursors." In this screen as well, there is an invisible reference point, and the position of the virtual camera, the point of focus, and the position of the circular cursor are determined based on this point. Therefore, visually, the user gets the feeling that they are operating the circular cursor. Specifically, the user changes the X and Z coordinates of the reference point in the virtual space by operating the left stick 32. Also, in this screen, a raycast is performed from the reference point to the ground, and the Y coordinate of the reference point is determined so that the reference point is positioned slightly higher than the ground.

[0078] (Point of focus control in Figure 9) In the game screen shown in Figure 9, the X and Z coordinates of the point of focus are set to the same coordinates as the reference point, and the Y coordinate is set to the most stable position based on the history of the reference point's Y coordinate. Specifically, if the reference point's Y coordinate has not changed for some time, or if the reference point moves from low ground to high ground, the point of focus's Y coordinate is set to the same Y coordinate as the reference point. If the reference point moves from high ground to low ground, the point of focus's Y coordinate is not updated. This allows for camera control without the point of focus shaking violently, even when moving the reference point in terrain where the reference point's height is likely to change. In this example, the circular cursor is assumed to be positioned perpendicular to the ground surface from the reference point. That is, it is positioned along the ground surface. Alternatively, the circular cursor may be positioned offset in the Y direction from the ground surface. In this case, the point of focus and the cursor position will not coincide (both are positioned based on the reference point).

[0079] Next, we will explain the position and orientation of the virtual cameras in the two screens described above. Figure 10 is a schematic diagram showing the virtual cameras in each of the two screens described above. For the sake of explanation, in the following explanation, the virtual camera (camera mode) in the overhead view shown in Figure 8 will be called the "overhead camera," and the virtual camera (camera mode) in the viewpoint shown in Figure 9 will be called the "ground camera."

[0080] In this game, as an example, the overhead camera is positioned at a distance of "120" from the reference point and has a depression angle of 30°. On the other hand, the ground camera is positioned closer to the ground surface of the virtual city than the overhead camera, at a distance of "6" from the reference point and has a depression angle of 8.5°. The position of the ground camera is determined by its relative position from the point of focus. In this game, the player can switch between the "overhead camera" and the "ground camera" by moving the right stick 52 up and down. That is, when using the overhead camera, inputting "up" on the right stick will switch the virtual camera to the ground camera. This switch can be instantaneous, or there can be a gradual transition animation from the overhead camera position to the ground camera position. Also, when using the ground camera, inputting "down" on the right stick will switch from the ground camera to the overhead camera. Again, this switch can be instantaneous, or there can be a gradual transition animation.

[0081] Additionally, users can move the virtual camera along an orbit centered on a reference point, without changing the point of focus, by using the left and right direction input of the right stick 52.

[0082] By the way, in this game, objects within the field of view of the virtual camera and within a predetermined range from the virtual camera are made transparent. Specifically, when a disk-shaped collision centered on the virtual camera comes into contact with the collision of an object, the object is made transparent. In this example, a process (hereinafter referred to as alpha-out) is performed to gradually increase the transparency over time until it is completely transparent. Increasing the transparency over time prevents buildings from suddenly disappearing or reappearing. This alpha-out process is implemented in consideration of the nature of this game, which involves observing virtual residents. As mentioned above, in this game, users can freely place buildings and other objects. Depending on how these buildings are placed, narrow roads and alleys may be created. On the other hand, the ground camera, in particular, is close to the ground surface and has a small depression angle. Therefore, there is a tendency for the virtual camera to come into contact with objects such as buildings. Here, as a control measure when the virtual camera comes into contact with objects such as buildings, it is conceivable to implement a control that pushes the virtual camera outwards. However, with this type of control, for example, if you try to follow a virtual resident who has entered a narrow street and move the virtual camera through that street, a building may block the way, preventing the virtual camera from entering the street and making it impossible to observe the virtual resident. In light of this, this game prioritizes the ability to observe the virtual resident and implements a control mechanism that makes various objects such as buildings and decorations that appear in front of the virtual camera transparent, without adjusting the position of the virtual camera. As a variation, in addition to providing collision detection for the camera, a raycast could be performed at a certain distance in the XZ direction from the camera, and intersecting objects could be made transparent.

[0083] The objects to be made transparent are various objects that are in close proximity within the field of view of the virtual camera, and are not limited to buildings and decorations; virtual residents themselves are also subject to transparency. Here, the distance at which transparency begins may differ between virtual residents and other objects. For example, the distance at which transparency begins may be shorter for virtual residents than for buildings, etc. This is because delaying the timing of transparency for virtual residents as much as possible is consistent with the nature of the game, which is to observe virtual residents.

[0084] Next, we will explain "access" to buildings. The above buildings can be "accessed" through a predetermined operation (hereinafter referred to as "building access"). By accessing a building, a predetermined process corresponding to that building (hereinafter referred to as "building access processing") is executed. Building access processing will be described separately later, but for example, it may involve processes such as entering the building (moving to a different area corresponding to the building in the virtual space) or displaying a shop screen. Furthermore, in this game, the method for accessing buildings differs depending on whether you are using an overhead camera or a ground camera.

[0085] [How to access the building when using an overhead camera] First, let's explain how to access a building using an overhead camera. In this case, as shown in Figure 11, you can access a building by placing the finger cursor over the desired building and pressing button A 53.

[0086] In this game, when the finger cursor hovers over a building, a "speech bubble" indicating the building's name will also be displayed, as shown in Figure 11. The display of this speech bubble will be explained later.

[0087] [Regarding building access methods when using ground cameras] Next, we will explain building access in the case of a ground camera. In this case, control is implemented to prevent the circular cursor from moving inside the building. Specifically, in this example, a region called the "cursor collision area," as shown in Figure 12, is set for each building. Then, in the case of a ground camera, control is implemented so that the circular cursor cannot enter the cursor collision area. Furthermore, the reference point is such that the circular cursor, centered on the XZ coordinates of the reference point, cannot move toward the cursor collision area when it comes into contact with it, so in reality, it is not possible to move toward the cursor collision area from a position slightly away from the cursor collision area. The cursor collision area is set for buildings that have a certain area. This prevents the generation of a game screen where hidden buildings are displayed large by setting the point of focus at the center of a building with a large area. The shape of the area can be any shape, but for example, the area on the ground surface that forms the building's site can be used as the cursor collision area. Alternatively, for example, if the building is octahedron, spherical, or egg-shaped, the building's collision can be moved closer to the ground surface, and the area overlapping with the ground surface can be set as the cursor collision area. As an alternative, cursor collision may be applied to certain types of buildings regardless of their size.

[0088] In the case of a ground camera, when accessing a building, the "access area" set for each building is used. Figure 13 shows an example of an access area. In Figure 13, a predetermined area of ​​the two-dimensional plane in front of the building entrance is set as the access area. Although shown in Figure 13, this access area is also an invisible area in the game image. In this embodiment, this access area is set so as not to overlap with the cursor collision area.

[0089] In other examples, a portion of the access area may overlap with the cursor collision area. Also, while the access area is illustrated as a two-dimensional plane in this example, in other embodiments, it may be set as a space with height (access space).

[0090] Then, by pressing button A 53 while the circular cursor is within the access area, you can access the building corresponding to that access area. In the case of the ground camera, when the circular cursor is within the access area, a speech bubble similar to the one shown for the overhead camera will be displayed as appropriate.

[0091] This section explains building access using a ground camera with a specific example. Figure 14 shows a screen example where the circular cursor is located a certain distance from the building. In Figure 14, the building is directly in front. Suppose the cursor moves forward from the state in Figure 14 to the state shown in Figure 15. That is, the circular cursor is now located just before the entrance of the building (within the access area). In this state, the cursor cannot be moved any further forward due to the cursor collision area. However, the circular cursor is also within the access area. Therefore, by pressing button A 53 in this state, it is possible to access the building.

[0092] Furthermore, as shown in Figure 16, for example, if the circular cursor is located adjacent to a building but outside the access area, pressing button A 53 will not allow access to the building. Also, in this state, attempting to move forward will not allow the circular cursor to move forward due to cursor collision.

[0093] Here, if the finger cursor is overlapping a building (in an accessible state) while using the overhead camera and the operation to switch to the ground camera is performed, exceptionally, a game image may be displayed with the circular cursor positioned inside the building (within the cursor collision area). This is because, if the circular cursor's position were to be moved outside the cursor collision area in such a case, it might give the user the feeling that the cursor moved on its own, creating a sense of incongruity with the user's actions. Therefore, in such cases, the game switches to the ground camera without changing the cursor's position. Also, this camera mode switching operation is not treated as building access. Furthermore, pressing the A button 53 at this time will not allow building access. Therefore, for example, as a result of switching to the ground camera, a game image may be displayed where a virtual camera is positioned inside the building, and the walls and roof are made transparent by alpha-out control, allowing the outside scenery to be seen. Also, when moving the circular cursor outside the building in this state, the cursor collision area is not activated, and the circular cursor can be moved outside. However, once it is moved outside, the cursor collision area prevents the circular cursor from moving back into the building (i.e., it prevents reverse flow).

[0094] Furthermore, if the virtual camera is rotated using left and right input on the right stick (position 52), it is possible that only the virtual camera will be positioned inside the building. In this case, since the game screen will not display with the building largely gone, the alpha-out control allows the building to become transparent.

[0095] [Regarding the processing of building access] Next, we will explain an example of the process that is executed when accessing the buildings described above. In this game, the buildings are classified into several "types," and the content of the building access process differs for each type. As an example, we will explain using an example in which the buildings shown in Figure 8 above are classified into three types. Specifically, we will explain using an example in which the buildings shown in Figure 8 above are classified into three types as shown in Figure 17: "Building Type A," "Building Type B," and "Building Type C."

[0096] "Building Type A" refers to buildings that serve as residences for virtual residents, such as apartments or detached houses. The building access process for buildings belonging to "Building Type A" (hereinafter referred to as "Type A buildings") involves moving the reference point, cursor, and virtual camera to a different area corresponding to the interior of the building (hereinafter referred to as "building interior area"). This building interior area corresponds to a "room" within the building, as shown in Figure 18. In other words, when you access a Type A building, a process is performed that takes place to enter (transition to) the interior of the building. By moving to a different area in this way, it is possible to create rooms that are actually larger in size within the virtual city. The camera mode of the virtual camera inside the building is fixed and controlled as either the "ground camera" mentioned above, or a building-specific mode with settings such as a depression angle set specifically for use inside buildings. In the area corresponding to the interior of the building, the reference point (and consequently the point of focus and cursor) can be moved within the building using the same operations as above. Then, by performing a predetermined operation for exiting (for example, aligning the cursor with the exit and pressing button A 53), the user can exit the building interior area.

[0097] "Building Type B" refers to a building where items can be bought and sold, such as a shop. The building access process for buildings belonging to "Building Type B" (hereinafter referred to as "Type B buildings") involves switching to a "shop screen" as shown in Figure 19, and allowing the user to buy and sell items. The shop screen closes when the user exits.

[0098] "Building Type C" refers to buildings such as restaurants and various leisure facilities. Unlike "Building Type A" and "Building Type B," buildings belonging to "Building Type C" (hereinafter referred to as "Type C buildings") have detailed interiors. In this game, when you access "Building Type A" or "Building Type B," you move to a different area or switch to the shop screen, so the interiors of these types of buildings are essentially empty spaces. In contrast, for Type C buildings, for example, a restaurant, objects such as chairs and tables are created and placed within the building's grounds. Furthermore, the method of accessing Type C buildings from an overhead camera is slightly different from other types. The following explains how to access Type C buildings using diagrams.

[0099] First, let's explain the process of accessing a C-shaped building using the overhead camera. When the finger cursor is positioned over the C-shaped building in overhead camera mode, the situation will be as shown in Figure 20, for example. In this state, if the user presses button A 53, only the "roof" of the C-shaped building will be hidden, as shown in Figure 21. In this state, the interior of the C-shaped building can be seen, and in the example in Figure 21, tables and other items can be seen.

[0100] Then, in the state shown in Figure 21, if the user further moves the right stick 52 upwards (to switch to the ground camera), the virtual camera seamlessly moves to enter the building's entrance. The camera then switches to the ground camera, with the virtual camera positioned at the entrance of the building. In other words, in the case of the overhead camera, for a Type C building, access to the building is achieved by either moving the right stick 52 upwards, or by pressing the A button to hide the roof and then pressing the A button again. After entering the building, movement within the building is possible, similar to the case of "Building Type A" described above. If the user exits the building, the camera returns to the overhead view.

[0101] On the other hand, in the case of a ground camera, the two-stage processing described above is not performed, and building access to the Type C building can be performed via the "access area" as with other types of buildings. When moving into the building in this case, the cursor collision area may be temporarily disabled, allowing the cursor and virtual camera to move seamlessly into the building (near the entrance). Alternatively, the cursor collision area may not be disabled, and the cursor may be moved into the building by temporarily switching screens.

[0102] Additionally, when a virtual camera is located inside a Type C building, the alpha-out control described above may be temporarily disabled. Alternatively, the distance at which transparency begins may be changed to a shorter distance only when inside a Type C building.

[0103] Furthermore, regarding the various types of buildings mentioned above, from the perspective of whether or not there is a screen transition, Type A and Type B buildings can be considered as "screen transition type buildings" that involve transitions to different screens, while Type C buildings can be considered as "seamless type buildings" that allow seamless movement within the building's interior.

[0104] [Regarding GPU Pick processing] Next, we will explain the processing related to the pick function using the frame buffer (hereinafter simply referred to as the pick function). First, we will explain the overview and principle of the pick function. For example, let's consider a building with the shape shown in Figure 22. The building shown in Figure 22 is a building belonging to "Building Type B" and is a building modeled after a "fountain" (here referred to as the fountain object). The shape of the fountain object consists of a fountain part and an arch part, and there is a hollow part (space) between the arch part and the fountain part. When considering the pixels of the game screen in an overhead camera view, the area where the fountain object is drawn is, for example, as shown in Figure 23. In Figure 23, the black area indicates the pixels where the image corresponding to the above fountain object is drawn. In other words, the black area can be said to be the selectable range for selecting the fountain object.

[0105] Here, let's consider a scenario where the position of the tip of the index finger of the finger cursor is used to determine whether a building is selected, and the tip of the finger cursor is located in the hollow part. In this case, if the overlap between the finger cursor and the fountain object is strictly determined, the finger cursor may be treated as not having selected the fountain object. In this case, even if the user positions the finger cursor with the intention of selecting the fountain object, pressing button A 53 may not allow access to the building, potentially causing the user to perceive a decrease in usability.

[0106] Therefore, in this game, control is implemented to allow access to buildings even when the finger cursor is not strictly overlapping with a building. This improves the feel of the controls. Specifically, in this example, information (hereinafter referred to as "pick information") is used that defines information indicating the building corresponding to each pixel of the game image. This information may be embedded as additional information for each pixel in the frame buffer, for example. Then, for the pixel at the position indicated by the finger cursor, this information is referenced to determine whether or not there is a building associated with that pixel, and if there is a building associated with it, control is implemented to allow access to that building.

[0107] The pick information described above basically sets information indicating the building to be drawn on a given pixel. However, for buildings like the fountain object shown above, information about the fountain object is associated even with pixels where the fountain object is not strictly drawn. In the above case, as shown in Figure 24, pick information associated with the fountain object is set even for pixels where the hollow part is drawn. In Figure 24, the black area indicates the selectable range. In other words, a wider range than the range of pixels that are originally drawn (see Figure 23) is set as the selectable range. By expanding the selectable range, it becomes easier to select the desired building. Below, the part of the selectable range where the corresponding building is not drawn may be referred to as the "extended range".

[0108] Furthermore, by referring to this pick information when determining the building selected by the finger cursor, it becomes possible to reflect the user's intent in the selection. In the example above, when the finger cursor is pointing to the hollow part (i.e., the extended part), the pick information shows that the pixel pointed to by the finger cursor is associated with the fountain object. Therefore, if button A 53 is pressed at this position, the system will execute a process to access the building through the fountain object.

[0109] Here, by setting the selectable area to be wider than the range of pixels that are actually drawn, it is possible that the extended area and the display of other buildings may overlap. For example, consider a case where building B is located behind building A, and in the pick information, the selectable area for building A is set to be wider than the actual drawing range. In this case, as shown by the black circle in Figure 25, there may be overlaps between the position included in the selectable area of ​​building A (the extended area), which is not drawn, and the pixels where building B is drawn. In such a case, if the finger cursor is moved to the position of the black circle and button A 53 is pressed, building B will be selected first, and the process related to accessing building B will be executed. As a result, the building that is actually displayed takes priority, which reduces the feeling of inconsistency between the appearance and the executed building access, and makes it less likely to cause confusion.

[0110] Next, the display of the speech bubble described above will be explained. In this game, when using the overhead camera, if a specific building is defined in the pick information for the pixel where the finger cursor is displayed, a speech bubble indicating the name of that building will be displayed. In other words, when the finger cursor is within the selectable area, a speech bubble indicating the building corresponding to that area will be displayed. This speech bubble will be displayed, for example, for at least a portion of the selectable area indicated in the pick information. As a result, the speech bubble may be displayed so that a portion of it overlaps with the building. In particular, the display of the speech bubble when the cursor is in the extended area makes it easier for the user to see and select the extended area.

[0111] Here, for example, a callout corresponding to building A may be displayed in the extended area, including the position of the black circle explained in Figure 25, as shown in Figure 26. In other words, the callout for building A is displayed overlapping building B. In such cases, where there is another building behind the callout that the callout indicates, if the finger cursor is moved to a position where the two overlap, the callout for building A may be hidden, for example, as shown in Figure 27. Alternatively, the callout for building A may be made semi-transparent. In short, if a positional relationship occurs where one building, the callout of another building, and the finger cursor overlap, the callout may be hidden. By hiding the callouts in this way, the user can determine from the game image which building they are trying to select.

[0112] On the other hand, in the case of ground cameras, as described above, while the circular cursor is within the access area, a pop-up about the building corresponding to that access area is displayed.

[0113] [Details of game processing] Next, the game processing in this embodiment will be described in more detail with reference to Figures 28 to 41. Here, we will mainly describe the processing related to building access, and details of other game processing will be omitted.

[0114] [About the data used] First, we will explain the various data used in this game processing. Figure 28 is a memory map showing an example of the various data stored in the DRAM 85 of the main unit 2. The DRAM 85 of the main unit 2 stores the game program 301, virtual city data 302, reference point data 305, virtual camera data 306, cursor position data 309, operation data 310, building access flag 311, accessed building information 312, currently designated information 313, frame buffer 314, etc.

[0115] Game program 301 is a program for executing the game processing described above.

[0116] The virtual city data 302 is data that defines the structure of the virtual city described above. This virtual city data can be generated, for example, based on operations performed by the user on the edit screen for creating the virtual city, such as placing buildings and virtual residents. The virtual city data 302 includes at least building data 303 and virtual resident data 304. It also includes data for the decorations placed in the virtual city.

[0117] Building data 303 is data relating to various buildings placed in the virtual city. Figure 29 is a diagram showing an example of the data structure of building data. The virtual city data 302 contains multiple individual building data 331. Each individual building data 331 includes building ID 332, building type data 333, placement location data 334, appearance data 335, cursor collision definition data 336, access area definition data 337, access processing content definition data 338, extended part information 339, hidden flag 340, etc.

[0118] Building ID 332 is an ID used to uniquely identify individual buildings located in the virtual city.

[0119] Building type data 333 indicates the type of building, which in this example is one of the building types A to C above.

[0120] The placement data 334 is data indicating the location where the building is placed within the virtual city.

[0121] Exterior data 335 defines the building's appearance, including its shape and look, and includes, for example, 3D model data and texture data. For the Type C building mentioned above, it also includes data for various objects placed inside the building.

[0122] The cursor collision definition data 336 is data that defines the shape and size of the cursor collision for that building.

[0123] Access area definition data 337 is data that defines the location, shape, and size of the access area corresponding to the building.

[0124] Access processing content definition data 338 is data that defines the processing content to be executed when the building is accessed, depending on whether the building is a Type A building or a Type B building. For example, if it is a Type A building, it includes information about the interior area of ​​the building corresponding to that building. If it is a Type B building, it includes information about the shop screen and the items that can be bought and sold.

[0125] The extension portion information 339 is data related to the pick information described above, and is information for specifying whether or not there is an extension portion within the selectable range, and if so, the range of that extension portion. For example, in the case of a building with a hollow portion as shown in Figure 22, information is set indicating that there is an extension portion and that the hollow portion will be the extension portion.

[0126] The hidden flag 340 is data used when the building is a Type C building, and it is a flag that indicates whether the building's roof is hidden, as shown in Figure 21 above. The initial value is off, and it is set to on when the roof is hidden.

[0127] Returning to Figure 28, the virtual resident data 304 is data relating to virtual residents placed in the virtual city. For each virtual resident, the virtual resident data 304 includes at least a resident ID to identify that virtual resident, appearance data of that virtual resident, data indicating their current location in the virtual city, and various parameters for controlling that virtual resident's behavior.

[0128] Reference point data 305 is data indicating the position of the above reference point within the virtual space.

[0129] The virtual camera data 306 is data relating to the virtual camera described above, and includes the current camera mode 307 and camera parameters 308. The current camera mode 307 is data indicating whether the current camera mode is an overhead camera or a ground camera. The initial value is set to data indicating an overhead camera. The camera parameters 308 are various parameters for controlling the virtual camera. For example, they include various parameters indicating the virtual camera's point of focus, position, imaging direction, downward angle, field of view, etc.

[0130] The cursor position data 309 is data indicating the position of the cursor, and is determined based on the reference point.

[0131] Operation data 310 is data that indicates the various operations performed on the controller. Figure 30 is a diagram showing an example of the data structure of operation data 310. Operation data 310 includes at least button operation data 351, right stick data 352, and left stick data 353. Button operation data 351 is data that indicates the operations performed on the various operation buttons mentioned above. Right stick data 352 is data that indicates the operations performed on the right stick 52. Left stick data 353 is data that indicates the operations performed on the left stick 32.

[0132] Returning to Figure 28, the building access flag 311 is a flag that indicates whether or not building access processing is being performed for any of the buildings. The initial value is off, and when it is on, it indicates that building access processing is being performed for any of the buildings.

[0133] The access building information 312 is data that is set when accessing a designated building, and it contains information to identify the building currently being accessed.

[0134] The currently designated information 313 is information set based on the pick information 316 described later, and it is information to determine whether or not there is a building corresponding to the pixel where the cursor is currently located, and if so, to identify that building.

[0135] The frame buffer 314 is a buffer area for storing the display content for one screen to be output, and color information 315 and pick information 316 are stored associated with each pixel. For example, in a two-dimensional table-type address space where the horizontal axis is the X coordinate and the vertical axis is the Y coordinate, the color information 315 stored in the memory address corresponding to each pixel is information indicating the drawing color of each pixel. The pick information stored in each memory address is information indicating the selectable range of buildings to be drawn as game images. Specifically, a building ID 332 of the building to be drawn is set for each pixel. In addition, for some buildings, a building ID 332 may be set as an extension of the above for pixels where the building is not drawn.

[0136] Please note that the above data are merely examples. Other data may be included, and some data may be omitted. Furthermore, the data does not need to be permanently available; it may be added, deleted, or modified.

[0137] Figure 31 is an example of a flowchart showing the process according to this embodiment. Note that the process may include other processes, or some processes may be omitted. Also, the order of the processes is just an example; for example, the processes may be executed simultaneously or in reverse order. Furthermore, although the processes are shown separately for convenience, they may be a single integrated process. In addition, the following processes may be executed at predetermined intervals (for example, every processing frame, every 1 / 30 second).

[0138] In Figure 31, the processor 81 first performs a preparation process (S1). In this process, a virtual city is generated based on the virtual city data 302 and placed in the virtual space. Various data is also initialized, and the reference points are placed in their initial positions. Subsequently, a game image is generated and output. The pick information mentioned above is also generated during the generation of the game image, but the process for generating this information will be described later.

[0139] Next, the processor 81 determines whether the building access flag 311 is on or off (S2). If the result of this determination is off (NO in S2), the processor 81 performs normal processing (S3). On the other hand, if it is on (YES in S2), the processor 81 performs building access processing (S4).

[0140] Figure 32 is a flowchart detailing the normal processing described above. In Figure 32, first, the processor 81 controls the actions of each virtual resident (S11). As a result, each virtual resident moves around the virtual city and performs predetermined actions.

[0141] Next, the processor 81 executes user operation processing (S12). Figure 33 is a flowchart detailing the user operation processing. In Figure 33, first, the processor 81 acquires operation data (S21). Next, the processor 81 sets the reference point data 305 based on the left stick data 353 and moves the position of the reference point (S22). In this case, in the case of a ground camera, the reference point is controlled so that the circular cursor does not enter the cursor collision area. However, as mentioned above, if the operation to switch to the ground camera is performed when the finger-shaped cursor is overlapping a building in the overhead camera, the reference point may exceptionally move into the cursor collision area.

[0142] Next, the processor 81 determines the position of the point of focus based on the current camera mode 307 and the current reference point position, and sets the parameters related to the point of focus in the camera parameters 308. Furthermore, the processor 81 determines the cursor position based on the current camera mode 307 and the current reference point position, and sets the cursor position data 309 (S23). In this case, for a ground camera, the point of focus and cursor position are determined so that the circular cursor does not fall within the cursor collision area, as described above. However, as described above, if the operation to switch to a ground camera is performed when the finger-shaped cursor is overlapping a building in an overhead camera, the positions are exceptionally determined so that the circular cursor is placed within the cursor collision area. Also, for a ground camera, as described above, the Y coordinate of the point of focus is determined to be the most stable position.

[0143] Next, the processor 81 sets the current designated information 313 based on the current cursor position and the pick information (S24). That is, if a building ID 332 of a predetermined building is set for the pixel corresponding to the current cursor position, the processor 81 sets the building ID 332 as the current designated information 313. If no building is set for the pixel corresponding to the current cursor position, the processor 81 sets a value indicating this, such as a Null value, as the current designated information 313. Note that this processing in S24 may be performed only in the case of an overhead camera and not in the case of a ground camera.

[0144] Next, the processor 81 executes camera operation processing (S25). Figure 34 is a flowchart detailing the camera operation processing. First, the processor 81 determines, based on the right stick data 352, whether an upward or downward input operation has been performed on the right stick 52 (S31). If, as a result of this determination, no input in either direction has been performed (NO in S31), the process proceeds to S34, which will be described later.

[0145] On the other hand, if any input operation has been performed (YES in S31), the processor 81 determines whether the input operation was an upward input, the camera mode is an overhead camera, and the finger cursor is over the C-shaped building (S32). If the result of this determination is that these conditions are not met (NO in S32), the processor 81 switches the camera mode (overhead camera and ground camera) based on the current camera mode and whether the input was upward or downward (S33). In addition, various camera parameters (such as the downward angle and position) corresponding to each camera mode are set along with this switch.

[0146] Next, the processor 81 determines whether or not a left or right directional input has been performed on the right stick 52 based on the right stick data 352 (S34). If a left or right directional input has been performed (YES in S34), the position and orientation of the virtual camera are set so that the virtual camera moves along an orbit around the reference point without changing the point of focus (S35). On the other hand, if there is no left or right directional input (NO in S34), it is assumed that the right stick 52 has not been operated, so the processor 81 sets the position and orientation of the virtual camera based on the current camera mode and point of focus (S36). After that, the camera operation process ends.

[0147] On the other hand, if the above condition is met as a result of the determination in S32 (YES in S32), the processor 81 switches the camera mode to the ground camera. Furthermore, the processor 81 sets various parameters of the virtual camera so that the virtual camera's position is seamlessly moved to the position where it enters the entrance of the C-shaped building (with the roof hidden) on which the finger cursor is overlapping (S37).

[0148] Next, the processor 81 sets the building access flag to ON and sets the building ID 332 of the above-mentioned C-type building to the access building information 312 (S38). After that, the camera operation process ends.

[0149] Returning to Figure 33, the processor 81 then executes the callout control process (S26). Figure 35 is a flowchart detailing the callout control process. First, the processor 81 determines whether the camera mode is an overhead camera (S51). If it is an overhead camera (YES in S51), the processor 81 then determines whether any building ID 332 is specified in the currently specified information (S52). If it is set (YES in S52), the processor 81 determines whether a callout indicating another building is displayed at the current cursor position (S53). This means that a part of the callout for the other building is displayed outside the selectable range of the other building, and that part overlaps with the building indicated in the currently specified information. If, as a result of this determination, a callout indicating another building is displayed (YES in S53), the callout indicating the other building is deleted (S54). On the other hand, if no callout indicating another building is displayed (NO in S53), the process in S54 is skipped.

[0150] Next, the processor 81 generates a callout indicating the building shown in the currently specified information and places it in a predetermined position (S55).

[0151] On the other hand, if, as a result of the determination in S52, none of the building IDs 332 are currently specified in the designated information (NO in S52), the processor 81 determines whether or not a callout is placed for any of the buildings (S57). If a callout is placed (YES in S57), the processor 81 deletes that callout (S58). If no callout is placed (NO in S57), the process in S58 is skipped. This completes the callout control process.

[0152] On the other hand, if the camera mode is determined to be a ground camera as a result of the determination in S51 (NO in S51), the processor 81 determines whether the circular cursor is within any of the access areas (S56). If it is (YES in S56), the processor 81 places a callout indicating the building corresponding to that access area in a predetermined position (S59). On the other hand, if it is not (NO in S56), the process proceeds to S57.

[0153] Returning to Figure 33, the processor 81 then executes the building access determination process (S27). Figures 36 and 37 are flowcharts detailing the building access determination process. First, the processor 81 determines whether button A 53 has been pressed based on the button operation data 351 (S71). If button A 53 has been pressed (YES in S71), the processor 81 then determines whether the current camera mode is an overhead camera (S72). If it is an overhead camera (YES in S72), the processor 81 determines whether the building ID 332 of the above-mentioned Type A building or Type B building is specified in the currently specified information (S73). If it is specified (YES in S73), the processor 81 sets the building access flag 311 to ON and sets the building ID 332 specified in the currently specified information in the access building information 312 (S79). After that, the building access determination process ends.

[0154] On the other hand, if, as a result of the determination in S73, the building ID 332 of the A-type building or the B-type building is not specified in the currently designated information (NO in S73), the processor 81 determines whether the building ID 332 of the C-type building is specified in the currently designated information (S74). If it is specified (YES in S74), the processor 81 then determines whether the hide flag 340 for the C-type building is on. If it is not on (NO in S75), the processor 81 sets the roof of the designated C-type building to be hidden (S76). Furthermore, the processor 81 sets the hide flag 340 for the designated C-type building to on (S77). After that, the building access determination process ends.

[0155] On the other hand, if the result of the determination in S75 is that the hidden flag 340 is on (YES in S75), the process proceeds to S79.

[0156] On the other hand, if the result of the determination in S72 is that the current camera mode is a ground camera (NO in S72), the processor 81 determines whether the circular cursor is within the access area of ​​any building (S78). Alternatively, the determination may be made based on whether the reference point is within the access area instead of the circular cursor. If the circular cursor is within the access area of ​​any building (YES in S78), the process proceeds to S79. If the circular cursor is not within any access area (NO in S78), the process in S79 is skipped, and the building access determination process ends.

[0157] On the other hand, if the result of the determination in S71 is that button A 53 was not pressed (NO in S71), the processor 81 determines whether the state in which the finger cursor overlaps has changed from one where it is overlapping to one where it is not overlapping for a C-type building with the camera mode set to overhead camera and the preparation flag set to ON, that is, a C-type building with a hidden roof (S80). If the result of this determination is that the state in which the finger cursor does not overlap has changed (YES in S80), the processor 81 executes the process to display the roof (S81). Furthermore, the processor 81 sets the hidden flag 340 for the C-type building whose roof was hidden to OFF (S82). After that, the building access determination process ends.

[0158] On the other hand, for a C-type building whose roof is not visible, if the state in which the finger cursor is overlapping has not changed from the state in which the finger cursor is overlapping to the state in which it is not overlapping (NO in S80), then the processes in S81 to S82 above are skipped and the building access determination process ends.

[0159] Returning to Figure 33, once the building access determination process is complete, the user operation process ends.

[0160] Returning to Figure 32, the processor 81 then executes virtual camera control processing (S13). Figure 38 is a flowchart detailing the virtual camera control processing. First, the processor 81 controls the position and orientation of the virtual camera based on the camera parameters 308 (S101). When controlling the virtual camera to move seamlessly to the C-shaped building whose roof is hidden, the processor continues to control the seamless movement until the movement is complete.

[0161] Next, the processor 81 performs alpha-out control as described above (S102). In this example, as described above, when a disk-shaped collision centered on the virtual camera comes into contact with the collisions of various objects, the alpha-out is set to gradually make the object transparent over the time period described above.

[0162] Next, the processor 81 determines whether the current camera mode is an overhead camera (S103). If it is an overhead camera (YES in S103), the processor 81 places a finger-shaped cursor at the position indicated by the cursor position data 309 (S104). On the other hand, if it is a ground camera (NO in S103), the processor 81 places a circular cursor at the position indicated by the cursor position data 309 (S105). This completes the virtual camera control process.

[0163] Returning to Figure 32, the processor 81 then executes the game image generation process (S14). Figure 39 is a flowchart detailing the game image generation process. First, the processor 81 determines whether or not the situation is such that the shop screen should be displayed. That is, it determines whether the building access flag 311 is on and whether or not the building set in the access building information 312 is a Type B building (S111). If the result of this determination is such that the situation is such that the shop screen should be displayed (YES in S111), the processor 81 generates the shop screen as a game image (S115).

[0164] On the other hand, if the situation does not require displaying the shop screen (NO in S111), the processor 81 generates an image captured by the virtual camera of the virtual space (S112). This image is stored in the frame buffer 314.

[0165] Next, the processor 81 sets the pick information as described above based on the relationship between each pixel in the frame buffer and the building to be drawn on each pixel (S113). In this case, depending on the building, a building ID 332 is set even for pixels where the building is not drawn, based on the extended portion information 339. Furthermore, if a certain pixel is, for example, a pixel on which building A is drawn, and is also a pixel included in the extended portion of building B, the processor processes the pixel to set the building ID 332 of building A.

[0166] Next, the processor 81 combines various images with the captured image as needed to generate the final output game image (S114). This completes the game image generation process.

[0167] Returning to Figure 32, once the game image generation process is complete, the normal process ends.

[0168] Next, the details of the building access processing related to the processing in S4 of Figure 31 will be explained. Figures 40-41 are flowcharts detailing the building access processing. First, the processor 81 determines whether or not the access is to the Type C building based on the access building information 312 (S121). If the result of this determination is not to the Type C building (NO in S121), the processor 81 then determines whether or not the access is to the Type B building (S122). If the result of this determination is to the Type B building (YES in S122), the processor 81 executes a predetermined process related to the shop screen based on the user's operation (S123). Furthermore, based on the result of this process, the display content of the shop screen is set appropriately (S124). After that, the process proceeds to S129, which will be described later.

[0169] On the other hand, if the result of the determination in S122 is not building access to a Type B building (NO in S122), then it is considered to be building access to a Type A building. In this case, the processor 81 first determines whether it has already moved to the building interior area corresponding to the Type A building from which the building access was performed (S125). If it has not already moved (NO in S125), the processor 81 moves the reference point and virtual camera to the building interior area (S126). At this time, the camera mode is set to ground camera. If it has already been moved (YES in S125), the process in S126 is skipped.

[0170] Next, the processor 81 moves the reference point within the building's interior area based on the user's input. Furthermore, camera parameters 308, such as the virtual camera's gaze point and camera position, are determined based on the reference point. The cursor position is also determined based on the reference point (S127).

[0171] Next, the processor 81 appropriately performs various processes related to the interior area of ​​the building (S128). For example, it controls the movements of virtual residents in the interior area of ​​the building.

[0172] On the other hand, if the result of the determination in S121 is that building access is to a Type C building (YES in S121: the virtual camera moves seamlessly into the Type C building), then no movement to another area occurs, and the process can proceed to S127.

[0173] Next, the processor 81 determines whether an exit operation has been performed (S129). In the case of a Type A building, an exit operation is, for example, moving the cursor to the exit and performing a predetermined button operation. In the case of a Type B building, it is, for example, operating the "exit button" displayed on the shop screen. In the case of a Type C building, it is, for example, performing an operation to move from the exit towards the outside of the building. If, as a result of the above determination, an exit operation has been performed (YES in S129), the processor 81 sets the building access flag 311 to off (S130). Next, the processor 81 moves the reference point to a predetermined position near the entrance of the building that was being accessed in the virtual city. The virtual camera is also moved accordingly (S131). The camera mode when exiting the building may also be set to the camera mode before accessing the building. For example, if a Type A building is accessed in the overhead camera state, the camera may be controlled by the ground camera inside the building, and when exiting, control may be performed to return to the overhead camera.

[0174] Regarding the above-mentioned Type C building, the timing for redisplaying the hidden roof may be at the time the above-mentioned exit operation is performed.

[0175] On the other hand, if no exit operation is performed (NO in S129), the processes in S130 to S131 above are skipped.

[0176] Next, processor 81 executes the game image generation process described above (S132). This process is the same as the process in S14 explained using Figure 39 above, so the explanation is omitted. This concludes the building access process.

[0177] Returning to Figure 31, after normal processing or building access processing, the processor 81 outputs the game image generated by the above processing (S5).

[0178] Next, processor 81 determines whether the conditions for terminating the game have been met (S6). If the conditions are not met (NO in S6), it returns to the process in S2 and repeats the process. If the conditions are met (YES in S6), processor 81 terminates the game process.

[0179] This concludes the detailed explanation of the game processing according to this embodiment.

[0180] Through the processing described above, the system provides different methods for accessing buildings depending on whether an overhead camera or a ground-level camera is used. This allows for the provision of appropriate operation methods based on the virtual camera's position.

[0181] [Differentiation] In the above embodiment, regarding building access, if the finger cursor is overlapping a building when using the overhead camera, switching to the ground camera may be restricted. Alternatively, if the camera switches to the ground camera while the finger cursor is overlapping a building in the overhead camera view, the reference point may be moved so that the ground cursor is not included outside the cursor collision area.

[0182] Furthermore, while the above embodiment illustrates the case where the reference point is moved in the world coordinate system, in other embodiments, it may be moved in the screen coordinate system.

[0183] Furthermore, although the above example described determining the cursor position and the point of focus based on a reference point, a reference point may not be used in other embodiments. For example, the cursor and / or the point of focus may be directly controlled based on the directional input of the left stick 32. Also, for example, if the cursor is controlled by the left stick 32, the point of focus may be determined based on the cursor position, or vice versa.

[0184] Furthermore, regarding access to the above-mentioned Type C building, in addition to the example above, building access may also be enabled if the user presses button A 53 while the roof is hidden. Also, if the user switches from the overhead camera to the ground camera after positioning the finger cursor over the Type C building, without hiding the roof as described above, building access may also be enabled for the said Type C building.

[0185] Furthermore, the above-mentioned processor may mean one or more processors within a single device, such as a main unit, or it may mean some or all of the one or more processors present in each of multiple devices, such as a main unit and a controller, or a main unit, a controller, and a server. The same applies to the memory and other components of the information processing system.

[0186] Furthermore, the program that causes a computer to execute each process may be a single program or a group of programs containing multiple programs. "A certain program" does not necessarily mean a single program, but can include a group of programs. Also, programs do not necessarily have to be stored in a single device. "A certain program" may, for example, mean the totality of the individual programs stored in multiple devices included in an information processing system.

[0187] At least a portion of the series of processes described above may be executed by the server-side device in an information processing system that includes a terminal-side device and a server-side device that can communicate via a network. The server may consist of multiple information processing devices, and the processing may be divided and executed by these multiple devices.

[0188] Although this embodiment and its variations have been described above, these descriptions are merely illustrative in every respect and are not intended to limit its scope. Furthermore, it goes without saying that various improvements and modifications can be made to this embodiment and its variations. [Explanation of symbols]

[0189] 1. Game System 2. Main unit 3 Left controller 4 Right controller 81 processors 84 Flash Memory 85 DRAM

Claims

1. On the computer, Based on the user input, the system switches between the first and second modes. In the first mode, Based on the input, the reference point is moved. Based on the aforementioned reference point, the gaze point of a virtual camera in a virtual space including a virtual plane on which a first type of object is placed is set. An image is generated based on the virtual camera, and a first game image is generated in which a first cursor is displayed at a predetermined position within the image. When the first cursor is overlapping an object of the first type, and a decision instruction is given based on the operation input, the first process relating to the object of the first type is executed. In the second mode, The virtual camera is positioned closer to the virtual surface than the position of the virtual camera in the first mode. Based on the operation input, the reference point is moved, An image is generated based on the virtual camera, and a second game image is generated in which a second cursor is displayed at a position on the virtual surface determined based on the reference point. If the first type of object is located within a predetermined range from the virtual camera, at least a portion of the first type of object will be hidden. In setting the point of focus based on the reference point, the point of focus is set such that the first area where the first type of object is placed does not overlap with the second cursor. When the second cursor overlaps with a second region which includes at least a region that does not overlap with the first region and which corresponds to the position where the first type of object is placed, and the decision instruction is given based on the operation input, the first processing relating to the first type of object is performed. Game program.

2. Based on the operation input, the first type of object is placed in the virtual space at the position based on the operation input. The game program according to claim 1.

3. When the first cursor is overlapping an object of the first type, and the system switches from the first mode to the second mode based on the operation input, the point of focus is set based on the reference point so that the second cursor is displayed at a position overlapping the first area. The game program according to claim 1.

4. If the first cursor is overlapping an object of the first type, the switching from the first mode to the second mode based on the operation input is restricted. The game program according to claim 1.

5. The game program according to claim 1, wherein when the first cursor is overlapping an object of the first type and the program switches from the first mode to the second mode based on the operation input, the program sets the point of focus so that the second cursor is displayed in a position that does not overlap with the first area.

6. The game program according to claim 1, wherein the depression angle of the virtual camera in the first mode is smaller than the depression angle of the virtual camera in the second mode.

7. The game program according to claim 1, wherein in the second mode, the height of the virtual camera in the virtual space is controlled based on the height of the reference point in the virtual space.

8. The game program according to claim 7, wherein when the height of the reference point changes from a first height to a second height, the height of the virtual camera is set from a height based on the first height to a height based on the second height, and when the height of the reference point changes from a second height to a first height, the height of the virtual camera is set to a height based on the second height.

9. In the first mode, When the first cursor is overlapping a second type of object and the decision instruction is given, the second process relating to the second type of object is executed. When the first cursor is overlapping the second type of object, and the system switches from the first mode to the second mode based on the operation input, the first processing relating to the second type of object is executed. In the second mode, The game program according to claim 1, which, when the second cursor overlaps with a third region corresponding to the position where the second type of object is placed, executes the first processing relating to the second type of object when the decision instruction is given.

10. In the first game image, data relating to the first type of object is embedded in the pixels within a first range that includes pixels where the first type of object is displayed. The game program according to claim 1, which, when the first cursor and a pixel on which data relating to the first type of object is embedded overlap, causes the first processing relating to the first type of object to be executed when the decision instruction is given.

11. The game program according to claim 10, wherein the first range is wider than the range in which objects of the first type are displayed.

12. The game program according to claim 11, wherein a first indicator indicating an object of the first type is displayed in pixels of a second range which is at least a part of the first range in the first game image.

13. The game program according to claim 12, wherein when the first cursor overlaps with a pixel that is included in the first region and does not display an object of the first type, but displays another object of the first type, the first processing relating to the other object of the first type is executed when the decision instruction is given.

14. In the case where a pixel within the second range on which another object of the first type is displayed does not overlap with the first cursor, the first indicator and the other object of the first type are displayed superimposed on that pixel. The game program according to claim 13, in the case where a pixel within the second range on which another object of the first type is displayed overlaps with the first cursor, the first indicator is hidden on the pixel and the other object of the first type is displayed.

15. The game program according to claim 1, wherein if an object of a first type is located within a first distance in a direction based on the line of sight of the virtual camera, the transparency of the object of the first type is increased over time.

16. A game device comprising at least one processor, The aforementioned processor, Based on the user input, the system switches between the first and second modes. In the first mode, Based on the input, the reference point is moved. Based on the aforementioned reference point, set the gaze point of a virtual camera in a virtual space that includes a virtual plane on which a first type of object is placed, An image is generated based on the virtual camera, and a first game image is generated in which a first cursor is displayed at a predetermined position within the image. When the first cursor is overlapping an object of the first type and a decision instruction is given based on the operation input, the first process relating to the object of the first type is executed. In the second mode, The virtual camera is positioned closer to the virtual surface than the position of the virtual camera in the first mode, Based on the operation input, the reference point is moved, A second game image is generated, which is an image generated based on the virtual camera, in which a second cursor is displayed at a position on the virtual surface determined based on the reference point. If the object of the first type is located within a predetermined range from the virtual camera, at least a portion of the object of the first type is hidden. In setting the point of focus based on the reference point, the point of focus is set such that the first area where the first type of object is placed does not overlap with the second cursor. A game device that, when the second cursor overlaps with a second region which includes at least a region that does not overlap with the first region and which corresponds to a position where an object of the first type is placed, and when the decision instruction is given based on the operation input, executes the first processing with respect to the object of the first type.

17. A game system having at least one processor, The aforementioned processor, Based on the user input, the system switches between the first and second modes. In the first mode, Based on the input, the reference point is moved. Based on the aforementioned reference point, set the gaze point of a virtual camera in a virtual space that includes a virtual plane on which a first type of object is placed, An image is generated based on the virtual camera, and a first game image is generated in which a first cursor is displayed at a predetermined position within the image. When the first cursor is overlapping an object of the first type and a decision instruction is given based on the operation input, the first process relating to the object of the first type is executed. In the second mode, The virtual camera is positioned closer to the virtual surface than the position of the virtual camera in the first mode, Based on the operation input, the reference point is moved, A second game image is generated, which is an image generated based on the virtual camera, in which a second cursor is displayed at a position on the virtual surface determined based on the reference point. If the object of the first type is located within a predetermined range from the virtual camera, at least a portion of the object of the first type is hidden. In setting the point of focus based on the reference point, the point of focus is set such that the first area where the first type of object is placed does not overlap with the second cursor. A game system that, when the second cursor overlaps with a second region which includes at least a region that does not overlap with the first region and corresponds to a position where an object of the first type is placed, and when the decision instruction is given based on the operation input, executes the first processing with respect to the object of the first type.

18. On the computer, Based on the user input, the system switches between the first and second modes. In the first mode, Based on the input, the reference point is moved. Based on the aforementioned reference point, the gaze point of a virtual camera in a virtual space including a virtual plane on which a first type of object is placed is set. An image is generated based on the virtual camera, and a first game image is generated in which a first cursor is displayed at a predetermined position within the image. When the first cursor is overlapping an object of the first type, and a decision instruction is given based on the operation input, the first process relating to the object of the first type is executed. In the second mode, The virtual camera is positioned closer to the virtual surface than the position of the virtual camera in the first mode. Based on the operation input, the reference point is moved, An image is generated based on the virtual camera, and a second game image is generated in which a second cursor is displayed at a position on the virtual surface determined based on the reference point. If the first type of object is located within a predetermined range from the virtual camera, at least a portion of the first type of object will be hidden. In setting the point of focus based on the reference point, the point of focus is set such that the first area where the first type of object is placed does not overlap with the second cursor. When the second cursor overlaps with a second region which includes at least a region that does not overlap with the first region and which corresponds to the position where the first type of object is placed, and the decision instruction is given based on the operation input, the first processing relating to the first type of object is performed. Game processing method.

Images