Information processing program, information processing system, information processing device, and information processing method

Abstract

This invention provides an information processing program, information processing system, information processing device, and information processing method that can improve visibility according to the status of the player character. [Solution] The system determines whether the positional relationship between the player character in the virtual space and the surrounding terrain objects satisfies the permission conditions. If the positional relationship does not satisfy the permission conditions and the virtual camera approaches the terrain object, avoidance control is performed to prevent the virtual camera from being placed inside the terrain object. If the positional relationship satisfies the permission conditions, the system controls the virtual camera without performing the avoidance control. Then, the faces of the terrain object that are facing outwards to the virtual camera are drawn.

Description

Technical Field

[0001] The present invention relates to an information processing program, an information processing system, an information processing apparatus, and an information processing method for performing processing to display an image based on a virtual space viewed from a virtual camera.

Background Art

[0002] Conventionally, there has been an information processing apparatus that displays an image of a virtual space viewed from a virtual camera (see, for example, Patent Document 1). When the virtual camera is likely to be placed inside another object in the information processing apparatus disclosed in Patent Document 1, the virtual camera is moved to a position where it does not contact the other object.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, even in a situation where the visibility is improved by transmitting the other object when the virtual camera is placed inside the other object in the information processing apparatus disclosed in Patent Document 1, the virtual camera cannot be placed inside the other object.

[0005] Therefore, an object of the present invention is to provide an information processing program, an information processing system, an information processing apparatus, and an information processing method capable of improving visibility according to the situation of the player character.

Means for Solving the Problems

[0006] In order to achieve the above object, the present invention can adopt configurations such as the following (1) to (18).

[0007] (1) One example of the configuration of the information processing program of the present invention is executed in the computer of an information processing device. The information processing program causes the computer to function as a determination means, a virtual camera control means, a terrain drawing means, and an image output means. The determination means determines whether the positional relationship between a player character in the virtual space and terrain objects surrounding the player character satisfies the permission conditions. The virtual camera control means, when the virtual camera approaches a terrain object if the positional relationship does not satisfy the permission conditions, performs avoidance control to prevent the virtual camera from being placed inside the terrain object, and controls the virtual camera without performing the avoidance control if the positional relationship satisfies the permission conditions. The terrain drawing means draws the faces of the terrain object that are facing the virtual camera. The image output means performs processing to output a display image based on the image of the virtual space including the terrain objects to a display device.

[0008] According to the configuration described in (1) above, based on the positional relationship between the player character and the surrounding terrain objects, it is determined whether or not avoidance control is performed to prevent the virtual camera from being placed inside the terrain objects. As a result, an image with improved visibility can be displayed according to the player character's situation.

[0009] (2) In the configuration of (1) above, the determination means may determine that the positional relationship satisfies the permission conditions if the proportion of the area around the position based on the player character being obscured by other objects, including terrain objects, is equal to or greater than a threshold.

[0010] According to the configuration in (2) above, when the degree of occlusion is high, it is assumed that the player character is surrounded by other objects and the user wants to observe the surroundings. Therefore, by placing the virtual camera inside the terrain object, it is possible to appropriately determine situations in which visibility will be improved.

[0011] (3) In the configuration of (1) or (2) above, the determination means may determine whether the positional relationship satisfies the permission conditions based on the distance between the player character and other objects, including terrain objects.

[0012] According to the configuration in (3) above, if the player character is obscured by other objects in the distance, it is considered to be a situation similar to when the player character is placed outside the terrain object. Placing the virtual camera inside the terrain object may reduce visibility, so it is possible to avoid placing the virtual camera inside the terrain object in such situations.

[0013] (4) In any one of the configurations (1) to (3) above, the determination means may prioritize the horizontal positional relationship over the vertical positional relationship of the virtual space to determine whether the positional relationship satisfies the permission conditions.

[0014] According to the configuration in (4) above, even if the player character's vertical position is obstructed, in areas where the front, back, left, and right directions are not obstructed, placing the virtual camera inside a terrain object may reduce visibility. Therefore, in such situations, it is possible to avoid placing the virtual camera inside a terrain object.

[0015] (5) In any one of the configurations (1) to (4) above, the information processing program may further include a computer as an internal determination means and a display change means. The internal determination means determines whether or not the virtual camera is located inside the terrain object. The display change means performs a display change process such that the display image changes when it is determined that the virtual camera is located inside the terrain object.

[0016] According to the configuration of (5) above, it is possible to clearly show that an image seen from a virtual camera placed inside a terrain object is being displayed. Also, it is possible to display an appropriate image according to the fact that the terrain object can be seen through.

[0017] (6) In the configuration of (5) above, as the display change means, as a display change process, a post - process may be performed on an image depicting a virtual space including a terrain object.

[0018] According to the configuration of (6) above, when a virtual camera is placed inside a terrain object, it is possible to easily change the display image by using post - process processing.

[0019] (7) In the configuration of (5) above, as the display change means, as a display change process, a change object may be placed in the virtual space. [[ID=­17]]

[0020] According to the configuration of (7) above, by placing a change object in the virtual space, when a virtual camera is placed inside a terrain object, it is possible to easily change the display image.

[0021] (8) In any one of the configurations of (5) to (7) above, as the display change means, as a display change process, the visibility of an object located at a position far from the virtual camera may be reduced.

[0022] According to the configuration of (8) above, by preventing an object far from the virtual camera from being seen through, it is possible to prevent the game from becoming too easy.

[0023] (9) In the configuration of (8) above, as the display change means, as a display change process, fog may be applied so that the visibility of an object located at a position far from the virtual camera decreases more.

[0024] According to the configuration of (9) above, an image that can capture the sense of distance to the object can be displayed.

[0025] (10) In any one of the configurations of (5) to (9) above, as the display change process, the display change means may change the display mode of at least a part of the non-front side portion, which is the portion where the front side facing surface among the surfaces constituting the terrain object is not drawn.

[0026] According to the configuration of (10) above, an image that can clearly show that the virtual camera is arranged inside the terrain object can be displayed.

[0027] (11) In the configuration of (10) above, as the display change process, the display change means may change the display mode of at least a part of the non-front side portion by darkening the color of the background of the virtual space. <​​​​​​​​​​​​​​​​​​​​

[0032] According to the configuration described in (13) above, it is possible to display an image that clearly shows that a cavity is located within a terrain object. Furthermore, even in cases where the view of distant objects is obscured to prevent the user from seeing what is located inside the cavity, it is possible to display an image that clearly shows the existence of the cavity, which can serve as a target for the player character's actions.

[0033] (14) In any one of the configurations (5) to (13) above, the display changing means may reduce the visibility of the edges of the display image as a display changing process.

[0034] According to the configuration described in (14) above, it is possible to display an image that clearly shows that a virtual camera is placed within the terrain object. In addition, by making the edges of the displayed image difficult to see, it is possible to prevent the display of an image that allows for transparency over long distances.

[0035] (15) In any one of the configurations (5) to (14) above, the internal determination means may determine whether the virtual camera is located inside a terrain object based on whether the four corners of the near-clip surface of the virtual camera are located inside the terrain object.

[0036] According to the configuration described in (15) above, when the area to be rendered using the virtual camera is within a terrain object, a display image corresponding to the virtual camera being located within the terrain object is displayed, thus enabling the display of an image consistent with the rendered area.

[0037] (16) In any one of the configurations (1) to (15) above, the virtual camera control means may automatically move the virtual camera so that it is placed inside a terrain object when the positional relationship satisfies the permission conditions.

[0038] According to the configuration described in (16) above, it is possible to avoid generating an image in which the player character is obscured by the faces of the terrain object that are facing the virtual camera.

[0039] (17) In any one of the configurations (1) to (15) above, the information processing program may further function as a transparent display means, which is a computer. When the player character is obscured by a face of a terrain object that is facing outwards, as seen from the virtual camera, the transparent display means displays the player character so that it is transparent to that face.

[0040] According to the configuration described in (17) above, even if the player character is obstructed by the face of the terrain object that is facing the virtual camera, an image can be displayed that allows the player character's position to be confirmed.

[0041] (18) In any one of the configurations described in (1) to (17) above, the information processing program may further include a computer as a player character motion control means. The player character motion control means causes the player character to perform an action that destroys and / or deforms at least a portion of a terrain object based on the user's input.

[0042] According to the configuration described in (18) above, in games where the player character cannot destroy or deform terrain objects, the developer can pre-set a suitable virtual camera position for displaying the player character. On the other hand, in games where the player character can destroy or deform terrain objects, even in situations where setting such a virtual camera becomes difficult, an image with improved visibility can be displayed even when the player object is placed in a narrow space within a terrain object that allows the player character to destroy or deform the terrain object.

[0043] Furthermore, the present invention may be implemented in the form of an information processing device, an information processing system, and an information processing method. [Effects of the Invention]

[0044] According to the present invention, it is possible to display images with improved visibility according to the player character's situation. [Brief explanation of the drawing]

[0045] [Figure 1] This diagram shows an example of the main unit 2 with the left controller 3 and right controller 4 attached. [Figure 2] This diagram shows an example of the state in which the left controller 3 and right controller 4 have been removed from the main unit 2. [Figure 3] A six-view drawing showing an example of the main unit 2. [Figure 4] A six-view drawing showing an example of the left controller 3. [Figure 5] A six-view drawing showing an example of the right controller 4. [Figure 6] Block diagram showing an example of the internal configuration of the main unit 2. [Figure 7] Block diagram showing an example of the internal configuration of the main unit 2, left controller 3, and right controller 4. [Figure 8] This diagram shows an example of a terrain object that is a voxel object. [Figure 9] Figure 8 shows an example of what the terrain object looked like before a portion of it was deleted. [Figure 10] Figure 8 shows an example of what the terrain looks like after a portion of the terrain object has been deleted. [Figure 11] A diagram showing an example of the contents of voxel data. [Figure 12] A diagram showing an example of property information that indicates the properties of a material. [Figure 13] A diagram showing an example of texture information that indicates the texture of a material. [Figure 14] A diagram showing an example of a mesh generation method. [Figure 15] A diagram showing an example of a game image that includes terrain objects. [Figure 16] This diagram shows an example where a virtual camera C is placed in a game space with terrain object TO and player character PC set up, in a first state. [Figure 17] This diagram shows an example of how a player character PC erases part of a terrain object TO. [Figure 18] This diagram shows an example of the destruction range of voxels targeted for destruction in terrain object TO. [Figure 19] This diagram shows an example where a virtual camera C is positioned in a second state within a game space where terrain object TO and player character PC are set up. [Figure 20] This diagram shows an example where a virtual camera C is positioned in a third state within a game space where terrain object TO and player character PC are set up. [Figure 21] A diagram illustrating an example of the range of motion of virtual camera C when the underground camera permit conditions are not met, and an example of the range of motion of virtual camera C when the underground camera permit conditions are met. [Figure 22] This diagram shows an example of images taken from the player character PC's position, capturing the six sides (up, down, left, right, front, and back). [Figure 23] This figure shows an example of a display image shown on display 12 based on the image viewed from the virtual camera C positioned in the first state. [Figure 24] This figure shows an example of a display image shown on display 12 based on the image viewed from the virtual camera C positioned in the second state. [Figure 25] This figure shows an example of a display image shown on display 12 based on the image viewed from the virtual camera C positioned in the third state. [Figure 26] This figure shows an example of points P1 to P4 at the four corners of the near-clip surface of virtual camera C. [Figure 27] This figure shows an example of a display image with a fog effect applied based on the distance from virtual camera C. [Figure 28]This figure shows an example of a display image that changes the display pattern of the background portion of the game space. [Figure 29] This diagram shows an example of various types of data used in information processing in Game System 1. [Figure 30] This diagram shows an example of various types of data used in information processing in Game System 1. [Figure 31] Figure 30 shows a subroutine illustrating an example of the underground camera switching process in step S12 of the flowchart. [Modes for carrying out the invention]

[0046] The following describes a game system according to an example of this embodiment. An example of the game system 1 in this embodiment includes a main unit (information processing device; functioning as the game device main unit in this embodiment) 2, a left controller 3, and a right controller 4. The left controller 3 and the right controller 4 are detachable from the main unit 2. In other words, the game system 1 can be used as an integrated device by attaching the left controller 3 and the right controller 4 to the main unit 2. Alternatively, the game system 1 can be used with the main unit 2 and the left controller 3 and right controller 4 as separate components (see Figure 2). The hardware configuration of the game system 1 in this embodiment will be described below, followed by a description of the control of the game system 1 in this embodiment.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0082] 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. In other words, the main unit 2 can determine the operation of each button 103 and the analog stick 32 based on the operation data.

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

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

[0085] The right controller 4 is equipped with the same inputs as the left controller 3. Specifically, it is equipped with buttons 113 and an analog stick 52. These inputs have the same functions and operate in the same way as the inputs of the left controller 3.

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

[0087] Next, an overview of the processes performed in the game system 1 will be described with reference to Figures 8 to 15. In this embodiment, the game system 1 generates a game image in which terrain objects and characters (for example, player characters controlled by the player) are placed in a game space, which is a three-dimensional virtual space, and displays it on a display device. In this embodiment, the display device on which the game image is displayed may be the display 12 described above, or it may be a stationary monitor.

[0088] In this embodiment, the shape of some objects in the game space is defined by voxel data. Here, a voxel is a rectangular (more specifically, cubic) region arranged in a grid in the game space, and voxel data is the data set for each voxel. Hereafter, objects whose shape is defined by voxel data will be called "voxel objects". In this embodiment, the game system 1 stores voxel data for each of the multiple voxels set in the game space as data for generating voxel objects in the game space.

[0089] Figure 8 shows an example of a terrain object that is a voxel object. As shown in Figure 8, in this embodiment, terrain objects representing the ground and other terrain are defined by voxel data (i.e., they are voxel objects). Each cube shown in Figure 8 represents a terrain object. Note that in Figure 8, the edges of the terrain objects are shown with thick lines, but these thick lines are added for the purpose of making the drawing easier to read, and in reality, the edges of the terrain objects do not need to be displayed with thick lines.

[0090] Furthermore, the terrain object shown in Figure 8 is generated using a rule such as, "If the parameter included in the voxel data set for a voxel is greater than a predetermined value, a cube is placed at the voxel's position; if it is less than or equal to the predetermined value, nothing is placed at the voxel's position." The terrain object shown in Figure 8 is provided to illustrate the relationship between voxels and voxel objects in an easy-to-understand manner. In this embodiment, in practice, voxel objects are generated (based on voxel data) using a rule that results in a shape more complex than the length of one side of a voxel, such as the terrain object shown in Figure 15, which will be described later. The rule for determining the shape of a voxel object based on voxel data is arbitrary. In other embodiments, the game system 1 may generate voxel objects as shown in Figure 8 or as shown in Figure 15 based on object data.

[0091] For voxel objects, the shape can be changed by modifying the voxel data of each voxel. Figures 9 and 10 show examples of what the terrain object shown in Figure 8 looks like before and after a portion of it is deleted. That is, when the shaded portion of the terrain object shown in Figure 9 is destroyed, the terrain object changes to the shape shown in Figure 10. At this time, the game system 1 can easily delete the terrain object by rewriting the voxel data of the shaded portion voxel to indicate that the terrain object does not exist. Furthermore, when adding a terrain object, the game system 1 can easily change the shape of the terrain object by modifying the voxel data of each voxel, just as when deleting a terrain object.

[0092] In this way, Game System 1 can freely change the shape of voxel objects by rewriting the voxel data. For example, if a terrain object is destroyed in a game for some reason (for example, when a player character hits the terrain object) and the shape of that terrain object changes as a result, Game System 1 can freely change the shape of the terrain object by changing the voxel data used to generate the terrain object, rather than directly changing the data that represents the external shape of the terrain object (i.e., the mesh described later).

[0093] Figure 11 shows an example of the contents of voxel data. In this embodiment, the game space can be divided into a plurality of voxels arranged in a grid. The game system 1 stores voxel data associated with each voxel in the game space. The voxel data indicates the presence or absence of a voxel object in the voxel corresponding to the voxel data.

[0094] As shown in Figure 11, the voxel data includes density data. The density data indicates the degree to which an object is contained within the region in which each voxel is defined. As will be explained in detail later, the position and shape of the surface of the voxel object (i.e., the mesh described later) are determined based on the above density. In other words, in this embodiment, the above density is also the data used to create the mesh that defines the surface of the voxel object.

[0095] In this embodiment, the density can take an integer value within the range from a lower limit (e.g., 0) to an upper limit (e.g., 255). In this embodiment, the game system 1 assumes that if the density value set for a voxel is high, the proportion of the volume occupied by voxel objects within that voxel tends to be large, and if the density value is low, the proportion within that voxel tends to be small. For example, if the density is 0, there are no objects in that voxel; if the density is 255, the entire voxel is occupied by objects; and if the density is a value in between, objects occupy the voxel in a proportion corresponding to the value. The shape of the voxel mesh, i.e., the shape of the voxel object, is then determined based on the density. However, the shape of the voxel object generated based on the above density does not need to have a volume that exactly matches the proportion indicated by the density. For example, the volume may differ between a method for generating a voxel object like the one in Figure 8 and a method for generating a voxel object like the one in Figure 15, even if they are based on the same density.

[0096] In other embodiments, density may represent either a state where voxel objects occupy the entire region within the voxel, or a state where no voxel objects are contained within the region within the voxel. For example, density data may only take the form of either 0 or 1.

[0097] As shown in Figure 11, the voxel data includes material data. The material data indicates the material (in other words, substance) of the voxel object generated by the voxel data. In this embodiment, the voxel object is assigned materials such as sand, rock, and soil. That is, in this embodiment, multiple types of materials are provided as materials that can be assigned to the voxel object, and the voxel object is assigned one of these multiple types of materials.

[0098] As shown in Figure 11, in this embodiment, the material data indicates the material identification information (referred to as the "material ID"). In this embodiment, the game system 1 stores material information indicating the properties and texture of each material provided in the game. In this embodiment, the material information associates the material ID with the properties of the material and the appearance of the material (specifically, the texture). Specifically, the material information is information that associates the material ID with the identification information of the properties of the material (referred to as the "property ID") and the identification information of the texture of the material (referred to as the "texture ID") (see Figure 11).

[0099] Figure 12 shows an example of property information indicating the properties of a material. As shown in Figure 12, the game system 1 stores property information that associates the above property ID with information indicating the content of the property indicated by the property ID. The properties of a material are the properties that the voxel object to which the material is set has in the game, such as weight and slipperiness as shown in Figure 12. The specific content of the properties is arbitrary, and for example, the following information may be set as the properties of the material. ·temperature • Fragility (for example, the number of times a voxel object will break when subjected to an impact) • Whether or not other objects can be attached to a voxel object. • The amount of health the player character recovers when the player character destroys a voxel object. • The amount of in-game currency a player character acquires when they destroy a voxel object. The specific properties set for the material are arbitrary. In other embodiments, different information may be set as information indicating the properties of the material.

[0100] Figure 13 shows an example of texture information indicating the texture of a material. As shown in Figure 13, the game system 1 stores texture information that associates the above-mentioned texture ID with the texture indicated by that texture ID.

[0101] In addition to texture information, optional information regarding color and / or pattern may be set as data that defines the appearance of a voxel object. For example, a crack pattern may be set as information regarding the appearance of a voxel object. By using such a pattern, game system 1 can generate an image of a voxel object that represents a cracked appearance.

[0102] As described above, in this embodiment, the material data defines the properties of the voxel object and the texture used for the voxel object by the material ID. For example, if the material ID indicated by the material data included in the voxel data is "002", the properties indicated by the property ID "001" associated with that material ID in the material information are set as the properties of the voxel object corresponding to that voxel data (see the arrow shown in Figure 11). In the above case, the texture indicated by the texture ID "002" associated with that material ID in the material information is applied to the voxel object corresponding to that voxel data (see the arrow shown in Figure 11).

[0103] As described above, in this embodiment, the game system 1 manages the properties and textures of materials separately. Therefore, in this embodiment, it is possible to easily set up multiple types of materials that have the same properties but different appearances (i.e., textures), or multiple types of materials that have different properties but the same appearance.

[0104] The material data may be any data that can identify the properties and / or texture of the material. For example, in other embodiments, the material data may indicate the property ID and texture ID, or it may have a data structure that actually contains data indicating the properties and texture of the material.

[0105] Furthermore, material data may also include information about the material, which may contain other information different from the properties and textures described above. For example, material data may include effect data that indicates an effect that occurs when the effect conditions set for a voxel object (for example, when a part of the voxel object is destroyed, or when a character steps on the voxel object) are met. Note that effect data may be data that indicates an effect image (for example, an effect image that represents the destruction of the voxel object) or data that indicates an effect sound (the sound of a character walking on the voxel object).

[0106] As shown in Figure 11, voxel data includes state data that indicates the state of the voxel object. The specific content of the state data is arbitrary. For example, the state data may indicate whether the voxel object is wet or not, or it may indicate the amount of damage inflicted on the voxel object. The content of the state data may be updated during gameplay.

[0107] In this embodiment, the surface of a voxel object is represented by a mesh. A mesh is a collection of multiple faces (specifically, polygons) placed in the game space. In this embodiment, the game system 1 generates a mesh for a voxel object based on the voxel data of each voxel set in the game space. An example of generating a mesh based on voxel data is described below.

[0108] Figure 14 shows an example of a mesh generation method. Note that in Figure 14, voxels and meshes are represented in two dimensions for clarity and ease of explanation; however, in reality, a three-dimensional mesh is generated based on voxels in three-dimensional space.

[0109] As described above, in this embodiment, the density set for a voxel is set within the range of 0 to 255. In this embodiment, voxels with a density equal to or greater than the reference value are considered to be inside the object, and voxels with a density less than the reference value are considered to be outside the object. It is not necessary to define only voxels with a density of 0 as being outside the object (i.e., reference value = 1), and the reference value can be, for example, 128. In the example shown in Figure 14, the density of voxel 201 and the other outer voxels is set to 0, the density of voxel 202 is set to 100 (less than the reference value), and the densities of voxels 203 and 204 are set to 150 and 200 (greater than or equal to the reference value). In this embodiment, the game system 1 generates vertices between voxels with a density equal to or greater than the reference value and voxels with a density less than the reference value. Specifically, for each region spanning eight adjacent voxels (four in the diagram) (the region enclosed by the dotted line in the diagram), a determination is made as to whether or not to generate a vertex. In other words, vertices are generated in regions that span both voxels with a density above a certain threshold and voxels with a density below that threshold. Furthermore, if the boundaries between adjacent vertices (the boundaries of the regions containing each vertex) pass through areas with voxels with a density above a certain threshold and areas with a density below that threshold, a polygon mesh is generated by connecting those vertices.

[0110] The coordinates of vertices are determined by comparing the density of adjacent voxels along each of the X, Y, and Z axes and interpolating based on the density difference. While coordinate calculations can also be performed based on normal information, this normal information may be stored beforehand for at least some voxels, or if not stored, it may be calculated based on the density of adjacent voxels. In Figure 14, since the density of voxel 202 is below the baseline value, voxel 202 is treated as outside the object when determining the presence or absence of vertices; however, the density value of voxel 202 itself is used in calculating the coordinates of the generated vertices. If the baseline value were set lower than the density of voxel 202, additional vertices would be added to the upper right and upper left sides of voxel 202 in Figure 14.

[0111] As described above, by generating a polygon mesh, it is possible to generate a shape with a volume that reflects the density of each voxel to some extent. However, depending on the relationship with adjacent voxels, it is possible that voxels with a density of 0 may include some areas within the object, or that voxels with a density of 255 may include some areas outside the object. In addition, in this embodiment, voxels below a certain threshold are treated as being outside the object, so the volume is smaller because there are fewer vertices compared to when they are treated as being inside the object. In other words, it is not necessary to calculate the polygon mesh so that the volume corresponds precisely to the density value.

[0112] Figure 15 shows an example of a game image including terrain objects. In this embodiment, by generating a mesh as described above, the voxel object can be made to have a shape with complex irregularities compared to the length of one side of a voxel.

[0113] The method for generating the mesh based on the voxel data is optional. For example, in another embodiment, if the density of the voxel data is greater than a predetermined value, the mesh may be generated such that cubes are placed in the voxels (see Figure 8).

[0114] Game System 1 determines the appearance (i.e., color and / or pattern) of each face of the mesh generated as described above, according to the material identified by the voxel data. Specifically, Game System 1 determines the texture to be used for rendering each face of the mesh based on the voxel data, and generates an image of the voxel object by mapping the determined texture to each face. The texture mapped to each face of the mesh is determined based on the voxel data of the voxel used to generate that face (referred to as the target voxel) among the voxels in which the voxel object exists. The target voxel is, depending on the mesh generation method, for example, one or more voxels arranged around that face. In other words, the texture mapped to the face of the mesh is determined to be the texture corresponding to the material set for one or more voxels arranged around that face.

[0115] In other embodiments, a single voxel data may contain multiple types (e.g., two types) of material data. In this case, the voxel data includes ratio data relating to the multiple types of material data. The ratio data is used to determine the texture to be used for the voxel object, and indicates the ratio by which each material (specifically, the texture corresponding to the material) represented by the multiple types of material data affects the appearance (specifically, the color and / or pattern) of the voxel object. Furthermore, when determining the texture to be mapped to each face of the mesh, the texture is determined based on the various data (specifically, density data, multiple types of material data, and ratio data) contained in the voxel data of the target voxel. For example, if multiple types of materials are set for a target voxel corresponding to one face, the texture corresponding to the material with the greatest influence (one type) may be used, taking the above ratio into consideration, or each texture corresponding to the multiple types of materials may be used, taking the above ratio into consideration.

[0116] In other embodiments, there may be both voxel objects that use voxel data containing one type of material data and voxel objects that use voxel data containing two types of material data.

[0117] Next, with reference to Figures 16 to 28, an example of gameplay in which a player character in the game space moves in response to user operations on the game system 1 will be described. For example, in this embodiment, the player character PC that appears in the game space displayed on the display 12 moves in response to operations on the operation buttons and sticks of the left controller 3 and / or right controller 4 of the integrated game system 1, or touch operations on the touch panel 13 of the main unit 2, or operations that move the entire game system 1 or change its posture.

[0118] Figure 16 shows an example where a virtual camera C is placed in a game space with a terrain object TO and a player character PC set up, in a first state. The terrain object TO includes not only natural objects and natural areas such as the ground, cliffs, and rocks in the game space, but also artificial objects such as buildings and paved surfaces. The terrain object TO is generated based on the voxel data described above and consists of voxel objects whose surfaces are represented by meshes. For example, one voxel space defining voxels is set up in the game space, and multiple voxels are defined in that voxel space, thereby generating a terrain object TO in the game space. Here, at least one voxel space is set up in at least a part of the game space to define multiple voxels, and the length of one side of the voxel (resolution), the vector (direction) of the xyz axes in the global coordinate system in the vector space, the lengths of the x, y, and z directions of the voxel space, and the position of the voxel space in the game space are defined for each voxel space. Note that Figure 16 illustrates an example of rendering using a mesh generation method described in Figure 14, which produces an appearance similar to that in Figure 15. However, rendering may also be performed using block-shaped meshes as described in Figures 9 and 10.

[0119] In this embodiment, a display image based on an image (virtual space image) viewed from a virtual camera C placed in the game space is displayed on a display device (e.g., display 12). For example, the virtual camera C is placed within a range of motion based on the position of the player character PC placed in the game space. The player character PC can move within the game space in response to user operations, and the range of motion also moves within the game space in response to the movement of the player character PC. Furthermore, the virtual camera C can move within the range of motion in response to user operations. Therefore, the position of the virtual camera C can be moved within the game space in response to user operations that move the player character PC and user operations that move the position of the virtual camera C, respectively.

[0120] In this embodiment, for example, the player character PC can be moved into a cave or cavity that is pre-formed in the terrain object TO, such as cave B shown in Figure 16, or into a cave or cavity formed by the player character PC destroying and / or deforming a part of the terrain object TO. For example, the player character PC can destroy the terrain object TO and make at least a part of it disappear (erase) by performing an action to destroy the terrain object TO. As an example, the player character PC can destroy the terrain object TO and make a part of it disappear by performing an action to hit a part of the terrain object TO.

[0121] Figure 17 shows an example of a player character PC erasing a portion of a terrain object TO. As an example, Figure 17 shows the interior of a terrain object TO as the player character PC is excavating while erasing a portion of it, and this excavation is shown using a vertical cross-sectional view of the terrain object TO. Note that the vertical cross-sectional view shown in Figure 17 is not a virtual space image used in this embodiment or a display image based on said virtual space image, but rather a diagram used to explain how the player character PC is excavating the terrain object TO.

[0122] When a player character PC performs an action that involves hitting a portion of a terrain object TO, the terrain object TO within a predetermined range centered on the hit location is erased. For example, as shown in the upper part of Figure 17, if a player character PC performs an action that involves hitting the wall at the end of a cave formed within a terrain object TO, the terrain object TO beyond that wall is destroyed and erased, resulting in the cave being reduced in depth. Specifically, as shown in the lower part of Figure 17, the destruction action of the player character PC creates a bell-shaped destruction area in the terrain object TO, where the innermost part missing due to the destruction is semi-ellipsoidal. This action expands the space at the innermost part of the cave where there is no terrain object TO. Figure 17 shows an example where the cave formed in the terrain object TO expands by space CV due to the above action.

[0123] In this embodiment, the destruction and deletion of a terrain object TO is represented by modifying the voxel data of each voxel that constitutes the terrain object TO. Figure 18 shows an example of the destruction range of the voxels to be destroyed in the terrain object TO. The left side of Figure 18 shows the front (destroyed side) of the terrain object TO as seen from the player character PC side that destroys the terrain object TO. The right side of Figure 18 shows the right side of the terrain object TO shown in the left side.

[0124] The destruction range of a terrain object TO destroyed by a player character PC's destruction action is set based on the position, strength, and ability of the player character PC when destroying the terrain object TO, as well as the strength (material) of the terrain object TO. For example, the destruction range is set to a range where the distance from a reference position, which is set based on the position where the destruction action by the player character PC occurred in the game space, is within a predetermined distance. In the example in Figure 18, the terrain object TO has a bell-shaped destruction range formed around the position where the player character PC performed the destruction action, with the innermost part missing by the destruction being hemispherical. The shape of the destruction range may be other shapes, including spherical, ellipsoidal, cube-shaped, cylindrical, wedge-shaped, shapes generated by 3D software, or shapes where parts of these shapes are missing. Furthermore, the position of the destruction range may be set centered on the position where the destruction action by the player character PC occurred in the game space (for example, the position reached by the player character PC's fist), or it may be set centered at a predetermined distance forward from that position as viewed from the player character PC.

[0125] Based on the aforementioned destruction range, voxels to be deleted (including partial deletion) are determined using a Signed Distance Field (SDF). The SDF indicates the distance from each voxel to the nearest destruction range surface, with the destruction range surface being considered as 0, and distances outside the destruction range being considered positive and negative. Then, the deletion process for each voxel is set according to the SDF for that voxel. For example, for voxels to be deleted, the voxel data of that voxel is rewritten to indicate that the terrain object does not exist, thereby deleting that portion of the voxel from the terrain object TO.

[0126] For example, in this embodiment, the deletion of at least a portion of each voxel is controlled by changing the density contained in the voxel data. For example, density is an index that indicates the degree to which voxel objects occupy the volume within the area defined by the voxel. The density value can take the range of an integer value from a lower limit (e.g., 0) to an upper limit (e.g., 255). When the density value set for a voxel is high, the above degree within that voxel is large, and when the density value is low, the above degree within that voxel is small. Furthermore, for voxels with a density set to the lower limit (i.e., 0), it is assumed that no voxel objects are contained within that voxel, and for voxels with a density set to the upper limit (i.e., 255), it is assumed that voxel objects are contained throughout the entire voxel. In other words, when the density is set to a value greater than the lower limit, it becomes voxel data that indicates the presence of terrain objects, and when it is set to the lower limit, it functions as voxel data that indicates the absence of terrain objects. However, the shape of the voxel mesh generated based on density does not need to have a volume that precisely corresponds to the density value.

[0127] In this embodiment, the deletion of each voxel is controlled by rewriting the density of each voxel based on the SDF of each voxel. Specifically, by rewriting the density of voxels where the SDF is a negative distance to a lower value, terrain objects are omitted from at least some of the voxels included in the destruction range. As a first example, by rewriting the density of voxels where the SDF is a negative distance to a lower limit, terrain objects are omitted from voxels included in the destruction range, and terrain objects are omitted from voxels outside the destruction range by maintaining the density of voxels where the SDF is a positive distance at its original value. As a second example, the density of voxels where the SDF is a negative distance is rewritten to a lower value as the absolute value of the distance increases, and the density of voxels where the absolute value is greater than a predetermined value is rewritten to a lower limit, resulting in some of the voxels included in the destruction range being devoid of terrain objects, while terrain objects are omitted from voxels outside the destruction range by maintaining the density of voxels where the SDF is a positive distance at its original value. As a third example, by rewriting the density of voxels where the SDF is a negative distance to a lower limit, terrain objects will not exist for voxels within the destruction range, and by rewriting the density of voxels where the SDF is a positive distance to a lower value as the absolute value of the distance decreases, voxels outside the destruction range will also be considered to have no voxel objects within their entirety.

[0128] Furthermore, the amount of change in density when rewriting the density in the voxel data as described above may be adjusted according to the type and state of the material indicated by the material data contained in the voxel data. For example, the amount of change in density may be adjusted according to the properties of the material indicated by the material data (e.g., fragility, temperature) (for example, the more fragile a material is, the larger the amount of change in density to lower).

[0129] Furthermore, the rewriting of the density in the voxel data described above may be adjusted according to the state data contained in the voxel data. For example, the state data is data indicating the amount of damage inflicted on the terrain object TO by the player character PC. As an example, whether to decrease the density in the voxel data or increase the amount of damage may be determined by the relationship between the attack power of the player character PC and the defensive power of the terrain object TO. Specifically, in the relationship between the hardness of the attacking side (for example, the hardness of the fist that the player character PC uses to punch the terrain object TO) and the hardness of the receiving side (the hardness of the material possessed by the terrain object TO), the density in the destruction range is rewritten if the hardness of the attacking side is greater, and neither the density nor the amount of damage in the destruction range is rewritten if the hardness of the receiving side is greater. When the hardness of the attacking side and the hardness of the receiving side are equal, the amount of damage to the voxels in the destruction range is increased, and the density of the voxel is rewritten when the amount of damage exceeds the allowable amount of the voxel (damage durability value due to the material). Furthermore, if the amount of damage to a voxel exceeds the allowable limit for that voxel, the density of that voxel may be set to 0 and the voxel may be deleted. The amount of damage to a voxel can also function as voxel data indicating the absence of terrain.

[0130] Then, as described above, the surface of the terrain object TO after its density has been rewritten (specifically, the surface newly exposed to the outside due to destruction) is updated for display by generating a new mesh. For example, based on the occurrence of an event in which the terrain object TO is destroyed, a new mesh is generated by recalculating the vertices of the mesh in the range that includes at least the voxels whose voxel data has been rewritten by the destruction. As an example, each vertex of the mesh is generated as shown in Figure 14. In this way, after voxel deletion, the terrain object TO may be deleted by generating a new mesh using an algorithm that recalculates the vertices of the mesh based on the density of each voxel between voxels where terrain does not exist and voxels where terrain exists. Then, the texture used to draw each face of the mesh is determined based on the voxel data, and the image of the destroyed terrain object TO is generated by mapping the determined texture to each face. Note that the range in which the mesh recalculation described above is performed may be a chunk (a group of voxels that becomes a processing unit consisting of a predetermined number of voxels) that contains the voxels whose voxel data has been rewritten. For example, by treating a 16x16x16 voxel as a single chunk and recalculating only the chunk containing the voxel whose data has been rewritten, the processing load can be reduced compared to recalculating the mesh of the entire game space. This range may be the voxel space where the voxel whose data has been rewritten is located, or it may be the entire terrain object TO that contains the voxel whose data has been rewritten. Alternatively, if there are no processing load issues, the mesh may be recalculated for the entire game space.

[0131] In the example shown in Figure 16, the player character PC is positioned outside the cave B formed in the terrain object TO. The virtual camera C is also positioned outside the terrain object TO based on the player character PC's position, and there are no other objects (e.g., terrain object TO) between the virtual camera C and the player character PC.

[0132] Figure 19 shows an example where a virtual camera C is positioned in a second state within a game space where a terrain object TO and a player character PC are set up. In the example shown in Figure 19, the player character PC has moved and is positioned inside a cave B formed in the terrain object TO. The virtual camera C also moves within the game space based on the position of the player character PC, but in the example shown in Figure 19, the virtual camera C is positioned outside the terrain object TO. Therefore, the terrain object TO exists between the virtual camera C and the player character PC, and the player character PC is obscured by the faces of the terrain object TO that are facing outwards from the perspective of the virtual camera C. In other words, in the example shown in Figure 19, the player character PC is obscured by the faces of the mesh that make up the terrain object TO that are visible to the virtual camera C.

[0133] Figure 20 shows an example where a virtual camera C is positioned in a third state within a game space where a terrain object TO and a player character PC are set. In the example shown in Figure 20, the player character PC has moved further to the back of the cave B formed in the terrain object TO. The virtual camera C also moves within the game space based on the position of the player character PC, and in the example shown in Figure 20, the virtual camera C is positioned inside the terrain object TO. Therefore, there is no surface facing the front side intervening between the virtual camera C and the player character PC. Note that the dashed lines in Figure 20 indicate that the player character PC and virtual camera C are positioned inside the terrain object TO.

[0134] In this embodiment, if the positional relationship between the player character PC and the surrounding terrain object TO in the game space does not satisfy the underground camera permission conditions, when the virtual camera C approaches the terrain object TO, avoidance control is performed to prevent the virtual camera C from being placed inside the terrain object TO. On the other hand, if the positional relationship satisfies the underground camera permission conditions, the virtual camera C is controlled without the avoidance control being performed. In other words, if the positional relationship satisfies the underground camera permission conditions, it is possible to place the virtual camera C inside the terrain object TO. Note that the terrain object TO that is the subject of the determination of the underground camera permission conditions and the terrain object TO that is subject to the avoidance control or in which the virtual camera C is allowed to be placed inside may be the same object or different objects.

[0135] Figure 21 illustrates an example of the range of motion of virtual camera C when the above-mentioned underground camera permission conditions are not met, and an example of the range of motion of virtual camera C when the above-mentioned underground camera permission conditions are met. As shown in the upper and lower figures of Figure 21, the range of motion of virtual camera C is the range within the game space based on the position of the player character PC (for example, an internal position such as the center of gravity of the player character PC or a position around the player character PC). For example, the range of motion is formed using a three-dimensional shape surface such as a long sphere (flat ellipsoid), an oblate sphere (flat ellipsoid), or a sphere (circular sphere) centered on the position of the player character PC. As an example, the range of motion is formed using a long sphere, an oblate sphere, or a sphere formed with the vertical direction of rotation in the game space passing through the position of the player character PC as the rotation direction, or a long sphere or an oblate sphere formed with the front-to-back direction of the player character PC in the game space passing through the position of the player character PC as the rotation direction. The virtual camera C can then move within the game space within the range of motion in response to user operation.

[0136] As shown in the upper diagram of Figure 21, the range of motion when the above underground camera permission conditions are not met is formed outside the terrain object TO. If a portion of the three-dimensional surface forming the range of motion overlaps with the terrain object TO, the surface of the three-dimensional object excluding the overlapping portion becomes the range of motion of the virtual camera C.

[0137] Furthermore, as shown in the lower diagram of Figure 21, when the above-mentioned underground camera permission conditions are met, the movable area is formed in a shape that overlaps with the interior of the terrain object TO, even if a part of the three-dimensional shape surface forming the movable area overlaps with the terrain object TO. As described above, since the virtual camera C can be moved and positioned within the game space along the movable area, by moving the virtual camera C into the movable area formed inside the terrain object TO, the virtual camera C can be made to function as an underground camera positioned inside the terrain object TO.

[0138] Furthermore, in cases where the above-mentioned permit conditions for underground cameras are not met, the size, orientation, and type of shape of the three-dimensional surface forming the movable area may be changed compared to the movable area when the permit conditions are not met. In addition, the virtual camera C may be able to move not only on the surface of the three-dimensional object forming the movable area, but also inside it. Moreover, the three-dimensional surface forming the movable area may be any other three-dimensional shape. For example, the three-dimensional surface forming the movable area may be a polyhedron, cylinder, elliptical cylinder, regular polygonal prism, cone, regular polygonal pyramid, or a three-dimensional object with a part of the above-mentioned three-dimensional object removed, or a three-dimensional object that is a deformed version of the above-mentioned three-dimensional object.

[0139] Furthermore, the range of motion of the virtual camera C described above conceptually explains the possible behaviors of the virtual camera C, and in actual control, the aforementioned 3D region does not necessarily need to be calculated and set in advance. For example, the position and orientation of the virtual camera C may be calculated each time based on the position of the player character PC. In this case, the distance from the player character PC to the virtual camera C is calculated each time based on the direction in which the virtual camera C is placed relative to the player character PC, and the position and orientation of the virtual camera C are set according to the said placement direction and distance. If the position of the virtual camera C coincides with the terrain object TO when the above underground camera permission conditions are not met, the position is changed to be outside of the terrain object TO. As an example, in the placement direction of the virtual camera C described above, the position of the virtual camera C is changed to the position closest to the terrain object C, which is outside of the terrain object C.

[0140] In this embodiment, the underground camera permission condition is set using the percentage of the area around the player character PC's position that is obscured by other objects, including terrain object TO. For example, the underground camera permission condition may be set based on the occlusion rate of other objects that obstruct the field of view in the up, down, left, right, front, and back directions as seen from the player character PC's position. As an example, the underground camera permission condition may be determined to be met if the occlusion rate is 50% or more.

[0141] Figure 22 shows an example of a view of the six sides (up, down, left, right, front, and back) taken from a position based on the player character PC. For example, the position based on the player character PC from which the above six sides are taken is set to a predetermined distance above the player character PC in the game space (for example, about 8m above). In the example in Figure 22, since the player character PC is positioned near the entrance of cave B, the top surface that is photographed is divided into terrain object TO and the sky in the game space, and is more than 50% obscured by other objects.

[0142] For example, in this embodiment, the six surfaces are photographed at regular intervals, and the occlusion rate is calculated as the ratio of pixels that do not have a depth value (z value) to the total number of pixels. If the calculated occlusion rate is greater than or equal to a threshold, it is determined that the positional relationship between the player character PC and the surrounding terrain object TO satisfies the underground camera permission conditions. By using such an occlusion rate, if the occlusion rate is high, it is considered that the player character PC is placed inside another object (for example, terrain object TO) and wants to observe other objects around it. Therefore, it is possible to appropriately determine whether visibility will improve by allowing the virtual camera C to be placed inside the other object in this situation.

[0143] The above occlusion rate is a parameter that indicates the extent to which the player character PC is occluded by terrain objects TO, etc., and is assumed to be occluded regardless of the distance from the player character PC to the occluding object. However, it may also be calculated based on the distance between the player character PC and the occluding object that is the subject. For example, pixels that are more than a predetermined distance away from the player character PC and the other object that is the subject (for example, pixels with a depth value (z value) of a predetermined value or higher) may be treated as unoccluded pixels when calculating the above occlusion rate. In this case, the occlusion rate is calculated as the ratio of pixels that are not more than a predetermined distance away from the player character PC and pixels with no depth value (z value) to the total number of pixels. By using such an occlusion rate, if the player character PC is occluded by other objects far away (for example, if it is placed in a wide open space), it can be considered to be in a state similar to if it is placed on the ground, and since it is conceivable that visibility would decrease if the virtual camera C were placed inside other objects, such a situation can be avoided.

[0144] Furthermore, the above occlusion rate may be calculated prioritizing some of the six surfaces mentioned above. As a first example, the above occlusion rate may be calculated prioritizing the horizontal surfaces (front, back, left, right) of the game space over the vertical surfaces (top, bottom). As another example, the above occlusion rate may be calculated using the four horizontal surfaces of the game space, excluding the two vertical surfaces. As yet another example, the above occlusion rate may be calculated by giving a lower contribution rate (weighting) to the two vertical surfaces of the game space than to the other four surfaces. By using such an occlusion rate, it is possible to avoid situations where visibility would be reduced if a virtual camera C were placed above the ceiling or below ground level when a player character PC is placed in a space with a ceiling but not much horizontal obstruction. As a second example, the above occlusion rate may be calculated using the four horizontal surfaces of the game space and the top surface of the game space, excluding the one downward surface of the game space. Since the downward direction, which corresponds to the ground in the game space, is almost always occluded, the calculation process can be simplified by excluding the bottom surface from the calculation of the occlusion rate. Furthermore, the method of calculating the occlusion rate by prioritizing some of the six surfaces mentioned above may be implemented in conjunction with the method of calculating the occlusion rate based on the distance to the subject as described above.

[0145] Furthermore, the occlusion rate may be calculated using only the terrain object TO as the object that is considered to be obscuring the player character PC. Also, the shooting positions of the six faces may be moved depending on the environment in which the player character PC is located. For example, if the player character PC is located in a position where there is another object nearby above, the shooting positions of the six faces may be moved to a position closer to the player character PC or to a position inside the player character PC (i.e., a position moved downward from a predetermined distance above the player character PC) in order to avoid the shooting positions overlapping with those other objects.

[0146] Next, we will describe the display images shown on the display 12 based on the images of the game space (virtual space images) as seen from each virtual camera C. Figure 23 is a diagram showing an example of a display image shown on the display 12 based on the image seen from the virtual camera C positioned in the first state. Figure 24 is a diagram showing an example of a display image shown on the display 12 based on the image seen from the virtual camera C positioned in the second state. Figure 25 is a diagram showing an example of a display image shown on the display 12 based on the image seen from the virtual camera C positioned in the third state.

[0147] In Figure 23, the player character PC is positioned outside of cave B, near the entrance to cave B formed in terrain object TO. The virtual camera C for generating the virtual space image is positioned outside of terrain object TO based on the player character PC's position, as described in the first state using Figure 16. Therefore, in the first state, there is no terrain object TO between the virtual camera C and the player character PC, and the faces of terrain object TO that are facing forward from the virtual camera C are visible on the side furthest from the player character PC from the virtual camera C's perspective. In this embodiment, when generating the game space image (virtual space image), backface culling is performed, which does not render faces that are facing backward from the virtual camera C (for example, faces of the mesh that make up terrain object TO that are facing backward from the virtual camera C), and hidden face removal is performed, which removes faces that are not visible from the virtual camera C. Therefore, as shown in Figure 23, the image of the game space as seen from the virtual camera C in the first state is an image of the entire player character PC, and an image of the surface of the terrain object TO that is facing the front side on the side furthest from the player character PC as seen from the virtual camera C, and a display image based on this image is displayed on the display 12.

[0148] In Figure 24, the player character PC is moving into the cave B formed in the terrain object TO, from its entrance. The virtual camera C, which generates the virtual space image, is positioned outside the terrain object TO based on the player character PC's position, as described in the second state using Figure 19. Therefore, in the second state, the terrain object TO exists between the virtual camera C and the player character PC, and the surface of the terrain object TO facing outwards is visible to the virtual camera C side of the player character PC. Also, from the perspective of the virtual camera C, the player character PC is obscured by the surface of the terrain object TO facing outwards, so the player character PC is not directly visible from the virtual camera C. In this embodiment, in order to confirm the position of the player character PC even in this state, the player character PC is displayed as a silhouette image (shown as a shaded area in Figure 24) in which the shadow of the player character PC is depicted as being projected through the surface of the terrain object TO. Therefore, as shown in Figure 24, the image of the game space as seen from the virtual camera C in the second state is an image in which the surface of the terrain object TO facing the front side on the side closer to the player character PC as seen from the virtual camera C is captured, and the entire player character PC is shown as a silhouette image that is transparent to the surface, and a display image based on this image is displayed on the display 12. Note that the above silhouette image may be an image in which the player character PC is displayed as is, transparent to the surface of the terrain object TO. In addition, if a thin terrain object TO of less than a predetermined thickness is interposed between the player character PC and the virtual camera C, the virtual space may be displayed with the terrain object TO transparent.

[0149] Here, if the positional relationship between the player character PC and the terrain object TO (another object) satisfies the above underground camera permission conditions, the virtual camera C may be automatically moved so that it is positioned inside the terrain object TO. For example, in the second state explained using Figure 19, if the positional relationship between the player character PC and the terrain object TO satisfies the above underground camera permission conditions, the virtual camera C, which is positioned outside the terrain object TO, may be forcibly positioned inside the terrain object TO so that it is closer to the player character PC. In this case, the virtual camera C may be automatically moved by reducing the range of motion of the virtual camera C set in the second state, or the virtual camera C may be automatically moved by temporarily moving the virtual camera C inside the range of motion of the virtual camera C set in the second state.

[0150] Furthermore, the process of automatically moving the virtual camera C inside the terrain object TO described above may be executed when certain conditions are met in addition to the above underground camera permission conditions. As an example of the first condition, if the above underground camera permission conditions are met and a terrain object TO of a certain thickness or greater is interposed between the player character PC and the virtual camera C, the virtual camera C may be automatically moved inside the terrain object TO. As an example of the second condition, if the state in which the virtual camera C is located outside the terrain object TO continues for a predetermined time or longer while the above underground camera permission conditions are met, the virtual camera C may be automatically moved inside the terrain object TO. As an example of the third condition, if the player character PC moves a predetermined distance or more while the virtual camera C is located outside the terrain object TO while the above underground camera permission conditions are met, the virtual camera C may be automatically moved inside the terrain object TO.

[0151] In Figure 25, the player character PC has moved further into the cave B formed in the terrain object TO and is positioned there. The virtual camera C for generating the virtual space image is positioned inside the terrain object TO based on the player character PC's position, as described in the third state using Figure 20. In the third state, although the terrain object TO exists between the virtual camera C and the player character PC, there are no faces of the terrain object TO that are facing outwards (for example, faces of the mesh that make up the surface of the terrain object TO or the surface of cave B that are visible to the virtual camera C). In this embodiment, even if the inside of the terrain object TO exists between the virtual camera C and the player character PC, only the mesh of the surface of the terrain object TO is displayed, so the existing terrain object TO is not displayed by the virtual camera C. Furthermore, among the meshes that make up cave B, the meshes closer to virtual camera C exist between virtual camera C and the player character PC, but most of them are facing away from virtual camera C and are therefore not displayed. As a result, the player character PC, which has moved to the back of cave B, is captured in a way that it is visible to virtual camera C. Therefore, as shown in Figure 25, the image of the game space as seen from virtual camera C in the third state described above captures the entire player character PC, and the surface of cave B, which is facing the front side on the side furthest from the player character PC as seen from virtual camera C, is captured in this image, and a display image based on this image is displayed on display 12.

[0152] Furthermore, in this embodiment, when the virtual camera C is positioned inside the terrain object TO, a display change process is performed to change the display image for display on the display 12. As described above, when the positional relationship between the player character PC and the terrain object TO satisfies the permission conditions, the virtual camera C is allowed to be positioned inside the terrain object TO without performing avoidance control to prevent the virtual camera C from being positioned inside the terrain object TO. Then, when the virtual camera C moves in the game space and it is determined that the virtual camera C is positioned inside the terrain object TO, the above display change process is performed. This determination may be made based on whether the position of the virtual camera C itself is inside the terrain object TO, but as an example, as shown in Figure 26, when all four corner points P1 to P4 of the near-clip plane of the virtual camera C are positioned inside the terrain object TO, it is determined that the virtual camera C is positioned inside the terrain object TO. As another example, when at least two of the four corner points P1 to P4 of the near-clip plane of the virtual camera C are positioned inside the terrain object TO, it is determined that the virtual camera C is positioned inside the terrain object TO.

[0153] For example, as part of the display change processing described above, post-processing is performed on the image of the game space as seen from the virtual camera C (virtual space image) to generate the display image shown on the display 12. For example, post-processing is performed by applying an effect (filter) to the frame buffer used to render the virtual space image as seen from the virtual camera C.

[0154] As a first example of the display change processing described above, a post-processing is performed to reduce the visibility of the edges of the display image. For example, in the example of the display image shown in Figure 25, a dimmed area F is formed by darkening the peripheral area outside the rounded rectangular area formed in the center of the display image. Note that the shape of the area formed in the center of the display image does not have to be a rounded rectangle; it may be an ellipse, a circle, a chamfered rectangle, a rhombus, an oval, a polygon, or other shapes.

[0155] As a second example of the display change processing described above, post-processing is performed to apply fog or blurring so that the visibility of objects is reduced the further they are from the virtual camera C. For example, the hatched area showing the terrain object TO in Figure 25 is an area where the display has changed because stronger fog is applied the further away it is from the virtual camera C.

[0156] Figure 27 shows an example of a display image with a fog effect applied based on the distance from the virtual camera C. In Figure 27, the virtual camera C, positioned inside the terrain object TO, generates an image of the game space as seen from the side of the player character PC positioned inside the cave B. Note that in the example display image shown in Figure 27, the dimming region F is omitted from the illustration for clarity.

[0157] Within the terrain object TO, in addition to cave B, several cavities C1 to C4 are formed. Specifically, cavities C1, C2, C3, and C4 are formed within the terrain object TO in order of proximity to the virtual camera C. The player character PC is placed inside cave B, and virtual object OBJ is placed inside cavities C1 and C2, respectively. As described above, in the processing of this embodiment, the mesh of the terrain object TO whose surface is visible from the virtual camera C is the display target. Therefore, among the meshes that make up the caves and cavities within the terrain object TO, the drawing process is performed to display the mesh whose surface is visible from the virtual camera C. In other words, by performing the drawing process described above without any special processing such as detecting caves and cavities within the field of view of the virtual camera C or forming cross-sections that allow caves and cavities to be directly seen from the virtual camera C, a display image is generated that shows not only the inside of cave B but also the surrounding cavities, as illustrated in Figure 27. Furthermore, within the terrain object TO, in addition to the cave B, cavities C1-C4, player character PC, and virtual object OBJ mentioned above, there may be other cavities and other objects located far from the virtual camera C, but these are not visible in the display image due to the fog effect described later. Also, if the virtual object OBJ has the function of being a target for the player character PC, it may be placed in the virtual space within the terrain object TO with a conspicuous color, brightness, or luminance.

[0158] Cavity C1 has a rectangular parallelepiped shape formed by six inner walls (surfaces) and is located within the terrain object TO closest to virtual camera C. The virtual object OBJ is placed inside cavity C1. In the display image, four of the meshes that make up the six inner walls (surfaces) of cavity C1 are shown, with the front side of the mesh facing the virtual camera C. Since cavity C1 is located in the same position as cave B where the player character PC is placed, and is closest to virtual camera C, no fog effect is applied, and the images of the four faces of cavity C1 and the virtual object OBJ that are visible on the virtual camera C side are displayed as is.

[0159] Cavity C2 has a rectangular parallelepiped shape formed by six inner walls (surfaces) and is located within terrain object TO, which is further away from cavity C1 as viewed from virtual camera C. A virtual object OBJ is placed inside cavity C2. In the display image, four of the meshes constituting the six inner walls (surfaces) of cavity C2 are displayed, with the front side of the mesh facing the virtual camera C. Cavity C2 is given a weak fog effect based on its distance from virtual camera C. For example, in the fog processing of this embodiment, the fog effect is applied to the images of the four faces of cavity C2 and the virtual object OBJ by blending colors according to the distance (for example, depth value (z value)) (for example, increasing the RGB values ​​so that it becomes browner as the distance increases). In addition, in the fog processing of this embodiment, the color of the edges (for example, the outer perimeter of the displayed cavity C2) may be changed to a predetermined color (for example, orange) for emphasis. As a result, a weak fog effect is applied to the images of the four faces of the cavity C2 and the virtual object OBJ that appear on the virtual camera C side, and a display change process is performed that highlights the edges of each of the four faces, and the display image with this display change process is displayed.

[0160] Cavity C3 has a rectangular parallelepiped shape formed by six inner walls (surfaces) and is located within terrain object TO, which is farther away from cavities C1 and C2 as viewed from virtual camera C. In the display image, four of the meshes constituting the six inner walls (surfaces) of cavity C3, with the front side of the mesh facing the virtual camera C, are displayed. Cavity C3 is given a stronger fog effect than cavity C2 based on its distance from virtual camera C. Although a virtual object OBJ may be placed inside cavity C3, it is not visible in the display image due to the strong fog effect. By applying the fog processing to cavity C3 so that it is given a stronger fog effect than cavity C2, the images of the four faces of cavity C3 with the front side of the mesh facing the virtual camera C are given a strong fog effect, and a display change process is performed to highlight the outer edges of cavity C3, and the display image with this display change process is displayed.

[0161] Cavity C4 has a rectangular parallelepiped shape formed by six inner walls (surfaces) and is located within terrain object TO, which is farther away from cavities C1, C2, and C3 as viewed from virtual camera C. In the display image, four of the meshes constituting the six inner walls (surfaces) of cavity C4 are displayed, with the front side of the mesh facing towards virtual camera C. Cavity C4 is given a considerably stronger fog effect than cavities C2 and C3, based on its distance from virtual camera C. Although a virtual object OBJ may be placed inside cavity C4, it is not visible in the display image due to the considerably strong fog effect. By applying the fog processing to cavity C4 so that it is given a stronger fog effect than cavity C3, the images of the four faces of cavity C3 with the front side of the mesh facing towards virtual camera C are given a considerably strong fog effect, and a display change process is performed to highlight the outer edge of cavity C3. As a result, in the example of Figure 27, the display image is shown in which only the edges are visible.

[0162] In this way, by applying a fog effect based on the distance from the virtual camera C, it becomes possible to grasp the sense of distance to an object. Furthermore, by highlighting edges during the fog process, even if the surface of the object itself is not visible, only the outline can be displayed, making it easier to see that there is a cavity. In addition, even if the virtual object placed inside the cavity is placed far away to avoid showing it, the existence of the cavity can be made visible, presenting it as a target for the player character PC.

[0163] In the second example of the display change processing described above, in addition to the fog processing described above, a process to add a predetermined pattern may also be performed. For example, when the display change processing is performed, a checkerboard pattern or geometric pattern of the same or different colors as the colors blended in the fog processing may be added.

[0164] As a third example of the above display change processing, a post-process is performed to change the display manner of at least a portion of the non-front side of the terrain object TO, which is the part of the surface that is facing the front side as seen from the virtual camera C and was not rendered (for example, the background part of the game space).

[0165] Figure 28 shows an example of a display image that changes the display mode of the background portion of the game space. In the upper part of Figure 28, the player character PC and virtual camera C are positioned outside the terrain object TO. In the game space outside the terrain object TO, the field which is the outside world of the terrain object TO, and the ground object OBJg and smoke effect E are displayed in the distance from the virtual camera C, and a display image with a background image (for example, a blue sky) is displayed behind the ground object OBJg and effect E.

[0166] In the lower diagram of Figure 28, the player character PC and virtual camera C have moved from their game space positions shown in the upper diagram of Figure 28 and are positioned inside the terrain object TO. A portion of the surface of cave B is displayed as the face of the mesh that makes up the surface of terrain object TO and cave B, with the front side of the mesh facing towards virtual camera C. The faces of the field and ground object OBJg that make up the outside world of terrain object TO, which are facing outwards (for example, the surface of the field and the surface of the ground object OBJg that are visible to virtual camera C) are also displayed. The background image is displayed in the parts of the field, ground object OBJg, and terrain object TO that are not drawn as faces facing outwards, corresponding to the non-front sides. Note that in the example of the display image shown in the lower diagram of Figure 28, the dimming region F is omitted from the illustration to make the example of the image easier to understand.

[0167] When a virtual camera C is placed inside a terrain object TO, the fog processing described in the second example of the display change processing above is performed, and a fog effect is applied to the images of the terrain object TO, the field surrounding the terrain object TO, and ground objects OBJg, etc., according to the distance from the virtual camera C.

[0168] On the other hand, the background image, which is the non-front side, has an infinite distance from the virtual camera C (for example, no depth value), and a display change process is performed on such images to change them to a predetermined display mode. In this embodiment, as a third example of the display change process, for images without a depth value, such as the background image, a display image is shown that has been filled with a dark gray to black color. Also, the effect E shown in the upper part of Figure 28 is an image without a depth value. In this embodiment, the same dark gray to black coloring process is performed on the image of effect E as on the background image, so in the lower part of Figure 28, a display image with a changed appearance is shown so that effect E is not displayed.

[0169] Thus, in this third example of the display change processing, the display of at least a portion of the non-front side (for example, the background of the game space or the area where effect E is displayed) is changed, making it clear that the virtual camera C is located inside the terrain object TO. Note that the color used to fill the non-front side can be any color darker than the color of the background image displayed when the virtual camera C is located outside the terrain object TO (for example, the color of a bright sky). By filling it with a dark color in this way, it is possible to prevent the display of an incongruous image, such as a bright sky being displayed as the background image even though the virtual camera C is located inside the terrain object TO.

[0170] In the third example of the display change process described above, images without depth values, such as Effect E, are hidden in the display image by being filled with dark gray to black by the display change process. Therefore, by drawing the image such as Effect E before the fill process, only the area where the fill is performed will be hidden, and the image will be displayed in the area where the fill is not performed. On the other hand, if it is necessary to display an image in the display image that is hidden at least in part by the display change process, the part that was hidden by the display change process may be redrawn after the display change process to redisplay the image in the display image.

[0171] Furthermore, while the above explanation used an example of performing display change processing by performing post-processing on the virtual space image as seen from virtual camera C, display change processing may also be performed by changing the virtual space as seen from virtual camera C. For example, in the first example of the above display change processing, the visibility of the edges of the display image may be reduced by placing change objects corresponding to the dimming area F at the edge of the field of view of virtual camera C. In the second example of the above display change processing, the visibility of objects may be reduced according to the distance from virtual camera C by placing change objects for smoke, fog, and smog in the virtual space at a predetermined distance or more from virtual camera C. Alternatively, the visibility of objects may be reduced according to the distance from virtual camera C by changing the color, brightness, luminance, size, shape, or presence of each object based on the distance from virtual camera C, or by changing the distance from virtual camera C at which the change is performed (for example, by shortening the distance from virtual camera C at which the change is performed compared to the case where no display change processing is performed). In the third example of the display change processing described above, the display of at least a portion of the non-front side may be changed by changing the color, brightness, and luminance of the background image or effect E in the virtual space, or by removing effect E from the virtual space.

[0172] Furthermore, if the display change process described above is initiated when the virtual camera C moves from outside to inside the terrain object TO, a fade-in process may be performed on the underground camera representation so that it gradually transitions from a state where the display change process is not performed to a state where the display change process has been performed. Also, if the display change process described above is terminated when the virtual camera C moves from inside to outside the terrain object TO, a fade-out process may be performed on the underground camera representation so that it gradually transitions from a state where the display change process is being performed to a state where the display change process is not being performed.

[0173] Next, with reference to Figures 29 to 31, we will explain a specific example of game processing that serves as an example of information processing in game system 1.

[0174] Figure 29 shows an example of various data used for information processing in Game System 1. As shown in Figure 29, Game System 1 stores game program Pa, voxel space data Da, voxel object data Db, mesh data Dc, operation data Dd, player character data De, virtual camera data Df, destruction range data Dg, occlusion rate data Dh, virtual space image data Di, display image data Dj, and image data Dk, etc. Game program Pa, voxel space data Da, and image data Dk are data that are stored in Game System 1 in advance before game processing is executed. Game program Pa and voxel space data Da are stored, for example, on a storage medium installed in slot 23 of the main unit 2. Voxel object data Db, mesh data Dc, operation data Dd, player character data De, virtual camera data Df, destruction range data Dg, occlusion rate data Dh, virtual space image data Di, and display image data Dj are data that are generated during the execution of game processing. Voxel object data Db, mesh data Dc, operation data Dd, player character data De, virtual camera data Df, destruction range data Dg, occlusion rate data Dh, virtual space image data Di, and display image data Dj are stored, for example, in the DRAM 85 of the main unit 2.

[0175] Game program Pa is a game program for executing the game processing in this embodiment (specifically, the game processing shown in Figures 30 and 31).

[0176] Voxel space data Da is data that defines the voxels to be placed in the game space. Specifically, voxel space data Da indicates the length of one side of the voxel and the direction of each side of the voxel in the game space. In addition, if voxels are placed in only a part of the game space, voxel space data Da may also include data indicating the location and size of the space in which the voxels are placed (i.e., the voxel space) (i.e., data indicating the range in the game space in which the voxels are placed).

[0177] The voxel object data Db is data that represents voxel objects placed in the game space. Specifically, the voxel object data Db includes voxel data Db1 for each unit region, covering part or all of the game space.

[0178] Mesh data Dc is data that describes the mesh assigned to a voxel object placed in game space. Mesh data Dc includes, for example, data indicating the position of each vertex in the mesh.

[0179] The operation data Dd is data acquired as appropriate from the left controller 3 and / or the right controller 4 and the main unit 2, respectively. As described above, the data acquired from the left controller 3 and / or the right controller 4 and the main unit 2 includes information about input from each input unit (specifically, each button, analog stick, and touch panel) (specifically, information about operation). In this embodiment, data is acquired from the left controller 3 and / or the right controller 4 and the main unit 2, and the operation data Dh is updated as appropriate using the acquired data. The update cycle of the operation data Dh may be updated every frame, which is the cycle of processing executed by the game system 1 described later, or it may be updated every time the above data is acquired.

[0180] Player character data De is data that indicates the position and posture of the player character PC placed in the game space, as well as their actions and state in the game space.

[0181] The virtual camera data Df is data that indicates the placement position, orientation, and state of the virtual camera C placed in the game space.

[0182] The destruction range data Dg is data that indicates the destruction range set when a terrain object TO is destroyed by a player character PC.

[0183] The occlusion rate data Dh indicates the percentage of the area around the player character PC's position that is occluded by other objects, including terrain objects TO.

[0184] The virtual space image data Di represents the image of the game space as seen from the virtual camera C, and functions as a frame buffer for rendering the game space image. The display image data Dj represents the image to be displayed on a display device (e.g., display 12).

[0185] Image data Dk is data that represents images such as player character PCs, other objects, various effects, fields, and background images that are placed in the game space.

[0186] In addition to the data shown in Figure 29, Game System 1 also stores the aforementioned property information and texture information data, etc., as data that is stored in Game System 1 before the execution of game processing.

[0187] Figure 30 is a flowchart showing an example of the game processing flow executed by the game system 1. Figure 31 is a subroutine showing an example of the underground camera switching process in step S12 of the flowchart shown in Figure 30. In this embodiment, the series of processes shown in Figures 30 and 31 are performed by the processor 81 executing the game program. The timing at which the game processing shown in Figures 30 and 31 begins is arbitrary, but as an example, it begins when the user gives an instruction to start the game while the game program is running.

[0188] In this embodiment, the processor 81 of the main unit 2 executes the game program stored in the game system 1, thereby executing the processing of each step shown in Figures 30 and 31. However, in other embodiments, some of the processing of each step may be executed by a processor other than the processor 81 (for example, a dedicated circuit). Also, if the game system 1 can communicate with other information processing devices (for example, a server), some of the processing of each step shown in Figures 30 and 31 may be executed by the other information processing device. That is, each of the processing shown in Figures 30 and 31 may be executed by the cooperation of multiple information processing devices, including the main unit 2. Furthermore, the processing of each step shown in Figures 30 and 31 is merely an example, and the processing order of each step may be changed, or other processing may be executed in addition to (or instead of) each step, as long as similar results can be obtained.

[0189] Furthermore, the processor 81 executes the processing of each step shown in Figures 30 and 31 using memory (for example, DRAM 85). That is, the processor 81 stores the information (in other words, data) obtained by each processing step in memory, and when it is necessary to use that information in subsequent processing steps, it reads the information from memory and uses it.

[0190] In Figure 30, the processor 81 sets the voxel objects in the game space in their initial state (step S1) and proceeds to the next step. Specifically, the processor 81 acquires voxel data indicating the arrangement of the voxel objects in their initial state, and stores (in other words, writes) part or all of the acquired voxel data to the DRAM 85 as voxel object data Db. The voxel data indicating the arrangement of the voxel objects in their initial state is stored, for example, in a storage medium installed in slot 23 of the main unit 2.

[0191] The voxel data written to the DRAM 85 as voxel object data may be a portion of the voxel data used to generate game images from the voxel data covering the entire range of the game space. The processor 81 may, for example, generate an image of an object using voxel data only for a portion of the game space (for example, a range within a predetermined distance from the virtual camera's position). In this case, the voxel object data Db may include the voxel data within that range. Furthermore, when voxel data for a portion of the game space is written, the same processing as in step S1 is executed at an appropriate timing during the execution of the series of processes in steps S3 to S13 described later (for example, when the virtual camera's position moves by a predetermined distance or more).

[0192] Next, the processor 81 generates a mesh for the voxel object (step S2), proceeds to the next step to start the game, and repeatedly executes steps S3 to S12 during the game. The mesh is generated according to the method described above. Here, the processor 81 generates the mesh based on the voxel object data stored in the DRAM 85. Through the process of step S2 above, voxel objects such as terrain object TO are constructed in the game space.

[0193] Next, the processor 81 acquires data corresponding to user operations from the left controller 3, the right controller 4, and / or the main unit 2, updates the operation data Dh (step S3), and proceeds to the next step.

[0194] Next, the processor 81 controls the actions of the player character PC that appears in the game space (step S4) and proceeds to the next step. For example, the processor 81 controls the actions of the player character PC based on the operation data acquired in step S3 and updates the player character data De. Also, if a character other than the player character PC is placed, the processor 81 controls the actions of that character based on an algorithm defined in the game program.

[0195] Next, the processor 81 determines whether the erasure condition for erasing at least a portion of the voxel object has been met (step S5). For example, if the player character PC strikes the terrain object TO, the processor 81 sets the area where the strike occurred and its surroundings as the destruction range, updates the destruction range data Dg, destroys the terrain object TO (voxel object) within the destruction range, and erases the destroyed portion. As an example, to indicate that the destruction range has been destroyed, the density value indicated by the voxel data of at least some of the voxels within the destruction range is set to 0, thereby erasing the terrain object TO within the destruction range. Therefore, if the voxels of the voxel object are included within the destruction range caused by the player character PC's strike, the processor 81 makes a positive determination in step S5. Then, if the erasure condition is met, the processor 81 proceeds to step S6. On the other hand, if the erasure condition is not met, the processor 81 proceeds to step S8.

[0196] In step S6, the processor 81 updates the voxel data for the voxel objects that satisfy the erasure conditions and proceeds to the next step. For example, the processor 81 updates the voxel data Db1 corresponding to each voxel by changing the voxel density of the voxels in the area where the player character PC has made a hit and the voxels in the surrounding area, so that at least a portion of the voxel objects that satisfy the erasure conditions are erased. The processor 81 also erases terrain objects TO in the voxels surrounding the area to be erased (for example, the area affected by the hit) by decreasing the density of the voxels surrounding the area to be erased (however, it must be 0 or greater). Specifically, the processor 81 updates the voxel object data Db stored in the DRAM 85 to change the density data for the voxel data of the area to be erased and the voxels surrounding it. The processor 81 may also update the density data so that the density is less than the above-mentioned reference value. For example, the processor 81 may set the density of voxels in the area (destruction range) that has been struck by the player character PC to 0, and reduce the density of voxels in the surrounding area by a predetermined value.

[0197] Next, the processor 81 updates the mesh for the voxel objects whose voxel data was modified in step S6 (step S7), and proceeds to step S8. That is, the processor 81 generates meshes for voxel objects whose deletion conditions are met based on the updated voxel object data Db from step S6. This allows the mesh of terrain object TO to be dynamically changed during the game. The processor 81 also updates the mesh data Dc stored in DRAM 85 to reflect the newly generated mesh.

[0198] In step S8, the processor 81 performs occlusion rate calculation processing and proceeds to the next step. For example, the processor 81 acquires images of the game world from six sides (top, bottom, left, right, front, and back) taken from a shooting position based on the player character PC's position, calculates the occlusion rate of the player character PC based on these images, and updates the occlusion rate data Dh. In the processing in step S8, the processing may be performed on one of the six sides for each frame, and then in subsequent frames, processing using the overall occlusion rate may be performed. The method for calculating the occlusion rate is the same as the calculation method explained using Figure 22, so a detailed explanation is omitted here.

[0199] Next, the processor 81 determines whether the occlusion rate calculated in step S8 satisfies the underground camera permission conditions (step S9). For example, if the occlusion rate calculated in step S8 is greater than or equal to a threshold, the processor 81 determines that the positional relationship between the player character PC and the surrounding terrain object TO satisfies the underground camera permission conditions. If the occlusion rate does not satisfy the underground camera permission conditions, the processor 81 proceeds to step S10. On the other hand, if the occlusion rate satisfies the underground camera permission conditions, the processor 81 proceeds to step S12.

[0200] In step S10, the processor 81 operates the virtual camera C within the range of ground movement and proceeds to the next step. For example, the processor 81 refers to the player character data De to calculate the placement distance from the player character PC based on the direction in which the virtual camera C is positioned relative to the player character PC, and sets the position and direction of the virtual camera C based on the said placement direction and placement distance. Then, if the set position overlaps with the terrain object TO, the processor 81 changes the position to be outside the terrain object TO. As a result, the virtual camera C operates within the range of ground movement. Here, the ground movement range is the movement range explained using the upper diagram of Figure 21, and is the surface of the solid excluding the part that overlaps with the terrain object TO. Based on the user operation indicated by the operation data Dd, the processor 81 operates the virtual camera C within the range of ground movement and updates the virtual camera data Df.

[0201] Next, the processor 81 generates a display image based on a game image representing the game space and displays it on a display device (step S11), and proceeds to step S13. For example, the processor 81 generates a game space including voxel objects (terrain object TO), player character PC, other objects (e.g., other characters), effects, and background, based on voxel space data Da, voxel object data Db, mesh data Dc, player character data De, and image data Dk, etc. The image of the voxel object is generated using the voxel object data Db and mesh data Dc according to the method described above. The image of the player character PC is generated using the player character data De. The processor 81 also places a virtual camera C in the game space based on virtual camera data Df, generates a game image as seen from the virtual camera C, and stores it in the virtual space image data Di. If at least a part of the player character PC is obscured by the surface of the terrain object TO facing forward, the obscured part of the player character PC is generated as a silhouette image. The processor 81 then generates a display image based on the game image, stores it in the display image data Dj, and displays the generated display image on the display device. If a negative result is obtained in step S9 during the game, the process in step S11 is repeatedly executed at a rate of once every predetermined time (for example, 1 frame time).

[0202] On the other hand, if it is determined in step S9 that the shielding ratio does not meet the underground camera permit conditions, the processor 81 performs underground camera switching processing (step S12) and proceeds to step S13. The underground camera switching processing performed in step S12 will be explained below with reference to Figure 31.

[0203] In Figure 31, the processor 81 operates the virtual camera C within the range of underground movement (step S81) and proceeds to the next step. For example, the processor 81 refers to the player character data De to calculate the placement distance from the player character PC based on the direction in which the virtual camera C is placed relative to the player character PC, sets the position and direction of the virtual camera C based on the placement direction and placement distance, and does not change the position even if the set position overlaps with the terrain object TO. As a result, the virtual camera C operates within the range of underground movement. Here, the underground movement range is the movement range explained using the lower diagram in Figure 21, and even if it overlaps with the terrain object TO, it takes the shape of overlapping with the interior of the terrain object TO. Based on the user operation indicated by the operation data Dd, the processor 81 operates the virtual camera C within the range of underground movement and updates the virtual camera data Df. Note that in the processing in step S81 above, if the virtual camera C is located outside the terrain object TO, the virtual camera C may be forcibly moved so that it is located inside the terrain object TO.

[0204] Next, the processor 81 determines whether all four corner points P1 to P4 of the near-clip plane of the virtual camera C are located inside the terrain object TO (step S82). If all four corner points P1 to P4 of the near-clip plane of the virtual camera C are located inside the terrain object TO, the processor 81 proceeds to step S83. On the other hand, if any of the four corner points P1 to P4 of the near-clip plane of the virtual camera C are located outside the terrain object TO, the processor 81 proceeds to step S88.

[0205] In step S83, the processor 81 generates a game image (virtual space image) representing the game space and proceeds to the next step. For example, the processor 81 generates a game space including voxel objects (terrain object TO), player character PC, other objects (e.g., other characters), effects, and background, based on voxel space data Da, voxel object data Db, mesh data Dc, player character data De, and image data Dk, etc. The image of the voxel object is generated using the voxel object data Db and mesh data Dc according to the method described above. The image of the player character PC is generated using the player character data De. The processor 81 also places a virtual camera C in the game space based on virtual camera data Df, generates a game image as seen from the virtual camera C, and stores it in the virtual space image data Di. If at least a part of the player character PC is obscured by the surface of the terrain object TO facing forward, the obscured part of the player character PC is generated as a silhouette image.

[0206] Next, processor 81 performs fog processing (step S84) and proceeds to the next step. For example, processor 81 performs a post-processing step in which it applies a fog effect to the game space image (virtual space image) stored in the virtual space image data Di based on the distance from the virtual camera C. Note that the processing performed in step S84 is the same as the fog processing explained using Figure 27, so a detailed explanation is omitted here.

[0207] Next, the processor 81 performs background processing (step S85) and proceeds to the next step. For example, the processor 81 performs a post-processing on the image of the game space (virtual space image) stored in the virtual space image data Di, changing the display manner of at least a portion of the non-front side that is not drawn in the terrain object TO (for example, the background part of the game space or the part where effect E is displayed). Note that the processing performed in step S85 is the same as the processing to change the display manner explained using Figure 28, so a detailed explanation is omitted here.

[0208] Next, the processor 81 performs peripheral dimming (step S86) and proceeds to the next step. For example, the processor 81 performs a post-processing on the game space image (virtual space image) stored in the virtual space image data Di, reducing visibility by dimming the edges of the display area to create a dimmed area F (see Figure 25). Then, the processor 81 updates the display image data Dj using the game space image that has undergone the post-processing steps S84 to S86.

[0209] Next, the processor 81 performs the process of displaying the display image stored in the display image data Dj on the display device (step S87), and then terminates the processing by the subroutine. If a positive result is obtained in step S82 during the game, the processing in steps S83 to S87 is repeatedly executed at a rate of once every predetermined time (for example, 1 frame time).

[0210] On the other hand, if in step S82 it is determined that any of the four corner points P1 to P4 of the near-clip surface of the virtual camera C is located outside the terrain object TO, the processor 81 generates a display image based on the game image representing the game space and displays it on the display device (step S88), and terminates the processing by the subroutine. Note that the processing in step S88 is the same as the processing in step S11, so a detailed explanation is omitted here.

[0211] Returning to Figure 30, in step S13, the processor 81 determines whether or not to terminate the game. Conditions for terminating the game process in step S13 include, for example, when the conditions for terminating the game process are met, or when the user performs an operation to terminate the game process. If the game process is not terminated, the processor 81 returns to step S3 and repeats the process, and if the game process is terminated, it terminates the process according to the flowchart. From there, the series of processes from steps S3 to S13 are repeatedly executed until it is determined in step S13 that the process should be terminated.

[0212] Thus, in this embodiment, a virtual camera C can be positioned inside the terrain object TO based on the position of the player character PC, thereby improving the visibility of the displayed image according to the player character PC's situation. Furthermore, in this embodiment, since the display image change process based on the game space image is performed in response to the virtual camera C being positioned inside the terrain object TO, an image with appropriate rendering representation can be displayed even when the virtual camera C is positioned inside the terrain object TO.

[0213] In the above description, if the positional relationship between the player character PC and the surrounding terrain object TO satisfies the underground camera permission conditions, the virtual camera C is controlled without avoidance control to prevent the virtual camera C from being placed inside the terrain object TO. However, the presence or absence of such avoidance control may be switched by other means. For example, the system may be configured to switch whether or not to perform the avoidance control in response to an operation by the user to select whether or not to perform the avoidance control.

[0214] Furthermore, in conventional games, virtual cameras can sometimes become buried underground due to bugs or other issues unintended by the developers. This is an example of how avoidance controls that prevent virtual cameras from becoming buried can sometimes fail. The present invention does not assume such accidental phenomena of virtual cameras becoming buried underground, but rather intentionally allows virtual cameras to be placed inside terrain objects TO based on whether or not the above underground camera permission conditions are met, and thus possesses entirely different and new technical features.

[0215] Furthermore, the terrain object TO in which the virtual camera C may be placed does not have to be a voxel object. The same effect can be obtained even if the virtual camera C is placed inside a terrain object TO that is set based on other data formats such as polygons.

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

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

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

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

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

[0221] Although the present invention has been described in detail above, the above description is merely illustrative in all respects and is not intended to limit its scope. Needless to say, various improvements and modifications can be made without departing from the scope of the present invention. Furthermore, those skilled in the art will understand from the description of specific embodiments of the present invention that an equivalent scope can be implemented based on the description of the present invention and common technical knowledge. In addition, it should be understood that the terms used herein are used in the sense commonly used in the art unless otherwise specified. Accordingly, unless otherwise defined, all technical terms used herein have the same meaning as commonly understood by those skilled in the art to which the present invention pertains. In case of any conflict, this specification (including definitions) shall prevail. [Industrial applicability]

[0222] As described above, the present invention can be used as an information processing program, information processing system, information processing device, and information processing method, etc., capable of displaying images with improved visibility according to the status of the player character. [Explanation of Symbols]

[0223] 1… Information processing system 2…Main unit 3…Left controller 4…Right controller 11… Housing 12…Display 13…Touch panel 32, 52... Analog stick 42, 64… terminals 81… Processor 82…Network Communications Department 83... Controller Communication Unit 85…DRAM 101, 111... Communication Control Unit

Claims

1. An information processing program executed in a computer of an information processing device, The aforementioned computer, A determination means for determining whether the positional relationship between a player character in a virtual space and the surrounding terrain objects satisfies the permission conditions, A virtual camera control means that, when the virtual camera approaches the terrain object if the positional relationship does not satisfy the permission conditions, performs avoidance control to prevent the virtual camera from being placed inside the terrain object, and controls the virtual camera without performing such avoidance control when the positional relationship satisfies the permission conditions. A terrain drawing means that draws the faces of the terrain object that are facing the virtual camera, An information processing program that functions as an image output means for performing a process of outputting a display image based on an image of the virtual space including the terrain objects to a display device.

2. The information processing program according to claim 1, wherein the determination means determines that the positional relationship satisfies the permission condition when the proportion of the area around the position based on the player character being obscured by other objects, including the terrain object, is greater than or equal to a threshold.

3. The information processing program according to claim 1, wherein the determination means determines whether the positional relationship satisfies the permission conditions based on the distance between the player character and other objects, including the terrain object.

4. The information processing program according to claim 1, wherein the determination means prioritizes the horizontal positional relationship over the vertical positional relationship of the virtual space to determine whether the positional relationship satisfies the permission conditions.

5. An internal determination means for determining whether the virtual camera is located inside the terrain object, The information processing program according to any one of claims 1 to 4, further comprising the functioning of the computer as a display change means for performing a display change processing such that the display image changes when it is determined that the virtual camera is located inside the terrain object.

6. The information processing program according to claim 5, wherein the display changing means performs post-processing on the image in which the virtual space including the terrain objects is drawn as the display changing process.

7. The information processing program according to claim 5, wherein the display change means places a change object in the virtual space as the display change processing.

8. The information processing program according to claim 5, wherein the display changing means reduces the visibility of an object located far from the virtual camera as the display changing process.

9. The information processing program according to claim 8, wherein the display changing means applies fog as the display changing process such that the visibility of the object decreases the further away it is from the virtual camera.

10. The information processing program according to claim 5, wherein the display changing means changes the display mode of at least a portion of the non-front portion, which is the portion of the faces constituting the terrain object in which the front-facing faces were not drawn, as the display changing process.

11. The information processing program according to claim 10, wherein the display changing means changes the display manner of at least a part of the non-front portion by darkening the background color of the virtual space as the display changing process.

12. The information processing program according to claim 10, wherein the display changing means changes the display manner of the effect in the virtual space so that the effect is not displayed in the non-front portion by the display changing process.

13. The information processing program according to claim 8, wherein the display changing means causes the contour of a cavity inside the terrain object to be highlighted as the display changing process.

14. The information processing program according to claim 5, wherein the display changing means reduces the visibility of the edges of the display image as the display changing process.

15. The information processing program according to claim 5, wherein the internal determination means determines whether the virtual camera is located inside the terrain object based on whether the four corners of the near-clip surface of the virtual camera are located inside the terrain object.

16. The information processing program according to claim 1, wherein the virtual camera control means automatically moves the virtual camera so that it is positioned inside the terrain object when the positional relationship satisfies the permission conditions.

17. The information processing program according to claim 1, further comprising the functioning of the computer as a transparency display means for displaying the player character so that it is transparent to the surface when the player character is obscured by a surface of the terrain object that is facing outwards, as viewed from the virtual camera.

18. The information processing program according to claim 1, further comprising the computer functioning as a player character action control means for causing the player character to perform an action that destroys and / or deforms at least a part of the terrain object based on user input.

19. A determination means for determining whether the positional relationship between a player character in a virtual space and the surrounding terrain objects satisfies the permission conditions, A virtual camera control means that, when the virtual camera approaches the terrain object if the positional relationship does not satisfy the permission conditions, performs avoidance control to prevent the virtual camera from being placed inside the terrain object, and controls the virtual camera without performing such avoidance control when the positional relationship satisfies the permission conditions. A terrain drawing means that draws the faces of the terrain object that are facing the virtual camera, An information processing apparatus comprising: an image output means that performs processing to output a display image based on an image of the virtual space including the terrain objects to a display device.

20. A determination means for determining whether the positional relationship between a player character in a virtual space and the surrounding terrain objects satisfies the permission conditions, A virtual camera control means that, when the virtual camera approaches the terrain object if the positional relationship does not satisfy the permission conditions, performs avoidance control to prevent the virtual camera from being placed inside the terrain object, and controls the virtual camera without performing such avoidance control when the positional relationship satisfies the permission conditions. A terrain drawing means that draws the faces of the terrain object that are facing the virtual camera, An information processing system comprising: an image output means that performs processing to output a display image based on an image of the virtual space including the terrain objects to a display device.

21. A determination step to determine whether the positional relationship between the player character in the virtual space and the surrounding terrain objects satisfies the permission conditions, A virtual camera control step in which, when the virtual camera approaches the terrain object while the positional relationship does not satisfy the permission conditions, avoidance control is performed to prevent the virtual camera from being placed inside the terrain object, and when the positional relationship satisfies the permission conditions, the virtual camera is controlled without performing the avoidance control. A terrain drawing step of drawing the faces of the terrain object that are facing the virtual camera, An information processing method comprising: an image output step of performing a process to output a display image based on an image of the virtual space including the terrain objects to a display device.

Images