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

Abstract

This system provides a mechanism to suppress distortion of the object's shape after destruction when an object is destroyed through multiple instructions from the player in a voxel-based game. [Solution] One example of an information processing system is that when a player character's destruction action hits a virtual object, the damage value of the voxels within the destruction range is updated, and if the damage value reaches a limit, the virtual object within the destruction range is destroyed. When a player character's destruction action hits a virtual object, if there are voxels that meet a predetermined standard regarding damage value, the density of voxels included in the destruction range is updated, and the virtual object within the destruction range is destroyed.

Description

Technical Field

[0001] The present invention relates to a game program, an information processing system, an information processing apparatus, and an information processing method capable of generating an image using voxels.

Background Art

[0002] Conventionally, there is a game that creates character voxels based on imaging information and generates polygon mesh information (see, for example, Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in the above prior art, voxels are used to generate an object from imaging information, and the object is not freely deformed using voxel data.

[0005] Therefore, an object of the present invention is to suppress distortion of the shape after destruction when an object is destroyed through a plurality of instructions by a player in a game in which an object can be freely destroyed using voxels, and to provide a game program, an information processing system, an information processing apparatus, and an information processing method.

Means for Solving the Problems

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

[0007] The game program of the present invention is a game program executed in the processor of an information processing device. The game program causes the processor to store volume data in a storage medium, which is data for representing virtual objects in a virtual space, and for each voxel included in the voxel space arranged in the virtual space, the voxel value holds at least a density indicating the degree to which an object occupies the space defined by the voxel, and a damage value indicating the damage inflicted on the voxel. The game program also causes the processor to move a player character in the virtual space based on the player's input, cause the player character to perform a destruction action based on the player's input, and when the destruction action hits a virtual object, if there are voxels that satisfy a predetermined criterion with respect to at least the damage value, the game program causes the processor to update the voxel value so that the density of voxels included in the erasure range set based on the player character's position indicates that the virtual object does not exist, and if there are no voxels that satisfy the predetermined criterion, the game program causes the processor to update the voxel value so that the damage to the voxels included in the erasure range indicates that the damage has increased. The game program then causes the processor to generate an image of the virtual space by drawing at least a polygon mesh representing 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 meet a predetermined standard for damage value, the voxel values ​​of the voxels included in the erasure range can be updated to a density that indicates the absence of the virtual object. As a result, if there are voxels that meet the predetermined standard for damage value, the voxel objects within the erasure range can be erased even if there are voxels that do not meet the predetermined standard, thereby suppressing the distortion of the voxel object's shape after the destruction action.

[0009] Furthermore, a voxel that meets the predetermined criteria may be a voxel whose damage, when increased by the destruction action, exceeds a predetermined damage limit.

[0010] According to the above, if the damage increased by this destruction action exceeds the damage limit, the voxel objects within the erasure range can be erased, and a decision can be made on whether to erase the voxel objects within the erasure range before actually dealing damage to the voxels.

[0011] Furthermore, the computer may be instructed to determine the hit location where the destruction action strikes the virtual object when the destruction action is performed. A voxel that satisfies the predetermined criteria may be a voxel within a predetermined range including the hit location, and may have a predetermined damage value.

[0012] According to the above, the hit location where a destruction action strikes a virtual object can be determined, and based on the damage value of the voxels within a predetermined range including that hit location, it can be determined whether or not there are voxels that meet a predetermined criterion. This can, for example, reduce the processing load.

[0013] Alternatively, the computer may be instructed to perform contact detection between the polygon mesh or the determination polygon mesh representing the surface of the virtual object generated for determination and the determination shape set based on the destruction action, and to determine the hit position.

[0014] According to the above, contact detection with a polygon mesh or a detection polygon mesh can be performed using a determination shape based on a destruction action.

[0015] Furthermore, the voxel value may further include data indicating the hardness or material of the voxel. The computer may be instructed to update the voxel value to indicate that the virtual object does not exist for voxels having a hardness of less than or equal to a predetermined hardness or a predetermined type of material, if there are voxels that meet the predetermined criteria when the destruction action hits the virtual object.

[0016] According to the above, if there are voxels that meet the predetermined criteria, voxels within the erasure range that have a hardness of less than or equal to a predetermined hardness or have a predetermined type of material can be destroyed. This allows for the destruction of virtual objects while taking into account the hardness or material of the voxels.

[0017] Furthermore, the erasure area may be a sphere, an ellipsoid, or a shape obtained by asymmetrically deforming an ellipsoid.

[0018] According to the above, the erasure area can be 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 to be a natural shape.

[0019] Furthermore, the virtual object may be the terrain within the virtual space.

[0020] According to the above, terrain objects can be destroyed.

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

[0022] According to the above, a polygon mesh representing a virtual object can be generated, and when a destruction action is performed, the vertices of the polygon mesh are recalculated, so that the virtual object after the destruction action can be represented.

[0023] Further, another invention may be an information processing system that executes the above game program, or an information processing device, or an information processing method.

Effect of the Invention

[0024] According to the present invention, when a destruction action hits a virtual object, if there are voxels that meet a predetermined standard regarding damage values, the voxel objects within the deletion range can be deleted, and it is possible to suppress the voxel objects after the destruction action from having a distorted shape.

Brief Description of the Drawings

[0025] [Figure 1] A diagram showing an example of a state in which the left controller 3 and the right controller 4 are attached to the main body device 2 [Figure 2] A diagram showing an example of a state in which the left controller 3 and the right controller 4 are each removed from the main body device 2 [Figure 3] A six-sided view showing an example of the main body device 2 [Figure 4] A six-sided view showing an example of the left controller 3 [Figure 5] A six-sided view showing an example of the right controller 4 [Figure 6] A block diagram showing an example of the internal configuration of the main body device 2 [Figure 7] A block diagram showing an example of the internal configurations of the main body device 2, the left controller 3, and the right controller 4 [Figure 8] A diagram showing an example of a terrain object that is a voxel object [Figure 9] A diagram showing an example of the state before and after a part of the terrain object shown in FIG. 8 is deleted [Figure 10]Figure 8 shows an example of what the terrain object looks like before and after a portion of it 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 that indicates the properties of a material. [Figure 13] A diagram showing an example of texture information that indicates the texture of a material. [Figure 14] A diagram showing an example of a mesh generation method. [Figure 15] A diagram showing an example of a game image that includes terrain objects. [Figure 16] This figure shows an example of a game image displayed on a display device, representing the game space in the game of this embodiment as seen from a virtual camera. [Figure 17] This diagram shows the state after the player character PC's first punch hit terrain object 220, causing damage to the terrain object 220. [Figure 18] This diagram shows the state after the player character PC's second punch hit terrain object 220, causing damage to the terrain object 220. [Figure 19] This diagram shows the damage state of terrain object 220 when the player character PC's third punch hits terrain object 220. [Figure 20] This diagram shows the state after terrain object 220 has been destroyed by the player character PC's third punch. [Figure 21] Diagram showing the process flow for voxel destruction. [Figure 22] This diagram illustrates an example of density updating when a destruction action is performed on a voxel object composed of multiple materials with different hardnesses, and there are voxels that meet a predetermined criterion for damage value. [Figure 23] This diagram shows an example of various types of data used in information processing in Game System 1. [Figure 24]A flowchart illustrating an example of the game processing flow executed by Game System 1. [Figure 25] A flowchart showing an example of the destruction detection process in step S5. [Figure 26] A flowchart showing an example of the voxel data update process in step S7. [Modes for carrying out the invention]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0047] The main unit 2 is equipped with a slot interface (hereinafter abbreviated as "I / F") 91. The slot I / F 91 is connected to the processor 81. The slot I / F 91 is connected to slot 23 and reads and writes data to a predetermined type of storage medium (for example, a dedicated memory card) installed in slot 23, according to instructions from the processor 81.

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

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

[0050] The main unit 2 includes a controller communication unit 83. The controller communication unit 83 is connected to the processor 81. The controller communication unit 83 communicates wirelessly with the left controller 3 and / or the right controller 4. The communication method between the main unit 2 and the left controller 3 and the right controller 4 is arbitrary, but in this embodiment, the controller communication unit 83 communicates with the left controller 3 and with the right controller 4 in accordance with the Bluetooth® standard.

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

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

[0053] The display 12 is also connected to the processor 81. The processor 81 displays images generated (for example, by performing the above information processing) and / or images acquired from an external source on the display 12.

[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 terminals 25, as well as to the processor 81. The codec circuit 87 is a circuit that controls the input and output of audio data to the speakers 88 and the audio input / output terminals 25.

[0055] The main unit 2 comprises a power control unit 97 and a battery 98. The power control unit 97 is connected to the battery 98 and the processor 81. Although not shown in the figures, the power control unit 97 is also connected to various parts of the main unit 2 (specifically, the parts that receive power from the battery 98, the left terminal 17, and the right terminal 21). Based on commands from the processor 81, the power control unit 97 controls the power supply from the battery 98 to the aforementioned parts.

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

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

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

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

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

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

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

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

[0064] As shown in Figure 7, the right controller 4 includes a communication control unit 111 that communicates with the main unit 2. The right controller 4 also includes a memory 112 connected to the communication control unit 111. The communication control unit 111 is connected to each component, including the terminal 64. The communication control unit 111 and the memory 112 have the same functions as the communication control unit 101 and memory 102 of the left controller 3. Therefore, the communication control unit 111 can communicate with the main unit 2 both by wired communication via the terminal 64 and by wireless communication without the terminal 64 (specifically, communication according to the Bluetooth® standard), and controls the method of communication that the right controller 4 performs with the main unit 2.

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

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

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

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

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

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

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

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

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

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

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

[0076] In other embodiments, density may indicate either a state where the entire region within the voxel is occupied by voxel objects, or a state where the region within the voxel is not contained by voxel objects. For example, density data may only take the form of either 0 or 1.

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

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

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

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

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

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

[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 up multiple types of materials that have the same properties but different appearances (i.e., textures), or multiple types of materials that have different properties but the same appearance.

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

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

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

[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) placed in the game space. In this embodiment, the game system 1 generates a mesh for a voxel object based on the voxel data of each voxel set in the game space. An example of generating a mesh based on voxel data is described below.

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

[0089] As described above, in this embodiment, the density set for a voxel is set within the range of 0 to 255. In this embodiment, voxels with a density equal to or greater than the reference value are considered to be inside the object, and voxels with a density less than the reference value are considered to be outside the object. It is not necessary to define only voxels with a density of 0 as being outside the object (i.e., reference value = 1), and the reference value can be, for example, 128. In the example shown in Figure 14, the density of voxel 201 and the other outer voxels is set to 0, the density of voxel 202 is set to 100 (less than the reference value), and the densities of voxels 203 and 204 are set to 150 and 200 (greater than or equal to the reference value). In this embodiment, the game system 1 generates vertices between voxels with a density equal to or greater than the reference value and voxels with a density less than the reference value. Specifically, for each region spanning eight adjacent voxels (four in the diagram) (the region enclosed by the dotted line in the diagram), a determination is made as to whether or not to generate a vertex. In other words, vertices are generated in regions that span both voxels with a density above a certain threshold and voxels with a density below that threshold. Furthermore, if the boundary between adjacent vertices (the boundary of the region containing each vertex) passes through a range of voxels with a density above a certain threshold and voxels with a density below that threshold, 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 density difference. At this time, coordinate calculations can also be performed based on normal information, but the normal information may be stored in advance for at least some of the voxels, or if it is not stored, the normal information may also be calculated based on the densities of adjacent voxels. Note that in Figure 14, since the density of voxel 202 is below the threshold, voxel 202 is treated as outside the object when determining the presence or absence of a vertex, but the density value of voxel 202 itself is used in the calculation of the coordinates of the generated vertices. If the baseline value is set lower than the density of voxel 202, the result will be that more vertices will be added to the upper right and upper left sides of voxel 202 in Figure 14.

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

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

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

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

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

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

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

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

[0098] When the game starts, a fixed voxel space is set up in the game space, defined in an Xs-Ys-Zs coordinate system, to represent the field. The Xs-Ys-Zs coordinate system is assumed to have axes parallel to the XYZ coordinate system of the game space. That is, the Ys axis is the axis pointing upwards in the game space, and the Xs and Zs axes are axes perpendicular to the Ys axis. The voxel space defined in the Xs-Ys-Zs coordinate system may be referred to as the "field voxel space" below. The position of each object in the game space is represented by coordinate values ​​in the Xs-Ys-Zs coordinate system. Note that, here, 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, but they do not have to coincide.

[0099] In the field voxel space, terrain objects are set as voxel objects. For example, terrain object 210 representing the ground and terrain object 220 representing a rocky mountain are set as terrain objects. For example, by setting material data representing rock to the voxel data of each voxel located below in the field voxel space, terrain object 210 representing a rocky ground is formed. Also, by setting material data representing rock to the voxel data of multiple voxels located above the ground in the field voxel space, terrain object 220 representing a rocky mountain rising from the ground is formed.

[0100] The player character (PC) can move on terrain objects according to the player's instructions. Additionally, the player character (PC) can perform destructive actions according to the player's instructions.

[0101] When a player character's (PC) destruction action hits a voxel object, the action can either destroy the voxel object or inflict damage on it. If damage is inflicted on the voxel object, and the amount of damage reaches a certain limit, the voxel object will be destroyed; otherwise, the voxel object will not be 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 the destruction action hits the 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, which is 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] Figure 17 shows the state after the terrain object 220 has been damaged by the player character PC's first punch. Figure 18 shows the state after the terrain object 220 has been damaged by the player character PC's second punch. Figure 19 shows the state of damage to the terrain object 220 after the player character PC's third punch. Figure 20 shows the state after the terrain object 220 has been destroyed by the player character PC's third punch. Figures 17 to 20 show a two-dimensional representation of the terrain object 220 as viewed from the front.

[0106] As shown in Figure 17, when a player character PC's punch hits terrain object 220, a destruction range DR is set based on the hit location, and damage is dealt to voxels contained within the destruction range DR. Each voxel stores a damage value dm. For example, the first punch adds 1 to the damage value dm of voxels contained within destruction range DR1. The damage value of a voxel is increased each time a destruction action is performed, and when the damage value reaches the limit value of "3", the voxel is destroyed. Therefore, when a player character PC punches the same location as in Figure 17, the voxels within destruction range DR1 are destroyed in response to the third punch. In other words, the density of voxels within destruction range DR1 is updated to a value indicating that no object exists.

[0107] If the second punch hits a different location than the first punch, as shown in Figure 18, the destruction range DR2 is set according to the location where the second punch hits, and a damage value of "1" is added to the voxels included in the destruction range DR2. Since the first punch has already added a damage value of "1" to the destruction range DR1, the damage value for the overlapping area between destruction range DR1 and destruction range DR2 becomes "2". For voxels within the destruction range DR2 outside of this overlapping area, the damage value becomes "1". In this state, the damage value of all voxels in terrain object 220 is less than the limit value of "3", so none of the voxels are destroyed.

[0108] Next, suppose the player character PC makes a third punch, and this third punch hits terrain object 220. As shown in Figure 19, if the location where the third punch hits is different from the locations where the first and second punches hit, damage will be added to the voxels within the destruction range DR3, which is set according to the hit location of the third punch. In this case, the damage value will be "3" for the overlapping areas of the three destruction ranges DR1 to DR3, "2" for the overlapping areas of the two destruction ranges DR1 and DR3, "2" for the overlapping areas of the two destruction ranges DR2 and DR3, and "1" for the remaining areas of destruction range DR3. In other words, within the destruction range DR3 set according to the third punch, there will be voxels with a damage value of "1", voxels with a damage value of "2", and voxels with a damage value of "3". 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, and all voxels within the destruction range DR3 are destroyed.

[0109] In other words, if there are voxels whose damage value exceeds the limit of "3" due to the third punch, all voxels within the destruction range DR3, including those that have not yet reached the limit, are destroyed (erased). As a result, as shown in Figure 20, no objects remain in the destruction range DR3 set in response to the third punch, and a cavity with the same or similar shape as the destruction range DR3 is created in the terrain object 220. On the other hand, the area DR1, which was damaged by the first punch, and the area DR2, which was damaged by the second punch, are not destroyed, and the damage continues to accumulate.

[0110] If, in Figure 19, only voxels whose damage value reaches the limit of "3" are destroyed, the shape of the destroyed voxel object will become distorted. Also, the destruction range may become narrower, making the gameplay more difficult. Furthermore, if the destruction occurs at a location slightly off from the hit point of the third punch, voxels around the hit point may remain, potentially causing the player to feel uneasy.

[0111] Therefore, in this embodiment, assuming that damage values ​​are added by the current destruction action, if there are voxels whose damage values ​​exceed a limit value, the voxels within the destruction range set according to the current destruction action are destroyed. Specifically, among all voxels within the destruction range set according to the current destruction action, voxels with a hardness less than or equal to the hardness of the voxel whose damage value exceeds the limit value are destroyed. This prevents only the voxel at a location offset from the hit position from being destroyed, and prevents the voxel object from becoming distorted after destruction.

[0112] Next, we will explain the process flow until a voxel is destroyed, referring to Figure 21. Figure 21 is a diagram showing the process flow related to voxel destruction.

[0113] As shown in Figure 21(a), when the player character PC makes a punch, a collision detection shape used for collision detection with other objects is launched. 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 is a sphere, cylinder, disc, cone, or polygonal pyramid containing the position of the player character PC's fist, and is launched into the virtual space in response to the punch. Once the collision detection shape is launched, it is determined whether or not it 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] Furthermore, a separate polygon mesh may be provided for voxel objects, in addition to the polygon mesh that forms the surface, to determine contact (collision) with other objects. In this case, collision detection is performed between the collision detection shape and the detection polygon mesh. The collision detection shape may have different sizes and shapes depending on the type of destruction action.

[0115] As shown in Figure 21(b), when the collision detection shape collides with the terrain object 220, the collision area is identified. Specifically, the area where the collision detection shape and the polygon mesh of the terrain object 220 collide is identified. The collision area identified here is the surface of the terrain object 220.

[0116] Next, as shown in Figure 21(c), for each voxel within the identified collision range, it is checked whether there are any voxels that satisfy a predetermined criterion regarding damage value. A voxel that satisfies the predetermined criterion is a voxel that is damaged by the punch (i.e., a voxel that satisfies the second condition above) and whose damage value exceeds the limit 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 satisfy the second condition) are extracted. Then, based on the current damage value of the extracted voxels, it is determined whether the damage value will exceed the limit value when the current punch is added.

[0117] As shown in Figure 21(d), if there is a voxel in each voxel within the collision range that satisfies the predetermined criteria, the 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 has a different shape from the collision detection shape, and may be, for example, a sphere, an ellipsoid, or an ellipsoid that is asymmetrical in a predetermined direction. Then, for all voxels within the destruction range DR that have a hardness less than or equal to the hardness of a voxel that satisfies the predetermined criteria, the density is set to a value that indicates the absence of an object. Specifically, for voxels located inside the destruction range DR, the density is set to "0", and for voxels located at the boundary of the destruction range DR, for example, the density is reduced to a value less than or equal to the standard value (it may also be above the standard value). As a result, the voxel objects included in the destruction range DR are destroyed (erased).

[0118] On the other hand, if no voxels satisfying the above-mentioned predetermined criteria exist within the collision range, then the voxels that satisfy the above-mentioned second condition and are included within the destruction range DR will not be destroyed (their density will not be updated), and their damage value will be added.

[0119] Furthermore, voxels that satisfy the first condition above (voxels where the punch's hardness DH is equal to or greater than the material's hardness MH) will be destroyed. In other words, voxels made of materials that are the same hardness as or softer than the punch will be destroyed by this punch regardless of the damage value. Also, for voxels that do not satisfy either the first or second condition, neither density updates nor damage values ​​are added. In other words, voxels made of materials that are sufficiently hard compared to the punch's hardness (for example, iron) will not have their damage values ​​added and will not be destroyed.

[0120] Figure 22 shows an example of density updating when a destruction action is performed on a voxel object composed of multiple materials with different hardnesses, and there are voxels that meet a predetermined criterion for damage value.

[0121] As shown in Figure 22, consider a case where a punch hits a voxel object made up of materials with hardness levels "2", "3", and "4". If there are voxels within the destruction range DR corresponding to this punch that meet a predetermined standard for damage value, then among the voxels within the destruction range DR, those with the same hardness level "3" as the voxel determined to meet the predetermined standard will have their density updated and be destroyed as described above. Also, voxels with a hardness level "2" that is lower than the hardness level "3" of the voxel determined to meet the predetermined standard will also be destroyed. On the other hand, for voxels with a hardness level "4", the difference between the voxel's hardness "4" and the punch's hardness "2" is greater than or equal to a predetermined value, so the density is not updated and no damage value is added. As a result, as shown in the lower part of Figure 22, the voxel object after the density update will have a shape where part of the destruction range DR is missing, and a cavity of that shape will be formed.

[0122] Thus, in this embodiment, each voxel is assigned a voxel value that includes a density indicating the degree to which an object occupies the space defined by the voxel, and a damage value indicating the damage inflicted on the voxel. When a destruction action hits a voxel object, the damage value is added to the voxel, and when the accumulated damage value in the voxel through multiple destruction actions reaches a limit, 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, which is set based on the position of the player character PC, are deleted. If there are no voxels that meet the predetermined criterion, the damage value is added to the voxels included in the destruction range.

[0123] This makes it possible to suppress the distortion of the shape of voxel objects after they are destroyed by multiple destruction actions in games where voxel objects are destroyed by multiple destruction actions.

[0124] Furthermore, in this embodiment, when a destruction action is performed, a collision determination is first performed using the collision determination shape, and it is determined whether or not there are voxels that satisfy the predetermined criteria only within the collision range (the surface of the voxel object) identified in the collision determination. If it is determined that there are voxels that satisfy the predetermined criteria, the voxels within the destruction range that extends inside the voxel object are deleted. Since it is determined whether or not there are voxels that satisfy the predetermined criteria only for a part of the voxel object, the computational load can be reduced.

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

[0126] [3. Specific examples of processing in game systems] Next, we will explain specific examples of information processing in game system 1 with reference to Figures 23 to 26.

[0127] Figure 23 shows an example of various data used for information processing in game system 1. As shown in Figure 23, game system 1 stores 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 Figure 24). The game program is pre-stored in a storage medium or flash memory 84 installed in slot 23 and is loaded into the DRAM 85 when the game is executed.

[0129] Game space data is data used to define the game space and includes data representing the XYZ coordinate system described above.

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

[0131] Furthermore, the field voxel space data 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 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 terrain in the game space. Initial first volume data is pre-stored in the storage medium or flash memory 84 installed in slot 23. At the start of the game, the first volume data stored in the storage medium or flash memory 84 installed in slot 23 is read into the DRAM 85. This forms the initial terrain. For example, as initial terrain, a terrain object 210 representing horizontal ground and a terrain object 220 representing rocky mountains are formed. During game execution, the terrain changes as the voxel data contained in the first volume data stored in the DRAM 85 is updated.

[0132] The reference voxel data is the voxel data of voxels that are determined to meet the predetermined criteria for damage value. The reference voxel data is stored when a destruction action hits a voxel object and there are voxels that are determined to meet the predetermined criteria.

[0133] The second voxel space data pertains to a second voxel space located within the game space, distinct from the field voxel space. The second voxel space data contains similar data to the field voxel space data. The second voxel space data includes second volume data that holds multiple voxel data to represent voxel objects (e.g., enemy objects) that can move within the virtual space.

[0134] Player character data refers to data about the player character (PC), including data indicating their position and orientation in the game space.

[0135] Mesh data is data that represents the mesh set for voxel objects placed in game space. Mesh data includes, for example, data indicating the position of each vertex in the mesh. Mesh data is generated based on first volume data, second volume data, etc.

[0136] In addition to the data shown in Figure 23, Game System 1 also stores data that is stored in advance before game processing is executed, such as the aforementioned property information and texture information data, and data related to various characters that appear in the game. For example, 3D object data representing a 3D object different from a voxel object (e.g., a player character PC) is stored. Furthermore, Game System 1 stores voxel space data for each voxel object that can move within the game space.

[0137] Figure 24 is a flowchart illustrating an example of the game processing flow performed by game system 1. The game processing shown in Figure 24 is initiated, for example, when the player gives an instruction to start the game.

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

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

[0140] As shown in Figure 24, in step S1, the processor 81 sets the initial state of the game space. Specifically, the processor 81 obtains first volume data representing the terrain of the game space in the initial state from a storage medium installed in slot 23, and stores part or all of the obtained first volume data in the DRAM 85. The processor 81 also reads player character data from the storage medium, sets the initial position and orientation of the player character, and stores it in the DRAM 85. The processor 81 also sets the initial position and orientation of the virtual camera and stores it in the DRAM 85.

[0141] Furthermore, the voxel data written to the DRAM 85 may be a portion of the voxel data used to generate game images from the voxel data of the entire game space. For example, the processor 81 may generate an image of an object using voxel data of voxels included in a portion of the game space (for example, within a predetermined distance from the virtual camera's position). Also, when voxel data for a portion of the game space is written, the same processing as in step S1 is executed at an appropriate timing during the execution of the series of processes in steps S2 to S11 (for example, when the virtual camera's position moves by a predetermined distance or more).

[0142] In step S2, the processor 81 generates a mesh for the voxel objects. The mesh is generated according to the method described in "[2-2. Mesh]" above. Specifically, the processor 81 generates a mesh representing each voxel object based on the first volume data stored in the DRAM 85 in step S1. Polygons are generated such that vertex positions are determined between voxels defined as being inside the voxel object and voxels defined as being outside the voxel object. This sets the polygon mesh representing the voxel object in the game space. For example, terrain objects 210 and 220 are set in the game space. An example of a specific method for determining vertex positions is explained with reference to Figure 14. After step S2, the game starts, and the processes in 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 (for example, the player character PC) that appear in the game space. For example, the processor 81 moves the player character PC or makes the player character PC perform predetermined actions (destruction actions, jumps, etc.) based on operation data received from controllers 3 and 4. The destruction actions of the player character PC may include punching, kicking, throwing projectiles, etc. After step S3, the processing of step S4 is executed.

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

[0145] In step S5, the processor 81 performs a destruction determination process. First, it is determined whether the destruction action performed by the player character PC hit a voxel object (for example, a terrain object). If the destruction action hits a voxel object, it is determined whether there are voxels that meet predetermined criteria. If it is determined that there are, 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, the processor 81 executes the process in step S6.

[0146] In step S6, the processor 81 performs a destruction range setting process to set the 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, the processor 81 sets a first destruction range that includes 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 a second voxel space (e.g., an enemy object), the processor 81 sets a second destruction range that includes the hit position determined in step S5. The destruction range may be a sphere, an ellipsoid, or an ellipsoid deformed asymmetrically left-right or up-down, and may be a different shape from or the same shape as the collision detection shape. Next, the processor 81 executes the process of step S7.

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

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

[0149] In step S9, the processor 81 updates the mesh for voxel objects whose voxel data was modified 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 for the destroyed voxel object based on the updated voxel data from step S7. This allows the mesh of a voxel object that has undergone a destruction action to be dynamically changed during the game. In step S9, the vertices of the mesh are recalculated only for the parts where the voxel data has been updated. For the parts of the mesh where the voxel data has not been updated, the vertex positions of the mesh generated in step S2 are used. In this way, the mesh is recalculated only for the updated voxel data, thus reducing the processing load. In other embodiments, in step S9, the vertex positions of the mesh may be recalculated based on all voxel data in the game space (or all voxel data within the imaging range of the virtual camera), including both updated and unupdated voxel data. The process in step S10 is executed after step S9.

[0150] In step S10, the 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, the processor 81 generates a game image as seen from the position of the virtual camera, viewing the mesh generated in step S2 or S9. This generates a game image representing the game space, including voxel objects and other 3D objects (e.g., the player character PC). The processor 81 then displays the generated game image on the display device. The processing in step S11 is executed after step S10.

[0151] In step S11, the processor 81 determines whether or not to terminate the game. For example, the processor 81 determines whether or not the user has given an instruction to terminate the game. If the result of the determination in step S11 is negative, the process in step S3 is executed again. Thereafter, the series of processes from steps S3 to S11 are repeatedly executed until it is determined in step S11 that the game should be terminated. On the other hand, if the result of the determination in step S11 is positive, the processor 81 terminates the game process as shown in Figure 24.

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

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

[0154] In step S22, the processor 81 determines, based on the collision detection process, whether the destruction action hit the voxel object. If the result of the determination in step S22 is positive, the process in step S23 is executed. On the other hand, if the result of the determination in step S22 is negative, the process in Figure 25 is terminated.

[0155] In step S23, the processor 81 identifies the collision range on the surface of the voxel object that 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 within the collision range that satisfy 0 < MH - DH < a predetermined value. 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 therebetween is less than the predetermined value are extracted. These voxels satisfy the second condition and are 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 any voxels among the voxels extracted in step S24 for which the damage value becomes equal to or greater than the limit value when the damage value is added by the current destruction action. If the determination result in step S25 is affirmative, that is, if there are voxels on the surface of the voxel object that collided with the collision determination shape that satisfy a predetermined criterion, then next, the process of step S26 is executed. On the other hand, if the determination result in step S25 is negative, the process of 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 on the surface of the voxel object that collided with the collision determination shape that satisfy a predetermined criterion. This condition flag is referred to in the next voxel data update process.

[0159] When the process of step S26 is performed, when the determination in step S​​ (Voxel data update process) The voxel data update process in step S7 will be explained below with reference to Figure 26. Figure 26 is a flowchart showing an example of the voxel data update process in step S7.

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

[0162] In step S32, the processor 81 determines whether the hardness DH of the destruction action is greater than or equal to 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 the first condition. That is, it is determined whether the destruction action is hard enough for the voxel object and whether the voxel object is destroyed by a single destruction action. If the result of the determination in step S32 is positive, the process in step S36 is executed next. On the other hand, if the result of the determination in step S32 is negative, the process in step S33 is executed next.

[0163] In step S33, the processor 81 determines whether the difference (MH-DH) between the hardness MH of the voxel 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 the second condition. That is, it is determined whether the voxel selected in step S31 is a voxel to which damage can be added by the destruction action. If the result of the determination in step S33 is positive, the process in step S34 is executed next. On the other hand, if the result of the determination in step S33 is negative, the process in step S37 is executed next.

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

[0165] In step S35, the processor 81 updates the voxel's damage value. For example, the processor 81 adds 1 to the voxel's damage value. The added damage value may differ depending on the hardness of the destruction action and the hardness of the material. If, as a result of the processing in step S35, there are no voxels within the collision range that meet the predetermined criteria, the damage value is added to the voxels within the destruction range without updating their density. The mesh of the voxel to which the damage value has been added may display an indication that damage has been added. The processing in step S37 is executed after step S35.

[0166] In step S36, the processor 81 updates the voxel density to a value that indicates the absence of voxel objects. For example, if a voxel is completely contained within the destruction range (i.e., the voxel is inside the destruction range), the processor 81 sets the voxel density to "0". If only a portion of the voxel is contained within the destruction range (i.e., the voxel is at the boundary of the destruction range), the processor 81 updates the voxel density to a value, for example, below a baseline value. If the hardness DH of the destruction action is greater than or equal to the hardness MH of the voxel's material, the result is determined to be YES in step S32, and the process in step S36 is performed. As a result, the voxel is destroyed in one destruction action without any damage value being added to it. The process in step S36 is also performed if the result is determined to be YES in step S34. As a result, even if a voxel would normally have its damage value increased in order to satisfy the second condition above (MH-DH < predetermined value of voxel), if there is a voxel within the collision range that satisfies the predetermined criteria above, the voxel within the destruction range will be destroyed.

[0167] Furthermore, the process in step S36 is performed on voxels with a hardness less than or equal to the hardness of a voxel that satisfies the predetermined criteria, if such voxels exist within the collision range. For example, suppose there is a voxel with a hardness of "3" and a voxel with a hardness of "2" within the destruction range corresponding to the current destruction action, and it is determined that the voxel with a hardness of "3" satisfies the predetermined criteria. That is, if damage is added to the voxel with a hardness of "3" in accordance with the current destruction action, it is determined that the added damage value is greater than or equal to the limit value, and it is stored as the reference voxel data. In this case, the density of the other voxels with a hardness of "3" within the destruction range is updated even if the damage value does not exceed the limit value due to the current destruction action. For example, even if the current damage value of the other voxels with a hardness of "3" within the destruction range is "0", the process in step S36 is executed and they are destroyed. Also, for the voxel with a hardness of "2" within the destruction range, MH-DH < predetermined value is satisfied. Therefore, even voxels with a hardness of "2" within the fracture range are subjected to the process in step S36 and fractured. In other words, voxels with a hardness lower than that of voxels that meet the predetermined criteria are also fractured.

[0168] If the process in step S36 is performed, if the process in step S35 is performed, or if NO is determined in step S33, the processor 81 executes the process in step S37.

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

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

[0171] As described above, in this embodiment, if even one voxel that satisfies a predetermined criterion regarding damage value exists within the destruction range set by the current destruction action (step S25: YES), the voxel values ​​are updated so that the density of voxels having the same or less hardness as the voxel that satisfies the predetermined criterion within the destruction range is such that it indicates the absence of an object. A voxel that satisfies the predetermined criterion is a voxel whose damage value exceeds the limit value due to the current destruction action. This makes it possible to suppress the deformation of the voxel object after destruction by ensuring that only voxels whose damage value exceeds the limit value are destroyed by the current destruction action.

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

[0173] Furthermore, in this embodiment, instead of determining whether or not there are voxels that meet the predetermined criteria for all voxels within the destruction range, the determination is made for some of the voxels included in the destruction range (voxels that form the surface of the voxel object) whether or not they meet the predetermined criteria. This reduces the processing load.

[0174] (modified version) Although this embodiment has been described above, the above embodiment is merely an example, and modifications such as the following may be made.

[0175] For example, in the above embodiment, a damage value is set for the voxel, and the damage value is increased by the destruction action. When this damage value exceeds a predetermined limit, the voxel is destroyed. In other embodiments, a durability value is set for the voxel, and the durability value is decreased by the destruction action. When this durability value falls below a predetermined value, the voxel may be destroyed. The increase in damage value due to the destruction action and the decrease in durability value due to the destruction action have the same technical significance. To remember that the damage applied to the voxel has increased, either a damage value that increases in response to the destruction action or a durability value that decreases in response to the destruction action may be used.

[0176] In other words, when a destruction action hits a voxel object, the voxel value may be updated to reflect a damage value that indicates an increase in damage. "Updating the voxel value to reflect a damage value that indicates an increase in damage" includes increasing the damage value set for the voxel and decreasing the durability value set for the voxel.

[0177] Furthermore, in the above embodiment, when a voxel is destroyed when its damage value exceeds a limit value, a voxel that meets the predetermined criteria is defined as a voxel whose damage value increases to a predetermined limit value or higher when the destruction action increases its damage value. When a voxel is destroyed when its durability value falls below a predetermined value, a voxel that meets the predetermined criteria is defined as a voxel whose durability value falls below a predetermined value when damage is inflicted by the destruction action. In other words, a voxel that meets the predetermined criteria is a voxel whose damage exceeds a predetermined damage limit when the damage of the voxel increases due to the destruction action. Here, "the damage of a voxel exceeds the damage limit" includes the voxel's damage value being above a limit value and the voxel's durability being below a predetermined value.

[0178] Furthermore, in the above embodiment, before actually updating the damage values ​​of the voxels within the destruction range, it was determined whether or not some of the voxels included in the destruction range met a predetermined standard regarding damage values. In other embodiments, the same process may be performed for all voxels within the destruction range. That is, it may be determined whether or not some of the voxels within the destruction range meet a predetermined standard. Also, if the damage values ​​of the voxels within the destruction range are actually updated and there are voxels whose updated damage values ​​are equal to or greater than the limit value, the voxels within the destruction range may be destroyed.

[0179] Furthermore, 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 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 is a predetermined number of voxels that satisfy a predetermined criterion regarding damage value.

[0180] Furthermore, in the above embodiment, the relationship between the hardness of the destruction action and the hardness of the voxel material determines whether the voxel object is destroyed or damaged when the destruction action hits it. In other embodiments, the determination of whether the voxel object is destroyed or damaged when the destruction action hits it may be based solely on the hardness of the material of the voxel being destroyed.

[0181] Furthermore, in the above embodiment, when a destruction action hits a voxel object, if there are voxels that meet a predetermined criterion, the density of voxels having a hardness less than or equal to the "hardness" of the voxel that meets the predetermined criterion is updated. In other embodiments, if there are voxels that meet a predetermined criterion, the density of voxels having a hardness less than or equal to a predetermined hardness may be updated. Also, the above processing may be performed not only based on the "hardness" of the material, but also based on the material properties of the material. For example, if there are voxels that meet a predetermined criterion, the density of voxels having a predetermined material property may be updated. For example, a material may have multiple materials, and the relationships between each material are predetermined. If there are voxels that meet a predetermined criterion, the density of voxels of materials having a predetermined relationship with the material of the voxel that meets the predetermined criterion may be updated.

[0182] Furthermore, while the above embodiment described the case where a destruction action is performed on a terrain object that the player character can move, 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 regarding damage value, the density of 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 added to the voxels within the destruction range.

[0183] Furthermore, in the above embodiment, for voxels within the destruction range, a value indicating that no object exists in that voxel was set by setting the voxel density to "0". As a result, the portion of the voxel object within the destruction range was erased, and the voxel object was destroyed. 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 respect to density, the "value indicating that no object exists" is not limited to "0", but may be any value less than a reference value (e.g., 128). Also, with respect to density, the "value indicating that an object exists" may be a value in the range of 1 to 255, or a value greater than or equal to 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 existence or non-existence of an object may be stored in the voxel data, and when the flag is ON, it indicates that an object exists in that voxel, and when the flag is OFF, it indicates that no object exists in that voxel (i.e., it is empty).

[0184] Furthermore, the above-described process may be performed not only in game system 1, but also in any other information processing device or information processing system. The information processing system may consist of multiple devices, and these multiple devices may be connected via a network (for example, a LAN or the Internet).

[0185] Furthermore, the configurations of the above embodiments and their modified forms can be combined in any way, as long as they do not contradict each other. Moreover, the above is merely an example of the present invention, and various other improvements and modifications may be made. [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 in the processor of an information processing device, wherein the processor: Data for representing a virtual object in a virtual space, wherein for each voxel contained in the voxel space arranged in the virtual space, volume data is stored on a storage medium that holds voxel values ​​including at least a density indicating the degree to which the object occupies the space defined by the voxel, and a damage value indicating the damage inflicted on the voxel. Based on the player's input, the player character is moved within the virtual space. Based on the player's input, the player character is made to perform a destructive action. If the destruction action hits the virtual object, If there are voxels that satisfy a predetermined standard with respect to at least the damage value, the voxel values ​​are updated so that the density of voxels included in the erasure range set based on the player character's position indicates that the virtual object does not exist. If there are no voxels that meet the predetermined criteria, update the voxel values ​​so that the damage values ​​for the voxels included in the deletion range are increased to indicate that the damage has been increased. A game program that generates an image of the virtual space by drawing at least a polygon mesh representing the surface of the virtual object based on the volume data.

2. The game program according to claim 1, wherein a voxel that satisfies the predetermined criteria is a voxel whose damage, when increased by the destruction action, exceeds a predetermined damage limit.

3. The computer is further instructed to determine the hit location where the destruction action strikes the virtual object when the destruction action is performed. The game program according to claim 1 or 2, wherein a voxel that satisfies the predetermined criteria is a voxel within a predetermined range including the hit position and having a predetermined damage value.

4. The game program according to claim 3, wherein the computer is instructed to perform contact detection between the polygon mesh or a determination polygon mesh representing the surface of the virtual object generated for determination and a determination shape set based on the destruction action, and to determine the hit position.

5. The voxel value further includes data indicating the hardness or material of the voxel, To the aforementioned computer, The game program according to any one of claims 1 to 4, wherein, when the destruction action hits the virtual object, if there are voxels that satisfy the predetermined criteria, the voxel values ​​are updated so that the density of voxels having a hardness of less than or equal to a predetermined hardness or a predetermined type of material indicates that the virtual object does not exist.

6. The game program according to any one of claims 1 to 5, wherein the erasure range is a sphere, an ellipsoid, or a shape obtained by asymmetrically deforming an ellipsoid.

7. The game program according to any one of claims 1 to 6, wherein the virtual object is the terrain in the virtual space.

8. To the aforementioned computer, Based on the density, the polygon mesh is generated by an algorithm that arranges polygons between voxels defined as being inside the virtual object and voxels defined as being outside the virtual object so that vertex positions are determined. The game program according to any one of claims 1 to 7, wherein when the destruction action is performed, the program recalculates the vertices of the polygon mesh in the range that includes at least the voxel whose voxel value has been updated.

9. An information processing system comprising a storage medium and at least one processor, The aforementioned processor, Data for representing a virtual object in a virtual space, wherein for each voxel contained in the voxel space arranged in the virtual space, volume data is stored in the storage medium that holds voxel values, each including at least a density indicating the degree to which the object occupies the space defined by the voxel, and a damage value indicating the damage inflicted on the voxel. Based on the player's input, the player character is moved within the virtual space. Based on the player's input, the player character is made to perform a destructive action. If the destruction action hits the virtual object, If there are voxels that satisfy a predetermined standard with respect to at least the damage value, the voxel values ​​are updated so that the density of voxels included in the erasure range set based on the player character's position indicates that the virtual object does not exist. If there are no voxels that meet the predetermined criteria, the voxel values ​​are updated to reflect the damage values ​​indicating that the damage to the voxels included in the erasure range has been increased. An information processing system that generates an image of the virtual space by drawing at least a polygon mesh representing the surface of the virtual object based on the volume data.

10. The information processing system according to claim 9, wherein a voxel that satisfies the predetermined criteria is a voxel whose damage, when increased by the destruction action, exceeds a preset damage limit.

11. The processor determines the hit location where the destruction action strikes the virtual object when the destruction action is performed. The information processing system according to claim 9 or 10, wherein a voxel that satisfies the predetermined criteria is a voxel within a predetermined range including the hit position and having a predetermined damage value.

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

13. The voxel value further includes data indicating the hardness or material of the voxel, The aforementioned processor, The information processing system according to any one of claims 9 to 12, wherein, when the destruction action hits the virtual object, if there are voxels that satisfy the predetermined criteria, the voxel values ​​are updated so that the density of voxels having a hardness of less than or equal to a predetermined hardness or a predetermined type of material indicates that the virtual object does not exist.

14. The information processing system according to any one of claims 9 to 13, wherein the erasure range is a sphere, an ellipsoid, or a shape obtained by asymmetrically deforming an ellipsoid.

15. The information processing system according to any one of claims 9 to 14, wherein the virtual object is the terrain within the virtual space.

16. The aforementioned processor, Based on the density, the polygon mesh is generated by an algorithm that arranges polygons between voxels defined as being inside the virtual object and voxels defined as being outside the virtual object such that vertex positions are determined. The information processing system according to any one of claims 9 to 15, wherein when the destruction action is performed, the system recalculates the vertices of the polygon mesh in a range that includes at least the voxel whose voxel value has been updated.

17. Data for representing a virtual object in a virtual space, which stores volume data that holds voxel values ​​for each voxel in the voxel space located in the virtual space, including at least a density indicating the degree to which the object occupies the space defined by the voxel, and a damage value indicating the damage inflicted on the voxel. Based on the player's input, the player character is moved within the virtual space. Based on the player's input, the player character is made to perform a destructive action. If the destruction action hits the virtual object, If there are voxels that satisfy a predetermined standard with respect to at least the damage value, the voxel values ​​are updated so that the density of voxels included in the erasure range set based on the player character's position indicates that the virtual object does not exist. If there are no voxels that meet the predetermined criteria, update the voxel values ​​so that the damage values ​​for the voxels included in the deletion range are increased to indicate that the damage has been increased. An information processing device that generates an image of the virtual space by drawing at least a polygon mesh representing the surface of the virtual object based on the volume data.

18. The information processing device according to claim 17, wherein a voxel that satisfies the predetermined criteria is a voxel whose damage, when increased by the destruction action, exceeds a preset damage limit.

19. When the destruction action is performed, the hit location where the destruction action strikes the virtual object is determined. The information processing apparatus according to claim 17 or 18, wherein the voxel that satisfies the predetermined criteria is a voxel within a predetermined range including the hit position and having a predetermined damage value.

20. An information processing method performed in an information processing system, The aforementioned information processing system stores volume data that represents virtual objects in a virtual space, and for each voxel contained in the voxel space arranged in the virtual space, the volume data holds voxel values ​​that include at least a density indicating the degree to which an object occupies the space defined by the voxel, and a damage value indicating the damage inflicted on the voxel. Based on the player's input, the player character is moved within the virtual space, To cause the player character to perform a destructive action based on the player's input, If the destruction action hits the virtual object, If there are voxels that satisfy a predetermined standard with respect to at least the damage value, the voxel values ​​are updated so that the density of voxels included in the erasure range set based on the player character's position indicates that the virtual object does not exist. If there are no voxels that meet the predetermined criteria, the voxel values ​​are updated to reflect the damage values ​​indicating that the damage to the voxels included in the erasure range has been increased. An information processing method comprising generating an image of the virtual space by drawing at least a polygon mesh representing the surface of the virtual object based on the volume data.

21. The information processing method according to claim 20, wherein a voxel that satisfies the predetermined criteria is a voxel whose damage, when increased by the destruction action, exceeds a preset damage limit.

22. The method further includes determining the hit location where the destruction action strikes the virtual object when the destruction action is performed. The information processing method according to claim 20 or 21, wherein the voxel that satisfies the predetermined criteria is a voxel within a predetermined range including the hit position and having a predetermined damage value.

Images