JP7672888B2 - Game program, information processing device, and camera control method - Google Patents

Description

The present invention relates to a game program, an information processing device, and a camera control method.

There is known a game program that converts objects such as player characters and enemy characters moving in a virtual space (for example, a virtual three-dimensional space) into an image with a virtual virtual camera as the viewpoint, and displays the image on a display or the like. One method of controlling the virtual camera is to move the virtual camera to follow the player character while aligning the virtual camera's gaze point with the player character. This allows the game program to always display the player character in approximately the center of the image.

When the player character moves close to an obstacle such as a wall, or when the player operates the virtual camera to move close to an obstacle such as a wall, the virtual camera may come closer to the obstacle than the player character. In such cases, a technique is known for moving the virtual camera up so that it does not collide with the obstacle (see, for example, Patent Document 1). Patent Document 1 discloses a technique for moving the virtual camera up and changing the virtual camera's point of view when the player character moves close to an obstacle such as a wall.

JP 2009-087277 A

Although various methods have been devised to capture images properly near obstacles, such as the technology mentioned above, there is still room for improvement.

In view of the above problems, the present invention aims to provide a game program that enables a virtual camera to capture appropriate images near obstacles.

In consideration of the above problems, the present invention provides a program that causes an information processing device to function as a virtual camera in a virtual space, a contact determination unit that determines contact with an object in the virtual space that is a target for contact determination, a camera control unit that causes the virtual camera to follow the movement of an object to be followed among the objects, and an image data generation unit that generates image data captured by the virtual camera, and the camera control unit performs avoidance processing such that, when contact is made with the object subject to contact determination that has a height equal to or less than a threshold, the virtual camera does not move to follow the object, but increases the height of the virtual camera, and when contact is made with the object subject to contact determination that has a height exceeding the threshold, the virtual camera does not move to follow the object, and decreases the height of the virtual camera .

It is possible to provide a game program that enables the virtual camera to capture appropriate images near obstacles.

FIG. 1 is a diagram illustrating an example of the configuration of a game system. FIG. 2 is a diagram illustrating an example of a hardware configuration of an information processing device. FIG. 2 is an example of a functional block diagram illustrating functions of an information processing device divided into blocks. FIG. 1 is a diagram illustrating an example of camera setting information (first embodiment); 1 is a diagram illustrating an example of a posture of a virtual camera; 11A and 11B are diagrams illustrating operations of the attitude of the virtual camera by a player. 11A to 11C are diagrams illustrating a method for controlling the attitude of a virtual camera near a wall whose height is equal to or less than a threshold (Example 1). 11A and 11B are diagrams illustrating inconveniences that may occur when a player operates the attitude of a virtual camera using a camera control stick. 11 is a diagram illustrating the limit distance between the virtual camera and the player character. FIG. 11A and 11B are diagrams illustrating inconveniences that may occur during lock-on. 11 is a flowchart illustrating an example of a procedure in which a camera control unit controls the attitude of a virtual camera. FIG. 11 is a diagram illustrating an example of camera setting information (Example 2). 13A to 13C are diagrams illustrating a method for controlling the attitude of a virtual camera near a wall whose height exceeds a threshold (Example 2). 13A to 13C are diagrams illustrating a method for controlling the attitude of a virtual camera when the virtual camera locks onto an enemy character near a wall. 11 is a flowchart illustrating an example of a procedure in which a camera control unit controls the attitude of a virtual camera. FIG. 13 is an explanatory diagram of an example of a method for controlling the attitude of the virtual camera when the player operates the camera control stick when the camera is close to a wall. FIG. 13 is an example of a flowchart illustrating a method for controlling the attitude of the virtual camera when the player operates the attitude of the virtual camera when the virtual camera is close to a wall.

Below, a description will be given of an embodiment of the game program disclosed herein with reference to the drawings. Note that in this specification and the drawings, substantially identical configurations will be denoted by the same reference numerals to avoid redundant description.

In this embodiment, a method for controlling the attitude of a virtual camera near an obstacle (camera control method) that can move the virtual camera onto the obstacle will be described. Note that in this embodiment, a wall will be used as an example of an obstacle.

<Game System>
First, an example of the configuration of a game system will be described with reference to Fig. 1. Fig. 1 is a diagram showing the configuration of a game system 1 according to this embodiment. The game system 1 includes an information processing device 3, a game controller 5, and a display device 7. Each of the game controller 5 and the display device 7 is connected to the information processing device 3 so as to be able to communicate with each other via wire or wirelessly.

The information processing device 3 is, for example, a stationary game console. However, this is not limited to this, and the information processing device 3 may be, for example, a portable game console that is equipped with an input unit, a display unit, etc.

In addition, the information processing device 3 does not have to be a dedicated game machine, and may be, for example, a computer, desktop computer, notebook computer, tablet computer, etc. that is manufactured and sold as a computer, or a smartphone, mobile phone, phablet, etc. that is manufactured and sold as a telephone. These devices are usually used as general-purpose information processing terminals, 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 in the information processing device 3. The game program is distributed in a state stored on an optical storage medium such as a CD-ROM or a semiconductor memory such as a USB memory, or is distributed by being downloaded from a server.

The player uses the game controller 5 to perform various operation inputs. In the example shown in FIG. 1, the game controller 5 has, for example, a cross key 9, a plurality of buttons 8, and a camera operation stick 6. 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 voice operation. The game controller 5 may also have a gyro sensor, an acceleration sensor, etc., allowing operation by the player changing the attitude of the game controller 5.

In addition, the information processing device 3 may further communicate with a server on the network. In this case, multiple information processing devices 3 executing the same game program connect to the server, making so-called online games possible. An online game is, for example, a game in which multiple players can operate the same game program in a cooperative manner. The server of an online game performs the minimum processing of accepting the positions and operation commands of other players and transmitting them to the information processing devices 3 of the other players. The information processing device 3 performs the actual game processing, such as drawing each player and reflecting the operation commands.

The game system 1 may also be of the so-called P2P (Peer To Peer) type, in which an information processing device 3 communicates with another information processing device 3.

The game system 1 may also be a so-called cloud game. Below, the game system 1 of this embodiment will be described mainly using the configuration of FIG. 1.

<Example of hardware configuration of information processing device>
Fig. 2 is an example of a hardware configuration diagram of the information processing device 3. As shown in Fig. 2, the information processing device 3 includes, for example, a CPU 501, a ROM 502, a RAM 503, a GPU 504, a dedicated integrated circuit 505 constructed for a specific purpose such as an ASIC or an FPGA, an input device 506, an output device 507, a recording device 508, a drive 509, a connection port 510, and a communication device 511. These components are connected to each other via a bus 513, an input/output interface 514, etc. so as to be able to transmit signals to each other.

The game program can be recorded, for example, in ROM 502, RAM 503, recording device 508, etc.

The CPU 501 may, for example, directly read and execute the game program from the recording device 508, or may first load the game program into the RAM 503 and then execute it. Furthermore, when the CPU 501 receives the game program via the communication device 511, the drive 509, or the connection port 510, for example, the CPU 501 may directly execute the received game program without recording it in the recording device 508.

The CPU 501 may also perform various processes based on signals and information input from an input device 506, such as a mouse, keyboard, microphone, etc. (not shown), including the aforementioned game controller 5, as necessary.

The GPU 504 performs image display processing, such as rendering processing, in response to instructions from the CPU 501.

The CPU 501 and GPU 504 then output the results of the above processing from an output device 507, which may include, for example, the display device 7 and audio output unit described above. If necessary, the CPU 501 and GPU 504 may transmit the results of this processing via a communication device 511 or a connection port 510, or may record the results in the recording device 508 or recording medium 512.

The hardware configuration of the server or general-purpose information processing device may be the same as that of the information processing device 3, or may be different, but for the sake of convenience in explaining this embodiment, it will not cause any problems.

<About the function>
Fig. 3 is an example of a functional block diagram for explaining functions of the information processing device 3 in blocks. As shown in Fig. 3, the information processing device 3 has an object control unit 31, an image data generation unit 32, a display control unit 33, a contact determination unit 34, a camera control unit 35, and an operation reception unit 36. Each of these functional units of the information processing device 3 is a function or means realized by the CPU 501 shown in Fig. 2 executing a game program expanded in the RAM 503.

First, in this embodiment, an image of an object is obtained by a virtual camera placed in a virtual space (for example, a virtual three-dimensional space). The object is also a three-dimensional solid object. In computer graphics, a three-dimensional object is composed of polygons (or a collection of three-dimensional points). A polygon is polygonal data formed by connecting three or more vertices, and is the smallest unit that composes a curved surface. The object data storage unit 38 stores information about the objects, such as the polygons that form each object, the attributes of each object, and position information.

The object control unit 31 controls the positions and behavior of characters other than the player character (an example of a target object; hereafter referred to as the PC). For example, the position is updated every frame according to the character's nature (enemy, ally, role, etc.) within a range determined for each character. Furthermore, the character's position is determined so that the character moves on a mesh called a navigation mesh according to the character's nature. Furthermore, behavior, which may be, for example, attacking, talking, or simply moving, is also determined by the object control unit 31 according to the character's nature.

The contact determination unit 34 detects contact between objects. The objects between which contact is determined include a PC and another character, a PC and a feature fixed to the ground (walls, rocks, buildings, plants, etc.), movable objects (furniture, home appliances, doors, etc.), a flying object such as a bullet or magic and a PC (or an enemy character), a virtual camera and a feature or a movable object, and so on. Objects within a specified range of the PC (characters that are far enough away that they do not affect the PC4 are stopped in the first place) may be subjected to contact determination with other objects. In this embodiment, contact determination between the virtual camera and a feature will mainly be explained. Hereinafter, a feature will be simply referred to as an "obstacle".

The result of the contact determination by the contact determination unit 34 is notified to the object control unit 31. The object control unit 31 controls the object depending on which object has come into contact with which object. For example, when the virtual camera comes into contact with an obstacle object, the virtual camera is pushed in the opposite direction to the object by the amount of contact with the object. Instead of "pushing", the virtual camera may be "stopped on the surface" of the object.

The camera control unit 35 controls the attitude of the virtual camera based on the camera setting information stored in the camera setting information storage unit 39. Details are described in FIG. 4.

The operation reception unit 36 receives operations from the player using the game controller 5. The operation reception unit 36 can receive any operation that is possible within the game program, but in this embodiment it mainly receives operations related to the movement of the PC and the attitude of the virtual camera.

The image data generation unit 32 converts objects in the game space viewed from the virtual camera into image data. The display control unit 33 displays the image data generated by the image data generation unit 32 on the display device 7.

Figure 4 is an example diagram explaining the camera setting information. The camera setting information defines how the camera control unit 35 controls the camera attitude according to the "situation" and "manual camera operation."

- "Situation" is the specific situation that controls the attitude of the virtual camera. In Figure 4, the situation is specified in which the virtual camera has come into contact with a slope.

- "Manual camera operation" indicates whether the camera control stick 6 has been operated. If the camera control stick 6 has been operated, the player's manual operation takes priority as a general rule. As an exception, in situations where it is necessary to show the player the entire view, automatic camera control takes priority over the player's manual operation.

- "Lock-on" indicates whether the player has locked on or not. Lock-on refers to a state in which the camera's position is automatically adjusted so that both the PC and enemy character are in the field of view. Lock-on is initiated by pressing the camera control stick 6, but it can also be initiated automatically.

- "Virtual camera attitude" defines how the attitude of the virtual camera is controlled in the situation. In the camera setting information (first line) of FIG. 4, when the virtual camera 10 comes into contact with the slope 13 as the "situation", the virtual camera 10 is moved in the X- and Y-axis coordinate directions along an arc trajectory in response to the operation, and a limit distance L is set for the distance between the virtual camera 10 and the PC.

In this embodiment, the virtual camera 10 has two types of height movement.
(i) Movement processing in the X and Y axis coordinate directions along a circular arc trajectory (see FIG. 5 for the X, Y, and Z directions). This movement processing is used when the player operates the camera control stick 6 to change the pitching.
(ii) Simple up/down movement in the Y-axis direction, which is expressed as "height" in this embodiment.

Also, when locked on (line 3), the height of the virtual camera (movement along the Y axis) is adjusted according to the height of the PC, and the pitching angle is adjusted according to the height of the enemy character.

- "Adjustment speed" is the number of frames the camera control unit 35 takes to control the attitude of the virtual camera 10. For example, the N frames in the third line of FIG. 4 is the typical number of frames the camera control unit 35 takes to go from a non-locked-on state to a locked-on state. N frames is, for example, several frames to several tens of frames.

<Virtual camera posture>
5 is a diagram for explaining the attitude of the virtual camera 10. The attitude of the virtual camera 10 is determined by, for example, the position, the gaze point, and the upward direction of the camera. The position is represented by X, Y, and Z coordinates in the virtual space. The gaze point 41 is a point where the optical axis 42 of the virtual camera 10 contacts an object (PC4 in FIG. 5). The presence of an object contacting the optical axis 42 is not essential, and any point on the optical axis 42 can be the gaze point. The upward direction of the camera is an axis perpendicular to the bottom and top surfaces when the virtual camera 10 is considered as a rectangular parallelepiped, and is a direction from the bottom surface to the top surface.

The virtual camera 10 can rotate around three axes perpendicular to the virtual camera 10 in a neutral state. The angles corresponding to each axis are called the yaw angle β, the roll angle α, and the pitching angle γ. In this embodiment, the control of the gaze point 41 is described, but at this time, the pitching angle also changes. Therefore, controlling the gaze point 41 may change the pitching angle, and controlling the pitching angle may change the gaze point 41.

When PC4 is simply moving, the camera control unit 35 controls the virtual camera 10 so that a point on PC4 at a fixed height A [m] a fixed distance behind PC4 becomes the gaze point 41 (tracking movement). In contrast, under predetermined conditions, such as near a wall with a slope, the camera control unit 35 controls the attitude of the virtual camera 10 based on the camera setting information stored in the camera setting information storage unit 39.

The camera control unit 35 also controls the attitude of the virtual camera 10 in response to the operation of the camera control stick 6 arranged on the game controller 5.

Figure 6 is a diagram explaining the operation of the attitude of the virtual camera 10 by the player. Figure 6(a) is a top view of the PC4. In response to the player's operation, the virtual camera 10 rotates 360° horizontally around the PC4. Even with the rotation, the focus point is maintained on the PC4, so the angle of view of the virtual camera 10 always includes the PC4.

Figure 6(b) is a side view of PC4. Since the virtual camera 10 is placed in the virtual space, it rotates a fixed angle vertically around PC4 in response to the player's operation. The fixed angle may be from the ground toward the zenith of PC4 (or just before that). In the embodiment, when the attitude of the virtual camera 10 is manipulated, the gaze point of the virtual camera 10 is controlled to the center of the arc (PC4).

However, being able to move the virtual camera 10 in virtual space in this way may result in the virtual camera 10 coming into contact with surrounding objects.

<How to control the orientation of a virtual camera near a wall>
In the following state, the virtual camera 10 sets the gaze point at, for example, the waist of the PC4 from a height A [m] a certain distance behind the PC4. When the player moves the PC4 in the game space, the virtual camera 10 also moves in response to the movement of the PC4. This manner of movement of the virtual camera 10 is called following movement. The distance and height A [m] between the virtual camera 10 and the PC are determined so that the angle of view of the virtual camera 10 preferably includes the entire PC4, and further has a margin that allows the player to confirm the situation around the PC4.

In addition, if the angle of view is increased, the PC 4 and the surrounding situation can always be included in the angle of view regardless of the relative positions of the virtual camera 10 and the PC 4. However, if the angle of view is large, the number of objects included in the angle of view also increases. This increases the processing load of image generation (perspective projection transformation), causing a decrease in fps (flames per second).

Figure 7 is a diagram explaining a method for controlling the attitude of the virtual camera 10 near a wall whose height is equal to or less than a threshold. A wall 12 whose height H [m] is equal to or less than the threshold becomes an obstacle that allows the virtual camera 10 to move up the wall 12. In this embodiment, a slope is provided on the wall 12 whose height is equal to or less than the threshold. Note that, for example, a slope may not be required for an obstacle that is lower than the height A [m] of the virtual camera 10 in the following state (where there is no risk of contact with the virtual camera 10).

The threshold value is preferably set to a height that allows PC4 to be within the viewing angle when virtual camera 10 looks down at PC4 at the foot of the slope from above wall 12 at an appropriate pitching angle. If there is room to move virtual camera 10 above wall 12, camera control unit 35 can move virtual camera 10 above wall 12 even if virtual camera 10 touches wall 12.

However, if the camera control unit 35 increases the height of the virtual camera 10 in a short time next to a wall, the image viewed by the player changes suddenly, which may cause motion sickness and reduce interest. Therefore, in this embodiment, the object control unit 31 places a slope 13 for the camera (this is not visualized but is transparent) from the top end of the wall 12, and the camera control unit 35 moves the virtual camera 10 along the surface of the slope 13. This allows the camera height to be gradually increased, and the image changes smoothly, making it less likely that motion sickness will occur. The virtual camera 10 cannot move inside this slope 13, but the PC4 can move inside the slope 13. In other words, a collision is determined between the virtual camera 10 and the slope 13, but a collision is not determined between the PC4 and the slope 13.

Figure 7(a) shows a state in which the virtual camera 10 comes into contact with the slope 13 as the PC 4 approaches the wall 12. The slope 13 and virtual camera 10 come into contact when, for example, the player makes the PC 4 step back with its back to the wall 12, the player is forced to move due to an attack from an enemy, or the virtual camera 10 rotates horizontally by operating the camera control stick 6 and comes into contact with the slope 13.

When the contact determination unit 34 determines that the virtual camera 10 has come into contact with the slope 13, the camera control unit 35 cannot move the virtual camera 10 to the inside of the slope 13, and so moves the virtual camera 10 along the surface of the slope 13. Note that when moving along the surface of the slope 13, the gaze point of the virtual camera 10 is always adjusted to PC4.

Figure 7(b) shows a state in which PC4 is closer to wall 12 than in Figure 7(a), and virtual camera 10 has moved from a low position on slope 13 to a higher position. As PC4 has moved closer to wall 12, virtual camera 10 has also moved closer to wall 12. However, since virtual camera 10 cannot enter the inside of slope 13, the horizontal distance between PC4 and virtual camera 10 is the same as in Figure 7(a), but the height of virtual camera 10 has increased.

Figure 7(c) shows the virtual camera 10 when PC4 has reached the bottom of the slope 13. The virtual camera 10 moves along the surface of the slope 13 and reaches a height above the wall 12.

Controlling the attitude of the virtual camera 10 using the slope in Figure 7 is an example of obstacle avoidance processing.

In FIG. 7, the angle D of the slope 13 is determined by the height H [m] of the wall 12 and the horizontal distance between the virtual camera 10 and the PC 4 (a fixed distance behind the PC). This is just one example, and the angle of the slope 13 may be constant regardless of the height H [m] of the wall 12, or the angle D may be changed while keeping the length K [m] of the base of the slope constant even if the height H [m] of the wall 12 differs.

<When the player manipulates the virtual camera's position>
Next, a case where the player operates the attitude of the virtual camera 10 will be described. As described in FIG. 6, the player can rotate the virtual camera 10 vertically in the virtual space by operating the camera operation stick 6. However, the virtual camera 10 cannot move inside the wall 12 and the slope 13. Therefore, even if the player operates to move the virtual camera 10 in the X-axis and Y-axis coordinate directions along the arc trajectory in the state of FIG. 7(a) to (c), the virtual camera 10 moves on the slope 13. However, when the camera operation stick 6 is operated, the virtual camera 10 has the center of the arc as its gaze point, so that the further the virtual camera 10 is operated downward, the more the virtual camera 10 looks up, and the PC 4 is no longer included in the angle of view.

Figure 8 is a diagram explaining the inconvenience that occurs when the player manipulates the attitude of the virtual camera 10 with the camera control stick 6. The virtual camera 10 on the wall 12 in Figure 8 would normally move on the dotted trajectory 43 by manipulating the camera control stick 6. However, since the virtual camera 10 is pushed toward the PC by the slope 13, it exists on the slope 13 with the center of the trajectory 43 (arc) as the gaze point (virtual cameras 10a, 10b). As can be seen from the pitching angle of virtual camera 10b, the more the virtual camera 10 moves (mainly downward) along the arc trajectory in the X and Y coordinate directions, the more the virtual camera 10 is angled upward, making it difficult for the PC 4 to be included in the field of view.

In this embodiment, as shown in FIG. 9, even if the player performs an operation to move the virtual camera 10 along an arc trajectory in the X- and Y-axis coordinate directions, the camera control unit 35 does not allow the virtual camera 10 to approach closer than the limit distance L from the PC 4. The limit distance L is set in the camera setting information.

Figure 9 is a diagram explaining the limit distance L between the virtual camera 10 and the PC 4. By setting the limit distance L, the player can only operate the camera within the range where the PC 4 is within the field of view, preventing the PC 4 from going outside the field of view.

In FIG. 9, a limit distance L is set between the virtual camera 10 and the PC 4, but a lower limit C may be set for the height of the virtual camera 10. In this case, the same effect can be obtained.

<Controlling the virtual camera attitude when locked on>
Next, a method for controlling the attitude of the virtual camera 10 when the slope 13 is used to control the attitude of the virtual camera 10 at a wall where there is room for the virtual camera 10 to move upward and an enemy character 15 is locked on will be described. Details of the process at the time of locking on will be described with reference to Figs. 13 and 14.

Figure 10 is a diagram explaining inconveniences during lock-on. The player locks on to an enemy character. For example, let us assume that the player locks on to an enemy character when enemy character 15 is present to the right (not shown) of PC4 in the situation shown in Figure 7(c). The virtual camera adjusts the pitching angle γ to include the enemy character in the field of view at the current position. In this case, the pitching angle γ will naturally be at a different angle (upward) than when it was adjusted to capture PC4 from the top of slope 13 (above the wall), making it difficult to capture PC4. In situations such as those shown in Figures 7(a) to (c), PC4 may still be included in the field of view even if the pitching angle γ is adjusted to a slightly upward angle, but if PC4 is inside slope 13 as shown in Figure 10, it will definitely be out of the field of view.

Therefore, when locking on, the object control unit 31 deletes the slope 13. After deleting the slope 13, the camera control unit 35 regards a wall that is below the threshold as a wall that exceeds the threshold, and performs the same processing as in Example 2.

<Operation procedure>
Fig. 11 is an example of a flowchart showing a procedure in which the camera control unit 35 controls the attitude of the virtual camera 10. The process in Fig. 11 is executed, for example, for each frame.

The contact determination unit 34 determines whether or not the virtual camera 10 and the slope 13 have come into contact (S1). This determination (one example of a predetermined condition) may be made only when the PC 4 is within a predetermined distance from an obstacle. Because the slope 13 is transparent, it is always placed except during lock-on, but the slope may be placed only when the PC is within a predetermined distance from an obstacle. For example, the contact determination unit 34 projects a perpendicular line (raycast) from the center of the virtual camera 10 to the slope 13 (surface), and determines whether or not contact has occurred depending on whether the distance from the virtual camera 10 to the intersection point is within a threshold.

If the determination in step S1 is Yes, the camera control unit 35 restricts the movement of the virtual camera 10 inward from the slope 13 (S2). In other words, the camera control unit 35 permits the virtual camera 10 to approach the wall, but prohibits the virtual camera 10 from moving inward from the slope.

Then, the camera control unit 35 determines whether or not the camera has been locked on (S3).

If the determination in step S3 is No, the camera control unit 35 determines whether the operation reception unit 36 has received a manual operation of the camera (S4).

If the determination in step S4 is Yes, the camera control unit 35 moves the virtual camera 10 along an arc trajectory in the X- and Y-axis coordinate directions in response to the player's operation, but restricts the distance between the virtual camera 10 and the PC 4 so that it does not fall within the limit distance L (S5).

If the determination in step S3 is Yes, the object control unit 31 deletes the slope 13 that has come into contact with the virtual camera 10 (S6). That is, the object control unit 31 prevents the slope 13 from existing in the virtual space. Alternatively, the contact determination unit 34 may not perform contact determination between the virtual camera 10 and the slope 13.

Then, the camera control unit 35 processes the wall as exceeding the threshold even if the wall is below the threshold (S7). In other words, the process thereafter proceeds to the flow of Example 2.

<Major Effects>
According to this embodiment, the virtual camera 10 moves along the surface of the slope 13 near an obstacle where there is room to move the virtual camera 10 over the obstacle, so that sudden changes in the image seen by the player are suppressed, improving interest, etc. Also, when the player operates the height of the virtual camera 10, the virtual camera 10 is prevented from approaching the PC 4, so that the PC 4 comes into the angle of view. Also, when locked on, the slope 13 is deleted and the height of the virtual camera 10 is lowered, so that the PC 4 and the enemy character 15 come into the angle of view.

In this embodiment, we explain how to control the attitude of the virtual camera 10 near an obstacle where there is no room to move the virtual camera 10 above the wall 12.

In this embodiment, the hardware configuration diagram in FIG. 2 and the functional block diagram in FIG. 3 described in the above embodiment can be used.

Figure 12 is an example of camera setting information in this embodiment. Figure 12 mainly explains the differences from Figure 4. In this embodiment, there is no slope around the wall, and control is defined for when the virtual camera 10 comes into contact with a wall object.

In FIG. 12, in this situation, if there is no manual operation of the camera, height B [m] is set as the "virtual camera height." In addition, 30 frames is set as the "adjustment speed." This is because if the camera control unit 35 momentarily changes the height of the virtual camera (simple up and down movement), the screen may suddenly change, causing the player to feel uncomfortable. 30 frames is just an example, and several tens of frames may be used, for example. Also, different values may be adopted depending on the fps.

When locked on in a similar situation, the height of the virtual camera 10 (movement in the Y-axis direction) is adjusted according to the height of the PC, and the pitching angle is adjusted according to the height of the enemy character. This "adjusting the height of the virtual camera according to the height of the PC" is the same as adjusting the virtual camera to a height of B [m].

When the camera is manually operated in a similar situation, the virtual camera 10 is moved in the X and Y coordinate directions along an arc trajectory by the player. The gaze point is determined from the height of the virtual camera 10, the distance from the wall, the distance to the enemy, and the height of the enemy.

<Controlling the virtual camera's pose near an obstacle with no room to move the virtual camera over the wall>
13A and 13B are diagrams for explaining a method for controlling the attitude of the virtual camera 10 near a wall whose height exceeds a threshold in this embodiment. Fig. 13A shows a state in which the virtual camera 10 has entered inside the wall 11. It is determined that the virtual camera 10 has come into contact with the wall 11, and the camera control unit 35 pushes the virtual camera 10 toward the PC 4.

Figure 13(b) shows the virtual camera 10 in an extruded state. By extruding the virtual camera 10, the virtual camera 10 is present on the surface of the wall 11 facing the PC 4. The reason why the state shown in Figure 13(b) occurs has been explained in Figure 7(a).

Regardless of the presence of wall 11, when virtual camera 10 maintains a constant distance from PC4, virtual camera 10 enters inside wall 11. When virtual camera 10 enters inside wall 11, wall 11 enters the angle of view of virtual camera 10, and PC4 is no longer reflected in the image data generated by image data generation unit 32. Therefore, in this embodiment, contact determination unit 34 determines whether virtual camera 10 has come into contact with wall 11, and if contact occurs, camera control unit 35 restricts movement of virtual camera 10 toward the wall. Therefore, even if PC4 approaches wall 11, virtual camera 10 is pushed out without entering the wall.

However, when the virtual camera 10 is pushed away from the wall 11 and the PC4 moves toward the wall 11, the distance between the PC4 and the virtual camera 10 becomes shorter, and the PC4 is no longer included in the angle of view.

Therefore, the camera control unit 35 refers to the camera setting information and lowers the height of the virtual camera 10. That is, the camera control unit 35 controls the height of the virtual camera 10 from A [m] to B [m] as a simple up-down movement over, for example, 30 frames (A (an example of the first height)>B (an example of the second height)). FIG. 13(c) shows the virtual camera 10 with a lowered height. The height of the virtual camera 10 in FIG. 13(c) is B [m]. B [m] is adjusted, for example, based on the height of the PC 4, so that the PC 4 is within the angle of view of the virtual camera. In addition, after preparing a virtual camera at an ideal position that can enter the inside of a wall, a raycast may be cast from the PC 4 to the virtual camera, and the height of the virtual camera may be lowered in proportion to the distance from the PC 4 to the virtual camera and the distance from the PC 4 to the position where the raycast hits the wall. In addition, the gaze point of the virtual camera 10 may be the waist of the PC 4. Controlling the height of the virtual camera 10 from A [m] to B [m] is an example of obstacle avoidance processing.

As a result, even if PC4 approaches a wall, the camera control unit 35 can control the attitude of the virtual camera 10 so that PC4 is within the field of view.

<How to control the virtual camera's attitude when locked on to the wall>
Next, referring to FIG. 14, a method for controlling the attitude of the virtual camera 10 when the virtual camera 10 is locked on will be described. FIG. 14 is a diagram for explaining a method for controlling the attitude of the virtual camera when the virtual camera 10 locks on to an enemy character at the wall. Since the gaze point of the virtual camera 10 (shown by a dotted line) in FIG. 13(c) before locking on is PC4, there is a risk that the locked-on enemy character will not be included in the angle of view. For this reason, when locking on, the camera control unit 35 refers to the camera setting information and controls the attitude of the virtual camera 10 to be suitable for locking on. That is, the camera control unit 35 adjusts the pitching angle based on the height of the enemy character so that the enemy character is included in the angle of view. In this way, both PC4 and the locked-on enemy character 15 are included in the angle of view of the virtual camera 10.

<Operation procedure>
Fig. 15 is an example of a flowchart showing a procedure in which the camera control unit 35 controls the attitude of the virtual camera 10. The process in Fig. 15 is executed, for example, for each frame.

The object control unit 31 determines whether PC4 is within the threshold from wall 11 (S11). For example, if PC4 is present in a mesh at the wall edge of the navigation mesh, the object control unit 31 determines that PC4 is within the threshold from wall 11.

If the determination in step S11 is Yes, the contact determination unit 34 determines whether or not the virtual camera 10 has come into contact with the wall 11 (S12). For example, the contact determination unit 34 projects a perpendicular line (raycast) from the center of the virtual camera 10 to the wall 11, and determines whether or not the virtual camera 10 has come into contact with the wall 11 based on whether or not the distance from the virtual camera 10 to the intersection point is within a threshold. Note that the contact determination unit 34 may perform only step S12 without performing the determination in step S11 (S11 or S12 is an example of a predetermined condition).

If the determination in step S12 is Yes, the object control unit 31 determines whether or not the height of the wall 11 exceeds the threshold (S13). In other words, it determines whether or not there is room to move the virtual camera 10 above the wall 11. This determination may be made, for example, based on the height of the attribute of the object that the virtual camera 10 has come into contact with, or based on the presence or absence of a slope.

If the determination in step S13 is Yes, the camera control unit 35 restricts the movement of the virtual camera 10 toward the wall (S14). In other words, even if the virtual camera 10 comes into contact with the wall, the camera control unit 35 prohibits the virtual camera 10 from moving toward the inside of the wall (pushing it out by the amount of contact).

The camera control unit 35 changes the height of the virtual camera 10 from A [m] to B [m] by simple up and down movement, for example, over 30 frames (S15).

Then, the camera control unit 35 determines whether or not a lock-on has been established (S16). If the determination in step S16 is Yes, the camera control unit 35 adjusts the pitching angle so that the enemy character 15 and PC4 are within the field of view at the height B [m] determined in step S15 (S17).

<When the player manipulates the virtual camera's position>
6, when the player operates the camera control stick 6 when not next to a wall, the virtual camera 10 moves along a vertical arc. The gaze point is set to the center direction of the arc (PC4).

However, if the player performs a similar operation near a wall, the trajectory of the virtual camera 10 will come into contact with the wall 11. In this case, the camera control unit 35 will only push out the camera when the trajectory comes into contact with the wall 11 (the camera is stuck in the wall), and will not be able to move the camera along an arc. Therefore, the camera control unit 35 distorts the trajectory near the wall and controls the attitude of the virtual camera 10 so that the virtual camera 10 is more likely to pitch upward (so that the enemy character enters the field of view sooner). The camera control unit 35 determines the point of gaze from the height of the virtual camera 10, the distance of the virtual camera 10 from the wall 11, the distance from the enemy character 15, and the height of the enemy character 15. Simply put, the center of gravity of the enemy character 15 and the PC4 may be set as the point of gaze.

Figure 16 is an explanatory diagram of an example of a method for controlling the attitude of the virtual camera 10 when the player operates the camera control stick 6 when the camera is close to a wall.

First, the camera control unit 35 determines the maximum height Hmax of the virtual camera 10. The maximum height Hmax is the greater of the heights of the PC 4 and the enemy character 15 + m (margin).

The player operates the camera control stick 6 to determine the position of the virtual camera 10 on the arc trajectory within the range of this maximum height Hmax. As shown in FIG. 16, if the distance between the PC 4 and enemy character 15 and the wall 11 is relatively large, the virtual camera 10 will not be able to include the PC 4 and enemy character 15 in its angle of view unless the height of the virtual camera 10 is low. Therefore, the player operates the virtual camera 10 to move it in the X and Y coordinate directions (mainly downward) along the arc trajectory. On the premise that the player operates in this way, the camera control unit 35 changes the trajectory so that when the virtual camera 10 is lower than the center P in the height direction of the maximum height Hmax, the distance of the virtual camera 10 from the wall 11 is longer than when the virtual camera 10 is above the center P.

The distance M of the virtual camera 10 from the wall 11 when the virtual camera 10 is at its lowest is a predetermined fixed value, for example, 50% to 100% of the maximum height Hmax. The distance N of the virtual camera 10 from the wall 11 when the virtual camera 10 is at its highest is, for example, about half the distance M. The distance of the virtual camera 10 from the wall 11 increases downward from the center P, with the maximum being M. The distance of the virtual camera 10 from the wall 11 increases upward from the center P, with the maximum being N. The center P may be shifted up or down, or may be set to, for example, 3/4 of the maximum height Hmax.

The camera control unit 35 also controls the center of gravity 21 of the PC 4 and enemy character 15 to be the gaze point. The center of gravity is a position in virtual space calculated by averaging the coordinates of the vertices of the polygons of the PC 4 and enemy character 15 for each of the X-axis, Y-axis, and Z-axis.

By deforming the trajectory near a wall, it becomes easier to pitch the camera upwards, bringing enemy characters into view sooner than if the player were to move the camera downwards on an arc.

Figure 17 is an example of a flowchart illustrating a method for controlling the attitude of the virtual camera 10 when the player operates the attitude of the virtual camera 10 near a wall.

The camera control unit 35 determines whether the operation reception unit 36 has received an operation of the camera operation stick 6 that controls the attitude of the virtual camera 10 (S21).

If the determination in step S21 is Yes, the contact determination unit 34 determines whether or not the virtual camera 10 has come into contact with the wall 11 (S22). This is because if the virtual camera 10 comes into contact with the wall 11, the trajectory of the virtual camera 10 is distorted.

If the determination in step S22 is Yes, the camera control unit 35 sets a trajectory of the virtual camera 10 such that the higher or lower the height from the center of the maximum height Hmax, the greater the amount of push on the lower side (S23).

The camera control unit 35 controls the center of gravity 21 of the PC 4 and the enemy character 15 to be the gaze point according to the X and Y axis coordinates of the virtual camera 10 along the arc trajectory operated by the player (S24).

<Major Effects>
As described above, according to the game system of this embodiment, when the PC 4 approaches the wall 11, the virtual camera 10 is lowered by simple vertical movement, so that the attitude of the virtual camera 10 can be controlled so that the PC 4 is included in the angle of view. Furthermore, when locking on, the attitude of the virtual camera 10 can be controlled so that the PC 4 and the enemy character 15 are included in the angle of view by determining the point of gaze so that the PC 4 and the enemy character 15 are included in the angle of view. Furthermore, when the player operates the camera control stick 6 near a wall, if the height of the virtual camera 10 is low, the point of gaze becomes one that looks up at the PC 4 and the enemy character 15 early, making it easier for the player to visually recognize the enemy character 15.

<Other application examples>
The present invention is not limited to the above-described embodiment, and various modifications are possible without departing from the spirit and technical concept of the present invention.

For example, in this embodiment, walls 11 and 12 are used as examples of obstacles, but the obstacles may be any object. Obstacles may be man-made objects such as walls, or natural objects such as rocks and trees. Furthermore, the virtual space in which the objects move may be on the ground, in the air, underwater, or underground, or inside a car, ship, or airplane.

In addition, although it has been described that the virtual camera 10 moves to follow the PC 4, the virtual camera 10 may also move to follow an enemy character.

The configuration examples in FIG. 3 and the like are divided according to main functions to facilitate understanding of the processing by the information processing device 3. The present invention is not limited by the manner in which the processing units are divided or the names of the processing units. The processing by the information processing device 3 can be divided into even more processing units depending on the processing content. It can also be divided so that one processing unit includes even more processes.

In addition, in this embodiment, some or all of the processing performed by the game program may be performed by hardware processing circuits such as an ASIC (Application Specific Integrated Circuit), DSP (digital signal processor), or FPGA (field programmable gate array).

1 Game system 3 Information processing device 5 Game controller 7 Display device

Claims (11)

An information processing device,
a collision determination unit that determines a collision between a virtual camera in a virtual space and a collision determination target object among objects in the virtual space;
a camera control unit that causes a virtual camera to follow the movement of a target object among the objects ;
an image data generating unit that generates image data captured by the virtual camera;
the camera control unit, when making contact with the collision determination target object having a height equal to or less than a threshold, does not perform tracking movement of the virtual camera but increases the height of the virtual camera;
a game program that performs avoidance processing by lowering the height of the virtual camera rather than moving the virtual camera to follow the collision when the virtual camera comes into contact with the object subject to collision detection that has a height exceeding the threshold value ; 2 . The computer-readable storage medium according to claim 1 , wherein the object to be detected as a collision target having a height equal to or less than the threshold is a non-visualized, transparent slope object disposed around an obstacle object that serves as an obstacle among the objects. the virtual camera is restricted from moving to the inside of the slope object ;
3. The game program according to claim 2, wherein, when the object to be followed approaches the obstacle object in response to an operation by a player, the camera control unit moves the virtual camera from a lower side to a higher side on the slope object as the avoidance processing. the obstacle object has a height equal to or less than the threshold ;
4. The computer- readable storage medium according to claim 3, wherein, when the object to be followed comes closer to the obstacle object than a distance between the virtual camera and the object to be followed , the camera control unit moves the virtual camera onto the obstacle object. 5. The game program according to claim 2, wherein, when the virtual camera comes into contact with the object subject to collision detection and a player performs an operation of moving the virtual camera downward in X and Y axis coordinate directions along an arc trajectory, the camera control unit causes the virtual camera to approach the object to be followed only up to a predetermined distance. When the virtual camera locks on to an enemy character arranged in the virtual space,
Delete the slope object ;
The game program according to any one of claims 2 to 5, wherein the camera control unit adjusts a height of the virtual camera in accordance with a height of the object to be followed , and determines a pitching angle so that the enemy character and the object to be followed are included in an angle of view. the collision determination target object having a height exceeding the threshold is an obstacle object that serves as an obstacle among the objects,
2. The game program according to claim 1, wherein the camera control unit, when coming into contact with the obstacle object, pushes the virtual camera away from the obstacle object as the avoidance processing, and further changes the height of the virtual camera to a second height lower than the first height in the following movement. 8. The game program according to claim 7, wherein when the virtual camera locks on to an enemy character placed in the virtual space, the camera control unit adjusts a pitching angle so that the enemy character and the object to be tracked are included in the angle of view of the virtual camera at the second height. when the virtual camera does not come into contact with the obstacle object, the camera control unit moves the virtual camera along a circular arc in a vertical direction in the virtual space in response to an operation by a player;
9. The game program according to claim 8, wherein, when the trajectory comes into contact with the obstacle object , the camera control unit deforms the object to be tracked and the enemy character approaching the obstacle object into a trajectory that has an upward pitching angle faster than when the virtual camera moves along a circular arc trajectory. a collision determination unit that determines a collision between a virtual camera in a virtual space and a collision determination target object among objects in the virtual space;
a camera control unit that causes a virtual camera to follow the movement of a target object among the objects ;
an image data generating unit that generates image data captured by the virtual camera;
the camera control unit, when making contact with the collision determination target object having a height equal to or less than a threshold, does not perform tracking movement of the virtual camera but increases the height of the virtual camera;
When the virtual camera comes into contact with the object subject to collision detection whose height exceeds the threshold, the information processing device performs avoidance processing by lowering the height of the virtual camera instead of moving the virtual camera to follow the object . a step of a contact determination unit determining contact between a virtual camera in a virtual space and a contact determination target object among objects in the virtual space;
a step of causing a virtual camera to follow the movement of a target object among the objects by a camera control unit;
An image data generating unit generates image data captured by the virtual camera;
the camera control unit performs a step of increasing the height of the virtual camera without performing a tracking movement of the virtual camera when the virtual camera comes into contact with the collision determination target object having a height equal to or less than a threshold; and a step of performing an avoidance process of decreasing the height of the virtual camera without performing a tracking movement of the virtual camera when the virtual camera comes into contact with the collision determination target object having a height exceeding the threshold .
The camera control method includes:

Images