Game program, information processing device, and camera control method

Abstract

To provide a game program that allows a virtual camera to take an appropriate image close to an obstacle.SOLUTION: A program of the present invention causes an information processing device to function as a camera control part for causing a virtual camera to track the movement of a target object disposed in a virtual space, and as an image data generation part for generating image data captured by the virtual camera. The camera control part does not execute the tracking movement of the virtual camera under a predetermined condition and executes obstacle avoidance processing of the virtual camera.SELECTED DRAWING: Figure 7

Description

[Technical field]

[0001] The present invention relates to a game program, an information processing device, and a camera control method. [Background technology]

[0002] There is known a game program that converts objects such as a player character or an enemy character moving in a virtual space (for example, a virtual three-dimensional space) into an image with a 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 matching 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.

[0003] When the player character moves close to an obstacle such as a wall, or when the virtual camera is moved close to an obstacle such as a wall by the player's operation, the virtual camera may come closer to the obstacle than the player character. In such a case, a technique is known for moving the virtual camera upward so that the virtual camera does not collide with the obstacle (see, for example, Patent Document 1). Patent Document 1 discloses a technique for moving the virtual camera upward and changing the gaze point of the virtual camera when the player character moves close to an obstacle such as a wall. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2009-087277 A Summary of the Invention [Problem to be solved by the invention]

[0005] Although various methods have been devised for capturing images appropriately near obstacles, such as the above-mentioned techniques, there is still room for improvement.

[0006] In view of the above-mentioned problems, an object of the present invention is to provide a game program that enables a virtual camera to capture an appropriate image near an obstacle. [Means for solving the problem]

[0007] In view of the above problem, the present invention provides an information processing device that is a virtual camera in the virtual space, a collision determination unit that determines a collision with a collision determination target object among objects in the virtual space, and a tracking object among the objects. a camera control unit that causes a virtual camera to follow the movement of a target object, and an image data generation unit that generates image data captured by the virtual camera, When the object comes into contact with the object to be subjected to collision detection, the height of the object is equal to or less than the threshold value. The virtual camera is not moved in a tracking manner, The height of the virtual camera is increased, and when the virtual camera comes into contact with the object subject to collision detection whose height exceeds the threshold, the virtual camera is not moved to follow the object, and the height of the virtual camera is decreased. Provide a program that performs avoidance processing. Effect of the Invention

[0008] A game program can be provided that allows the virtual camera to capture appropriate images near obstacles. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram illustrating an example of the configuration of a game system. [Diagram 2] FIG. 2 is a diagram illustrating an example of a hardware configuration of an information processing device. [Diagram 3] FIG. 2 is an example of a functional block diagram illustrating functions of an information processing device divided into blocks. [Figure 4] FIG. 1 is a diagram illustrating an example of camera setting information (first embodiment); [Diagram 5] 1 is a diagram illustrating an example of a posture of a virtual camera; [Figure 6] 11A and 11B are diagrams illustrating operations of the attitude of the virtual camera by a player. [Figure 7] 1A to 1C 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). [Figure 8] 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. [Figure 9] 11 is a diagram illustrating the limit distance between the virtual camera and the player character. FIG. [Figure 10] 11A and 11B are diagrams illustrating inconveniences that may occur during lock-on. [Figure 11] 11 is a flowchart illustrating an example of a procedure in which a camera control unit controls the attitude of a virtual camera. [Figure 12] FIG. 11 is a diagram illustrating an example of camera setting information (Example 2). [Figure 13] 11A and 11B are diagrams illustrating a method for controlling the attitude of a virtual camera near a wall whose height exceeds a threshold (Example 2). [Figure 14] 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. [Figure 15] 11 is a flowchart illustrating an example of a procedure in which a camera control unit controls the attitude of a virtual camera. [Figure 16] 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. [Figure 17] 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. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Hereinafter, an embodiment of the game program of the present disclosure will be described with reference to the drawings. In this specification and the drawings, substantially the same configurations are denoted by the same reference numerals, and duplicated explanations will be omitted. EXAMPLES

[0011] In this embodiment, a method for controlling the attitude of a virtual camera near an obstacle (a 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 the obstacle.

[0012] <Game System> First, a configuration example 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 of this embodiment. The game system 1 has 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.

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

[0014] Furthermore, the information processing device 3 does not have to be a dedicated game machine, and may be, for example, a computer, a desktop computer, a notebook computer, a tablet computer, or the like that is manufactured and sold as a computer, or a smartphone, a mobile phone, a phablet, or the like that is manufactured and sold as a telephone. These devices are usually used as general-purpose information processing terminals, but when a player executes an installed game program, the player can progress through the game in the same way as with a dedicated game machine.

[0015] The game program of this embodiment is installed in the information processing device 3. The game program is distributed in a state stored in an optical storage medium such as a CD-ROM or a semiconductor memory such as a USB memory, or is distributed in a form in which it is downloaded from a server.

[0016] The player uses the game controller 5 to input various operations. 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, and the like, allowing the player to operate the game controller 5 by changing its attitude.

[0017] Furthermore, the information processing device 3 may further communicate with a server on the network. In this case, a plurality of information processing devices 3 executing the same game program are connected to the server, enabling a so-called online game. An online game is, for example, a game in which multiple players can cooperate to operate the same game program. The server of an online game performs the minimum processing of receiving 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 rendering each player and reflecting the operation commands.

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

[0019] The game system 1 may be a so-called cloud game. In the following, the game system 1 of the present embodiment will be described mainly with reference to the configuration of FIG.

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

[0021] The game program can be recorded in, for example, the ROM 502, the RAM 503, the recording device 508, or the like.

[0022] The CPU 501 may, for example, directly read out and execute the game program from the recording device 508, or may execute the game program after first loading it into the RAM 503. 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.

[0023] Furthermore, the CPU 501 may 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 above-mentioned game controller 5, as necessary.

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

[0025] Then, the CPU 501 and the GPU 504 output the results of the above-mentioned processing from an output device 507 including, for example, the above-mentioned display device 7 and audio output unit. The CPU 501 and the GPU 504 may transmit the results of the processing via a communication device 511 or a connection port 510 as necessary, or may record the results in the recording device 508 or recording medium 512.

[0026] 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 from that of the information processing device 3, but this does not pose any problems for the convenience of explaining this embodiment.

[0027] <About the function> Fig. 3 is an example of a functional block diagram explaining the functions of the information processing device 3 by dividing them into 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.

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

[0029] The object control unit 31 controls the positions and behaviors of characters other than the player character (an example of a target object, hereinafter referred to as a 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. Also, the character's position is determined so that the character moves on a mesh called a navigation mesh according to the character's nature. Also, behaviors include, for example, attacking, talking, or simply moving, and are also determined by the object control unit 31 according to the character's nature.

[0030] 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, etc. An object within a predetermined range from the PC (characters that are far enough away not to affect the PC4 are stopped in the first place) may be subjected to a contact determination with another object. In this embodiment, a contact determination between a virtual camera and a feature will be mainly described. Hereinafter, a feature will be simply referred to as an "obstacle."

[0031] 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 an amount equal to the contact with the object. Instead of "pushing", the virtual camera may be "stopped on the surface" of the object.

[0032] 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 will be described with reference to FIG.

[0033] The operation acceptance unit 36 ​​accepts operations from the player to the game controller 5. The operation acceptance unit 36 ​​can accept any operation that is possible within the game program, but in this embodiment, it mainly accepts operations related to the movement of the PC and the attitude of the virtual camera.

[0034] The image data generating unit 32 converts an object 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 generating unit 32 on the display device 7.

[0035] 4 is a diagram illustrating an example of the camera setting information. The camera setting information defines how the camera control unit 35 controls the attitude of the camera according to the "situation" and the "manual operation of the camera."

[0036] "Situation" is a specific situation that controls the posture of the virtual camera. In Figure 4, the situation that the virtual camera touches the slope is specified.

[0037] "Manual camera operation" indicates whether the camera control stick 6 has been operated. When 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.

[0038] "Lock-on" indicates whether the player has locked on or not. Lock-on refers to the state in which the camera position is automatically adjusted so that both the PC and the 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.

[0039] "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 a "situation", the virtual camera 10 is moved in the X- and Y-axis coordinate directions along a circular trajectory in response to the operation, and a limit distance L is set for the distance between the virtual camera 10 and the PC.

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

[0041] Also, when locked on (line 3), the height of the virtual camera (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.

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

[0043] <Virtual camera pose> FIG. 5 is a diagram for explaining the attitude of virtual camera 10. The attitude of 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 the point at which the optical axis 42 of virtual camera 10 contacts an object (PC4 in FIG. 5). The presence of an object contacting optical axis 42 is not essential, and any point on 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 virtual camera 10 is considered as a rectangular parallelepiped, and is the direction from the bottom surface to the top surface.

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

[0045] In a state where 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.

[0046] Furthermore, the camera control unit 35 controls the attitude of the virtual camera 10 in response to the operation of a camera operation stick 6 arranged on the game controller 5.

[0047] Fig. 6 is a diagram for explaining the operation of the attitude of virtual camera 10 by the player. Fig. 6(a) is a top view of PC4. In response to the operation of the player, virtual camera 10 rotates horizontally 360° around PC4. Even if it rotates, the focus point is maintained on PC4, so PC4 is always included in the angle of view of virtual camera 10.

[0048] Fig. 6(b) is a side view of PC4. Since virtual camera 10 is placed in the virtual space, it rotates vertically by a fixed angle 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), for example. In the embodiment, when the attitude of virtual camera 10 is operated, the gaze point of virtual camera 10 is controlled to the center of the arc (PC4).

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

[0050] <How to control the orientation of a virtual camera near a wall> In the following state, the virtual camera 10 looks at, for example, the waist of PC4 from a certain distance behind PC4 at height A [m]. When the player moves PC4 in the game space, the virtual camera 10 also moves in response to the movement of 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 PC4.

[0051] If the angle of view is increased, the PC 4 and the surroundings can always be included in the angle of view regardless of the relative positional relationship between 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).

[0052] 7 is a diagram illustrating a method for controlling the attitude of 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 virtual camera 10 to move up the wall 12. In this embodiment, a slope is provided on wall 12 whose height is equal to or less than the threshold. Note that, for example, an obstacle that is lower than height A [m] of virtual camera 10 in the following state (where there is no risk of contact with virtual camera 10) may not require a slope.

[0053] Furthermore, the threshold value is preferably set to a height that allows PC4 to be included in the angle of view when virtual camera 10 looks down at PC4 at the bottom of the slope at an appropriate pitching angle from above wall 12. 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.

[0054] However, if the camera control unit 35 increases the height of the virtual camera 10 in a short time near a wall, the image viewed by the player changes suddenly, which may cause motion sickness and reduce the 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 height of the camera to be gradually increased, and the image changes smoothly, making it difficult for motion sickness to occur. The virtual camera 10 cannot move inside the slope 13, but the PC4 can move inside the slope 13. In other words, the virtual camera 10 and the slope 13 are judged to collide, but the PC4 and the slope 13 are not judged to collide.

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

[0056] 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 therefore moves the virtual camera 10 along the surface of the slope 13. When moving the virtual camera 10 along the surface of the slope 13, the gaze point of the virtual camera 10 is always adjusted to PC4.

[0057] FIG. 7(b) shows a state in which PC4 is closer to wall 12 than in FIG. 7(a), and therefore 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 also moves 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 FIG. 7(a), but the height of virtual camera 10 has increased.

[0058] 7(c) shows the virtual camera 10 in a state where the PC4 has reached the bottom of the slope 13. The virtual camera 10 moves along the face of the slope 13 and reaches a height above the wall 12.

[0059] Controlling the attitude of virtual camera 10 using the slope in FIG. 7 is an example of obstacle avoidance processing.

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

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

[0062] FIG. 8 is a diagram for explaining inconveniences when a player operates the attitude of virtual camera 10 with camera control stick 6. Virtual camera 10 on wall 12 in FIG. 8 would normally move along dotted trajectory 43 by operating camera control stick 6. However, virtual camera 10 is pushed toward the PC by slope 13, and therefore exists on slope 13 with the center of 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 virtual camera 10 moves (mainly downward) along the arc trajectory in the X and Y axis coordinate directions, the more the virtual camera 10 looks up, making it difficult for PC4 to be included in the angle of view.

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

[0064] 9 is a diagram illustrating the limit distance L between the virtual camera 10 and the PC 4. By setting the limit distance L, the player can operate the camera only within the range where the PC 4 is within the angle of view, thereby preventing the PC 4 from going out of the angle of view.

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

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

[0067] FIG. 10 is a diagram for explaining inconveniences during lock-on. The player locks on to an enemy character. For example, assume that the player locks on to an enemy character 15 when the enemy character 15 is on the right side (not shown) of the PC4 in the situation shown in FIG. 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 γ naturally becomes a different angle (upward) from when the pitching angle γ is adjusted to capture the PC4 from the top of the slope 13 (above the wall), making it difficult to capture the PC4. In the situation shown in FIG. 7(a) to (c), even if the pitching angle γ is adjusted to a slightly upward angle, there is a possibility that the PC4 will be included in the field of view, but if the PC4 is inside the slope 13 as shown in FIG. 10, the PC4 will definitely be out of the field of view.

[0068] Therefore, at the time of lock-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 the second embodiment.

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

[0070] 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 performed only when the PC 4 is within a predetermined distance from an obstacle. Since 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.

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

[0072] Then, the camera control unit 35 judges whether or not a lock-on has been established (S3).

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

[0074] If the determination in step S4 is Yes, the camera control unit 35 moves the virtual camera 10 along the 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 become equal to or smaller than the limit distance L (S5).

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

[0076] Then, the camera control unit 35 processes the wall as a wall exceeding the threshold even if the wall is below the threshold (S7). That is, the subsequent processing moves to the flow of the second embodiment.

[0077] <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, and interest, etc. can be improved. Also, when the player operates the height of the virtual camera 10, the virtual camera 10 is prevented from approaching the PC4, so that the PC4 comes into the angle of view. Also, when the player locks on, the slope 13 is deleted and the height of the virtual camera 10 is lowered, so that the PC4 and the enemy character 15 come into the angle of view. EXAMPLES

[0078] In this embodiment, a method for controlling the attitude of the virtual camera 10 near an obstacle on the wall 12 where there is no room to move the virtual camera 10 will be described.

[0079] In this embodiment, it is assumed that the hardware configuration diagram of FIG. 2 and the functional block diagram of FIG. 3 described in the above embodiment can be used.

[0080] Fig. 12 is an example of camera setting information in this embodiment. Fig. 12 mainly explains the differences from Fig. 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.

[0081] 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". Also, 30 frames is set as the "adjustment speed". This is because if the camera control unit 35 changes the virtual camera height instantaneously (simple up and down movement), the screen may suddenly change, which may cause the player to feel uncomfortable. 30 frames is just an example, and several tens of frames may be used. Also, different values ​​may be adopted depending on the fps.

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

[0083] In addition, in a similar situation, when the camera is manually operated, the virtual camera 10 is moved in the X- and Y-axis coordinate directions along an arc trajectory by the player's operation. The gaze point is determined based on the height of the virtual camera 10, the distance from the wall, the distance to the enemy, and the height of the enemy.

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

[0085] Fig. 13(b) shows virtual camera 10 in an extruded state. By extruding virtual camera 10, virtual camera 10 is present on the surface of wall 11 on the PC4 side. The reason why the state shown in Fig. 13(b) occurs has been explained in Fig. 7(a).

[0086] Regardless of the presence of wall 11, when virtual camera 10 maintains a certain 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 image data generated by image data generation unit 32. Therefore, in this embodiment, contact determination unit 34 performs contact determination between virtual camera 10 and wall 11, and when 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 inside the wall.

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

[0088] 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 whose height has been lowered. 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 PC4, so that the PC4 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 PC4 to the virtual camera, and the height of the virtual camera may be lowered in proportion to the distance from the PC4 to the virtual camera and the distance from the PC4 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 PC4. Controlling the height of the virtual camera 10 from A [m] to B [m] is an example of obstacle avoidance processing.

[0089] As a result, even if PC4 approaches a wall, camera control unit 35 can control the attitude of virtual camera 10 so that PC4 is included in the angle of view.

[0090] <How to control the virtual camera's attitude when locked on to the wall> Next, with reference 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 (indicated 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, at the time of 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 the time of 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.

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

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

[0093] 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 make a determination only in step S12 without making a determination in step S11 (S11 or S12 is an example of a predetermined condition).

[0094] If the determination in step S12 is Yes, the object control unit 31 determines whether or not the height of the wall 11 exceeds a threshold value (S13). That is, it determines whether or not there is room to move the virtual camera 10 above the wall 11. This determination may be made based on, for example, 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.

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

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

[0097] Then, the camera control unit 35 determines whether or not the 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 the PC 4 are included in the angle of view at the height B [m] determined in step S15 (S17).

[0098] <When the player manipulates the virtual camera's orientation> 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).

[0099] However, when the player performs a similar operation near a wall, the trajectory of the virtual camera 10 comes into contact with the wall 11. In this case, the camera control unit 35 pushes the camera only when the trajectory comes into contact with the wall 11 (the camera goes into the wall), and the camera cannot move along the 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 pitch of the virtual camera 10 tends to point upward (so that the enemy character comes into the angle of view sooner). The camera control unit 35 determines the gaze point 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 gaze point.

[0100] FIG. 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 virtual camera is close to a wall.

[0101] 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 plus m (margin).

[0102] 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 the maximum height Hmax. As shown in FIG. 16, when the distance between the PC 4 and the enemy character 15 and the wall 11 is relatively large, the virtual camera 10 must be low in height in order for the PC 4 and the enemy character 15 to be included in the angle of view of the virtual camera 10. Therefore, the player operates the virtual camera 10 to move it in the X- and Y-axis 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 of the maximum height Hmax in the height direction, the distance of the virtual camera 10 from the wall 11 is longer than when the virtual camera 10 is above the center P.

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

[0104] In addition, 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. 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 the enemy character 15 for each of the X-axis, Y-axis, and Z-axis.

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

[0106] FIG. 17 is an example of a flowchart illustrating a method for controlling the attitude of virtual camera 10 when the player operates the attitude of virtual camera 10 when the virtual camera 10 is next to a wall.

[0107] The camera control unit 35 determines whether or not the operation receiving unit 36 ​​has received an operation of the camera operation stick 6 that controls the attitude of the virtual camera 10 (S21).

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

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

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

[0111] <Major Effects> As described above, according to the game system of this embodiment, when the PC4 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 PC4 is included in the angle of view. Furthermore, when locking on, the attitude of the virtual camera 10 can be controlled so that the PC4 and the enemy character 15 are included in the angle of view by determining the point of gaze so that the PC4 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 PC4 and the enemy character 15 early, so that the player can easily view the enemy character 15.

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

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

[0114] Also, while the virtual camera 10 has been described as moving to follow the PC 4, the virtual camera 10 may also move to follow an enemy character.

[0115] Moreover, the configuration example in Fig. 3 and the like is divided according to main functions in order 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 more processing units according to the processing contents. Also, it can be divided so that one processing unit includes more processes.

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

[0117] 1. Game System 3. Information processing equipment 5. Game Controllers 7 Display device

Claims

1. 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. A game program as described in claim 1, wherein the object to be judged for contact, which has a height below the threshold, is a non-visualized, transparent slope object arranged around an obstacle object that serves as an obstacle among the objects.

3. 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.

4. 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. 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.

6. 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.

7. The contact determination target object having a height exceeding the threshold is an obstacle object that is an obstacle among the objects, 2. The game program according to claim 1, wherein, when contact is made with the obstacle object, the camera control unit, as the avoidance processing, pushes the virtual camera away from the obstacle object, and further changes the height of the virtual camera to a second height lower than the first height in the following movement.

8. 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.

9. 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.

10. 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.

11. 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