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

Abstract

To provide a system capable of suppressing distortion of a shape after destruction when destroying an object following a plurality of instructions by a player in a game using a voxel.SOLUTION: One example of an information processing system updates a damage value of voxels in a destruction range when a destruction action of a player character hits a virtual object, and destroys the virtual object in the destruction range when the damage value reaches a limit value. When the destruction action of the player character hits the virtual object, the density of the voxels included in the destruction range is updated and the virtual object in the destruction range is destroyed when there are voxels satisfying a predetermined criterion on the damage value.SELECTED DRAWING: Figure 19

Description

[Technical Field]

[0001] The present invention relates to a game program, an information processing system, an information processing device, and an information processing method that are capable of generating images using voxels. [Background technology]

[0002] Conventionally, there are games in which character voxels are created based on imaging information and polygon mesh information is generated (see, for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2008-33521 Summary of the Invention [Problem to be solved by the invention]

[0004] However, in the above-mentioned prior art, voxels are used to generate objects from imaging information, and voxel data is not used to freely transform objects.

[0005] Therefore, an object of the present invention is to provide a game program, an information processing system, an information processing device, and an information processing method that can prevent distortion of the shape of an object after destruction when the object is destroyed through multiple instructions from the player in a game in which objects can be freely destroyed using voxels. [Means for solving the problem]

[0006] In order to solve the above problems, the present invention employs the following configuration.

[0007] A game program according to the present invention is a game program executed by a processor of an information processing device. The game program causes the processor to store, in a storage medium, volume data representing a virtual object in a virtual space, the volume data holding, for each voxel included in a voxel space arranged in the virtual space, voxel values ​​including at least a density indicating the degree to which the object occupies a space defined by the voxel and a damage value indicating damage inflicted on the voxel. The game program also causes the processor to move a player character within the virtual space based on a player's operation input, cause the player character to perform a destructive action based on the player's operation input, and, when the destructive action hits the virtual object, update the voxel values ​​for voxels included in an erasure area set based on the position of the player character if at least any voxel satisfies a predetermined criterion with respect to the damage value to a density indicating the absence of the virtual object, and update the voxel values ​​for voxels included in the erasure area to a damage value indicating increased damage if no voxel satisfies the predetermined criterion. The game program then causes the processor to generate an image of the virtual space by drawing at least a polygon mesh that represents the surface of the virtual object based on the volume data.

[0008] According to the above, when a destruction action hits a virtual object, if there are voxels that satisfy a predetermined criterion regarding damage values, the voxel values ​​of the voxels included in the erasure range can be updated to a density that indicates that no virtual object is present. As a result, if there are voxels that satisfy the predetermined criterion regarding damage values, it is possible to erase the voxel objects within the erasure range even if there are voxels that do not satisfy the predetermined criterion, and it is possible to prevent the voxel objects from becoming distorted in shape after the destruction action.

[0009] Furthermore, the voxels that satisfy the predetermined criteria may be voxels whose damage, when increased by the destruction action, exceeds a preset damage upper limit.

[0010] According to the above, if the damage increased by this destruction action exceeds the damage upper limit, the voxel objects within the erasure range can be erased, and it can be determined whether to erase the voxel objects within the erasure range before actually damaging the voxels.

[0011] The computer may further determine a hit position where the destructive action hits the virtual object when the destructive action is performed. The voxels that satisfy the predetermined criteria may be voxels within a predetermined range that includes the hit position and that have a predetermined damage value.

[0012] Based on the above, it is possible to determine the hit position where a destructive action hits a virtual object, and to determine whether or not there are voxels that satisfy a predetermined criterion based on the damage values ​​of voxels within a predetermined range that includes the hit position, thereby reducing the processing load, for example.

[0013] The computer may also be caused to perform a collision detection between the polygon mesh or a judgment polygon mesh representing the surface of the virtual object generated for judgment, and a judgment shape that is set based on the destruction action, and determine the hit position.

[0014] Based on the above, it is possible to perform a judgment of contact with a polygon mesh or a judgment polygon mesh using a judgment shape based on a destructive action.

[0015] The voxel values ​​may further include data indicating hardness or material of the voxel. When the destruction action hits the virtual object and there is a voxel that satisfies the predetermined criterion, the computer may update the voxel values ​​of voxels that have hardness equal to or less than a predetermined hardness or a predetermined type of material so that the voxel values ​​have a density indicating that the virtual object does not exist.

[0016] According to the above, if there are voxels that satisfy a predetermined criterion, among the voxels included in the erasure range, voxels that have a hardness equal to or less than a predetermined hardness or that have a predetermined type of material can be destroyed. This allows the virtual object to be destroyed taking into account the hardness or material of the voxels.

[0017] The erasure range may have a shape of a sphere, an ellipsoid, or an asymmetrically deformed ellipsoid.

[0018] According to the above, the erasure range is set to a sphere, an ellipsoid, or a shape obtained by asymmetrically deforming an ellipsoid, and the shape of the virtual object after destruction can be made natural.

[0019] The virtual object may be a terrain in the virtual space.

[0020] According to the above, it is possible to destroy a terrain object.

[0021] The computer may also be caused to generate the polygon mesh using an algorithm that arranges polygons so that vertex positions are determined between voxels defined as inside the virtual object and voxels defined as outside the virtual object based on the density, and when the destruction action is performed, recalculate the vertices of the polygon mesh in a range that includes at least the voxels whose voxel values ​​have been updated.

[0022] Based on the above, a polygon mesh representing a virtual object is generated, and when a destruction action is performed, the vertices of the polygon mesh are recalculated, thereby making it possible to represent the virtual object after the destruction action has been performed.

[0023] Another invention may be an information processing system, an information processing device, or an information processing method that executes the game program. [Effects of the Invention]

[0024] According to the present invention, when a destructive action hits a virtual object, if there is a voxel that satisfies a predetermined standard regarding the damage value, the voxel object within the erasure range can be erased, and it is possible to prevent the voxel object from becoming distorted in shape after the destructive action. [Brief explanation of the drawings]

[0025] [Figure 1] FIG. 1 shows an example of a state in which the left controller 3 and the right controller 4 are attached to the main unit 2. [Figure 2] FIG. 10 shows an example of a state in which the left controller 3 and the right controller 4 are detached from the main unit 2. [Figure 3] Six-sided views showing an example of the main unit 2 [Figure 4] Six-sided diagram showing an example of the left controller 3 [Figure 5] Six-sided diagram showing an example of the right controller 4 [Figure 6] A block diagram showing an example of the internal configuration of the main unit 2. [Figure 7] A block diagram showing an example of the internal configuration of the main unit 2, the left controller 3, and the right controller 4. [Figure 8] FIG. 1 is a diagram showing an example of a terrain object that is a voxel object. [Figure 9] 9A and 9B are diagrams showing an example of the state before and after a part of the terrain object shown in FIG. 8 is deleted. [Figure 10]9A and 9B are diagrams showing an example of the state before and after a part of the terrain object shown in FIG. 8 is deleted. [Figure 11] A diagram showing an example of the contents of voxel data. [Figure 12] A diagram showing an example of property information indicating the properties of a material [Figure 13] A diagram showing an example of texture information indicating the texture of a material. [Figure 14] A diagram showing an example of a mesh generation method [Figure 15] FIG. 10 is a diagram showing an example of a game image including a terrain object. [Figure 16] FIG. 10 is an image of the game space in the game of this embodiment as viewed from a virtual camera, showing an example of a game image displayed on a display device. [Figure 17] FIG. 10 is a diagram showing a state in which damage has been inflicted on the terrain object 220 as a result of the first punch from the player character PC hitting the terrain object 220. [Figure 18] FIG. 10 is a diagram showing a state in which damage has been inflicted on the terrain object 220 as a result of the player character PC's second punch hitting the terrain object 220. [Figure 19] FIG. 10 is a diagram showing the damage state of the land object 220 when the third punch of the player character PC hits the land object 220. [Figure 20] FIG. 10 is a diagram showing the state after the terrain object 220 has been destroyed by the player character PC's third punch hitting the terrain object 220. [Figure 21] A diagram showing the process flow for destroying voxels. [Figure 22] A diagram showing an example of density updates when a destruction action is performed on a voxel object made up of multiple materials with different hardnesses, and a voxel exists that meets a predetermined criteria for damage value. [Figure 23] FIG. 10 is a diagram showing an example of various data used in information processing in the game system 1. [Figure 24]A flowchart showing an example of the flow of game processing executed by the game system 1. [Figure 25] A flowchart showing an example of the destruction determination process in step S5. [Figure 26] A flowchart showing an example of the voxel data update process in step S7. DETAILED DESCRIPTION OF THE INVENTION

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0062] By transmitting the above operation data to the main unit 2, the main unit 2 can obtain the input made to the left controller 3. In other words, the main unit 2 can determine the operation of each button 103 and analog stick 32 based on the operation data.

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

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

[0065] The right controller 4 has input units similar to those of the left controller 3. Specifically, it has buttons 113 and an analog stick 52. These input units have the same functions as those of the left controller 3 and operate in the same manner.

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

[0067] [2. Overview of processing in the game system] Next, an overview of the processing executed in the game system 1 will be described with reference to Figs. 8 to 15. In this embodiment, the game system 1 generates a game image in which terrain objects and characters (for example, a player character operated by a player) are arranged in a game space, which is a three-dimensional virtual space, and displays the game image on a display device. Note that in this embodiment, the display device on which the game image is displayed may be the above-mentioned display 12 or a stationary monitor.

[0068] [2-1. Voxel] In this embodiment, the shapes of some objects in the game space are defined by voxel data. Here, a voxel is a rectangular parallelepiped (more specifically, cubic) region arranged in a grid pattern in the game space, and voxel data is data set for each voxel. Hereinafter, an object whose shape is defined by voxel data will be referred to as a "voxel object." In this embodiment, the game system 1 stores voxel data for each of a plurality of voxels set in the game space as data for generating voxel objects in the game space.

[0069] Fig. 8 is a diagram showing an example of a terrain object that is a voxel object. As shown in Fig. 8, in this embodiment, the shape of a terrain object that represents terrain such as the ground is defined by voxel data (i.e., it is a voxel object). Each cube shown in Fig. 8 represents a terrain object. Note that in Fig. 8, the edges of the terrain object are shown with thick lines, but these thick lines are added to make the drawing easier to read, and in reality, the edges of the terrain object do not need to be displayed thick.

[0070] The terrain object shown in FIG. 8 is generated according to a rule that, for example, "if a parameter included in the voxel data set for a voxel is greater than a predetermined value, a cube is placed at the position of the voxel, and if the parameter is equal to or less than the predetermined value, nothing is placed at the position of the voxel." The terrain object shown in FIG. 8 is shown for the purpose of clearly illustrating the relationship between voxels and voxel objects. In this embodiment, a voxel object is actually generated (based on voxel data) according to a rule that results in a shape that is complex compared to the length of one side of a voxel, such as the terrain object shown in FIG. 14 (described later). Note that 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 a voxel object as shown in FIG. 8 or a voxel object as shown in FIG. 15 based on object data.

[0071] The shape of a voxel object can be changed by changing the voxel data of each voxel. FIGS. 9 and 10 are diagrams showing an example of the state before and after a portion of the terrain object shown in FIG. 8 is deleted. That is, when the hatched portion of the terrain object shown in FIG. 9 is destroyed, the terrain object changes to a shape as shown in FIG. 10. At this time, the game system 1 can easily erase the terrain object by rewriting the voxel data (described later) for the voxels in the hatched portion so that they indicate that the terrain object does not exist. Note that when adding a terrain object, the game system 1 can easily change the shape of the terrain object by changing the voxel data of each voxel, just as when erasing a terrain object.

[0072] In this way, the game system 1 can freely change the shape of a voxel object by rewriting the voxel data. For example, when a terrain object is destroyed in a game for some reason (for example, when a player character hits the terrain object), resulting in a change in the shape of the terrain object, the 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 indicating the outer shape of the terrain object (i.e., a mesh, which will be described later).

[0073] 11 is a diagram showing 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 pattern. The game system 1 associates and stores voxel data for each voxel in the game space. The voxel data indicates, for example, whether a voxel object exists in the voxel corresponding to the voxel data.

[0074] As shown in Fig. 11, the voxel data includes density data. The density data is data of density that indicates the degree to which an object is contained within the area in which each voxel is defined. As will be described 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 density. In other words, in this embodiment, the density is also data used to create a mesh that defines the surface of the voxel object.

[0075] In this embodiment, the density can be an integer value ranging from a lower limit (e.g., 0) to an upper limit (e.g., 255). In this embodiment, the game system 1 assumes that when the density value set for a voxel is high, the proportion of the volume within the voxel is large, and when the density value is low, the proportion of the volume within the voxel occupied by the voxel object is small. For example, when the density is 0, no object exists within the voxel; when the density is 255, the entire voxel is occupied by the object; and when the density is between these values, the voxel is occupied by the object at 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 density does not necessarily have a volume that exactly matches the proportion indicated by the density. For example, a method for generating a voxel object such as that shown in FIG. 8 and a method for generating a voxel object such as that shown in FIG. 15 may have different volumes even though they are based on the same density.

[0076] In other embodiments, the density may indicate whether the entire area of ​​the voxel is occupied by voxel objects or whether the area of ​​the voxel does not contain any voxel objects. For example, the density data may be data that can only take on the value 0 or 1.

[0077] As shown in Fig. 11, the voxel data includes material data. The material data indicates the material (in other words, the substance) of a voxel object generated from the voxel data. In this embodiment, materials such as sand, rock, and soil are set for the voxel object. That is, in this embodiment, multiple types of materials are prepared as materials that can be set for the voxel object, and one of the multiple types of materials is set for the voxel object.

[0078] As shown in FIG. 11, in this embodiment, the material data indicates identification information of the material (referred to as a "material ID"). Furthermore, in this embodiment, the game system 1 stores material information indicating the properties and texture of the material for 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 associates the material ID with identification information of the properties of the material (referred to as a "property ID") and identification information of the texture of the material (referred to as a "texture ID") (see FIG. 11).

[0079] Fig. 12 is a diagram showing an example of property information indicating the properties of a material. As shown in Fig. 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 property of a material is a property that a voxel object to which the material is set has in the game, and is, for example, information such as weight and slipperiness shown in Fig. 12. Note that the specific content of the property is arbitrary, and for example, the following information may be set as the property of a material: ·temperature Breakability (for example, the number of times a voxel object can be impacted before it breaks) Whether other objects are glued to the voxel object - The amount of health recovered by the player character when the player character destroys a voxel object The amount of in-game currency the player character will acquire when they destroy a voxel object. The specific content of the properties set for the material is arbitrary. In other embodiments, information different from the above may be set as information indicating the properties of the material.

[0080] 13 is a diagram showing an example of texture information indicating the texture of a material. As shown in Fig. 13, the game system 1 stores texture information that associates the above texture ID with the texture indicated by the texture ID.

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

[0082] As described above, in this embodiment, the material data defines the properties of a voxel object and the texture to be 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 property indicated by the property ID "001" associated with that material ID in the material information is set as the property of the voxel object corresponding to that voxel data (see the arrow in FIG. 11). Also, 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 in FIG. 11).

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

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

[0085] Furthermore, the material data may be information about a material that further indicates information other than the properties and textures described above. For example, the material data may include effect data that indicates an effect that is generated when an effect generation condition set for a voxel object (e.g., a part of the voxel object is destroyed, or a character steps on the voxel object) is satisfied. The effect data may be data that indicates an effect image (e.g., an effect image that expresses that a voxel object has been destroyed) or data that indicates an effect sound (footsteps when a character walks on a voxel object).

[0086] As shown in FIG. 11 , the voxel data includes state data that indicates the state of a voxel object. The specific content of the state data is arbitrary. For example, the state data may be data that indicates whether a voxel object is wet or not, or data that indicates the amount of damage that has been inflicted on the voxel object. The content of the state data may be updated during the game.

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

[0088] Fig. 14 is a diagram showing an example of a method for generating a mesh. Note that in Fig. 14, voxels and meshes are expressed in two dimensions for the purpose of making the drawing easier to see and the explanation easier to understand, but in reality, a three-dimensional mesh is generated based on voxels in a three-dimensional space.

[0089] As described above, in this embodiment, the density set for a voxel is set in the range of 0 to 255. Furthermore, in this embodiment, voxels with a density equal to or greater than a 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 outside the object (i.e., reference value = 1); the reference value may be, for example, 128. In the example shown in FIG. 14, the density of voxel 201 and the other voxels outside is set to 0, the density of voxel 202 is set to 100, which is less than the reference value, and the densities of voxels 203 and 204 are set to 150 and 200, which are equal to or greater than the reference value. In this embodiment, the game system 1 generates vertices between voxels with densities equal to or greater than the reference value and voxels with densities less than the reference value. Specifically, a determination is made as to whether to generate a vertex for each area spanning eight adjacent voxels (four in the drawing) (areas surrounded by dotted lines in the drawing). That is, vertices are generated in regions that span both voxels with densities equal to or greater than a reference value and voxels with densities less than the reference value. Furthermore, if adjacent vertices (the boundaries of the aforementioned regions containing each vertex) pass between a voxel with a density equal to or greater than the reference value and a voxel with a density less than the reference value, a polygon mesh is generated by connecting those vertices. The coordinates of the vertices are determined by comparing the densities of adjacent voxels along each of the X, Y, and Z axes and interpolating based on the difference in density. In this case, coordinate calculations can also be performed based on normal information. Normal information may be stored in advance for at least some voxels. If normal information is not stored, normal information may also be calculated based on the densities of adjacent voxels. Note that in FIG. 14, the density of voxel 202 is less than the reference value, so voxel 202 is treated as outside the object when determining whether a vertex exists. However, the density value of voxel 202 itself is used to calculate the coordinates of the vertices to be generated. If the reference value were set to a value lower than the density of the voxel 202, the result would be that more vertices would be added to the upper right and upper left sides of the voxel 202 in FIG.

[0090] By generating a polygon mesh as described above, it is possible to generate a shape whose volume reflects the density of each voxel to some extent. However, depending on the relationship with adjacent voxels, it is possible that a voxel with a density of 0 may include a portion of an area within the object, or that a voxel with a density of 255 may include a portion of an area outside the object. Furthermore, in this embodiment, voxels with a density less than the reference value are processed as being outside the object, so that the number of vertices is reduced compared to when voxels are processed as being inside the object, resulting in a smaller volume. In other words, it is not necessary to calculate a polygon mesh so that the volume strictly corresponds to the density value.

[0091] 15 is a diagram showing an example of a game image including a terrain object. In this embodiment, by generating a mesh as described above, it is possible to make a voxel object have a shape with complex irregularities compared to the length of one side of a voxel, for example.

[0092] Note that any method may be used to generate a mesh based on voxel data. For example, in another embodiment, if the density of voxel data is greater than a predetermined value, a mesh may be generated such that cubes are placed in the voxels (see FIG. 8).

[0093] The game system 1 determines the appearance (i.e., color and / or pattern) of each face of the mesh generated as described above, depending on the material specified by the voxel data. Specifically, the game system 1 determines the texture to be used for drawing 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 to be mapped to each face of the mesh is determined based on voxel data of voxels (referred to as target voxels) used to generate the face, among the voxels in which the voxel object exists. The target voxels may be, for example, one or more voxels arranged around the face, depending on the mesh generation method. In other words, the texture to be mapped to a face of the mesh is determined to be a texture corresponding to the material set for one or more voxels arranged around the face.

[0094] In another embodiment, one voxel data may include 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 data for determining a texture to be used for a voxel object, and indicates the ratio of influence that each material (specifically, the texture corresponding to the material) indicated by the multiple types of material data has on the appearance (specifically, the color and / or pattern) of the voxel object. When determining a texture to be mapped to each face of a mesh, the texture is determined based on various data (specifically, density data, multiple types of material data, and ratio data) included in the voxel data of the target voxel. For example, when multiple types of materials are set for a target voxel corresponding to one face, the texture corresponding to the material (one type) with the greatest influence may be used in consideration of the ratio, or each texture corresponding to the multiple types of materials may be used in consideration of the ratio.

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

[0096] (Game Processing Overview) Next, destruction of voxel objects in the game of this embodiment will be described. Fig. 16 is a diagram showing an example of an image of the game space in the game of this embodiment as viewed from a virtual camera, and is displayed on a display device.

[0097] As shown in FIG. 16, a player character PC is placed in the game space. The player character PC moves within the game space in response to player operations (for example, operations on the analog stick 32). The player character PC also performs various actions within the game space, such as punching or jumping, in response to player operations (for example, operations on the A button 53 or the B button 54). The player character PC is not a voxel object, but a 3D object whose shape is defined in advance by polygons.

[0098] When the game starts, a fixed voxel space defined by the Xs-Ys-Zs coordinate system is set within the game space as a voxel space representing the field. The Xs-Ys-Zs coordinate system is assumed to have axial directions parallel to the XYZ coordinate system of the game space. That is, the Ys axis points upward in the game space, and the Xs and Zs axes are perpendicular to the Ys axis. Below, the voxel space defined by the Xs-Ys-Zs coordinate system is sometimes referred to as the "field voxel space." The position of each object in the game space is expressed by coordinate values ​​in the Xs-Ys-Zs coordinate system. Note that, although the orientation of the Xs-Ys-Zs coordinate system representing the field voxel space is assumed to coincide with the XYZ coordinate system representing the game space, they do not have to coincide.

[0099] In the field voxel space, terrain objects are set as voxel objects. For example, a terrain object 210 representing the ground and a terrain object 220 representing a rocky mountain are set as terrain objects. For example, material data representing rocks is set in the voxel data of each voxel located lower in the field voxel space, thereby forming the terrain object 210 representing the ground made of rock. Furthermore, material data representing rocks is set in the voxel data of multiple voxels located higher than the ground in the field voxel space, thereby forming the terrain object 220 representing a rocky mountain rising from the ground.

[0100] The player character PC can move on the terrain object in response to the player's instructions, and can also perform destructive actions in response to the player's instructions.

[0101] When the player character PC's destruction action hits a voxel object, the destruction action may destroy the voxel object or may damage the voxel object. If the voxel object is damaged and the amount of damage reaches a limit, the voxel object is destroyed, but if the amount of damage does not reach the limit, the voxel object is not destroyed.

[0102] Here, the "hardness" is predefined for the material set for each voxel. That is, the voxel object has a hardness corresponding to the material. Also, a "limit value" is predefined for the material. The "limit value" is a value indicating the degree to which the object can withstand without being destroyed. For example, it is a value indicating the number of destruction actions that can be endured without being destroyed. This "limit value" may change according to the progress of the game. For example, even for the same material, it may be controlled such that the "limit value" is higher in the late stage of the game than in the early stage. Also, for the destruction action, a "hardness" corresponding to the type of the destruction action is predefined. Further, when the player character PC performs a destruction action, the hardness of the destruction action may vary depending on the state of the player character PC at that time. For example, the "hardness" of the destruction action and the material of the voxel are defined in the range of 1 to 5.

[0103] For example, when a destruction action hits a voxel object, if the hardness MH (hardness of the voxel object) of the material set for the voxel is less than or equal to the hardness DH of the destruction action (when DH≥MH is satisfied), no damage is added to that voxel, and that voxel is destroyed by one destruction action. Specifically, the density of the voxel is updated. On the other hand, if the hardness MH of the material set for the voxel is greater than the hardness DH of the destruction action and the difference is less than a predetermined value (when 0<MH - DH<the predetermined value is satisfied), the density of the voxel is not updated, and damage is added to that voxel. Hereinafter, "DH≥MH" may be referred to as the "first condition", and "0<MH - DH<the predetermined value" may be referred to as the "second condition".

[0104] Hereinafter, the case where the player character PC performs a punch as an example of a destruction action on the terrain object 220 will be described. For example, assume that the hardness MH of the material "rock" of the terrain object 220 is "3", and the hardness DH of the punch of the player character PC is "2", and these satisfy the above second condition.

[0105] FIG. 17 is a diagram showing a state in which damage has been inflicted on the land object 220 when the first punch of the player character PC hits the land object 220. FIG. 18 is a diagram showing a state in which damage has been inflicted on the land object 220 when the second punch of the player character PC hits the land object 220. FIG. 19 is a diagram showing a state in which the land object 220 has been damaged when the third punch of the player character PC hits the land object 220. FIG. 20 is a diagram showing a state after the land object 220 has been destroyed when the third punch of the player character PC hits the land object 220. FIGS. 17 to 20 show two-dimensional views of the land object 220 as viewed from the front.

[0106] As shown in FIG. 17, when a punch from the player character PC hits the terrain object 220, a destruction range DR is set based on the hit position indicating the location of the punch, and damage is inflicted on voxels included in the destruction range DR. A damage value dm is stored in each voxel. For example, the first punch adds 1 to the damage value dm of a voxel included in the destruction range DR1. The damage value of a voxel is added each time a destruction action is performed, and when the damage value reaches the limit value "3," the voxel is destroyed. Therefore, if the player character PC punches the same location as in FIG. 17, the voxels within the destruction range DR1 are destroyed by the third punch. In other words, the density of voxels within the destruction range DR1 is updated to a value indicating that no object is present.

[0107] Here, if the second punch hits a position different from the position where the first punch hit, as shown in FIG. 18, a destruction range DR2 is set according to the position where the second punch hit, and a damage value of "1" is added to the voxels included in the destruction range DR2. Because a damage value of "1" has already been added to the destruction range DR1 by the first punch, the damage value for the overlapping area between the destruction range DR1 and the destruction range DR2 becomes "2". The damage value for the voxels within the destruction range DR2 other than this overlapping area becomes "1". In this state, the damage values ​​of all voxels in the terrain object 220 are less than the limit value "3", so no voxels are destroyed.

[0108] Next, suppose that the player character PC throws a third punch and the third punch hits the terrain object 220. As shown in FIG. 19 , if the position where the third punch hits is different from the positions where the first and second punches hit, damage values ​​are added to voxels within the destruction range DR3 that is set according to the hit position of the third punch. In this case, the damage value is "3" for the overlapping area of ​​the three destruction ranges DR1 to DR3, the damage value is "2" for the overlapping area of ​​the two destruction ranges DR1 and DR3, the damage value is "2" for the overlapping area of ​​the two destruction ranges DR2 and DR3, and the damage value is "1" for the rest of the destruction range DR3. That is, the destruction range DR3 that is set according to the third punch includes voxels with a damage value of "1," voxels with a damage value of "2," and voxels with a damage value of "3." In such a case, in this embodiment, not only voxels with a damage value of "3", but also voxels with a damage value of "1" and voxels with a damage value of "2" are destroyed within the destruction range DR3.

[0109] That is, if there is a voxel whose damage value becomes equal to or exceeds the limit value of "3" due to the third punch, the voxels within the destruction range DR3 are destroyed (erased), including voxels that have not yet reached the limit value. As a result, as shown in FIG. 20, no objects are present in the destruction range DR3 set in response to the third punch, and a cavity of the same or similar shape as the destruction range DR3 is created in the terrain object 220. On the other hand, the area DR1 damaged by the first punch and the area DR2 damaged by the second punch are not destroyed, and damage remains accumulated.

[0110] For example, if only voxels whose damage value reaches the limit "3" in Figure 19 are destroyed, the shape of the destroyed voxel object will be distorted. Also, the range of destruction may become narrower, making it difficult to play. Also, the voxels that are deviated from the hit position of the third punch will be destroyed, and the voxels around the hit position will remain, which may cause a sense of incongruity to the player.

[0111] For this reason, in this embodiment, assuming that a damage value is inflicted by the current destruction action, if there is a voxel whose damage value is equal to or greater than the limit value, the voxels within the destruction range set according to the current destruction action are destroyed. Specifically, of all voxels within the destruction range set according to the current destruction action, voxels whose hardness is equal to or less than the hardness of the voxel whose damage value is equal to or greater than the limit value are destroyed. This makes it possible to prevent only positions shifted from the hit position of the punch from being destroyed, and to prevent the voxel object from becoming distorted after destruction.

[0112] Next, the flow of processing up to the destruction of voxels will be described with reference to Fig. 21. Fig. 21 is a diagram showing the flow of processing related to the destruction of voxels.

[0113] As shown in (a) of FIG. 21, when the player character PC punches, the collision detection shape used for collision detection with other objects is skipped. The collision detection shape is a shape used internally by the information processing system for collision detection and is not displayed on the game screen. For example, the collision detection shape may be a sphere, cylinder, disk, cone, or polygonal pyramid that includes the position of the player character PC's fist, and is skipped into virtual space in response to the punch. By skipping the collision detection shape, it is determined whether the collision detection shape has collided with another object (a voxel object or other 3D object). For example, a collision detection is performed between the collision detection shape and the polygon mesh that forms the surface of the voxel object.

[0114] In addition to the polygon mesh that forms the surface, a voxel object may also be provided with a judgment polygon mesh for determining contact (collision) with other objects. In this case, collision detection is performed between the collision detection shape and the judgment polygon mesh. The collision detection shape may have different sizes and shapes depending on the type of destruction action.

[0115] 21(b), when the collision detection shape collides with the land object 220, the collision range is identified. Specifically, the range in which the collision detection shape collides with the polygon mesh of the land object 220 is identified. The collision range identified here is the surface of the land object 220.

[0116] Next, as shown in FIG. 21(c), each voxel within the identified collision range is checked to see if it meets a predetermined criterion for damage value. Voxels that meet the predetermined criterion are voxels that are damaged by a punch (i.e., voxels that meet the second condition) and whose damage value will be equal to or greater than a threshold value due to the current punch. For example, the material and damage value of each voxel within the collision range are checked, and voxels whose material hardness MH is greater than the punch hardness DH and whose difference is less than a predetermined value (voxels that meet the second condition) are extracted. Then, based on the current damage value of the extracted voxel, it is determined whether the damage value will be equal to or greater than the threshold value if added by the current punch.

[0117] As shown in (d) of FIG. 21, if a voxel within the collision range satisfies the predetermined criteria, a destruction range DR is set based on the position where the punch hit (hit position). The hit position may be the center of the collision detection shape or any position within the collision range. The destruction range DR is a range having a predetermined shape that includes the hit position and includes the collision range. The destruction range DR may have a shape different from the collision detection shape, such as a sphere, an ellipsoid, or an ellipsoid asymmetric in a predetermined direction. Then, for all voxels within the destruction range DR that have a hardness equal to or less than that of the voxels that satisfy the predetermined criteria, the density is set to a value indicating the absence of an object. Specifically, for voxels located inside the destruction range DR, the density is set to "0," and for voxels located on the boundary of the destruction range DR, the density is reduced to, for example, a value equal to or less than a reference value (or may be equal to or greater than the reference value). As a result, voxel objects included in the destruction range DR are destroyed (erased).

[0118] On the other hand, if there are no voxels within the collision range that satisfy the above-mentioned specified criteria, the voxels included in the destruction range DR that satisfy the above-mentioned second condition are not destroyed (their density is not updated), and a damage value is added to them.

[0119] Note that voxels that satisfy the first condition above (voxels whose punch hardness DH is equal to or greater than the material hardness MH) are destroyed. In other words, voxels made of materials that are the same hardness or softer than the punch are destroyed by the punch regardless of the damage value. Also, for voxels that do not satisfy either the first or second condition, neither the density is updated nor the damage value is added. In other words, for voxels made of materials that are sufficiently hard against the hardness of the punch (such as iron), no damage value is added and they are not destroyed.

[0120] FIG. 22 is a diagram showing an example of density update when a destruction action is performed on a voxel object made of a plurality of materials with different hardnesses, and a voxel that satisfies a predetermined standard regarding the damage value exists.

[0121] As shown in FIG. 22 , for example, consider a case where a punch hits a voxel object made up of materials with hardnesses of "2," "3," and "4." If a voxel meets a predetermined criterion for damage value within the destruction range DR corresponding to the punch, the voxels within the destruction range DR with a hardness of "3" equal to the hardness of the voxel determined to meet the predetermined criterion are destroyed with their density updated as described above. Voxels with a hardness of "2" less than the hardness of the voxel determined to meet the predetermined criterion are also destroyed. On the other hand, for voxels with a hardness of "4," the difference between the voxel's hardness of "4" and the punch's hardness of "2" is greater than or equal to the predetermined value, so their density is not updated and their damage value is not increased. As a result, as shown in the lower diagram of FIG. 22 , after the density is updated, the voxel object is destroyed with a portion of the destruction range DR missing, forming a cavity of that shape.

[0122] Thus, in this embodiment, each voxel is assigned a voxel value including a density indicating the degree to which an object occupies the space defined by the voxel and a damage value indicating damage inflicted on the voxel. When a destruction action hits a voxel object, a damage value is added to the voxel, and when the damage value accumulated in the voxel due to multiple destruction actions reaches a limit value, the voxel is destroyed. When a destruction action hits a voxel object, if there are voxels that meet a predetermined criterion, the voxels included in the destruction range set based on the position of the player character PC are erased. If there are no voxels that meet the predetermined criterion, a damage value is added to the voxels included in the destruction range.

[0123] This makes it possible to prevent the shape of a destroyed voxel object from becoming distorted when it is hit by a destruction action in a game in which the voxel object is destroyed by multiple destruction actions.

[0124] Furthermore, in this embodiment, when a destruction action is performed, collision detection is first performed using the collision detection shape, and it is determined whether or not there are voxels that satisfy a predetermined criterion only in the collision range (surface of the voxel object) identified in the collision detection. If it is determined that there are voxels that satisfy the predetermined criterion, voxels within the destruction range that extends to the interior of the voxel object are erased. Because it is determined whether or not there are voxels that satisfy the predetermined criterion only for a portion of the voxel object, the calculation load can be reduced.

[0125] In the game of this embodiment, various voxel objects exist in addition to the terrain objects 210 and 220. For example, voxel objects made of various materials that can be destroyed by the player character PC are arranged in the field voxel space. Furthermore, for example, a second voxel space separate from the field voxel space may be set, and voxel objects (e.g., enemy objects) defined by voxels in the second voxel space may exist. For example, the enemy object moves within the virtual space as the position and posture of the second voxel space change within the virtual space. The above-described damage value-related processing is also performed on voxel objects defined in such a second voxel space.

[0126] [3. Specific examples of processing in game systems] Next, a specific example of information processing in the game system 1 will be described with reference to FIGS.

[0127] Fig. 23 is a diagram showing an example of various data used for information processing in the game system 1. As shown in Fig. 23, the game system 1 stores a game program, game space data, field voxel space data, reference voxel data, second voxel space data, player character data, and mesh data.

[0128] The game program is a program for executing the game processing in this embodiment (specifically, the game processing shown in FIG. 24). The game program is stored in advance in a storage medium inserted in the slot 23 or in the flash memory 84, and is read into the DRAM 85 when the game is executed.

[0129] The game space data is data for defining the game space, and includes data representing the XYZ coordinate system.

[0130] The field voxel space data is data relating to the entire field voxel space. As shown in Figure 23, the field voxel space data includes position data. The position data is data representing the position and rotation of the field voxel space in the game space. In this embodiment, the field voxel space is fixed to the game space.

[0131] The field voxel space data also includes first volume data. The first volume data includes voxel data for each voxel in the field voxel space. Each voxel data includes density data, material data, and a damage value. Density and material are set for each voxel in the first volume data, and a mesh is generated based on the voxel data, thereby forming a terrain in the game space. Initial first volume data is pre-stored in a storage medium or flash memory 84 attached to the slot 23. At the start of the game, the first volume data stored in the storage medium or flash memory 84 attached to the slot 23 is loaded into the DRAM 85. This forms an initial terrain. For example, a terrain object 210 representing a level ground and a terrain object 220 representing a rocky mountain are formed as the initial terrain. During game execution, the voxel data included in the first volume data stored in the DRAM 85 is updated, thereby changing the terrain.

[0132] The reference voxel data is voxel data of a voxel determined to satisfy the predetermined criteria regarding the damage value, and is stored when a voxel determined to satisfy the predetermined criteria exists when a destruction action hits a voxel object.

[0133] The second voxel space data is data relating to a second voxel space arranged within the game space and different from the field voxel space. The second voxel space data has data similar to the field voxel space data. The second voxel space data includes second volume data that holds multiple voxel data for representing voxel objects (e.g., enemy objects) that can move in the virtual space.

[0134] The player character data is data relating to the player character PC, and includes data indicating the position and posture in the game space.

[0135] The mesh data is data that indicates a mesh that is set for a voxel object placed in a game space. The mesh data includes, for example, data that indicates the position of each vertex in the mesh. The mesh data is generated based on the first volume data, the second volume data, etc.

[0136] 23, the game system 1 stores the above-mentioned property information and texture information data, data related to various characters appearing in the game, and the like as data stored in advance before the execution of the game process. For example, 3D object data representing a 3D object (e.g., a player character PC) different from a voxel object is stored. In addition, the game system 1 stores voxel space data for each voxel object that can move within the game space.

[0137] Fig. 24 is a flowchart showing an example of the flow of game processing executed by the game system 1. The game processing shown in Fig. 24 is started in response to, for example, an instruction to start the game being given by the player.

[0138] In the present embodiment, the processor 81 of the main unit 2 executes the game program stored in the game system 1 to perform the processing of each step shown in FIG. 24. However, in other embodiments, some of the processing of each step may be performed by a processor (e.g., a dedicated circuit) other than the processor 81. Furthermore, if the game system 1 is capable of communicating with another information processing device (e.g., a server), some of the processing of each step shown in FIG. 24 may be performed in the other information processing device. Furthermore, the processing of each step shown in FIG. 24 is merely an example, and the processing order of each step may be reversed, or another process may be performed in addition to (or instead of) the processing of each step, as long as similar results are obtained.

[0139] 24 using a memory (for example, DRAM 85). That is, the processor 81 stores information (in other words, data) obtained by each processing step in the memory, and when using the information in a subsequent processing step, reads the information from the memory and uses it.

[0140] 24, in step S1, the processor 81 sets a game space in an initial state. Specifically, the processor 81 acquires first volume data representing the topography of the game space in the initial state from a storage medium inserted in the slot 23, and stores some or all of the acquired first volume data in the DRAM 85. The processor 81 also reads player character data from the storage medium, sets an initial position and orientation of the player character, and stores the same in the DRAM 85. The processor 81 also sets an initial position and orientation of the virtual camera, and stores the same in the DRAM 85.

[0141] The voxel data written to the DRAM 85 may be voxel data for a partial range of the voxel data for the entire range of the game space, which is used to generate a game image. For example, the processor 81 may generate an image of an object using voxel data for voxels included in a partial range of the game space (for example, a range within a predetermined distance from the position of the virtual camera). When voxel data for a partial range of the game space is written, a process similar to that of step S1 is executed at an appropriate timing during execution of the series of processes of steps S2 to S11 (for example, at a timing when the position of the virtual camera has moved by more than a predetermined distance).

[0142] In step S2, processor 81 generates a mesh for the voxel object. The mesh is generated according to the method described above in "[2-2. Mesh]". Specifically, processor 81 generates a mesh representing each voxel object based on the first volume data stored in DRAM 85 in step S1. Polygons are generated so that vertex positions are determined between voxels defined as inside the voxel object and voxels defined as outside the voxel object. In this way, a polygon mesh representing the voxel object is set in the game space. For example, landform objects 210 and 220 are set in the game space. An example of a specific method for determining vertex positions is as described with reference to FIG. 14. After step S2, the game starts, and the processes of steps S3 to S11 are repeatedly executed at predetermined frame time intervals (for example, 1 / 60 second intervals) during the game.

[0143] In step S3, the processor 81 controls the actions of various objects (e.g., the player character PC) that appear in the game space. For example, the processor 81 moves the player character PC based on operation data received from the controllers 3 and 4, and causes the player character PC to perform a predetermined action (destructive action, jump, etc.). The destructive action of the player character PC may be a punch, a kick, a throwing of a bullet, etc. Following step S3, the processing of step S4 is executed.

[0144] In step S4, processor 81 determines, based on the operation data from the controller, whether or not a destructive action has been performed by the player character PC. Specifically, based on the operation data from the controller, it determines whether or not a predetermined button on the left controller 3 or the right controller 4 has been pressed. If the determination result in step S4 is positive, the process proceeds to step S5. On the other hand, if the determination result in step S4 is negative, the process proceeds to step S10.

[0145] In step S5, processor 81 performs a destruction determination process. Here, it is first determined whether or not a destruction action performed by the player character PC has hit a voxel object (for example, a terrain object). If the destruction action has hit a voxel object, it is determined whether or not a voxel that satisfies a predetermined criterion exists, and if it is determined that such a voxel exists, a condition flag for destroying voxels within the destruction range is set to ON. Details of the destruction determination process in step S5 will be described later. Next, processor 81 performs the process of step S6.

[0146] In step S6, processor 81 performs a destruction range setting process to set a destruction range according to the voxel object hit by the destruction action. For example, if the destruction action hits a terrain object defined by voxels in the field voxel space, processor 81 sets a first destruction range including the hit position of the destruction action determined in step S5. Also, for example, if the destruction action hits an object defined by voxels in the second voxel space (e.g., an enemy object), processor 81 sets a second destruction range including the hit position determined in step S5. The destruction range is, for example, a sphere, an ellipsoid, or a shape obtained by deforming an ellipsoid asymmetrically left and right or up and down, and may be a shape different from or the same as the above-mentioned collision detection shape. Next, processor 81 performs the process of step S7.

[0147] In step S7, the processor 81 executes a voxel data update process. Details of the voxel data update process in step S7 will be described later. Next, the processor 81 executes the process of step S8.

[0148] In step S8, processor 81 determines whether to update the mesh. Here, if the voxel data has been updated in step S7, processor 81 determines to update the mesh. If the determination result in step S8 is positive, the process of step S9 is executed. On the other hand, if the determination result in step S8 is negative, the process of step S10 is executed. Note that even if the voxel data has been updated in step S7, if there are no updated voxels within the imaging range of the virtual camera, processor 81 may determine not to update the mesh in step S8. In other words, even if a destruction action hits a voxel object and destroys part or all of the voxel object, if the voxel object in the game space visible from the virtual camera is not destroyed, the mesh may not need to be updated. Furthermore, when the processing load is high, for example, the mesh update may not be performed in the current frame but may be carried over to the next frame or later.

[0149] In step S9, the processor 81 updates the mesh of the voxel object whose voxel data was changed in step S7. Specifically, the vertex positions of the mesh are recalculated based on the updated voxel data. The updated mesh is stored in the DRAM 85 as mesh data. That is, the processor 81 generates a mesh of the destroyed voxel object based on the voxel data updated in step S7. This allows the mesh of the voxel object for which a destruction action has been performed to be dynamically changed during the game. In step S9, the vertices of the mesh are recalculated only for the portion of the voxel data for which the voxel data has been updated. For the portion of the mesh for which the voxel data has not been updated, the vertex positions of the mesh generated in step S2 are used. In this way, since the mesh is recalculated only for the updated voxel data, the processing load can be reduced. Note that in another embodiment, in step S9, the vertex positions of the mesh may be recalculated based on all voxel data in the game space, including both updated and unupdated voxel data (or all voxel data within the imaging range of the virtual camera). After step S9, the process of step S10 is executed.

[0150] In step S10, processor 81 generates a game image representing the game space based on the virtual camera, and displays the generated game image on the display device. Specifically, processor 81 generates a game image of the mesh generated in step S2 or S9 as viewed from the position of the virtual camera. This generates a game image representing the game space including voxel objects and other 3D objects (e.g., player character PC). Then, processor 81 displays the generated game image on the display device. Following step S10, the process of step S11 is executed.

[0151] In step S11, processor 81 determines whether or not to end the game. For example, processor 81 determines whether or not an instruction to end the game has been given by the user. If the determination result in step S11 is negative, the processing of step S3 is executed again. Thereafter, the series of processing from steps S3 to S11 is repeatedly executed until it is determined in step S11 that the game is to be ended. On the other hand, if the determination result in step S11 is positive, processor 81 ends the game processing shown in FIG. 24.

[0152] (Destruction determination process) The destruction determination process in step S5 will be described below with reference to Fig. 25. Fig. 25 is a flowchart showing an example of the destruction determination process in step S5.

[0153] In step S21, processor 81 performs collision detection processing. Specifically, processor 81 performs collision detection with another object by flying a collision detection shape from the position of the player character PC (for example, near the fist) in the direction in which the destructive action was performed (see FIG. 21(a)). For example, it may be determined whether or not the collision detection shape has collided with a polygon mesh that forms the surface of a voxel object. Alternatively, a detection polygon mesh for determining contact of voxel objects may be prepared, and collision detection between the collision detection shape and the detection polygon mesh may be performed. Next, the processing of step S22 is performed.

[0154] In step S22, processor 81 determines whether or not the destructive action hits a voxel object as a result of the collision determination process. If the determination result of step S22 is positive, the process of step S23 is then executed. On the other hand, if the determination result of step S22 is negative, the process of FIG. 25 is terminated.

[0155] In step S23, the processor 81 identifies the collision range on the surface of the voxel object that has collided with the collision determination shape, and extracts the voxels within the collision range (see Fig. 21(b)). Next, the process of step S24 is performed.

[0156] In step S24, the processor 81 extracts the voxels that satisfy 0 < MH - DH < a predetermined value among the voxels within the collision range. That is, here, the voxels in which the hardness MH of the material set for the voxel is greater than the hardness DH of the destruction action and the difference is less than the predetermined value are extracted. These voxels satisfy the second condition and are the voxels to which damage can be added by the current destruction action. Next, the process of step S25 is performed.

[0157] In step S25, the processor 81 determines whether there are voxels for which the damage value after addition becomes equal to or greater than the limit value when the damage value is added to the voxels extracted in step S24 by the current destruction action. If the determination result in step S25 is affirmative, that is, if there are voxels that satisfy a predetermined criterion on the surface of the voxel object that has collided with the collision determination shape, then the process of step S26 is executed next. On the other hand, if the determination result in step S25 is negative, the process in Fig. 25 is terminated.

[0158] In step S26, the processor 81 sets the condition flag to ON and stores the voxel data of the voxels determined to satisfy the predetermined criterion as reference voxel data. The condition flag is a flag indicating that there are voxels that satisfy a predetermined criterion on the surface of the voxel object that has collided with the collision determination shape. This condition flag is referred to in the next voxel data update process.

[0159] When the process of step S26 is performed, when it is determined NO in step S22, or when it is determined NO in step S25, the processor 81 ends the process shown in Fig. 25.

[0160] (Voxel data update process) The voxel data update process in step S7 will be described below with reference to Fig. 26. Fig. 26 is a flowchart showing an example of the voxel data update process in step S7.

[0161] In step S31, processor 81 selects one voxel that is included in the destruction range set in step S6 from among the voxels in the volume data that indicate the voxel object hit by the destruction action. Here, voxels that are completely included in the destruction range or voxels that are partially included in the destruction range are selected. For example, if the destruction action hits a terrain object 220 defined by voxels in the field voxel space, one voxel that is included in the destruction range set in step S6 from among the voxels in the field voxel space is selected. Following step S31, the processing of step S32 is executed.

[0162] In step S32, processor 81 determines whether the hardness DH of the destruction action is equal to or greater than the hardness MH of the material indicated by the material data of the voxel data. Here, it is determined whether the hardness of the destruction action and the hardness of the voxel object satisfy a first condition. That is, it is determined whether the destruction action is hard against the voxel object and whether the voxel object is destroyed by a single destruction action. If the determination result of step S32 is positive, then the process of step S36 is executed. On the other hand, if the determination result of step S32 is negative, then the process of step S33 is executed.

[0163] In step S33, processor 81 determines whether the difference (MH-DH) between the hardness MH of the voxel's material and the hardness DH of the destruction action is less than a predetermined value. Here, it is determined whether the hardness of the destruction action and the hardness of the voxel object satisfy a second condition. That is, it is determined whether the voxel selected in step S31 is a voxel to which a damage value can be added by a destruction action. If the determination result in step S33 is positive, the process proceeds to step S34. On the other hand, if the determination result in step S33 is negative, the process proceeds to step S37.

[0164] In step S34, processor 81 determines whether the condition flag was set to ON in step S26 of the destruction determination process. That is, it is determined whether a voxel that satisfies a predetermined criterion regarding the damage value exists in the collision range of the voxel object that collided with the collision determination shape. A voxel that satisfies the predetermined criterion is a voxel to which damage may be inflicted by the current destruction action, and a voxel whose damage value after addition by the current destruction action is equal to or greater than a limit value. If the determination result in step S34 is positive, the process of step S36 is executed next. On the other hand, if the determination result in step S34 is negative, the process of step S35 is executed next.

[0165] In step S35, processor 81 updates the damage value of the voxel. For example, processor 81 adds 1 to the damage value of the voxel. The damage value to be added may differ based on the hardness of the destruction action and the hardness of the material. If the processing of step S35 results in no voxel satisfying the above-mentioned predetermined criteria being present within the collision range, damage values ​​are added to voxels within the destruction range without updating their densities. A display indicating that damage has been added may be displayed on the mesh of the voxel to which the damage value has been added. Following step S35, the processing of step S37 is executed.

[0166] In step S36, processor 81 updates the density of the voxel to a value indicating that a voxel object does not exist. For example, if the voxel is completely contained within the destruction range (if the voxel exists inside the destruction range), processor 81 sets the density of the voxel to "0." Also, if a portion of the voxel is contained within the destruction range (if the voxel exists on the boundary of the destruction range), processor 81 updates the density of the voxel to a value equal to or less than a reference value, for example. If the hardness DH of the destruction action is equal to or greater than the hardness MH of the voxel's material, step S32 is determined to be YES, and the process of step S36 is performed. As a result, the voxel is destroyed by a single destruction action without adding a damage value to the voxel. Also, if the determination of step S34 is YES, the process of step S36 is performed. As a result, even if a voxel would normally have a damage value added because it satisfies the second condition (voxel MH-DH<predetermined value), if there is a voxel within the collision range that meets the above-mentioned predetermined criteria, the voxel within the destruction range will be destroyed.

[0167] Note that, if a voxel satisfying the predetermined criterion exists within the collision range, the processing of step S36 is executed for voxels whose hardness is equal to or less than the voxel satisfying the predetermined criterion. For example, suppose that within the destruction range corresponding to the current destruction action, there is a voxel with a hardness of "3" and a voxel with a hardness of "2." The voxel with a hardness of "3" is determined to satisfy the predetermined criterion. That is, if a damage value is added to the voxel with a hardness of "3" in accordance with the current destruction action, the resulting damage value is determined to be equal to or greater than the threshold value, and the voxel is stored as reference voxel data. In this case, the density of other voxels with a hardness of "3" within the destruction range is updated even if the damage value does not exceed the threshold value due to the current destruction action. For example, even if the current damage value of other voxels with a hardness of "3" within the destruction range is "0," the processing of step S36 is executed and the voxel is destroyed. Furthermore, for voxels with a hardness of "2" within the destruction range, the MH-DH value satisfies the predetermined value. Therefore, the process of step S36 is executed to destroy voxels within the destruction range that have a hardness of "2." That is, voxels that have a hardness less than the hardness of voxels that satisfy the predetermined criterion are also destroyed.

[0168] When the process of step S36 has been performed, when the process of step S35 has been performed, or when the determination in step S33 is NO, the processor 81 executes the process of step S37.

[0169] In step S37, processor 81 determines whether or not the processing of steps S31 to S36 has been completed for all voxels included in the destruction range among the multiple voxels in the voxel space corresponding to the voxel object hit by the destruction action. If the determination result of step S37 is positive, the processing shown in Fig. 26 is terminated. On the other hand, if the determination result of step S37 is negative, processor 81 changes the voxel to be processed among the voxels within the destruction range, and executes the processing of step S31 again.

[0170] The processing shown in the above flowchart is merely an example, and the order and content of the processing may be changed as appropriate.

[0171] As described above, in this embodiment, if there is at least one voxel within the destruction range set by the current destruction action that satisfies a predetermined criterion for damage value (step S25: YES), the voxel values ​​of voxels within the destruction range that have a hardness equal to or less than that of the voxels that satisfy the predetermined criterion are updated to a density that indicates that no object is present. Voxels that satisfy the predetermined criterion are voxels whose damage value will be equal to or greater than a limit value due to the current destruction action. This prevents the voxel object from becoming distorted after destruction by destroying only voxels whose damage value is equal to or greater than the limit value due to the current destruction action.

[0172] In this embodiment, before the damage value of a voxel is actually added by the current destruction action, it is determined whether or not there are any voxels that will satisfy a predetermined criterion due to the current destruction action. This makes it possible to determine whether or not there are any voxels that satisfy the predetermined criterion without actually adding a damage value to the voxels, thereby reducing the processing load.

[0173] In this embodiment, instead of determining whether all voxels in the destruction range satisfy a predetermined criterion, it is determined whether some voxels (voxels forming the surface of the voxel object) included in the destruction range satisfy a predetermined criterion, thereby reducing the processing load.

[0174] (Variation) Although the present embodiment has been described above, the above embodiment is merely an example, and the following modifications may be made, for example.

[0175] For example, in the above embodiment, a damage value is assigned to a voxel, and a destruction action adds to the damage value. If the damage value exceeds a predetermined limit, the voxel is destroyed. In another embodiment, a durability value may be assigned to a voxel, and a destruction action reduces the durability value. If the durability value falls below a predetermined value, the voxel is destroyed. An increase in the damage value due to a destruction action and a decrease in the durability value due to a destruction action have the same technical significance. To record the increase in damage inflicted on a voxel, a damage value that increases in response to a destruction action or a durability value that decreases in response to a destruction action may be used.

[0176] That is, when a destructive action hits a voxel object, the voxel value may be updated to a damage value that indicates increased damage. "Updating the voxel value to a damage value that indicates increased damage" includes increasing the damage value set in the voxel and decreasing the durability value set in the voxel.

[0177] In the above embodiment, when a voxel is destroyed when its damage value exceeds a threshold, a voxel that satisfies the predetermined criteria is a voxel whose damage value exceeds a predetermined threshold when increased by a destruction action. When a voxel is destroyed when its durability value falls below a predetermined threshold, a voxel that satisfies the predetermined criteria is a voxel whose durability value falls below a predetermined threshold when damaged by a destruction action. In other words, a voxel that satisfies the predetermined criteria is a voxel whose damage exceeds a predetermined damage upper limit when increased by a destruction action. Here, "the damage of a voxel exceeds the damage upper limit" includes both the damage value of a voxel exceeding a threshold and the durability value of a voxel falling below a predetermined value.

[0178] In the above embodiment, before actually updating the damage values ​​of voxels within the destruction range, it is determined whether or not some voxels within the destruction range have a damage value that satisfies a predetermined criterion. In other embodiments, a similar process may be performed for all voxels within the destruction range. That is, it may be determined whether or not all voxels within the destruction range have a voxel that satisfies a predetermined criterion. Furthermore, the damage values ​​of voxels within the destruction range may be updated, and if there are voxels whose updated damage values ​​are equal to or greater than a limit value, the voxels within the destruction range may be destroyed.

[0179] In the above embodiment, when a destruction action hits a voxel object, if there is at least one voxel that satisfies a predetermined criterion regarding the damage value, the density of voxels within the destruction range is updated. In other embodiments, the density of voxels within the destruction range may be updated if there are a predetermined number of voxels that satisfy a predetermined criterion regarding the damage value.

[0180] In the above embodiment, whether to destroy or damage a voxel object when a destructive action hits a voxel object is determined based on the relationship between the hardness of the destructive action and the hardness of the voxel material. In other embodiments, whether to destroy or damage a voxel object when a destructive action hits a voxel object may be determined based only on the hardness of the material of the voxel being destroyed.

[0181] In the above embodiment, when a destruction action hits a voxel object and a voxel that satisfies a predetermined criterion is present, the density of voxels having a hardness equal to or less than the "hardness" of the voxel that satisfies the predetermined criterion is updated. In other embodiments, when a voxel that satisfies the predetermined criterion is present, the density of voxels having a hardness equal to or less than the predetermined hardness may be updated. Furthermore, the above process may be performed based on the material, not just the "hardness" of the material. For example, when a voxel that satisfies the predetermined criterion is present, the density of voxels having a predetermined material may be updated. For example, there are multiple materials, and the relationship between the materials is predetermined. When a voxel that satisfies the predetermined criterion is present, the density of voxels having a material that has a predetermined relationship with the material of the voxel that satisfies the predetermined criterion may be updated.

[0182] In the above embodiment, a case where a destruction action is performed on a terrain object on which the player character can move is described. However, the same processing is performed when a destruction action hits a voxel object other than a terrain object. That is, when a destruction action hits a voxel object, if there are voxels that satisfy a predetermined criterion for the damage value, the density of the voxels within the destruction range is updated. On the other hand, if there are no voxels that satisfy the predetermined criterion, the damage value is increased for the voxels within the destruction range.

[0183] In the above embodiment, the density of voxels within the destruction range was set to "0," thereby setting a value indicating that no object exists in the voxel. This erases the portion of the voxel object within the destruction range, destroying the voxel object. Destruction (erasure) of a voxel object is not limited to setting the density in the voxel data to "0," but may also be performed by setting the density to another value. For example, with regard to density, the "value indicating the absence of an object" is not limited to "0" but may be any value less than a reference value (e.g., 128). With regard to density, the "value indicating the presence of an object" may be a value in the range of 1 to 255, or may be a value equal to or greater than the reference value. Furthermore, destruction of a voxel object may be performed by other methods, not limited to changing the density in the voxel data. For example, a flag indicating the presence or absence of an object may be stored in the voxel data, and when the flag is ON, it indicates that an object exists in the voxel, and when the flag is OFF, it indicates that no object exists in the voxel (i.e., a cavity).

[0184] Furthermore, the above-described processing may be executed in any other information processing device or information processing system, not limited to the game system 1. The information processing system may be configured by multiple devices, and the multiple devices may be connected via a network (for example, a LAN, the Internet, etc.).

[0185] Furthermore, the configurations according to the above-described embodiments and their modifications can be combined in any manner as long as they are not inconsistent with each other. Furthermore, the above is merely an example of the present invention, and various other improvements and modifications may be made thereto. [Explanation of symbols]

[0186] 1. Game System 81 processors 85 DRAM 201, 202, 203, 204 voxels 210, 220 Terrain objects

Claims

1. A game program executed by a processor of an information processing device, the processor storing, in a storage medium, volume data that is data for representing a virtual object in a virtual space, and holds voxel values ​​for each voxel included in a voxel space arranged in the virtual space, the voxel values ​​including at least a density indicating the degree to which the object occupies a space defined by the voxel and a damage value indicating damage inflicted on the voxel; moving a player character within the virtual space based on an operation input by a player; making the player character perform a destructive action based on an operation input by the player; If the destruction action hits the virtual object, when there is a voxel that satisfies a predetermined criterion with respect to at least the damage value, updating the voxel values ​​of voxels included in an erasure range that is set based on the position of the player character so that the voxel values ​​have a density that indicates that the virtual object does not exist; If there is no voxel that satisfies the predetermined criterion, the voxel value is updated so that the voxel value is a damage value that indicates that damage has been increased for the voxels included in the erasure range; a game program that generates an image of the virtual space by drawing at least a polygon mesh that represents a surface of the virtual object based on the volume data;

2. The game program according to claim 1 , wherein the voxels that satisfy the predetermined criteria are voxels whose damage, when increased by the destruction action, exceeds a preset damage upper limit.

3. the processor further determines a hit position at which the destruction action hits the virtual object when the destruction action is performed; 3. The game program according to claim 1, wherein the voxels that satisfy the predetermined criteria are voxels within a predetermined range that includes the hit position and have a predetermined damage value.

4. 4. The game program according to claim 3, wherein the processor performs a collision detection between the polygon mesh or a determination polygon mesh representing a surface of the virtual object generated for the detection and a determination shape set based on the destruction action, and determines the hit position.

5. the voxel values ​​further include data indicative of the hardness or material of the voxel; the processor, 2. The game program according to claim 1, wherein, when the destruction action hits the virtual object, if there is a voxel that satisfies the predetermined criterion, the voxel values ​​of voxels that have a hardness equal to or less than a predetermined hardness or a predetermined type of material are updated so that the density indicates that the virtual object is not present.

6. The game program according to claim 1 , wherein the erasure area has a shape of a sphere, an ellipsoid, or an asymmetrically deformed ellipsoid.

7. The game program according to claim 1 , wherein the virtual object is a terrain in the virtual space.

8. the processor, generating the polygon mesh using an algorithm that arranges polygons so that vertex positions are determined between voxels defined as inside the virtual object and voxels defined as outside the virtual object based on the density; The game program according to claim 1 , wherein, when the destruction action is performed, vertices of the polygon mesh in a range including at least the voxel whose voxel value has been updated are recalculated.

9. An information processing system comprising a storage medium and at least one processor, The processor: storing, in the storage medium, volume data that represents a virtual object in a virtual space, the volume data holding voxel values ​​for each voxel included in a voxel space arranged in the virtual space, the voxel values ​​including at least a density that indicates the degree to which the object occupies a space defined by the voxel and a damage value that indicates damage inflicted on the voxel; moving a player character within the virtual space based on an operation input by a player; making the player character perform a destructive action based on an operation input by the player; If the destruction action hits the virtual object, When there is a voxel that satisfies a predetermined criterion with respect to at least the damage value, the voxel value is updated for voxels included in an erasure range that is set based on the position of the player character so that the voxel value has a density that indicates that the virtual object is not present; If there is no voxel that satisfies the predetermined criterion, update the voxel value to a damage value that indicates that damage has been increased for the voxels included in the erasure range; an information processing system that generates an image of the virtual space by drawing at least a polygon mesh that represents a surface of the virtual object based on the volume data;

10. The information processing system according to claim 9 , wherein the voxels that satisfy the predetermined criteria are voxels whose damage, when increased by the destructive action, exceeds a preset damage upper limit.

11. the processor determines a hit position at which the destruction action will hit the virtual object when the destruction action is performed; The information processing system according to claim 9 or 10, wherein the voxels that satisfy the predetermined criteria are voxels within a predetermined range including the hit position and have a predetermined damage value.

12. 12. The information processing system according to claim 11, wherein the processor performs a collision detection between the polygon mesh or a determination polygon mesh representing a surface of the virtual object generated for determination and a determination shape that is set based on the destruction action, and determines the hit position.

13. the voxel values ​​further include data indicative of the hardness or material of the voxel; The processor:

10. The information processing system according to claim 9, wherein, when the destruction action hits the virtual object, if there is a voxel that satisfies the predetermined criterion, the voxel values ​​of voxels that have a hardness equal to or less than a predetermined hardness or a predetermined type of material are updated so that the density indicates that the virtual object does not exist.

14. The information processing system according to claim 9 , wherein the erasure range has a shape of a sphere, an ellipsoid, or an asymmetrically deformed ellipsoid.

15. The information processing system according to claim 9 , wherein the virtual object is a terrain in the virtual space.

16. The processor: generating the polygon mesh using an algorithm that arranges polygons so that vertex positions are determined between voxels defined as inside the virtual object and voxels defined as outside the virtual object based on the density; The information processing system according to claim 9 , wherein, when the destructive action is performed, the vertices of the polygon mesh in a range including at least the voxel whose voxel value has been updated are recalculated.

17. storing volume data that is data for representing a virtual object in a virtual space, and holds voxel values ​​for each voxel included in a voxel space arranged in the virtual space, the voxel values ​​including at least a density indicating the degree to which the object occupies a space defined by the voxel and a damage value indicating damage inflicted on the voxel; moving a player character within the virtual space based on an operation input by a player; making the player character perform a destructive action based on an operation input by the player; If the destruction action hits the virtual object, when there is a voxel that satisfies a predetermined criterion with respect to at least the damage value, updating the voxel values ​​of voxels included in an erasure range that is set based on the position of the player character so that the voxel values ​​have a density that indicates that the virtual object does not exist; If there is no voxel that satisfies the predetermined criterion, the voxel value is updated so that the voxel value is a damage value that indicates that damage has been increased for the voxels included in the erasure range; an information processing device that generates an image of the virtual space by drawing at least a polygon mesh that represents a surface of the virtual object based on the volume data.

18. The information processing device according to claim 17 , wherein the voxels that satisfy the predetermined criteria are voxels whose damage, when increased by the destructive action, exceeds a preset damage upper limit.

19. determining a hit position where the destruction action hits the virtual object when the destruction action is performed; The information processing device according to claim 17 or 18, wherein the voxels that satisfy the predetermined criteria are voxels within a predetermined range that includes the hit position and have a predetermined damage value.

20. An information processing method performed in an information processing system, The information processing system stores volume data that is data for representing a virtual object in a virtual space, and holds voxel values ​​for each voxel included in a voxel space arranged in the virtual space, the voxel values ​​including at least a density indicating the degree to which the object occupies a space defined by the voxel and a damage value indicating damage inflicted on the voxel; moving a player character within the virtual space based on an operation input by a player; causing the player character to perform a destructive action based on an operation input by a player; If the destruction action hits the virtual object, When there is a voxel that satisfies a predetermined standard with respect to at least the damage value, updating the voxel values ​​of voxels included in an erasure range that is set based on the position of the player character so that the voxel values ​​have a density that indicates that the virtual object does not exist; If there is no voxel that satisfies the predetermined criterion, updating the voxel value for the voxel included in the erasure range to a damage value that indicates increased damage; generating an image of the virtual space by drawing at least a polygon mesh representing a surface of the virtual object based on the volume data.

21. The information processing method according to claim 20 , wherein the voxels that satisfy the predetermined criteria are voxels whose damage, when increased by the destructive action, exceeds a preset damage upper limit.

22. determining a hit position where the destruction action hits the virtual object when the destruction action is performed; 22. The information processing method according to claim 20, wherein the voxels that satisfy the predetermined criteria are voxels within a predetermined range including the hit position and have a predetermined damage value.

Images