Visual identification control method, electronic equipment and readable storage medium

Abstract

The invention discloses a visual identification control method, which comprises the following steps: controlling a virtual camera in a game scene to perform visual angle rotation in response to an adjustment operation for a game visual angle; determining a current view cone of the virtual camera in response to the situation that the view angle rotation is limited by a system; if a virtual object exists in the current view cone and the virtual object is not located on the sight line reference axis of the current view cone, determining a target virtual object located in a judgment range from the virtual object; and controlling a visual identifier in the graphical user interface to generate directional offset so as to point to the target virtual object. By means of the method, when rotation of the visual angle of a player is limited, the visual identification can automatically deviate to point to the target, rapid positioning is achieved to avoid repeated movement, and game operation convenience and experience are improved.

Description

Technical Field

[0001] This disclosure relates to the field of computers, and more specifically to a visual identification control method, an electronic device, and a computer-readable storage medium. Background Technology

[0002] In simulation games, visual markers such as crosshairs are often used to assist players in aiming and interacting. Players can move the crosshair by adjusting the game's viewpoint to select virtual objects in the scene, thus achieving precise positioning.

[0003] However, when the camera cannot continue to rotate due to system limitations, such as reaching the pitch angle limit, the target may be outside the interaction range, making it difficult for the player to select it. This requires frequent adjustments to the virtual character's position, affecting the gaming experience and operational efficiency. Summary of the Invention

[0004] This disclosure provides a visual signage control method, program product, and electronic device to at least partially solve the aforementioned problems existing in the related art.

[0005] According to a first aspect of this disclosure, a visual identifier control method is provided, the method comprising: controlling a virtual camera in a game scene to rotate its view in response to an adjustment operation for a game view; determining the current view frustum of the virtual camera in response to a system restriction on the view rotation; if a virtual object exists within the current view frustum and the virtual object is not located on the line-of-sight reference axis of the current view frustum, determining a target virtual object located within a determination range from the virtual objects; and controlling a visual identifier in a graphical user interface to generate a directional offset to point to the target virtual object.

[0006] According to a second aspect of this disclosure, an electronic device is provided, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform the method of the first aspect and possible implementations thereof by executing the executable instructions.

[0007] According to a third aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the method of the first aspect described above and possible implementations thereof.

[0008] A visual identifier control method in at least one embodiment of this disclosure includes: controlling a virtual camera in a game scene to rotate its viewpoint in response to an adjustment operation for the game's viewing angle; determining the current viewing frustum of the virtual camera in response to a system restriction on the viewpoint rotation; identifying a target virtual object within a defined range from the virtual objects if a virtual object exists within the current viewing frustum and is not located on the line-of-sight reference axis of the current viewing frustum; and controlling a visual identifier in the graphical user interface to generate a directional offset to point to the target virtual object. In this way, when the player's viewpoint rotation is restricted, the visual identifier can automatically offset to point to the target, quickly locating it to avoid repeated movement and improving the convenience and experience of game operation. Attached Figure Description

[0009] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments of this disclosure will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a schematic diagram of an example system for implementing a visual signage control method according to an embodiment of the present disclosure;

[0011] Figure 2 A flowchart illustrating an example of a visual identity control method provided in an embodiment of this disclosure; Figure 3 This is a schematic diagram of a virtual camera shooting example provided in an embodiment of this disclosure; Figure 4a A schematic diagram of an example graphical user interface provided for an embodiment of this disclosure; Figure 4b A schematic diagram of an example graphical user interface provided for an embodiment of this disclosure; Figure 5 This disclosure provides a structural block diagram of an electronic device for implementing a visual identification control method. Detailed Implementation

[0012] Numerous specific details are set forth in the following description to provide a full understanding of this disclosure. However, this disclosure can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this disclosure. Therefore, this disclosure is not limited to the specific implementations disclosed below.

[0013] It should be noted that the terms "first," "second," "third," etc., in the claims, specification, and drawings of this disclosure are used to distinguish similar objects and are not used to describe a specific order or sequence. Such data are interchangeable where appropriate so that the embodiments of this disclosure described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising," "having," and their variations are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0014] It should be understood that in the embodiments of this disclosure, "at least one" refers to one or more, "several" refers to one or more, and "more than" refers to two or more. "And / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "Containing A, B, and / or C" means containing any one, two, or three of A, B, and C.

[0015] It should be understood that in the embodiments of this disclosure, "B corresponding to A", "B corresponding to A", "A corresponds to B", or "B corresponds to A" means that B is associated with A, and B can be determined based on A. Determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0016] Based on the problems described above, embodiments of this disclosure provide a visual signage control method, an electronic device, and a computer-readable storage medium.

[0017] The visual identification control method provided in this disclosure can be executed by an electronic device, which can be a terminal or a server. The terminal can be a smartphone, tablet, laptop, or other similar device. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can be hardware or software. When the server is hardware, it can be implemented as a distributed server cluster composed of multiple servers or as a single server. When the server is software, it can be implemented as multiple software programs or software modules (e.g., software or software modules used to provide distributed services) or as a single software program or software module. This disclosure does not specifically limit the implementation in this regard.

[0018] In one alternative embodiment, when the visual identification control method is run on a terminal device, the terminal device stores a game application and a virtual game scene. The terminal device interacts with the player through a graphical user interface (GUI). The terminal device can provide the GUI to the player in various ways, such as rendering it on the terminal device's display screen or presenting the GUI through holographic projection.

[0019] In an optional embodiment, when the visual identifier control method runs on a server, it can be implemented and executed based on a cloud gaming system. A cloud gaming system refers to a gaming method based on cloud computing. A cloud gaming system includes a server and client devices. The main body running the game application and the main body presenting the game screen are separate. The storage and operation of the visual identifier control method are completed on the server. The game screen presentation is completed on the client, which is mainly used for receiving and sending game data and presenting the game screen. For example, the client can be a display device with data transmission capabilities located close to the player, such as a mobile terminal, television, computer, PDA, personal digital assistant, head-mounted display device, etc. However, the terminal device for processing game data is the server in the cloud. During gameplay, the player operates the client to send commands to the server. The server controls the game operation according to the commands, encodes and compresses game screen data, returns it to the client via the network, and finally, the client decodes and outputs the game screen.

[0020] It should be noted that, in this embodiment of the disclosure, the executing entity of the visual identification control method can be a terminal device or a server. The terminal device can be a local terminal device or a client device in the aforementioned cloud gaming. This embodiment of the disclosure does not limit the type of executing entity.

[0021] For example, in conjunction with the above description, Figure 1 This disclosure illustrates a game system 1000 for implementing a visual identifier control method. The game system 1000 may include at least one terminal 1001, at least one server 1002, at least one database 1003, and a network. The terminal 1001 held by the player can connect to servers of different games via the network. The terminal is any device with computing hardware capable of supporting and executing software applications corresponding to the game.

[0022] In the aforementioned game system 1000, terminal 1001 is used to install and run the game application. In some cases, the game application may not need to be pre-installed on terminal 1001, and players can directly access the game through a browser or other client. Players log in to the game application using their registered game account to control the virtual character corresponding to that account and participate in the game. When a player logs in to the game application, terminal 1001 sends a login request to server 1002. Server 1002 verifies the game account used by the player and determines the game mechanism corresponding to the game account based on the login request. If the verification is successful, a login success notification is returned to terminal 1001. During the player's participation in the game through the game application, terminal 1001 and server 1002 exchange data. Terminal 1001 sends various information to server 1002. Server 1002 determines the display data of terminal 1001 based on the stored game mechanism (such as the visual identifier control method provided in this disclosure) and the received information, and sends the display data to terminal 1001 so that terminal 1001 can display the display data sent by server 1002 to the player.

[0023] In possible application scenarios, different terminals 1001 may be served by different servers 1002. Therefore, in order to distinguish the servers 1002 corresponding to different game terminals 1001, the embodiments of this disclosure will use the terms "first" and "second" to describe them. In fact, the servers 1002 corresponding to different game terminals 1001 can be the same server 1002. Therefore, without distinguishing between "first" and "second", it can be understood that the terminals 1001 corresponding to virtual characters in the same game scene are served by the same server 1002.

[0024] Furthermore, when the game system 1000 includes multiple terminals, multiple servers, and multiple networks, different terminals can connect to each other through different networks and servers. The network can be a wireless network or a wired network; for example, wireless networks include Wi-Fi, LAN, cellular networks, 2G, 3G, 4G, and 5G networks. Additionally, different terminals can also connect to other terminals or servers using their own Bluetooth networks or hotspot networks. Moreover, the game system 1000 can include multiple databases, which are coupled to different servers, and can continuously store game-related information in the databases as different players engage in multiplayer online gaming.

[0025] It should be noted that, Figure 1 The game system diagram shown is merely an example. The game system 1000 described in this disclosure is intended to more clearly illustrate the technical solutions of this disclosure and does not constitute a limitation on the technical solutions provided in this disclosure. As those skilled in the art will know, with the evolution of game systems and the emergence of new business scenarios, the technical solutions provided in this disclosure are also applicable to similar technical problems.

[0026] It should be noted that the operations described in the subsequent detailed introduction of the visual identification control method provided in this disclosure can all be considered as operations performed by the player using their fingers or controlling a medium such as a mouse, keyboard, or stylus. The specific medium used can be determined based on the type of electronic device. For example, when the electronic device is a touchscreen device such as a mobile phone, tablet, or game console, the player can operate the touchscreen using any suitable object or accessory such as a finger or stylus. When the terminal device is a non-touchscreen terminal device such as a desktop computer or laptop, the player can operate it using external devices such as a mouse or keyboard.

[0027] It should be noted that in this embodiment, there is no restriction on whether the terminal device providing the graphical user interface is placed horizontally or vertically; that is, there is no specific restriction on whether the virtual game is a landscape game or a portrait game. This embodiment uses a landscape virtual game and a horizontally placed terminal device as an example for the solution description. However, this does not mean that the visual identifier control method provided in this disclosure is not applicable to portrait games. The visual identifier control method provided in this disclosure is applicable to both landscape and portrait games; that is, the operation methods and corresponding game logic set in the virtual game are consistent in both landscape and portrait games, with only minor differences in the layout of interface elements in the graphical user interface.

[0028] The technical solutions of this disclosure will be described in detail below through specific embodiments. It should be noted that the subsequent descriptions will primarily use mobile touch-screen games as an example. The following specific embodiments can be combined with each other, and similar or identical concepts or processes may not be repeated in some embodiments.

[0029] like Figure 2 As shown, Figure 2 This is an example flowchart of a visual identifier control method provided in an embodiment of this disclosure. It should be noted that the steps shown may be performed in a logical order different from that shown in the flowchart. The method may include the following steps: Step S210: In response to the system restricting the viewpoint rotation, determine the current view frustum of the virtual camera; Step S230: If a virtual object exists within the current visual cone and the virtual object is not located on the line-of-sight reference axis of the current visual cone, determine the target virtual object within the judgment range from the virtual objects; Step S250: Control the visual identifiers in the graphical user interface to generate a directional offset so as to point to the target virtual object.

[0030] In this way, when players are unable to further adjust the view due to system limitations, the system can automatically guide the visual marker to the target within the edge area of ​​the view, reducing the need for players to repeatedly move their character to select a target, thus improving interaction efficiency and the smoothness of the game experience.

[0031] For example, in a game scenario where a player controls a virtual character to collect resources, when the player tries to aim at a fruit high up but the camera has reached its maximum elevation angle, the system detects that the viewpoint rotation is limited. At this point, the system calculates the field of view (FRP) space visible to the current camera and finds that although the fruit is within the FRP, it is not precisely on the baseline in the center of the screen. The system then searches within a preset angle range extending upwards from the baseline, confirming that the fruit is within this range and identifying it as the target. Immediately afterward, the crosshair in the center of the screen automatically shifts slightly upwards, accurately pointing at the fruit, allowing the player to select and interact with it without moving the character.

[0032] Among them, the view rotation being restricted by the system means that the virtual camera cannot continue to rotate in a certain direction under the player's input operation. This is usually due to the physical boundaries set by the game or the design to prevent view penetration. Its function is to trigger subsequent compensatory aiming assistance logic.

[0033] Optionally, a common scenario where viewpoint rotation is restricted by the system is when the virtual camera reaches a preset maximum or minimum angle in the pitch direction (i.e., vertical rotation). In most first-person or third-person games, to prevent unreasonable visual effects such as clipping or inversion, a pitch angle rotation boundary is usually set for the camera. When the player continuously tilts their head up or down, causing the camera's expected pitch angle to reach this boundary, the system will prevent further viewpoint rotation. At this point, even if the player continues to input an upward command, the camera will remain at the extreme angle. This restriction directly triggers the analysis of the "current view frustum" and the subsequent process of finding the target within the "judgment range," thus restoring interaction opportunities that might have been lost due to viewpoint limitations to the player through directional shifts in visual markers, ensuring the continuity of interaction.

[0034] Optionally, the system can also restrict viewpoint rotation by setting boundaries in the horizontal direction. For example, in certain game segments with fixed scenes or specific plot developments, the player's horizontal viewpoint rotation range may be locked by the system to guide the player's gaze or maintain narrative rhythm. When the player attempts to rotate the viewpoint left or right to this locked boundary, further rotation requests will be ignored or gently resisted by the system. In this case, if the system determines that an important virtual object (such as a key quest item or dialogue character) is located at the edge of the current restricted viewpoint, it can also initiate a judgment process. By determining the current view frustum and calculating whether the target is within the horizontal judgment range based on the viewpoint reference axis, the system controls the visual marker to make a horizontal directional shift, helping the player to easily locate and select targets even in a restricted viewpoint environment, avoiding interaction difficulties caused by forced viewpoint locking.

[0035] Optionally, the system's restrictions on viewpoint rotation can be dynamic and contextual, rather than fixed mechanical boundaries. For example, when a virtual character is in a narrow passage, a specific combat stance, or affected by environmental effects, the system may temporarily reduce the camera's rotation range based on real-time physics simulation or game status. This dynamic restriction also triggers a method. In response to this contextual rotation restriction, the system calculates the current view frustum under dynamic changes in real time. If an interactive object not on the line of sight is found within this view frustum, such as an object behind or to the side that is difficult to observe directly due to viewpoint limitations, the system will search for the target within a judgment range intelligently adjusted according to the current dynamic boundaries. Once the target virtual object is identified, it drives the visual identifier to generate a corresponding directional shift. This dynamic adaptation mechanism greatly enhances the game's interactivity and immersion in various complex situations.

[0036] The current view frustum is the spatial region that the virtual camera can observe in the 3D game scene. Its shape is similar to a truncated pyramid, defining the range of sources of visible content on the screen. Figure 3 Figure 3 illustrates an example of virtual camera shooting provided in this embodiment of the present disclosure. A virtual camera 302 is set within a game scene 301. The game scene 301 includes a virtual character 303 and virtual scene elements 304. The virtual camera 302 can be positioned above and behind the virtual character 303. The game scene is captured by the virtual camera 302, and the game screen displayed on the terminal device's monitor is the scene content included within the shooting range of the virtual camera 302. The shooting range of the virtual camera 302 is... Figure 3 The range encompassed by the central visual cone AOB.

[0037] Optionally, the current view frustum is a core concept in 3D graphics. It is defined by the camera's position, orientation, field of view, and near and far clipping planes, forming a frustum-shaped visual space. In this method, accurately determining the current view frustum is a fundamental step in executing subsequent logic when view rotation is restricted by the system. This view frustum represents the entire potential area that the player can directly "see" at that moment without moving the camera. The system obtains the six plane equations constituting this view frustum through a graphical interface or internal mathematical calculations, enabling it to accurately determine whether the 3D coordinates of any virtual object lie within this space. This step is crucial because it first filters out completely irrelevant objects located behind the player or outside the player's field of view, ensuring that subsequent search operations focus only on candidates that theoretically might enter the player's field of view. This improves computational efficiency and accuracy and provides spatial context for further precise filtering of the "judgment range."

[0038] Optionally, determining the current view frustum requires comprehensive consideration of all spatial parameters of the camera. Specifically, the system calculates the orientation of the four sides of the view frustum based on the virtual camera's position in the world coordinate system, the direction vector its lens is pointing (i.e., the forward vector), and the size of the vertical and horizontal field of view. Simultaneously, based on preset nearest and farthest visible distances (near clipping plane and far clipping plane), the positions of the front and rear sections of the view frustum are determined. This series of parameters collectively "cuts out" a specific subspace within the game world. When the viewpoint is limited, this view frustum is fixed, but the relative relationship between its internal objects and the viewing reference axis becomes crucial. The system detects the visibility of virtual objects by substituting their bounding boxes or keypoint coordinates into the view frustum plane equation. This provides the necessary three-dimensional spatial information foundation for subsequent determinations of whether virtual objects are "not located on the viewing reference axis."

[0039] Optionally, to improve performance, a hierarchical optimization strategy can be employed for determining the current view frustum and detecting objects. The system does not always perform precise view frustum detection on all objects in the scene. Instead, it may first use a spatial partitioning data structure (such as a quadtree, octree, or scene graph) for a coarse screening, quickly eliminating sets of objects clearly located outside the large regions of the view frustum. For objects that, after the initial screening, may be located near or inside the view frustum, a precise view frustum plane intersection test is then performed. Furthermore, while the calculation of the current view frustum may be updated every frame, the system can cache the view frustum parameters at the moment when view rotation is restricted for subsequent consecutive decision processes, avoiding redundant calculations. This fine-grained management ensures that the method can run smoothly and in real-time, even in complex game scenes containing a large number of interactive objects, providing players with immediate, lag-free aiming assistance feedback.

[0040] The line-of-sight reference axis is an infinitely extending ray emanating from the center of the virtual camera lens and passing through the center of the screen, representing the player's precise aiming direction without deviation. As shown in Figure 3, the ray OM is the line-of-sight reference axis.

[0041] Optionally, virtual scene element 304 includes virtual fruit 3041 and virtual fruit 3042, such as Figure 3 As shown, if the virtual fruit 3042 is located on the line-of-sight reference axis (ray OM), the player can directly interact with the virtual fruit 3042 (e.g., pick it). If the virtual fruit 3041 is not located on the line-of-sight reference axis (ray OM), the player needs to adjust the orientation of the virtual camera by adjusting the game view (e.g., adjusting the virtual camera's orientation upwards) so that the line-of-sight reference axis (ray OM) passes through the virtual fruit 3041, thus enabling the player to interact with the virtual fruit 3041; or by moving the virtual character 303 (e.g., controlling the virtual character 303 to move to the right) so that the line-of-sight reference axis (ray OM) passes through the virtual fruit 3041, thus enabling the player to interact with the virtual fruit 3041.

[0042] Optionally, the line-of-sight reference axis is the core reference line for determining spatial relationships in the method. Essentially, it is the representation of the forward axis in the virtual camera's local coordinate system in world space. This ray originates at the camera's projection center, passes straight through the center point of the screen's pixel coordinates, and points deep into the 3D game world. During normal player operation, visual markers (such as a crosshair) are typically fixed at the intersection of this axis and the screen. Figure 4aAs shown in 4a, a schematic diagram of a virtual camera shooting example provided in this embodiment of the present disclosure is provided. The graphical user interface 400 displays the game scene 401 within the current field of view range of the virtual camera. The game scene 401 includes virtual scene elements 404, which include virtual fruits 4041 and virtual fruits 4042. The graphical user interface also includes a visual identifier 410, which is used to indicate the reference axis of the virtual camera's line of sight. By aligning the visual identifier 410 with the scene element in the game scene, the scene element in the game scene can be selected.

[0043] Optionally, when viewpoint rotation is restricted, the positions of all virtual objects within the current view frustum will be calculated with respect to this viewpoint reference axis, resulting in an angular deviation. If an object happens to be on this axis, the deviation is zero, and it can be selected directly without compensation. This method pays particular attention to objects that are "not on" this axis, i.e., they are visible but not centered on the screen (e.g., ...). Figure 4a The virtual fruit 4042). At this time, the line of sight reference axis serves as the reference for calculating the "judgment range". For example, the axis can be used as the center to offset and open an angle in the direction where the view rotation is restricted (such as directly above), forming a fan-shaped or cone-shaped judgment area, which provides a precise spatial basis for subsequent target selection.

[0044] Optionally, accurate acquisition of the line-of-sight reference axis is crucial for achieving stable directional offset. In the graphics rendering pipeline, the system can use the inverse transformation of the camera's view-projection matrix to back-calculate the normalized device coordinates (e.g., (0,0)) of the screen center point back into world space, thereby obtaining two points on the line-of-sight reference axis (near clipping plane and far clipping plane), and thus determining the direction and origin of the ray. This axis is the ideal aiming line in a static view. When the system detects a target within the detection range, it needs to calculate the degree to which the target deviates from this reference axis. Typically, the system calculates the direction vector from the camera position to the target position, performs a dot product operation with the direction vector of the line-of-sight reference axis, obtains the cosine of the angle, and then converts it into an angle deviation. This angle deviation value will be directly used for subsequent target priority ranking (e.g., selecting the target with the smallest angle) and calculating the direction and distance that the visual identifier needs to be offset, ensuring that the offset visual identifier can accurately "point" to the target.

[0045] Optionally, the concept of a line-of-sight reference axis can be adaptively extended according to different interaction modes. For example, in some third-person over-the-shoulder perspective games, the reference axis may not strictly originate from the camera, but rather be a ray-like line emanating from the player character's shoulder or weapon aiming point. Although the origin of calculation differs, its role in the methodology remains consistent: serving as a reference for determining whether a target is "directly facing" and calculating offset. Furthermore, in some games that support assisted aiming or target magnetization, the line-of-sight reference axis may be given a very narrow "effective width" or "conical error range," rather than an absolute mathematical ray. As long as the target falls within this tiny range, it can be considered "located" on the reference axis. However, in the method of this invention, the emphasis is on compensating by actively offsetting visual markers when the target is clearly not within this reference axis or core range. This differs from the approach of passively widening the judgment range, providing a more proactive and explicit interactive guidance.

[0046] The judgment range is a spatial area defined by the line-of-sight reference axis in the direction where the viewpoint rotation is restricted. It is used to filter targets that are currently visible but not directly in front of the viewer.

[0047] Optionally, the decision range is a crucial spatial filter whose design directly determines which off-center targets the system will consider when the field of view is limited. This range is typically a three-dimensional spatial area extending from the line-of-sight reference axis towards the direction in which the camera rotation is restricted (e.g., upwards when the elevation angle is at its maximum). Its shape can be conical, fan-shaped, or a flat box with thickness and angle. The core purpose of defining this range is to enable the system to intelligently infer the target the player might want to interact with when the player intends to look in a certain direction but is prevented by the system, and to search only within a reasonably nearby space, avoiding incorrectly including objects on the other side of the screen or irrelevant objects as candidates, thereby ensuring the accuracy of assisted aiming and the match between the player's intention and the target. The parameters of this range (such as the angle of view and the range length) are usually configurable, allowing game designers to adjust them according to different gameplay requirements.

[0048] Optionally, one specific implementation of the judgment range is to define an angular tolerance range formed by offsetting a fixed angle from the line-of-sight reference axis. For example, when the player's camera elevation angle reaches its upper limit, the system can set an angular range extending 10 degrees upward from the line-of-sight reference axis as the judgment range. All virtual objects located within the current view frustum, whose line of connection to the camera forms an angle less than or equal to 10 degrees with the line-of-sight reference axis, are considered to be within this judgment range. This angle definition method is intuitive and computationally efficient. The system can quickly calculate the angular deviation of each object using vector dot product and inverse trigonometric functions. The setting of this range needs to balance sensitivity and accuracy: a range that is too small may fail to cover nearby targets, while a range that is too large may introduce too many interference terms, affecting the accuracy of target determination. It is an important bridge connecting the coarse screening of the "current view frustum" and the precise positioning of the "target virtual object".

[0049] Optionally, the determination of the judgment range can be more intelligent, rather than a simple fixed angle. It can be an adaptive area that dynamically adjusts according to the game context. For example, the size or shape of the judgment range can dynamically change based on the type and importance of the target object, the player's current task status, or the complexity of the environment. In areas with dense targets, the system can automatically narrow the judgment range to improve selection accuracy; while when targets are sparse or there are key task targets, the range can be appropriately expanded to ensure that important interaction opportunities are not missed. In addition, the judgment range can also be a reverse projection of the two-dimensional screen space into the three-dimensional game world. The system can define a two-dimensional pixel radius around the center point of the screen and project it back into three-dimensional space to form a subspace within a view frustum. Regardless of the mathematical definition used, the essential function of the judgment range is to establish a reasonable and limited "attention focus area" in the special context of limited viewpoint, so that the system's auxiliary behavior can closely match the player's potential intentions.

[0050] The target virtual object is a specific object determined from the virtual objects within the judgment range. It is the entity that the visual identifier will ultimately point to and is ready to accept player interaction.

[0051] Optionally, the target virtual object is the final interactive object obtained after multiple layers of spatial and logical filtering. Its determination process begins with all objects within the current view frustum, filtered by the condition of "not located on the viewing reference axis," and further narrowed down to a set of objects within the "determination range." When determining a unique or primary target from this set, the system requires a clear set of decision rules. A basic rule is the spatial nearest principle, which calculates the angular deviation or three-dimensional spatial distance between each object within the determination range and the viewing reference axis, and identifies the object with the smallest deviation or the closest distance as the target virtual object. For example... Figure 4aAs shown, neither virtual fruit 4041 nor virtual fruit 4042 is located on the line-of-sight reference axis (i.e., they do not coincide with visual marker 410). Therefore, virtual fruit 4041 with the smallest deviation is determined as the target virtual object. This method aligns with the player's intuitive intention to "attempt to aim at the target closest to the center of their line of sight." After determining the target, its three-dimensional coordinates are used to calculate its projection position in screen space, thereby driving the visual marker to make a directional shift. Accurately determining the target virtual object is the final step in ensuring that the entire compensation mechanism is effective and meets the player's expectations.

[0052] Optionally, an object attribute filtering mechanism can be introduced during the determination of the target virtual object. That is, not all geometric models within the decision range are considered candidates. The system can first check whether these virtual objects possess the "interactive" attribute tag, such as whether they are pickable items, attackable enemies, or talkative characters. Only objects with the corresponding interactive attributes will enter the final decision-making process. This step filters data through the game logic layer, avoiding the use of background decorations, impenetrable walls, etc., as targets, ensuring the effectiveness and practicality of the assistive function. For multiple qualified candidate objects, the aforementioned spatial relationship sorting (such as minimum angular deviation) can be used to determine the final target. This two-stage determination method of "attribute filtering + spatial sorting" improves the accuracy of interaction while also giving game designers greater control, allowing them to define which objects are eligible for this type of aiming assistance according to gameplay needs.

[0053] Optionally, the determination of the target virtual object can support a certain degree of player intervention and dynamic switching. For example, after determining an initial target, if the player continuously holds down the view adjustment button / button (even though the view can no longer be rotated), the system can interpret this as the player potentially being dissatisfied with the currently automatically selected target. In this case, the system can allow the player to dynamically adjust a "virtual" aiming tendency by slightly moving the input device (such as a small displacement of the joystick). Based on this tendency, the system recalculates and switches the target virtual object within the judgment range. This mechanism, without adding additional operation buttons, gives players the ability to fine-tune on top of automatic assistance. The system dynamically updates the selection of the target virtual object in real time based on the relationship between the player's input vector and the direction vectors of each candidate object, allowing the directional offset of the visual identifier to dynamically adjust according to the player's intention, ultimately achieving more precise target locking that better matches the player's subjective wishes.

[0054] Among them, directional offset is the behavior of moving the visual markers (such as the crosshair) on the screen from the default center position to align with the projection position of the target virtual object on the screen. Figure 4b This is a schematic diagram of a virtual camera shooting example provided in an embodiment of this disclosure, as shown below. Figure 4b As shown, visual identity 410 is from Figure 4a The screen center position shown is moved to the screen position aligned with the virtual fruit 4041. After the movement, the visual identifier 410 is no longer located in the screen center.

[0055] Optionally, directional offset is the direct visual feedback presented to the player, representing the overall effect of the method. Once the target virtual object is determined, the system needs to calculate its precise projected coordinates in the two-dimensional screen space. This is achieved by transforming the target's three-dimensional world coordinates through the camera's view matrix and projection matrix, followed by perspective division. Subsequently, the system calculates the vector difference between this projected coordinate and the screen center (i.e., the default position of the visual identifier). This difference represents the amount and direction of the required offset. Controlling the visual identifier to generate a directional offset involves driving the UI system to translate the visual identifier's drawing position from the screen center to the calculated target projection position. This offset process must be instantaneous or accompanied by a smooth animation transition, resulting in the visual identifier "jumping" or "moving" onto the target, thus visually indicating "the system recommends this target for you," allowing the player to immediately confirm and interact.

[0056] Optionally, the directional offset can be implemented using a smooth animation transition rather than an abrupt jump to provide a better visual experience and conform to cognitive habits. After calculating the target projection position, the system does not immediately set the coordinates of the visual identifier to that position. Instead, it uses that position as the endpoint and the current coordinates as the starting point, performing interpolation motion over several frames. For example, linear interpolation, easing functions, or spring physics simulations can be used to calculate the midpoint of the visual identifier in each frame, allowing it to move smoothly and fluidly to the target point. This smooth movement has several benefits: First, it avoids abrupt visual jumps, reducing confusion or discomfort for players caused by sudden focus shifts; second, the animation process itself guides the player's gaze, allowing them to clearly track the movement trajectory of the crosshair, thus naturally shifting their attention to the new target; finally, it conforms to the general principles of user interface animation design, enhancing the overall quality of the product and the user experience.

[0057] Optionally, the magnitude and method of directional offset can be differentiated based on different game scenarios or target types. For example, for targets that are far away or of low importance, the offset can be scaled proportionally or capped to ensure that the visual identifier does not move too far from the edge of the screen; for critical mission targets, a larger offset magnitude can be allowed, even supplemented with effects such as highlighting or pulses to enhance the cues. Furthermore, the offset doesn't have to be a simple two-dimensional planar movement, but can incorporate perspective effects. For example, when the target has significant depth in three-dimensional space, the size or shape of the visual identifier can undergo slight changes during movement to simulate a sense of spatial depth. Another advanced implementation is "predictive offset," where, when the target is a moving object, the system not only calculates the projection of its current position but also calculates a lead time based on its speed and direction, causing the visual identifier to offset to a predicted hit position, further enhancing the practicality of assisted aiming in dynamic scenes. All these processes revolve around one core: making directional offset feedback more intelligent, natural, and effective.

[0058] In an optional implementation, the method further includes: determining the judgment range based on the line-of-sight reference axis.

[0059] In this way, determining the judgment range based on the line-of-sight reference axis ensures that the judgment range is directly related to the player's current visual focus direction, making the offset compensation of visual markers more accurate and intuitive, avoiding the blindness of the compensation range, and improving the efficiency and reliability of assisted positioning.

[0060] For example, in a first-person shooter game, when a player attempts to raise their gun to aim at an enemy on the top of a tall building, the camera's elevation angle reaches the system's maximum allowable limit. At this moment, the system uses the straight line extending directly in front of the camera as the line of sight reference axis, and uses this axis as the center or reference point to expand a fan-shaped spatial area upwards (i.e., in the direction where the viewpoint rotation is restricted) as the judgment range for subsequent searching for interactive targets.

[0061] In an optional implementation, the angular range generated by offsetting the line of sight reference axis by a preset distance angle along the direction where the rotation of the viewing angle is restricted is determined as the judgment range.

[0062] In this way, by offsetting the line of sight reference axis along the restricted direction of view rotation, the judgment range can be defined, which allows for precise expansion of the target judgment area when view rotation is restricted by the system. This helps visual markers to quickly point to the target virtual object, improving interaction efficiency and game experience.

[0063] For example, when the pitch rotation of the virtual camera reaches the system's preset rotation boundary and is restricted, the line-of-sight reference axis is offset by a preset angle, such as 15 degrees, in the pitch direction. The fan-shaped angle range generated by this offset is determined as the judgment range, and the target virtual object is searched within this range.

[0064] Among them, the direction in which the viewpoint rotation is restricted refers to the spatial orientation in which the virtual camera cannot continue to rotate under adjustment operations, and is used to indicate the direction in which the judgment range expands.

[0065] Optionally, the direction in which the viewpoint rotation is restricted can be the pitch direction. In 3D game scenes, virtual cameras typically have pitch rotation freedom, but for game design or performance considerations, the system presets boundary angles for pitch rotation. When a player attempts to exceed these boundaries by adjusting their controls, the virtual camera's pitch rotation is restricted, meaning it cannot continue to rotate upwards or downwards. In this case, the direction in which the viewpoint rotation is restricted is clearly the pitch direction, specifically, it can be restricted upwards or downwards. Determining this direction provides a benchmark for expanding the subsequent judgment range, enabling the compensation mechanism to search for target virtual objects along the correct spatial orientation. For example, when a player attempts to look up at a target at a high altitude, if the pitch rotation is restricted upwards, the judgment range will expand in the upward direction, thus covering areas that the viewpoint could not originally see directly. This direction definition ensures consistency between the compensation judgment and the viewpoint rotation restriction, avoiding target omissions due to directional misjudgment, while maintaining camera stability and reducing unpleasant sensations caused by viewpoint jitter.

[0066] Optionally, the direction in which the viewpoint rotation is restricted can also be horizontal. When the virtual camera rotates horizontally, it may also be limited by system-preset rotation boundaries. For example, in certain game scenarios, to prevent the player's viewpoint from penetrating walls or exceeding the map's boundaries, a horizontal rotation angle limit may be set. When horizontal rotation is restricted, the direction in which the viewpoint rotation is restricted is horizontal, which can be left or right. In this case, the scope of judgment will expand along the horizontal direction, allowing visual markers to shift to capture lateral target virtual objects. This design expands the applicability of the compensation mechanism, making it suitable not only for pitch scenes but also for situations where the horizontal direction is restricted, thus improving the flexibility of interaction. By explicitly defining the horizontal direction as the restricted direction, the system can accurately generate the corresponding angle range, ensuring the logical consistency and intuitiveness of target search.

[0067] Optionally, the direction in which the viewpoint rotation is restricted can be dynamically determined based on rotation boundaries. In some implementations, the virtual camera may be restricted on multiple rotation axes simultaneously, such as both pitch and horizontal rotation reaching their limits. In this case, the system can dynamically determine the dominant restricted direction based on the trend of the adjustment operation or the player's intention. For example, if the player mainly performs pitch adjustments and reaches the limit, the pitch direction is preferentially determined as the restricted direction; if the adjustment operation involves complex rotations, the dominant restricted direction can be calculated through vector analysis. This dynamic determination mechanism enhances the intelligence of the judgment range expansion, making the compensation judgment more consistent with the actual game situation. It ensures that even under complex rotation constraints, the judgment range can still shift along the most relevant direction, optimizing target acquisition accuracy while maintaining natural and smooth interaction.

[0068] The preset distance angle is a configurable angle value used to define the magnitude of the offset of the line of sight reference axis, thereby controlling the size of the judgment range.

[0069] Optionally, the preset distance angle can be a fixed value, pre-set by the game developers according to experience requirements. This fixed value simplifies system implementation and ensures the consistency and predictability of the judgment range. Developers determine a suitable angle value, such as 10 or 20 degrees, through testing and balancing. This value is sufficient to cover potential target areas near the viewpoint limit while avoiding misselection or visual interference caused by an excessively large range. The fixed preset distance angle is easy to configure and maintain, suitable for most game scenarios, and provides players with a stable compensation experience. In implementation, this value can be stored in the game configuration file, allowing for flexible adjustments in different game modes or updates, but remaining consistent throughout a single game session. This design balances performance and experience, making the calculation of the judgment range efficient and reliable.

[0070] Optionally, the preset distance angle can be a dynamic value, adjusted according to the game scene or player status. This dynamic adjustment mechanism enhances the adaptability and personalization of the compensation judgment. For example, in densely populated target areas, the system can automatically reduce the preset distance angle to narrow the judgment range and improve the accuracy of target selection; while in sparse areas, the angle can be increased to expand the search range. Furthermore, player skill level or device performance may also affect this angle value; for example, novice players may receive a larger angle to aid aiming. The implementation of dynamic values ​​relies on real-time data acquisition and processing, such as scene complexity analysis or player behavior pattern recognition. This design enhances the intelligence and immersion of the gaming experience, making the compensation mechanism more aligned with actual needs and optimizing resource allocation and interaction effects.

[0071] Optionally, the preset distance angle can be adaptively calculated based on the attributes or distance of the target virtual object. Adaptive calculation associates the preset distance angle with target features, further enhancing the targeting of the judgment range. For example, for distant targets, the system can increase the angle to compensate for viewpoint deviation; for targets with high priority or special interactive attributes, the angle can be adjusted to ensure they are included in the judgment range. The calculation process may involve assessing the target's position, size, or interaction difficulty, dynamically generating angle values ​​through algorithms. This adaptability enhances the accuracy of the compensation mechanism, reduces interference from irrelevant targets, and ensures the selectability of key targets. It reflects the refinement of human-computer interaction design, improving player operational efficiency and satisfaction under limited viewpoints through data-driven optimization.

[0072] The angle range is the spatial area swept by the line of sight reference axis after being offset by a preset distance angle, which serves as the basis for determining whether the target virtual object can be selected.

[0073] Optionally, the angle range can be a fan-shaped region, starting from the line-of-sight reference axis and extending along the offset direction. The fan-shaped region is defined in 2D screen space or 3D scene projection, with its vertex located at the virtual camera position, the starting edge as the line-of-sight reference axis, and the ending edge as the offset axis; the angle between the two is equal to a preset distance angle. This fan-shaped region covers a continuous angular range in the direction of restricted viewpoint rotation, suitable for most third-person or first-person game scenarios. The simple geometry of the fan-shaped region facilitates quick calculation of whether a target virtual object is within it, allowing for filtering through angle comparison. This design ensures intuitive judgment range and computational efficiency, making the visual offset logic clear and controllable. Simultaneously, the fan-shaped region can be visually represented as a highlight or prompt area in the graphical user interface, enhancing the player's perception of the compensation mechanism.

[0074] Optionally, the angle range can be a conical region, suitable for target identification in 3D space. The conical region is defined with the virtual camera as the vertex, the view reference axis as the central axis, and a preset distance angle as the half-vertex angle, forming a 3D cone-shaped space. This region definition better aligns with the geometric characteristics of the 3D game world, comprehensively covering 3D space in directions with limited viewpoints. During identification, the system needs to calculate whether the target virtual object is located within this cone, which may involve detecting the spatial relationship between points and the cone. The conical region provides more accurate 3D target capture, especially suitable for scenes where targets are unevenly distributed in the depth direction. It expands the dimensionality of the identification range, allowing the compensation mechanism to work effectively in complex 3D environments, improving the realism and reliability of the interaction.

[0075] Optionally, the size and shape of the angle range can be adjusted according to changes in the preset distance angle to optimize target search accuracy. This adjustment mechanism allows the angle range to dynamically adapt to game requirements; for example, when the preset distance angle increases, the angle range expands accordingly, covering a wider area; when the angle decreases, the range shrinks, focusing on a narrower area. Furthermore, the shape can also be adjusted, such as changing from a fan shape to a rectangle or a custom polygon, to suit specific graphical user interfaces or interaction modes. This flexibility allows the judgment range to be customized for different scenarios or player preferences, balancing search breadth and accuracy. In implementation, the system can control the attributes of the angle range through parameterized configuration or real-time algorithms to ensure that compensation judgment is always optimized. This design reflects the configurability and adaptability of the interactive system, enhancing the personalization and efficiency of the overall gaming experience.

[0076] In an optional implementation, responding to the system limiting the viewpoint rotation includes: responding to the virtual camera's expected rotation angle during adjustment reaching a system-preset rotation boundary. Thus, by clearly defining the triggering condition for the system limiting the viewpoint rotation, the visual identifier offset mechanism is ensured to activate only when the virtual camera's rotation reaches the boundary, avoiding unnecessary interference and improving operational accuracy and the gaming experience.

[0077] For example, when a player attempts to raise the game's viewing angle further by swiping the screen, if the expected angle of elevation calculated by the virtual camera based on the swipe operation is already equal to the maximum angle of elevation set by the system, it is determined that the viewpoint rotation is restricted by the system, thereby triggering the subsequent visual marker offset process.

[0078] The expected rotation angle refers to the angle that the virtual camera intends to reach under the player's adjustment operation but has not yet been actually executed, and is used to determine whether the viewpoint rotation will be restricted by the system.

[0079] Optionally, the expected rotation angle can be calculated in real time based on the player's input operation vector and the current camera state. For example, on a touchscreen device, the player adjusts the viewing angle by swiping the screen with their finger. The system predicts the target angle the camera would rotate to if unrestricted, based on the distance, direction, and speed of the swipe, combined with the camera's current orientation and rotation sensitivity. This calculation process considers the continuity of the operation intention, ensuring a rapid response that meets the player's expectations. By predicting the rotation angle, the system can anticipate whether the viewpoint rotation will reach the boundary, thus smoothly triggering the limiting mechanism at the boundary, preventing the camera from suddenly stopping or shaking, and maintaining visual smoothness. In implementation, the expected rotation angle can be expressed as an increment of the pitch or horizontal angle and compared with the system's preset rotation boundary to determine whether the limiting condition has been met.

[0080] Optionally, the expected rotation angle can be dynamically adjusted based on the game context or player settings. For example, the camera's rotation sensitivity may vary in different game modes, resulting in different expected rotation angles for the same player actions. The system allows players to customize the rotation sensitivity, thus affecting the calculation of the expected rotation angle. Furthermore, in certain situations, such as aiming mode or running, the expected rotation angle may be scaled or limited to provide a more suitable control experience for the current gameplay. Dynamically adjusting the expected rotation angle allows the system to adapt to diverse player needs and game states, improving the flexibility and personalization of control. This adjustment mechanism ensures that the judgment of viewpoint rotation limitations is based not only on static boundaries but also on real-time context, thus providing more accurate and human-like interaction.

[0081] Optionally, the calculation of the expected rotation angle can incorporate historical operation data or predictive algorithms to improve accuracy. For example, the system can analyze the player's recent operation patterns, such as rotational inertia and trends, to optimize the prediction of the expected rotation angle. If the player continuously and rapidly rotates the viewpoint, the system may predict a larger rotation angle, and vice versa. Furthermore, interpolation or filtering algorithms can be used to smooth the input, reduce noise interference, and make the expected rotation angle more stable. Through advanced prediction, the system can identify potential limitations earlier, prepare for visual marker shifts in advance, and reduce perceived latency. This intelligent calculation method enhances the system's responsiveness and predictability, providing players with a more consistent experience near the operational boundaries.

[0082] The system's preset rotation boundary is the limit angle that the virtual camera is allowed to rotate in the pitch or horizontal direction, which is used to prevent excessive rotation of the viewpoint and trigger visual marker offset.

[0083] Optionally, the system's preset rotation boundaries can be configured as fixed or dynamic values ​​based on game design requirements. For example, in most games, the tilt angle rotation boundaries typically have upper and lower limits, such as 30 degrees upward and 60 degrees downward, to prevent players from seeing unreasonable perspectives. These boundary values ​​are preset during game development and stored in configuration files for easy adjustment. Dynamic boundaries may change according to game scene variations; for example, when a player enters a narrow space, the horizontal rotation boundary may temporarily shrink to avoid clipping or visual confusion. Preset rotation boundaries ensure a reasonable range of camera movement, maintaining visual consistency and immersion in the game world. When the expected rotation angle reaches these boundaries, the system triggers the limit, providing conditions for subsequent visual marker offsets.

[0084] Optionally, the system's preset rotation boundaries can be set hierarchically or regionally to adapt to complex game environments. For example, in open-world games, different areas may have different rotation boundaries; for instance, pitch restrictions are stricter inside caves, while restrictions are more lenient on plains. Hierarchical boundaries allow the system to dynamically switch preset values ​​based on the player's position. Furthermore, boundaries can be set independently for different camera modes, such as first-person and third-person modes having different rotation limits. This flexibility allows game designers to finely control viewpoint behavior, enhancing scene adaptability. Through intelligent boundary management, the system provides a diverse visual experience while maintaining core functional limitations, avoiding the operational inconvenience caused by a one-size-fits-all approach.

[0085] Optionally, the system's preset rotation limits can be linked to player assistance features or difficulty settings. For example, in assistance mode, the rotation limits may be widened, allowing for a greater range of viewpoint rotation, making it easier for players with mobility issues to aim at targets. Conversely, in high-difficulty modes, the limits may be stricter, increasing the challenge. The system can also allow players to fine-tune the limit values ​​in the settings, such as customizing the pitch angle range to suit personal preferences. This linkage mechanism makes the rotation limits not only a technical limitation but also a tool for game balance and accessibility. Through configurable limits, the game can accommodate a wider player base, improving inclusivity and user satisfaction.

[0086] In an optional implementation, the system-restricted viewpoint rotation includes restricting the virtual camera's pitch rotation direction. By explicitly defining the system-restricted direction as the pitch rotation direction, the system enables players to trigger directional offset assistance from visual identifiers when vertical viewpoint movement is limited. This precisely defines the core scenarios to which this solution applies and effectively solves the problem of players struggling to select vertical targets due to the inability to further raise or lower their viewpoint.

[0087] For example, when a player attempts to tilt the camera upwards to observe a virtual object located at a high position, the virtual camera's tilt angle reaches the system's preset upper limit and cannot continue to rotate. If the virtual object at the high position is within the detection range, the crosshair will shift upwards to point at the target, allowing the player to lock onto the target without moving the character's position.

[0088] The pitch rotation direction refers to the direction of rotation of the virtual camera around the horizontal axis in its local coordinate system, which is used to control the vertical angle change of the observation line of sight.

[0089] Optionally, the pitch rotation direction corresponds specifically to the axis that controls the vertical direction of the view in games or 3D graphics applications. In common third-person or first-person perspectives, this rotation is typically triggered by the player by sliding the screen vertically, moving the mouse vertically, or pushing the right analog stick of a gamepad up or down. The virtual camera rotates around its own lateral axis (usually the X-axis running from left to right through the camera). Rotating upwards increases the pitch angle, directing the view towards the sky or higher; rotating downwards decreases the pitch angle, directing the view towards the ground or lower. Controlling this direction is crucial for exploring 3D space, aiming at targets at different heights, or adjusting composition. Its rotation range is often limited by system design to prevent the view from penetrating the scene model or causing discomfort for the player; for example, excessive upward tilting might reveal the inside of the character model or unreasonable skybox boundaries.

[0090] Optionally, the virtual camera's pitch rotation is restricted, meaning there's an insurmountable boundary value for the angle at which the camera can rotate up or down around its horizontal axis. This restriction is typically pre-set by the game engine or application's system logic, possibly based on factors such as game balance, narrative needs, preventing model glitches, or reducing motion sickness. When the player continuously issues commands to adjust the pitch angle via input devices, the virtual camera responds and rotates, but its pitch angle value is constrained within a closed interval consisting of a minimum and a maximum value. Once the current pitch angle touches any boundary of this interval, regardless of subsequent input commands from the player requesting it to continue rotating in that direction, the virtual camera's pitch angle will remain unchanged; that is, its pitch rotation is "locked" or "stuck" by the system. This restriction is rigid, unlike the slow rotation caused by physics simulation or damping effects; it directly prevents the viewpoint from exceeding the vertical limit.

[0091] Optionally, the system's restriction on the pitch rotation direction is one of the key prerequisites for triggering subsequent judgments and visual marker offset logic. This solution does not activate assistance in all viewpoint rotation scenarios, but intervenes precisely at the specific moment when the pitch rotation degree of freedom is exhausted. When the system detects that the virtual camera can no longer respond to the player's pitch adjustment operations due to reaching the preset pitch angle boundary, it immediately determines that the viewpoint rotation is "system-restricted" in the vertical direction. At this time, the conventional method of directly rotating the viewpoint to align the visual marker with the target fails. The system then activates a compensation mechanism: based on the current restricted viewpoint state, it calculates a judgment range that extends moderately from the line-of-sight reference axis to the original rotation direction. This judgment range is essentially a functional compensation at the software logic level for the lost physical rotation angle, aiming to search for potential interactive targets that have just exceeded the original vertical boundary of the view frustum. Therefore, "the pitch rotation direction is restricted" not only describes a state, but also a triggering event. It marks the transition of the interaction mode from completely manual player control to a system-assisted "manual-automatic" hybrid mode to solve the problem of blind spots in operation caused by rigid design limitations.

[0092] In an optional implementation, the system-restricted viewpoint rotation also includes restricting the virtual camera's horizontal rotation. Thus, in addition to the pitch restriction, when the virtual camera's horizontal rotation also reaches the system's preset rotation boundary, it can trigger subsequent target detection and visual marker offset mechanisms. This helps players locate and select targets in a wider range of scenarios with restricted viewpoint rotation, improving the applicability and flexibility of the solution.

[0093] For example, when a player is exploring a scene, if the terrain or system design causes the player's horizontal rotation angle (such as turning their head left or right) to reach its limit and they can no longer rotate, then if there is an interactive object located to the side within the detection range that was originally impossible to aim at directly due to the limited view, the crosshair in the center of the screen can automatically shift towards the object and point at it, making it convenient for the player to select it without the player having to adjust their orientation through tedious movement.

[0094] Among them, being restricted in the horizontal rotation direction means that the virtual camera's left and right rotation around its vertical axis (such as the Y-axis) is constrained by the angle boundaries set by the system.

[0095] Optionally, the horizontal rotation limit of the virtual camera can be set to create a specific game atmosphere or meet narrative needs. For example, in horror or narrative-driven games, to guide the player's focus or control the pace of the plot, the system strictly limits the range of the player character's horizontal rotation. This limitation is not based on physical collision, but is a soft boundary actively imposed by the game logic. When the player's rotation attempts to exceed this boundary, although the actual orientation of the camera no longer changes, this solution allows key plot items or clues located outside the boundary but still within the detection range to still be captured and selected by the crosshair. This ensures the accessibility of key interactions without disrupting the established narrative framework, maintaining the game's immersion and narrative coherence.

[0096] Optionally, restrictions on horizontal rotation may also stem from the physical environment or equipment status of the virtual character. In one specific scenario, when a character is wearing a heavy helmet with limited field of vision or is in a narrow passage or crack, the horizontal rotation range of their head will be physically limited due to collisions with the virtual environment or constraints imposed by the equipment model itself. In this case, the system calculates and applies rotation boundaries in real time based on collision detection or preset equipment parameters. The value of this solution in this scenario lies in the fact that even if the player's field of vision is physically limited by the environment or equipment, they can still efficiently locate and select objects or enemies that are not in the exact center of their field of vision but are within reach, thanks to the intelligent offset of the crosshair, thus improving operational efficiency and combat survivability in confined spaces.

[0097] Optionally, the system's restrictions on horizontal rotation can be deeply integrated with gameplay mechanics to create unique challenges and puzzle elements. For example, in a puzzle level, the player's camera is limited to discrete horizontal rotations at fixed angles (such as switching between several fixed orientations), preventing smooth rotation. This restriction itself is part of the puzzle. When the player switches to a fixed orientation, if the target object is not precisely in front of that orientation but is at the edge of the detection range, this solution can cause the crosshair to shift towards it, thus hinting to the player that there is an interactive element in that direction. This reduces the frustration of searching due to a rigid perspective and cleverly integrates guiding information into the puzzle-solving process itself, enriching the gameplay layers.

[0098] In an optional implementation, determining the target virtual object within the judgment range from the virtual objects includes: filtering the virtual objects within the judgment range and identifying virtual objects with interactive attributes as candidate virtual objects; and determining the target virtual object from the candidate virtual objects. In this way, by filtering virtual objects with interactive attributes as candidates, non-interactive virtual objects can be effectively excluded, ensuring that the subsequent target determination process focuses on truly operable targets, thereby improving selection accuracy and operational efficiency, and reducing ineffective attempts by players.

[0099] For example, in a game scenario, when the virtual camera reaches its pitch and rotation limits and can no longer adjust its viewpoint, the system scans multiple virtual objects within the detection area. For instance, the system first identifies all virtual objects within the area, then checks whether each object is marked as "pickable" or "interactive," and only includes objects with interactive attributes in the candidate list. Then, based on preset rules, it selects a target virtual object from the candidate list, causing the visual marker on the screen to automatically shift and point towards that target.

[0100] Interactive attributes refer to the characteristics of virtual objects that can be operated or interacted with by users. Their function is to identify whether an object can be used as a valid interaction target, so as to guide the system to perform preliminary screening.

[0101] Optionally, interactive attributes can be represented as metadata tags or specific status flags attached to virtual objects. In game engine architecture, developers typically add components such as "Interactable" to interactive objects, which encapsulate interaction trigger conditions, feedback logic, and related parameters. When the system iterates through virtual objects within its scope, it checks whether each object carries such a component or tag. Only objects that pass the check are considered to have interactive attributes and thus enter the candidate virtual object set. This component- or tag-based design makes attribute management highly modular, facilitating reuse and adjustment in different game scenarios. For example, different sub-components can be defined for different types of interactions such as picking up, attacking, and dialogue. The system can filter specific types of interactive attributes based on the current game context (such as the player holding a tool or the stage of a task), thereby enhancing the targeting and flexibility of the filtering. This mechanism not only ensures the efficiency of the filtering process but also provides game designers with fine-grained control to create richer interactive experiences.

[0102] Optionally, the determination of interactive attributes can also rely on the dynamic logical state of an object rather than static labels. For example, a virtual fruit may only be pickable when ripe; a mechanism may only be operable after being unlocked. When performing filtering, in addition to checking static labels, the system also needs to call the object's logical state query interface to evaluate in real time whether it currently meets the interaction conditions. This dynamic determination avoids misselection or omission due to changes in object state, making the filtering results more in line with the real-time changes in the game world. In addition, the system can combine player character status (such as skills and equipment) for condition matching to ensure that candidate objects match the player's current abilities. This dynamic attribute management increases the realism and strategic depth of the game world, while requiring the system design to have an efficient state query and caching mechanism to balance performance and accuracy.

[0103] Optionally, interactive attributes can be categorized based on the urgency or priority of the interaction. For example, in a combat scenario, attackable objects may have a high priority, while in an exploration scenario, collectible objects may receive more attention. During the filtering process, the system can assign weights to different priority attributes, prioritizing objects with higher weights in the candidate list. Priority information can be stored in object attributes or dynamically calculated by game rules (e.g., based on distance or threat level). This categorization mechanism ensures that the candidate virtual object set not only includes interactive objects but also implicitly suggests the order of interactions, providing a basis for subsequent target determination. Simultaneously, the priority design allows the game to guide player attention, enhances control over the game's pace, and conveys priority information to players through visual cues (e.g., highlight intensity), achieving more intuitive interaction guidance.

[0104] Among them, candidate virtual objects refer to a set of virtual objects with interactive attributes after preliminary screening. Their role is to provide an optimized range of candidates for the final target determination and to narrow down the selection targets.

[0105] Optionally, the candidate virtual object set is generated by applying one or more layers of filtering conditions to all virtual objects within the decision range. Initial filtering is typically based on interactivity attributes, but the system can further introduce other dimensions, such as the approximate angular difference between the object and the viewpoint reference axis, the object's projection size in screen space, or its logical distance from the player. These additional conditions can be configured as filtering thresholds, for example, retaining only interactive objects with angular differences less than a certain value as candidates. This hierarchical filtering strategy breaks down target determination into two stages: first, quickly narrowing the scope using broad conditions, and then determining the final target using refined rules. This design reduces the real-time computational burden, significantly improving system response speed, especially when the number of objects within the decision range is large. Furthermore, configurable filtering parameters allow game designers to flexibly adjust the filtering strictness to adapt to different gameplay requirements.

[0106] Optionally, the candidate virtual object set can be organized according to predefined or dynamically calculated sorting rules. A common sorting method is to calculate the angular deviation between each candidate object and the line-of-sight reference axis, and arrange the candidate list in ascending order of deviation. This way, when determining the target virtual object later, the system can directly select the first object in the list as the default target. The sorting process can be executed immediately after filtering or maintained incrementally during the filtering process. In addition to angular deviation, the sorting rules can also take into account object type priority, player historical interaction preferences, or scene context weights. This ordered candidate set not only accelerates target determination but also makes target selection behavior more predictable and consistent, making it easier for players to understand the system's automatic selection logic and reducing cognitive burden. Furthermore, the sorted list can provide a basis for player manual intervention, such as allowing players to jump sequentially when switching between candidates.

[0107] Optionally, the size of the candidate virtual object set can be dynamically adjusted based on real-time performance or game context. The system can set a maximum limit on the number of candidates. When the number of selected objects exceeds this limit, only the most relevant objects (e.g., those with the smallest angular deviation or highest priority) are retained as valid candidates. Relevance calculation can be based on a weighted score of multiple factors, including spatial proximity, task criticality, or object prominence. Dynamic size control helps avoid an overly bloated candidate list in complex scenes, ensuring that system resources are focused on the most likely targets. Simultaneously, when the number of candidate objects is too small, the system can appropriately relax the selection criteria to expand the candidate set, ensuring the possibility of interaction. This flexible mechanism balances selection precision and coverage, adapts to varying game environments, and allows for difficulty adjustment through configuration parameters, such as expanding the candidate range in simple mode to reduce operational difficulty.

[0108] In an optional implementation, determining the target virtual object from the candidate objects includes: calculating the angular deviation between the viewing reference axis and each candidate object; and determining the candidate object with the smallest angular deviation as the target virtual object. In this way, when multiple candidate objects exist within the judgment range, the target closest to the player's current viewing direction can be automatically determined, making the visual marker offset selection more intuitive and improving the accuracy and efficiency of target selection.

[0109] For example, when the virtual camera cannot rotate further due to system limitations, if there is both a harvestable fruit tree and an attackable enemy as candidate objects within the detection range, the system will calculate the angular deviation between the line-of-sight reference axis and the center point of each of these two objects. Assuming the angular deviation from the fruit tree is 8 degrees and the angular deviation from the enemy is 5 degrees, the system will identify the enemy as the target virtual object because its angular deviation is the smallest.

[0110] Among them, angular deviation refers to the angular difference between the line-of-sight reference axis and the candidate object. It is used to quantify the degree of deviation of the candidate object from the player's current line of sight and serves as the basis for selecting the target.

[0111] Optionally, the angle deviation can be calculated based on either the screen space coordinate system or the 3D world coordinate system. In screen space, the system projects the direction of the viewing reference axis onto the 2D screen, forming a reference direction line. Simultaneously, it compares the projection center point of each candidate object on the screen with this reference direction line to calculate its deviation angle. This method is simple to calculate and directly reflects the visual deviation of the target in the player's field of view. In the 3D world coordinate system, the angle deviation is obtained by calculating the angle between a unit vector pointing from the virtual camera position towards the viewing reference axis and a unit vector pointing towards the center point of the candidate object. This calculation method is more consistent with the geometric relationships of 3D space and can accurately reflect the difference in orientation between the object and the viewpoint in the real game world. Regardless of the coordinate system used, the core purpose of the angle deviation is to provide a comparable numerical indicator to objectively measure the closeness of each candidate object to the player's intended direction.

[0112] Optionally, the specific calculation of the angle deviation can be implemented using vector mathematics. The system first obtains the direction vector of the line-of-sight reference axis, which is usually determined by the position and orientation of the virtual camera. Next, for each candidate object, the system calculates the vector from the camera position to the geometric center of the object (or a preset interaction hotspot). Then, the system calculates the cosine of the angle between these two vectors using the vector dot product formula, and then obtains the precise angle value using inverse trigonometric functions. This angle value is the angle deviation of the candidate object. Furthermore, when considering the rotation constraints in both pitch and horizontal dimensions, the calculation of the angle deviation may need to be decomposed into the yaw angle deviation in the horizontal plane and the pitch angle deviation in the vertical plane, and then weighted and synthesized to more accurately reflect the player's rotation intentions and constraints in different directions, thereby ensuring that the selected target best matches the player's operational expectations in terms of overall spatial orientation.

[0113] Optionally, the calculation of angle deviation can be dynamic and continuous. When a player continuously presses the screen and attempts to fine-tune the viewing direction (even if the actual viewing angle remains unchanged due to system limitations), the system can recalculate the angle deviation of each candidate object in real-time or frame-by-frame. This dynamic calculation allows target selection to respond to subtle changes in the player's operational tendencies. For example, if the player's finger slightly slides to the left, the system can simulate a "desired" leftward shift in the gaze and, when calculating the angle deviation, virtually shift the gaze reference axis slightly to the left before performing the calculation, thus identifying the candidate object on the left as the target with a smaller angle deviation in advance. This mechanism incorporates the player's input into the deviation calculation, enabling indirect and smooth switching of the locked target through gesture cues at a fixed camera angle, enhancing the flexibility of control and the accuracy of intention tracking.

[0114] Among them, the minimum angle deviation refers to the minimum value of the angle deviation values ​​of all candidate objects. The candidate object corresponding to this value is determined as the final target, thus realizing automated optimal target selection.

[0115] Optionally, determining the minimum angular deviation involves iterative comparison. After calculating the angular deviation for all candidate objects, the system stores these deviation values ​​in a temporary list or array for sorting and comparison. Through a single iteration, the system can find and record the minimum angular deviation value and its corresponding candidate object identifier in the current frame. This process is efficient and deterministic, ensuring clarity and consistency in the selection logic in multi-object environments. In complex game scenes, candidate objects may frequently enter or leave the judgment range, so this iterative comparison process may need to be re-executed each frame to ensure that the "minimum angular deviation" target is always the optimal solution at the current moment. This design ensures real-time response, allowing the offset of visual identifiers to closely follow changes in target priority in the scene, providing players with continuous and accurate target indication.

[0116] Optionally, when two or more candidate objects have the same minimum angular deviation, the system needs a set of auxiliary decision-making rules. A common approach is to introduce a second ranking metric, such as calculating the straight-line distance between the candidate object and the virtual camera, identifying the closer object as the final target. This aligns with the player's intuition of prioritizing nearby targets. Another approach is based on object type or attribute priority; for example, in combat scenarios, threatening enemy objects may have a higher priority than collectable objects in the environment. Yet another approach is to keep the currently selected target unchanged unless a new candidate object has a significantly smaller angular deviation (i.e., setting a tolerance threshold) to avoid visual jitter caused by frequent switching between targets with similar deviation values, thus maintaining operational stability and visual comfort.

[0117] Optionally, the minimum angular deviation filtering mechanism can be combined with a filtering threshold to improve the experience. The system can preset a maximum effective threshold for angular deviation, and only candidates with angular deviations less than this threshold will participate in the "minimum angular deviation" competition. This is equivalent to setting an effective selection boundary, avoiding forcibly identifying objects with the smallest angular deviations but still excessively large deviations as targets, and preventing unnatural or confusing long-distance jumps in visual identifiers. For example, the threshold can be set to 15 degrees, meaning that only candidates within a 15-degree cone range to the left and right of the line-of-sight reference axis will be considered. This design ensures that the automatic offset mechanism only works on targets "near" the player's line of sight, reinforcing the positioning of "aiming assistance" rather than "automatic pathfinding," providing convenience while retaining the player's final control.

[0118] In an optional implementation, controlling the visual identifier to generate a directional offset includes: calculating the offset between the projected position of the target virtual object in screen space and the current position of the visual identifier; and controlling the visual identifier to move to the projected position based on the offset. In this way, by accurately calculating the position offset and driving the visual identifier to move, precise alignment between the visual identifier and the projected target object on the screen is achieved, allowing players to accurately select the target without manual fine-tuning, thus improving the accuracy and convenience of the interaction.

[0119] For example, once the target virtual object is determined, the system calculates the coordinates of the center point of the object in the two-dimensional coordinate system of the screen, and calculates the vector difference between the coordinate point and the center point of the screen (i.e. the initial position of the visual identifier). Then, the visual identifier will smoothly move from the center of the screen to the projection position of the target object according to this vector difference, thereby completing the directional offset.

[0120] Screen space refers to the two-dimensional coordinate system corresponding to the display screen of the terminal device, which is used to define the final presentation position of all visual elements in the graphical user interface.

[0121] Optionally, screen space is a two-dimensional Cartesian coordinate system, with its origin typically located at the top-left, bottom-left, or center of the screen. The horizontal and vertical axes correspond to the width and height of the screen, respectively, and coordinate values ​​are usually in pixels. Virtual objects in a 3D game scene, including target virtual objects, need to undergo a series of transformations in the graphics rendering pipeline, especially through the projection transformation of the virtual camera, to map their 3D world coordinates to this two-dimensional coordinate system, generating their "projected position" on the screen. This mapping process ensures that the 2D image seen by the player accurately reflects the perspective relationships in 3D space and the relative positions between objects. In the process of visual identifier control, screen space serves as a unified reference system, enabling the system to accurately calculate the geometric relationship between the current position of the visual identifier and the projected position of the target object, providing a foundation for subsequent offset calculations and movement control. Transforming 3D spatial relationships into 2D screen space simplifies the complexity of position determination and UI element control.

[0122] Optionally, the screen space coordinate range can be normalized according to design requirements. For example, the range of screen width and height can be mapped to the [0, 1] interval. This normalization makes the offset calculation independent of the specific resolution of the device, improving the adaptability and consistency of the solution on devices with different screen sizes. When calculating the projection position, the clipping space coordinates of the 3D model vertices are divided by perspective to obtain normalized device coordinates, whose x and y components are usually in the range of [-1, 1]. These can then be converted into screen space normalized coordinates in the range of [0, 1] through a simple linear transformation. When calculating the offset, the system can directly use these normalized coordinates, thereby avoiding numerical overflow or precision problems that may occur when calculating directly in pixel units on a high-resolution screen, ensuring the stability and accuracy of visual sign movement control.

[0123] Optionally, in addition to determining static positions, the concept of screen space is also associated with a dynamic update mechanism. At the start of each frame's rendering, the system recalculates the projected positions of all relevant virtual objects in screen space based on the latest virtual camera parameters. When a target virtual object undergoes a slight change due to its own animation or its position relative to the camera, its projected position in screen space is also updated accordingly. Accordingly, the system can continuously or frame-by-frame recalculate the offset and dynamically adjust the movement trajectory or final position of the visual identifier, creating a "follow" effect. This screen space-based dynamic update mechanism ensures that even with slight dynamic changes in the target object or camera, the visual identifier's pointing remains accurate, enhancing the real-time nature and realism of interactive feedback and avoiding pointing errors or visual jitter caused by data update delays.

[0124] The projection position refers to the two-dimensional coordinate position of the target virtual object in the screen space after the projection transformation of the graphics rendering. It usually represents the visual center or key anchor point of the object on the screen.

[0125] Optionally, the projection position is obtained by transforming the 3D model of the target virtual object (usually the center point of its bounding box or a specific interactive anchor point) from the world coordinate system to the screen coordinate system. This transformation process includes model transformation, view transformation, and projection transformation in sequence. Model transformation determines the object's pose; view transformation, based on the position and orientation of the virtual camera, transforms the object to the camera coordinate system; the crucial projection transformation (usually using a perspective projection matrix) is responsible for mapping points in the 3D camera space to the 2D clipping space, and finally converting them to screen pixel coordinates through viewport transformation. Through this standard graphics workflow, the system can accurately calculate where the target object should be drawn on the screen from the player's current perspective. This position is the "destination" that guides the visual identifier's offset.

[0126] Optionally, the calculation of the projection position can be refined for specific parts of the target virtual object, rather than simply the center of its overall bounding box. For example, for a character model, its meaningful interaction points might be the head, hands, or the weapon in hand. The system can pre-define "hot spots" or "anchor points" skeletal nodes for these important interaction points. After identifying the target object, the system selects the predefined main interaction anchor points on the object as the basis for calculating the projection position. By calculating the position of this specific skeletal node in world space and performing the same view and projection transformations, a more precise projection position in screen space is obtained. This approach makes the offset and pointing of visual identifiers more accurate, directly targeting the specific parts that the player may intend to interact with, thereby improving the intuitiveness of the interaction and the efficiency of operation, and avoiding the feeling of misoperation caused by pointing to the coarse center of the object.

[0127] Optionally, in multiplayer or online game environments, the calculation of the projected position of the target virtual object also needs to consider positional differences caused by network synchronization. The object coordinates used by the client to calculate the projected position locally may have slight differences from the server's authoritative coordinates due to network latency. To maintain fairness while keeping response speed up, one strategy is for the client to use the interpolated or predicted local coordinates used in its current rendering frame to calculate the projected position, ensuring the immediacy and smoothness of visual marker movement. Simultaneously, the system can submit this "projected position" information, or the back ray detection result based on this position, to the server for verification when initiating an actual interaction request. The server then recalculates or verifies the legitimacy of the interaction using its authoritative coordinates. This separate processing balances the smooth experience of local operations with the fairness and accuracy of online interactions.

[0128] The offset refers to the vector difference in screen space between the current position of the visual identifier and the projection position of the target virtual object. It indicates the direction and distance that the visual identifier needs to move.

[0129] Optionally, the offset is a two-dimensional vector whose two components represent the distances that need to be compensated along the horizontal axis (e.g., the X-axis) and vertical axis (e.g., the Y-axis) in screen space. Calculating this offset involves a simple vector subtraction: subtracting the coordinate vector of the visual identifier's current position from the coordinate vector of the target's projected position. The resulting vector direction is the path from the identifier's current position to the target position, and the vector's magnitude (i.e., length) represents the straight-line distance that needs to be moved. After obtaining this offset, the system can directly use it as a core parameter for movement commands. For example, the direction of the visual identifier's movement can be determined based on the vector's direction, and the duration or speed of the movement animation can be determined based on its magnitude. This vector-based calculation method has clear geometric meaning and facilitates the implementation of various movement control strategies, such as uniform linear movement or physics-based easing movement.

[0130] Optionally, the use of offset is not limited to driving a one-time, direct movement from start to finish. The system can design more complex motion trajectories or dynamic responses based on the initially calculated offset. For example, the offset can be decomposed into horizontal and vertical components, and different motion curves or response functions can be configured for each component to achieve non-linear motion effects, such as differentiated animations that move quickly horizontally and follow slowly vertically. Furthermore, when a player continuously presses the screen and attempts to fine-tune the viewpoint (e.g., on a handover document), the system can add the displacement vector input by the player's touch, with a certain weight, to the initially calculated target offset, thereby dynamically and continuously updating the expected target position and real-time movement direction of the visual identifier, achieving smooth target switching under manual intervention. This transforms the offset from a static parameter into one of the core inputs for dynamic motion control.

[0131] Optionally, the calculation and processing of offsets also need to consider the interface layout and preventing visual identifiers from moving out of the visible area. After obtaining the original offset, the system can constrain it. For example, there may be fixed UI elements (such as health bars and skill buttons) at the edge of the screen, and visual identifiers should avoid moving to these areas to cover important information. Therefore, the system can clamp the calculated target projection position according to the preset "safe area" boundary to ensure that it falls within the safe area, and then recalculate the final constrained offset based on the clamped position. In addition, to prevent visual identifiers from instantly "jumping" to the edge of the screen or beyond due to excessive offset, the system can set a maximum allowable offset distance. When the original offset magnitude exceeds this threshold, it is normalized according to the threshold, and only a partial offset is performed proportionally, or combined with other prompts (such as arrow guidance) to indicate the target direction, thereby providing assistance while maintaining the overall stability and readability of the interface.

[0132] In an optional implementation, controlling the movement of the visual identifier includes moving it with smooth animation. This makes the movement of the visual identifier smooth and natural, avoiding player discomfort caused by abrupt jumps in the visual identifier and improving the comfort of the interactive experience.

[0133] For example, when a visual identifier needs to point to a target virtual object within the judgment range, the visual identifier moves from its current position to the screen projection position of the target virtual object. This movement is achieved through smooth animation, such as using linear interpolation or easing functions, so that the movement trajectory of the visual identifier is continuous and the speed changes smoothly, thereby providing a more natural visual feedback.

[0134] Among them, smooth animation refers to the use of animation transition effects during the movement of visual logos. Its purpose is to make the movement process visually continuous and smooth, reducing abruptness.

[0135] Optionally, smooth animation can be achieved using linear interpolation. Linear interpolation is a basic animation technique that calculates the intermediate position between the starting and target positions of a visual identifier based on a time parameter, achieving uniform movement of the visual identifier. This algorithm is computationally simple and has low performance overhead, making it suitable for game scenarios with high real-time requirements. Linear interpolation ensures a straight movement path, resulting in visual continuity without jumps, but the constant movement speed may appear mechanical. For further optimization, the interpolation weights can be fine-tuned using a time curve to give the movement a slight sense of acceleration or deceleration, improving naturalness. In implementation, interpolation calculations are typically performed based on frame time to ensure that the animation progress is synchronized with time, avoiding animation stuttering or jumps caused by frame rate fluctuations. Linear interpolation algorithms are widely used in game user interfaces, such as for the movement of elements like crosshairs and icons, due to their stability and reliability, and ease of integration into existing game loops. By adjusting the interpolation step size and animation duration, smoothness and responsiveness can be balanced to meet different interaction requirements.

[0136] Optionally, smooth animation can also employ easing functions to enhance the naturalness of the animation. Easing functions define the change in speed over time through mathematical curves. For example, easing-in and easing-out functions make the animation slower at the beginning and end, and faster in the middle, simulating the inertial motion of real objects. This speed variation makes the movement of visual identifiers more vivid, conforms to user expectations, and reduces user fatigue. Easing functions are implemented based on mathematical models such as quadratic and sine functions, and game engines often have a variety of built-in easing functions for developers to choose from. In visual identifier movement scenarios, easing functions can flexibly adjust the dynamic effects of the movement trajectory, such as elastic or rebound effects, to increase visual appeal. Through parameterized configuration, developers can precisely control the rhythm and emotional expression of the animation, making it consistent with the overall style of the game. In addition, easing functions can be combined with user input, such as dynamically adjusting the animation curve when the player continuously adjusts the viewpoint, to achieve more intelligent interactive feedback. The advantage of this approach is that it enhances the immersive experience of the user experience, making the movement of visual identifiers not only highly functional but also more artistically expressive.

[0137] Optionally, smooth animation can be combined with screen refresh rate for frame synchronization to ensure smooth animation. During gameplay, animation updates need to be synchronized with the display device's refresh cycle. Typically, the new position of visual identifiers is calculated and rendered every frame to avoid screen tearing or jitter. Time-based animation updates advance the animation state based on the time increment since the previous frame. Regardless of the frame rate, the animation completes within a fixed time, ensuring consistency. For example, if the visual identifier movement animation is set to 0.3 seconds, the system updates the position every frame based on the elapsed time until the target is reached at the end of 0.3 seconds. This mechanism adapts to different hardware performance, maintaining a smooth experience, especially on mobile devices. Furthermore, the animation duration can dynamically adapt to the movement distance; short movements are completed quickly to maintain responsiveness, while long movements are prolonged to show a smooth transition. Frame synchronization technology is often combined with vertical synchronization or variable refresh rate technology to further optimize smoothness. For better results, the animation system can predict frame time and use interpolation compensation to reduce animation stuttering caused by frame rate fluctuations. Smooth animation can also integrate post-processing such as motion blur to enhance visual continuity, but this requires a trade-off in performance overhead. In summary, frame-synchronized smooth animation ensures the stability and comfort of visual icon movement, improving the overall interaction quality.

[0138] Combination Figure 4a as well as Figure 4b A specific embodiment of this disclosure is described below. The graphical user interface 400 includes multiple game control controls, such as a view adjustment control 420, a pick-up control 430, a backpack control 450, and a movement control 440. Players control the game character to move within the game scene 410 by sliding the movement control 440, and adjust the game view by sliding the view adjustment control 420 to orient the virtual camera in the game scene, aligning the visual marker 410 with the virtual fruit to be picked. Players click the pick-up control 430 to pick the virtual fruit aligned with the view marker 410. The picked virtual fruit can be stored in the virtual backpack, and the picked virtual fruit can be viewed by clicking the backpack control 450. In this embodiment, as... Figure 4a As shown, the viewpoint rotation is limited by the system, meaning the virtual camera's elevation angle has reached its maximum. At this point, the virtual camera's line-of-sight reference axis does not hit the virtual fruit 4041 (i.e., the visual identifier does not coincide with the display position of the virtual fruit in the graphical user interface). The virtual fruit 4041 is identified as the target virtual object, and the visual identifier 410 in the graphical user interface 400 is controlled to produce a directional offset to point towards the target virtual object, as shown. Figure 4bAs shown, the visual identifier 410 moves to the display position of the virtual fruit 4041 on the graphical user interface 400. Using the method of this disclosure, when the rotation of the virtual camera is restricted, players do not need to repeatedly move the virtual character to select the scene element to be interacted with. Instead, the visual identifier automatically shifts and points to the target, quickly locating it and improving the convenience and experience of game operation.

[0139] Exemplary embodiments of this disclosure also provide a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the methods described above.

[0140] In one implementation, the computer program product can be a tangible product containing a computer program, such as a computer-readable storage medium storing the computer program. The readable storage medium can be a storage medium based on electrical, magnetic, optical, electromagnetic, infrared, or other signals, including but not limited to: random access memory (RAM), read-only memory (ROM), magnetic tape, floppy disk, flash memory, hard disk drive (HDD), solid-state drive (SSD), etc. For example, the computer program product can be implemented as a non-volatile storage medium storing a computer program, such as read-only memory, NAND flash memory, etc.

[0141] In one implementation, the computer program product can be an intangible product containing a computer program. For example, the computer program product can be implemented as a virtual digital product, such as an executable file, installation package, or other digital file storing the computer program.

[0142] Computer program code can be written in one or more programming languages. Examples of programming languages ​​include C, Java, and C++. Program code can execute entirely on the user's computing device, partially on the user's computing device, or as a standalone software package. It can also execute partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, such as a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via an internet connection provided by a mobile network operator).

[0143] Computer programs can be carried or transmitted via signals such as electricity, magnetism, light, electromagnetic fields, and infrared radiation. Electronic devices can convert signals carrying computer programs into digital signals, thereby running the computer programs. When a computer program runs on an electronic device, its code is used to cause the electronic device to execute (more specifically, to be executed by the processor of the electronic device) the method steps of various exemplary embodiments of this disclosure, such as: a visual identifier control method, the method comprising: controlling a virtual camera in a game scene to rotate its viewpoint in response to an adjustment operation for a game viewpoint; determining the current viewpoint frustum of the virtual camera in response to a system restriction on the viewpoint rotation; if a virtual object exists within the current viewpoint frustum and the virtual object is not located on the line-of-sight reference axis of the current viewpoint frustum, determining a target virtual object located within a determination range from the virtual objects; and controlling a visual identifier in a graphical user interface to generate a directional offset to point to the target virtual object.

[0144] Exemplary embodiments of this disclosure also provide an electronic device. The electronic device may include a processor and a memory. The memory stores executable instructions for the processor, such as a computer program. The processor executes the executable instructions to perform the method steps of various exemplary embodiments of this disclosure. Furthermore, the electronic device may also include a display for displaying a graphical user interface.

[0145] The following is for reference. Figure 5 The electronic device is illustrated by way of a general-purpose computing device. It should be understood that... Figure 5 The electronic device 500 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.

[0146] like Figure 5 As shown, the electronic device 500 may include: a processor 510, a memory 520, a bus 530, an I / O (input / output) interface 540, a network adapter 550, and a display 560.

[0147] Memory 520 may include volatile memory, such as RAM 521 and cache unit 522, and may also include non-volatile memory, such as ROM 523. Memory 520 may also include one or more program modules 524, including but not limited to: operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. For example, program module 524 may include the modules in the above-described apparatus.

[0148] Processor 510 may include one or more processing units, such as: AP (Application Processor), modem processor, GPU (Graphics Processing Unit), ISP (Image Signal Processor), controller, encoder, decoder, DSP (Digital Signal Processor), baseband processor and / or NPU (Neural-Network Processing Unit).

[0149] The processor 510 can be used to execute executable instructions stored in the memory 520 to perform the methods described above in this disclosure, such as the following method steps: a visual identifier control method, the method comprising: in response to an adjustment operation for a game viewpoint, controlling a virtual camera in a game scene to rotate its viewpoint; in response to the viewpoint rotation being restricted by the system, determining the current view frustum of the virtual camera; if a virtual object exists within the current view frustum and the virtual object is not located on the line-of-sight reference axis of the current view frustum, determining a target virtual object located within a determination range from the virtual objects; controlling a visual identifier in the graphical user interface to generate a directional offset to point to the target virtual object.

[0150] Bus 530 is used to connect different components of electronic device 500 and may include a data bus, an address bus and a control bus.

[0151] Electronic device 500 can communicate with one or more external devices 600 (such as keyboard, mouse, external controller, etc.) through I / O interface 540.

[0152] Electronic device 500 can communicate with one or more networks via network adapter 550. For example, network adapter 550 can provide mobile communication solutions such as 3G / 4G / 5G, or wireless communication solutions such as wireless LAN, Bluetooth, and near-field communication. Network adapter 550 can communicate with other modules of electronic device 500 via bus 530.

[0153] Electronic device 500 can display a graphical user interface, such as virtual scenes and virtual characters, through display 560.

[0154] although Figure 5Other hardware and / or software modules may also be configured in the electronic device 500, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID (Redundant Arrays of Independent Disks) systems, tape drives, and data backup storage systems.

[0155] As can be seen from the above, the technical solutions disclosed herein can be implemented as methods, systems, computer program products, storage media, electronic devices, etc. Those skilled in the art will understand that various aspects of this disclosure can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combined hardware and software implementation, which may be referred to as a "circuit," "module," or "system," respectively.

[0156] It should be understood that this disclosure is not limited to the specific methods, steps, or structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. Those skilled in the art will readily conceive of other embodiments based on the specific implementations provided in this disclosure. Therefore, the specific implementations provided in this disclosure are merely exemplary, and the scope and spirit of this disclosure are indicated by the claims, and should cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary technical means in the art not disclosed in this disclosure.

Claims

1. A visual identifier control method, characterized in that, The method includes: In response to adjustments made to the game's viewpoint, control the virtual camera in the game scene to rotate the viewpoint; In response to the viewpoint rotation being restricted by the system, the current view frustum of the virtual camera is determined; If a virtual object exists within the current visual cone, and the virtual object is not located on the line-of-sight reference axis of the current visual cone, a target virtual object within the determination range is determined from the virtual objects. The visual identifiers in the graphical user interface are controlled to generate a directional offset to point to the target virtual object.

2. The method as described in claim 1, characterized in that, The method further includes: The determination range is determined based on the line-of-sight reference axis.

3. The method as described in claim 2, characterized in that, Determining the judgment range based on the line-of-sight reference axis includes: The range of angles generated by offsetting the reference axis of the line of sight by a preset distance angle along the direction of the restricted rotation of the viewpoint is determined as the judgment range.

4. The method as described in claim 1, characterized in that, The response to the viewpoint rotation being restricted by the system includes: The virtual camera rotates to the desired angle under the adjustment operation, reaching the system's preset rotation boundary.

5. The method as described in claim 1 or 4, characterized in that, The system restricts the viewpoint rotation, including restricting the virtual camera's pitch rotation direction.

6. The method as described in claim 1 or 4, characterized in that, The system-restricted viewpoint rotation also includes the restriction on the virtual camera's horizontal rotation direction.

7. The method as described in claim 1, characterized in that, Determining the target virtual object within the judgment range from the virtual objects includes: The virtual objects within the determination range are filtered, and virtual objects with interactive attributes are identified as candidate virtual objects; The target virtual object is determined from the candidate virtual objects.

8. The method as described in claim 7, characterized in that, Determining the target virtual object from the candidate objects includes: Calculate the angular deviation between the line-of-sight reference axis and each of the candidate objects; The candidate object with the smallest angular deviation is determined as the target virtual object.

9. The method as described in claim 1, characterized in that, The control of the visual identifier to generate a directional offset includes: Calculate the offset between the projected position of the target virtual object in screen space and the current position of the visual identifier; The visual identifier is moved to the projection position based on the offset.

10. The method as described in claim 9, characterized in that, Controlling the movement of the visual identifier includes moving it in a smooth animation manner.

11. An electronic device, characterized in that, include: processor; as well as A memory for storing a data processing program, which, when powered on and run by the processor, executes the method as described in any one of claims 1 to 10.

12. A computer-readable storage medium, characterized in that, The system contains a data processing program that is executed by a processor to perform the method as described in any one of claims 1 to 10.

Images