KR102396060B1 - Changing Camera View in Electronic Games - Google Patents

Abstract

In electronic games, the camera view of an avatar traversing a three-dimensional (3D) world may be altered to avoid occlusion of the avatar by graphical objects in the camera view. The camera view can be moved forward towards the avatar to avoid occlusion, and the camera view can then be moved back away from the avatar after the avatar has passed the graphical object. Graphic objects that do not significantly occlude the avatar in the camera view may not cause changes in the camera view.

Description

Changing Camera View in Electronic Games

BACKGROUND This disclosure relates generally, but not exclusively, to computer-based gaming, and more particularly, to methods, systems, and computer-readable media for displaying a camera view in an electronic game.

Some online gaming platforms allow users (eg, players) to explore their avatars within a three-dimensional (3D) world. By using the mouse, keyboard or other input mechanism provided on their client device, the user can run, walk, climb, fly, etc., of his avatar through buildings, fields, forests, parks, mountains and other environments within the 3D world. various elements such as trees, walls, columns, clouds and other structures/objects can be rendered as visual graphical representations within the 3D world.

Typically, the 3D world is presented in a camera view as a live camera follows the avatar as the avatar traverses from one point to another through the 3D world. However, the camera view of many electronic games is filled with annoying discontinuities and destructive visual effects that often annoy many users.

According to a first aspect, there is provided a method for altering a camera view of a three-dimensional (3D) world rendered in an electronic game. The method includes: determining a speed and direction of traversal of a rendered first graphical object in a 3D world; identifying a second graphical object located along a direction of traversal; determining whether a second graphical object occluding the first graphical object in the current camera view by at least a threshold level during traversal of the first graphical object along a direction of traversal; In response to determining that occlusion of the first graphical object by the second graphical object exceeds at least a threshold level, occlusion by the second graphical object by moving the camera view forward toward the first graphical object changing the current camera view of the first graphic object to avoid and in response to determining that occlusion by the second graphical object is below the threshold level, maintaining the current camera view.

According to another aspect, there is provided a non-transitory computer-readable medium having stored thereon instructions that, in response to execution by a processor, cause the processor to control or perform an operation. The actions include: determining a speed and direction of traversal of a rendered first graphical object in a three-dimensional (3D) world of the electronic game; identifying a second graphical object located along the direction of traversal; determining whether the second graphical object occludes the first graphical object in the current camera view by at least a threshold level during traversal of the first graphical object along a direction of traversal; In response to determining that occlusion of the first graphical object by the second graphical object exceeds at least a threshold level, move the camera view forward toward the first graphical object to avoid occlusion by the second graphical object. 1 Changing the current camera view of a graphic object; and in response to determining that occlusion by the second graphical object is below the threshold level, maintaining the current camera view.

According to another aspect, a user interface; and a processor coupled to the memory having a user interface and a stored game application, wherein the game application, in response to execution by the processor, causes the processor to display a camera view of the three-dimensional (3D) world of the electronic game on the user interface. , wherein the game application is further executable by the processor to cause the processor to control or perform the performance of the action. The operations include: determining a speed and direction of traversal of a rendered first graphical object in the 3D world; identifying a second graphical object located along the direction of traversal; determining whether the second graphical object occludes the first graphical object in the current camera view by at least a threshold level during traversal of the first graphical object along a direction of traversal; In response to determining that occlusion of the first graphical object by the second graphical object exceeds at least a threshold level, move the camera view forward toward the first graphical object to avoid occlusion by the second graphical object. 1 Changing the current camera view of a graphic object; and in response to determining that occlusion by the second graphical object is below the threshold level, maintaining the current camera view.

1A is an exemplary camera view of an avatar traversing through a 3D world, wherein the camera view has not moved forward.
1B is a top view of an avatar traversing through the 3D world of FIG. 1A ;
2A is another exemplary camera view of an avatar traversing through a 3D world, wherein the camera view has moved forward and then back.
FIG. 2B is a top view of an avatar traversing through the 3D world of FIG. 2A ;
3 is a schematic diagram illustrating example parameters that may be used to determine whether to change a camera view in an electronic game, in accordance with some implementations.
4 is a schematic diagram of an example system architecture for an online game that may provide the camera views of FIGS. 1A , 1B , 2A and 2B , in accordance with some implementations.
5 is a flow diagram illustrating a method for changing a camera view in an electronic game, in accordance with some implementations.
6 is a block diagram illustrating an example computing device, in accordance with some implementations.

In the following detailed description, reference is made to the accompanying drawings, which form a part thereof. In the drawings, like symbols typically identify similar components, unless the context dictates otherwise. The exemplary embodiments described in the detailed description, drawings and claims are not meant to be limiting. Other embodiments may be utilized and other changes may be made without departing from the spirit or scope of the subject matter presented herein. Aspects of the disclosure generally described herein and illustrated in the drawings may be arranged, substituted, combined, separated, and designed in a wide variety of different configurations, all of which are contemplated herein.

References herein to “one embodiment”, “an embodiment”, “exemplary embodiment”, etc. may indicate that the described embodiment may include a particular feature, structure, or characteristic, but not all embodiments may incorporate the particular function, structure, or characteristic. may not necessarily be included. Also, such phrases are not necessarily referring to the same embodiment. Also, when a particular feature, structure, or characteristic is described in connection with an embodiment, that feature, structure, or characteristic may be affected in connection with another embodiment, whether or not explicitly described.

The present disclosure solves the aforementioned problem in electronic games by selectively moving the camera view forward towards the avatar according to the level of occlusion to occur (to avoid occlusion of the avatar in the camera view). Whether to freeze the camera view, move the camera view forward, or move the camera view backward, the speed and direction the avatar traverses in the three-dimensional (3D) world of an electronic game, whether the occlusion is hard occlusion It may depend on several factors, such as whether or not the occlusion is soft occlusion, or other factors.

For example, hard occlusion (such as a wall or other opaque graphical object) may cause the camera view to be moved forward such that the wall is removed from the camera view and thus does not occlude the avatar's camera view. Soft occlusion (such as a transparent window or other at least translucent structure/object that only partially occludes the avatar) allows the camera view to remain fixed, allowing the avatar to be seen moving behind the soft occlusion. (eg, the camera view does not move forward).

As the avatar traverses through the 3D world, the direction and speed of the avatar can be used to determine whether to change the camera view. For example, if the direction and speed of traversal is determined by, eg, a game application, to cause the avatar to pass behind hard occlusion, the camera view will be in the direction of traversal (to provide an unassigned camera view of the avatar). It moves forward towards the avatar in a vertical direction. As another example, if the direction and speed of traversing are determined by, for example, the game application to cause the avatar to pass behind soft occlusion, the game application may control the camera view to remain stationary (perpendicular to the direction of traversing). direction, not moving forward towards the avatar), the camera view shows that the avatar is partially occluded when the avatar traverses behind soft occlusion.

The speed of the avatar's traversal and/or the amount of potential occlusion may also be used as factors/thresholds for determining whether to change the camera view. As an example, the gaming application may determine that the avatar will quickly traverse behind a hard occlusion (such as a wall). Thus, even if a wall can occlude the avatar up to 100% occlusion, the avatar can move at sufficient speed so that 100% occlusion can occur for a short window of time, eg, less than a few seconds. In such cases, the duration of full occlusion may be determined to be acceptable, such as to render a smoother view of the game rather than moving the camera at high speed, so that the gaming application does not move the camera view forward to avoid occlusion. it may not be In another example, the avatar may pause/pause behind a soft occlusion (eg, narrow pole) that only partially occludes the avatar (eg, 10% occlusion) - in this case, the Since durations occur over several seconds, the gaming application can move the camera view forward to provide a full (non-occluded) view of the avatar.

The details of these and other aspects may be further understood with reference to FIGS. 1A, 1B, 2A and 2B. First, FIG. 1A is an exemplary camera view 100 of an avatar 102 traversing through a 3D world in an electronic game. The camera view 100 may be, for example, a side view rendered in a user interface of the client device to follow (eg, pan) the movement of the avatar 102 within the 3D world. The camera views shown and described herein may be provided by a “virtual camera” that may be positioned anywhere in the 3D world to create a camera view and to generate different views. The position of the virtual camera may also be updated/changed.

In some implementations, the avatar 102 may be a graphical object representing a player/user operating a client device to play an electronic game. While playing the electronic game, the avatar 102 is traversing (eg, walking or running) from left to right in the 3D world, as represented by one or more arrows 104 . As the avatar 102 traverses from left to right in the camera view 100 , the subsequent location of the avatar 102 is shown in FIG.

Camera view 100 shows avatar 102 initially traversing along a substantially flat path 106 in a left-to-right direction. A flat path 106 may lie in a planar region (which may be expressed in x-y coordinates) in the 3D world. As the avatar 102 continues to traverse from left to right, the avatar 102 may also change elevation to climb a slope 108 (which may be expressed in x-y-z coordinates) in the 3D world.

A plurality of graphic objects may be rendered in the 3D world in addition to the avatar 102 . For example, the graphical object may be trees 110 , 112 and 114 along path 106 and slope 108 . Trees 110 , 112 and 114 may have tree trunks 116 , 118 and 120 respectively. Another graphical object may be a wall 122 (such as a wall of a building) on top of the slope 108 .

Trees 110 , 112 and 114 may have respective tree trunks 116 , 118 and 120 , which as the avatar passes behind tree trunks 116 , 118 and 120 respectively, the tree trunks 116 , 118 and 120 has a relatively thin profile such that it does not completely occlude the avatar 102 . Each of the tree trunks 116 , 118 , and 120 can thus be thought of as a “soft” occlusion that allows at least a portion of the avatar 102 to be visible. Thus, for example, in FIG. 1A , parts of the body of the avatar 102 (such as parts of the head, limbs, or torso) are still visible in the camera view 100 , while other parts of the body of the avatar 102 are It is occluded by tree trunks 116 , 118 and 120 . As will be described in more detail with respect to FIG. 3 below, the amount and/or duration of occlusion determines whether or not the camera view 100 remains stationary (eg, as shown in FIG. 1A , where Tree trunks 116 , 118 and 120 occlude any portion of avatar 102 in camera view 100 ) or avatar 102 as avatar 102 traverses behind tree trunks 116 , 118 and 120 . ) may be used to determine whether to move the camera view 100 forward to a position between the avatar 102 and the tree trunks 116 , 118 and 120 , to show an unoccluded view of .

1B is a top view of the avatar 102 traversing through the 3D world of FIG. 1A . In one embodiment, the top view of FIG. 1B may be a camera view 150 rendered in the electronic game, such as when the user selects an overhead plan view or aerial view while playing the electronic game. Corresponding to the position of the graphical object shown in the camera view 100 of FIG. 1 , the camera view 150 of FIG. arrow 104 , trees 110 , 112 and 114 , and wall 122 .

1B shows the tree 110 having protruding branches 124 through which the avatar 102 passes. Similar to camera view 100 of FIG. 1 , camera view 150 of FIG. 1B shows that branch 124 occludes any portion of avatar 102 as avatar 102 traverses under branch 124 . is treated with soft occlusion while other parts of the avatar 102 remain stationary such that they remain visible under the branches 124 . Graphic objects with a larger profile (thicker branches, clouds, overpasses, etc.) than branches 124 that will occlude a larger portion of the avatar 102 (and/or for a longer duration of occlusion) If present, the camera view 150 may be altered to move the camera view “between” the avatar 102 and a graphical object such that the avatar 102 is not occluded in the camera view.

1A and 1B , the avatar 102 is approaching the wall 122 . If the camera view 100 remains unchanged while the avatar 102 traverses behind the wall 122 , the avatar 102 will be fully occluded by the wall 122 . The wall 122 can thus be considered to be a hard occlusion that completely occludes the avatar 102 . Accordingly, one embodiment changes the camera view so that the wall 122 does not occlude the avatar 102 while the avatar 102 is positioned behind the wall 122 . 2A and 2B illustrate this aspect in more detail.

Specifically, FIG. 2A is a camera view 200 of the avatar 102 traversing behind a wall 122 (again shown by the dashed line representation of the avatar 102 and arrow 104 ), wherein the camera view 200 ) moved forward with respect to the camera view 100 of FIG. 1A . Thus, in FIG. 2A , the camera rendering the camera view 200 is moved forward (toward the avatar 102 and in a direction perpendicular to the arrow 104 ) to a position between the wall 122 and the avatar 102 . (eg, moving closer to the avatar 102 ). In this way, the wall 122 disappears (eg, removed) from the camera view 200 and thus no longer occludes the avatar 102 . As shown in FIG. 2A , the avatar 102 is also shown rendered at an enlarged size indicating that the camera view 200 has been zoomed in closer to the avatar 102 .

As shown in the plan view of FIG. 2B at the corresponding location(s) of the avatar 102 , the wall 122 itself continues to exist and the avatar 102 still traverses behind the wall 122 . As mentioned above, compared to that shown in FIG. 1A , the camera view 200 now excludes the wall 122 by moving forward through the wall 122 , whereby the wall 122 becomes the camera view 200 . ) to prevent occlusion of the avatar 102 .

In the example of FIGS. 2A and 2B , the avatar 102 continues traversing behind the wall 122 and reaches a portion of the wall 122 including windows 202 and 204 mounted to a sash 206 . Windows 202 and 204 and sash 206 are considered soft occlusion allowing portions of avatar 102 to be visible when avatar 102 traverses behind windows 202 and 204 and sash 206 can be For example, windows 202 and 204 may be transparent or translucent, and window sill 206 may have a narrower profile compared to that of avatar 102 .

FIG. 2A further shows a camera generating a camera view 250 that has been moved back (away from the avatar 102 and perpendicular to the direction of traversal) with respect to the camera view 200 . That is, the camera generating the camera view 250 has now moved back to its original position in order to be in front of the windows 202 and 204 and the window frame 206 . The avatar 102 is now smaller in size (returns to its original size) compared to the enlarged size of the camera view 200 , and when the avatar 102 traverses behind the windows 202 and 204 and the sash 206 , the avatar 102 . 102 is partially visible or partially occluded.

3 is a schematic diagram illustrating example parameters that may be used to determine whether to change a camera view in an electronic game, in accordance with some implementations. The various graphical elements and other information shown in FIG. 3 are labeled similarly to FIGS. 1A, 1B, 2A and 2B for better understanding and consistency.

Similar to Figures 1b and 2b, Figure 3 shows a top view of the 3D world. The 3D world and the graphic elements contained therein may be laid out according to the x-y-z coordinate system 300 as an example, although other types of coordinate systems and techniques for identifying the position and relative positions of graphic elements may be used in different embodiments. . In Fig. 3, the x-y coordinate axis lies in the plane of the drawing sheet, whereas the z-coordinate lies in an axis perpendicular to the plane of the drawing sheet. For simplicity of explanation, the avatar 102 is shown and described below as traversing only along the x-axis in the direction of arrow 104 , and not traversing along the y- and z-coordinates off the x-axis. It should be understood that this single-dimensional traversal of the avatar 102 within the 3D world is exemplary only, and that the player/user may navigate the avatar 102 in any direction in the coordinate system 300 - the avatar 102 along the x-axis. The following discussion of single-dimensional movement of 102 may apply to other movements of avatar 102 along the y-axis and z-axis.

The avatar 102 is traversing along the x-axis at a particular velocity v, which can be measured in terms of pixels per second across a display screen or other unit of measure(s). In any given case, the location of the avatar 102 may be identified at points A, A1, A2, A3, A4, etc. of the coordinate system 300 . Points A, A1, A2, A3, A4, etc. are sufficient to identify the avatar 102 , an edge of the avatar (such as a fingertip), or an immediate location of the avatar 102 in the coordinate system 300 , the body of the avatar 102 . may correspond to a central axis passing through different locations on the graphical representation of The positions of other graphic elements in the 3D world may also be represented by one or more points B-H in the coordinate system 300 . For example, the location of the tree trunk 120 of the tree 114 may be defined at point C along the central z-axis of the tree trunk 120 . Alternatively or additionally, an edge boundary of the tree trunk 120 may be identified at points B and D. Still alternatively or additionally, a point C along the z-axis of the tree trunk 120 may be used to identify a location of the tree trunk 120 , and other configuration information (along the z-axis of the tree trunk 120 ) may be used to specify a constant or varying edge of the tree trunk 120 (such as a radius in terms of a pixel, measured from point C and another point).

In a similar manner, the edge of the wall 122 may be located at points E and F, the edge of the window 202 may be located at points F and G, and the edge of the window frame 206 may be located at points G and H can be located. Specific coordinates and other size/position information corresponding to points A-H may be stored as attribute/configuration information for each graphic element in the 3D world.

Camera views 100 , 200 and 250 of FIGS. 1A and 2A are also represented by dashed lines in FIG. 3 . Starting first with respect to the camera view 100 , the avatar 102 is determined to traverse from point A to point A1 and then to point A2 . In the region in front (eg, to the left) of the x-coordinate corresponding to point B or C, the game application determines that there is no graphic object occluded the avatar 102 , so that the camera view 100 remains unchanged. there is.

As the avatar 102 approaches the x-coordinate corresponding to point B or C, eg, by a game application (or game engine), a graphical object (eg, tree 114 ) becomes the traversal of avatar 102 . It is determined to lie proximate to the path and to occlude the avatar 102 . However, the game application also indicates that when the avatar 102 reaches point A1 (corresponding to the x-coordinate of point C where there may be the maximum amount of occlusion), the avatar 102 will not be fully occluded, and /or decide to be occluded only temporarily. For example, the maximum amount of occlusion may be less than 50% of the profile of the avatar 102 , or less than some other threshold level. For example, the length between points B and D of the diameter of the tree trunk 120 may be significantly shorter than the length of the visible profile of the avatar 102 , so that the maximum amount of occlusion is less than 50% of the visible profile of the avatar 102 . can The 50% threshold is exemplary and may be configured with other threshold amounts or ranges for electronic games. Other thresholds or combinations thereof may be used. For example, a threshold for determining whether to change the camera view may be a duration (eg, occlusion less than or equal to 0.5 seconds), or a combination of time and amount of occlusion (eg, greater than 60% occlusion, 0.5 seconds). above, etc.). In this example, the gaming application does not meet the threshold for the amount of occlusion to change the camera view. Keep the camera view 100 unchanged (eg, do not move the camera view forward).

In some embodiments, the duration of occlusion may be used as an additional or alternative parameter to determine whether to change the camera view. For example, in some implementations tree trunk 120 may be wide enough to occlude more than 50% of the profile of avatar 102 , perhaps even 100% occlusion. However, if the speed v of the avatar 102 is high enough so that the duration of occlusion is less than 1 second or some other threshold level that may be set for the electronic game, the gaming application may not change the camera view 100 . (eg, camera view 100 remains stationary and is not moved forward). The reason is that the duration of occlusion is short enough in time compared to the fast movement of the camera in the forward and backward directions, which can provide a camera view with a high level of motion that is less enjoyable as a user interface than temporary occlusion. .

In another example, the amount of occlusion caused by the tree trunk 120 (or other graphical object) is determined by the user choosing to pause or slow down the speed v of the avatar 102 while the avatar is partially occluded. Except as determined, it may be less than or equal to 50%. Thus, the duration of occlusion may exceed one second or other threshold amount of time set in electronic games. In such a situation, the game application may change the camera view to move the camera view forward towards the avatar 102 , whereby the avatar 102 is not occluded while the avatar 102 is paused or moved slowly. provides a view.

Continuing with FIG. 3 , the avatar 102 continues traversing, reaching point A2 . Point A2 may be immediately before the x-coordinate of point E, exactly at the x-coordinate of point E, or directly through the x-coordinate of point E. In this situation, the gaming application determines that the speed v and the transverse direction of the avatar 102 place the avatar 102 behind the wall 122 . The game application also knows from the configuration information that the wall 122 provides a hard occlusion that completely occludes the avatar 102 between points E and F. As such, the game application changes the position of the camera so that the camera view changes from camera view 100 to camera view 200, while avatar 102 traverses between the x coordinates corresponding to points E and F ( For example, while the avatar 102 is at point A3 ), it moves the camera view between the wall 122 and the avatar 102 .

Subsequently, when the avatar 102 approaches the x-coordinate of point F, is exactly at the x-coordinate of point F, or passes directly through the x-coordinate of point F, the game application determines that the speed and direction of traversal is ) will pass behind the window 202 and window sill 206 , which are soft occlusion. Accordingly, the game application may change the camera position to change from camera view 200 to camera view 250 , thereby moving the camera view back to its original position. The avatar 102 is thus fully visible behind the window 202 between points F and G, and is partially occluded between points G and H. Moving the camera back and forth to provide a camera view (100, 150, 250, etc.) can be a "jerky zoom" that avoids rendering of the occluded graphic object during the transition, or the occluded graphic object. It can be a relatively smooth transition with the camera view sliding through. The type of transition may vary from implementation to implementation, based on developer and/or player configuration settings.

Thus, camera view 250 can change camera view 250 depending on whether avatar 102 pauses or decelerates behind soft occlusion caused by window frame 206 between point G and point H. may be similar to the camera view 100 described above.

1A, 1B, 2A, 2B and 3 illustrate movement in the x-direction, it will be understood that the avatar can move in any direction, eg, the x-y direction, the y-z direction, or the x-y-z direction, based on user input. . For example, lateral movement (eg, as indicated by pressing a single arrow key on a keyboard, entering a gesture in a single direction, etc.) may include movement along a single direction. In another example, a combined movement (e.g., simultaneously pressing two vertical arrow keys, such as Left and Up, represented by a "leap" gesture, etc.) includes movement in two or more directions. can do. In another implementation, the camera generating the camera view may be positioned in a direction generally perpendicular to the primary direction of movement (eg, as the avatar moves from left to right in the user interface, the camera is perpendicular to the screen displaying the avatar) may be positioned in the direction of phosphorus). In a different implementation, the movement of the avatar within the 3D world may be governed by rules specified by the game's developer. In some implementations, each graphic object in the game may be stored in a data store having a corresponding attribute, such as a dimension, transparency level, color, texture, and the like.

4 is a schematic diagram of an example system architecture for an online game that may provide the camera views of FIGS. 1A, 1B, 2A, and 2B, in accordance with some implementations. Online gaming platforms (also referred to as “user-generated content platforms” or “user-generated content systems”) provide a variety of ways for users to interact with each other, such as while users are playing electronic games. For example, users of an online gaming platform may work together for a common goal, share various virtual gaming items, send electronic messages to each other, and the like. A user of the online gaming platform may play a game using a character, such as the avatar 102 described above, that the user may navigate through a rendered 3D world in the electronic game.

Online gaming platforms may also allow users of the platform to create and animate avatars, as well as allow users to create other graphical objects and place them in the 3D world. For example, a user of an online gaming platform may be permitted to create, design, and customize an avatar 102 , and to create, design, and insert walls 122 , windows 202 and other graphical objects in the 3D world.

In FIG. 4 , an exemplary system architecture 400 (also referred to herein as a “system”) includes an online gaming platform 402 , a first client device 410 (herein generally referred to as “client device(s) 410 ). ") and at least one second client device 416 . The online gaming platform 402 may include a game engine 404 and one or more electronic games 406 , among others. System architecture 400 is provided to illustrate one possible implementation. In other implementations, the system architecture 400 may include the same, fewer, more, or different elements configured in the same or different manner as shown in FIG. 4 .

The communications network 422 may be used for communications between the online gaming platform 402 and the client devices 410/416 and/or other elements of the system architecture 400 . Network 422 may include a public network (eg, the Internet), a private network (eg, a local area network (LAN) or wide area network (WAN)), a wired network (eg, an Ethernet network), a wireless network (eg, an 802.11 network, It may include a Wi-Fi network or wireless LAN (WLAN), a cellular network (eg, a long term evolution (LTE) network), a router, a hub, a switch, a server computer, or a combination thereof.

The client device 410 may include a gaming application 412 and one or more user interfaces 414 (eg, audio/video input/output devices). The client device 416 may include a game application 420 and a user interface 418 (eg, an audio/video input/output device). The audio/video input/output device may include one or more of a microphone, a speaker, a headphone, a display device, and the like.

System architecture 400 may further include one or more storage devices 424 . The storage device 424 may be, for example, a storage device located within the online gaming platform 402 or communicatively coupled to the online gaming platform 402 via a network 422 (as shown in FIG. 4 ). . The storage device 424 includes, for example, the graphic object rendered in the game 406 by the game engine 404 or the game application 412/420, as well as configuration/property information (eg, the coordinate information described above, the size of the graphic object). dimensions, etc.). In some embodiments, storage device 424 may be part of a separate content delivery network that provides graphical objects rendered in game 406 . For example, game application 412 may pull (or push) a graphical object stored on storage device 424 for display while playing a game.

In one implementation, storage device 424 may be a non-transitory computer readable memory (eg, random access memory), cache, drive (eg, hard drive), flash drive, database system, or other device capable of storing data and other content. It can be a tangible component or device. Storage device 424 may also include multiple storage components (eg, multiple drives or multiple databases), which may span multiple computing devices (eg, multiple server computers).

In some implementations, the online gaming platform 402 may include a server having one or more computing devices (eg, cloud computing systems, rackmount servers, server computers, clusters of physical servers, etc.). In some implementations, the server may be included in the online gaming platform 402 , may be a standalone system, or may be part of another system or platform.

In some implementations, the online gaming platform 402 is one or more computing devices (eg, a rackmount server) that may be used to perform operations on the online gaming platform 402 and provide access to the online gaming platform 402 to a user. , router computers, server computers, personal computers, mainframe computers, laptop computers, tablet computers, desktop computers, etc.), data storage (eg, hard disks, memory, databases), networks, software components and/or hardware components. can The online gaming platform 402 may also include a website (eg, a webpage) or application backend software that may be used to provide users with access to content provided by the online gaming platform 402 . For example, a user may access the online gaming platform 402 using a gaming application 412 on the client device 410 .

In some implementations, the online gaming platform 402 is a type of social network that provides connections between users or a user-generated content system that allows users (eg, end users or consumers) to communicate with other users on the online gaming platform 402 . wherein the communication is voice chat (eg, synchronous and/or asynchronous voice communication), video chat (eg, synchronous and/or asynchronous video communication), or text chat (eg, synchronous and/or asynchronous text-based communication) communication) may be included. In some implementations of the present disclosure, a “user” may be represented as a single individual. However, other implementations of the present disclosure include that a “user” (eg, user-created) is an entity controlled by a set of users or an automated source. For example, in a user-generated content system, a set of individual users associated as a community or group may be considered a “user.”

In some implementations, the online gaming platform 402 may be a virtual gaming platform. For example, the gaming platform may provide a single player or multiplayer game to a community of users who may access or interact with the game using the client device 410 over the network 422 . In some implementations, games (also referred to herein as “video games,” “online games,” or “virtual games,” etc.) are, for example, two-dimensional (2D) games, three-dimensional (3D) games (eg, 3D user-generated). game), virtual reality (VR) game, or augmented reality (AR) game.In some implementations, the user can engage in gameplay with other users.In some implementations, the game can be played in real time with other users of the game. can be

In some implementations, gameplay is one or more player interactions with a client device (eg, client device 410 and/or 416 ) within a game (eg, game 406 ) or client device 410 or 416 . may refer to the display of an interaction on a display or other user interface (eg, user interface 414/418).

In some implementations, game 406 may include electronic files that may be executed or loaded using software, firmware, or hardware configured to present game content (eg, digital media items) to an entity. In some implementations, a game application 412 may be executed and a game 406 may be rendered in conjunction with a game engine 404 . In some implementations, games 406 may have a common set of rules or common goals, and environments of games 406 share a common set of rules or common goals. In some implementations, different games may have different rules or goals from each other.

In some implementations, a game may have one or more environments (also referred to herein as “gaming environments” or “virtual environments”) to which multiple environments can be linked. An example of an environment may be a 3D environment. One or more environments of game 406 may be collectively referred to herein as “world” or “gaming world” or “virtual world” or “universe”. An example of a world could be the 3D world of the game 406 , as illustrated in FIGS. 1A , 1B , 2A , 2B and 3 above. For example, a user may build a virtual environment that is linked to another virtual environment created by another user. A character in a virtual game can cross virtual boundaries and enter an adjacent virtual environment.

It may be noted that a 3D environment, or 3D world, uses graphics that provide a three-dimensional representation of geometric data representing the game content (or at least the current game content as 3D content, whether or not a 3D representation of the geometric data is used). appear). A 2D environment, or 2D world, uses graphics to provide a two-dimensional representation of geometric data representing game content.

In some implementations, the online gaming platform 402 may host one or more games 406 , which may allow users to interact with the games 406 using the game application 412 on the client device 410 . can A user of the online gaming platform 402 plays, creates, interacts with, or builds a game 406 , communicates with other users, and/or an object of the game 406 (eg, “item(s)” herein). or “game objects” or “virtual game item(s) or “graphic objects”) may be created and constructed. For example, in creating a user-generated virtual item, the user creates one or more virtual environments for a character, animation for a character, decoration for a character, an interactive game, among others, or builds a structure used in game 406 . can do. In some implementations, users may purchase, sell, or trade game virtual game objects, such as in-platform currency (eg, virtual currency), with other users of the online gaming platform 402 . In some implementations, the online gaming platform 402 can send game content to a game application (eg, game application 412 ). In some implementations, game content (also referred to herein as “content”) includes any data or software instructions (eg, game objects, games, user information, videos, images, instructions) associated with the online gaming platform 402 or game application. , media items, etc.). In some implementations, a game object (eg, also referred to herein as “item(s)” or “object” or “virtual game item(s)”) is a game 406 or client device ( 410/416), may refer to an object used, created, shared, or otherwise shown in the game application 412 or 420 of FIG. For example, a game object may be a part, model, character, or component thereof (eg, face, arm, lips, etc.), tool, weapon, clothing, building, vehicle, currency, flora, fauna, component of the foregoing (eg, windows of buildings), and the like.

It may be noted that the online gaming platform 402 hosting the game 406 is provided for purposes of illustration. In some implementations, the online gaming platform 402 may host one or more media items that may include communication messages from one user to one or more other users. Media items include digital video, digital movies, digital photos, digital music, audio content, melodies, website content, social media updates, e-books, e-magazines, digital newspapers, digital audio books, e-journals, web blogs, real simple syndication) feeds, electronic comic books, software applications, and the like. In some implementations, a media item may be an electronic file that may be executed or loaded using software, firmware, or hardware configured to present a digital media item to an entity.

In some implementations, the game 406 may be associated with a particular user or a particular group of users (eg, a private game) or made widely available to users of the online gaming platform 402 (eg, a public game). In some implementations where the online gaming platform 402 associates one or more games 406 with a particular user or group of users, the online gaming platform 402 may send user account information (eg, a user account identifier such as a user name and password). may be used to associate specific user(s) with the game 406 .

In some implementations, the online gaming platform 402 or client device 410/416 may include a game engine 404 or game application 412/420. In some implementations, game engine 404 may be used for development or execution of game 406 . For example, the game engine 404 may include, among other features, a rendering engine (“renderer”) for 2D, 3D, VR or AR graphics, a physics engine, a collision detection engine (and collision response), a sound engine, and scripting capabilities. , animation engines, artificial intelligence engines, networking functions, streaming functions, memory management functions, threading functions, scene graph functions, or video support for cinematics. Components of the game engine 404 may generate instructions (eg, rendering instructions, collision instructions, animation instructions, physics instructions, etc.) to help compute and render the game. In some implementations, the gaming applications 412/418 of the client devices 410/416 may each operate independently, in cooperation with the game engine 404 of the online gaming platform 402 , or a combination of the two. .

In some implementations, both the online gaming platform 402 and the client devices 410/416 may execute a game engine or game application (404, 412, 420, respectively). The online gaming platform 402 using the game engine 404 may implement some or all game engine functions (eg, generating physics commands, animation commands, rendering commands, etc., including controlling changes to the camera view described above). or offload some or all game engine functions to the game application 412 of the client device 410 . In some implementations, each game 406 may have a different ratio between the game engine functions performed on the online gaming platform 402 and the game engine functions performed on the client devices 410 and 416 .

For example, the game engine 404 of the online gaming platform 402 can be used to generate physics commands when there is a conflict between at least two game objects, while additional game engine functions (eg, changing the camera view) , including rendering command generation) may be offloaded to the client device 410 . In some implementations, the proportion of game engine functions performed on the online gaming platform 402 and the client device 410 may be changed (eg, dynamically) based on gameplay conditions. For example, if the number of users participating in gameplay of a particular game 406 exceeds a threshold number, the online gaming platform 402 performs one or more game engine functions previously performed by the client device 410 or 416 . can do.

For example, a user may play a game 406 on client devices 410 and 416 and issue control commands (eg, right, left, up, down, user selection, or user input such as character position and speed information, etc.). to the online gaming platform 402 . After receiving control commands from the client devices 410 and 416, the online gaming platform 402 provides gameplay commands (eg, location and speed information or rendering commands of characters participating in group gameplay, commands such as collision commands, etc.) ) to the client devices 410 and 416 based on the control command. For example, the online gaming platform 402 may perform one or more logical operations (eg, using the game engine 404 ) on the control instructions to generate gameplay instructions for the client devices 410 and 416 . . In other instances, the online gaming platform 402 may pass one or more of the control instructions from one client device 410 to another client device participating in the game 406 (eg, client device 416 ). Client devices 410 and 416 may use gameplay commands and render gameplay for display on the display of client devices 410 and 416 , including the adjustable camera views described above.

In some implementations, the control instructions may refer to instructions that indicate in-game activities of the user's character. For example, the control commands may include user inputs for controlling in-game activities such as right, left, up, down, user selections, gyroscope position and orientation data, force sensor data, and the like. The control command may include character position and speed information. In some implementations, the control commands are sent directly to the online gaming platform 402 . In another implementation, control commands may be sent from a client device 410 to another client device (eg, client device 416 ), where the other client device uses the local game application 420 to execute gameplay commands. create The control instructions may include voice communication messages or instructions for playing other sounds from other users on an audio device (eg, speakers, headphones, etc.), eg, other sounds generated using voice communication or the audio spatialization techniques described herein. may include

In some implementations, gameplay instructions may refer to instructions that allow the client device 410 to render the gameplay of a game, such as a multiplayer game. Gameplay commands may include one or more of user input (eg, control commands), character position and speed information, or commands (eg, physics commands, animation commands, rendering commands, collision commands, etc.).

In some implementations, the client device(s) 410 or 416 are personal computers (PCs), mobile devices (eg, laptops, mobile phones, smartphones, tablet computers, or netbook computers), networked televisions, gaming consoles, etc. Each of the computing devices may be included. In some implementations, client device 410 or 416 may also be referred to as a “user device”. In some implementations, one or more client devices 410 or 416 may connect to the online gaming platform 402 at any given moment. It may be noted that the number of client devices 410 or 416 is provided by way of example rather than limitation. In some implementations, any number of client devices 410 or 416 may be used.

In some implementations, each client device 410 or 416 may include an instance of a game application 412 or 420 , respectively. In one implementation, game application 412 or 420 allows a user to control a virtual character in a virtual game hosted by online gaming platform 402 , or content such as game 406 , images, video items, web pages, documents, etc. to use and interact with the online gaming platform 402 , such as viewing or uploading In one example, the game application may be a web application (eg, an application that works in conjunction with a web browser) that can access, search, present, or navigate content provided by the web server (eg, virtual characters in a virtual environment, etc.) . In another example, the game application is installed and executed locally on the client device 410 or 416 and is a native application (eg, a mobile application, app, or gaming program) that allows a user to interact with the online gaming platform 402 . ) can be A gaming application may render, display, or present content (eg, a web page, a media viewer) to a user. In implementations, the game application may also include an embedded media player (eg, a Flash® player) embedded in a web page.

In accordance with aspects of the present disclosure, gaming applications 412 / 420 allow a user to interact with the online gaming platform 402 (eg, play a game 406 hosted by the online gaming platform 402 ); It may be an online gaming platform application that builds, creates, edits, and uploads content to the online gaming platform 402 . As such, the gaming application 412 / 420 may be provided to the client device 410 or 416 by the online gaming platform 402 . In another example, the game application may be an application downloaded from a server.

In some implementations, a user may log in to the online gaming platform 402 through a gaming application. A user may access a user account by providing user account information (eg, a username and password), wherein the user account includes one or more characters that may participate in one or more games 406 of the online gaming platform 402 and related

In general, functions described in one implementation as being performed by the online gaming platform 402 may also be performed by the client device(s) 410 or 416 or the server in another implementation where appropriate. In addition, a function assigned to a specific component may be performed by different or a plurality of components operating together. The online gaming platform 402 may also be accessed as a service provided to other systems or devices via an appropriate application programming interface (API), and thus is not limited to use on a website.

5 is a flow diagram illustrating a method 500 for changing a camera view in an electronic game, in accordance with some implementations. For simplicity, various operations of method 500 will be described in the context of a gaming application 412 performing the operations. However, as described above with respect to FIG. 4 , some of the operations may alternatively or additionally be performed, in whole or in part, by the game engine 404 on the gaming platform 402 . Example method 500 may include one or more operations illustrated in one or more blocks, such as blocks 502 - 514 . The various blocks of method 500 and/or any other process(s) described herein may be combined into fewer blocks, divided into additional blocks, supplemented with additional blocks, and/or based on a desired implementation can be removed.

The method 500 of FIG. 5 may be described herein with reference to the elements shown in FIGS. 1A, 1B, 2A, 2B and 3 . In one embodiment, the operations of method 500 may be performed in a pipelined sequential manner. In other embodiments, some operations may be performed out of sequence, in parallel, or the like.

At block 502 (“determining the direction and speed of traversing of the avatar”), the user is playing an electronic game that includes moving a graphical object, such as the avatar 102 , within the 3D world. The gaming application 412 identifies the speed (eg, pixels per second) and direction (eg, a particular direction along the coordinate system 300 ) of traversing the avatar 102 within the 3D world. Block 502 may continue to block 504 .

At block 504 (“Identify graphical object along direction of traversal”), game application 412 electronically determines the direction of traversal of avatar 102 to identify graphical objects located along direction of traverse. Compare with setting/property information of game. For example, in FIGS. 1A and 3 , the graphical object is a tree trunk 120 or wall 122 having coordinates in a coordinate system 300 that determines that the game application 412 is positioned along the direction of traversal of the avatar 102 . can Block 504 may be followed by block 506 .

At block 506 (“Does the graphical object occlude the avatar greater than a threshold level?”), the game application 412 determines whether the graphical object will occlude the avatar 102 in the current camera view, and if so, decide how much For example, the game application 412 may determine that the avatar 102 will traverse behind the graphical object (such as shown in FIGS. 1A and 2A ) such that the graphical object occludes the avatar 102 in the current camera view. . If there is potential occlusion, the game application 412 determines the level of occlusion by referencing the level of occlusion relative to a threshold level.

For example, the threshold level may be an amount threshold, as in the example provided above where the threshold level is set to 50% occlusion (or some other threshold level). An occlusion of less than 50% may be considered soft occlusion, and an occlusion greater than 50% may be considered hard occlusion. The threshold to which the gaming application 412 compares may also be a time threshold, such as whether the speed of the avatar's traversal causes occlusion to occur only for short durations or for relatively long durations.

If at block 506 the gaming application 412 determines that the threshold level will not be exceeded (“No” at block 506 ), then the gaming application 412 at block 507 (“keep the existing camera view”) ) does not change the camera view. For example, the camera view does not move forward towards the avatar 102 in a way that removes the graphical object from the camera view. Block 507 may continue to block 502 .

If, however, at block 506 the gaming application 412 determines that the threshold level will be exceeded (“Yes” at block 506 ), then the gaming application 412 returns at block 508 (“turn the camera view towards the avatar”). By moving forward, change the camera view in "change the camera view to avoid occlusion"). For example, as shown in FIG. 2A , the camera view is between the wall 122 and the avatar 102 , such that the wall 122 is removed from the camera view and the enlarged unassembled avatar 102 is rendered in the camera view. moved forward to a position between Block 508 may be followed by block 510 .

At block 510 (“Is the threshold level still exceeded?”), the game application 412 determines whether occlusion will still remain above the threshold if the camera view is moved back to its original position. For example, if the camera view returns to the previous camera view (moved back) while the avatar 102 is still traversing behind the wall 122 , the threshold is still exceeded (“Yes” at block 510 ), and thus the game application keeps the existing camera view unchanged at block 512 (“keep the existing camera view”). In another example, the avatar 102 may have passed through the wall 122 and may immediately encounter additional graphical objects that result in occlusion exceeding a threshold (another “Yes” at block 510 ). ) - In this situation, the game application 412 retains the existing camera view, in order to exclude additional graphical objects from the camera view, rather than moving the camera view back away from the avatar 102 . Block 512 may be followed by block 510 .

However, at block 510 , if the threshold level for occlusion is no longer exceeded (“NO” at block 510 ), then the camera view is displayed at block 514 (“by moving the camera view back away from the avatar”). , back to previous camera view") can be changed back to move back away from the avatar 102 . For example, the avatar 102 may now have passed through the wall 122 and is traversing along a path where there is no graphical object or a graphical object is present but will not satisfy the threshold level for occlusion. In this situation, the camera view may return to a previous position where the camera view did not move forward towards the avatar 102 .

The method 500 then returns to block 502 to continue monitoring the speed and direction of traversing of the avatar 102 . Method 500 may be repeated as avatar 102 continues to move through the 3D world.

6 is a block diagram of an example computing device 600 that may be used to implement one or more features described herein. The client devices 410 and 416 of FIG. 4 and/or the gaming platform 402 may be provided in the form of the computing device 600 of FIG. 6 . In one example, computing device 600 may be used to perform the methods described herein. Computing device 600 may be any suitable computer system, server, or other electronic or hardware device. For example, computing device 600 may be a mainframe computer, desktop computer, workstation, portable computer, or electronic device (portable device, mobile device, cell phone, smartphone, tablet computer, television, TV set-top box, personal digital assistant (PDA)). assistant), media player, game device, wearable device, etc.). In some implementations, device 600 includes a processor 602 , a memory 604 , an input/output (I/O) interface 606 , and an audio/video input/output device 614 .

Processor 602 may be one or more processors and/or processing circuitry for executing program code and controlling basic operations of computing device 600 . “Processor” includes any suitable hardware and/or software system, mechanism or component that processes data, signals, or other information. A processor may include a general-purpose central processing unit (CPU), multiple processing units, systems having dedicated circuitry to accomplish the functions, or other systems. Processing need not be limited to a particular geographic location or time constrained. For example, the processor may perform its function in "real time", "offline", "batch mode", and the like. Portions of processing may be performed by different (or the same) processing systems, at different times and at different locations. A computer may be any processor in communication with a memory.

Memory 604 is provided in computing device 600 for access by processor 602 , suitable for storing instructions for execution by the process, and located separately from processor 602 , and/or its It may be any suitable processor-readable storage medium integrated with the processor, such as random access memory (RAM), read-only memory (ROM), electrical erasable read-only memory (EEPROM), flash memory, and the like. Memory 604 may store software executable on computing device 600 by processor 602 , and includes an operating system 608 , one or more applications 610 , and associated data 612 . Application 610 may be used to implement game application 412 / 420 or game engine 404 . In some implementations, the application 610 , in response to execution by the processor 602 , determines whether the processor 602 changes the camera view, and thereafter changes the camera view accordingly, as described herein It may include a command to control or perform the performed operation.

Any of the software in memory 604 may alternatively be stored in any other suitable storage location or computer readable medium. In addition, memory 604 (and/or other attached storage device(s)) may store instructions and data used in the features described herein. Memory 604 and any other type of storage (magnetic disk, optical disk, magnetic tape, or other tangible media) may be considered "storage" or "storage device."

The I/O interface 606 may provide functionality that enables the computing device 600 to interface with other systems and devices. For example, network communication devices, storage devices, and input/output devices may communicate with computing device 600 via I/O interface 606 . In some implementations, I/O interface 606 is an input device (keyboard, pointing device, touchscreen, microphone, camera, scanner, etc.), collectively shown as at least one audio/video input/output device 614 . and/or an interface device including an output device (display device, speaker device, printer, motor, etc.).

Audio/video input/output devices 614 include audio input devices (eg, microphones, etc.), audio output devices (eg, speakers, headphones, etc.) and/or display devices that may be used to receive audio messages as inputs. , which can be used to provide graphical and visual output, such as the example camera view described above.

For convenience of explanation, FIG. 6 shows one block for each of the processor 602 , the memory 604 , the I/O interface 606 , and the application 610 . These blocks may represent one or more processors or processing circuits, operating systems, memory, I/O interfaces, applications, and/or software modules. In other implementations, device 600 may not have all of the components shown, and/or may have other elements that include other types of elements instead of or in addition to those shown herein.

User devices may also implement and/or use features described herein. An example user device may be a computer device that includes some similar components to computing device 600 , such as processor(s) 602 , memory 604 , and I/O interface 606 . An operating system, software and applications suitable for the client device may be provided in memory and used by the processor. I/O interfaces for client devices include network communication devices, as well as input and output devices, such as a microphone for capturing sound, a camera for capturing images or video, an audio speaker device for outputting sound, images or video It may be connected to a display device for outputting , or other output devices. For example, a display device within audio/video input/output device 614 may be coupled to (or included) with device 600 to display images pre- and post-processing as described herein. wherein such display device includes any suitable display device, such as an LCD, LED or plasma display screen, CRT, television, monitor, touchscreen, 3-D display screen, projector, or other visual display device. can do. Some implementations may provide audio output devices, such as speech output or synthesis to speak text.

One or more methods (eg, method 500 ) described herein may be implemented by computer program instructions or code that may be executed on a computer. For example, the code may be implemented by one or more digital processors (eg, microprocessors or other processing circuitry) and may be magnetic, including non-transitory computer-readable media (eg, storage media) such as semiconductors or solid state memory. , optical, electromagnetic or semiconductor storage media, magnetic tape, removable computer diskette, random access memory (RAM), read-only memory (ROM), flash memory, rigid magnetic disk, optical disk, may be stored in a computer program product, including a solid state memory drive and the like. The program instructions may be included and provided in an electronic signal, for example, in the form of software as a service (SaaS) delivered from a server (eg, a distributed system and/or a cloud computing system). Alternatively, one or more methods may be implemented in hardware (such as logic gates), or a combination of hardware and software. Exemplary hardware may be a programmable processor (eg, a field-programmable gate array (FPGA), a complex programmable logic device), a general-purpose processor, a graphics processor, an application specific integrated circuit (ASIC), or the like. One or more methods may be performed as part or component of an application running on a system, or as an application or software running in conjunction with other applications and operating systems.

One or more methods described herein can be implemented as a standalone program that can run on any type of computing device, a program running on a web browser, a mobile computing device (e.g., a cell phone, smart phone, tablet computer, wearable device) Wristwatches, armbands, jewelry, hats, goggles, eyeglasses, etc.), laptop computers, etc.) may run in a mobile application ("App"). In one example, a client/server architecture may be used, eg, a mobile computing device (as a client device) sends user input data to a server device and final output data for output (eg, for display) from the server. receive In another example, all calculations may be performed within a mobile app (and/or other app) of the mobile computing device. In another example, the computation may be split between the mobile computing device and one or more server devices.

Although the description has been described in terms of its specific implementation, this specific implementation is illustrative only and not restrictive. Concepts described in the examples may be applied to other examples and implementations.

Note that the functional blocks, operations, features, methods, apparatus, and systems described in this disclosure may be integrated or divided into different combinations of systems, apparatuses, and functional blocks, as known to those skilled in the art. Any suitable programming language and programming technique may be used to implement the routines of the particular implementation. Different programming techniques may be used, such as procedural or object-oriented. A routine may execute on a single processing unit or on multiple processors. Although steps, acts, or calculations may be presented in a particular order, the order may be changed in different particular implementations. In some implementations, a plurality of steps or actions shown sequentially herein may be performed concurrently.

Claims (20)

A method for changing a camera view of a rendered three-dimensional (3D) world in an electronic game, the method comprising:
determining a speed and direction of traversal of a first graphical object rendered in the 3D world;
identifying a second graphical object located along the direction of traversing;
determining whether the second graphical object is occluding the first graphical object in a current camera view by at least a threshold level during traversal of the first graphical object along the direction of traversing;
In response to determining that occlusion of the first graphical object by the second graphical object exceeds at least the threshold level, by moving the camera view forward toward the first graphical object, the second graphical object changing the current camera view of the first graphic object to avoid occlusion by the graphic object; and
in response to determining that occlusion by the second graphical object is below the threshold level, maintaining the current camera view;
including,
If the second graphic object is at least a translucent graphic object that can see the first graphic object in the current camera view, occlusion by the second graphic object is less than the threshold level, changing the camera view how to do it. According to claim 1,
wherein the first graphical object comprises an avatar associated with a player of the electronic game, and wherein the speed and direction of traversing of the first graphical object is controllable by the player. According to claim 1,
wherein the threshold level is associated with an amount of a profile of the first graphical object that is occluded by the second graphical object. According to claim 1,
wherein the threshold level is associated with a duration associated with the speed of the traversing over which the profile of the first graphical object is occluded by the second graphical object. According to claim 1,
After moving the camera view forward towards the first graphic object to avoid occlusion by the second graphic object, the first graphic object passes through the second graphic object along the direction of traversal. in response, moving the camera view back away from the first graphical object. According to claim 1,
a third graphical object positioned along the direction of traversal while the first graphical object is positioned behind the second graphical object or immediately behind the second graphical object and occludes the first graphical object by at least the threshold level in response to identifying a, maintaining the camera view moved forward towards the first graphical object. According to claim 1,
wherein the at least translucent graphic object through which the first graphic object is visible in the current camera view comprises a transparent window through which the first graphic object is visible. A non-transitory computer-readable medium having stored thereon instructions that, in response to execution by a processor, cause the processor to control or perform performance of an operation, the operation comprising:
determining a speed and direction of traversal of a rendered first graphical object in the three-dimensional (3D) world of the electronic game;
identifying a second graphical object located along the direction of traversing;
determining whether the second graphical object occludes the first graphical object in a current camera view by at least a threshold level during traversal of the first graphical object along the direction of traversal;
in response to determining that occlusion of the first graphical object by the second graphical object exceeds at least the threshold level, by moving the camera view forward toward the first graphical object, changing the current camera view of the first graphical object to avoid occlusion; and
in response to determining that occlusion by the second graphical object is below the threshold level, maintaining the current camera view.
includes
occlusion by the second graphical object is less than the threshold level, if the second graphical object is at least a translucent graphical object that makes the first graphical object visible in the current camera view possible medium 9. The method of claim 8,
wherein the first graphical object comprises an avatar associated with a player of the electronic game, and wherein the speed and direction of traversing of the first graphical object is controllable by the player. 9. The method of claim 8,
and the threshold level is associated with an amount of a profile of the first graphical object that is occluded by the second graphical object. 9. The method of claim 8,
and the threshold level is associated with a duration associated with the speed of the traversing over which the profile of the first graphical object is occluded by the second graphical object. 9. The method of claim 8,
The operation is performed by moving the camera view forward toward the first graphic object to avoid occlusion by the second graphic object, and then the first graphic object moves the second graphic object along the direction of the traversal. responsive to passing through, further comprising moving the camera view back away from the first graphical object. 9. The method of claim 8,
The operation comprises a second graphical object positioned along the direction of traversal while the first graphical object is positioned behind the second graphical object or immediately behind the second graphical object and occluded the first graphical object by at least the threshold level. 3 in response to identification of the graphical object, maintaining the camera view moved forward towards the first graphical object. 9. The method of claim 8,
wherein the at least translucent graphical object through which the first graphical object is visible in the current camera view comprises a transparent window through which the first graphical object is visible. As a device,
user interface; and
a processor coupled to a memory having the user interface and a stored game application
including,
the game application, in response to execution by the processor, causes the processor to display a camera view of a three-dimensional (3D) world of an electronic game on the user interface, the game application causing the processor to: further executable by the processor to control or perform the operation, the operation comprising:
determining a speed and direction of traversal of a rendered first graphical object in the 3D world;
identifying a second graphical object located along the direction of traversing;
determining whether the second graphical object occludes the first graphical object in a current camera view by at least a threshold level during traversal of the first graphical object along the direction of traversal;
in response to determining that occlusion of the first graphical object by the second graphical object exceeds at least the threshold level, by moving the camera view forward toward the first graphical object, changing the current camera view of the first graphical object to avoid occlusion; and
in response to determining that occlusion by the second graphical object is below the threshold level, maintaining the current camera view.
including,
If the second graphic object is at least a translucent graphic object that can see the first graphic object in the current camera view, occlusion by the second graphic object is less than the threshold level. 16. The method of claim 15,
wherein the first graphical object comprises an avatar associated with a player of the electronic game, and wherein the speed and direction of traversing of the first graphical object is controllable by the player. 16. The method of claim 15,
and the threshold level is associated with an amount of a profile of the first graphical object that is occluded by the second graphical object. 16. The method of claim 15,
wherein the threshold level is associated with a duration associated with the speed of the traversal over which the profile of the first graphical object is occluded by the second graphical object. 16. The method of claim 15,
After moving the camera view forward towards the first graphic object to avoid occlusion by the second graphic object, the game application causes the processor to:
by the processor, in response to the first graphical object passing the second graphical object along the direction of the traversal, to control or perform an action of moving the camera view back away from the first graphical object; The more feasible one, the device. 16. The method of claim 15,
The game application causes the processor to
a third graphical object positioned along the direction of traversal while the first graphical object is positioned behind the second graphical object or immediately behind the second graphical object and occludes the first graphical object by at least the threshold level responsive to the identification of: control or perform performing of maintaining the camera view moved forward towards the first graphical object.

Images