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

Abstract

Multiple parts are used to generate a variety of objects. [Solution] The information processing system determines the position, rotation, and scale parameters for each of the multiple parts. The information processing system generates a composite object having a first part having a shape formed by combining the multiple parts arranged in a virtual space based on each parameter, and a second part that is placed at a reference position in the virtual space and is different from the first part. The information processing system determines each parameter so that the reference position on the reference direction side of the composite object is not obstructed by the first part.

Description

Technical Field

[0001] The present invention relates to an information processing program, an information processing system, an information processing apparatus, and an information processing method for generating an object to be arranged in a virtual space.

Background Art

[0002] Conventionally, there is a technique for generating a plurality of types of characters by combining a plurality of parts to generate a character. For example, there is a technique for preparing parts such as a face contour, eyes, a nose, and a mouth and generating a plurality of types of characters by combining the parts (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] In the above technique, since parts such as eyes, a nose, and a mouth are only arranged at positions defined with respect to the contour, the patterns of the generated characters are limited.

[0005] Therefore, an object of the present invention is to provide an information processing program, an information processing system, an information processing apparatus, and an information processing method capable of generating a variety of objects using a plurality of parts.

Means for Solving the Problems

[0006] In order to solve the above problems, the present invention employs the following configurations (1) to (14).

[0007] (1) An example of the present invention is an information processing program executed in a computer of an information processing device, wherein the computer functions as a parameter determination means and an object generation means. The parameter determination means determines the parameters of position, rotation, and scale for each of a plurality of parts. The object generation means generates a composite object having a first part having a shape formed by combining the plurality of parts arranged in a virtual space based on each parameter, and a second part that is arranged at a reference position in the virtual space and is a part different from the first part. The parameter determination means determines each parameter such that the reference position on the reference direction side of the composite object is not obstructed by the first part.

[0008] According to the configuration described in (1) above, a variety of objects can be generated by creating the first part using parts in which each of the above parameters is changed to various values.

[0009] (2) In the configuration of (1) above, the parameter determination means may determine each parameter such that the reference position is located on the surface of the first part.

[0010] According to the configuration described in (2) above, it is possible to reduce the possibility that the object may look unnatural due to the second part being buried and invisible in the first part, or the second part being positioned separately from the first part.

[0011] (3) In the configuration of (1) or (2) above, the virtual space may be a three-dimensional space. Each of the multiple parts may have a flat surface portion. The parameter determination means may determine the position parameter and the scale parameter so that the plane containing the reference position and each surface portion of the multiple parts are located in the same plane, and may also determine the rotation parameter so that the surface portion is perpendicular to the reference direction and faces the side of the reference direction.

[0012] According to the configuration described in (3) above, the second part can be placed on the surface formed by the surface portion of each part, thereby reducing the possibility of the object having an unnatural appearance.

[0013] (4) In the configuration of (1) or (2) above, the parameter determination means may determine each parameter for each of the multiple parts within a range that is set in advance so that the reference position on the reference direction side of the composite object is not obstructed by the first part.

[0014] According to the configuration described in (4) above, the possibility of the object appearing unnatural can be reduced.

[0015] (5) In any of the configurations (1) to (4) above, the parameter determination means may determine at least one of each parameter based on probability.

[0016] According to the configuration described in (5) above, it is possible to generate an object in which the shape of the first part changes randomly.

[0017] (6) In the configuration of (1) or (2) above, the parameter determination means may repeat the process of determining each parameter based on probability until each parameter is determined such that the reference position on the reference direction side of the composite object is not obscured by the first part.

[0018] According to the configuration described in (6) above, the possibility of the object having an unnatural appearance can be reduced, and an object in which the shape of the first part changes randomly can be generated.

[0019] (7) In any of the configurations described in (1) to (6) above, the parameter determination means may determine each parameter during game execution. The object generation means may place the composite object in the virtual space during game execution.

[0020] According to the configuration of (7) above, objects with different shapes can be generated each time the game is executed.

[0021] (8) In any of the configurations of (1) to (7) above, the plurality of parts and the first part of the composite object may be voxel objects generated based on voxel data.

[0022] According to the configuration of (8) above, the process of generating the first part based on the parts can be easily executed using voxel data.

[0023] (9) In any of the configurations of (1) to (8) above, the composite object may be a non-player character.

[0024] According to the configuration of (9) above, non-player characters with individuality can be introduced into the game one by one.

[0025] (10) In the configuration of (9) above, the information processing program may further cause the computer to function as character control means for controlling the non-player character so that the reference direction faces from the non-player character to the player character.

[0026] According to the configuration of (10) above, the object can be made to operate so as to face the front as seen from the player character.

[0027] (11) In the configuration of (9) or (10) above, the information processing program may further cause the computer to function as object erasing means for erasing a part of the composite object in accordance with the operation by the player character.

[0028] According to the configuration described in (11) above, the player can change the shape of an object by manipulating the player character.

[0029] (12) In the configuration described in (11) above, the information processing program may further enable the computer to function as an object restoration means, which restores the shape of the composite object to its original shape over time if a part of the composite object is erased.

[0030] According to the configuration described in (12) above, the player can enjoy repeatedly transforming the object.

[0031] (13) In any of the configurations described in (9) through (12) above, the second part may be an object representing the eyes of a non-player character.

[0032] According to the configuration described in (13) above, the possibility of generating objects in which the object's eyes are in an unnatural position can be reduced.

[0033] (14) In any of the configurations described in (9) through (13) above, the composite object may further have an object representing the feet of a non-player character.

[0034] Another example of the present invention is an information processing device or information processing system that performs the processes described in (1) to (14) above. Another example of the present invention is an information processing method that performs the processes described in (1) to (14) above. [Effects of the Invention]

[0035] According to the above-mentioned information processing program, information processing system, information processing device, or information processing method, a variety of objects can be generated using multiple parts. [Brief explanation of the drawing]

[0036] [Figure 1] This diagram shows an example of the main unit with the left and right controllers attached. [Figure 2] This diagram shows an example of the left and right controllers being removed from the main unit. [Figure 3] A six-view drawing showing an example of the main unit. [Figure 4] A six-view drawing showing an example of a left controller. [Figure 5] A six-view drawing showing an example of a right controller. [Figure 6] Block diagram showing an example of the internal configuration of the main unit. [Figure 7] Block diagram showing an example of the internal configuration of the main unit, left controller, and right controller. [Figure 8] This diagram shows an example of a terrain object that is a voxel object. [Figure 9] Figure 8 shows an example of what the terrain object looks like before and after a portion of it 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] A diagram illustrating an example of the process for generating non-player characters. [Figure 17] A diagram showing an example of a generated body object. [Figure 18] A diagram showing an example of three parts. [Figure 19] A diagram showing examples of each part that are arranged based on each parameter. [Figure 20]Figure 19 shows an example of a body object generated based on each of the parts shown. [Figure 21] A diagram showing an example of a generated non-player character. [Figure 22] This diagram shows an example of various types of data used in information processing in Game System 1. [Figure 23] A flowchart illustrating an example of the game processing flow executed by Game System 1. [Figure 24] Figure 23 shows a subflowchart illustrating an example of a detailed flow of the character generation process in step S4. [Modes for carrying out the invention]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0081] 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, voxel objects are actually generated using a rule (based on voxel data) that results in a shape more complex than the length of one side of a voxel, such as the terrain object shown in Figure 15, which will be described later. The rule for determining the shape of a voxel object based on voxel data is arbitrary. In other embodiments, the game system 1 may generate voxel objects as shown in Figure 8 or as shown in Figure 15 based on object data.

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

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

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

[0085] As shown in Figure 11, the voxel data includes density data. The density data indicates the density, which is an index used to define the shape of the voxel object in the voxel corresponding to the voxel data (specifically, the shape defined by the mesh described later). As will be described in detail later, the position and shape of the surface of the voxel object (i.e., the mesh described later) are determined based on the above density. In other words, in this embodiment, the above density is used to create a mesh that defines the surface of the voxel object.

[0086] In this embodiment, density can take the form of an integer value within a range from a lower limit (e.g., 0) to an upper limit (e.g., 255). In this embodiment, the game system 1 determines the shape of a voxel object based on density, such that a higher density value for a voxel tends to result in a larger proportion of the volume occupied by voxel objects within that voxel, while a lower density value tends to result in a smaller proportion. Thus, density is an indicator that affects the proportion of the volume occupied by voxel objects within a voxel. Density can also be said to be an indicator that shows the degree to which objects are contained within the area in which each voxel is defined. For example, if the density is 0, there are no voxel objects within that voxel; if the density is 255, the entire voxel is filled with voxel objects; and if the density is between 0 and 255, voxel objects can occupy the voxel in proportion to the value. Based on the above density, the shape of the mesh, i.e., the shape of the voxel object, can be determined. However, the volume of the voxel object generated based on the above density does not need to exactly match the ratio indicated by the density. For example, the volume of the voxel object may differ between the method used to generate the voxel object shown in Figure 8 and the method used to generate the voxel object shown in Figure 15, even if they are based on the same density.

[0087] In other embodiments, density may indicate either a state in which voxel objects occupy the entire region within the voxel, or a state in which no voxel objects are contained within the region within the voxel. For example, density data may only take the values ​​of 0 or 1.

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

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

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

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

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

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

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

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

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

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

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

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

[0100] As described above, in this embodiment, the density set for a voxel is set in the range of 0 to 255. In this embodiment, voxels with a density equal to or greater than a reference threshold are considered to be inside the object, and voxels with a density less than the reference threshold 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 threshold = 1), and the reference threshold 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, voxel 202 has a density of 100 which is less than the reference threshold, and voxels 203 and 204 have densities of 150 and 200 which are equal to or greater than the reference threshold. In this embodiment, the game system 1 generates vertices between voxels with a density equal to or greater than the reference threshold and voxels with a density less than the reference threshold. 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 threshold and voxels with a density below a threshold. Furthermore, a polygon mesh is generated by connecting vertices when the boundary between adjacent vertices (the boundary of the region containing each vertex) passes through a range of voxels with a density above the threshold and voxels with a density below the threshold. The coordinates of 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 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 reference threshold is set to a value lower than the density of voxel 202, the result will be an increase in the number of vertices on the upper right and upper left sides of voxel 202 in Figure 14.

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

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

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

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

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

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

[0107] [2-3. Creating Voxel Objects] The following describes a method for generating non-player characters that appear in the game space as voxel objects. In this embodiment, game system 1 generates non-player characters so that their shape differs each time they are generated. Furthermore, by generating multiple non-player characters so that their shape differs each time they are generated, the player can be given the impression that each non-player character is not uniform, but rather has its own individuality. As will be described in detail later, in this embodiment, game system 1 automatically generates non-player characters at appropriate timings during the game (specifically, using procedural techniques).

[0108] Figure 16 shows an example of the process for generating a non-player character. As shown in Figure 16, the non-player character in this embodiment is a character with a rock-like body, eyes, and feet. In this embodiment, multiple parts are prepared to generate the body of the non-player character. As shown in Figure 16(a), in this embodiment, three parts 211 to 213 are prepared. Note that the number of parts prepared can be any number of two or more.

[0109] As shown in Figure 16(b), the game system 1 generates an object (referred to as a body object) 214 representing the body of a non-player character by combining the above-mentioned parts 211 to 213. At this time, the game system 1 randomly determines the position and orientation (also called tilt) of the three parts 211 to 213 and generates one body object 214 by combining the three parts 211 to 213. Therefore, the body object 214 can take on various shapes. In other words, in this embodiment, a body object 214 of a different shape is generated each time the generation process is performed.

[0110] Figure 17 shows examples of body objects that can be generated. In this embodiment, by randomly combining multiple parts 211 to 213 as described above to generate a body object 214, multiple non-player characters with different shapes can be generated, as shown in Examples 1 to 3 in Figure 17.

[0111] As shown in Figure 16(c), the game system 1 adds an eye object 215 and a foot object 216 to the generated body object 214. This completes the non-player character. In this embodiment, the eye object 215 and the foot object 216 are placed in predetermined positions.

[0112] In this embodiment, parts 211-213 and body object 214 are voxel objects. In this embodiment, the shapes of parts 211-213 and body object 214, which are voxel objects included in the non-player character, are defined by voxel data relating to voxels different from those of the terrain object described above. That is, the voxel space relating to the non-player character (referred to as the "sub-voxel space") is a voxel space set separately from the voxel space relating to the terrain object (referred to as the "main voxel space"). The sub-voxel space is set as part of the game space (which can also be said to be part of the main voxel space), and the non-player character is placed within the sub-voxel space. The size and orientation of voxels in the sub-voxel space (i.e., the orientation of each edge of a voxel) may differ from the size and orientation of voxels in the main voxel space. For example, by defining a sub-voxel space that includes voxels with shorter side lengths than the voxels in the main voxel space, the shape of non-player characters can be represented in more detail than terrain objects based on the main voxel space. Furthermore, game system 1 changes the position or orientation of non-player characters (more precisely, their position or orientation in the game space) by changing the position or orientation of the sub-voxel space in the game space. If multiple non-player characters are generated, game system 1 sets up a sub-voxel space for each non-player character.

[0113] In other embodiments, the eye object 215 and the foot object 216 (i.e., the entire non-player character) may also be voxel objects in addition to the body object 214. In other embodiments, the shape of the non-player character may be defined by the voxel data of the main voxel space described above. In other embodiments, the non-player character may not be a voxel object.

[0114] Next, the details of the non-player character generation process will be explained with reference to Figures 18 to 21. Figure 18 shows an example of three parts. As mentioned above, in this embodiment, the non-player character has the appearance of a rock. Therefore, each part 211 to 213 is an object that imitates a rock, as shown in Figure 18.

[0115] Note that in Figures 18 and 19, meshes are shown for each part 211-213 for the purpose of making the generation process easier to understand. However, in this embodiment, it is sufficient for voxel data to be provided for each part 211-213, and the game system 1 does not need to generate meshes for each part 211-213.

[0116] Each part 211-213 is placed in the sub-voxel space relating to the non-player character. The x-axis direction of the coordinate system of this sub-voxel space (the xyz coordinate system shown in Figure 18) is horizontal and perpendicular to the front-to-back direction described later (i.e., left-to-right direction). When the sub-voxel space (in other words, the non-player character) is placed in the game space in a standard orientation, the x-axis direction is parallel to the horizontal direction in the game space. The y-axis direction of the above coordinate system is vertical (also called the up-and-down direction), and when the sub-voxel space is placed in the game space in a standard orientation, it corresponds to the vertical direction in the game space. Furthermore, the z-axis direction of the above coordinate system corresponds to the front-to-back direction of the non-player character. Specifically, the positive z-axis side is the back side of the non-player character, and the negative z-axis side is the front side of the non-player character. In this embodiment, the non-player character is generated in the sub-voxel space, and the non-player character is placed in the game space when the sub-voxel space is set in the game space.

[0117] Note that in Figure 18, the parts 211 to 213 are shown spaced apart from each other for the purpose of making them easier to see. However, in reality, as shown in Figure 19, which will be described later, the parts 211 to 213 are arranged so that parts of each overlap.

[0118] As shown in Figure 18, in this embodiment, each part 211 to 213 has a flat surface portion 221 to 223. In this embodiment, the surface portions 221 to 223 are planar. However, the term "flat" does not mean strictly planar. As will be described in detail later, after the body object 214 is generated based on the parts 211 to 213, the eye object 215 is placed on the surface formed by the surface portions 221 to 223. At this time, the flat surface portions 221 to 223 may have small irregularities to that extent, as long as it does not cause any inconvenience such as part or all of the eye object 215 placed on the surface being hidden and not visible by the body object 214.

[0119] In this embodiment, each part 211 to 213 is set with a position parameter indicating the position of the part, a rotation parameter indicating its rotation (which can also be called its orientation), and a scale parameter indicating its size. The position parameter is a parameter that indicates the position coordinates in the sub-voxel space, the rotation parameter is a parameter that indicates the rotation angle relative to a reference orientation in the sub-voxel space, and the scale parameter is a parameter that indicates the ratio of the size to a reference in the sub-voxel space (for example, the size of the part when the reference size is set to 1). Note that the scale parameter may also be a parameter that indicates the above ratio for each axis.

[0120] In this embodiment, the game system 1 randomly determines a set of the above-mentioned parameters (i.e., position parameter, rotation parameter, and scale parameter) for each part. In this specification, "randomly determined" is not limited to a method in which the determination result (i.e., each set of parameters) is obtained with equal probability, but includes any method in which the determination is made so that the results of multiple trials are not the same each time (i.e., it has randomness), for example, by using random numbers. For example, when generating multiple non-player characters, the game system 1 may randomly determine the set of the above-mentioned parameters so that there is no bias in the values ​​of each parameter among the non-player characters, in order to avoid the shapes of each generated non-player character being similar.

[0121] In this embodiment, the game system 1 randomly determines the set of parameters such that each face portion 221 to 223 is located within a reference plane 226 perpendicular to the front-to-back direction, including reference positions 225a and 225b, and faces the front side (i.e., the negative z-axis direction). Here, reference positions 225a and 225b are predetermined positions in the sub-voxel space, and are the positions where the eye objects 215 are placed. Specifically, the right eye object 215a is placed at reference position 225a, and the left eye object 215b is placed at reference position 225b (see Figure 21). In this embodiment, reference positions 225a and 225b are set to the same position with respect to the front-to-back direction (i.e., the z-coordinate values ​​of reference positions 225a and 225b are the same).

[0122] Furthermore, the set of reference positions (in the example above, reference positions 225a and 225b) only needs to be defined as one set when determining each of the above parameters. Game system 1 may select one set from among several prepared candidates and then determine each of the above parameters according to the selected set of reference positions. This increases the variations in the position of the eye object 215 and further increases the visual variations of the non-player character. The method of selecting one set of reference positions from multiple candidates is arbitrary. For example, game system 1 may select one set randomly, or it may select one set according to a defined rule.

[0123] In this embodiment, the position parameters are randomly determined such that they are variable in the left-right direction (i.e., the x-axis direction) and the up-down direction (i.e., the y-axis direction), but fixed in the front-back direction (i.e., the z-axis direction). Specifically, when the position indicated by the position parameter corresponds to a position on the surface portion of the part, this fixed value is set to a value equal to the coordinate value in the front-back direction (i.e., the z-axis coordinate value) of the above-mentioned reference positions 225a and 225b. In this way, each part 211 to 213 may change in the left-right and up-down directions each time the position parameters are determined, but is fixed in the front-back direction (see the dashed arrows shown in Figure 18).

[0124] For example, game system 1 sets initial coordinates for the position parameters and determines the position parameters by randomly determining the amount of change from the initial coordinates in the left-right and up-down directions. Note that the initial coordinates may be set to different values ​​for each part 211 to 213. In addition, a range may be set in which the position parameters can be changed from the initial coordinates when randomly determining the position parameters. For example, game system 1 may change the position parameters from the initial coordinates within a range that includes the reference positions 225a and 225b for the face portions 221 to 223 of each part 211 to 213. This prevents the face portions 221 to 223 from being placed in positions that do not include the reference positions 225a and 225b (although they are still within the reference plane 226).

[0125] Furthermore, the rotation parameters are randomly determined such that the angle around the front-to-back axis is variable, while the angles around the left-to-right axis and the up-to-down axis are fixed. Specifically, these fixed values ​​are set so that each surface portion 221-223 is perpendicular to the front-to-back direction and faces forward. In this way, each part 211-213 is positioned so that its angle around the front-to-back axis may change each time the rotation parameter is determined, but its angles around the left-to-right axis and the up-to-down axis remain fixed (see the dotted arrows in Figure 18).

[0126] For example, game system 1 sets an initial angle for the rotation parameter and determines the rotation parameter by randomly determining the amount of change from the initial angle for the angle around the front-to-back axis. Note that the initial angle may be set to a different value for each part 211 to 213.

[0127] Furthermore, in this embodiment, the scale parameter is set to a predetermined fixed value. However, in other embodiments, the game system 1 may randomly determine the scale parameter so that it can also change. In this case, the game system 1 may change the scale parameter while adjusting each parameter so that the direction in which each face portion 221 to 223 faces (i.e., the front direction) and its position in the front-to-back direction do not change. For example, since the position of the face portion of the part may change in the front-to-back direction due to a change in the scale parameter, the game system 1 may change the position parameter to offset the change in the position of the face portion due to the change in the scale parameter, thereby ensuring that the position of the face portion does not change in the front-to-back direction. Note that, even when the scale parameter is changed as described above, adjustment of the position parameter is not necessary in the left-to-right and up-to-down directions, so it can be said that the position parameter is easy to change in the left-to-right and up-to-down directions.

[0128] As described above, in this embodiment, the game system 1 determines at least one of the above parameters based on probability (for example, using a random number). This makes it possible to generate non-player characters with diverse shapes. The parameter that is determined randomly based on probability may be one of the above parameters or two or more parameters.

[0129] Figure 19 shows an example of each part arranged based on the parameters determined as described above. Each part 211-213 is arranged to include reference positions 225a and 225b, so as shown in Figure 19, it is arranged to partially overlap with at least one other part. However, in other embodiments, each part 211-213 may be arranged so as not to overlap with other parts. Also, as described above, the direction in which each surface portion 221-223 faces and its position in the front-rear direction are fixed, so each surface portion 221-223 is arranged to be located within the reference plane 226 that includes reference positions 225a and 225b.

[0130] When parts 211 to 213 are placed, the game system 1 generates a body object 214 by combining parts 211 to 213. Figure 20 shows an example of a body object generated based on parts 211 to 213 shown in Figure 19. As shown in Figure 20, the game system 1 generates the body object 214 so that the parts 211 to 213 form a unified shape (specifically, the surfaces of the parts 211 to 213 that do not overlap with other parts become the surfaces of the body object 214). The body object 214 has a surface portion 224 that is positioned to coincide with the surfaces formed by the surface portions 221 to 223 of parts 211 to 213 and to include reference positions 225a and 225b.

[0131] As described above, in this embodiment, the multiple parts 211-213 and the body object 214 of the player character are voxel objects generated based on voxel data. Therefore, for example, the game system 1 can obtain the voxel data of the body object 214 by adding the density of each voxel in the voxel data of each part 211-213 for each voxel. In this way, in this embodiment, the process of obtaining the body object 214 by combining parts 211-213 can be easily performed using voxel data. Furthermore, when generating the body object 214 using voxel data, the number of vertices in the mesh of the generated body object 214 may change with each generation process, making it easier to generate body objects with a wide variety of shapes. Note that in other embodiments, the parts 211-213 and the body object 214 do not have to be voxel objects, and the player character does not have to be a voxel object.

[0132] The specific method for generating the body object 214 by combining parts 211-213 is arbitrary. For example, game system 1 may generate a body object composed of meshes by combining parts composed of meshes. Furthermore, the shapes defined by parts 211-213 do not have to strictly match the shapes of the body object 214. Specifically, the surfaces of parts 211-213 that do not overlap with other parts do not have to strictly match the surfaces of the body object 214. For example, game system 1 may generate a body object by changing the shape of the boundary between one part and another so that the corners are smooth.

[0133] In this embodiment, the materials (specifically, properties and textures) set for each part 211 to 213 are assumed to be the same. However, in other embodiments, the materials set for each part 211 to 213 are arbitrary, and different materials may be set for each part. In this case, for the body object 214, different materials may be set for each part corresponding to the original part, or a material based on the materials of each part (for example, a material with properties that are a combination of the materials of each part) may be set, or the material of any one of the parts may be set.

[0134] Figure 21 shows an example of a generated non-player character. As shown in Figure 21, the game system 1 adds eye objects 215 to the generated body object 214. In this embodiment, of the two eye objects, the right eye object 215a is placed at reference position 225a, and the left eye object 215b is placed at reference position 225b. As described above, the face portion 224 of the body object 214 is placed in a position that includes reference positions 225a and 225b. Therefore, as shown in Figure 21, the eye objects 215 are placed on the surface of the face portion 224.

[0135] The reference position does not need to be the center of the object; it can be any position where any part of the object (in this case, the eye object 215) is placed at that reference position. In other words, the eye object 215 only needs to be positioned such that a part of it is at the reference position, and the other part may be embedded in the body object 214.

[0136] As described above, in this embodiment, the game system 1 determines each parameter (i.e., position parameter, rotation parameter, and scale parameter) so that the reference positions 225a and 225b are located on the surface of the non-player character. This reduces the possibility that the non-player character may look unnatural due to the eye object 215 being embedded in the body object 214 and becoming invisible, or being positioned far away from the body object 214. In other embodiments, the above parameters may be determined to values ​​such that the reference position is positioned away from the surface of the non-player character (for example, the reference position is positioned slightly in front of the surface of the non-player character).

[0137] As described above, in this embodiment, in a three-dimensional virtual space, each of the multiple parts 211 to 213 has a flat surface portion 221 to 223. The game system 1 determines position parameters and scale parameters so that the plane containing the reference positions 225a and 225b (in this embodiment, the reference plane 226) and each of the surface portions 221 to 223 of the multiple parts 211 to 213 are located on the same plane. The game system 1 also determines rotation parameters so that the surface portions 221 to 223 are perpendicular to the reference direction (in this embodiment, the negative z-axis direction) and face the reference direction. According to the above, the eye object 215 can be placed on the plane formed based on the surface portions of each part 211 to 213 (i.e., the surface portion 224 of the body object 214), thereby reducing the possibility of the non-player character having an unnatural appearance. In other embodiments, a part may have multiple flat surfaces, in which case the game system 1 may determine the rotation parameters for the part such that one of the multiple surfaces is perpendicular to the reference direction and faces the reference direction.

[0138] Furthermore, as described above, in this embodiment, the game system 1 determines each parameter for each of the multiple parts 211 to 213 within a preset range such that the reference position is not obscured by the body object on the reference direction side of the non-player character. Specifically, the position parameter is determined within a range in which the surface portion of the part includes the reference position, and the rotation parameter is determined to be a fixed value around the left-right axis and the up-down axis. This reduces the possibility of the non-player character appearing unnatural. In other embodiments, the specific content of the "pre-set range" is not limited to the example of the above embodiment, and other ranges may be used. For example, in other embodiments, the game system 1 may set the range of possible values ​​for the rotation parameter to be variable around the left-right axis or the up-down axis, and adjust the range of other parameters (i.e., position parameter and scale parameter) according to the value of the rotation parameter within that range so that the reference position is not obscured by the body object.

[0139] Furthermore, the game system 1 adds a foot object 216 to the body object 214. In this embodiment, the foot object 216 is placed in a predetermined position. In this embodiment, unlike the eye object 215, there are no restrictions on the generation of the body object 214 regarding the position of the foot object 216. Therefore, there may be cases where part of the foot object 216 is embedded in the body object 214, or where the foot object 216 is placed separately from the body object 214. In this embodiment, the non-player character 211 has a form in which the body (which can also be called the face) occupies the majority of the whole, so the position of the eye object 215 in the body object 214 is thought to affect the unnaturalness of the appearance of the non-player character 211. In contrast, even in the above cases, the unnaturalness of the appearance of the non-player character is thought to be smaller for the foot object 216 (compared to the case of the eye object 215). Therefore, in this embodiment, the foot object 216 is fixedly placed regardless of the shape of the body object 214.

[0140] In other embodiments, the game system 1 may position the foot object 216 such that it is not partially obscured by the body object 214. For example, if, with the foot object 216 positioned at a predetermined reference position, part of the foot object 216 is embedded in the body object 214 or the foot object 216 separates from the body object 214, the game system 1 may move the foot object 216 vertically (i.e., in the y-axis direction) from the reference position so that at least the upper end of one of the feet of the foot object 216 touches the body object 214.

[0141] As described above, in this embodiment, the non-player character has a foot object 216, but the form of the non-player character is arbitrary. For example, in other embodiments, the non-player character does not have to have a foot object 216, or it may have a hand object in addition to (or instead of) the foot object 216.

[0142] The non-player characters generated as described above are placed in the game space. In this embodiment, the game system 1 places the non-player characters in the game space by placing the sub-voxel space of the non-player characters in the game space.

[0143] In this embodiment, the non-player character generation process is executed when the generation conditions are met during the game. In this embodiment, the generation conditions are that a new game stage is generated during the game (for example, when a player character moves to a new game stage, the data of the new game stage is read into the DRAM 85). When the generation conditions are met, the game system 1 executes a generation process to generate non-player characters that appear in the new stage. The above generation conditions may be any conditions that can be met during the game. For example, the game system 1 may use the timing when a non-player character is displayed (for example, the timing when a non-player character is drawn when the distance from the virtual camera to the non-player character is within a predetermined distance) as the generation condition.

[0144] Based on the above, in this embodiment, the game system 1 determines each parameter (i.e., position parameter, rotation parameter, and scale parameter) during game execution and places non-player characters based on each determined parameter in the virtual space (i.e., game space) during game execution. This allows the game system 1 to generate non-player characters of different shapes each time the game is executed. Note that "during game execution" includes the start of the game. In other words, the game system 1 may execute the above generation process at the start of the game. In other embodiments, the above generation process may be executed at a time when the game is not being executed.

[0145] Game system 1 controls the movement of non-player characters placed in the game space. In this embodiment, game system 1 changes the orientation of non-player characters according to the game situation. Specifically, game system 1 controls non-player characters so that their reference direction (i.e., the front direction) faces the direction from non-player character to player character. This allows non-player characters to move so that they face forward from the perspective of the player character. In other embodiments, game system 1 does not need to control the movement of non-player characters, and non-player characters may be objects that do not move (i.e., objects that are simply placed in the game space).

[0146] Furthermore, in this embodiment, since the non-player character (specifically, the body object 214) is a voxel object, it can be erased (also called destroyed) during the game, similar to the terrain object described above. Specifically, when some kind of impact is applied to the non-player character, the game system 1 erases a part of the body object 214 by updating the voxel data of the body object 214 (more specifically, the density data described above). For example, the game system 1 erases a part of the non-player character in response to actions by the player character (for example, in response to actions such as the player character punching the non-player character or hitting the non-player character with another object). As a result, the player can change the shape of the non-player character by manipulating the player character. In this embodiment, since the non-player character can take on various shapes, even if the destruction action by the player character is the same, the destroyed non-player character can take on various shapes, thus further enhancing the enjoyment of the operation to destroy the non-player character.

[0147] As described above, if a part of a non-player character (specifically, body object 214) is erased, the game system 1 restores the shape of the non-player character to its original shape over time. Specifically, the game system 1 gradually changes the voxel data (more specifically, density data) of body object 214 over time so that it returns to its value before the update. Therefore, even if the non-player character is destroyed by the actions of the player character, it will gradually return to its original shape. According to the above, the player can enjoy repeatedly deforming the non-player character.

[0148] Furthermore, similar to the terrain objects described above, it may be possible to add other objects to non-player characters. Specifically, when a predetermined object (for example, a rock object with the same material as the body object 214) comes into contact with the body object 214 of a non-player character, the game system 1 integrates that object with the body object 214. In other words, in the above case, the game system 1 makes the shape of the new body object 214 the original shape of the body object 214 with the object attached. Also, if other objects are added to a non-player character, the game system 1 may return the shape of the non-player character to its original shape over time, similar to when objects are removed.

[0149] [3. Specific examples of processing in game systems] Next, we will explain a specific example of information processing in game system 1 with reference to Figures 22 to 24.

[0150] Figure 22 shows an example of various types of data used for information processing in the game system 1. As shown in Figure 22, the game system 1 stores game programs, parts data, and non-player character data. The game program and parts data are data that are stored in the game system 1 in advance before the execution of game processing. The game program and parts data are stored, for example, in a storage medium installed in slot 23 of the main unit 2. The non-player character data is data that is generated during the execution of game processing. The non-player character data is stored, for example, in the DRAM 85 of the main unit 2.

[0151] The game program is a game program for executing the game processing in this embodiment (specifically, the game processing shown in Figure 23).

[0152] The part data refers to the data for each of the parts 211-213 mentioned above. Specifically, the part data includes data indicating the shape of each of the parts 211-213.

[0153] Non-player character data is data relating to a non-player character. Non-player character data includes voxel space data, voxel object data, mesh data, and partial object data. In this embodiment, non-player character data is generated and stored for each non-player character. In addition to the above data, non-player character data may also include data indicating the posture and state of the non-player character.

[0154] Voxel space data defines the sub-voxel space for non-player characters. Specifically, voxel space data includes data indicating the length of one side of a voxel in the sub-voxel space. It also includes data indicating the position, orientation, and size of the sub-voxel space in the game space.

[0155] The voxel object data includes voxel data related to non-player characters, i.e., voxel data for each voxel in the sub-voxel space described above. The voxel object data is data that defines the shape of the non-player character in the sub-voxel space.

[0156] Mesh data is data that represents the mesh assigned to a non-player character. Mesh data includes, for example, data indicating the position of each vertex in the mesh.

[0157] Partial object data refers to data relating to partial objects (in this embodiment, eye objects and foot objects) that are parts of a non-player character other than voxel objects. Specifically, partial object data includes data indicating the shape, position, and orientation of the partial objects.

[0158] In addition to the data shown in Figure 22, the game system 1 also stores data that defines the main voxel space set in the game space, data that indicates voxel objects (in this case, terrain objects) placed in the main voxel space, and data that indicates the mesh set for said voxel objects (i.e., the mesh of the terrain object).

[0159] Figure 23 is a flowchart illustrating an example of the game processing flow performed by game system 1. The game processing shown in Figure 23 is initiated, for example, when the player issues an instruction to start the game during the execution of the game program described above.

[0160] 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 23. 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 23 may be executed by the other information processing device. Furthermore, the processing of each step shown in Figure 23 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.

[0161] Furthermore, the processor 81 executes the processing of each step shown in Figure 23 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.

[0162] In step S1 shown in Figure 23, the processor 81 sets up a voxel space in the game space. Specifically, the processor 81 acquires the voxel space data and stores it in the DRAM 85 (in other words, writes it). In subsequent game processing, the processor 81 may refer to the voxel space data when executing processing related to voxel objects (for example, the processing in step S2). In this case, the processor 81 refers to the voxel space data stored in the DRAM 85. The processing in step S2 is executed after step S1.

[0163] In step S2, the processor 81 sets up voxel objects (specifically, terrain objects) in the main voxel space in the game space. Specifically, the processor 81 acquires voxel data indicating the arrangement of terrain objects in the initial state and stores (in other words, writes) part or all of the acquired voxel data to the DRAM 85. The voxel data indicating the arrangement of terrain objects in the initial state is stored, for example, in a storage medium installed in slot 23 of the main unit 2. The processing in step S3 is executed after step S2.

[0164] In step S3, the processor 81 determines whether the above-mentioned generation conditions for generating a non-player character have been met. For example, if the game starts or if a player character moves to a new game stage, it is determined that the generation conditions have been met. If the result of the determination in step S3 is positive, the process in step S4 is executed. On the other hand, if the result of the determination in step S3 is negative, the process in step S4 is skipped and the process in step S5 is executed.

[0165] In step S4, the processor 81 executes a character generation process to generate non-player characters. The detailed flow of the character generation process will be explained below with reference to Figure 24.

[0166] Figure 24 is a subflowchart showing an example of a detailed flow of the character generation process in step S4 shown in Figure 23. In the character generation process, first in step S11, the processor 81 places multiple parts to be used to generate non-player characters in the sub-voxel space (see Figure 19). Specifically, the processor 81 randomly determines a set of parameters (i.e., position parameter, rotation parameter, and scale parameter) according to the method described in "[2-3. Generation of Voxel Objects]" above. Furthermore, the processor 81 reads the part data stored in the DRAM 85 and calculates each voxel data representing each part placed in the sub-voxel space based on the part data and the determined parameters. The process in step S12 is executed after step S11.

[0167] In step S12, the processor 81 generates a body object for the non-player character based on the parts placed in the sub-voxel space (see Figure 20). Specifically, the processor 81 calculates the voxel data for the body object based on the voxel data calculated in step S11, according to the method described in "[2-3. Generation of Voxel Objects]" above. The calculated voxel data is stored in the DRAM 85 as the voxel object data for the non-player character. The processing in step S13 is executed after step S12.

[0168] In step S13, the processor 81 adds eye objects to the body object generated in step S12. Specifically, the processor 81 places the eye objects at the aforementioned reference positions. At this time, the partial object data stored in the DRAM 85 for the non-player character is updated to include data related to the added eye objects. The processing in step S14 is executed after step S13.

[0169] In step S14, the processor 81 adds a leg object to the body object generated in step S12. Specifically, the processor 81 places the leg object at a predetermined position. At this time, the partial object data stored in the DRAM 85 for the non-player character is updated to include data about the added leg object. The processing in step S15 is executed after step S14.

[0170] In step S15, the processor 81 places the non-player character generated by the processing in steps S11 to S14 into the game space. Specifically, the non-player character is placed into the game space by setting its sub-voxel space into the game space. At this time, the voxel space data stored in the DRAM 85 for the non-player character is updated to include data indicating the position, orientation, and size of the sub-voxel space in the game space. The processing in step S16 is executed after step S15.

[0171] The voxel space data and voxel object data stored in the DRAM 85 through the processes in steps S11 to S15 above define the position, orientation, and shape of the non-player character in the game space. Furthermore, the mesh of the non-player character is generated based on the voxel object data through the process in step S8, which will be described later.

[0172] In step S16, the processor 81 determines whether all non-player characters to be generated have been generated in relation to the generation conditions that were determined to have been met in step S3. For example, if the generation conditions are met in accordance with the generation of a new game stage, the processor 81 determines whether all non-player characters that appear in the new game stage and are generated in this character generation process have been generated. If the result of the determination in step S16 is negative, the process in step S11 is executed again. Thereafter, the series of processes from steps S11 to S16 are repeatedly executed until it is determined in step S16 that all non-player characters have been generated. On the other hand, if the result of the determination in step S16 is positive, the processor 81 terminates the character generation process shown in Figure 24. Following the character generation process in step S4, the process in step S5 is executed.

[0173] In step S5, the processor 81 controls the movements of various characters appearing in the game space (specifically, the player character and the non-player character). For example, the processor 81 controls the movements of the player object based on the operation data received from each controller 3 or 4. The processor 81 also controls the non-player character to face the player character. The processing in step S6 is executed after step S5.

[0174] In step S6, the processor 81 determines whether a change event has occurred for a non-player character as a result of operating various characters in accordance with the processing in step S5. A change event is a game event that changes a non-player character (for example, erasing part of it, adding other objects, or restoring a changed non-player character to its original state). For example, if some kind of impact is applied to a non-player character, the processor 81 determines that a change event has occurred for that non-player character. If the result of the determination in step S6 is positive, the processing in step S7 is executed. On the other hand, if the result of the determination in step S6 is negative, the processing in step S7 is skipped and the processing in step S8 is executed.

[0175] In step S7, the processor 81 modifies the non-player character in response to the change event. Specifically, the processor 81 erases a portion of the non-player character, adds other objects to the non-player character, or restores the non-player character, which has been deformed by these erasures or additions, back to its original shape. In this embodiment, the processor 81 modifies the density of at least some of the voxel data relating to the non-player character in which the change event occurred. This deforms the non-player character in which the change event occurred. The processor 81 also updates the voxel object data stored in the DRAM 85 to reflect the modified density. The processing in step S8 is executed after step S7.

[0176] In addition, in steps S6 and S7 above, the processor 81 may also determine whether a change event has occurred for other voxel objects (for example, terrain objects) other than non-player characters, in the same way as for non-player characters, and if it is determined that a change event has occurred for other voxel objects, it may change those other voxel objects.

[0177] In step S8, the processor 81 generates a mesh for the voxel object. The mesh for the voxel object is generated according to the method described in "[2-2. Mesh]" above. Note that in step S8, the processor 81 does not need to regenerate the mesh that was generated in the previous steps of step S8, and may regenerate the mesh for the newly generated non-player character voxel data in step S4 (i.e., the voxel object data shown in Figure 22) and the updated voxel data in step S7. The processing in step S8 allows the mesh of the voxel object to be dynamically changed during the game. The processor 81 also updates the mesh data stored in the DRAM 85 to reflect the newly generated mesh. The processing in step S9 is executed after step S8.

[0178] In step S9, the processor 81 generates a game image representing the game space and displays it on the display device. Specifically, the processor 81 generates a game image representing the game space, including voxel objects and other objects. The image of the voxel object is generated using the voxel object data and mesh data stored in the DRAM 85, according to the method described in "[2-2. Mesh]" above. The processor 81 displays the generated game image on the display device. During the game, the process in step S9 is repeatedly executed at a rate of once every predetermined time (for example, 1 frame time). The process in step S10 is executed after step S9.

[0179] In step S10, 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 S10 is negative, the process in step S3 is executed again. Thereafter, the series of processes from steps S3 to S10 are repeatedly executed until it is determined in step S10 that the game should be terminated. On the other hand, if the result of the determination in step S10 is positive, the processor 81 terminates the game process as shown in Figure 23.

[0180] [4. Effects and Modifications of This Embodiment] As described above, in the above embodiment, the information processing system (specifically, the game system 1) is configured to include the following means. • Parameter determination means (step S11) for determining the position, rotation, and scale parameters for each of the multiple parts (for example, parts 211-213 shown in Figure 16, etc.) Object generation means (steps S12, S13) that generates a composite object (specifically, a non-player character) having a first part (specifically, a body object 214) having a shape formed by combining multiple parts arranged in a virtual space based on each parameter, and a second part (specifically, an eye object 215) that is placed at a reference position in the virtual space and is a part different from the first part. The parameter determination means described above determines each parameter such that the reference position is not obscured by the first part on the reference direction side (specifically, the front direction side) of the composite object.

[0181] According to the above configuration, by generating the first part using parts with various values ​​for each of the above parameters, it is possible to generate composite objects with various shapes. Furthermore, according to the above configuration, since each parameter is determined so that the reference position is not obscured by the first part, it is possible to reduce the possibility of generating composite objects with unnatural shapes, such as the second part being hidden by the first part.

[0182] Furthermore, "the reference position is obscured by the first part" means that the reference position is located inside the first part, and does not include the reference position being located on the surface of the first part. Also, the second part placed at the reference position does not need to be positioned so that the entire part is not obscured by the first part; it is sufficient if at least a part of it is not obscured by the first part. For example, if the first part has a box-like shape with a bottom and side parts and an open top, and the reference position is located on the inner surface of the side part of the box, then when viewed from the front (in this example, the front direction is assumed to be the reference direction), it can be said that the reference position is obscured by the first part. Therefore, in the above case, game system 1 sets the above parameters so that the reference position is located on the outer surface of the front side part of the box.

[0183] In the above embodiment, the game system 1 determines each parameter under predetermined limitations so that the reference position is not obscured by the first part, but the method for determining each parameter is not limited to this. For example, in another embodiment, the game system 1 may repeat the process of determining each parameter based on probability until parameters are determined such that the reference position on the reference direction side of the composite object is not obscured by the first part. This can also achieve the same effects as in the above embodiment.

[0184] In the above embodiment, the composite object was a non-player character not controlled by the player. In other embodiments, the composite object may be any object that appears in the game, and may be a player character or an object that is placed in the game space and does not perform any actions. For example, the composite object may be a terrain object, a rock object, or a tree object.

[0185] In the above embodiment, the object placed at the reference position (i.e., the second part) was an eye object representing the eyes of a non-player character. However, in other embodiments, the object placed at the reference position is not limited to this. The second part may be any object representing a part of an object, and may be an object representing the nose, mouth, hands, or feet of a character. Furthermore, if the composite object is a turret object, the second part may be an object representing the barrel of the cannon, and if the composite object is a clock object, the second part may be an object representing the clock face.

[0186] In the above embodiment, the case of generating a three-dimensional composite object was described as an example, but the generation process in the above embodiment is also applicable to the generation of a two-dimensional composite object. That is, when the game system 1 generates the first part using two-dimensional parts, it may determine the parameters of each part such that the reference position on the reference direction side in the two-dimensional plane does not fall inside the first part.

[0187] In other embodiments, the game system 1 may change the shape of the composite object during gameplay. For example, the game system 1 may change the shape of the composite object in time with the rhythm, or in response to changes in the game situation. In this case, the shape of the composite object after the change is determined in the same manner as when the shape of the composite object is determined in the generation process described above. This makes it possible to randomly change the shape of the composite object.

[0188] In the above embodiment, when processing is performed using data (meaning including programs) in a certain information processing device, some of the data necessary for the processing may be transmitted from another information processing device different from the said information processing device. In this case, the said information processing device may perform the processing using the data received from the other information processing device and the data stored in itself.

[0189] In other embodiments, the information processing system may not have some of the configurations in the above embodiments, nor may it perform some of the processes executed in the above embodiments. For example, in order to achieve some of the specific effects in the above embodiments, the information processing system may have to have the configurations necessary to achieve those effects and perform the processes necessary to achieve those effects, but it may not have to have other configurations or perform other processes. [Industrial applicability]

[0190] The above embodiment can be used, for example, as a game system or game program, for the purpose of generating diverse objects using multiple parts. [Explanation of symbols]

[0191] 1. Game System 2. Main unit 81 processors Parts 211-213 214 Body Objects 215th object 216 Foot Objects 221~224 surface area 225a,225b Reference position

Claims

1. An information processing program executed in a computer of an information processing device, wherein the computer A parameter determination means for determining the position, rotation, and scale parameters for each of the multiple parts, The object generation means functions to generate a composite object having a first part having a shape formed by combining the plurality of parts arranged in the virtual space based on the aforementioned parameters, and a second part that is arranged at a reference position in the virtual space and is a part different from the first part. The parameter determination means is an information processing program that determines each parameter such that the reference position on the reference direction side of the composite object is not obstructed by the first portion.

2. The information processing program according to claim 1, wherein the parameter determination means determines each parameter such that the reference position is located on the surface of the first portion.

3. The aforementioned virtual space is a three-dimensional space. Each of the aforementioned parts has a flat surface portion, The information processing program according to claim 1, wherein the parameter determination means determines the position parameter and the scale parameter so that the plane including the reference position and each of the surface portions of the plurality of parts are located in the same plane, and determines the rotation parameter so that the surface portion is perpendicular to the reference direction and faces the side of the reference direction.

4. The information processing program according to claim 1, wherein the parameter determination means determines each of the plurality of parts within a range predetermined such that the reference position on the reference direction side of the composite object is not obstructed by the first part.

5. The information processing program according to any one of claims 1 to 4, wherein the parameter determination means determines at least one of the parameters based on probability.

6. The information processing program according to claim 1, wherein the parameter determination means repeats the process of determining each parameter based on probability until each parameter is determined such that the reference position on the reference direction side of the composite object is not obstructed by the first portion.

7. The parameter determination means determines each of the parameters during the execution of the game. The information processing program according to claim 1, wherein the object generation means places the composite object in the virtual space during the execution of the game.

8. The information processing program according to claim 1, wherein the plurality of parts and the first part of the composite object are voxel objects generated based on voxel data.

9. The information processing program according to claim 1, wherein the composite object is a non-player character.

10. The information processing program according to claim 9, further comprising the computer functioning as a character control means for controlling the non-player character such that the reference direction is oriented from the non-player character to the player character.

11. The information processing program according to claim 9, further comprising the computer being used as an object erasure means for erasing a portion of the composite object in response to the actions of the player character.

12. The information processing program according to claim 11, further comprising the computer functioning as an object restoration means to restore the shape of the composite object to its original shape in accordance with the passage of time if a part of the composite object is erased.

13. The information processing program according to any one of claims 9 to 12, wherein the second part is an object representing the eyes of the non-player character.

14. The information processing program according to any one of claims 9 to 12, wherein the composite object further comprises an object representing the feet of the non-player character.

15. A parameter determination means for determining the position, rotation, and scale parameters for each of the multiple parts, The object generation means generates a composite object having a first part having a shape formed by combining the plurality of parts arranged in a virtual space based on the aforementioned parameters, and a second part that is arranged at a reference position in the virtual space and is a part different from the first part. The parameter determination means is an information processing system that determines each parameter such that the reference position on the reference direction side of the composite object is not obstructed by the first portion.

16. A parameter determination means for determining the position, rotation, and scale parameters for each of the multiple parts, The object generation means generates a composite object having a first part having a shape formed by combining the plurality of parts arranged in a virtual space based on the aforementioned parameters, and a second part that is arranged at a reference position in the virtual space and is a part different from the first part. The parameter determination means is an information processing device that determines each of the parameters such that the reference position on the reference direction side of the composite object is not obstructed by the first portion.

17. An information processing method performed by an information processing system, A parameter determination step for each of the multiple parts, which determines the parameters of position, rotation, and scale, The object generation step includes generating a composite object having a first part having a shape formed by combining the plurality of parts arranged in a virtual space based on the aforementioned parameters, and a second part that is arranged at a reference position in the virtual space and is a part different from the first part, An information processing method in which, in the parameter determination step, each parameter is determined such that the reference position on the reference direction side of the composite object is not obscured by the first portion.

Images