JP7795435B2 - Game program, game control method and information processing device - Google Patents

Description

This disclosure relates to a game program, a game control method, and an information processing device.

Patent document 1 describes measuring the surface area of objects exposed in the player character's field of view, and prioritizing loading of objects whose measured surface area is least obscured by the surface area of other objects.

Patent No. 4503073

Patent document 1 discloses a number of algorithms that can be used to check whether an object exposed in the player character's field of view is occluded by another object. For example, patent document 1 describes that various algorithms can be selected for checking for occlusion, such as occlusion horizon (Occlusion Horizon), shaft occlusion culling (ShaftOcclusionCulling), hardware occlusion query (HardwareOcclusionQuery), hierarchical Z-buffering, and the hierarchical occlusion map algorithm (The HOMalgorithm).

This disclosure proposes technology that can easily perform occlusion checks for multiple objects and reduce the load on rendering processing.

In one embodiment, a game program is provided that causes a computer to execute a rendering process for a game image captured by a virtual camera in a virtual space, the program including: (a) when there are multiple objects captured by the virtual camera, treating each of the multiple objects as a single object, and calculating the occlusion level of the single object based on the presence or absence of other objects that are within a predetermined distance from the single object and within a predetermined angle in the direction from the single object toward the virtual camera; (b) determining the update frequency for each of the multiple objects based on the occlusion level for each of the multiple objects; and (c) controlling the updating of the rendering process for each of the multiple objects based on the update frequency for each of the multiple objects.

In one aspect, the present disclosure makes it easy to perform occlusion checks for multiple objects, reducing the load on rendering processing.

FIG. 1 is a diagram showing an example of the configuration of a game system according to an embodiment. FIG. 10 is a diagram showing another example of the configuration of the game system according to the embodiment. FIG. 1 is a diagram showing the hardware configuration of a game machine according to an embodiment. FIG. 1 is a diagram showing the functional configuration of a game machine according to an embodiment. 10A and 10B are diagrams for explaining determination of the update frequency of an object in conventional drawing. 4 is a flowchart showing a game control method according to the first embodiment. 5A to 5C are diagrams showing an example of calculation of an occlusion level in the game control method according to the first embodiment. 5A to 5C are diagrams showing an example of calculation of an occlusion level in the game control method according to the first embodiment. 10 is a flowchart showing a game control method according to a second embodiment. 10A and 10B are diagrams showing an example of calculation of an occlusion level in the game control method according to the second embodiment. 10A and 10B are diagrams showing an example of calculation of an occlusion level in the game control method according to the second embodiment. 10A and 10B are diagrams showing an example of calculation of an occlusion level in the game control method according to the second embodiment. 10 is a flowchart showing a game control method according to a third embodiment. FIG. 11 is a diagram for explaining the game control method according to the third embodiment in comparison with a comparative example.

The following describes embodiments of the present disclosure with reference to the drawings. Note that in this specification and drawings, substantially identical components may be designated by the same reference numerals to avoid redundant description.

[Game System]
1 is a diagram showing an example of the configuration of a game system 1 according to an embodiment. The game system 1 includes a game machine 3, which is an example of an information processing device, a game controller 5, and a display device 7. The game controller 5 and the display device 7 are each connected to the game machine 3 via wire or wirelessly so as to be able to communicate with each other.

Game machine 3 is, for example, a stationary game machine. However, it is not limited to this, and game machine 3 may also be, for example, a portable game machine that is equipped with an input unit, display unit, etc.

Furthermore, the game machine 3 is not limited to a dedicated game machine, but may be, for example, a computer, desktop computer, notebook computer, tablet computer, or other computer that is manufactured, sold, etc., or a mobile terminal that also functions as a telephone, such as a smartphone, mobile phone, or phablet. These devices are normally used as general-purpose information processing terminal devices, but when a player executes the installed game program, the player can progress through the game, just like a dedicated game machine.

The game program of this embodiment is installed on the game console 3. The game program is distributed in a state stored on an optical storage medium such as a CD-ROM or semiconductor memory such as a USB memory, or is distributed by being downloaded from a server device.

The player uses the game controller 5 to perform various operational inputs. In the example shown in FIG. 1, the game controller 5 has, for example, a cross key 9 and multiple buttons 8. Note that the game controller 5 may have, for example, a joystick or a touchpad instead of or in addition to the above. The game controller 5 may also have a microphone, allowing for voice control. The game controller 5 may also have a gyro sensor, acceleration sensor, or the like, allowing for control by the player changing the orientation of the game controller 5.

The game console 3 may also communicate with a server device on the network (see Figure 2). Multiple game consoles 3 running the same game program connect to the server device, enabling so-called online games. An online game is, for example, a game in which multiple players can operate the same game program cooperatively. The server device for an online game may accept the positions and operation commands of other players and transmit them to the game consoles 3 of the other players. The game consoles 3 perform the actual game processing, such as drawing each player and reflecting operation commands.

Figure 2 is a diagram showing another example configuration of a game system 1 according to an embodiment. The game system 1 according to an embodiment provides various game-related services to players via a network N (e.g., the Internet, etc.). The game system 1 includes a server device 2 and a terminal device 30. The server device 2 is an example of an information processing device that provides various game-related services to the terminal device 30. The server device 2 may be a personal computer, a workstation, a cloud computer, etc.

The terminal device 30 is an example of an information processing device used by a player when playing a game. The terminal device 30 may be a game console, a computer manufactured, sold, etc. as a computer, such as a desktop computer, notebook computer, or tablet computer, or a mobile terminal that also functions as a telephone, such as a smartphone, mobile phone, or phablet.

The terminal device 30 requests the server device 2 to distribute various information related to the game (such as a game program containing game control methods and game screens). Upon receiving a request for distribution of various information from the terminal device 30, the server device 2 distributes the game program and web pages of the game screens to be played on the terminal device 30.

The terminal device 30 has a web browser function that allows the player to view web pages displaying game screens. This allows the terminal device 30 to display web pages such as game screens distributed from the server device 2. The server device 2 may provide games such as online games in which player characters and non-player characters operated by players are divided into allies and enemies and compete against each other.

The game system 1 may be a so-called P2P (Peer to Peer) system in which a game machine 3 as illustrated in FIG. 1 or a terminal device 30 as illustrated in FIG. 2 communicates with another game machine 3 or another terminal device 30. In this case, the server device 2 of FIG. 2 does not need to be provided. The game system 1 may also be a so-called cloud game. Note that the game system 1 of FIGS. 1 and 2 is just an example, and various system configurations can be considered depending on the application and purpose. Below, the game system 1 of this embodiment will be described mainly using the configuration of FIG. 1.

The game machine 3 can provide all kinds of games, including fighting games, sports games, racing games, and city-building games. The game machine 3 can also provide games through gacha or other methods. However, the games executed by the game system 1 disclosed in this embodiment are 3D or 2D games executed in a virtual space, and fighting games (action games) are preferred. In this embodiment, the game processing is controlled to present a more natural gameplay in a battle between a first character and a second character.

In this embodiment, the term "object" refers to a general term for objects, including characters, that exist primarily in virtual space (e.g., 3D space). For example, player characters (PCs), non-player characters (hereinafter also referred to as "NPCs"), buildings, and other objects are basically anything that appears in virtual space. Characters include enemy characters and ally characters, and may be player characters controlled by the player, or non-player characters automatically controlled by AI or the like.

[Game console hardware configuration]
Next, the hardware configuration of the game machine 3 will be described with reference to FIG. 3 . FIG. 3 is a diagram showing the hardware configuration of the game machine 3 according to the embodiment. The game machine 3 has a CPU (Central Processing Unit) 121, a memory 122, a communication device 123, an input device 124, and a display device 125. The CPU 121 controls the game machine 3. The memory 122 is, for example, a storage medium within the game machine 3 that is directly accessible by the CPU 121. The communication device 123 is a communication device such as a network circuit that controls communication with other devices. The input device 124 is an input device that is connected to the game machine 3 like the game controller 5 and does not necessarily have to be located inside the game machine 3. The input device 124 may be an input device such as a camera or a touch panel. The display device 125 is an output device such as a display.

The game console 3 may be equipped with various microprocessors such as a GPU (Graphics Processing Unit) or a DSP (Digital Signal Processor), and various types of memory 122 such as VRAM, RAM, and ROM.

The game machine 3 stores various game data necessary for playing the game through calculations in the memory 122, and has a game management function that controls and manages the game processing. The game control method is executed by the CPU 121 performing calculations based on a predetermined game program and game data.

[Functional configuration of game console]
Next, the functional configuration of the game machine 3 will be described with reference to Fig. 4. Fig. 4 is a diagram showing the functional configuration of the game machine 3 according to the embodiment. The game machine 3 has a control unit 11, a storage unit 12, and a communication unit 13.

The control unit 11 exchanges data between each unit and controls the game machine 3. The control unit 11 is realized by the CPU 121 executing a game program stored in the memory 122.

The storage unit 12 stores a game program that causes the computer to run the game, as well as various data and information. The game program includes a program that causes the computer to execute a rendering process for game images captured by a virtual camera in virtual space. The storage unit 12 is realized, for example, by memory 122. The storage unit 12 has a ROM (Read Only Memory), which is a read-only storage area in which the game program is stored, and a RAM (Random Access Memory), which is a rewritable storage area used as a work area for calculations by the control unit 11. The storage unit 12 is realized, for example, by a non-volatile storage device such as flash memory or a hard disk. Part or all of the game program may be stored in RAM.

Furthermore, the memory unit 12 stores an occlusion level 21 and character information 22. Calculation of the occlusion level 21 will be described later. The character information 22 includes the character's size, the character's importance, the character's movement speed, the character's motion (whether the character is in an attack motion or is being attacked, etc.), the distance between the character and the player character, the distance between the character and the virtual camera, etc.

The communication unit 13 has the function of communicating with the terminal device and/or other devices. The communication unit 13 functions as a receiving unit that receives various data transmitted from the terminal device and/or other devices, and as a transmitting unit that transmits various data to the terminal device and/or other devices in response to commands from the control unit 11. The communication unit 13 is realized, for example, by a NIC (Network Interface Card).

The control unit 11 has a game execution processing unit 14, a calculation unit 15, an update control unit 16, a collision determination unit 17, and a display control unit 18. The game execution processing unit 14 executes a fighting game in a virtual space, for example, in which a player character operated by a player fights against an enemy boss character. However, the game executed by the game execution processing unit 14 may be various games other than fighting games.

In this specification, "objects" refer to display components displayed in virtual space, and include movable and fixed objects displayed on the game screen. Movable objects include player characters, non-player characters, horses, weapons, etc. Objects such as buildings and mountains are usually fixed objects, but may also be movable objects.

When there are multiple objects photographed by the virtual camera, the calculation unit 15 considers each of the multiple objects to be a single object, and calculates the occlusion level of the single object based on the presence or absence of other objects that are within a predetermined distance from the single object and within a predetermined angle with respect to the direction from the single object toward the virtual camera.

If there are other objects within a predetermined angle, the calculation unit 15 may calculate the occlusion level of the one object to be higher than the occlusion levels of the other objects.If there are no other objects within a predetermined angle, the calculation unit 15 may set the occlusion level of the one object to the lowest level.

The calculation unit 15 may calculate the occlusion level of one object by classifying the object closest to the virtual camera as one of the multiple objects.

The calculation unit 15 may calculate the occlusion levels for each of the multiple objects until the occlusion levels of the multiple objects in the latest frame (next frame) no longer change from the occlusion levels of the multiple objects in the immediately preceding frame (previous frame). The calculation unit 15 may terminate the calculation of the occlusion levels when the occlusion levels of the multiple objects in the latest frame (next frame) no longer change from the occlusion levels of the multiple objects in the immediately preceding frame (previous frame).

The update control unit 16 determines the update frequency for each of the plurality of objects based on the occlusion level for each of the plurality of objects, and controls the update of the drawing process for each of the plurality of objects based on the update frequency for each of the plurality of objects.

The update control unit 16 may determine whether or not each of the multiple objects needs to be updated for each frame, according to the update frequency for each of the multiple objects, and update the drawing process for objects that are determined to need to be updated.

The collision determination unit 17 performs collision determination for multiple objects. The collision determination unit 17 will be described in detail in the third embodiment.

The display control unit 18 draws game scenes such as characters on the game screen in accordance with the drawing process of game images captured by the virtual camera in the virtual space. The display control unit 18 controls the updating of the drawing process for each of the multiple objects based on the update frequency for each of the multiple objects. The display control unit 18 displays a virtual space in which multiple characters and other objects appear on the display device 125 of the game machine 3. The display control unit 18 may control a web page of the game screen, send the web page of the game screen via the communication unit 13 to the terminal device on which the game is played, and display it on the screen of the terminal device.

[Conventional update frequency determination]
A conventional method for determining the update frequency will be described with reference to Fig. 5. Fig. 5 is a diagram for explaining a conventional method for determining the update frequency of an object in drawing.

When drawing characters and other objects on the game screen, update processing may be thinned out or the display of distant objects may be simplified. In particular, when updating the drawing of the actions of a large number of characters every frame, updating the actions of all characters can slow down the drawing processing. Therefore, to determine the update frequency for each character, an update priority is determined to determine which characters' drawing processing should be thinned out or whose display should be simplified, and most methods for this determination use the distance from the virtual camera to the character.

In this way, conventional methods determine the update priority for each character depending on their distance from the virtual camera, and change characters with low update priorities to lighter updates and thin out update processing. For example, in Figure 5, character N located in area B is closer to the virtual camera (easier to see) and therefore has a higher update priority. On the other hand, character N located in area A is farther from the virtual camera (is hidden by the character in front and therefore less visible from the virtual camera), and therefore has a lower update priority. Note that the circles in the figure indicate non-player characters (NPCs), but they may also be player characters.

In contrast, this embodiment performs occlusion checks based on the proximity or contact status of characters, estimates their visibility (or lack thereof) from the virtual camera, and uses this information to determine the update frequency. For example, this embodiment easily performs occlusion checks on multiple objects to calculate the occlusion level. The update frequency is then determined based on the occlusion level, and updates are thinned out or the display of distant objects is simplified, reducing the load on the rendering process.

This makes it difficult for the user to see low-quality update processes or characters for which update processes have been thinned out. This reduces the load on the rendering process while providing the user with high-quality game images. Below, we will explain the game control methods for the first to third embodiments in order.

First Embodiment
First, the game control method according to the first embodiment will be described with reference to Figures 6 to 8. Figure 6 is a flowchart showing the game control method according to the first embodiment. Figures 7 and 8 are diagrams showing an example of calculation of the occlusion level in the game control method according to the first embodiment.

[Game Control Method]
When the game control method is started, the game machine 3 executes each process of the flowchart shown in Fig. 6. Characters on the screen of a game executed by the game execution processing unit 14 are photographed by the virtual camera 10. Here, an example will be described in which the virtual camera 10 photographs multiple characters. The characters may be non-player characters (NPCs) or player characters (PCs).

First, in step S1, the update control unit 16 sets all characters captured by the virtual camera 10 as unprocessed characters (characters whose occlusion level updates have not yet been processed). Next, in step S2, the calculation unit 15 creates a list of unprocessed characters captured by the virtual camera 10 for each frame, sorted in order of proximity to the virtual camera 10.

Next, in step S3, the calculation unit 15 determines whether there are any unprocessed characters whose occlusion levels have not been updated. If it is determined that there are any unprocessed characters, the calculation unit 15 proceeds to step S5. If it is determined that there are no unprocessed characters, the calculation unit 15 proceeds to step S13.

In step S5, the calculation unit 15 identifies the unprocessed character that is closest to the virtual camera 10. Next, in step S7, the calculation unit 15 determines whether there are any other characters within a certain distance from the identified character and within 45 degrees to the left or right of the camera direction from the identified character. The condition "whether there are any other characters within a certain distance from the identified character and within 45 degrees to the left or right of the camera direction from the identified character" is referred to as "Condition 1." The fan-shaped region R in Figures 7(a) and (b) is an example of the "region within a certain distance and within 45 degrees to the left or right of the camera direction" indicated by Condition 1. In Figures 7(a) and (b), the fan-shaped region R is "the region within a certain distance P of radius F from character N1 and within 45 degrees to the left or right of character N1 in the direction C of the virtual camera 10." Note that the certain distance P and within 45 degrees to the left or right of the direction C of the virtual camera 10 are merely examples, and any distance and angle can be set.

If it is determined in step S7 that there are no other characters that satisfy condition 1, the calculation unit 15 proceeds to step S9, sets the occlusion level of the identified character to "0", and returns to step S3. In the case of Figure 7(a), there are no other characters in the fan-shaped region R. In this case, the occlusion level of character N1 is set to "0". The number shown inside character N1 in Figure 7(a) indicates the occlusion level. Note that a value other than "0" may be used as long as the occlusion level of the identified character is set to the lowest level.

On the other hand, if it is determined in step S7 that there is another character that satisfies condition 1, the calculation unit 15 proceeds to step S11. In step S11, the calculation unit 15 sets the occlusion level of the identified character to a value obtained by adding "1" to the maximum occlusion level of the other characters that satisfy condition 1, and then returns to step S3. In the case of Figure 7(b), other characters N2 and N3 are present in the fan-shaped region R. In this case, the occlusion level of character N1 is set to "2", which is the value obtained by adding "1" to the maximum occlusion level of the other characters N2 and N3, "1". Note that a value other than the value obtained by adding "1" to the maximum occlusion level of the other characters may be used as long as the occlusion level of the identified character is set to a value higher than the occlusion levels of other objects that satisfy condition 1.

The processing of steps S1 to S11 described above is repeated until it is determined in step S3 that there are no unprocessed characters whose occlusion levels have not been updated since the previous frame. As a result, the occlusion level update process is performed for all characters, as shown in an example in Figure 8. This determines the final occlusion level for each character N.

If it is determined in step S3 that there are no unprocessed characters, the process proceeds to step S13, where the update control unit 16 determines the update frequency for each of the multiple characters based on the occlusion level of each of the multiple characters. For example, the update control unit 16 performs update processing once every five frames for characters with an occlusion level of 4 or higher, and once every three frames for characters with an occlusion level of 1 or higher but lower than 4. The update control unit 16 also determines the update frequency, such as performing update processing for characters with an occlusion level of 0 every frame. Characters with a high occlusion level are less visible from the virtual camera 10, so the update frequency is reduced.

Next, in step S15, the display control unit 18 controls the updates for each of the multiple characters based on the update frequency for each of the multiple characters and draws a game image. Next, in step S17, the update control unit 16 determines whether the game is ending. If the update control unit 16 determines in step S17 that the game is ending, it ends this processing. If the update control unit 16 determines in step S17 that the game is not ending, it returns to step S1, sets all characters shown in the virtual camera 10 as unprocessed characters (characters whose occlusion level updates have not been processed), and continues processing.

The game control method according to the first embodiment makes it possible to easily perform occlusion checks for multiple characters based on the distance from a specific character whose occlusion level is calculated, the orientation of the virtual camera 10, and condition 1, which restricts the status of surrounding characters. This determines the occlusion level for each character, determines the update frequency for each character according to the occlusion level, and updates the rendering of each character based on the update frequency. This makes it difficult for the user to see characters that have undergone low-quality update processing or where update processing has been thinned out. This reduces the load on the rendering process, while clearly rendering game footage visible to the user and providing the user with high-quality game images.

Second Embodiment
In the first embodiment, when updating the occlusion level for each character, the correct occlusion level cannot be calculated unless the update is performed starting with the characters closest to the virtual camera 10. Therefore, in order to perform the update correctly, it is necessary to create a list in which the characters are sorted in order of proximity to the virtual camera 10 (FIG. 6, S1). However, as the number of characters increases, the processing cost for this sorting increases.

In contrast, the game control method according to the second embodiment calculates the occlusion level for the current frame by referencing the occlusion level from the previous update (previous frame), and calculates the occlusion level for each character over multiple frames. This allows the occlusion levels for each of multiple characters to converge to the correct occlusion level value without rearranging the characters. This makes it possible to reuse the occlusion level from the previous frame and simplify processing, thereby reducing the load on the rendering process and clearly rendering the game video visible to the user, providing the user with high-quality game images.

The game control method according to the second embodiment will be described with reference to Figures 9 to 12. Figure 9 is a flowchart showing the game control method according to the second embodiment. Note that when the step numbers in Figure 9 are the same as those in Figure 6, they indicate the same processing. Figures 10 to 12 are diagrams showing examples of calculation of occlusion levels in the game control method according to the second embodiment.

[Game Control Method]
When the game control method is started, the game machine 3 executes each process of the flowchart shown in Fig. 9. Characters on the screen of a game executed by the game execution processing unit 14 are photographed by the virtual camera 10. Here, an example will be described in which the virtual camera 10 photographs multiple characters. The characters may be non-player characters (NPCs) or player characters (PCs).

First, in step S1, the update control unit 16 sets all characters captured by the virtual camera 10 as unprocessed characters (characters whose occlusion level updates have not yet been processed). Figure 10 shows an example of the initial occlusion levels of unprocessed characters N1 to N10 captured by the virtual camera 10. The occlusion levels of all characters are set to "0."

Next, in step S3, the calculation unit 15 determines whether there are any unprocessed characters whose occlusion levels have not been updated. If it is determined that there are any unprocessed characters, the calculation unit 15 proceeds to step S4. If it is determined that there are no unprocessed characters, the calculation unit 15 proceeds to step S13.

In step S4, the calculation unit 15 selects one of the unprocessed characters. This selection does not have to be based on a specific procedure, and may be random, for example.

Next, in step S7, the calculation unit 15 determines whether there are other characters within a certain distance from the identified character and within 45 degrees to the left or right of the camera direction from the identified character (condition 1).

If it is determined in step S7 that there are no other characters that satisfy condition 1, the calculation unit 15 proceeds to step S9, sets the occlusion level of the identified character to "0", and returns to step S3.

On the other hand, if it is determined in step S7 that there is another character that satisfies condition 1, the calculation unit 15 proceeds to step S12. In step S12, the calculation unit 15 sets the occlusion level of the identified character to a value obtained by adding "1" to the maximum occlusion level of the other characters that satisfy condition 1 in the previous frame, and then returns to step S3.

The processing of steps S1 to S12 described above is repeated until it is determined in step S3 that there are no unprocessed characters whose occlusion levels have not been updated since the previous frame. This completes the occlusion level update process for all characters. This determines the final occlusion level for each character N.

If it is determined in step S3 that there are no unprocessed characters, the process proceeds to step S13, where the update control unit 16 determines the update frequency for each of the multiple characters based on the occlusion level of each of the multiple characters. At this time, as shown for the first time in Figure 11(a), the occlusion level of characters N1 to N5, which satisfy condition 1, becomes "1." The occlusion levels of characters N6 to N10 remain "0."

Next, in step S14, the update control unit 16 saves the occlusion level of the latest frame as the occlusion level of the previous frame. Next, in step S15, the display control unit 18 controls the update for each of the multiple characters based on the update frequency for each of the multiple characters and draws a game image. Next, in step S17, the update control unit 16 determines whether the game is ending. If the update control unit 16 determines in step S17 that the game is ending, it ends this processing. If the update control unit 16 determines in step S17 that the game is not ending, it returns to step S1, sets all characters shown in the virtual camera 10 as unprocessed characters (characters whose occlusion level updates have not been processed), and continues processing.

After returning to step S1, steps 1 to S12 are executed again, and the calculation unit 15 adds another "1" to the occlusion level of the character that satisfies condition 1. If step S3 returns "No," step S13 is executed again. In step S13, the update control unit 16 determines the update frequency for each of the multiple characters based on the occlusion level for each of the multiple characters.

At this time, as shown for the second time in Figure 11(b), the occlusion levels of characters N1 to N4 that satisfy condition 1 are further increased by 1 to become 2. As a result, the occlusion level of character N5 becomes 1, and the occlusion levels of characters N6 to N10 remain at 0.

In the third iteration of steps S1 to S12, the calculation unit 15 adds another "1" to the occlusion level of the characters that satisfy condition 1. If step S3 again returns "No," step S13 is executed again. In step S13, the update control unit 16 determines the update frequency for each of the multiple characters based on the occlusion level of each of the multiple characters. At this time, as shown in the third iteration in FIG. 12(a), an additional "1" is added to the occlusion level of characters N1 and N2 that satisfy condition 1, making it "3." As a result, the occlusion levels of characters N3 and N4 become "2," the occlusion level of character N5 remains "1," and the occlusion levels of characters N6 to N10 remain "0."

In the fourth iteration of steps S1 to S12, the calculation unit 15 adds another "1" to the occlusion level of the characters that satisfy condition 1. At this time, as shown in the fourth iteration in Figure 12(b), an additional "1" is added to the occlusion level of character N1 that satisfies condition 1, making it "4." As a result, the occlusion level of character N2 becomes "3," the occlusion levels of characters N3 and N4 remain "2," the occlusion level of character N5 remains "1," and the occlusion levels of characters N6 to N10 remain "0."

If step S3 again returns "No," step S13 is executed again. In step S13, the update control unit 16 determines the update frequency for each of the multiple characters based on the occlusion level for each of the multiple characters. Next, in step S14, the update control unit 16 saves the occlusion level of the latest frame as the occlusion level of the previous frame. Next, in step S15, the display control unit 18 controls the update for each of the multiple characters based on the update frequency for each of the multiple characters to draw a game image. Then, if it is determined in step S17 that the game is to end, this processing is terminated.

According to the game control method of the second embodiment, the occlusion level is calculated over multiple frames by referencing the occlusion level at the time of update one frame before. This allows the occlusion levels for multiple characters to converge to the correct occlusion level value without rearranging the characters. This reduces the load on the rendering process, while clearly rendering the game video visible to the user and providing the user with high-quality game images.

Third Embodiment
[Game Control Method]
Next, a game control method according to the third embodiment will be described with reference to Fig. 13 and Fig. 14. Fig. 13 is a flowchart showing the game control method according to the third embodiment. Fig. 14 is a diagram for explaining the game control method according to the third embodiment in comparison with a comparative example.

In the game control method according to the first embodiment, as shown in Figure 14(a), each time the occlusion level of each character is calculated, the distance between the target character (character N1 in the example of Figure 14(a)) and the other characters N2 to N10 is calculated, and a determination is made as to whether or not the "within a certain distance" indicated in Condition 1 is met. Thus, to calculate the occlusion levels of all N characters, it is necessary to calculate the distance to other characters N(N-1) times, and the larger N becomes, the greater the processing load becomes.

In the game control method according to the third embodiment, each character uses a collision object to push out other characters so that they do not sink into each other. By saving the collision object contact information and creating a list of other characters that each character has come into contact with, and storing this in the memory unit 12, the number of calculations can be significantly reduced. Furthermore, if a character is within contact distance of a collision object, it is considered to be a nearby character, making it possible to omit the distance calculation.

As shown in Figure 14(b), each character is covered by a collision object D, and the collision object D of each object makes it possible to determine whether each object has collided with another object. In other words, the collision determination unit 17 determines that the characters have collided if the collision objects D of each character are in contact with each other.

In the example of Figure 14(b), the collision determination unit 17 determines that characters N2, N3, and N9 of collision object D that come into contact with collision object D of character N1 are other characters that will collide with character N1. This allows the characters in the vicinity of character N1 to be identified as characters N2, N3, and N9. Therefore, since it is only necessary to determine whether characters N2, N3, and N9 are within region R, processing costs can be significantly reduced and processing can be sped up.

Collision object D is a virtual object and is not displayed on the screen. Therefore, collision object D is invisible to the player. In this embodiment, object C is spherical in shape, but this is not limited to this and various shapes and sizes can be used, such as capsule-shaped, square, spherical, or cylindrical.

If the collision object D is spherical, and the radius of the fan-shaped region R is greater than twice the radius of the collision object D, there will be other characters within the fan-shaped region R that have not come into contact with the collision object D. This makes it impossible to determine which characters are in the vicinity. Therefore, twice the radius of the collision object D must be greater than the radius of the region R within a specified angle in the direction from one object toward the virtual camera 10 and within a specified distance from the one object.

A game control method according to the third embodiment will be described with reference to Figure 13. Note that when step numbers in Figure 13 are the same as those in Figure 6, they indicate the same processing. When this processing starts, first, in step S1, the update control unit 16 sets all characters captured by the virtual camera 10 as unprocessed characters (characters whose occlusion level updates have not been processed). Next, in step S2, the calculation unit 15 creates a list of unprocessed characters captured by the virtual camera 10 for each frame, sorted in order of proximity to the virtual camera 10.

Next, in step S3, the calculation unit 15 determines whether there are any unprocessed characters whose occlusion levels have not been updated. If it is determined that there are any unprocessed characters, the calculation unit 15 proceeds to step S5. If it is determined that there are no unprocessed characters, the calculation unit 15 proceeds to step S13.

In step S5, the calculation unit 15 identifies the unprocessed character that is closest to the virtual camera 10. Next, in step S37, the collision determination unit 17 determines other characters that will collide with the identified character. The collision determination unit 17 determines that a character of a collision object D that comes into contact with the collision object D of the identified character is another character that will collide with the identified character.

Next, in step S39, the calculation unit 15 determines whether any of the other characters with which the collision will occur are within an area within 45 degrees to the left or right of the camera direction. This condition is referred to as "Condition 2." In Figure 14(b), none of the other characters with which the collision will occur are within area R. In other words, none of the other characters with which the collision will occur satisfy Condition 2. Note that within 45 degrees to the left or right of the direction C of the virtual camera 10 is just an example, and any angle can be set.

If it is determined in step S39 that there is no character that satisfies condition 2, the calculation unit 15 proceeds to step S41, sets the occlusion level of the identified character to "0", and returns to step S3. For example, in the case of Figure 14(b), the occlusion level of the identified character N1 is set to "0".

On the other hand, if it is determined in step S39 that there is a character that satisfies condition 2, the calculation unit 15 proceeds to step S43, sets the occlusion level of the identified character to a value obtained by adding "1" to the maximum occlusion level of the other characters determined to collide, and then returns to step S3.

The processing of steps S1 to S5 and S37 to S43 described above is repeated until it is determined in step S3 that there are no unprocessed characters whose occlusion levels have not been updated since the previous frame. This executes the occlusion level update process for all characters, and the final occlusion level for each character is determined.

If it is determined in step S3 that there are no unprocessed characters, the process proceeds to step S13, where the update control unit 16 determines the update frequency for each of the multiple characters based on the occlusion level of each of the multiple characters.

Next, in step S15, the display control unit 18 controls the updates for each of the multiple characters based on the update frequency for each of the multiple characters and draws a game image. Next, in step S17, the update control unit 16 determines whether the game is ending. If the update control unit 16 determines in step S17 that the game is ending, it ends this processing. If the update control unit 16 determines in step S17 that the game is not ending, it returns to step S1, sets all characters shown in the virtual camera 10 as unprocessed characters (characters whose occlusion level updates have not been processed), and continues processing.

According to the game control method of the third embodiment, collision detection between characters is performed using collision object D, and a character determined to be colliding can be determined to be another character in the vicinity of the first character. Then, by calculating the occlusion level of the first character based on whether other characters determined to be in the vicinity satisfy condition 2, occlusion detection for multiple objects can be performed more easily, and the load on the rendering process can be further reduced.

In the game control methods of the first to third embodiments, if there is no change in the occlusion level from the previous frame, processing ends. Thereafter, when the position of the character being photographed by the virtual camera 10 changes, the game control method of any of the first to third embodiments is restarted.

[Modification]
In the game control methods of the first to third embodiments, the update frequency is changed. However, not only the update frequency but also the update content may be changed. For example, when updating a character's motion, the update content can be reduced by eliminating the process of turning the head. In this case, the character moves while the character's neck is fixed. In addition, the update content can be reduced by eliminating the process of putting the character's feet on the ground.

Typically, the process of updating a character's movements involves multiple steps: (1) updating the character's motion, (2) updating the character's position, and (3) correcting the character's motion. For example, the number of updates may be reduced by not performing step (3).

Furthermore, the update frequency may not necessarily be determined using only the occlusion level, but may also be determined based on the occlusion level and the size of the character. For example, the larger the character, the higher the update frequency, and the smaller the character, the lower the update frequency.

The update frequency may be determined based on the occlusion level and the character's importance. For example, the more important the character, the higher the update frequency, and the less important the character, the lower the update frequency.

The update frequency may be determined based on the occlusion level and the character's movement speed or acceleration. For example, the faster the character's movement speed, the higher the update frequency, and the slower the character's movement speed, the lower the update frequency. Conversely, the faster the character's movement speed, the lower the update frequency, and the slower the character's movement speed, the higher the update frequency.

The update frequency may be determined based on the level of obscuration and the character's actions. For example, if the character is performing an attack motion, the update frequency may be increased. For example, if the character is performing an attack, the update frequency may be increased.

The update frequency may be determined using the occlusion level and the distance from the virtual camera 10. For example, the update frequency may be increased the shorter the distance from the virtual camera 10 to the character, and decreased the update frequency the longer the distance from the virtual camera 10 to the character.

The character size, character importance, character movement speed or acceleration, character action, and distance from the virtual camera 10, which determine the update frequency along with the occlusion level, are stored in the storage unit 12 as character information 22. In the above example, the update frequency may be determined using at least one of the occlusion level and character information 22.

The game program, game control method, and information processing device have been described above using the above embodiments, but the game program, game control method, and information processing device according to the present disclosure are not limited to the above embodiments, and various modifications and improvements are possible within the scope of the present embodiments. Furthermore, if there are multiple above embodiments and modifications, they can be combined to the extent that they do not contradict each other.

REFERENCE SIGNS LIST 1 Game system 2 Server device 3 Game machine 11 Control unit 12 Storage unit 13 Communication unit 14 Game execution processing unit 15 Calculation unit 16 Update control unit 17 Collision determination unit 18 Display control unit 21 Obscuration level 22 Character information

Claims (10)

A game program that causes a computer to execute a rendering process of a game image captured by a virtual camera in a virtual space,
(a) when there are a plurality of objects photographed by the virtual camera, a process of treating each of the plurality of objects as a single object and calculating an occlusion level of the single object depending on whether or not there is another object within a predetermined distance from the single object and within a predetermined angle with respect to a direction from the single object toward the virtual camera;
(b) determining an update frequency for each of the plurality of objects based on the occlusion level for each of the plurality of objects;
(c) a process of controlling updating of a drawing process for each of the plurality of objects based on an update frequency for each of the plurality of objects;
A game program that executes a process including the above. (a) calculates the occlusion level of the one object to be higher than the occlusion level of the other object when the other object is within a predetermined angle;
The game program according to claim 1 . (a) sets the occlusion level of the one object to the lowest level when there is no other object within a predetermined angle.
The game program according to claim 1 . (a) calculating an occlusion level of one of the plurality of objects by classifying the object as one object in order from an object closest to the virtual camera;
The game program according to any one of claims 1 to 3. A game program that causes a computer to execute a rendering process of a game image captured by a virtual camera in a virtual space,
(a) if there are a plurality of objects photographed by the virtual camera, a process of acquiring initial occlusion levels of the plurality of objects and calculating occlusion levels of the next frame using the initial occlusion levels;
(b) calculating an occlusion level for the next frame using the calculated occlusion level for the next frame as the occlusion level for the previous frame;
(c) determining an update frequency for each of the plurality of objects based on the occlusion level for each of the plurality of objects;
(d) a process of controlling updating of a drawing process for each of the plurality of objects based on an update frequency for each of the plurality of objects;
Including,
(a) considers each of the plurality of objects as one object, and when there is another object that is within a predetermined distance from the one object and is within a predetermined angle with respect to a direction from the one object toward the virtual camera, increases the occlusion level of the one object in the next frame above the occlusion level of the initial state;
(b) is a game program that executes a process in which, when each of the plurality of objects is considered to be a single object and there is another object within a predetermined distance from the single object and within a predetermined angle with respect to the direction from the single object toward the virtual camera, the occlusion level of the single object in the next frame is calculated to be higher than the occlusion level of the other object in the previous frame. (b) calculating the occlusion levels of the plurality of objects until the occlusion levels of the plurality of objects in the next frame do not change from the occlusion levels of the plurality of objects in the previous frame;
The game program according to claim 5 . Each of the plurality of objects is covered by a collision object, and collisions of the plurality of objects can be determined;
(a) defines each of the plurality of objects as a single object, identifies other objects determined to collide with the single object, and calculates an occlusion level of the single object according to whether or not any of the identified other objects is within a predetermined angle with respect to a direction from the single object toward the virtual camera;
The game program according to any one of claims 1 to 3. the collision object is spherical;
twice the radius of the collision object is greater than the radius of a region within a predetermined angle with respect to a direction from the one object toward the virtual camera and within a predetermined distance from the one object;
The game program according to claim 7. A game control method for causing a computer to execute a rendering process of a game image captured by a virtual camera in a virtual space, comprising:
(a) when there are a plurality of objects photographed by the virtual camera, a process of treating each of the plurality of objects as a single object and calculating an occlusion level of the single object depending on whether or not there is another object within a predetermined distance from the single object and within a predetermined angle with respect to a direction from the single object toward the virtual camera;
(b) determining an update frequency for each of the plurality of objects based on the occlusion level for each of the plurality of objects;
(c) a process of controlling updating of a drawing process for each of the plurality of objects based on an update frequency for each of the plurality of objects;
A game control method in which processing is performed by a computer. An information processing device that performs a rendering process of a game image captured by a virtual camera in a virtual space,
a calculation unit that, when there are a plurality of objects photographed by the virtual camera, regards each of the plurality of objects as a single object and calculates an occlusion level of the single object depending on whether or not there is another object within a predetermined distance from the single object and within a predetermined angle with respect to a direction from the single object toward the virtual camera;
an update control unit that determines an update frequency for each of the plurality of objects based on the occlusion level for each of the plurality of objects, and controls updating of a drawing process for each of the plurality of objects based on the update frequency for each of the plurality of objects;
An information processing device having the above.